<vagrantc>janneke: thanks for getting that ball rolling!
<xelxebar>plstohelp: One could argue that the sub-subcommands of guix system should be lifted to subcommands of guix, so something like guix describe-system and guix reconfigure-system. It's mainly a matter of organization. Do you want a subcommand hierarchy or a large flat list of subcommands?
<leoprikler>there is also a large collection of licenses on gnu.org
<leoprikler>you can iterate through them and do pattern matching
<bricewge>I think I'll go with learning them by heart to improve my Vogon poetry
<lprndn>hum.. is there a way to do something like mixed-text-file but outputing a string and not a file? or get a string from a gexp?
<hendi>Hi, I have a question re. packages. I'm running gtk3 with some patches, e.g. to restore the insane type-ahead behaviour to the behaviour from gtk2 times. If I create my own gtk.scm file with the patches applied, will all gtk3 applications pick that up automatically? Or would I need to create a fork of gimp.scm, gedit.scm and so on as well?
<emys>sorry, needed to go offline when you asked for which grafic chip I had
<hendi>leoprikler: oh, sweet, didn't know about grafts. That sounds useful
<leoprikler>thing is, to effectively use them you'd have to build your local guix to override the gtk definition
<lprndn>hendi: I think cloning guix repo, modifying it and using it through ./pre-inst-env (or as you only channel?) should work too. You'll have to build everything impacted but no need to rewrite gimp or any other gtk dependents. Maybe wait for someone to confirm or not...
<hendi>Ok, that's enough for making me try guix. If there's a chance that'll work I'm happy :)
<rekado>civodul: I’m updating the cuirass-gc-roots cron job to include squashfs images and guix pack archives.
<rekado>I also want it to write out a list of files it freed up for garbage collection so that we can target these files explicitly when necessary.
<rekado>I’m now running guix gc -F6T on ci.guix.gnu.org after deleting these roots
<rbonnal>instead related to using emacs-guix stuff, can I run `./pre-inst-env guix build package` from inside emacs ?
<mroh>can someone confirm a segfault for xfce4-display-settings? (at least on a 3 monitor system, crashes on free() after display_settings_get_profiles())
***wxie1 is now known as wxie
<efraim>/gnu/store/48vyvqrd1zyfaba9f93d9jm59dn4n5dg-hello-2.10/bin/hello: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /gnu/store/23vikdirgh992dapq6is0yazh8l02l21-glibc-2.30/lib/ld.so.1, for GNU/Linux 2.6.32, not stripped
<apteryx>trying to build gnu/system/hurd.scm: checking whether struct stat.st_atim is of type struct timespec... builder for `/gnu/store/i83xngxlhyxkxxgwp9dg9qz5gjxnm9wi-guile-bootstrap-2.0.drv' failed due to signal 11 (Segmentation fault)
<apteryx>ah, no, it's the build of guile-bootstrap that fails with a segmentation fault (builder for `/gnu/store/i83xngxlhyxkxxgwp9dg9qz5gjxnm9wi-guile-bootstrap-2.0.drv' failed due to signal 11 (Segmentation fault))
<janneke>apteryx: i don't need it; not sure if it's needed for cuirass that is/was building it...
<xelxebar>Oh, cool, so guix pins executables to specific dynamic libraries by setting DT_RUNPATH in the elf .dynamic section.
<janneke>the difference between wip-hurd and wip-hurd-vm may blurr real soon; we could also go back to the `wip-hurd' name and drop wip-hurd-vm some time soon
<apteryx>janneke: good, as long as there is only one hurd branch to keep things easy to follow :-)
<raghavgururajan>bricewge For your udiskie shepherd service, did you install udiskie in your user profile or just added a like `(#: use-module (gnu packages foobar))` in ~/.config/shepherd/services.scm?
<raghavgururajan>bricewge Thanks. Btw, for user services, is it required to install packages explicity in user profiles? Or is it enough to declare (use-modules [...]) in ~/.config/shepherd/services.scm?
<janneke>apteryx: i was just creating a 2.2 worktree to check -- i'd better try on a fresh machine, then
<apteryx>let me know if you can reproduce the failure!
<janneke>can you build 'guile-bootstrap' (see above) ... i'm kind of wondering where you got the .drv to build
<raghavgururajan>bricewge Also, do you have `udisks-service-type` in your system config?
<bricewge>raghavgururajan: I didn't tried it that way. My user profile is full of packages, which isn't the recommended wa.
<apteryx>re-attempting ./pre-inst-env guix build -f gnu/system/hurd.scm still throws the same signal 11 error though --> builder for `/gnu/store/i83xngxlhyxkxxgwp9dg9qz5gjxnm9wi-guile-bootstrap-2.0.drv' failed due to signal 11 (Segmentation fault)
<raghavgururajan>bricewge I have set up shepherd files, but for some reason udiskie doesn't load at startup. Here are my files:
<janneke>apteryx: would you like to create a bug for that?
<raghavgururajan>How do I overcome the build error "configure: error: can only configure for one host and one target at a time"?
<lfam>TZander: Do `guix environment --pure guix` and then, from within the environment, `./configure --localstatedir=/var && make`. You shouldn't need to reconfigure very often, unless you garbage collect the programs selected by a previous configure
<raghavgururajan>I checked the configure file and --host is not declared multiple times.
<lfam>But, you do need to run `make` somewhat frequently. Guile will auto-compile (avoiding the necessity to run make) but, as you saw, that doesn't work if the configure is stale
<TZander>I was hoping for a version of 'guix package -f myfile.scm'... :(
<ryanprior>Dang okay so how do I reconfigure the test step to do that? Do you know a guix package that does that so I can look at its definition?
<rekado>nagamalli: what is your goal with gnome-todo? What does “fix gnome-todo package” mean? Is it broken? How?
<lfam>ryanprior: Look for instances of "replace 'check"
<ryanprior>Okay now I'm getting somewhere. The tests assume you're in the git repo, not a tarball. I can ask upstream if they support any method of testing without git. Or, can I have guix fetch the git repo instead of the tarball?
<lfam>ryanprior: It can't be done, because the '.git' directory changes, meaning we wouldn't be able to treat the source code as content-addressed
<lfam>For cases like this we just skip the test suite
<lfam>If the package is working for you, that is good enough
<lfam>I mean, we do fetch Git repos as sources, but in that case part of "building" the source is to delete the .git repo
<ryanprior>Do you think I should submit this package as a patch to guix then? Even though it doesn't run tests? (I'm going to ask upstream about running tests against the tarball, maybe that's something they can support with the right workaround.)
<lfam>Yes, it's fine to skip the tests if there is a good reason, and this counts as a good reason. As long as the package is free software and works for you, we want it :)
<ryanprior>Should I document the reason in a comment in the package, or in the commit message, or elsewhere?
<ryanprior>In terms of formatting my patch, is it a good idea to add the visidata package to `python-science.scm` since it's a data science tool? Or is it better to put it in its own `visidata.scm` file?
<atw>ryanprior: in my uninformed opinion: python-science.scm seems to be python packages that are useful while doing science. If visidata is a standalone application, that's a good rationale for putting it in a visidata.scm. OTOH if it is a python library that is useful for doing science, then python-science.scm would make sense :)
<ryanprior>It is an end-user application, so I will start with that recommendation. Thank you atw :)