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.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
adisbladis has joined #nixos-dev
ivan has quit [Remote host closed the connection]
ivan has joined #nixos-dev
hl has quit [Ping timeout: 246 seconds]
hl has joined #nixos-dev
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 240 seconds]
lassulus_ is now known as lassulus
jtojnar_ has quit [Remote host closed the connection]
primeos has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 244 seconds]
sir_guy_carleton has quit [Quit: WeeChat 2.0]
jtojnar has joined #nixos-dev
goibhniu has joined #nixos-dev
__Sander__ has joined #nixos-dev
__Sander__ has quit [Ping timeout: 244 seconds]
__Sander__ has joined #nixos-dev
garbas has joined #nixos-dev
orivej has joined #nixos-dev
hiberno has quit [Quit: WeeChat 1.6]
__Sander__ has quit [Ping timeout: 252 seconds]
__Sander__ has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
__Sander__ has quit [Ping timeout: 240 seconds]
__Sander__ has joined #nixos-dev
<andi-> so the channel(s) do no longer advance due to the deprecation warnings? (https://hydra.nixos.org/build/81047553/nixlog/8) Or does the hydra message reffer to something else?
<clever> after bisecting for nearly a day, i stumbled upon https://github.com/NixOS/nixpkgs/commit/c5019585354291686e7b8c6a263336782d9de814
<clever> hydra was fixed in nixpkgs, but not fixed in hydra itself
<infinisil> Why can't a man just output some traces without everything breaking down lol
<andi-> so there seem to be two issues? The one clever was talking about and the linked hydra output?
<clever> in my case, the proble is even building hydra itself, on nixpkgs master
<clever> ive just now fixed that
<infinisil> clever: Shouldn't be a problem that prevents channel updates though, right? It's just a normal packages failure
<clever> correct
<clever> and it was already fixed in nixpkgs itself
<infinisil> So it seems that these traces are indeed the problem..
<infinisil> :(
<clever> but there is a copy of that expression in hydra's release.nix
<clever> and the copy lacked the fix
<infinisil> Hmm..
<andi-> So what do we do until he comes up with his ideas? Revert and wait for a better / fixed approach?
<srhb> Yes, I think it can safely be reverted if we want (especially release-18.09) to keep flowing while a fix is in progress.
<infinisil> Why the hell does hydra fail upon such traces though :/
<srhb> infinisil: That nixpkgs tarball job has specific mechanics in place to disallow traces.
<srhb> infinisil: So working as intended.
<infinisil> Why though?
<srhb> I can only guess to avoid shipping something with eval warnings at that level... But I don't know for sure :)
<infinisil> srhb: what's the code that makes traces fail?
<srhb> infinisil: pkgs/top-level/make-tarball.nix line 87
ekleog has quit [Quit: back soon]
ekleog has joined #nixos-dev
__Sander__ has quit [Ping timeout: 272 seconds]
<infinisil> srhb: Thanks
__Sander__ has joined #nixos-dev
obadz has quit [Ping timeout: 240 seconds]
obadz has joined #nixos-dev
phreedom has joined #nixos-dev
phreedom__ has quit [Ping timeout: 256 seconds]
__Sander__ has quit [Ping timeout: 272 seconds]
<aminechikhaoui> hm is `nix repl` unusable for everybody or just me ?
<aminechikhaoui> I'm on 2.1pre6338_45bcf541
<LnL> yes, update
<LnL> or use 2.1.1, it's newer then that unstable version
<aminechikhaoui> ok I'm on unstable on 18.03
<aminechikhaoui> I'll update and see if that's bumped
<aminechikhaoui> or override nix if not
* aminechikhaoui thinks it's probably time for 18.09 anyway
<srhb> aminechikhaoui: Nix got reverted to 2.0.x in 18.09 earlier today though..
__Sander__ has joined #nixos-dev
<samueldr> srhb: ?
<samueldr> wasn't it only the minimal version bumb that was reverted?
<srhb> samueldr: Oh, yes, I guess you're right. :)
<srhb> I actually thought it was all the way down. I'm less sad then.
<samueldr> yeah, just verified, it would have been weird to see a rollback of the released nix version :/
<srhb> Yeah, hours spent being grumpy for nothing! Need to learn to read. :-)
<samueldr> all that minimum version talk makes me wonder what's missing, if anything, to make actual tests for release upgrades, so that during the life of e.g. 18.09, an upgrade from 17.09 is always possible
<samueldr> with only superficial thinking, the only trouble I see is referencing an older release
<srhb> samueldr: I think we already can do rebuilds in the vms, so we just need to inject the two nixpkgs in that case, I think?
<samueldr> yeah :)
<elvishjerricco> What's the difference between /boot/EFI/systemd/systemd-bootx64.efi and /boot/EFI/BOOT/BOOTX64.EFI? They're identical files; why do we need both when UEFI is probably only loading one of them?
<samueldr> the EFI/BOOT/BOOTX64.EFI is a fallback path x86_64 platforms
<samueldr> most UEFI implementations will boot that if not possible to boot anything else
<samueldr> this is where the different "install as removable" options will install the EFI loader to
<elvishjerricco> I'm looking into secure boot with NixOS, doing signing during activation instead of during the build. Just curious about these files. I also need to figure out how to sign the kernel command line and the initrd though...
<samueldr> I don't know whether having the "install as removable" options will also installe the efi loaders in their respective locations (e.g. EFI/systemd/systemd-bootx64.efi)
<elvishjerricco> samueldr: What are these "install as removable" options?
<samueldr> looks like there's only one for grub?
<clever> yeah
<clever> another reason to never use systemd-boot :P
<elvishjerricco> What's wrong with systemd-boot? It always worked out of the box for me, whereas grub didn't (though I never tried to figure out how to fix it)
<srhb> Isn't the systemd-boot install always removable?
<samueldr> elvishjerricco: I do wonder, then, why you would have those two files
<samueldr> (don't know much about systemd-boot yet)
<samueldr> might be what srhb said
<elvishjerricco> srhb: It looks like systemd-boot installs its boot loader in both a removable location and that fallback location
<samueldr> as for I, I just use grub2 since it has background options :)
<srhb> Yeah, I think that is the case.
<elvishjerricco> Anyway, anyone have thoughts on how to sign the kernel command line and initrd for secure boot?
<clever> elvishjerricco: the entire grub.cfg may need to be signed
<samueldr> even when using systemd-boot clever? :)
<elvishjerricco> clever: Assume I'm using systemd-boot unless the situation ends up requiring grub :P
<elvishjerricco> Regardless, how does signing a boot loader config work? The boot loader would have to manually verify the file, right?
<clever> the bootloader would have to load the file, and then call a uefi function to verify the signature
<clever> and then the firmware will check it against the pubkeys loaded into the config
<elvishjerricco> clever: So this would require patching the boot loader?
<clever> yeah
<clever> the bootloader would have to do the same against the kernel and initrd anyways
<clever> and only a bootloader that verifies the signatures of binaries should ever be signed
<clever> i the bootloader runs unsigned code, then secureboot is useless
<elvishjerricco> I've been reading that if you make the initrd and the kernel into one binary, systemd-boot will use EFI to load the image, which will automatically verify both parts
<clever> elvishjerricco: nix makes that very difficult
<elvishjerricco> Which just leaves the kernel command line
<clever> the initrd is an input to the kernel
<clever> the kernel modules are an input to the initrd
<clever> the kernel modules are part of the kernel
<clever> recursion!
<elvishjerricco> clever: We can't combine the existing build products after the fact?
<elvishjerricco> into one image, which we sign, and EFI verifies when systemd-boot launches it?
<clever> elvishjerricco: oh, i think there is a special build flag in the kernel to support just concat'ing an initrd on
<clever> but the kernel will fail to boot if you dont concat an initrd to it
<elvishjerricco> right, that's what I'm talking about
<elvishjerricco> Leaving only the command line as a variable. This could also be hard coded, but then we need a whole image for each NixOS generation, which is too much IMO
<clever> i was thinking about the other option, where it embeds the initrd at kernel build time
__Sander__ has quit [Quit: Konversation terminated!]
orivej has quit [Ping timeout: 244 seconds]
orivej has joined #nixos-dev
sir_guy_carleton has joined #nixos-dev
pie__ has quit [Remote host closed the connection]
pie__ has joined #nixos-dev
Profpatsch has joined #nixos-dev
<Profpatsch> fpletz: I saw the meetup announcement on 20th (Munich). Do you have something special planned?
<Profpatsch> I think I’ll join you if I can make it.
<fpletz> Profpatsch: no, nothing special. just another meetup because we haven't done one in ages
<Profpatsch> Nice
<Profpatsch> Yeah, I hope I can make it.
orivej has quit [Ping timeout: 245 seconds]
joepie91 has quit [Ping timeout: 252 seconds]
<clever> sphalerite: and ive now fixed a number of bugs in hydra, and filed a PR to fix all of them, https://github.com/NixOS/hydra/pull/597
<{^_^}> hydra#597 (by cleverca22, 9 hours ago, open): applying various patches and fixing various things
<LnL> huh, does anybody know why preConfigure doesn't do anything in perl modules?
<LnL> oh, it does't use the stdenv
<samueldr> that configurePhase is overriden without ensuring pre/post are called?
<samueldr> or you answered yourself when I had the back turned :)
<LnL> well it does weird stuff, but it should honor preConfigure from what I can tell
<samueldr> (that was a wild uneducated guess)
<clever> heh, you beat me!
<LnL> lol
<LnL> so it doesn't use the hooks which is weird, but should kinda work?
<LnL> why the rename tho...
<clever> its not clear what the priority is for hooks, when both the function and variable exist
<clever> for phases, the variable has priority over functions
<LnL> I mean pre/post hooks
<clever> and it didnt clear $preConfigure
<LnL> euh, my build segfaults now
<LnL> imma just use perlPreHook
<LnL> samueldr: I think you mentioned XSUtil before https://github.com/NixOS/nixpkgs/pull/46501
<{^_^}> #46501 (by LnL7, 53 seconds ago, open): perl-Module-Build-XSUtil: fix darwin build
<samueldr> according to this handy chart, this potentially fixes 103 issues
<LnL> oh euh, nice! :D
<samueldr> (103 assumes no other failures stop the dependents from building)
<LnL> that report is great
<samueldr> thanks
<samueldr> I still don't know how to use hydra properly, but eh, made my own interface ;)
<LnL> hah, well a bunch of stuff like aggregating failures is something hydra doesn't do
<samueldr> yeah, had to make do with the data, I'm matching on the store path and removing "/nix/store/$hash-"
<samueldr> started build of a subset, let's hope there's no failures
<samueldr> (on ofborg)
<LnL> btw. I temporarily disabled my builder to test some darwin stdenv stuff, let me know if you notice that the queue gets too large
<samueldr> aww https://logs.nix.ci/?key=nixos/nixpkgs.46501&attempt_id=415b8242-f8ee-4a8e-aa82-b1b25a9e81a2
<samueldr> seems they all failed :(
<LnL> sounds like I'm going to have to rename that pr :p
goibhniu has quit [Ping timeout: 252 seconds]
<samueldr> haven't checked the result, half-working on stuff for $client while doing light misc. duties
<LnL> no worries, running some more builds
<LnL> didn't realise it's this late already, I think all of the random selected build now tho :p
<samueldr> they probably have something like one or two failing common builds
<samueldr> (hopefully)
<samueldr> a good thing to do tomorrow though :)
<LnL> yeah, I noticed the same thing passing by a few times