IRC channel logs
2023-10-11.log
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 <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 <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 <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 <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 <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 <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 <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 <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 <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 https://paste.debian.net/1294734/ . 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 <saux>janneke i guess that. and you had boot hurd on modern hardware successfully? <janneke>ACTION hasn't tried anything newer than x60 just yet <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"? <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>but 32bit hurd might run still on a modern machine? <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>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 <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 <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 "run.sh" in a subdir and calling it done <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>but also installing in /gnu/store is interesting <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>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>> command not found, did you mean 'home' <efraim>i'm getting errors that serde can't find serde_derive, 4 lines after compiling it ... <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 <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>typically only (guix build ...) is safe to use there <apteryx>does git LFS needs to be handled specially when fetching sources? <mirai>oh wait, perhaps not anymore <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>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 <apteryx>odd; I'd expect the apt repo to fetch from the same place as the other packages <janneke>ACTION silently hoped that someone whe knows about glibc's and locales wourd pick it up ;) <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 <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>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>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 <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.” <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>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>though I originally was expecting it to work only for relative paths <mirai>turns out absolute paths also do work <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 <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, y.es. <zamfofex>Besides, I don’t think Systemd supports the Hurd. 🙂 <apteryx>about my earlier failure with git-lfs, the hooks requires /bin/sh