gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.03 release managers: fpletz and vcunat
<shlevy> sphalerite: Ended up using this to get a drv to go with nix copy https://gist.github.com/shlevy/63509f743125588ca04146c5555d5b4d
<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> Proper? It doesn't
<hl> I'd be against discourse. It doesn't work at all without JS and doesn't have real threading
lopsided98 has joined #nixos-dev
<hl> honestly, google groups is pretty horrible too, I'd just go with mailman2
<sonarpulse> angerman: I saw you post
<sonarpulse> ooo but i think i only saw that on phone
<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> [clever@system76:~/iohk/nix-hs-hello-windows]$ nix-build hs-hello.nix
<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
<sonarpulse> extra.. or default... shlevy ?
<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...
<clever> shlevy: i'm guessing propagatedBuildInputs
<sonarpulse> shlevy: shlevy defaultNativeBuildInputs
<sonarpulse> see stdenv/generic/default.nix
<clever> although, i'm not sure if the stdenv is an input and handles nix-support right
<shlevy> OK
<zimbatm> maybe one day we'll have an infrastructure team that nurtures hydra and friends
<sonarpulse> (stdenv is an input, but i really wish it wasn't a derivation)
<zimbatm> that's why going for the hosted discourses seemed like a good idea
<shlevy> Sonarpulse: I think it's only a derivation so you can do nix-instantiate -A stdenv to see if you broke anything :P
<sonarpulse> shlevy: yeah basically
<sonarpulse> shlevy: and nixos tests do that
<sonarpulse> to get everything needed on machine
<shlevy> Hmm gnu-config should probably just be a fixed-output drv
<sonarpulse> shlevy: yes then it would work everywhere
<sonarpulse> *earlier stage
<shlevy> Eh, it works everywhere now
<sonarpulse> shlevy: 1 step closer to no stdenv cross adapter wooooo!!!!!
<shlevy> Except the dummy stdenv
<sonarpulse> well, haha
<shlevy> I needed a null in the top level set :P
<sonarpulse> gotcha
<shlevy> But yeah, it works
<sonarpulse> nice!
<shlevy> Just rebuilding every stage :D
<sonarpulse> lolz
<dtz> oh? \o/
<sonarpulse> well, ping me for that staging land
<shlevy> Yep, will do
<shlevy> Hoping itwill be part of an astoundingly small native riscv PR ;)
<shlevy> But if not I'll break it out
<sonarpulse> :D
<sonarpulse> heading home; good luck!
<sonarpulse> last thought; https://www.tweag.io/posts/2018-02-28-bazel-haskell.html means we really need intentional store
<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> One thing I'd like to push for is removing as many self-references as possible
<aszlig> niksnut: ^
<shlevy> Make all rpaths @origin etc.
<shlevy> Without self-references we don't need any fanciness to do content-addressing
<shlevy> fpletz: Mic92: ^^
<shlevy> (aszlig's link)
<MichaelRaskin> shlevy: let me introduce you to the wonderful world of compile-time hardwired resource loading paths
<shlevy> MichaelRaskin: I know about them :P
<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 guess mere static compilation is fine, but Go implements its own syscall wrappers.
<Mic92> oh wrong link
<shlevy> MichaelRaskin: Oh, we'd have to actually patch code
<Mic92> no was the right one
<MichaelRaskin> shlevy: patching everything scales badly
<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.
<aszlig> hm, forget that, factoryconfdir doesn't apply prefix
<aszlig> Mic92: so why isn't this in nixpkgs yet?
pie_ has quit [Ping timeout: 240 seconds]
lopsided98 has joined #nixos-dev
ma27 has quit [Ping timeout: 252 seconds]
<Mic92> aszlig: I had to wait until it was merged into systemd fork
<Mic92> that was today
<Mic92> Now it could be added to nixpkgs as well
Lisanna has joined #nixos-dev
Lisanna has quit [Quit: Lisanna]
Lisanna has joined #nixos-dev
pxc has quit [Ping timeout: 256 seconds]
mbrgm has quit [Ping timeout: 265 seconds]
mbrgm has joined #nixos-dev
<Profpatsch> We’ve got a complete list of maintainer github handles!
<Profpatsch> Was quite a bit of work, but mostly everything should be correct now.
yegortim1 has quit [Ping timeout: 255 seconds]
yegortim1 has joined #nixos-dev
yegortim1 has quit [Remote host closed the connection]
yegortim1 has joined #nixos-dev
adisbladis has quit [Ping timeout: 240 seconds]
<angerman> clever: you need the nixpkgs submodule checkout.
jtojnar has quit [Ping timeout: 240 seconds]
<simpson> I don't think it's morning yet over there. I can start the crying though.
<simpson> }"}"
<shlevy> :D yep
<shlevy> extrec."{" takes a second argument just to ignore it
<shlevy> Maybe I'll make it throw ifit's not a "}"
<sphalerite> it is morning over here, only just
<sphalerite> 8:41 in NL
<sphalerite> lol nice
<shlevy> Hmm when you fix an extrec should inner extrecs be fixed then?
<shlevy> I'm going to say no, you can always write something that does that.
<shlevy> Ah, never mind, you need it to fix everything at once so nested extrecs can refer to each other
<shlevy> gchristensen: Does ofborg run the nixpkgs lib tests?
ma27 has joined #nixos-dev
ma27 has quit [Ping timeout: 256 seconds]
ma27 has joined #nixos-dev
ma27 has quit [Ping timeout: 252 seconds]
ma27 has joined #nixos-dev
FRidh2 has joined #nixos-dev
goibhniu1 has joined #nixos-dev
simpson1 has joined #nixos-dev
goibhniu has quit [Ping timeout: 256 seconds]
simpson has quit [Ping timeout: 256 seconds]
<genesis> still on mame 0.195 derivation, i've a common issue with mame, it searsh for it cfg file in the exec path
<genesis> some distribution as arch provide a wrapper script ( https://aur.archlinux.org/cgit/aur.git/plain/sdlmame.sh?h=sdlmame-wout-toolkits )
mbrgm has quit [Ping timeout: 256 seconds]
mbrgm has joined #nixos-dev
<genesis> is the nix philosophy to have such integration wrapper ?
<genesis> (it's very tricky to make mame works without such things)
<sphalerite> yes nix uses lots of wrappers, much more than other distros, jsut because of how the filesystem is organised
ma27 has quit [Quit: WeeChat 2.0]
<genesis> yes, i understand that, but i'm a bit confused when i should rewrite some path
<genesis> sometime i feel it would be better to refer to a ~/.nix-profile/ instead of a $out one ...
ma27 has joined #nixos-dev
<genesis> oki i will commit a wrapper script with proper substitution in the deriv.
ma27 has quit [Client Quit]
pie_ has joined #nixos-dev
Lisanna has quit [Quit: Lisanna]
romildo has joined #nixos-dev
romildo has quit [Quit: Leaving]
pie__ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
<gchristensen> shlevy: nope
<gchristensen> shlevy: can they be tested with nix-instantiate, or do they build?
<shlevy> nix-instantiate --eval --strict lib/tests/misc.nix
<shlevy> should == []
<gchristensen> cool
<gchristensen> want to send a PR? it'll be easy
<shlevy> Sure, will take a look in a bit
<shlevy> Only have two more pieces of the extensible attr sets proposal to implement ;)
pie___ has joined #nixos-dev
pie__ has quit [Ping timeout: 268 seconds]
yegortim1 has quit [Write error: Broken pipe]
obadz has joined #nixos-dev
<obadz> hi team! any forecasts on the timing of the 18.03 fork?
ottidmes has joined #nixos-dev
<ekleog> BTW, if someone can get a look at https://github.com/NixOS/nixpkgs/pull/36249 before 18.03, it would avoid me to have to keep a module override until september :°
yegortim1 has joined #nixos-dev
<shlevy> extrecs is now feature-complete ;) https://github.com/shlevy/nixpkgs/tree/extensible-records
<obadz> ekleog: maybe tag people who have touched this module on your PR
<Mic92> how can merge nixos-artwork? https://github.com/NixOS/nixos-artwork/pull/26
<manveru> dbus is a pain as usual... :|
<ekleog> obadz: should have thought about it, thanks! :)
<Mic92> manveru: busctl is quite nice
<manveru> Mic92: i'm trying to talk to dbus in a user daemon
<Mic92> in a script I assume
<Mic92> busctl also supports that
<manveru> the problem is that it can't find the spotify service when i run it in polybar... but it was working just an hour ago :P
<manveru> and i have no clue what's going on
<manveru> oh, now it works again
<manveru> just restarted X
<manveru> oh damn, wrong channel
simpson1 is now known as simpson
FRidh2 has quit [Quit: Konversation terminated!]
<gchristensen> oops, telnet has a dependency upon gcc
JosW has joined #nixos-dev
<MichaelRaskin> For thread magic?
<gchristensen> I was just assuming by mistake
<LnL> what happened to the idea of using disallowedRequisites for stuff like gcc in the stdenv?
<clever> LnL: i think it doesnt support split outputs
<LnL> see xz
<clever> it may have improved since i last saw it
<shlevy> niksnut: Do you know why input propagation is handled with $out/nix-support instead of just being extracted in nix?
<niksnut> "extracted in nix"? what does that mean?
<MichaelRaskin> shlevy: because Xorg
<MichaelRaskin> (as an example)
<shlevy> MichaelRaskin: Can you say more?
<MichaelRaskin> There are packages where setting the list of propagated build inputs actually requires to look inside the tarball
<shlevy> Ahh
<shlevy> OK
<MichaelRaskin> Back when I had a composable builder that did everything in Nix, X libraries were annoying
<MichaelRaskin> (because I couldn't extract this information via Nix)
<shlevy> niksnut: for a plain lambda (i.e. no {}:), there's no way to access the pos of the call site right?
<Profpatsch> FRidh: We found a way to be backward-compatible with hydra https://github.com/NixOS/nixpkgs/pull/36119#issuecomment-370175598
<Profpatsch> niksnut: Can you take a quick look at https://github.com/NixOS/nixpkgs/pull/36119#issuecomment-370175598 so we don’t break Hydra?
<Profpatsch> It *should* work, but of course we don’t know all the moving parts.
<Profpatsch> Ideally, hydra would be able to parse the complex meta fields sometime in the future, but for now it should work well enough.
<Profpatsch> I added a note that `shortName` will probably be removed in the future, just in case.
<gchristensen> this is now the third or fourth PR to do this
<gchristensen> Profpatsch: as I've noted on two or three of them, eelco says to just do it and he'll fix hydra when it is done
obadz has quit [Quit: WeeChat 2.0]
<MichaelRaskin> Well, shortName support might be the outcome of one of the attempts
<gchristensen> just delete that and hydra can deal with it
<gchristensen> the preference was for no evaluation to have to take place to get the maintainer's attrset
obadz has joined #nixos-dev
<Profpatsch> gchristensen: So you mean we should just break it for now?
<gchristensen> yes
<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:)
<Dezgeg> yes
pxc has joined #nixos-dev