<atka>I get guix error: substitute died unexpectedly a few times a week when reconfiguring, I can re-run guix system reconfigure and it will work. when a substitute dies does that failed transaction leave anything behind? garbage collection should clean up that sort of stuff yes?
<Aurora_v_kosmose>Disabling tests isn't an amazing way to fix the build but the upstream situation with regard to its dependencies is a bit weird.
***rekado_ is now known as rekado
<vagrantc>Aurora_v_kosmose: it looks like your revision change isn't quite right, going from revision "2" to revision "0" ... the revision for git commits (unless the base upstream version is also updated) should always increase
<Aurora_v_kosmose>Ah, I had been under the impression revisions were for Guix-side changes between package versions.
<vagrantc>Aurora_v_kosmose: well, the git commit isn't consistently incrementing, so when using git-based versions, you need some sort of incrementer to ensure version updates. i think in this particular case, the git commit version is "newer" in a version-string sense, but you won't want to rely on that
<Aurora_v_kosmose>vagrantc: I now have. "firstname.lastname@example.org: label 'gfortran' does not match package name 'gfortran:lib'" and "email@example.com: label 'glib' does not match package name 'glib:bin'" . That fortran one is most puzzling because as far as "guix search" goes, gfortran doesn't exist as a package at all.
<wdkrnls>I think I just put a paren in the wrong spot.
<vagrantc>Aurora_v_kosmose: i wonder if those are things guix lint could be made smarter about ...
<Aurora_v_kosmose>Possibly, but I don't feel particularly comfortable trying to modify that.
<wdkrnls>I fixed the location of my paren and it sort of finished building. I got a couple of scary warnings though.
<wdkrnls>namely one warning suggests that the kernel debugging systems "could not be upgraded".
<vagrantc>Aurora_v_kosmose: oh, more i was saying i think that's more bugs in guix lint than anything you need to fix :)
<wdkrnls>guix system: warning: exception caught while executing 'start' on service 'file-system-/sys/kernel/debug'
<wdkrnls>Throw to key `match-error' with args `("match" "no matching pattern" ("none" "/sys/kernel/debug" "debugfs" () #f #f #f #t preen))'.
<vagrantc>Aurora_v_kosmose: well, hope that was helpful. heading off now
<kitty1>lilyp: does guix have flags to disable that type of integration? I don't know GNOME but the type of person who would, would probably be the type of person things like firefox being excluded are for.
<tschilptschilp23>This might be a somewhat strange questions -- how would I map something like ~guix shell glade gnunet gnutls gtk libextractor libgcrypt libunique qrencode pkg-config libglade gcc-toolchain make -D gnunet glade~ to a package config regarding inputs, native-inputs, and/org propagated inputs? I'm asking, because this environment seems to let me compile gnunet-gtk, that SuseJdoG mentioned yesterday, in the 'classic' ~./configure
<tschilptschilp23>--prefix=somewhere && make && make check && make install~ way. The produced binaries seem to work more or less. Although probably the most interesting one ~gnunet-fs-gtk~ produces an memory access error when run as user and bails out not finding gtk-icons and/or gdk-pixbuf when run with sudo. Nevertheless configure at least finds the needed gnunet-headers that way.
<tschilptschilp23>the actual shell package list preceding ~-D~ is actually a bit longer, but this probably unsupported/unsuggested way was the only way I managed to make configure see the headers...
<tschilptschilp23>compiling ~gnunet~ itself with the same 'technique' (but without ~-D~) also produces binaries, but these don't compare to the ones packaged in guix in functionality. I guess it's just not meant to be done that way?
<tschilptschilp23>To avoid confusion -- I've tried both the gnunet-gtk sources from git and ftp.gnu.org.
<jpoiret>hmmm, you shouldn't run make install ever
<Basspoon>Hi, I'm new to Guix and was wondering if there's a way to only upgrade packages that have an available substitute when running 'guix upgrade'. I've already added this snippet https://guix.gnu.org/manual/devel/en/guix.html#Channels-with-Substitutes to my channels.scm, but as the manual states, this only stops 'guix pull' from compiling package definitions. Please let me know if this is the wrong place to ask. Thank you.
<civodul>but there's currently no --upgrade-only-if-substitutes-available flag
<civodul>problem is that this could lead to security issues, if you end up running old vulnerable software
<Basspoon>Thanks for your help :) I considered that, but was curious if there was a better way. I guess it doesn't really matter, since I only need to avoid compiling big packages like linux-libre or ungoogled-chromium
<tschilptschilp23>Basspoon: I've put the critical packages (my computer also starts burning on ungoogled-chromium, gimp and linux-libre too) into a manifest-file, which makes it 'comfortable' to selectively 'guix weather -m critical-manifest.scm' peek into the new guix and in the not-ready case switch back.
*tschilptschilp23 now thinks that writing manifest-files for achieving ~guix weather ungoogled-chromium linux-libre gimp~ might be overkill
<Basspoon>@tschilptschilp23 by 'switch back' do you mean you avoid upgrading those packages (for the meantime)?
<tschilptschilp23>yes, I'm not sure if this is good practice, but I typically do ~guix pull~, then ~guix weather ungoogled-chromium linux-libre gimp~ (well, just now switched to that instead of the manifest 'technique'), and if substitutes show less than 100% run ~guix pull --switch-generations=PREVIOUSNUMBER~. From then on I do a ~guix pull --switch-generations=NEXTNUMBER~ and 'guix weather ...' to be aware of substitute-readiness and just by then
<tschilptschilp23>upgrade. That way I'm a few days late all the time, but at least do not put my computer into an unexpected fullout-compilation mode. I basically keep the 'old' guix until these packages are readily substituted, but do the check quite often to stay up-to-date.
***unmatche1-paren is now known as unmatched-paren
<tschilptschilp23>but maybe I'll stay with the manifest (containing actually all packages I have in my profile) anyway, as I just see plasma-packages for marble rolling in and wonder how long this will take...
<tschilptschilp23>yeah, manifests will stay the way for me. If I'd be a crypto-affine person, I'd probably like what's going on right now, but I'm not really.
<Basspoon>@tschilptschilp23 may I ask what you're referring to by 'source-packags'?
<tschilptschilp23>the *.tar.xz and *.tar.gz packages, that you see being downloaded when upgrading.
<Basspoon>Oh, I thought you might've been referring to something else
<tschilptschilp23>which undergo the configure, install, check phases before they turn into these .drv files
<tschilptschilp23>If I'd know that my laptop somehow contributes to guix with the 'compilation' process, I'd probably be fine, but without knowing it, I do not really like the the update/upgrade procedure that we have. except for the possibility to roll-back through time and space.
<jpoiret>tschilptschilp23: that's the opposite though, it's the .drv files that tell them how to configure install and check
<jpoiret>when guix says `building /gnu/store/xxxx.drv`, it means that it's building the derivation (which is that exact file)
<wdkrnls>can I place multiple expressions under modify-services e.g. (modify-services *service* expr1 expr2 expr3 etc? The docs look like they say yes I can, but I didn't really see any examples which show that.
<wdkrnls>and I'm still seeing the debugfs throw error.
*tschilptschilp23 would have an easier live, if progress bars would not affect attention
<wdkrnls>I haven't used matplotlib for a while. Where do expect the plot to go? don't you need to pass a file path somehow? I remeember it used to create a little GUI widget, but I don't know what configuration allowed that to be created.
<reza[m]>according to the matplotlib documentation it should detect an avilable backend and create a gui window with the plot
<reza[m]>you could also set `backend: webagg` inside the file `matplotlibrc`
<apteryx>civodul: hello! I haven't tried your latest guile-zstd benchmark yet, but based on my last findings, I believe it'll be aligned with your results (i.e., there is no problem with guile-zstd itself when it comes to decompression performance)
<apteryx>In light of this, I think your idea to had the index.db pre-computed per package and merged in a profile hook is currently the path to pursue
<civodul>apteryx: hi! ah yes, in general, if we could replace hooks by a cheap merge of pre-computed data, that'd be great
<civodul>the less computational and i/o work in hooks, the better
<apteryx>we could use this to monitor resource usage during builds, which would be useful to display how much memory was needed (total and per core, for example) for a build
<apteryx>just thinking out loud, but over time data service could amass build statistics that could be queried by users wanting to have an estimate of how long their source build will take or whether they have enough physical memory
<civodul>i haven't yet been able to do much with it
<civodul>but i think we should set up something along these lines
<apteryx>hm, GNU time seems to report memory usage only for one (child?) process; here's a failed build of webkitgtk when using CMAKE_BUILD_TYPE=RelWithDebInfo: 'cpu: 1125%, mem: 4049656 KiB, wall: 24:52.82, sys: 1445.89, usr: 15355.58'; that's on a machine with 32 GiB of RAM and 16 GiB of swap.
<apteryx>So time reports a usage of 4 GiB, which is probably the usage of the more demanding cc1plus process killed by earlyoom due to exhausting memory and swap exhaustion.
<apteryx>AwesomeAdam54321: using G-Exps would be a more future-proof way, depending on what you are attempting to achieve; seems perhaps you were missing #:use-modules (guix gexp) at the top of your module?
<civodul>apteryx: for big C++ packages, found it useful to builds with -g0 (not emitting debugging symbols)
<civodul>that saves a lot of disk space, but it might save memory as well
<ZhuZihao[m]>The interesting thing: This bug is introduced 3 years ago. pitivi is packaged 1 year ago, I run `guix shell pitivi -- pitivi` and failed to start it and reports gst-python is not correctly installed.
<ZhuZihao[m]>🤔 Why the packager of pitivi can run pitivi with a broken python-gst.
<apteryx>perhaps the failure depends on the Python version used?
<lilyp>kitty1: GOA is comparatively tiny and if you don't like it you probably hate GNOME anyway, so shrug emoji
<GNUtoo>Hi, I'm running valgrind in the tests of a package that I build through a guix.scm, and I've the following in the valgrind log: "A must-be-redirected function whose name matches the pattern: strlen in an object with soname matching: ld-linux.so.2 was not found whilst processing symbols from the object with soname: ld-linux.so.2"
<GNUtoo>And it proposes that as solutions: "Possible fixes: (1, short term): install glibc's debuginfo package on this machine. (2, longer term): ask the packagers for your Linux distribution to please in future ship a non- stripped ld.so (or whatever the dynamic linker .so is called) that exports the above-named function using the standard calling conventions for this platform. The package you need to install for
<mjw>yeah. valgrind really needs the symtab table for ld.so, please don't strip it, it is tiny anyway.
<GNUtoo>And it tells to install libc6-dbg or glibc-debuginfo dpeending on the distribution, so I added '("libc-debug" ,glibc "debug")' in native-inputs but that doesn't seems to solve the issue. Does someone has an idea?
<GNUtoo>That's probably easier than using --extra-debuginfo-path, and certainly cleaner
<mjw>Sorry for being not that helpful. I really should make sure valgrind works well on guix.
<mjw>Also have to drop out to get some food for now. Back later.
<GNUtoo>With --extra-debuginfo-path I need to add support for it in my python tests, and somehow add an option in configure.ac and somehow retrieve that in the Makefile.am to pass them to the tests through an environment variable...
<GNUtoo>And the issue is that even if I manage to do a patch, it'll probably take some time before it's merged
<GNUtoo>And it'll probably get in Guix at the next release because if you rebuild glibc everything on top is probably rebuilt
<GNUtoo>Hmmm maybe patching the tests in the guix.scm to use an extra argument looks better
<GNUtoo>(1) It works now and it's self contained (2) It doesn't make the libsamsung-ipc code complicated because of some Guix limitation. And then the ideal would be to remove that extra patch when Guix will be fixed.
<tschilptschilp23>before getting lost in circle-games, I'd be happy to have feedback on one assumption. If I spawn an environment using 'guix shell', there is a file $GUIX_ENVIRONMENT/manifest. This file contains all the information about the environment I'm in at this moment, like the one in ~/.guix-home/profile/manifest, when I'm outside of this environment (assuming I have nothing installed via 'guix package -i', just relying on my home-config.scm).