<jtojnar>
I am mostly concerned that every package's updatescript is a separate derivation
<jtojnar>
(separate writeScript)
<jtojnar>
but I guess it cannot be avoided when using maintainers/scripts/update.nix
<gchristensen>
yeah
<gchristensen>
and it isn't in the "hot path" for usage
<gchristensen>
just when updating
<gchristensen>
in which case N more drvs isn't going to be such a big deal
<jtojnar>
also I do not like having to pass the attribute path
<jtojnar>
it is needed by update-source-version
mbrgm has quit [Ping timeout: 252 seconds]
mbrgm has joined #nixos-dev
<jtojnar>
and also I do not see how to make maintainers/scripts/update.nix pass some arguments (stability configuration)
<jtojnar>
but I guess I will just change it in the file, when updating an unstable branch
<jtojnar>
I will just merge it and if someone does not like it, they can open a PR
disasm has quit [Quit: WeeChat 1.9.1]
disasm has joined #nixos-dev
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
aminechikhaoui has quit [Ping timeout: 248 seconds]
aminechikhaoui has joined #nixos-dev
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 252 seconds]
jtojnar_ is now known as jtojnar
jtojnar has quit [Ping timeout: 268 seconds]
pie_ has quit [Ping timeout: 240 seconds]
aminechikhaoui has quit [Ping timeout: 256 seconds]
aminechikhaoui has joined #nixos-dev
tv has quit [Ping timeout: 240 seconds]
tv has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
MichaelRaskin has quit [Quit: MichaelRaskin]
vcunat has joined #nixos-dev
vcunat has quit [Client Quit]
goibhniu1 is now known as goibhniu
<shlevy>
fpletz: vcunat: I have cross-compiled NixOS working in a branch on top of staging. I have no particular need to have it in 18.03 vs not, but would you be interested in including it if I could get the PR to staging up today?
<shlevy>
Right, but that's a workaround, not a solution
<Dezgeg>
no
<Dezgeg>
this needs to be fixed in nix
<shlevy>
Right. Not by enhancing the shell though, by letting builders determine what sets /bin/sh or not having /bin/sh at all during builds
<Dezgeg>
per-drv /bin/sh would be ideal, yes
<shlevy>
I think I'll make an RFC for that
<shlevy>
(once the core team is resolved either way)
pie_ has quit [Ping timeout: 268 seconds]
pie_ has joined #nixos-dev
<gchristensen>
what are the next steps on getting the core team RFC merged? should probably : 1. establish a mailing list, 2. possibly establishing an IRC channel (may I propose #nix-core-team?) 3. getting +1's from everyone _on_ the team
__Sander__ has joined #nixos-dev
<shlevy>
gchristensen: I don't think we should have a mailing list or IRC until the RFC is approved/merged...
<gchristensen>
s/merged\?.*$//
ma27 has joined #nixos-dev
<shlevy>
Sure :)
<shlevy>
Not sure why we'd approve and not merge though
<gchristensen>
ok now you're just being difficult :P
<gchristensen>
how do we finish this
<shlevy>
Oh, sorry, I thought you were substituting in mine :D
<shlevy>
Gotcha
<gchristensen>
XD
<shlevy>
Maybe just make a comment: +1 response for "yes", -1 for "no", unsure face for "still have questions before I can decide". The latter two should require explanation/chance for followup
<shlevy>
And then if we reach a clear overwhelming +1 and all of the questions are answered we can go ahead. Unsure how much lead time to give...
<fpletz>
shlevy: sounds good to me :)
<fpletz>
shouldn't break any other platforms, right?
<shlevy>
Right
<shlevy>
OK, I merged in latest staging last night and my rebuild is almost finished
<fpletz>
Mic92: will take care of that systemd PR now, sorry for the delay
<shlevy>
Assuming it boots I'll post the PR
<fpletz>
not sure when exactly vcunat wants to branch off though, he's not on irc much and writing emails is so old-school %)
<LnL>
he's here sometimes :)
<gchristensen>
he's made a commitment to be here more for the release duties
<gchristensen>
and has done a pretty good job of thath
<shlevy>
A blog post I found for cross-compiling gobject-introspection mentions using Wine to run host-native python :D
pie_ has quit [Ping timeout: 245 seconds]
<sphalerite>
quality corss
<sphalerite>
cross
adisbladis has quit [Ping timeout: 240 seconds]
<dtz>
Can we have a PR/issue backlog sprint/party? There are a lot of good PRs going back months...
<gchristensen>
we definitely should!
<dtz>
OMG ryantm hahah
<gchristensen>
what happened?
<dtz>
Oh, just the ongoing flood of PRs, nothing new
<gchristensen>
haha yeah
ma27 has quit [Quit: WeeChat 2.0]
goibhniu has quit [Ping timeout: 245 seconds]
ma27 has joined #nixos-dev
goibhniu has joined #nixos-dev
pie_ has joined #nixos-dev
<Mic92>
dtz: maybe start with the older ones. sometimes they already good progress and wonder why nobody review them.
<srhb>
gchristensen: We have something like that, except the actual built system is what is requested, not a configuration.nix to be built.
<fpletz>
gchristensen: sure thing, no blame there :) we have a talent to miss each other though
<srhb>
Could probably generalize that faaaairly easily.
<gchristensen>
srhb: no way...!!!
<srhb>
gchristensen: From your surprise I feel like I'm misunderstanding your question :-P
<gchristensen>
no I'm just Extremely Excited right now :P zimbatm is riling me up in another chat :D
<srhb>
gchristensen: What we have feeds the machine ID (I don't recall if we use a network hardware address, but probably) to a server that decides on the image to serve
<srhb>
gchristensen: The image is built from a specification of mac -> configuration.nix more or less
<srhb>
By hydra, of course
<srhb>
That's all though
<fpletz>
injecting a config would require a rebuild of the netboot initrd, if you want to live-boot from that url it would probably take too long to build :)
orivej has joined #nixos-dev
<fpletz>
or write pass the url via kernel cmdline and write a service that does a nixos-rebuild with that config
<fpletz>
we also have a netboot setup, that would be a nice idea :)
<fpletz>
gchristensen: if we have a fixed url for netboot we can finally get listed on netboot.xyz :)
<gchristensen>
yeah, that is still an annoying issue :P
<zimbatm>
what is a typical timeout for netboot?
<zimbatm>
the request could hang while the build is happening
<gchristensen>
what are the chances netboot firmware is resistant to the slow loris attack
<fpletz>
ipxe ftw :)
<gchristensen>
same question :)
<fpletz>
not sure about ipxe http timeouts but the connect timeout is 30s
<gchristensen>
my bet is if the image service sends a single byte every few seconds we'd stay connected just fine :A)
<zimbatm>
is there a prefix in the response that is always the same? fixed size bytes * 30 second :)
<gchristensen>
well it is HTTP so we can send as many HTTP headers as we want
<clever>
gchristensen: oh, if you return a file starting with #!ipxe, it will be parsed as an ipxe script
<clever>
gchristensen: that script could then sleep, then re-execute an http url
<clever>
which just returns the same script
<gchristensen>
haha, true
<fpletz>
clever: oh, yeah, it would have to return an ipxe script anyway at some point due to the init= kernel param for the system store path
<fpletz>
that will change if the config is dynamic :)
Willi_Butz has quit [Ping timeout: 256 seconds]
alunduil_ has quit [Ping timeout: 256 seconds]
<shlevy>
/nix/store/jhrsn9fq6jymrsw2njj7lbg4ni1kfi44-extra-utils-riscv64-unknown-linux-gnu/bin/ash: error while loading shared libraries: libm.so.6: cannot open shared object file: No such file or directory
<shlevy>
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
<shlevy>
*technically* I booted cross-nixos :D
niksnut_ is now known as niksnut
<dtz>
:D
<dtz>
\o/
<shlevy>
Aaah the failure is due to lack of proper LDD
<shlevy>
Forgot I hadn't fixed that yet.
<sorear>
LDD?
<shlevy>
Sorry, no caps
<shlevy>
Currently the nixos initrd works by running ldd on each binary and copying the libs needed
<shlevy>
Rather than using nix's closure, which is likely to be more than we need
<shlevy>
So instead I need a recursive readelf script :D
<sorear>
huh. didn't know glibc's ldd didn't work in that way
<clever>
shlevy: qemu-user?, dynamicaly linked?
<shlevy>
No qemu-user
<clever>
shlevy: oh, or cross ldd?
<shlevy>
cross-glibc doesn't even build ldd :)
<clever>
shlevy: also, ldd is just a bash script to set a few env vars, one min
<shlevy>
I'm just going to use readelf to find DT_NEEDED and rpath
<shlevy>
clever: yes, but then it calls the loader
<clever>
shlevy: you can use qemu-user for that, without binfmt-misc
<dtz>
pax-utils' lddtree may be useful but likely overkill.
<shlevy>
Sure, but it's overkill
<dtz>
esp since I have it install the python version by default.
<dtz>
but yeah ldd behavior shouldn't require execution
<Mic92>
shlevy: do you already have hardware for risc-v?
<shlevy>
Mic92: Nope, in a month or so
<Mic92>
shlevy: we have one strong FPGA here and a hardware guy who wants checkout risc-v sometime. maybe this will weekend project later or so. I assume you have risc-v branch somewhere?
<clever>
Mic92: ive also got an fpga, let me find its specs...
<sonarpulse>
shlevy: thoughts so far is a) we still need self super b) if {{ foo.bar.baz = ...; }} works, are we doing a shallow or recursive union?
<sonarpulse>
shlevy: but the library changes (separate from the language changes) I am all for anyways
<sonarpulse>
(oh shit, I hadn't even gotten to module system yet)
<pierron>
niksnut: The main issue I see, is that there is no equivalent of the old reference, and that the depth is defined ahead, so extending has to be thought ahead, instead of when you need to extend.
<pierron>
niksnut: the "old:" argument is used for extending postInstall phases or similar.
pxc has quit [Ping timeout: 240 seconds]
<sonarpulse>
pierron: do you think SOS is worth it without any language support?
<pierron>
niksnut: and being able to decide when you stop the extending process is similar to when you apply mkForce, in the case where everything is extendable by default.
<sonarpulse>
(I do)
<pierron>
sonarpulse: I think it would be too verbose to be accepted.
<sonarpulse>
(x: with x; [ ....]) isn't to verbose to me
<pierron>
sonarpulse: the recursiveZip is.
<pierron>
sonarpulse: (x: with x; …) is useful only if you can prevent anything else from the context to enter.
<sonarpulse>
pierron: we could do that with types hahaha
<pierron>
let y = …; in (x: with x; y /* read x.y */)
<sonarpulse>
(higher ranked polymorphism)
<sonarpulse>
(buildInputs : forall x. attrs x -> list x
<pierron>
niksnut: I think using the "… // {{ … }}" as a way to control the decent in an attribute set is nicer than the SOS proposal.
<pierron>
niksnut: this way the right-hand-side defines where the recusive decent stops.
<pierron>
niksnut: in which case we could keep the same idea as the old argument with some other syntax on attribute sets.
<pierron>
niksnut: and // would have to be changed to work on functions too.
<pierron>
I will comment on github later.
<niksnut>
pierron: regarding "old:", my hope is that merge functions are enough
<shlevy>
Hmm I've got systemd trying to run things like /usr/bin/mount... I wonder if that's something that's changed on staging or just an issue with cross specifically?
<shlevy>
fpletz: ^
<pierron>
niksnut: hum … I do not think the default merge option would cover all the override cases.
<pierron>
niksnut: I would definetly prefer named attribute in such cases.
<pierron>
niksnut: as a different merge rule.
<pierron>
niksnut: now that I tihnk about it, this would also be useful in many cases in NixOS where you want to remove something instead of adding something.
<Mic92>
shlevy: my pr is still open, so nothing has changed since the last systemd upgrade.
<shlevy>
:(
<gchristensen>
shlevy: could you write a blog post about your work on risc-v and how evidently easy it has been? :P
<Mic92>
shlevy: I think I know the reason, why this is happnening though.
<shlevy>
gchristensen: I should! I'm not going to quite commit right now but if I can find time for it I will :)
<Mic92>
shlevy: I plan to rework some stuff in the buildsystem and send it upstream to make NixOS build with less patches. If you have input I can also improve cross-compiling support.
<shlevy>
Mic92: Other than this issue it's all been great
<shlevy>
sonarpulse: OK with stdenv.runtimeShell = pkgs.bash?
<sonarpulse>
I really want to get rid of the stdenv cross adapter
<sonarpulse>
maybe I can on staging now
<shlevy>
:)
<sonarpulse>
shlevy: in your pr, i wonder what pkgs.bash we already changed should also go to pkgs.stdenv.runtimeShell
<sonarpulse>
*pkgs.runtimeShell
<sonarpulse>
whew
<shlevy>
sonarpulse: Probably a bunch :) But harder to trace down
<sonarpulse>
yeah indeed
<sonarpulse>
maybe I'll do a big (git diff first-bgmari-commit..) | grep pkgs.bash haha
<shlevy>
:D
<sonarpulse>
that's what I told him to do
MichaelRaskin has joined #nixos-dev
<thoughtpolice>
shlevy: I looked over #36187 and at a glance it looks good, but admittedly I don't know about some of the other WIP stuff going on.
<thoughtpolice>
There are a lot of moving pieces to CC right now...
<thoughtpolice>
But yes I basically fixed sudo/strace etc and a million other things in vaguely similar ways, though using some old work from sonarpulse
<sonarpulse>
thoughtpolice: me or bgamari?
<thoughtpolice>
Yours, from the Obsidian branch
<sonarpulse>
basic cross infra is much more settled now
<sonarpulse>
ah so the infra, not specific nixos fixes
<thoughtpolice>
Yes, I ended up doing my own work on our fork for a bunch of various other things, but I am cross building NixOS now, at least.
<sonarpulse>
cool
<sonarpulse>
it sounded like you 3 were already going to exchange commits for nixos
<thoughtpolice>
Obviously though at the moment I'm not going to upend our $WORK tree to examine this but yeah
<sonarpulse>
but yeah do recommend
<sonarpulse>
sure
<thoughtpolice>
we were basically all converging on the same solution at different speeds
<thoughtpolice>
Personally I have my own use for a few ARM board cross compiles though, so I'll probably get a good feel for where everything is in master real soon
<thoughtpolice>
shlevy: Also, unrelated, but I actually took a look around and I *think* NixOS at this point is actually pretty good wrt using <nixpkgs> in places, in case you want to set NIX_PATH empty -- it's only in the test components for Hydra that use NIX_PATH based imports, the rest are relative.
<thoughtpolice>
shlevy: I plan on verifying this soon on my own private nixos-configs (so they can always have in-sync, bootstrapped Nixpkgs checkouts across all machines), but do you imagine that's really the only sticking point?
<thoughtpolice>
I suppose I have to fix the testing stuff too actually, if I want qemu-based testing to work without leaking impurities into the build...
<gchristensen>
peti: that was very inspiring :)
<LnL>
^^
<gchristensen>
I'm pretty sure I'm going to get this thread framed
<shlevy>
thoughtpolice: I think it should work, yeah
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined #nixos-dev
<fpletz>
shlevy: that's weird, I didn't encounter that /usr/bin/mount issue before… did you read that in the journal? what unit was that?
<sonarpulse>
shlevy: didn't you already land perl cross?
<sonarpulse>
are there some master commits in that PR?
<shlevy>
sonarpulse: Nope, I pushed it to my branch to share it
<sonarpulse>
ah right
<sonarpulse>
shlevy: ok 3 questions after more thorough review. In case you saw already, I quickly deleted one comment that i posted on its own and remade it as part of the broader review
<sonarpulse>
shlevy: ok I'll look more more findLibs
<sonarpulse>
as far as the person is saying "just use host [sic, i think lol, should be "build"] perl", I like the sound of that
<sonarpulse>
but i see no reason to block you nixos improvements on that
orivej has joined #nixos-dev
pie__ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
FRidh2 has quit [Quit: Konversation terminated!]
goibhniu has quit [Ping timeout: 256 seconds]
<shlevy>
Yeah, I have that open to explore that too :)
goibhniu has joined #nixos-dev
goibhniu1 has joined #nixos-dev
goibhniu has quit [Ping timeout: 252 seconds]
<angerman>
sonarpulse: I’m having an issue when trying to extend the haskell packages through packageOverrides. The extension doesn’t end up in the buildPackages
<sonarpulse>
angerman: that's intended behavior, for better or worse
<angerman>
How do I inject a package into the build packages?
<sonarpulse>
(two seperate fixpoints so it was naturaly not to mess with the extend functions and tie them together)
<sonarpulse>
let me see
<angerman>
sonarpulse: the issue: I have a custom cabal (Cabal_HEAD) package.
<sonarpulse>
yeah
<sonarpulse>
angerman: so btw my coworker ended up working around that problem
<sonarpulse>
but my patch i linked you didn't seem to work
<sonarpulse>
I never ended up using it in our stuff you see
<angerman>
For my cross compiled package, I need buildPackages.Cabal_HEAD in the setupHsDepends
<sonarpulse>
the idea is sound however and am am sure you can fix it
<sonarpulse>
let me check nix for that
<angerman>
sonarpulse: I got your patch to work...
<sonarpulse>
oh good!
<angerman>
... as long as I keep doing evening *in* nixpkgs
<angerman>
Now I’m trying to clean it up, and move the custom compiler and Cabal_HEAD into config.nix
<sonarpulse>
cool
<sonarpulse>
I am getting you a gist
<sonarpulse>
from my coworker haha
<angerman>
sonarpulse: but I’m stuck with the buildPackages not having my Cabal_HEAD
<angerman>
sonarpulse: do we have any mechanism of automatically moving a package expression into buildPackages? You almost always want the Setup.hs dependencies from the buildPackages
<sonarpulse>
angerman: have you seen buildHaskellPackages?
<sonarpulse>
setup.hs are drawn from there
<sonarpulse>
that is in turn drawn from buildPackages in the default package sets
<clever>
in compiler.override { initialPackages = stackPackages;
<sonarpulse>
(see pkgs/top-level/haskell-packages.nix)
<clever>
any relation to this area?
<sonarpulse>
never heard of initialPackages huh
<clever>
stack2nix uses that to replace all of haskellPackages with custom versions
<sonarpulse>
the `ps.lib.optionalAttrs (ps.hostPlatform != ps.buildPlatform)` lib part you can adjust as you please
<sonarpulse>
(no harm also using it for libraries used by Setup.hs)
<angerman>
sonarpulse: thanks I'll give that a try once I'm out of bed :-)
<sonarpulse>
hahah sounds good. good morning!
<angerman>
it's 10 to 8am.
<shlevy>
sonarpulse: Am I good to merge cross-nixos?
<sonarpulse>
shlevy: you wanted me to look over findLibs bash in more detail?
<sonarpulse>
that is last thing I have to do
<shlevy>
Ah yeah
<angerman>
sonarpulse: another thing: the `.integer-simple.` logic seems to go horribly wrong when cross compiling. It starts pulling in all kind of packaes to be built for the host, that are supposed to be only built for the build machine.
<sonarpulse>
shlevy: will that be a mass rebuild alone? (adjusting my nit/style threshhold hahaha)
<sonarpulse>
angerman: oh hmm
<sonarpulse>
not surprised I didn't notice that
<angerman>
I went back, and basically changed the nix/head.nix to use integer-simple if build != host.
<angerman>
couldn't get gmp to built for windows via mingw32 just yet.
<shlevy>
sonarpulse: No, not a mass rebuild at all
<shlevy>
sonarpulse: Just the initrd would rebuild
<sonarpulse>
shlevy: hmm ok
<sonarpulse>
shlevy: I sometimes like `while (( ''${#left[@]} )); do` but this is just stupid style opinion
<sonarpulse>
I looked at the rest all else is fine
<sonarpulse>
I am embarrassed to so bike-shed on the RFC :D
<sonarpulse>
*PR itself
<shlevy>
Dude, that's what review is for
<shlevy>
If I can improve the code easily, great
<shlevy>
If you nit and I disagree, oh well we'll figure it out :P