IRC channel logs


back to list of logs

<Rukako>oh no, I missed ludovic again ;-;
<CompanionCube>woo i just randomly fixed my user's guix on a server by blowing away guix/latest and repulling
<rekado>Hi Guix,
<rekado>on core-updates python-minimal fails to build.
<rekado>the test is test.test_socket.LinuxKernelCryptoAPI
<rekado>the test is known to fail on kernels < 4.11
<rekado>python devs recommend skipping this test.
<efraim>i might need to disable a test on tar, it fails non-deterministically on aarch64
<civodul>Hello Guix!
<efraim>rekado: for python-3.6, with #:tests coming before ,phases it might ignore the #:tests config
<efraim>tests 117 and 118 passed this time on tar
<rekado>efraim: I just deleted the offending test.
<rekado>we cannot guarantee that all build nodes use Linux > 4.5, so it’s better to disable it until we update to Python 3.7 (where it is disabled dependent on kernel version)
<efraim>sounds good
<efraim>I should take a look at some of the tests that failed specifically on aarch64 and see if tehy still fail
<efraim>civodul: I've taken the top off the overdrive, I'm going to try some of the spare PSUs I have in my office to see if they make the difference
<civodul>efraim: awesome!
<civodul>you have PSUs of the right size?
<civodul>that seemed to be quite unusual
<efraim>rekado: no change in the disabled aarch64 tests for python3
<efraim>civodul: I have some older PSUs that I can try out so I figured it would be worth trying them first and then seeing what I can do from there
<civodul>sounds good
<rekado>looks like libtool fails to build on core-updates
<civodul>yes, i was planning to look into it
<efraim>civodul: other other overdrive just turns on when its plugged into the wall?
<civodul>you have to push the power button
<civodul>which i couldn't find initially because it's so stealthy :-)
<civodul>it's the shiny metal-ish rectangle on the front
<efraim>i'll look for it
<efraim>i see it now, the silverish part between the VCR door and the lights
<efraim>s/lights/usb ports/
<mbakke>Hmm, changing godot argumens don't seem to rebuild the package.
<rekado>heh, VCR door :)
<efraim>well that was fun, pressed the power button and spun up the fans in both computers
<civodul>don't forget to insert a VHS tape as well
<efraim>I started by only moving the 20+4 connector, so it spun up fans for all the computers it was connected to
<rekado>libtool has one test failure more than expected (6 instead of 5(
<rekado>102: FAILED (
<civodul>ok, i'm still building guile on core-updates so i don't have the test-suite.log yet
<Guest61385>hmm, seems as though my sudo is broken:
<Guest61385>$ sudo ls
<Guest61385>sudo: /root/.guix-profile/bin/sudo must be owned by uid 0 and have the setuid bit set
<efraim>I'm building out to libtool o aarch64 also
<mbakke>sturm: Removing sudo from the root user profile should do the trick.
<rekado>civodul: I’ll produce the test-suite.log and paste it in few minutes
<mbakke>Maybe we should add /run/setuid-programs first in PATH.
***Guest61385 is now known as sturm
<civodul>mbakke: /run/setuid-programs/ is on $PATH on GuixSD
<mbakke>civodul: But it's after the user profile, so if you install sudo or similar to your profile, it will stop working.
<sturm>mbakke: thanks, I'll try that - guess I'll need to boot of GuixSD install disk to get superuser access
<mbakke>sturm: Wait, I see now you run sudo as your user, then get an error about `/root/.guix-profile/bin/sudo`.
<sturm>mbakke, yes that's right
<civodul>mbakke: i have a slight preference for having ~/.guix-profile take precedence over everything else
<mbakke>sturm: Try `PATH="/run/setuid-programs:$PATH" sudo -E guix package -r sudo`.
<civodul>at the risk of allow users to shoot themselves in the foot
<rekado>these are the details of the unexpected libtool test failure:
<sturm>mbakke: yay, that did the trick thank you!
<mbakke>sturm: Great :)
<rekado>these files exist: /tmp/guix-build-libtool-2.4.6.drv-0/libtool-2.4.6/libltdl/.libs/
<rekado>but not the expected ltdl/
***tatiana is now known as tsholokhova
<efraim>second power supply is dead, my last known good PSU not in use is 110V, i'll have to find my converter
<rekado>civodul: adding libltdl to the native inputs seems to be enough to fix libtool.
<efraim>ovmf has (delete 'build) and (add-after 'build ...), that looks like something to take a look at while I try to build aarch64 firmware
<civodul>rekado: it could be because we do --disable-ltdl-install, though that's not new at all
<rekado>civodul: is it okay to add libltdl to libtool?
<civodul>it would be nice to understand why this happens, but since we're in a hurry, adding libltdl as an input is OK
<civodul>with an "XXX" comment maybe :-)
<rekado>next failure is cunit.
<rekado>./bootstrap: ./configure: /bin/sh: bad interpreter: No such file or directory
<rekado>it has an autoconf phase, but the bootstrap phase runs first and executes the “bootstrap” script.
<rekado>I’ll remove the bootstrap phase here and add a XXX comment.
<rekado>rather: I replace it.
<rekado>moving on
<mbakke>I'll give Python 3.6.4 a go.
<efraim>Ovmf built for aarch64
<efraim>mbakke: if you do get it built ping me and I'll check it on aarch64 for test failures
<rekado_>boost 1.66.0 failed on core-updates
<mbakke>ovmf for aarch64, woow :)
<rekado_>same bootstrap phase problem
<efraim>What about with the newer cmake?
<mbakke>Since boost 1.66 requires CMake 3.11, maybe we should go for rc3 :/
<rekado_>but boost 1.66 built just fine (after removing the boostrap phase)
<rekado_>do you mean that packages depending on boost and using CMake won’t be buildable without an update to CMake?
<mbakke>Anyone working on glibc 2.27?
<rekado_>not me.
<mbakke>There are not a lot of changes in the stable 2.27 branch, so we can cherry-pick the important stuff instead of making our own tarball.
<mbakke>We should get this, at least:
<mbakke>(found by perusing this:;a=shortlog;h=refs/heads/release/2.27/master)
<rekado_>I’m going to push a fork of core-updates under the name “rhel6” once I confirmed that most packages build fine.
<rekado_>that could be used as a stable foundation for RHEL6 systems until the core-updates merge.
<mbakke>Oh no, python-3-search-paths.patch needs to be adjusted to a new layer of abstraction in
<rekado_>for an update to 3.6.4?
<mbakke>Yes, but it seems like it was an easy fix regardless, false alarm :P
<mbakke>Since we don't care about the original libdirs and include paths.
<mbakke>3.6.5 is scheduled for 2018-03-26
<mbakke>*** WARNING: renaming "_crypt" since importing it failed: build/lib.linux-x86_64-3.6/_crypt.cpython
<mbakke> undefined symbol: crypt
<mbakke>*** WARNING: renaming "_ctypes" since importing it failed: build/lib.linux-x86_64-3.6/ cannot open shared object file: No such file or directory
<mbakke>Oh joy.
<mbakke>rekado_: The fix for kernels < 4.5 is part of 3.6.4, so I'll include again.
<mbakke>Here is the changelog, for those interested:
<rekado_>mbakke: yes, thank you.
<rekado_>mbakke: after the update could you please also check if python-six (or any other small python package) builds reproducibly?
<mbakke>rekado_: Will do, assuming I can figure out this crypt issue :P
<mbakke>Can't find the related changelog entry.
<roptat>hi, I have a problem with my guix installation: ERROR: no code for module (texinfo)
<roptat>it happens after I unset GUIX_PACKAGE_PATH
<roptat>if it's set to the correct directory, I don't get this error
<roptat>my ~/.config/guix/latest points to a git repository that I cleaned and rebuilt
<roptat>I only added a few packages to the git repository compared to master
<roptat>ok, it seems it was because of the directory I was in...
<rekado_>acl failed on core-updates (/gnu/store/ar59j6ikk7gpmpks0g92gb2pb1dkk7qs-acl-2.2.52.drv)
<rekado_>disabling parallel building fixes this, but that doesn’t seem right.
<rekado_>hmm, no, problems with gzip timestamps
<rekado_>gzip: stdin: warning: file timestamp out of range for gzip format
<rekado_>that’s what happens at this step: /gnu/store/8kzhdg265x5yw0nyw0w18sir7c1bc3a7-gzip-1.9/bin/gzip --best -c < CHANGES > CHANGES.gz
<rekado_>guess we’ll have to reset timestamps.
<mbakke>rekado_: Where did you get that warning?
<mbakke>That's something new in gzip 1.9 FWIW.
<rekado_>mbakke: that’s when building acl on core-updates.
<mbakke>Reading the commit, it's only supposed to emit that when timestamp==epoch 0.
<rekado_>CHANGES is at 0 because of patching and repacking. I’ll just touch the file after unpack.
<mbakke>Can we make the repack phase use epoch 1, as we do with SOURCE_DATE_EPOCH?
<mbakke>Otherwise I suspect this will crop up a lot.
<rekado_>yes, that would be better.
<rekado_>that’s going to be a world rebuilding change, though.
<mbakke>That's okay, we still need the GCC fix.
<mbakke>And preferably also glibc 2.27.
<rekado_>yeah, it’s just not okay for me :)
<rekado_>but that’s okay.
<rekado_>I’ll just try to fix this on a separate branch.
<rekado_>but wait, did we read this gzip change correctly?
***tilpner_ is now known as tilpner
<rekado_>this branch is only executed when stamp != 0
<mbakke>Oh, hmm.
<mbakke>/* It's intended that time stamp 0 generates this warning, since gzip format reserves 0 for something else. */
<mbakke>AFAICT when timestamp <= 0, then the warning is emitted and timestamp is set to 0.
<mbakke>Note that this is in zip.c, in the bottom hunk of the commit.
<civodul>rekado_: for boost in core-updates, do yo know how the standard 'bootstrap' phase failed?
<civodul>i'm curious
<civodul>i may have missed other phases not called 'bootstrap, as was the case for cunit
<rekado_>sorry, the logs have long run by.
<rekado_>in one of these cases the “bootstrap” script tried to run “configure” which complained about “/bin/sh” not existing.
<rekado_>I don’t know if that was boost or cunit, though.
***MatthewAllan93_ is now known as MatthewAllan93
<mbakke>Python 3.6.4 seems to work, will give glibc a go while waiting for it to finish.
<mbakke>Oh no, glibc requires bison now.
<efraim>We have a bison-boot0
<mbakke>Uh... /tmp/guix-build-glibc-intermediate-2.27.drv-0/glibc-2.27/elf/../locale/programs/xmalloc.c:63: undefined reference to `_libc_intl_domainname'
<mbakke>This sounds fun.
<rekado_>I pushed a branch rhel6, which is just core-updates at the moment.
<rekado_>it’s a dead-end branch that keeps core-updates stable for a little while, so that RHEL6 users won’t have to track the volatile core-updates.
<civodul>rekado_: great, thanks a lot for doing that
<civodul>we can tell berlin to build it
<civodul>mbakke: glibc requires bison? bah!
<mbakke>glibc-intermediate was happy with bison-boot0 though, but failed to link some locale specific stuff
<bavier`>davexunit: just saw you're presenting Guix at Libreplanet!
<civodul>oh! awesome!
<civodul>mbakke: terrible, i don't see where that comes from :-/
<mbakke>rekado_: I built python-{pytest-bootstrap,py,setuptools_scm,six} with --rounds=2 on 3.6.4 and it worked!
<rekado_>mbakke: thanks for testing.
<mbakke>Awesome stuff :)
<rekado_>unfortunately, Python itself still doesn’t build reproducibly, but I don’t know why.
<civodul>still, quite an achievement already
<rekado_>packages like multiqc also have lots of weird pyc differences.
<rekado_>yeah, I’m happy that we could at least get rid of the timestamps.
<civodul>for 2.7 ISTR that the patch to clear timestamps would work for (some) python2 packages, but not for python itself
<mbakke>Let's revisit the remainder after Python 3.7.
<rekado_>civodul: for rhel6 to be built only for x86_64 I’m doing this:
<rekado_>insert into specifications values ('rhel6', '', '.', 'build-aux/cuirass/gnu-system.scm', 'cuirass-jobs', '((subset . "all") (systems "x86_64-linux"))', 'rhel6', NULL, NULL, 1);
<civodul>rekado_: yep
<civodul>did you know that SQL was intended as a user interface?
<civodul>hence the English-style sentences
<civodul>see? :-)
<rekado_>I already feel better :)
<civodul>good :-)
<civodul>it's the COBOL of databases in that sense
<mbakke>efraim: I pushed Python 3.6.4 to core-updates.
<civodul>BTW, while discussing with a colleague of mine, i came up with a crazy for Cuirass: using Git as the database
<civodul>each commit would contain an evaluation
<efraim>mbakke: I'll try it out in an hour or so when I get home
<civodul>each evaluation would contain a set of builds
<civodul>so instead of fiddling with the HTTP interface to the DB, you could git clone that thing to inspect the state of things
<efraim>Would it be possible to see the timestamps so that groups of patches wouldn't trigger many different unwanted evaluations
<civodul>yes, though i think that's already the case no?
<efraim>I was thinking it would read guix's git and evaluate every commit
<efraim>So a commit for each successful or unsuccessful build then
<civodul>that would be like now, which is that it polls regularly
<jonsger[m]>civodul: that's kind of what I did at suse for cloudfoundry. I didn't like the idea so much ^^
<civodul>jonsger[m]: oh really?
<mbakke>Hmm I'm getting the "No code for module (system repl debug)" consistently on one machine.
<mbakke>Yet, a different user is fine.
<civodul>mbakke: the message says "Compiling with Guile 2.2.3"?
<mbakke>civodul: Indeed.
<nckx>Updating my FreeBSD machines is always a moment to be thankful for Guix.
<mbakke>nckx: Are you working on porting? :P
<civodul>mbakke: ok
<nckx>mbakke: (un?)fortunately not.
<mbakke>Guix/kFreeBSD would be amazing (or OpenBSD).
<mbakke>Want to buy PF for Linux.
<jonsger[m]>civodul: yeah it's based on the pipeline/build infrastracture of cloudfoundry upstream
<civodul>jonsger[m]: i find it an interesting idea, but perhaps in practice it's inconvenient, dunno
<rekado_>mbakke: a different user on the same machine? Is that with guix pull?
<mbakke>rekado_: Yes.
<mbakke>On GuixSD.
<rekado_>civodul: just FYI: I’m seeing some fiber-related exceptions on berlin: “database is locked”. I think that’s nothing new, but you can see it in the cuirass log now.
<rekado_>mbakke: how many cores / how much memory does this machine have?
<rekado_>is the other user also compiling with Guile 2.2.3?
<mbakke>16 cores/64G
<rekado_>you may need to use “--cores=1” :-/
<rekado_>I have to do that too when using “guix pull” on the cluster or the 1TB RAM servers.
<mbakke>The other user also used 2.2.3.
<mbakke>rekado_: After manually updating the ~/.config/guix/latest symlink to that of the "good" user, `guix pull` worked again.
<mbakke>Eh, the reason glibc 2.27 requires bison is for "reproducibility", since it would regenerate intl/plural.c when bison was present...
<mbakke>The function that fails to link with an "undefined reference to _libc_intl_domainname" is about 11 lines and only uses malloc:;a=blob;f=locale/programs/xmalloc.c;hb=refs/heads/release/2.27/master#l54
***tilpner_ is now known as tilpner
<efraim>more 117/118 test failures on aarch64 for tar
<bavier`>efraim: on core-updates?
<efraim>i have to build it a couple of times for it to pass
<efraim>mbakke: no change in python test failures
<bavier`>module circular reference issue on current master
<bavier`>between (gnu system linux-initrd) and (gnu system mapped-devices) it seems
<bavier`>I ultimately get a "ERROR: no binding `check-device-initrd-modules' in module (gnu system linux-initrd)" after `make clean-go && make`
<bavier`>maybe a result of ca23693d280de5c4031058da4d3041d830080484
<bavier`>now an error in gnu/tests/base.scm
***xetver1 is now known as xetver
<civodul>bavier`: what error?
<bavier`>civodul: ice-9/eval.scm:387:11: In procedure mapped-device-target: Wrong type argument: #<<file-system> device: "my-root" title: label mount-point: "/" type: "ext4" flags: () options: #f mount?: #t needed-for-boot?: #f check?: #t create-mount-point?: #f dependencies: () location\\
<bavier`>: ((line . 209) (column . 24) (filename . "gnu/tests.scm"))>
<bavier`>this is after I removed the '#:select' on (gnu system linux-initrd) in gnu/system/mapped-devices.scm
<civodul>why did you remove #:select? you had another error before?
<bavier`>civodul: yes, it seemed like a circular module dependency
<bavier`>error that is
<civodul>oh i see
<bavier`>after a 'make clean-go && make' on current master
<bavier`>I've only tried on this one machine though
<Rukako>civodul: h-hi, may I pm you?
<bavier`>and haven't checked hydra's status yet
<bavier`>ACTION needs to go afk for a bit, will check again later on a different machine
<civodul>bavier`: i'm preparing a fix
<bavier`>civodul: ah, ok, thanks!
<civodul>Rukako: i'll leave hopefully shortly :-/
<civodul>i guess we're not in the same TZ
<Rukako>I am in UTC, it's just that I have messed up my sleep cycle ;-;
<Rukako>hopefully I can get you tomorrow, good night!
<civodul>Rukako: heheh, i see :-)
<civodul>well hopefully we'll talk tomorrow
<civodul>bavier`: should be fixed now