<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>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 <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>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 <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 <rekado>looks like libtool fails to build on core-updates <efraim>civodul: other other overdrive just turns on when its plugged into the wall? <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 see it now, the silverish part between the VCR door and the lights <mbakke>Hmm, changing godot argumens don't seem to rebuild the package. <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: Makefile.inc FAILED (old-ltdl-iface.at:134) <civodul>ok, i'm still building guile on core-updates so i don't have the test-suite.log yet <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`. <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 <sturm>mbakke: yay, that did the trick thank you! <rekado>these files exist: /tmp/guix-build-libtool-2.4.6.drv-0/libtool-2.4.6/libltdl/.libs/libltdlc.la <rekado>/tmp/guix-build-libtool-2.4.6.drv-0/libtool-2.4.6/libltdl/libltdlc.la <rekado>but not the expected ltdl/libltdlc.la ***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 <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. <efraim>mbakke: if you do get it built ping me and I'll check it on aarch64 for test failures <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>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. <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 setup.py. <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>-36m-x86_64-linux-gnu.so: undefined symbol: crypt <mbakke>*** WARNING: renaming "_ctypes" since importing it failed: build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so: cannot open shared object file: No such file or directory <mbakke>rekado_: The fix for kernels < 4.5 is part of 3.6.4, so I'll include test_socket.py again. <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_>that’s going to be a world rebuilding change, though. <mbakke>That's okay, we still need the GCC fix. <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>/* 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 may have missed other phases not called 'bootstrap, as was the case for cunit <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. <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' <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 <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>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_>unfortunately, Python itself still doesn’t build reproducibly, but I don’t know why. <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: <civodul>did you know that SQL was intended as a user interface? <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 <mbakke>Hmm I'm getting the "No code for module (system repl debug)" consistently on one machine. <civodul>mbakke: the message says "Compiling with Guile 2.2.3"? <nckx>Updating my FreeBSD machines is always a moment to be thankful for Guix. <mbakke>nckx: Are you working on porting? :P <nckx>mbakke: (un?)fortunately not. <mbakke>Guix/kFreeBSD would be amazing (or OpenBSD). <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? <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? <rekado_>I have to do that too when using “guix pull” on the cluster or the 1TB RAM servers. <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... ***tilpner_ is now known as tilpner
<efraim>more 117/118 test failures on aarch64 for tar <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 ***xetver1 is now known as xetver
<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`>after a 'make clean-go && make' on current master <bavier`>I've only tried on this one machine though <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>Rukako: i'll leave hopefully shortly :-/ <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!