IRC channel logs


back to list of logs

<brendyn>nix fails to build for me
<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!
<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:
<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
<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 ''... 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?
<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( 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>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.
<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>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>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.)
<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?
<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>r-minimal uses “system”, which is provided by the libc(?).
<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.
<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:
<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 :-)
<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 :-)
<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><rekado> would it be enough to declare patched-static-bash as a replacement
<rekado> for static-bash-for-glibc then…? [22:41]
<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
<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 :-)
<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>nothing insurmountable, but a bit tedious
<civodul>until then...
<civodul>ACTION -> zZz