<shlevy>
sphalerite: I'll look at a real fix soon :D
<sonarpulse>
would something prevent me autojoining this one?
<zimbatm>
if I could get a cname for community.nixos.org then I am happy to pay for the discourse instance
<MichaelRaskin>
Frankly, committing plain text files into a repository with commit access granted by borg (optionally: by email request, just for lulz) sounds better and better with each _next_ web-based discussion system that doesn't seem better than email
<gchristensen>
yeah... I feel the email integration must be really good, since we even have a few people who send patches by mail still
<hl>
wait, since when does discourse have proper threading?
<MichaelRaskin>
We-ell, the only benefit of google groups is that no one can afford to admit the truth
<MichaelRaskin>
And recognise that GMail is a major source of spam
<hl>
it's probably the most used platform for FOSS mailing lists and I'm not aware of people having an issue with it
<angerman>
Sonarpulse: i wish we could hide the buildPackages hackery....
<sonarpulse>
per that thing I linked you
<sonarpulse>
it is supposed to apply to both package sets
<sonarpulse>
does it not?
<angerman>
Sonarpulse: not the buildpackages per se ... but the need to deal with them from a users point.
<angerman>
Sonarpulse: I tried it, couldn't get it to work.
<sonarpulse>
hmmm
<MichaelRaskin>
Maybe committing the mailing list snapshot in plain text in a repo could be a good idea just to provide a reasonable way to access archives… also a way to access archives that survives mailing list migration
<angerman>
Sonarpulse: anyway. that expression now fully works ;-)
<sonarpulse>
the logic should be barely decipherable if you grep for "allowCustomOverrides"
<sonarpulse>
great!!
<angerman>
Sonarpulse: I just think it still too much "hacking", and not clean enough... so I'm probably just complaining on the UX part.
<gchristensen>
tbh I miss the old ML :|
<sonarpulse>
angerman: no you are right, it's definitely not as clean as intended
<shlevy>
gchristensen: I do too
<sonarpulse>
.....I should read more mailing list so I'd know why I'd miss the old
<sonarpulse>
:D
<gchristensen>
the long and short of it is google groups is really bad
<sonarpulse>
ah ok
<gchristensen>
after the migration postings to the ML dropped a lot, too, I think
<sonarpulse>
verry lagggy I recall
<gchristensen>
and the archives are very difficlut to read if you don't log in to your google account
<clever>
error: anonymous function at /nix/store/7jwzj1glsf7fp0b9iqm1mwgf34wdmq44-nixos-18.03pre129076.831ef4756e3/nixos/pkgs/development/compilers/ghc/head.nix:1:1 called with unexpected argument 'ghcRevision', at /nix/store/7jwzj1glsf7fp0b9iqm1mwgf34wdmq44-nixos-18.03pre129076.831ef4756e3/nixos/lib/customisation.nix:74:12
<clever>
angerman: i suspect its sensitive to which version of nixpkgs is used
<clever>
angerman: which revision of nixpkgs did you use?
<sonarpulse>
yeah best to pin it
<shlevy>
Sonarpulse: Any reason why adding updateAutotoolsGnuConfigScriptsHook to extraNativeBuildInputs like aarch64 has it wouldn't take effect for dependencies of glibc?
<shlevy>
Sonarpulse: glibc 2.27 needs bison, and its config.guess is out of date
<samueldr>
dfeed is not a web-based forum, but an interface to NNTP; it may actually be the most approachable interface to mailing lists imho
<gchristensen>
hl: the problem is then we'd need to maintain a mail server
* dtz
misses NNTP
<sonarpulse>
maybe we should just add that for everything everywhere, haha
<shlevy>
I just changed the 'localSystem.isArch64' to 'localSystem.isArch64 || localSystem.isRiscV' in linux/default.nix
<shlevy>
Yeah, we should
<gchristensen>
hl: and I don't know about you, but I charge hazard pay for email servers
<hl>
gchristensen (IRC): is there some issue with that?
<sonarpulse>
dtz: yeah i was never around for usenet
<sonarpulse>
but it seemed quite good
<sonarpulse>
and downhill since
<sonarpulse>
in concept
<shlevy>
Oh, it's only added in bootstrap-stage3
<sonarpulse>
yeah
<MichaelRaskin>
The problem with mail servers is that they are always targets for spam emails and false spam accusations
<shlevy>
OK
<shlevy>
I'll just add it unconditionally to early stdenv?
<sonarpulse>
shlevy: cool!
<hl>
gchristensen (IRC): you know I don't get this - there's a lot of bad reputation around the occupation of running mail servers ("oh no, don't do that"), but I've been running one for years and never had any issues really
<sonarpulse>
the more the merrier!
<hl>
I find it very low maintenance
<shlevy>
I'm definitely wary of taking on more maintenance burden in our community right now... stuff like ofborg can't be done any other way, but there are other hosted mailing lists out there :P
<gchristensen>
hl: well that may be, my experience has been angry customers (set A) and angry customers (set B). set A are people I'm running it for, and their mail has too much spam, and set B is because they don't get the messages sent reliably
lopsided98 has quit [Ping timeout: 245 seconds]
<gchristensen>
shlevy++
<hl>
shlevy (IRC): What service would you recommend?
<shlevy>
hl: I don't have a specific recommendation, just anti-recommendations :) Not productive, I know, so I can't insist on it, but I do think we should think very hard and do our due diligence before committing to community-hosted
<gchristensen>
agreed
<shlevy>
Sonarpulse: What's the "right" way to add a dependency to stdenv everywhere?
<shlevy>
Sonarpulse: It's not even really Linux specific...
<sonarpulse>
even nixers are giving up on it happening
<shlevy>
I don't think intensional store is the big deal
<shlevy>
Recursive nix is
<gchristensen>
I'm not sure I'd read so far in to it, shlevy
<gchristensen>
Sonarpulse:
<shlevy>
gchristensen: I'm not reading into the bazel thing :P recursive nix is a big deal anyway
<sonarpulse>
shlevy: some other time let me tell you my derivation-continuation refinement of IFD
<shlevy>
I think I've heard it... Or something similar :) I think ultimately there's no reason recusive nix *can't* work and if wehad it such things would be completely unapppealing
<shlevy>
But I'll wait to hear your specific idea :)
<shlevy>
(no one is more zealous than a convert, years ago I chatted for hours with niksnut trying to convince him proper IFD support was all we really needed and came away wanting to implement recursive nix)
<MichaelRaskin>
Intentional store won't actually help Nix anyway
<MichaelRaskin>
Because of the paths of dependencies
sonarpulse has quit [Ping timeout: 240 seconds]
<clever>
i could see store hash rewriting just totally destroying an ext4 image
<MichaelRaskin>
Store hash rewriting can actually be supported, at least on Linux
<clever>
but if you try rewriting the paths, inside a disk image, and the fs hash metadata checksums
<MichaelRaskin>
In the build time, you bind-mount all the dependencies to $out/deps
<MichaelRaskin>
Well, for images the way I mean just won't do anything
<MichaelRaskin>
Then you link against $out/deps/libsomething/lib/libsomething.so
<MichaelRaskin>
When after installation you replace deps with symlinks
<MichaelRaskin>
Then if you need to do dependency rewriting you copy the path and change the symlinks
<clever>
ah, that could maybe work
<clever>
i could also see $out/deps/lib saving a lot of time with rpath length/startup time
<MichaelRaskin>
The problem is that it requires either root or user mount namespaces
<clever>
for example, with 20 paths in rpath, and 20 libraries, it can wind up searching up to 200 paths in total
<MichaelRaskin>
Cygwin? Darwin? User installation on RHEL?
<clever>
and ive gotten so used to that strace spamage, that it just looked broken when i copied libs to $out/lib and strace'd the binary
<MichaelRaskin>
Hehe
<clever>
also, ive seen windows builds failing a lot because PATH was too long
<MichaelRaskin>
I mean, if you don't care about rewriting, you can just pust symlinks to everything into $out/deps
<MichaelRaskin>
Which would help with a lot of small things already.
<MichaelRaskin>
But a build process could try to resolve the links
<shlevy>
MichaelRaskin: resources can ideally be in separate outputs... when they can't be, we can have libfindme as a cross-platform way for binaries to find themselves :P
<MichaelRaskin>
shlevy: at that point I should mention Go and immediately move towards cover
<Mic92>
shlevy: aszlig this is no longer necessary
<MichaelRaskin>
I had enough fun updating LibreOffice as it is, _and_ I don't like one test that I had to disable.
<shlevy>
This is a long-term vision. I think it's fair for something like Nix to eventually have some lessons to teach upstreams :)
<shlevy>
(and definitely shouldn't carry the patches locally!)
<MichaelRaskin>
Unfortunately, I have seen quite otherwise smart up/side-streams not get it w.r.t. Nix
<shlevy>
Of course
<shlevy>
But if you frame it as "relocatable builds"... :)
<MichaelRaskin>
Another story is that there are many smart people writing good software who are completely idealistic and manage to not notice it.
<aszlig>
shlevy: not really, as far as i can see
<MichaelRaskin>
«Why in the world would you want relocatable builds»
<MichaelRaskin>
I have seen quite different people say that there is a limit to how much garbage a piece of software can be to be allowed to even be installed.
<Mic92>
go 25
<aszlig>
shlevy, Mic92: but in a way, it is... at least it would work for us if we patch out the prefix to sysconfdir and set factoryconfdir to /etc/systemd
<MichaelRaskin>
I think what would really help is caching and build splitting.
<gchristensen>
I'm actually a bit impressed that nobody has merged their own PR yet :)
<dtz>
? on what repo? happens often enough on nixpkgs O:)
<Profpatsch>
gchristensen: The difference here is that I manually checked all Github handles.
<Profpatsch>
:)
<Profpatsch>
or semi-automaticall.
<Profpatsch>
*y
<MichaelRaskin>
dtz: it is limited to the topic of structured meta.maintainers
<dtz>
:D oh okay
<Profpatsch>
Yeah, wouldn’t want to break the infrastructure.
<MichaelRaskin>
I did self-merge LibreOffice update just a few days ago if we are talking of entire Nixpkgs.
<Profpatsch>
From what I could gather, it should only lead to no mails being sent from hydra.
goibhniu has joined #nixos-dev
goibhniu1 has quit [Ping timeout: 240 seconds]
pxc has joined #nixos-dev
<ekleog>
is mention-bot dead? I just opened https://github.com/NixOS/nixpkgs/pull/36265 and he didn't tag anyone, and I can't find who merged @bachp's last PRs, apart from the first “riot-web: init at 0.12.2 (#28585)” that was merged by Mic92 ~a year ago :/
davidlt_ has joined #nixos-dev
<ekleog>
oh, I've just been told it dates back to ~the end of travis… well, RIP
davidlt has quit [Ping timeout: 245 seconds]
<sphalerite>
Anyone know what might be causing SIGSYS on processes started by builders? Pretty innocuous stuff like sh, and it receives SIGSYS when calling brk(NULL) right after the exec. This is on a pretty normal x86_64 nixos system.
<sphalerite>
it seems to be seccomp-related, as it doesn't happen with --no-filter-syscalls
<Dezgeg>
32-bit binary? x32 binary?
<sphalerite>
nope, all 64-bit. Or it should be at least
<sphalerite>
ok no somehow 32-bit stuff got into the mix
<sphalerite>
that would explain it
<Dezgeg>
32-bit calls should still be permitted though?
<sphalerite>
I think it was a 32-bit nix trying to build 64-bit stuff
<sphalerite>
somehow
<clever>
nix defaults to the same arch as itself
<Dezgeg>
that should still work though
<clever>
Dezgeg: but wait!
<sphalerite>
Dezgeg: not with the seccomp filtering bit
<clever>
the /bin/sh is a 64bit binary, from nix.conf
<sphalerite>
surely?
<clever>
and if nix sets the sandbox up to be 32bit only...
<clever>
and seccomp tries to enforce that fully?
<Dezgeg>
well if you write the seccomp sandbox correctly
<Dezgeg>
i.e. not conditionalize seccomp_arch_add(ctx, SCMP_ARCH_X86) etc.
Lisanna has joined #nixos-dev
davidlt_ has quit [Remote host closed the connection]
davidlt_ has joined #nixos-dev
davidlt_ has quit [Ping timeout: 240 seconds]
jtojnar has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
<dtz>
hmm I was having segfault in newly spawned builders re:seccomp and malloc. But in my case it seems to disappear if I disable using vfork() which seemed like a good idea anyway[1]. Trying to check if anything 32bit was being invoked , that'd be interesting...
<Dezgeg>
is it calling malloc() after vfork or something?
<dtz>
sphalerite: oh, actually. Do you have sandbox *disabled*? O:)
<dtz>
I don't have a great story about the problem, unfortunately. Just tried disabling vfork usage to make things easier to reason about--esp since we're already doing that fork+clone dance before using seccomp
<Dezgeg>
do you have a coredump or backtrace?
<dtz>
in general AFAICT our vfork() usage looks ..questionable? Since I don't think you should malloc() or anything else really, and we use it to implement runProgram in which we do a small bit of things to memory before calling exec/execvp. also dup2.
<Dezgeg>
pure system calls are probably ok
<dtz>
I do but ... it was happening on musl-built nix O:) haha
JosW has quit [Ping timeout: 268 seconds]
pxc has quit [Quit: WeeChat 2.0]
<Dezgeg>
but yeah, I'd except push_back() et al to be a very bad idea
yegortim1 has quit [Remote host closed the connection]
yegortim1 has joined #nixos-dev
<dtz>
i think those could be pushed out of the call to startProcess(), and the others handled with posix_spawn_file_actions_adddup2 if we used posix_spawn/posix_spawnp instead. Anyway more debugging needed O:)