IRC channel logs
2018-03-13.log
back to list of logs
<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 <nckx>‘Outsourced Chip Design Contains Backdoors’ <bavier`>there's some doubt about the authenticity of the flaws published <bavier`>e.g. no peer review, limited notice given to relevant party before disclosure, no published exploits <bavier`>I'll need to wait for some more review <bavier`>Sleep_Walker: arguably none, just what many others are saying on the interwebs <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? <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. <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' <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>my hack energy has pretty much evaporated already, but the extended paper deadline drags me across the floor towards the finish line. <mbakke>Should we start a 'master' evaluation on Hydra? <civodul>mbakke: i just started one on 'staging' (i had forgotten yesterday) <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. <catonano>muto: are you the MutoShack from Mastodon ? <muto>catonano: I was AFK for a while, but yes that's me! <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... <muto>catonano: Just Guix running on top of Ubuntu <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 :/ <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>efraim: I didn't realise they had a reputation. I just sent a message to -patches. <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. <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>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”. <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. <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>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…? <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 <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 :-) <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>oh yes: qemu-x86_64 -r 2.6.45 $(type -P uname) -a <rekado>civodul: only 2.6.32 is supported <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>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. <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 <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>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