IRC channel logs


back to list of logs

<jonsger>ACTION found shiny new features after reconfiguring his cuirass server :)
<sturm>If I launch Icecat from Gnome, I'm getting an older versino than if I run it from the terminal (v102 vs v115). I'm having similar issues with the Emacs icon launching "emacs-next" which I removed from my profile some weeks back. I've done `guix gc --delete-generations=1d` and rebooted. Any suggestions about how to get rid of these old versions?
<sturm>oh, interesting - I wonder if it's caused by guix home. Found a suggestion to check `type -a icecat` on the help mailing list
<sturm>turns out I'd run `guix home` some time back and since gone back to `guix package --manifest`. The packages installed with guix package were taking priority in the terminal, but not in Gnome launcher
<saux>does the shepherd new commit fix the bug that cannot shutdown?
<apteryx>mirai: weird, patch 10 is the single one that was messed up by gnus
<apteryx>the 62 others applied fine
<sneek>mirai, you have 2 messages!
<sneek>mirai, antipode says: also, you can wrap the package object (or any other lowerable object supporting cross-compilation, relaly), in a with-parameters that sets %current-target-system to what you want.
<sneek>mirai, antipode says: relaly->realy
<mirai>I don't see any obvious (invisible) characters out of the ordinary
<mirai>what's funny is that gnus hallucinates empty lines when there's none
<apteryx>mirai: I've finally pushed the docbook series to core-updates! congrats and thanks for it
<mirai>thanks for reviewing it!
<vivien>A million thanks for merging my patches into gnome-team! CI did not manage to catch up unfortunately.
<jbnote>Hi, I need help with my system configuration. I'd like to add a file to /etc in my system declaration. The documentation for this in service-reference.html is not clear to me: the documentation only lists a list of additional files, not how to weave it into the system declaration. Declaring a (service etc-service-type) with the list yields an error about duplicate services. How would I go about extending the service as simply as
<jbnote>suggested in the documentation?
<PotentialUser-92>Hello Guix. I need some guidance on how to use GUIX copy-build-system or trivial-build-system. Which one is better suited if I have to download an archive (zip or tgz), containing a lot of java-Klasses and shell scripts to start the certain applications and put it under GUIX control. So, basically extract the archive put it in the store, set some
<PotentialUser-92>environment-Variables and find a way to have the shell scripts available to the end user. What would be the best approach?
<adanska>jbnote: you should use simple-service to extend etc-service-type. since etc-service-type is extendable, there cant be multiple instances of it (at least i think thats why). see the simple-service example for how to do this
<efraim>probably copy-build-system with a phase to wrap everything as needed
<efraim>jbnote: here's an example
<jbnote>thanks a lot
<jbnote>(modify-services) was not working either and I was starting to pull my hair out.
<PotentialUser-92>efraim: Does the copy-build-system extract the archive during the process? I was looking for some examples in the guix sources but never saw some calls to tar or other archivers. The url of the archive goes to a git repository.
<efraim>PotentialUser-92: the copy-build-system should still extract everything during the 'unpack phase
<efraim>or copies everything from a git-checkout instead during the 'unpack phase
<PotentialUser-92>efraim: I see. I provided only definitions for python packages so far and I did not need to deal with build-phases and did not know which phases exist for which build-system. Do I have to link the scripts from the store manually to the profile of the user or is there a mechanism to specify which files are "executables" after copying?
<efraim>PotentialUser-92: if the files are already executable in the tarball/git-repo then you don't have to do anything, otherwise there's a chmod function to set them as executable
<efraim>(chmod file #o555)
<PotentialUser-92>efraim: But how do they end in the users PATH? So he can start them without knowing the exact store location
<efraim>once they're in %output/bin, when they're installed they end up in the PATH automatically
<efraim>same with sbin
<jbnote>It works! I can add custom /etc entries, thanks a lot. Now i'd like to *replace* the default /etc/profile with a custom version. Would you know of any way to do this? Now the extension rightfully complains about duplicate "profile" entries in the service. modify-services does not seem to work if I match on etc-service-type in %base-services. Is there some place I can modify the operating-system-default-essential-services which seems t
<jbnote>be dynamically generated?
<PotentialUser-92>efraim: Sorry for asking dumb questions. This is all very new to me. So I will check the guix sources to see where %output/bin is configured and if this can be a ./scripts directory as a whole.
<efraim>for the copy-build-system %output/bin is likely either bin or /bin, I don't remember which
<PotentialUser-92>efraim: Thank you
<jbnote>wait, sorry, I think I found a way by redefining (essential-services) and applying (modify-services) there.
<jbnote>incredible, scheme is too good to be true
<adanska>would it be safe to add xfce-desktop-service-type to the list of services in installation-os? i want to make a guix rescue image with some graphical tools like gparted. i ask because there seems to be some changes that assume elogind is not present on the install image
<efraim>I have a WIP image for gparted. Unfortunately it fuctuates between 800MB and 2.1GB depending on how much I strip the inputs
<efraim> but with llvm-minimal replaced with llvm-for-mesa
<adanska>efraim: oooh cool! i seem to remember you working on this a while back... impressive that you got it that low anyway. I think i'm fine for the most part with a big install image - when something goes wrong on my system i want everything i could possibly need, including a web browser and full DE. a gparted-style guix image would be super valuable though - currently, installing guix is a little involved, especially since your only source of documentation is re
<adanska>- really just info. a web browser and NetworkManager would be something i would value quite a lot.
<efraim>ah, a full web browser is definately more than I was looking for. I think I found some spots where I was using a standard a a minimized version of some packages, even ignoring trying to cut the dependency tree somewhere with some static libraries
<nutcase>Hi all. I try to create a system service and ended up with . When I run this operating system (in vm), the machine boots and hangs with/after "creating /etc/machine-id..." . What is wrong in my service(-type) definition? I thought, that the service should not be the cause, because of `auto-start? #f`
<saux>how's hurd going, has anyone boot it on physical machines
<saux>janneke nice try, but it seems  too hard to boot on modern PC
<janneke>saux: what makes you think that?
<saux>janneke i guess that. and you had boot hurd on modern hardware successfully?
<janneke>saux: define "modern hardware"
<janneke>ACTION hasn't tried anything newer than x60 just yet
<efraim>does the x60 support 64 bits?
<saux>janneke: intel i3 4th at least
<zimoun>jpoiret: About Capitole du Libre, they will announce next week; they told me.
<janneke>ekaitz: nope, guix doesn't do 64bit hurd yet
<ekaitz>i think you wanted to ping efraim
<janneke>but that shouldn't be a problem for a "modern machine"?
<janneke>ekaitz: yup, ty :)
<efraim>I really meant did the x60 support running 64-bit, not did guix's hurd support 64bit
<ekaitz>other day we have to talk about hurd and why does guix support it, i'm really interested on it but I don't know in practice how useful could it be
<janneke>efraim: no, x60 is 32bit
<janneke>but 32bit hurd might run still on a modern machine?
<efraim>janneke: I don't see why not
<Minall>Hello Guix Community!
<Minall>Does the virtualization system from Guix is able to make networks between containers?
<Minall>I was thinking if it was possible, as one can specify the packages versions, to use Guix shell of course as a development environment, but also as a vulnerability analizer tool.
<cbaines>Minall, which virtualization system, I think Guix packages several?
<cbaines>and generally if you're talking about containers, you're not using virtualization
<Minall>For example, I'm reading right now a vulnerability which needs version xx.xx.xx of a package and I just got the idea that if I define a file.scm specifying this shell, then I could try the vulnerability and make a report about it?
<Minall>cbaines: Containers are different than virtualization?, perhaps I'm confused
<cbaines>Minall, yeah, virtualization is about virtual hardware, and containers are about environments within an OS
<Minall>cbaines: Oh, then I'm talking about environments. I wouldn't go as far as virtualisation just for studying, maybe in the future?
<Minall>So imagine a project that has several vulnerability1.scm file that tests several bugs from specific packages and me running these as an org report. That would be a good github page and a vulnerability list
<janneke>efraim: right, one might have to choose wisely wrt a netdde-supported ethernet card
<janneke>until rumpnet becomes more than just talk
<ekaitz>does anyone have experience with `guix pack -f deb`? do things generated with that see the rest of the debian system where they are installed?
<ekaitz>I have a very weird issue with a package that is not able to make a simple http requests from guile
<cbaines>ekaitz, I'm unsure, I presume you might be having an issue with GnuTLS or certificates, do you know what's not being found?
<anthk_>on guix pack I suggest to add nss and nss-certs
<ekaitz>cbaines: the error it gives is getaddrinfo fails with ai_socktype
<anthk_>it happened to me with mosh, I had to had glibc-locales too as mosh needed UTF-8
<ekaitz>anthk_: i will try with that!
<anthk_>getaddrinfo it's related to DNS
<ekaitz>it smelled like some cert issue but i thougth they should be taken from the machine
<ekaitz>anthk_: I have no idea of getaddrinfo is, honestly
<anthk_>ah no, that was gethostbyname
<ekaitz>this is the error I get: getaddrinfo: Servname not supported for ai_socktype
<cbaines>Given that error, I don't think this is anything to do with the things I mentioned
<ekaitz>i searched the error online but I didn't get anything reasonable
<anthk_>but yes, add nss and nss-certs just in case
<anthk_>if your software uses SSL/TLS
<ekaitz>anthk_: to propagated-inputs? or just to inputs?
<anthk_>on guix pack when I generated a tgz for a machine, I just put all the packages in a line:
<anthk_>guix pack -foobar argsss blah blah ... nss nss-certs guix-locales mosh
<anthk_>I don't have any experience on deb generation, but well...
<anthk_>on some recent kernels, you can use guix pack with relocatable binaries against that target
<ekaitz>ok, i'll add them to inputs and see what happens
<anthk_>then I don't use debs, but you can add a symlink to a generated tgz rootfs as a guix pack argv so the user can run /opt/gnu/bin/yourbinary instead of /gnu/store...
<anthk_>and in some newer kernels, relative paths in $HOME might work
<anthk_>ah, guix pack for deb allows the same
<ekaitz>in guix pack for deb i have to add a postinstall or something I guess
<ekaitz>but I don't know how to add it yet
<anthk_>in my case for a tgz for mosh so it worked for my netbook, I did
<anthk_>guix pack -RR -S /opt/gnu/bin=bin nss nss-certs guix-locales mosh
<anthk_>but what I'd love would be a plain rootfs and setting LD_LIBRARY_PATH and PATH by hand so I could just set a script called "" in a subdir and calling it done
<ekaitz>oh symlink
<ekaitz>that makes sense
<anthk_>the generated tgz/deb wil still get the /gnu/store structure, I wish there was some option to export a rootfs to be installabe in /opt/gnu for instance
<ekaitz>i agree
<ekaitz>but also installing in /gnu/store is interesting
<anthk_>yeah, of
<anthk_>at least it's faster to cross-generate a pkg from my newer amd64 machine to i386 than installing guix and then the packages for my netbook
<anthk_>anyway, the list of non-available packages I need in the netbook it's small, so /gnu/store is not a big issue
<anthk_>~219MB for mosh, nss* and locales, not bad at all
<anthk_>also it depends on perl and protobuf, so, guix does it well on exporting libre software for smaller libre distros
<anthk_>brb, good lock/buena suerte/zorte on
<efraim>I got some rust packages cross-building!
<anthk_>btw, one day I'll get chicken-scheme with the 203 and 216 srfi's working with guix import :p...
<ekaitz>anthk_: thanks!
<ekaitz>efraim: i'm building again the gcc for riscv, i'll keep you posted
<ekaitz>also efraim remember that zig-build-system? could you take a look into it please please?
<efraim>sure. I'm not sure about it with the few number of zig packages we have, but I suppose that is a bit of a chicken-and-egg problem
<efraim>and also we need to see about building zig-0.11 with 0.10 or 0.9
<ekaitz>efraim: I think one of the best solutions is to merge it, and start getting reports and improve it as it goes
<ekaitz>because it's not going to affect the quality of guix in any way
<ekaitz>if there's anything obvious we can of course fix it now, but being in the ml as a patch doesn't help anyone
<snape>./pre-inst-env guix home
<snape>> command not found, did you mean 'home'
<efraim>i'm getting errors that serde can't find serde_derive, 4 lines after compiling it ...
<attila_lendvai>anyone around who have successfully compiled a fw for RPI on guix? i'd like to have this compiled, but it's not trivial:
<attila_lendvai>the non-trivial part is the RPI SDK
<ekaitz>attila_lendvai: it shouldn't be hard, the main issue is our arm toolchain is broken
<ekaitz>there's a message in the ml by stefan that solves the issue in a very interesting way, but i didn't have the chance to take a deeper look into it
<ekaitz>attila_lendvai: if you search the ml with my name you can also find a message with the problems I encountered
<ekaitz>which are just #include_next <stdlib.h> doesn't work
<ekaitz>efraim: / 'build' phasebuilder for `/gnu/store/6rj1570pm4s02xzqgh32rzfmkgxb22vr-gcc-cross-sans-libc-riscv64-linux-gnu-11.3.0.drv' failed with exit code 1
<attila_lendvai>ekaitz, well, this is what i meant with 'non-trivial'... :)
<attila_lendvai>ACTION looks up the messages and takes notes
<ekaitz>attila_lendvai: yeah... the rp has kind of a simple sdk comparing with other things... but it's also hard to manage where are includes searched for
<snape>cbaines: now I get "Unknown issue with revision" on QA
<cbaines>hmm, there's some problems with the data service receiving the guix-patches emails
<snape>oh ok, it looked fixed so I tried^^
<efraim>We don't use (guix utils) in *-build-system, right?
<apteryx>we don't
<apteryx>typically only (guix build ...) is safe to use there
<apteryx>but there are exceptions
<efraim>I can make do without it
<apteryx>does git LFS needs to be handled specially when fetching sources?
<apteryx>it looks like
<apteryx>I have a test suite broken because test/ods/raw-values-1/input.ods is a text file containing metadata like "version" instead of an actual zip ODS
<apteryx>implemented in nix with
<mirai>oh wait, perhaps not anymore
<mirai>hmm… not sure
<apteryx>still there
<mirai>I recall trying to clone a lfs using repo before the ordinary way and failing
<mirai>and had to run some kind of command first
<mirai>there's also this answer: <>
<mirai>looks like you need to “git pull; git lfs install; git lfs pull”
<apteryx>that's what the above nixos merged PR does
<Parabellus>Hi, I tried to sudo apt install guix but it says 403 forbidden (I'm not using a VPN or anything else that I know could trigger this). It doesn't happen with any other package I install with apteryx
<Parabellus>*aptitude (stupid autocorrect lol)
<apteryx>odd; I'd expect the apt repo to fetch from the same place as the other packages
<janneke>civodul: fixed curl/fixed, but i could not reproduce
<janneke>ACTION silently hoped that someone whe knows about glibc's and locales wourd pick it up ;)
<bjc>mm... dvorak typo
<bjc>nice to see
<janneke>bjc: that's right :)
<apteryx>mirai: I have the lfs support implemented; will test a bit and send it soon
<apteryx>mirai: hm, seems 'git lfs install' is not a thing for our git
<lilyp>apteryx: you need git-lfs
<apteryx>ah! thanks
<apteryx>this will be more fun...
<apteryx>yuck, go
<apteryx>civodul: are you comfortable having guix-daemon depend on git-lfs, which depends on go?
<ieure>Agree wholeheartedly with "yuck, go"
<rekado>apteryx: a hard dependency? I’d rather not.
<apteryx>rekado: it seems inevitable; some repos use LFS; if we want builtin:download-git to be able to, we'd have to add a dependency to git-lfs for the daemon at build time
<lilyp>can we, like, make it optional to the fetcher tho?
<apteryx>how does git finds its extension?
<apteryx>lilyp: we can make it a soft dependency, but this means builtin];download-git would be a best effort thing and never able to replace the inband version currently in use
<lilyp>git anything is just a shorthand for git-anything
<lilyp>can you explain that in simpler terms? Is the goal to use guile-git rather than the git CLI?
<apteryx>no, the goal is to add a lfs? switch to <git-reference> and be able to rely on lfs being available for it to work
<apteryx>rather than "oops, 'git lfs' not present on your system"
<lilyp>ahh, okay
<lilyp>In that case, you'd only have to add git-lfs to the native-inputs when that flag is enabled, right?
<apteryx>for the inband downloader that can be done yes
<apteryx>for the builtin one we depend on the system ambiant authority (like a classic distro)
<lilyp>I'm not too knowledgable about these portions of the guix code – what's the inband downloader and the builtin one? Where are they used respectively?
<apteryx>it's been contributed recently; the inband one uses a normal derivation to do the fetching of a source
<apteryx>the out of band (builtin) assumes the daemon has access to external dependencies to do its work
<apteryx>the top level is at (guix git-download)
<apteryx>the idea of the builtin:git-downloader is to cut the dependency graph for downloads
<apteryx>knowing that its output is a fixed derivation anyway
<lilyp>ahh, so we're taking the dependencies and move them to the daemon, as it were
<apteryx>so far with the inband downloader I'm getting:
<mirai>Can someone suggest me a more concise docstring for a hypothetical “#:output "doc"” parameter in copy-build-system? I've got “@item The @code{#:output} argument is an output label which can be used to install the specified paths to a different output.”
<mirai>it sounds circular/verbose
<geoduck>"specified paths' label for alternate output install path"?
<lilyp>mirai, what does your spec currently look like? where have you tried adding #:output "doc" until now?
<mirai>lilyp: This is the package I used for “demo” purposes <>
<mirai>I also refined the description a bit below
<lilyp>uhm, this-package-input probably won't work here
<lilyp>the format should also not use #$output itself
<mirai>lilyp: it actually does!
<mirai>though I originally was expecting it to work only for relative paths
<mirai>turns out absolute paths also do work
<lilyp>happy accident :)
<mirai>nice catch for the #$output:doc
<mirai>funny that it also worked but clearly not the right way
<civodul>is someone working on the curl graft?
<civodul>8.0.4, released today or yesterday i think
<the_tubular>Yeah, that release was kind of a mess
<the_tubular>It got leaked like 20 hours earlier
<TehBoss>does guix not use systemd?
<Kolev>TehBoss, nope.
<Kolev>TehBoss, GNU Shepherd init system.
<TehBoss>is that just because it works better with the configuration system that guix uses?
<Kolev>TehBoss, GNU Shepherd works better with Guile Scheme,
<zamfofex>Besides, I don’t think Systemd supports the Hurd. 🙂
<apteryx>about my earlier failure with git-lfs, the hooks requires /bin/sh
<apteryx>maybe I can patch git-lfs