IRC channel logs

<brendyn>nix fails to build for me https://paste.debian.net/1014428/

<risciii>[14:30] risciii: I am running linux-libre 4.15.7-gnu on amd Ryzen 1600 and amd rx 580 GPU, is there any work around for 'fb: switching to amdgpudrmfb from EFI vga' error on boot? Apart from 'nomodeset' kernel option

<civodul>Hello Guix!

<pkill9>hey

<efraim>Hi!

<kmicu>( ^_^)／

<civodul>hey hey!

<bavier`>hello guix

<civodul>howdy bavier`

<civodul>how's everything?

<g_bor>hello guix!

<bavier`>hi g_bor

<bavier`>oh, lovely: https://amdflaws.com/

<civodul>bah

<nckx>‘Outsourced Chip Design Contains Backdoors’

<bavier`>there's some doubt about the authenticity of the flaws published

<civodul>it's hard to parse

<bavier`>e.g. no peer review, limited notice given to relevant party before disclosure, no published exploits

<civodul>yeah

<Sleep_Walker>bavier`: source?

<bavier`>I'll need to wait for some more review

<bavier`>Sleep_Walker: arguably none, just what many others are saying on the interwebs

<Sleep_Walker>thanks, nevermind

<g_bor>hello guix!

<g_bor>Yesterday I forwarded and e-mail from guix help to devel.

<g_bor>It was about pivot_root failing in chroot.

<g_bor>The reason was, that this was running on a systemd based distribution, where mounting filesystems with MS_SHARED is usual, and stops pivot_root from working.

<g_bor>Would there be any drawback, if we simply unshared the mount namespace before the pivot_root call?

<g_bor>I mean unconditionally?

<muto>So I have had Guix on my Ubuntu machine for some time now, but whenever I try to run 'guix pull', I get "Updating from Git repository at 'git.savannah.org'... guix pull: error: mkdir: Permission denied.

<NewGnuGuy>muto: try `sudo guix pull`

<muto>NewGnuGuy: From sudo I just get "aguix pull: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused" after a "no locale" error.

<wigust->muto: Does ‘pgrep -a guix-daemon’ return something?

<muto>wigust-: Yes, it returns '584 /var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon --build-users-group=guixbuild'

<wigust->muto: Will ‘guix build hello’ build successfully?

<muto>wigust-: No, that also returns: 'guix build: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused'

<g_bor>I have to go now. See you!

<muto>I've noticed that when I write 'id {username}', I am not part of the 'guibuild' group, but when I try 'useradd -G guixbuild {username}', it says I already exist

<efraim>Bad permissions on /var/guix/* ?

<muto>efraim: Do you think a 'chmod -R /var/guix/' might help?

<rekado>muto: no accounts except for the builder accounts should be member of that group.

<muto>rekado: Ah, that makes sense!

<efraim>I'm not in front of my computer so I don't know what its supposed to be off hand

<muto>I can run guix pull as root, but not with 'sudo' from my non-root account. I'm going to try updating from root and see if it works.

<rekado>in lieu of a fix for using a grafted glibc with a repaired bash-static I’m going to push a change to r-minimal that adds “bash-minimal” to the inputs.

<rekado>this ensures that no reference to the static bash is retained.

<civodul>rekado: sounds good! and sorry for not going further

<civodul>the initrd/module story is draining my hack energy

<rekado>no problem at all

<rekado>my hack energy has pretty much evaporated already, but the extended paper deadline drags me across the floor towards the finish line.

<rekado>I need a break :)

<civodul>heh, i can imagine!

<mbakke>Should we start a 'master' evaluation on Hydra?

<rekado>Does anyone know why gcc 4.7 fails to build? http://hydra.gnu.org/build/2507082/nixlog/1/tail-reload

<civodul>mbakke: i just started one on 'staging' (i had forgotten yesterday)

<mbakke>Oh. Thanks!

<rekado>should we build python-updates on hydra or is it okay to only have berlin build it?

<mbakke>I believe most users only have Hydra as a substitute server, so we should probably build it there in advance.

<mbakke>Can you also update Python to 3.6.4? :)

<efraim>the source seems unclear if invoke needs a #t at the end

<efraim>has python@3.6.4 been checked on aarch64?

<mbakke>efraim: (invoke ...) returns #t on successful execution.

<efraim>that's what I thought

<catonano>muto: hi !

<catonano>muto: are you the MutoShack from Mastodon ?

<muto>catonano: I was AFK for a while, but yes that's me!

<catonano>muto: Ah ! Glad to find you here !

<muto>catonano: Definitely! I'm just trying to run 'guix pull' as a non-root user right now, been running into some "Permission denied" issues right now...

<catonano>muto: guix or guixsd ?

<muto>catonano: Just Guix running on top of Ubuntu

<catonano>muto: I see

<catonano>muto did yo get any answers ? I couldn't follow the discussion

<catonano>muto: ok I read the log. No you didn't get answers. Please, write on the help mailing list, it's easier to follow, there !

<efraim>the source for ocaml-qtest changed upstream :/

<efraim>another github one

<nckx>So has the source for hop(.inria.fr). Not GitHub related, though, AFAICT.

<efraim>hop isn't great about not changing their source in place

<efraim>i have ocaml-qtest updated locally, i'll push it in a little bit

<bavier`>so, no source downloads from sourceforge anymore?

<nckx>Oh?

<nckx>efraim: I didn't realise they had a reputation. I just sent a message to -patches.

<nckx> Replies welcome :-)

<nckx>bavier`: I'm pretty sure I downloaded some sourceballz from SF in the past few days, but not on the command line.

<bavier`>nckx: right, I think JS is required, afaict

<bavier`>they don't offer a "direct link" on the download pages anymore

<nckx>^ yes, -patches, because it morphed into a bug report before I thought about sending it to bug- instead. Sorz.

<nckx>bavier`: Oh dear lord.

<nckx>ACTION groans.

<nckx>What are they drinking.

<bavier`>lemme see though..., xfig still downloads

<nckx>‘The old sourceforge you love is finally back! Also here suck on our JS.’

<nckx>efraim: Nice work on demystifying store file names.

<efraim>:)

<bavier`>nckx: false alarm; this project just has a weird file url. but still, the added JS and removal of direct links is worrisome

<rekado>unfortunately adding bash-minimal to the inputs of r-minimal didn’t help.

<rekado>it still uses the static bash for “system”

<rekado>and that’s despite the fact that “guix gc --references” does not show static-bash among the references any more.

<efraim>could it be related to the build system then?

<efraim>although i would have thought adding bash-minimal would've fixed that part

<rekado>oh, I know why.

<rekado>it didn’t retain a reference at all.

<rekado>it uses glibc’s “system”, which uses static-bash

<rekado>so this really requires either patching (but what about Python’s or Guile’s “system” implementation…) or a proper fix wrt to grafting the glibc.

<rekado>:(

<rekado>AIUI I’d need to build a new static-bash with the replacement for glibc, then build the actual replacement of the glibc with that new static-bash.

<rekado>as expected, python’s “os.system” also fails with “kernel too old”.

<jackhill>clbdbbeirrbciudjvhjkikkbflvfuhtk

<jackhill>oops, sorry for the noise

<g_bor>hello guix!

<rekado>hmm, tried building a new static bash with the patched glibc, but it still crashes on CentOS 6.

<rekado>looks like it’s not enough to just add the new glibc to the native inputs. Guess I’ll need to change the toolchain as well.

<rekado>if you know a better way, please share your ideas.

<rekado>I suppose I could copy the flags that static-bash-for-glibc uses

<nckx>Hello g_bor! Happy 22:22:22.

<nckx>(Shh, time zones don't exist.)

<g_bor>:)

<civodul>heheh

<civodul>rekado: hmm maybe, gcc sorta hardwires its libc

<rekado>I think I may need to build a static variant of the patched libc first, then build the static bash, then include that in the dynamically linked variant of the patched libc.

<rekado>oh, the thrill of fixing something that’s broken in production! :)

<rekado>well, at least I’m learning something.

<rekado>okay, that new static bash no longer fails on CentOS.

<rekado>now I just need to build the replacement glibc with patched-static-bash as an input.

<civodul>rekado: so you managed to build a static-bash against the patched glibc in the end?

<rekado>yes

<civodul>and passing it directly to r-minimal isn't enough?

<rekado>I’m preparing a patch now and try building this on the cluster.

<rekado>no.

<rekado>r-minimal uses “system”, which is provided by the libc(?).

<civodul>yes

<civodul>yes, 'system' is in libc and uses its static bash

<rekado>and since the libc uses static-bash, which is built with the regular libc (not the patched one), “system” ends up calling that static-bash.

<civodul>right

<rekado>and that crashes on CentOS 6 with “kernel too old”.

<rekado>so I built patched-static-bash, which statically links with glibc-2.26-patched-boot.

<rekado>and now I’m building glibc-2.26-patched, which uses patched-static-bash instead of static-bash.

<civodul>sounds good

<rekado>so with the new glibc-2.26-patched as a replacement for glibc I think it should work.

<civodul>yes, we need to check whether glibc-final gets a correct replacement, too

<rekado>oh, right.

<rekado>I don’t think it does.

<rekado>it adds static-bash-for-glibc to its inputs.

<rekado>would it be enough to declare patched-static-bash as a replacement for static-bash-for-glibc then…?

<rekado>(my head starts spinning)

<rekado>FWIW here’s my current patch, which doesn’t address this problem: http://paste.debian.net/1014606/

<g_bor>hello! I have a patch that fixes java-simple-xml test failures on java8, and it is forward-backward compatible. Should I send this to guix-patches or bug-guix?

<nckx>If anyone here's using a non-GuixSD distro and feels like doing me a favour: could you install knot(-dns) and check whether ‘man 5 knot.conf’ contains a COPYRIGHT section at the end?

<nckx>g_bor: -patches would be my choice, unless there's already a bug- thread.

<g_bor>ok, will send to patches then.

<civodul>nckx: on Debian there's a COPYRIGHT section at the end but "man 5 knot.conf | grep DESC" shows only one line

<civodul>rekado: let me give it a try :-)

<rekado>civodul:thanks!

<civodul>the patch LGTM at first sight

<rekado>but it doesn’t make any changes to glibc-final, which includes (the unpatched) static-bash-for-glibc.

<rekado>I don’t know if this matters for our purposes.

<g_bor>nckx: I've checked this on ubuntu, there is a COPYRIGHT section.

<rekado>IIRC glibc-final is a level lower than glibc/linux, so it shouldn’t matter here.

<nckx>civodul: Thanks! So even if there's something wrong with those pages (I agree it's the most likely explanation), there's something about our... is it still *roff nowadays? that is uniquely sensitive to that.

<nckx>I give up for now, more important things being discussed here :-)

<rekado>oops

<g_bor>Good night! See you!

<nckx>g_bor: thanks for taking the trouble. Weird bug. Weird bugs, troff source, spooky, me out.

<civodul>rekado: "linux64 --uname-2.6" returns 2.6.75

<civodul>do you have another way to test?

<civodul>oh yes: qemu-x86_64 -r 2.6.45 $(type -P uname) -a

<rekado>civodul: only 2.6.32 is supported

<rekado>(according to the patch)

<civodul>right, i just wanted to check whether i got "Kernel too old"

<rekado>civodul: I’ll push this somewhere to a private repo, guix pull from there, and then build r-minimal with this change

<rekado>oh, okay

<rekado>but you’d get it even with the patch.

<rekado>I’m building guix now; will try building r-minimal and run it on CentOS shortly.

<rekado>(it’s a pity I can only use one core with “guix pull”, because otherwise it crashes at the last few percent of the compilation)

<civodul>oh really? 'guix pull' is a nightmare

<civodul>currently your patch doesn't change the replacement of glibc-final

<rekado>yeah, it crashed three times today. I even tried with cores=2, but that didn’t make it better.

<rekado>right. Is this a problem?

<civodul>because glibc-final overrides "static-bash"

<civodul>it's a problem yes, because system(3) remains broken

<rekado>oh.

<rekado><rekado> would it be enough to declare patched-static-bash as a replacement

<rekado> for static-bash-for-glibc then…? [22:41]

<civodul>hmm

<rekado>or should I add a replacement for glibc-final that would then be grafted?

<civodul>so the problem is just that package/inherit applies changes to the replacement, and for glibc-final we'd want not to apply the static-bash change

<civodul>if you see what i mean

<civodul>maybe not, it's muddy here :-)

<civodul>or foggy

<rekado>I don’t get it, but I’ll try to use my brain again.

<rekado>what “static-bash change” do you mean here?

<rekado>the change from the static-bash in glibc-final-with-bootstrap-bash to static-bash-for-glibc?

<rekado>Or the change to using my new patched-static-bash?

<rekado>it seems to me that we can fix this by adding a replacement to glibc-final — glibc-final-patched —, which would override static-bash-for-glibc with the new patched-static-bash.

<rekado>then glibc-final (with the bad static-bash) would be replaced with glibc-final-patched (with the new patched-static-bash).

<civodul>rekado: yes, that would work

<civodul>however, package/inherit as used by glibc-final complicates things

<civodul>because it forces its own static-bash

<rekado>ugh

<civodul>we could get around it by adding a replacement in static-bash-for-glibc

<rekado>that would just be a matter of adding (replacement patched-static-bash) to static-bash-for-glibc, because patched-static-bash *is* that replacement.

<civodul>yes, though that seems to lead to a derivation cycle :-)

<rekado>argh!

<civodul>i think that's simply because we need to mirror the original graph

<civodul>in the original graph we have static-bash-for-glibc which mimics static-bash but using the early inputs

<civodul>here we need "patch-static-bash-boot" using the early inputs

<civodul>bah

<civodul>nothing insurmountable, but a bit tedious

<civodul>until then...

<civodul>ACTION -> zZz

IRC channel logs

2018-03-13.log