<rekado_>civodul: for “guix pack -RR” it would be nice to have it produce an executable; unpacking a tarball could become unnecessary.
<rekado_>e.g. a wrapper around a squashfs image, which mounts the image
<avalenn>this seems to be the AppImage approach. executable file wrap around a FS.
<apteryx>have others used Vagrant before? It's like Docker but for VM. It's able to quickly fetch and setup a VM and provide some Ruby-based DSL to provision it. Seems it'd be nifty to test our guix-install.sh script on an array of systems.
<apteryx>with the vagrant-libvirt service it can apparently use qemu/kvm
<roptat>I mean, you can certainly build both together, and that's maybe simpler, but from what you're explaining, there's a plugin system, so it's better to have one package for the program alone, and one package for each plugin, then use an environment variable to let the program know where its plugins are
<roptat>then users can install the program and chose which plugins they want or not
<roptat>to me, it sounds slightly easier to build two packages normally than have to write a new phase to decompress the second source archive, and that might not be accepted through review, unless you have a good reason to do so
<roptat>like, icedtea is made of different source repositories, and none of them really make sense to build alone (or even depend on each other), so we build them all in a single package, that's a good reason, because that's what's expected
<roptat>but in general, we try not to bundle packages together
<roptat>then again I don't know what you're packaging, so maybe there's really no choice but to build them together, it's up to you to decide which way is better for this package :)
<wonko7>well it's for elasticsearch & a plugin I need, but that won't be accepted anyway because I'm not building from source. I get your point though, but I'm learning and hacking stuff together right now :)
<tissevert>roptat: still the same failures in fedoraproject.org for the translation
<tissevert>AFAICT their registration system is currently broken (password reset yields a 500, registering a new user doesn't work, the password just set doesn't let one in)
<tissevert>their error messages aren't very useful it's just «bad credentials», which is a bit unhelpful for something you just copy-pasted ^^
<tissevert>for all I know they could handle mail adresses with a '+' in them badly
<tissevert>they apparently have a «unique mail adress» policy that prevents creating several accounts with the same adress (but the sign up form will still display a warning about the username, as if that part was already taken, which I doubt very much for a 16-long randomly generated username, and even more for 3 of them in a row)
<roptat>tissevert, can you describe the steps you took when registering your account?
<tissevert>that's what I was attempting to do in the previous lines, sorry ^^
<tissevert>do you want a more formal account ? I could send it to you on the fediverse to avoid spamming this chan even more
<roptat>just describe what you did, not what you think happened
<andreas-e>Then things become messy, and the emacs wizards will probably be able to tell you what to do... (I usually start with a fresh branch from master and cherry-pick from my conflicting branch, but I am not working on complex branches such as wip-gnome.)
<iskarian>efraim, while you're around: in your gccgo > go patch from a few years ago, you suggest that go wants to be built with the gcc from the gccgo build... do you recall where you found that info (or, by trial & error)?
<efraim>Oh yeah, I meant to write back when I got back to my computer
<efraim>That was a plan for getting go working on other architectures, apparently now the way is to either use gccgo itself or to use go with gccgo as the backend
<raghavgururajan>For some reason, latest gtkmm depends on older versions of cairomm, atkmm, pangomm
<leoprikler>is it strictly incompatible with newer ones? If so, we might want to hold cairomm atkmm and pangomm back
<nckx>raghavgururajan: If all that is true, what a mess you have to package...
<raghavgururajan>Yeah, strictly. I tried dirty hack of patching meson.build of gtkmm, to refer to latest versions of cairomm, atkmm, pangomm. Though, 'configure phase passes, 'build phase fails with *numerous* errors.
<iskarian>I've been wondering... why is it the status quo that everything on guix seems to be dynamically linked to libgcc_s.so? Is it because we expect gcc to always be installed anyway?
<nckx>raghavgururajan: Thanks for psychically answering my deleted question in detail, please continue doing so. Anyway: the other approach is to avoid propagation. I know the G-stack is a brittle mess but could we carve out a tiny island of unpropagated sanity just for this bit?
<raghavgururajan>> Thanks for psychically answering my deleted question in detail, please continue doing so.
<leoprikler>IOW you created that mess on your own and didn't check whether gtkmm would correctly build?
<leoprikler>wait a sec, if you build gtkmm against older atkmm, but then inside another package use old gtkmm + new atkmm, what happens?
<ruffni>i'm unable to build a package, but in a "pure" environment it builds just fine. it's missing `math.h` even though glibc is an input. is my "pure" env not as pure as i'd hoped? did i mess up some of my env vars?
<raghavgururajan>leoprikler: That is something I am confused myself. At that time, gtkmm built fine. Not sure I was building it on wrong branch.
<apteryx>civodul: ah! I just noticed that since the VM images are produced with 'guix system image', they are in *compressed* qcow2 format already. So we don't need to waste time attempting to compress them more with xz! It also makes them easier to use.
<nckx>raghavgururajan: Thanks, please let us know what happened. Also thanks for seeking feedback. I recommend, before pushing commits to one of the three ‘real’ branches (ma/st/c-u), ensuring that building everything listed by ‘guix refresh -l <affected packages>’ does not report any new build failures.
<civodul>apteryx: oh nice! how does the .qcow2.xz compare to the .qcow2?
<civodul>it'd be nice to get rid of xz there as well, more convenient
<civodul>apteryx: excellent! so yeah, let's drop .xz
<civodul>i hope roptat doesn't get mad at us though :-)
<civodul>apteryx: the extra Makefile is going to make things slower though
<civodul>"recursive makefiles considered harmful" and all
<civodul>as long as the warning is harmless, i'd rather keep it
<apteryx>civodul: I reckon the performance cost should be negligible. I think people are more likely to notice the warning than the (miliseconds?) cost of adding one makefile indirection :-)
<civodul>apteryx: i think it's noticeable (first by the number of extra lines printed by "make"), and we'd pay it each time we type "make"
<raghavgururajan>leoprikler, nckx: So libsigc++, glibmm, cairomm, pangomm and atkmm; play well with each other's latest stable version. The gtkmm is the only outlier.
<raghavgururajan>So I think it would be better to either de-propagate them in gtkmm; or use the patch as-is and remove -x.y when new gtkmm version is released. WDYT?
<bone-baboon>When a package build fails it says where to look for the build log. Where should I look for the build log when a package builds successfully?
<civodul>bone-baboon: "guix build --log-file --no-grafts the-package" will tell you where the build log lives
<bone-baboon>civodul: `guix build --log-file --no-grafts glib` says there is no build log. It has a different hash than the glib which was successfully built with `--file`. What should I use for <the-package> in `guix build --log-file --no-grafts <the-package>` for a package that was built with `--file`?
<lambdanon>Figured out how to solve my problem with foreign libraries in SBCL: (push #P"~/.guix-profile/lib/" cffi:*foreign-library-directories*)
<raghavgururajan>nckx: I just realized packages that depend on gtkmm, doesn't propagate it. So only way gtkmm, ends up in user-profiles is when explicitly installed.
<bone-baboon>nckx: That does not working for me. However I think there is enough information that I can get from my terminal scroll back. I will try sharing that and see if it is sufficient.
<ruffni>my build first does: "g++ -o fluxa/src/Sample.o [...]" and little later complains: "scons: *** [fluxa/src/Sample.o] sh: No such file or directory". does the guix build process do anything funny to .. object files? i'm sincerely puzzled
<leoprikler>raghavgururajan: I think the question is whether you can mix gtkmm and atkmm for packages even when building gtkmm against another atkmm
<leoprikler>if you can link against arbitrary atkmm, then not propagating should be fine
<raghavgururajan>leoprikler: Ah. I think that won't be an issue. If package abc depends on both gtkmm (latest) and atkmm (latest), we'll be adding both in the inputs. The pkg-config finds the correct version of atkmm as both version will be made available.
<nckx>bone-baboon: That's odd... it works here. It requires you to've built glib locally, but if you're copying build output from your scrollback I assume you've done so.
<nckx>bone-baboon: ‘Navigate’ gives me pause (visions of buggy graphical file managers etc.), but if something like ‘bzless <full file name>.bz2’ doesn't work, that's a bug!
<nckx>If ‘guix build --log-file’ prints something, that something must exist.
<nckx>For example by transparently downloading it from the build farm first.
<bone-baboon>nckx: No graphical file manager here. I am using Emacs on a virtual terminal. When I do `C-x C-f` and try to tab complete to the location of the log I only get to /tmp/log/guix/drvs/ and then there is no match with tab completion. I double checked looking for the logs directory in /tmp/log/guix/drvs/ using Dired but it is not there (even after a buffer refresh with g). I triple checked with `ansi-term` the log file direct
<bone-baboon>there. However taking the entire location of the log from the output and pasting that into the prompt for `C-x C-f` opens the log.
<bone-baboon>nckx: On the computer in question with `C-x C-f` tab completion works up to /var/log/guix/drvs/ then when I type in 21 the next directory in the path to the log and press tab it says [No Match] in the minibuffer.