taktoa has joined #nixos-dev
<dtz> (WIP posted, still early but by all means any and all interested parties please come on by)
<shlevy> Anyone ever build gdb suitable for cross-compilation?
<shlevy> That is, cross-debugging
<shlevy> Ah, it looks like we enable all targets, nice@
<shlevy> Maybe that's something else :)
<shlevy> Trying buildPackages.gdb...
<dtz> yeah, think you want buildPackages.gdb :)
<dtz> iirc that's in the release jobset or something
<dtz> yeah, release-cross.nix has buildPackages.gdb :)
mbrgm has quit [Ping timeout: 256 seconds]
mbrgm has joined #nixos-dev
<shlevy> Yep, that was it :)
<dtz> oh? \o/
<dtz> never tried it teehee
pie__ has joined #nixos-dev
pie_ has quit [Ping timeout: 264 seconds]
pie__ is now known as pie_
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie_ has quit [Read error: Connection reset by peer]
pie__ has joined #nixos-dev
pie__ has quit [Ping timeout: 248 seconds]
pie_ has joined #nixos-dev
pie_ has quit [Ping timeout: 276 seconds]
pie_ has joined #nixos-dev
Lisanna has joined #nixos-dev
pie_ has quit [Quit: Leaving]
orivej has joined #nixos-dev
ma27 has joined #nixos-dev
ma27 has quit [Client Quit]
ma27 has joined #nixos-dev
ma27 has quit [Ping timeout: 276 seconds]
FRidh has quit [Remote host closed the connection]
__Sander__ has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
ma27 has joined #nixos-dev
<domenkozar> dtz: sorry :)
<domenkozar> I must have missed that - you're asking for commit access?
<dtz> Yessir.
<domenkozar> invited :)
<dtz> YAY, ty!
<florianjacob> fpletz: ping for prosody 0.10: https://github.com/NixOS/nixpkgs/pull/32960 (freshly rebased! 😉)
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
<Profpatsch> dtz: musl support might be great!
<Profpatsch> How do you plan on handling packages that need different patches applied to work with musl (the GHC compiler comes to mind).
<Profpatsch> Especially for things like GHC, where there are already a few dozen or so settings that produce uncanny amount of code paths.
<Profpatsch> Don’t want to see those get even more complex by interspersing additional musl logic.
<dtz> Eep. Well honestly I know very little about GHC on musl-- I thought musl was a supported platform there in fact :)
<Profpatsch> afaik it’s not, but some people have reported it to work with a bit of patching here and there.
<dtz> Yeah idk what I was thinking, clearly not a conclusion I would have come to had I googled it before :D
<dtz> Best case would be convincing upstream to be musl compat so no patching is needed, maybe a config flag or so :P
<dtz> I'm a bit surprised, Haskell seems too high level and wrong in spirit to be excessively dependent on glibc-isms, wonder what the patches do.... :)
<Profpatsch> It probably just wasn’t a focus so far.
fadenb has quit [Ping timeout: 276 seconds]
<sphalerite_> niksnut: so I'm trying to get 32-bit ARM stuff building on a compatible aarch64 system. Since not all aarch64 systems support the armv7 instruction set and we need some way to tell nix which platforms the system does support, would it maybe make sense to upstream clever's patch which he wrote for binfmt-misc+qemu-user support?
<sphalerite_> clever: ^
fadenb has joined #nixos-dev
yegortimoshenko has quit [Ping timeout: 255 seconds]
yegortimoshenko has joined #nixos-dev
fadenb has quit [Ping timeout: 256 seconds]
<Profpatsch> fpletz: globin I was thinking that this runCommand should not try to substitute https://github.com/Profpatsch/yarn2nix/blob/master/nix-lib/default.nix#L41
<Profpatsch> Because we’re just creating a link farm and one per package, so that means an extra request to hydra per package.
<Profpatsch> For some projects that’s a few hundred packages.
<Profpatsch> But I’m not sure whether I should use preferLocalBuild lor allowSubstitutes.
<LnL> probably both in this case
<Profpatsch> I found https://github.com/NixOS/nix/issues/1378 but shlevy didn’t really explain which does what.
<Profpatsch> I guess preferLocalBuild is mostly used by Hydra?
<Profpatsch> And only allowSubstitutes forces local build?
<Profpatsch> And prevents substitute requests?
<LnL> dontSubstitute disables downloading from the cache
<LnL> with preferLocalBuild nix will try to build locally instead of using the build-hook when possible
<LnL> for distributed builds copying inputs -> building -> copying outputs is slower then just building locally for things like buildEnv
<Profpatsch> What build-hook?
<LnL> build-remote for distributed builds/hydra
<Profpatsch> Hasn’t that changed a bit with nix 2.0?
<Profpatsch> Ah, so the evaluator machine just builds them instead of moving them to a builder machine and copying the results.
<LnL> it's written in c++ now, but the principle is still the same
fadenb has joined #nixos-dev
<Profpatsch> Okay, then both it is.
<Profpatsch> allowSubstitutes isn’t even documented anywhere as far as I can see.
<LnL> doesn't look like it
Lisanna has quit [Quit: Lisanna]
<Profpatsch> LnL: Huh, then this description is conflating the two: https://github.com/NixOS/nixpkgs/blob/master/doc/stdenv.xml#L482
<Profpatsch> preferLocalBuild is only for builders, right?
<LnL> yeah, that's what the issue was about
<Profpatsch> Then prepare to be mentioned on a PR soon. :)
<LnL> great :)
pie_ has joined #nixos-dev
Lisanna has joined #nixos-dev
<aminechikhaoui> ikwildrpepper: do you remember what was the reason for setting boot.kernelParams = [ "console=ttyS0" "panic=1" "boot.panic_on_fail" ]; for GCE images ?
<aminechikhaoui> it was a bit confusing when having boot issues
<aminechikhaoui> I think the "console=ttyS0" should be enough like what the AWS images have
pie_ has quit [Ping timeout: 240 seconds]
<Profpatsch> grahamc or gchristensen I’m lost https://github.com/NixOS/nixpkgs/pull/35194#issuecomment-366949209, is ofborg down?
<Profpatsch> The build failures got weirder and weirder, first broken nix on master, then something else.
<gchristensen> well, is nix broken on master
<gchristensen> it seems more likely to me that Nixpkgs is broken than ofborg is broken, can you track that down?
<Profpatsch> I can try.
<gchristensen> ofborg does nothing special: it merges the PR in to the current master and runs nix-build ....
<Profpatsch> LnL: So, what are cases where you’d want to preferLocalBuild but not allowSubstitutes?
<Profpatsch> And what if you set preferLocalBuild on e.g. Chromium? Will that block the main hydra process?
<LnL> I'm not sure exactly how preferLocalBuild works with hydra
<Profpatsch> Many derivations set preferLocalBuild to true but not allowSubstitutes to false.
<aminechikhaoui> Profpatsch: I think preferLocalBuild is used for cases especially in Hydra where you'd like to run the build with machines having local system feature such as the frontend.
<Profpatsch> What’s a “local system feature”?
<aminechikhaoui> in /etc/nix/machines
<LnL> as for an example with substitutes, I guess something that's fast but has a bunch of build time dependencies you wouldn't want to download just to build it locally
<Profpatsch> Hm, that sounds fair.
<aminechikhaoui> e.g `localhost x86_64-linux,i686-linux - 10 1000 local local`
<Profpatsch> I didn’t think of build time dependencies.
<LnL> but they usually go together
<LnL> it's a bit of a weird example but the only thing I can think of
<Profpatsch> aminechikhaoui: I don’t understand, sorry.
pie_ has joined #nixos-dev
<aminechikhaoui> Profpatsch: so hydra reads the /etc/nix/machines to get which builders to use, if the derivation that is going to be built has preferLocalBuild it will build inside machines that have local as system feature which is typically localhost i.e the hydra frontend
<Profpatsch> Okay, tracing the code of hydra there’s only one check that is doen.
<aminechikhaoui> sorry if I'm still not clear :p
<Profpatsch> aminechikhaoui: I don’t have any experience with hydra setup.
<aminechikhaoui> well it's more of a nix setup
<aminechikhaoui> [amine@nixos:~]$ nix show-config | grep machines
<aminechikhaoui> builders = @/etc/nix/machines
<Profpatsch> for (auto & f : mandatoryFeatures)
<Profpatsch> if (!step->requiredSystemFeatures.count(f)
<Profpatsch> && !(f == "local" && step->preferLocalBuild))
<Profpatsch> return false;
<Profpatsch> This is the only code that uses this variable.
<Profpatsch> /* Check that the step requires all mandatory features of this
<Profpatsch> machine. (Thus, a machine with the mandatory "benchmark"
<Profpatsch> feature will *only* execute steps that require
<Profpatsch> "benchmark".) The "preferLocalBuild" bit of a step is
<Profpatsch> mapped to the "local" feature; thus machines that have
<Profpatsch> "local" as a mandatory feature will only do
<Profpatsch> preferLocalBuild steps. */
<Profpatsch> Ah, and this:
<Profpatsch> if (step->preferLocalBuild)
<Profpatsch> features.insert("local");
<Profpatsch> What I gather is that build steps have so-called “features” which are used to find machines that can build them.
<Profpatsch> And the front-end machine has probably a "local" constraint which ensures that only build steps tagged with `preferLocalBuild` are built on this machine.
<aminechikhaoui> right that's my understanding, although there are some more comments if you'd like to check: https://search.nix.gsc.io/?q=preferLocalBuild&i=nope&files=&repos=
<Profpatsch> Hm, so if I have a build-time dependency on e.g. pandoc, I should not set allowSubstitutes to false, otherwise each client will have to download pandoc (and GHC in the worst case)'
<Mic92> dtz: finally you asked for the maintainer bit :)
<dtz> :D
<dtz> I just made my very first merge seconds ago!!
<gchristensen> whoa, congratulations, dtz!
<dtz> .. it was my own PR. idk, I like going through the PR process even so :)
<gchristensen> especially with decent testing, I agree ... :)
orivej has joined #nixos-dev
jtojnar has quit [Ping timeout: 248 seconds]
<clever> sphalerite_: yeah, thats a great use for the patch
<clever> sphalerite_: another would be when 32bit compat is disabled in a linux-64 kernel
<sphalerite_> so to not enable i686-linux building on x86_64-linux by default either?
<sphalerite_> Yeah that would be good
<clever> sphalerite_: somebody in #nixos was running linuxPackages_hardened and couldnt figure out why the 32bit wine was just broken
<sphalerite_> yeah I was there :p
<clever> the tricky part, is setting nixos options when you change to such a kernel
<sphalerite_> although in that case it wouldn't have helped, would it? Since it's in the binary cache as well
<clever> yeah, it would have just downloaded the cached copy
<clever> but 32bit nix builds would have still failed in weird ways
<sphalerite_> I think it would be sensible to just disable 32-bit completely by default and leave it up to users who know they need 32-bit stuff to set the nix option?
<clever> wine and several other applications are 32bit only
<clever> often, its simpler to just patchelf the 32bit one and ignore 64bit entirely
<sphalerite_> clever: dtz: I'm trying to build armv7 stuff on a compatible aarch64 machine, but a bunch of stuff (so far, libelf and gcc) seems to detect the platform based on uname (this is just a guess, I'm not sure how exactly it detects it but that's my best guess). I could just fix it for those two but I suspect there's going to be a lot more later on, do we have a wider-reaching thing that would allow not having
<sphalerite_> to specify it manually in every single thing that misdetects it?
<clever> sphalerite_: nix has code to fix that, one min
<Dezgeg> the personality() one doesn't work on ARM
<clever> then the kernel will have to be patched first, lol
<Dezgeg> but yeah, we'd need a not-too-hacky way to return fake results from uname()
<sphalerite_> ptrace! :D
<sphalerite_> actually maybe even seccomp could do this?
<Dezgeg> no, it can't modify memory
<sphalerite_> well. I've clearly underestimated the amount of fuss that's going to be necessary for this
<clever> also, armv6 vs armv7 has had similar problems
<Dezgeg> yes
<clever> ive done v6 builds on a v7, and wound up with v7 opcodes
<clever> one min
<clever> thats a simple setup-hook you add to the buildInputs (potentially in stdenv), that will just check the elf flags to see what arch it targets
<clever> and fail the build if it doesnt match up
* sphalerite_ is reading the manpage for personality
<Dezgeg> well, the armv7-on-aarch64 is simple to fix with a kernel patch + the respective nix patch to set PER_LINUX32 on arm binaries
<Dezgeg> s/fix/hack around/
<sphalerite_> if only I could actually touch the kernel :p
<Dezgeg> ARMv6 one is trickier to hack around - maybe it wouldn't be too hard to hack the kernel to read the elf attributes and change the uname output based on that
<clever> Dezgeg: that sounds pretty hacky, lol
<sphalerite_> or we could just pass --host=${hostPlatform.config} to all the configure scripts?
<sphalerite_> why must they try to be smart :(
<Dezgeg> you have the problem of not all supporting that, plus those that will change their behaviour if you pass that
<sphalerite_> I can dream
<Dezgeg> e.g. if they now think you're cross-compiling and start to require all this ac_cv_foo=bar crap
<clever> and some may want a special cross-compiler, when the default one can target both arches
<Dezgeg> all arm compilers support -march=armvX
<Dezgeg> well, libgcc is another thing
<sphalerite_> cross is a pain even when you're not actually cross building D:
<shlevy> Anyone know if there's anyway to statically link to glibc and *not* retain references without explicitly using remove-references?
<shlevy> E.g. there seem to be some locale stuff referenced, in a main that just calls reboot(2) :o
<sphalerite_> you'd probably have to disable a bunch of the initialisation code I'm guessing
<sphalerite_> I don't know what can actually be disabled though.
<sphalerite_> clever: Dezgeg: setting ac_hostalias = hostPlatform.config; so it becomes an env var in the derivation seems to have done the trick
<sphalerite_> It's not beautiful and super generic, but it seems like a fair enough quick fix which should cover most autotools stuff
<sphalerite_> what do you think?
<Dezgeg> I have a very big fear of touching the autotools monster
<Dezgeg> maybe this could be implemented in a somewhat sane way: https://github.com/NixOS/nixpkgs/pull/25240#issuecomment-297491612
<Dezgeg> unless it actually causes every single system call to go through ptrace
<sphalerite_> I've just asked in #autotools if what I found is a terrible idea :p
<Dezgeg> heh, someone is proposing to add SECCOMP_RET_USER_NOTIF to the kernel
<Dezgeg> someone else clearly wants to do the same thing as well
<domenkozar> anyone seen this one: https://github.com/NixOS/nix/issues/1885
<domenkozar> niksnut: I premuse binary-cache-v3.sqlite has all info from narfile so it doesn't have to request narfile?
<clever> domenkozar: commented on the issue with the record that was corrupt
<domenkozar> possible fix would be for nix to repopulate narinfo
<clever> domenkozar: i believe the timestamp record will cause this data to expire after a while
<clever> then it will re-query the binary cache
<domenkozar> that's 52 days old
<clever> oh, lol
<LnL> I don't have problems with that anymore since I wrote something that correctly removes both the nar and narinfo
<domenkozar> removes?
<clever> i suspect hydra may have re-added it after it expired?
<LnL> yeah, nix freaks out if there's a narinfo but the corresponding nar file it points to was removed
<clever> i think both got removed
<clever> then both got re-added
<LnL> wait hydra has builtin support for expiring a cache?
<domenkozar> no, we run GC
<domenkozar> and narinfo is generated on the fly for hydra
<clever> the narinfo files dont exist, hydra generates the content on the fly as you attempt to read the url
<domenkozar> so hydra builds a new package with a nar
<domenkozar> due to binary non-determinism it has a different hash
<domenkozar> while binary-cache3.sqlite has the old narinfo data
<domenkozar> boom
<domenkozar> lesson learned: don't GC your binary cache
<sphalerite_> Dezgeg: clever: trying to build hello with stdenv having host_alias, build_alias and target_alias set now
<sphalerite_> this is probably going to blow up in my face but hey, it's worth a (long) shot, right?
<Profpatsch> LnL: Okay, now I’m confused
<Profpatsch> Directly above this chapter, preferLocalBuild is described.
<Profpatsch> First, the derivation will always be built, not substituted, even if a substitute is available. Second, if distributed building is enabled, then, if possible, the derivaton will be built locally instead of forwarded to a remote machine. This is appropriate for trivial builders where the cost of doing a download or remote build would exceed the cost of building locally.
<Profpatsch> So nix doesn’t substitute?
<sphalerite_> also according to some peripheral reading I did while making that change, Sonarpulse plans to change it so configure is *always* given --host and --build. If I understand correctly. Which would require corresponding changes to any non-autotools scripts as well
<Profpatsch> Hrmph
<sphalerite_> s/scripts/builds/
<Dezgeg> yeah I don't like that idea
<LnL> domenkozar: oh, are you using the hydra native cache?
<Dezgeg> the ac_* might even work
<clever> LnL: yeah
<Dezgeg> sphalerite_: do you have a branch? I might wanna try it
<LnL> clever: ah! I use a file:// store uri
<sphalerite_> Dezgeg: git fetch https://github.com/lheckemann/nixpkgs arm-hax
<clever> LnL: how would that work with a remote machine?
<Dezgeg> huh, autoconf takes them from those names? with no ac_ prefix?
<LnL> hmm?
<Dezgeg> nice consistency...
<sphalerite_> Dezgeg: that was just me getting transcribing it wrong from reading the configure script to storing it in my brain memory to writing it on IRC
<sphalerite_> it never was ac_hostalias
<clever> LnL: how would something like a travis job download things from the hydra using a file:// ?
<Dezgeg> yeah I see it's actually documented in the manual
<sphalerite_> oh sweet
<LnL> clever: I serve that it with nginx
<clever> LnL: ah, a second non-gc'd static file binary cache?
<LnL> that way requests don't go through hydra and I can put it on a separate volume
<LnL> exaclty
<clever> that will cost more disk space in the long run, but the lack of gc does entirely solve the problem
<LnL> and I wrote a small script that goes over old narinfo files and removes the narinfo/nar pair
<LnL> since that I've not really had any trouble with it anymore
<niksnut> domenkozar: strange, cache entries are supposed to be deleted after 30 days
<sphalerite_> Dezgeg: *** Configuration armv7l-unknown-linux-gnu not supported
<sphalerite_> :(
<domenkozar> niksnut: deleted on what action?
<Dezgeg> which one says that?
<sphalerite_> make[2]: *** [Makefile:4181: configure-stage1-gcc] Error 1
<sphalerite_> it works fine for aarch64 AFAICT but not for that
<sphalerite_> maybe it would prefer arm-unknown-linux-gnu or something?
<clever> (after nuking the db): Error: no such table: LastPurge
<niksnut> domenkozar: on startup
<Dezgeg> ah right, I think there might have been something weird in armv7
<niksnut> nix startup that is
<clever> niksnut: uptime, 82 days
<clever> root 3307 0.0 0.0 52996 2484 ? Ss 2017 0:16 nix-daemon --daemon
<domenkozar> we're running nix daemon
<Profpatsch> niksnut: Since you are here, will preferLocalBuild always prevent a substitution HTTP request?
<clever> its possible that the daemon has just never restarted since then
<niksnut> domenkozar: well, strictly speaking when the NAR info cache is first opened, which is probably done in each daemon child process
<Profpatsch> And is allowSubstitutes also a nix option and just not documented in the manual?
<clever> niksnut: which db is LastPurge in?, i cant find it on either one
<sphalerite_> Dezgeg: looking at the part that emits that error, gcc/config.gcc in gcc sources, I think it wants gnueabi instead of just gnu
<clever> it looks like its in binary-cache-v3.sqlite
<niksnut> Profpatsch: I don't think preferLocalBuild prevents substitution
<niksnut> create table if not exists LastPurge ...
<Profpatsch> Right? that was my impression from skimming the nix 1.11 and hydra sources
<clever> niksnut: yeah, i see that
<niksnut> in binary-cache-v5.sqlite
<niksnut> note: not -v3.sqlite
<clever> ah
* clever changes branches
<sphalerite_> Dezgeg: which makes sense, I think, at least i don't think we have any OABI stuff in nixpkgs :p
<clever> 404, no more nar-info-disk-cache.cc
<clever> ahh, now its managed in perl
<Dezgeg> I wonder where it is picking -gnu then? it's configured to tell "arm-unknown-linux-gnueabihf"
<sphalerite_> Dezgeg: that's what I'm trying to find out just now
<clever> if i'm reading it right, it can only expire negatives, and not positives? : https://github.com/NixOS/nix/blob/1.11.15/scripts/download-from-binary-cache.pl.in
<clever> and it never actually deletes, it just ignores upon read, if its old
<domenkozar> that would explain it, it's only in Nix 2.0
<clever> and while we are on the topic, a few years ago, my binary-cache-v3.sqlite got corrupted by an improper shutdown, because nix turned off sync'ing in sqlite
<clever> but it doesnt auto-delete the db upon corruption
<clever> so nix was just broken until i tracked the cause down
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
<sphalerite_> but it's really not pretty
<dtz> contributors?! IS IT ALMOST RELEASE TIME?!
<dtz> xD
<Dezgeg> /o\
<sphalerite_> on the bright side, integrating some changes vaguely along these lines but less nasty might fix the difficulties with armv6 vs armv7 as well
<sphalerite_> nvm it didn't do anything at all :p
<sphalerite_> oh I'm stupid. cpu == "armv7l", not "armv7l-linux"...
<gchristensen> niksnut: do you mind if we produce the Packet.net images on Hydra, or would you prefer if those were built outside of Hydra?
<gchristensen> this could be a separate project or jobset, not sure they need to be built per evaluation
<niksnut> how big are the images?
<Dezgeg> around the size of an ec2 one, I'd think
contrapumpkin has joined #nixos-dev
contrapumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<fpletz> Profpatsch: re yarn2nix, yeah, that would probably make sense - but the links farm itself is one of the problems we identified. node always has to run with --preserve-symlinks or some modules will break (i.e. babel)
<shlevy> :o how did I miss diverted stores in 2.0!
jtojnar has joined #nixos-dev
<dtz> :D
<dtz> our fearless leader has been busy brewing up some awesome
__Sander__ has quit [Quit: Konversation terminated!]
orivej_ has quit [Ping timeout: 248 seconds]
ma27 has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
FRidh has joined #nixos-dev
<sphalerite_> dtz: sorry to bother you about this again — it seems I was wrong about it working on current nix master… do you have any idea how I can align the stars to make attr build with nixUnstable? Or do I need to try and backport my arm patches to 1.11.x?
<dtz> latest nix built against latest nixpkgs ('nixpkgs' argument) would do--also, latest nixpkgs' nixUnstable should work as well
<dtz> only really need to build nix against latest nixpkgs to get the sandbox shell bits, if you'd like you can add those yourself: https://github.com/NixOS/nix/pull/1842
<gchristensen> Profpatsch: did you end up sorting out what was happening with ofborg?
<gchristensen> there is a cool 0800 (EST) and 1600 (EST), spike pattern emerging in nixpkgs
<gchristensen> s/nixpkgs/evals/
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
jtojnar_ is now known as jtojnar
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 276 seconds]
jtojnar_ is now known as jtojnar
pie_ has quit [Ping timeout: 256 seconds]
taktoa has quit [Remote host closed the connection]
Lisanna has quit [Ping timeout: 255 seconds]
Lisanna has joined #nixos-dev
<shlevy> Dezgeg: Thank you for all of the awesome Nix fixups you've been doing
<shlevy> !
<shlevy> Anyone know of a good C++ unit testing framework?
mbrgm has quit [Quit: ZNC 1.6.5 - http://znc.in]
mbrgm_ has joined #nixos-dev
mbrgm_ is now known as mbrgm
FRidh has quit [Quit: Konversation terminated!]
MichaelRaskin has joined #nixos-dev