<rcm>Hi All, my "guix system reconfigure /etc/config.scm" command finished evaluating and the problems I was having earlier with locale's went away. However, before the command finished it gave the following: "guix system: error: exception caught while executing 'start' on service 'term-auto': ERROR: find-long-options: unbound variable" <rcm>As far as I can tell, everything is working fine. Should these messages concern me? <CompanionCube>ACTION got around to seeing if flipping the symlink would make Guix work again for non-root <CompanionCube>(to be precise, guix pull: error: could not find bootstrap binary 'guile-2.0.9.tar.xz' for system 'x86_64-linux') <risci>I am trying to install guix sd. After running `guix system init \\mnt\\etc\\config.scm \\mnt` I get an error "10 (primitive-load "/GNU/store/jsc9...."). Any clues? <risci>It says at line 1452:12 of guix/UI.scm "9 (run-guix-command _ . _)" <risci>And the file in question reads "(if directory <risci>(scandir directory dot-scm?) <risci>I think there's an error here, and not sure even if I fix it how do I compile guix from source <marusich>risci, do you get more output (e.g., a full stack trace) if you run "guix system" with the "--on-error=backtrace" option. <marusich>Details about that option are described in the manual (run 'info "(guix) Invoking guix system"' to view it from the terminal) <rekado_>unfortunately, there are still problems with “guix environment -l” and grafts. <efraim>risci: can i post your config here too? maybe someone else will spot something quickly <zero21>is it gonna be hard to package amarok if i never done anything like that before and have little experience with gnu/linux? <risci>Wait, how do you know it's me? <efraim>lucky guess, saw your question on irc about the same time I saw the bug <catonano>I econigured my system and all of a sudden there's no code ofr the modle (ice-9 readline) <catonano>I ReconFigured my system and all of a sudden there's no code for the module (ice-9 readline) <civodul>catonano: try "guix package -i guile-readline" <efraim>i think I have a working enlightenment service <rekado_>civodul: it seems that there are still problems with the glibc graft in the context of “guix environment -l”. <rekado_>so while there was a problem with simply not applying the graft in the first place, even after the fix “guix environment -l” produces an environment with the original ungrafted glibc’s binaries. <rekado_>the easiest fix here is to make “guix environment” only install direct transitive inputs, not the whole package closure. <rekado_>that would leave glibc’s binaries (like “ldd”) out of the environment. <civodul>rekado_: ok, though i still don't get why the ungrafted libc ends up here <rekado_>other grafts make it into that environment just fine <rekado_>I suspect that it’s build system packages that are somehow exempt. <mbakke>On staging, anything that uses GTK is now "unsupported" on ARM. <mbakke>Because GTK requires json-glib, which uses meson-build-system, which for some reason uses patchelf (which currently fails on ARM). <mbakke>I suppose we can try to update patchelf to 0.9. <rekado_>mbakke: I tried that some time ago, but it fails some tests. <rekado_>why does the meson-build-system require patchelf? <mbakke>I don't know, it calls `patchelf --shrink-rpath` for whatever reason. <civodul>unfortunately we never got an answer as to where these extra entries come from <roptat>hi, I'm trying to compile a package that requires gcc>=7.2 <roptat>but when I add gcc-7 as an input, I get this error message during compilation: <roptat>/gnu/store/a4vwdk8r6p6l2mnffz4yaqlr1z6z6w3r-gcc-7.3.0/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or directory <mbakke>roptat: I've been meaning to file a bug for that, GCC6 has the same problem. It's an upstream issue. <mbakke>The problem is that C_INCLUDE_PATH does not work when -Isystem is passed IIRC. I'll try to find the bug. <civodul>mbakke: but we build linux-libre with gcc@7 as an additional input and that works fine <civodul>oh maybe that's because it's a bare-bones build (no libc)? <mbakke>civodul: IIRC the problem occurs when including headers from C(PLUS)_INCLUDE_PATH, Linux-Libre does not have a lot of dependencies. <civodul>roptat: perhaps you can work around it by setting CPATH=C_INCLUDE_PATH <mbakke>roptat: Can you try to patch the package to not pass `-isystem` to GCC? <civodul>we don't do -isystem, but C*_INCLUDE_PATH is equivalent to -isystem <civodul>whereas CPATH is supposed to be equivalent to -I <civodul>back then we changed from CPATH to C_INCLUDE_PATH precisely for the warning behavior <mbakke>civodul: So as a workaround, we could go back to using CPATH instead of C_INCLUDE_PATH? <mbakke>roptat: Can you try adding a phase that does something like `(setenv "CPATH" (getenv "C_INCLUDE_PATH")) (unsetenv "C_INCLUDE_PATH")`? <efraim>What was the other one that causes tons of issues for arm? Was it libunwind? <mbakke>Any ideas what to do with the patchelf situation on ARM/staging? <efraim>Disable tests and see if it still works? I think someone with arm access will have to do some of the testing to see what works/is good enough <efraim>'loginctl reboot' works, I think I'll change enlightenment's system actions to use loginctl <mbakke>Bah, ceph consistently fails on armhf....after 16 hours of building. <rekado_>mbakke: could we only use patchelf when the system is non ARM? <mbakke>rekado_: I suppose, as a workaround... Hopefully it can be done without changing the derivations for other platforms. <mbakke>I'll give it a go and send a patch. <mbakke>I'm going to try and bisect the binutils >=2.29 issue. There are over 500 commits on the ld and bfd folders between 2.28 and 2.29. <mbakke>I'm getting a syntax error when trying to splice a conditional into a modify-phases expression. <efraim>ls -L /run/setuid-programs/ to see which they're symlinked to? <efraim>I think there's one in omvf, or whatever that firmware is called <mbakke>efraim: Thanks. The issue is that the (define %standard-phases ...) in meson-build-system.scm is not quoted. <mbakke>It also does not have access to (guix utils) for %current-target-system. <civodul>mbakke: in gnu-build-system we pass #:target to the phases, which is either #f or the target triplet when cross-compiling <civodul>mbakke: re binutils, bonus point if you write "guix bisect" :-) <mbakke>binutils is somewhat special, since I need to override (source ...) of binutils-boot0, and also run autoreconf on the git repository. But `guix bisect` would be nice indeed :) <civodul>you could (package (inherit binutils) (name "binutils-under-test") ...) <civodul>to avoid rebuilding the whole shebang <mbakke>I'm not able to add a conditional for armhf in the meson builder without changing the derivations. <mbakke>Which on staging means ~900 rebuilds. <civodul>mbakke: notice that the result of 'system*' is ignored, so you could also simply remove patchelf on ARM <mbakke>I just noticed patchelf is an implicit input too, so just dropping the 'fix-runpath' phase is insufficient. <civodul>but then we have those extra entries in RUNPATH, right? <mbakke>civodul: If only it was just that, dropping patchelf actually causes 'validate-runpath' to fail! <mbakke>Yes. It's actually missing its own libdir in RUNPATH (testing with json-glib on staging). <mbakke>It seems meson-build-system relies on augment-rpath as well. <mbakke>Maybe it's time to write a Guile patchelf.. :-) <civodul>well, we have everything we need to do it :-) <civodul>namely, 'dynamic-entries' in (guix build gremlin) knows where the DT_RUNPATH entry lives <mbakke>The docstring of 'fix-runpath' says the extra RUNPATH entries come from libraries that are e.g. only used for tests. I wonder if that is really meson-specific. <mbakke>efraim: It also relies on patchelf to set up RUNPATH, not just shrinking it. <rekado_>that grafts problem is really just a problem with R, it seems. <rekado_>“r-minimal” retains a reference to /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c and /gnu/store/hrhxx37z97j7pniyr437illc0b5qq9pa-glibc-2.26.105-g0890d5379c-static <rekado_>I would think that the static variant is not grafted. <rekado_>when using “guix environment -l” that variant’s binaries end up in the environment. <rekado_>even with “guix environment --ad-hoc” this is a problem, though <rekado_>because some parts of R will use the ungrafted glibc to perform certain tasks <civodul>rekado_: so how can i reproduce it? "guix environment --ad-hoc r-minimal"? <rekado_>I don’t know yet; I’m looking at the binary now to figure out where that reference comes from. <rekado_>I still think that non-“--ad-hoc” variants of “guix environment” have an odd behaviour; but that’s tangential to the actual problem. <civodul>ACTION still working on kernel module load, which turns out to take more time than expected <rekado_>I see a reference to the *same* glibc in “hello” <rekado_>its bin/ldd binary fails with “FATAL: kernel too old”. <civodul>rekado_: ldd is a shell script, and it uses bash-static in its shebang <civodul>by definition bash-static cannot be grafted, hence the failure <rekado_>well, I wonder if R might be using ldd internally <rekado_>ACTION unpacks the code for r-minimal <civodul>regardless, in glibc-final we should arrange to fix ldd <rekado_>according to strace, R ends up calling "/gnu/store/05dvazr5wfh7lxx4zi54zfqnx6ha8vxr-bash-static-4.4.12/bin/bash" as a shell to execute “rm -rf /tmp/Rtmp…” <rekado_>and that’s what causes the error to surface <efraim>I think I need to register enlightenment's screen locker as a screen lock util <rekado_>R uses bash-static because it calls stdlib’s “system”. So this can only be fixed by changing the bash-static that is given to glibc-final. <civodul>no, we can arrange so that only glibc-2.26-patch is rebuilt <civodul>so we need need a glibc-final-with-bootstrap-bash that includes the patch <civodul>and use that to build the fixed bash-static <mbakke>How does gnu-build-system set up RUNPATH for outputs? The ld wrapper typically doesn't know the output location at link-time? <mbakke>I see cmake-build-system adds "out/lib" to RUNPATH as an argument, so it should be OK for meson. <mbakke>Still curious about how gnu-build-system does it though. <civodul>mbakke: for gnu-build-system there are two possibilities <civodul>1. if libtool is used, it does the right thing, i.e., it passes -Wl,-rpath=... <civodul>2. in other cases, ld-wrapper expands "-lfoo" to "-Wl,-rpath=... -lfoo" <civodul>the latter applies to all build systems <civodul>you can set GUIX_LD_WRAPPER_DEBUG=yes to see what's happening <rekado_>one annoying difference in two builds of r-minimal: “"John M. Chambers (2008)\\n``Software for Data Analysis: Programming with R''; Springer NY."” –> “"John M. Chambers (2008) ``Software for Data Analysis:\\nProgramming with R''; Springer NY."” <mbakke>civodul: thanks! Didn't realize it was libtool pulling the strings. Will send a patch series for meson shortly -- although it causes ~900 rebuilds :/ <civodul>rekado_: non-deterministic paragraph filling?! <Sleep_Walker>guix system: error: open-file: No such file or directory: "/run/booted-system/kernel/lib/modules/4.15.6-1-default/modules.alias" <Sleep_Walker>where 4.15.6-1-default is kernel version I use on system (and is not in store) <civodul>Sleep_Walker: that's a recent regression <civodul>essentially, 'guix system init' now attempts to determine whether your OS config lacks modules in its initrd <civodul>that's what's reading "modules.alias" <Sleep_Walker>(dependencies are on the way to Factory; when guile 2.2 is reenabled, guix can follow quickly) <rekado_>g_bor: when closing bugs could you please try to keep the subject line intact? That makes it a bit easier for others to see what bug has been closed (without having to check the bug tracker). <g_bor>rekado: Yes, of course. Sorry for the confusion. <g_bor>The jeromq pull request was merged today, so we can drop the patch on 0.4.4. <rekado_>does this mean we should upgrade jeromq? <g_bor>I keep tracking it, and upgrade as soon as possible <rekado_>but that’s good anyway; we can be more confident about adding the patch then. <rekado_>you’ve already sent a patch to the list, right? <g_bor>Yes, and also an updated version mentioning the upstream status, the pull request number, and that it will be merged soon. Should I send an updated one mentioning it is already merged? <rekado_>g_bor: that would be very nice. I’d merge your patch right away. ***loonquawl_ is now known as loonquawl
<g_bor>I have an issue with one of the java packages. It basically uses gradle, and the test resources are 'included', and not under the java directory structure. What would be the easiest way to solve that? <rekado_>g_bor: in other packages I’ve often had to move the resources to the classes directory <rekado_>we do this in java-fasterxml-jackson-core, for example <g_bor>Ok, I will check that approach. <g_bor>I have sent an updated patch. <g_bor>Is there a way to subscribe to a specific bug? <rekado_>when you create the bug you are automatically subscribed, I think <g_bor>I've asked this, as it seems that I sometimes miss messages, and resolving issues get delayed that way. <g_bor>It seems to me that usually it depends on the others using answer to all in their mail. <g_bor>I've found a two line pull request for java-simple-xml, it dates to 2016, and most probably solves the java8 test failures. I guess we should apply this. <g_bor>Latest commit on the codebase was in 2015. <g_bor>Thanks, I will do that then. I'm now reviewing my work on the java updates so far, an it seems that almost all issues are solved. <g_bor>I guess I can submit the patches next week for final review.