<lane>Q: I've finally gotten the project I'm packaging to build, but the built executable doesn't have the correct RUNPATH. I found the place in the Makefile where RUNPATH is set, so I know I can use `substitute*` to change it to the correct value before building. What I'm not sure about is how I should be setting the path. The executable depends on `.so` files from its inputs. Does this mean those libraries need to be propagated-inputs?
<efraim>lane: I'd do a grep through the code for 'rpath', adding (string-append "LDFLAGS=-Wl,-rpath=" %output "/lib") to configure-flags might be enough
<lane>efraim: Thanks, I tried that but it didn't seem to work- maybe it would if I had the libs as propagated inputs...
<maav>lane: IIUC, these shouldn't need to be propagated inputs, but I think you'll need to add "-Wl,-rpath=" (assoc-ref %build-inputs "otherlib") "/lib" to LDFLAGS too
<maav>being otherlib the dependency you have to add to the runtime library path
<maav>lane: or substituting the Makefile if providing LDFLAGS to the configure script isn't an option, of course
<wehlutyk>after a `git pull` on my guix checkout, on master, I `./bootstrap` and `./configure --localstatedir=/var` then `SHELL=$(which bash) make check` (otherwise my shell being fish some tests fail), I'm hitting a `failed to load 'guix/scripts/system/reconfigure.scm'` error, followed by `ice-9/eval.scm:293:34: In procedure allocate-struct: Wrong number of initializers when instantiating #<record-type <gexp>>`. Does this ring a bell?
<mange>Is there an easy way to build a disk-image that embeds the current Guix version after a "guix pull"? I've noticed that we have current-guix in (gnu packages package-management), but it doesn't seem to work from a "guix pull" (the documentation around it implies that it needs to be run in a source checkout). Presumably I could write my own package definition to get the "source" from... somewhere?
<efraim>bumping qt is a major undertaking, it'll take a bit
*civodul just fixed an embarrasing thinko in 'version-1.2.0'
<civodul>mange: no really "easy" way, but i'd like to support that
<civodul>it's probably safer but then we need people to actually test it
<lane>Hmm, I'm working on submitting my first patch to add a package, and `./pre-inst-env guix lint mypackage` is failing with `error: define-json-mapping: unbound variable`. Anyone run into this before?
<nckx>‘Tip: download during off-peak hours.’ Great idea, I'll schedule meetings at 2am now, thanks.
<nckx>‘[A]ccording to N. Decaro and A. Lorusso in Veterinary Microbiology (May 2020), "Novel Human Coronavirus (SARS-CoV-2): A Lesson from Animal Coronaviruses", pigeons are not known carriers of COVID-19’
<maav>i just tried too and it's working on my pc too
<nckx>guile-json@4 is also in Guix's closure. I'm not sure what's up. civodul?
<lane>hmmm. haha I guess it couldn't hurt to try restarting. Be back in a minute
<nckx>sneek: Later ask lane: So to be clear, I can run ‘guix environment --pure guix -- ./pre-inst-env guix lint dear-imgui’ without issue (assuming it ever finishes fetching CVEs at this pace :-/ ). What are you running?
<divoplade>Hi! I'm testing my service definition by creating an operating-system definition with just that service (and the required fields), then create a docker-image of that system, start it and run bash as described in "invoking guix system". But, if I run herd status, my service is not listed.
*nckx waits patiently while individual commits are flown in per pigeon.
<divoplade>So it works with the older commit 71456036de246694b393a6697af0c73d0901b65d, trying branch version-1.2.0...
<nckx>civodul: When you return from the sun, it looks like 37b98e8 needs to make it to master somehow.
<maav>divoplade: the problem seems to be introduced by 977eb5d023
<lane>yet another question: I'm working on packaging something that includes a command line utility which is installed in `out/bin`. I was expecting that if I do `./pre-inst-env guix environment --pure mypackage` then I would be able to execute it, but that doesn't seem to be the case
<nckx>lane: You need --ad-hoc mypackage to include mypackage itself, not it's build inputs.
<zimoun>the download/latest about Hurd Binary return 502, is it expected?
<divoplade>OK I confirm the problem is fixed in version-1.2.0
<nckx>What's supposed to be listening on berlin's localhost:8081?
<nckx>zimoun: The problem is in cuirass-web, which returns an empty reply for both /download/1385 and /download/1450 (latest binary tarball & Hurd qcow2), but not for /download/1692 (latest Guix System).
<zimoun>civodul: I am almost sure it is fixable because IMHO the current design (static offload) and huge store to GC (with deduplication I guess) does not scale. Now we know :-) I really hope for fruitful discussions on this area in the 2 sessions: Fix the CI and Coordianator.
<jonsger>are mesa updates happening nowadays on core-updates or staging? It has 2k deps
<zimoun>civodul: sometimes the substitutes are available on Bayfront, does it make sense to fallback before trying to build locally from source?
<nckx>jayspeer: Ideally, if the patch is hosted somewhere stable on the 'net, you add a PATCHES field to SOURCE, with an ORIGIN field that points to it. Otherwise, it might be appropriate to ship the patch with Guix (in gnu/packages/patches) and using SEARCH-PATCHES.
<nckx>It depends a bit on the size & nature of the patch.
<nckx>zimoun: What do you mean by ‘IO issue’? It's not fs damage, just that (apparently) Cuirass didn't create a GC root (or deleted it too soon), so the GC cron job deleted the images before their time.
<nckx>divoplade: Could you share the list of what's being downloaded? I want to make sure it looks sane.
<jayspeer>nckx: since the patching is the straightforward part of the thing I'm trying to accomplish, let me share you some links which explain what I need to do
<civodul>zimoun: what would fall back to what? :-)
<jayspeer>my first thought was to add another build phase, which adds and applies this patch. But after second thought, I've came to the conclusion that it might be stupid, given what guix is trying to accomplish
<samplet>Hooray! My local Cuirass is building Disarchive metadata. It’s even using the Scheme interface via “with-extensions”. :)
<cbaines>adding bayfront might be nice, although the downside is that checking for substitutes and not finding any does have a cost (in time)
<nckx>I think what you mean is that Guix will trust a positive (‘I have that’) narinfo response, and fail hard if the server can't serve it, without falling back to the next server in the substitute-urls list?
<cbaines>and bayfront has even worse substitute availability than ci.guix.gnu.org
<nckx>Or do you mean that bayfront should come as a default out of the box?
<civodul>vagrantc: thanks for the reminder, done! :-)
<civodul>apparently "git push" alone doesn't cut it
<civodul>i do that through Magit though, maybe it does something special, dunno
<Rovanion>Is there a guix equivalent of nix-shell or python viirtualenvs? That is: a tool which allows you to download and activate a virtual shell environment with the packages needed to develop some piece of software without polluting the user or system environment.
*vagrantc hopes to add armhf to the successful builds of guix in Debian
<civodul>email sent, upload is still running but almost done
<nckx>*lfam just pauses for a minute to increase tension*
<lfam>I don't use `guix edit` so I can't speak to its relevance here. But usually when `./pre-inst-env` stops working for me, it's when I've garbage collected the build dependencies and failed to rebuild my Git tree
<lfam>The result is that guix falls back to using its default — i.e. ~/.config/guix/current
<jayspeer>I haven't gced today, and this is clean state source tree - I've just redownloaded it
<lfam>So, try creating a Guix development environment and re-running `./configure --localstatedir=/var && make`
<nckx><run `./bootstrap` and `./configure --localstatedir=/var` and then `./pre-inst-env guix build nqc`>
<nckx>Meh. The manual telling you to run ‘make && make check’ instead of the 100% equivalent ‘make check’ is only helpful if you're sneakily planning on skipping ‘make check’.
<lfam>The second chapter implicitly depends on the first because you only get the `./pre-inst-env` script by following the instructions of the first
<jayspeer>who never skipped checks, be the first to stone me :)
<lfam>Well... people don't know that `make check` includes compiling
<lfam>And I run `make` almost every day but almost never run `make check`
<lfam>I'd describe `make && make check` as an "affordance" to user-friendliness :)
<lfam>And even though it would be redundant... it's not as redundant as explaining it on IRC
<nckx>If they don't know what it includes they shouldn't skip it. Anyway, I don't like this ‘humans are lazy, but it's documentation that doesn't pander to them that is flawed, not them’ trend but it's not going to change any minds ☺
<nckx>Clearly it's in our own self-interest to do so.
<jayspeer>the first problem with tools is that their built for human in first place :(
<lfam>I think that updating documentation is a band-aid. The ideal solution is to make it so that it doesn't require documentation
<lfam>What about making pre-inst-env more robust? What exactly could it check for?
<lfam>The failure case you get after `guix gc` is not great
<nckx>lfam: I don't know. What's the failure case now? I don't tend to run into them. I suspect most of the folks who could be annoyed into fixing the current tools don't.
<ngz>Hello. I just packaged axel, which is a so-called download accelerator. I'm wondering in what file it could go. AFAIK, it doesn't handle bittorrent, bittorrent.scm is not appropriate. So, would you have any idea?
<jayspeer>IMO the only problem with the first chapter is that it never implies the `make` as a necessary step of the setup. `make check` implies this is just for tests and the chapter refers to hacking on guix directly - so if one just wants to add/update a package definition, one will think that this step is not necessary
<lfam>nckx: If you have a working development environment and garbage collect it, the pre-inst-env script will "silently" begin using ~/.config/config/guix/current, and so you won't actually be testing your changes in the Git repo. Depending on what you are testing, this can be really confusing
<lfam>jayspeer: I understand your point of view jayspeer. Like I said, I don't run the test suite often. But everything in the directions is mandatory :)
<jayspeer>`make` finished and my package finally failed to build! what an astounding success :) thanks for the support
<lfam>That's why it says "you *have* to invoke make check" :)
<nckx>jayspeer: Ah, think I see what you mean now. Hacking on package definitions *is* hacking on Guix (there is no Guixpkgs, no ‘Guix package repo’), the two are intertwingled, but as (I think) lfam mentioned above it's not common knowledge.
<lfam>I'm actually not sure exactly what 'pre-inst-env' falls back to after dev dependencies are garbage collected. It may fall back to the already-built .go files in the Git repo. In any case, it fails to warn that code changes are no longer effective
<lfam>Well, it's a developer tool for developers and not a first-class part of Guix, but it would still be nice to avoid this
<jayspeer>nckx: I've interpreted *hacking on Guix* as playing around with like `deploy` and `system`. Comparing packages to those seem like "library vs variable" if you get what I'm getting at.
<nckx>lfam: Oh wow, that is extremely surprising. I promise I would have stomped off to fix it if it had happened to me even once.
<civodul>vagrantc: yes, alpha.gnu.org is meant for pre-releases
<lfam>It's all-in-one jayspeer. Like the Linux kernel integrating drivers and core, we do it all in the same codebase
<jayspeer>lfam: still, I don't expect having to run test for the whole kernel, after adding a variable somewhere
<lfam>It happens to me after every `guix gc` nckx. I've learned to follow gc with a `./configure && make`
<nckx>jayspeer: Absolutely. It's just so obvious to long-time users that it took me a moment to realise what you meant.
<lane>Can anyone here help with an issue regarding shared libraries?
<ngz>nckx: would a reproducer be : modify some package 'foo'; guix environment guix; guix gc; ./pre-inst-env guix build foo <-- silently builds unmodified foo. I didn't test it because "recovering" from a guix gc takes ages.
<jayspeer>nckx: I'm getting the same error without any patches at all :(
<lane>haha ok, I'll try: For some context, I'm trying to package openFrameworks, a fairly popular framework for creative coding in C++. It basically just glues a ton of libraries together and provides a more unified interface that's a bit more newbie friendly. My goal is to eventually use it as a way to teach Guile/Guix, but for now I'm just trying to package it for Guix. Currently, it's successfully built by Guix, but there's still some
<lane>issues. Part of the installation is a "project generator" which uses templates to make a new openFrameworks project (i.e. generating some basic source files and a Makefile). So when I install my package, I can use the project generator and successfully compile the generated project. However, the generated executable crashes immediately, apparently due to missing/mismatched shared libraries. Using `readelf` and `ldd` I get some hints
<lane>about the exact problem, but it's unclear to me how this type of problem can even occur.
<lane>For example, `glew` is a dependency, and according to `readelf` the executable is looking for `libGLEW.so.2.0`, but in the `lib` of my guix profile, only `libGLEW.so`, `libGLEW.so.2.1` and `libGLEW.so.2.1.0` exist
<jayspeer>nckx: sanity check: plain build works (without any changes)
<ngz>nckx: I understand. The thing is I don't know what `which guix' is supposed to return compared to the guix executable from `./pre-inst-env guix'. IOW, I don't understand how to check what changed at this level between before and after the gc. ISTM that `which guix' always return the same thing in both cases.
<lane>I guess I could work around this by creating a symlink from `libGLEW.so.2.0` -> `libGLEW.so` as part of the installation, but it seems like the fact that I'm using the same `glew` during the build process means that the executable should have the correct filename already...
<jayspeer>nckx: huh, I wonder what was wrong in your original attempt
<nckx>jayspeer: Wow, and Guix should cache the patch it once it's downloaded.
<nckx>jayspeer: I don't think the /tarbomb variant (that fails to create compiler/rcx1_nqh.h) is wrong, per se, but that the nqc build system somehow behaves differently when the directory name changes even if the contents are the same.
<jayspeer>nckx: I've played around with this stuff some more, my finding: building normally the patch works, I can talk to the robot with the usb device. Package built with guix doesn't work, seems the patch wasn't applied; trying to find a workaround
<jayspeer>I suspect it's related to combination of these two things: tarbomb download & patch has to be applied from a directory which contains the project directory (so one level bellow)
<nckx>jayspeer: I haven't had time since posting that patch but I suspect it has no effect on the output at all.
<nckx>That does not meet the bar for inclusion in Guix for me.
<jayspeer>sure, I imagine that if you meet anyone in the future who is at the same time using: 1) guix, 2) 20y old lego mindstorms, 3) has multiple serial ports in their machine; then you'll more than glad to patch it up ;) just for the novelty
<nckx>If they write a udev rule to make the symlinking automagic, deal!