<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?
<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
<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.
<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.
<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
<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
<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
<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
<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
<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?