IRC channel logs
2025-02-13.log
back to list of logs
<eikcaz>seems having "ffmpeg" and "mpv" cause the profile to fail. looks like mpv uses (propagated-inputs (list ffmpeg ...)) which resolves to ffmpeg version 6, but (specification->package "ffmpeg") resolves to version 7. Shouldn't (specification->package "ffmpeg") resolve to the "stable" ffmpeg, not the latest? <eikcaz>ACTION doesn't like to pin package versions in home.scm <ieure>eikcaz, specification->package resolves to the latest version, the `ffmpeg' symbol is pointing to an older one. <coyotes4ys>sideline question: eikcaz are you talking about your whole system profile? i'm new to guix <eikcaz>coyotes4ys: I try not to touch my system config. I'm updating my guix home config. <graywolf>Hello Guix :) Would anyone know whether the user/group IDs are stable across reconfigure? If I create a user using (user-account), will it keep the assigned UID even when I will be adding more? <mange>I'm pretty sure they will be stable as long as the same user/group is present between generations. I'm not sure that there's a guarantee if you remove a user, reconfigure, and then add the same user back again. Let me see if I can find that written down anywhere... <graywolf>I do not plan removing *that* particular user :) Basically I wonder whether activation service needs to do chown or chowm -R. <mange>You can also set a uid on a user-account record, or an id on a user-group record, if you need to. <graywolf>Reference to manual would be gret, I did not find much :/ <mange>I can't find anything in the manual, but the code is in gnu/build/accounts.scm and several docstrings say "preserve stateful bits from..." and similar. <graywolf>Good enough for me. Thanks for the peace of mind ^_^ <mange>I'm pretty confident in what I said: uid/gid will be preserved if it's currently in use, but if you reconfigure to no longer have the user/group then there is no attempt to preserve the uid/gid if you re-add it in future. <mange>Which may mean that a service needs to chown things, because a user could remove the service and re-add it. <mange>But I guess it depends on the details. <graywolf>Hm, true, though in this only-for-my-system case though I would just call that PEBKAC and move on :D <graywolf>Shepherd does not log lines that do not end in #\newline. <coyotes4ys>i downloaded torbrowser from the torproject website because i had problems with our in-repos version <coyotes4ys>it won't start though. it is in ~/downloads/ is that ok to start an executable? <ieure>Pinging on this one again. Straightforward. 76189 <gorilla>How easy is it to lock down users in GuixSD? Think lab environment. <gorilla>For instance, can I prevent users from installing software? Can I remove users' ability to edit network configuration? <ieure>gorilla, I don't think you can prevent people from installing software on Guix System. <ieure>You can lock down network configuration. <gorilla>What is the mechanism for pushing config changes from a central authority? <dcunit3d_>i'm working on a Guix Home configuration. for some reason, i can refer to a package via its symbol by importing `#:use-module (rde packages fonts)` <dcunit3d_>however, when i try do `(specifications->package "font-pkg-string")`, it can't be found <dcunit3d_>the errors that i'm getting occur when i evaluate sexp's that have the manifest syntax in the repl. <dcunit3d_>i haven't set up my environment using Guix Home yet. my geiser and guix.el paths seem to be correct. <dcunit3d_>is it possible that this will be a non issue once the ".profile" for my window manager's shell is being loaded through guix home? <dcunit3d_>i'm trying to gradually move towards implementing things with service extensions, but it's a bit hard to move everything all at once. i appreciate all the work that's been done to make Guix & Guix Home simpler <dcunit3d>i'm hoping to get to a more standard configuration that's easier to explain when i have problems <dcunit3d>(that's why i have been advising people to just move to guix home ASAP bc i think it avoids a lot of potential config issues) <ieure>gorilla, `guix deploy' is how you'd do that. <apteryx>wow, so many access call for finding icons <apteryx>am I right that /var/run is depreceated in favor of /run ? <apteryx>otherwise, what's the difference supposed to be, and why do we have both? <nico_>I'm trying to install a Syncthing service for my user. I found `syncthing-service-type` in the manual, but to me it is unclear how to add services. I tried to /etc/config.scm, but that resulted in an error. Also I assume I can just add it on a user level isntead of a system level. Should I create a new services entry in the user config (I installed Guix System). An example would be helpful. Also, do I need to install syncthing as a package, o <nico_>r is it then already accounted for? <aure884>Hello. What could be the reason for a shepherd service to not be found with `herd status` or `herd start <service>`? The strange thing is that the activation function which needs to create some folders is taken place on boot! <aure884>Thanks for the hel in advance, I'll read the logs later in case someone replies :) <apteryx>are tempel snippets more advanced than our yasnippet ones? <dcunit3d>nico_: you can either run syncthing as a system service or a guix home service. if you want it to run on the user level, you can either start it once you login (somehow, outside of guix, as an autostart entry or something) or you can add it to the user's home-environment <dcunit3d>apteryx: they are close to the same, basically <dcunit3d>apteryx: the tempel snippets are close to the same as the yas snippets <apteryx>I think I saw they can add phases now too, which would be something new I think <nico_>dcunit3d: thanks. Is there an example somewhere how to add a service to the home environment? <Guest4>Hi all. Has anybody received: guix home: error: canonicalize-path: No such file or directory: "/home/XXXXXXX/src/guix-config/src/guix-config/.bashrc" when running guix home reconfigure? <flypaper-ultimat>aure84: not all guix [ system | home ] services are shepherd services. If they do not directly or indirectly extend shepherd, they would not create a shepherd service that gets loaded by shepherd, and thus not show up in the 'herd status'. A thing that extends 'activation-services' means that it gets loaded by the activation script at boot. This script is not 'managed' by shepherd. <flypaper-ultimat>nico_: (home-environment (services (cons* (service home-syncthing-service-type) %base-home-services))) <Guest4>flypaper-ultimat: dcunit3d: Was that for me? <dcunit3d>for you Guest4, `guix home reconfigure` can't find that path. check how you've configured your home-bash-configuration <dcunit3d>you may need to run `guix home reconfigure` from a specific directory until you have it properly set up <nico_>Thanks I'll test it tonight probably <Guest4>dcunit3d, this was a clean install of guix system. I ran all commands from the root of my home folder. This was the suggestion from guix home that produced the error: <Guest4>$ guix home import src/guix-config <Guest4>guix home: 'src/guix-config' populated with all the Home configuration files <Guest4>hint: Run `guix home reconfigure src/guix-config/home-configuration.scm' to <Guest4>effectively deploy the home environment described by these files. <Guest4>I ran that right away and it gave the error above <jcabieces>Hi all. When I use guix build -f myfile.scm, I don't get the cmake version I'm expecting (3.24.2 instead of 3.30.1 installed with guix install). I failed to understand how I can set the "context" (commit!) from which I'm basing my build file ? <divya>jcabieces: Well, when you build you don't use the installed package, it uses what's provided in the file. How are you providing the cmake in your file? <jcabieces>divya But I never fix the version/commit anywhere <jcabieces>divya when I use-module, I don't know what version I'm actually using <flypaper-ultimat>jcabieces: the cmake is determined by the cmake-build-system, lemme make a minimal example to see if i can get it to be replaced. <flypaper-ultimat>jcabieces: actually theres already examples in guix, run "guix edit hyprgraphics" to open the hypgraphics definition in your $EDITOR <divya>jcabieces: You can mention in the #:cmake paramter <divya>Which cmake you want to use. <jcabieces>divya flypaper-ultimat thanks, I'm testing it! <jcabieces>divya flypaper-ultimat I still fail to understand how guix had selected the 3.24.5 version over anyone else ? <flypaper-ultimat>jcabieces: also, the package building steps are isolated, so no matter what you have installed in your .guix-profile or wherever, it will not those. <jcabieces>flypaper-ultimat that makes perfectly sense indeed <divya>jcabieces: That's probably the version pinned for the cmake-build-system, I guess most programs still used an older version of cmake.. <jcabieces>divya ok, do you know how can I see the pinned versions ? <flypaper-ultimat>i think its more of a thing of 'if we change the default, everything that is build with cmake will need to be rebuild', so the default is only updated on certain times <flypaper-ultimat>so the default is the 'cmake-minimal' symbol, as used in '(gnu build-system cmake), you can use "guix edit cmake-minimal" to jump to the definition. <jcabieces>divya ok, I understand now! flypaper-ultimat divya thanks for detailed explanation <efraim>does anyone know how long the novena takes to boot up? <flypaper-ultimat>aure84: weird, i added it to a minimal system config (from (gnu system exxamples bare-bones)) , running it in a 'guix system container', and indeed it gets added to the shepherd-conf, but it doensnt seem to be listed by status . <flypaper-ultimat>aure84: ah doing a herd load on the scm file gives 'Unbound variable: aetitle' <flypaper-ultimat>so replace lines 91,92 with "--aetitle #$aetitle" "--storage-dir" #$storage-dir <xelxebar>Anyone else use transmission-daemon-service-type? <xelxebar>Stopping the service started erroring for me since my last reconfigure. <xelxebar>Wrong type (expecting exact integer): (process (version 0) (id 16431) (command ("/gnu/store/wa9mb7p78ga90vr3yb7j81i76gyxjp9c-transmission-4.0.6/bin/transmission-daemon" "--config-dir" "/var/lib/transmission-daemon" "--foreground"))) <xelxebar>Also, reconfigure is failing at the last minute now... <xelxebar>guix system: error: error parsing derivation `/gnu/store/49ygdzi7w51dimqdhlbzq3lw7na0c2wr-module-import-compiled.drv': expected string `Derive([' <civodul>xelxebar: looks like the ‘stop’ method of that service is completely bogus and incompatible with Shepherd 1.0 <civodul>actually i can send a patch while i’m at it <dcunit3d>i'm trying to use the `guix home container -e '(@ (my home config) (my-home-environment))' syntax, but I'm getting "source expression failed to match any pattern" <janneke>dcunit3d: exactly what it says...it isn't a valid expression <janneke>possibly you mean (@ (my home config) my-home-environment) or ((@ (my home config) my-home-environment)) <dcunit3d>i see, thanks janneke. i haven't used the syntax much. are the expressions interpreted by a define-syntax rule? <dcunit3d>i need it to evaluate a named procedure. <dcunit3d>idk. i may be able to figure it out tomorrow. i know i've seen the pattern somewhere <janneke>yeah, then you need the second variant i guess <dcunit3d>it still didn't work. i think i'll figure it out tomorrow. thanks <dcunit3d>janneke: i think i was missing a semicolon in my module <dcunit3d>i really need to get to the point where i've established my home environment bc my guile & guix.el environments are just wonky <aure84>flypaper-ultimat: thanks a lot for the insight! I'll give it a try. Could give me a hint on how you did debug this? `herd load service.scm`? <flypaper-ultimat>aure84: if you `herd status root`, you can see in the comamnd section config of shepherd used, opening that i did see that shepherd tried to load your dicom-daemon. doing `guix gc --references /gnu/store/...-shepherd.conf` (where the /gnu/store/...-shepherd.conf is the --config of the shepherd command), one of the things you get back is /gnu/store/...-shepherd-dicom-daemon.go; which is the compiled guile file. then doing `guix gc <flypaper-ultimat>--references /gnu/store/...-shepherd-dicom-daemon.go` you can get the (noncompiled) .scm file that it was made from, which looks something like /gnu/store/...-shepherd-dicom-daemon.scm. I invoked 'herd load root /gnu/store/...-shepherd-dicom-daemon.scm' and that gave me the error of undefined variables, which made me look back at your .scm file , looking at how you used those variables. <flypaper-ultimat>but yeah, it was a valid quoted expression when guix turned it into a shepherd service, because guix has no way of knowing that 'aetitle' is not defined in the shepherd service scheme file. but I didnt see anything in /var/log/messages. manually invoking shepherd with the same args as 'herd status root' did give me an informative message about undefined variables in dicom-daemon. <xelxebar>Ugh, xinit update broke startx. Erroring with MK_COOKIE: command not found (CC iyzsong) <xelxebar>Comes from the fact that the script has mk_cookie=MK_COOKIE <xelxebar>AFAICT, the upstream configure.ac is broken, failing to set MK_COOKIE (and HAS_COOKIE_MAKER) in the fallback case, which we're in. <xelxebar>I've poked the xorg IRC channel and offered a patch there, but given upstream's slow cadence, I think we'll need a workaround. <iyzsong>xelxebar: patch welcome, it seems mcookie come from util-linux <divya>Would a committer review and merge #75645? It allows one to use rtorrent with RPC and helps the emacs package `mentor`. <divya>I'm typing wrong bug numbers this week. <janneke>oh my, core-packages-team got updated right under me... <janneke>and now another gcc-14.2.0 commencement build that just finished :-(( <OnASnoopPhone>Hello, to try out GNU Guix I installed it on a spare pendrive. However I want to make sure everything is working but cannot find out how to check the system log (journalctl command in systemd). Does one know how to check what devices have free firmware missing and check logs then? Thank you! <vhns>OnASnoopPhone: either `dmesg` or `cat /var/log/messages` <OnASnoopPhone>Thank you for the fast response vhns! sudo less /var/log/messages <yelninei>janneke: almost done with all of the %final-inputs. glibc was fine, have been waiting on gcc-final for the past 3h <janneke>yelninei: great; did you push to core-packages-team with the glibc 2.41 update? <janneke>ACTION has also been working to build "./pre-inst-env guix build --target=i586-pc-gnu hello" <janneke>but was suprised by a new version of core-packages-team, rebased and pushed their patches right away <yelninei>janneke: i started at the HEAD from yesterday <janneke>yelninei: yeah me too, but things have changed by Zheng Junjie <yelninei>(i downgraded automake-boot0 to 1.16.5 locally) <yelninei>but probably need to restart with your changes though <janneke>yeah, alignment with others working on core-packages-team via here or else #75518 would have been nice <janneke>yelninei: /gnu/store/jwv275s1b5w02xj0h8f8zk7da0yjn36m-hello-2.12.1 for current core-packages-team <xelxebar>iyzsong: Well, I thought simply adding util-linux to the inputs would do the trick. It does work around the original bug but surfaces another. <yelninei>janneke: Are you cross compiling? i am trying with -s i586-gnu and offloading <xelxebar>For some reason the mcookie path is getting borked. The ungrafted package turns "linux" into "1 ", and this causes the graft to behave strangely. <xelxebar>That's despite the fact that the configure stage reports detecting the correct path. <mirai_>divya: is it worth defining a package variant just for the XML-RPC support? <xelxebar>Maybe it's another bug in upstream's configure.ac? <janneke>so we're doing different things, that's nice :) <mirai_>why not just build rtorrent with XML-RPC baked in? <janneke>yelninei: as i said before... "* janneke has also been working to build "./pre-inst-env guix build <divya>mirai_: Yep because you don't always need XML-RPC, unless you're using rtorrent to talk to other things. <civodul>i think i’ll reboot berlin (ci.guix) <mirai_>divya: can you not disable it at runtime via config? <apteryx>civodul: hi! OK; basic maintenance, or some issue? <yelninei>janneke: Missed that. It will take a while before I arrive at hello . Restarted now with the current branch and the downgraded automake-boot0 <divya>mirai_: From what I've seen in the documentation, nope. <mirai_>I don't see a recommendation to build rtorrent variants, only to secure that socket (which is general advice) <apteryx>lilyp: what was the package responsible to get the calendar widgets to fully work in gnome? evolution-data-server? <civodul>apteryx: full because it’s running shepherd 0.10; i’ve been trying to synchonize on guix-sysadmin to have someone close to the data center just in case, but that hasn’t worked <apteryx>OK. Is node 129 up? if so, that's some guarantee we can at least go through iDRAC in case we must <divya>mirai_: I don't really have an issue with xmlrpc being packaged by default. It wasn't already done in Guix, so I assumed someone didn't want that. <lilyp>should we include that in gnome by default? <mirai_>divya: not every package is built "fully" but the reasons are up for speculation <apteryx>then I'd say... go for it, but it's a bit risky given the shepherd upgrade -- make sure you have a couple hours ahead of you in case :-) <divya>mirai_: Okay, what do you recommend? <civodul>apteryx: ok, let’s do that; thing is, if it doesn’t reboot, there’s nothing i can personally do <civodul>ah well, i could check the iDRAC, right? <apteryx>see guix-maintenance/doc/infra-handbook.org <apteryx>make sure it works before your attempt :-) <mirai_>divya: I'd say build rtorrent with that thing enabled <civodul>apteryx: i can connect and i have that “racadm” prompt <mirai_>quickly glancing at docs seems to suggest me that you need to configure a port or a socket file path to use that anyways <apteryx>civodul: by hopping through node 129? <divya>mirai_: Cool, so I'll send an updated patch? <mirai_>so if it does unconfigured there should be no problem <divya>mirai_: It ges with 8080 by default. <civodul>apteryx: yes, as noted in the handbook (i have that in ~/.ssh/config) <apteryx>civodul: e.g. via ProxyJump hydra-guix-129 in your ~/.ssh/config <apteryx>I meant, the iDRAC web interface for berlin <mirai_>divya: feel free to send in a patch but note that I can't commit anything :) <civodul>apteryx: dunno, i don’t use it, too hard to set up <apteryx>it should work too (it's a must, the console interface is a pain) <divya>mirai_: No worries, but is there a specific team for torrents and stuff? I don't think so.. <civodul>apteryx: ok, i’ll check it out if i have to <ekaitz>janneke: are you around, i need some of your wisdom <apteryx>I haven't seen a GNOME desktop where you can't add items to the calendar widget out of the box <mirai_>divya: no idea (dont have teams.scm open right now) but your patch should get picked up by anyone nonetheless <ekaitz>sneek: later tell janneke I need to talk to you about Mes <apteryx>that list is in a very parsable format by the way; we should make a manifest that returns the packages it lists, at the versions shown <sneek>Welcome back janneke, you have 1 message! <sneek>janneke, ekaitz says: I need to talk to you about Mes <apteryx>is that something you'd be interested to do? otherwise I can try to hack it <ekaitz>janneke: i passed first round of NlNet for the Mes speedup effort, I'm preparing the task list, which includes you, would you like to take a look? <lilyp>apteryx: yeah, we might want to add it to "core-services" <ekaitz>janneke: i'll send you an email right now <ekaitz>janneke: sent! it's a little bit rough but... i just had a child and i'm not really awake these days <apteryx>lilyp: have you been able to test a running gnome desktop on gnome-team yet? <apteryx>are the backgrounds finally showing by default? that was a sore visual point. <apteryx>the default desktop template had its background shown as solid blue or something <apteryx>I think because there was an incompatibility in our gnome-backgrounds package, IIRC. <apteryx>ekaitz: congratulations for the little one <dthompson>ACTION notices the node update was finally merged <apteryx>lilyp: any idea why the mutter/x11 and mutter/backends/native suites are now failing for mutter? <apteryx>civodul: why is our space usage up to 40% on berlin? that used to stay around 10-15% <lilyp>mutter/backends/native is the one that was previously disabled with that sed expression <lilyp>mutter/x11 is probably due to xorg-updates <civodul>apteryx: no idea; could be the many branches that were built over the last few months <apteryx>it'll be more important to go from lzip+zstd -> zstd only <apteryx>I should revisit what was missing in terms of warning old deamon users <civodul>most people never upgrade their daemon on foreign distros <civodul>but really, we should be using the nar-herder <civodul>so stash away nars that we want to preserve <apteryx>I see both as valuable an orthogonal :-) <apteryx>1. make it as small as can be 2. archive it <apteryx>civodul: all services went back up without any problem, right (e.g. nginx) ? <apteryx>there's this zabbix thing that's been forever failing <civodul>i think we can say we’ve given up on zabbix :-) <civodul>there’s really nice monitoring on bordeaux.guix & co. with Prometheus <apteryx>oh. is that simpler to setup than zabbix? <civodul>looks like it, but i’m rather incompetent here <civodul>the only downside is that the frontend is a JS-heavy interface (Grafana and Prometheus itself), we may not even have everything packaged <civodul>(it’s also an advantage: the interface is really good) <ieure>Grafana is very good these days. It is JS-heavy, as most things are. I run it for my personal stuff. <civodul>there are too few sysadmins on the sysadmin team <csantosb>Are we sure about the average downtime with codegerg ? Seems not reachable again. <mra>csantosb: iirc they're facing a pretty large ddos attack at the moment <mra>also, would someone with an up-to-date guix install mind running a script for me in `guix repl`? i want to make sure that something isn't just my system being weird: https://paste.rs/A8apB.scm <mra>it just requires that `store` be defined <mra>sorry, was too lazy hacking this together to think about the monadic way of doing this <mra>i just want to know if someone else also gets a non-empty list. i am surprised that this list is non-empty and would really like to know why. before running `guix pull`, the list was empty <mra>so i assume that this is some reasonably recent change <gorilla>Can you partition harddrives over guix deploy? <ieure>gorilla, I don't think so, that's more of an installation task. <gorilla>I'm interested in doing a netboot install that sets up an extremely minimal OS and lets everything else happen over guix deploy. <ieure>gorilla, Guix currently has no mechanism to automate installation. <ieure>It's definitely possible to do so, but you'll be writing that stuff yourself if you need it. <gorilla>ieure: I was thinking of a bare minimum image with a script to partition disks. Then a different boot image with network config to allow guix deploy <gorilla>The first image wouldn't have to be guix, but I figured I might as well <mra>Deltafire: right, yeah, sorry <mra>the store needs to be defined <mra>I didn't want to guess at the path of the socket on someone else's system <ieure>gorilla, Why do you want to install locally at all? When I've done netboot stuff (disclaimer: this was decades ago and Guix didn't exist), I didn't have any local storage, I'd TFTP the kernel and mount the netboot server over NFS as the root FS. <ieure>gorilla, That was on Debian, which has very good support for netbooting a lab full of machines. <gorilla>ieure, yes. I have considered that, too. <vhns>Hi. I'm currently trying to package a QT application. One of the things it needs to work is the `qtimageformats` package. I already include it in it's inputs, but, it seems to not be loaded. From what I could gather, the path of qtimageformats/lib/qt6/plugins needs to be in the environment variable "QT_PLUGIN_PATH". I tried adding it through a (native-search-path) but the does not cause the package to be <gorilla>ieure, perhaps I should be asking about tools to build a guix image <ieure>gorilla, `guix system image' is how you do that, there's a section in the manual. <futurile>I'm getting a timeout on ci.guix.gnu.org, anyone else get that? <vhns>futurile: it's being rebooted/maintained right now iirc <vhns>ludo posted about a bit above <futurile>thanks vhns - should have read the backscroll! <vhns>nah, it was ways back, I would've missed too. yw <mra>oh, damn it. i think that i screwed up my guix store while doing some testing. i am beign happily informed that `gcc-11` is non-substitutable... <vhns>btw, I fixed my earlier issue by adding a (wrap-program) to my package definition with the proper environment variables <cbaines>futurile, vhns as far as I can see from IRC, the reboot has finished <cbaines>SSH also doesn't seem to be working to berlin <cbaines>berlin is still up, but I can't seem to login via the tty <cbaines>I did get the motd but then it said "Login timed out after 60 seconds." and I'm back at the prompt <cbaines>this is fun, the berlin tty via idrac can function like IRC <cbaines>a reboot of berlin has now happened, and I can ssh in at least <cbaines>and issues.guix.gnu.org is back, which was the problem I was originally looking at <jaft_r>Anyone using KeePassXC? It keeps crashing when I try to make a new database <cbaines>hmm, berlin seems to be down again, I was ssh'ed in and had htop running, but it froze <ngz>jaft_r: I do. It doesn’t crash here. <jaft_r>ngz: are you running X11 or Wayland? <ngz>jaft_r: Wayland, on a foreign distro <craigbro>issues.guix.gnu.org is down (I'm guessing it's on berlin) <craigbro>cbaines: only trying to give data, not harrass or imply it's blocking me from anything <jaft_r>Hmm; well, I'm also running Wayland, just not a foreign distro. I wouldn't expect /that/ to be the cause for it erroring out… <ieure>craigbro, Known, being worked on. <cbaines>yep, ci.guix.gnu.org and issues.guix.gnu.org will be down as they're on berlin (a machine at the MDC) <ngz>jaft_r: Is it on x86_64? <ngz>Ah well. Same here. No idea about what could be wrong then. <jaft_r>Yeah; it keeps saying "xdg_toplevel#66: error 2: client provided an invalid min or max size \n The Wayland connection experienced a fatal error: Protocol error". Maybe it's Wayfire specific; 🤷. <mra>ooh, profile pictures are here? fun! <vhns>is there a way to set environment variables for a package before it's build phase? <cbaines>if you're looking for examples add-before and setenv are the things to search existing package definitions for <vhns>just read that I could do (add-before 'build 'set-foobar (lambda _ (setenv "FOOBAR" "BAR"))) <gorilla>I installed guix into an ubuntu container just to be able to create a system image very quickly. <gorilla>But guix keeps throwing pages of errors when I try to use it. <gorilla>even just `guix --version` gives me pages of `WARNING: loading compiled file /usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/guix/packages.go failed: In procedure load-thunk-from-memory: incompatible bytecode version` type warnings <lfam>gorilla: Are there any errors, or just warnings? <ieure>gorilla, I've used a vanilla Debian container to build a Guix image recently and it worked fine. <lfam>Also, how did you install Guix? It's really weird that Guix is printing messages about '/usr/lib'. Guix is specifically designed not to use anything in /usr <lfam>I see. I know that vagrantc is involved in the Debian packaging of Guix, but for Ubuntu, I don't know <lfam>Personally, I'd ignore the warnings unless there are any errors <lfam>vagrantc is not around right now <lfam>Anyone else familiar with the dpkg / Debian / Ubuntu (!!!) packaging? <ieure>Nope. I've used it on Debian, both hardware and in a container, without issues. <ieure>I don't use Ubuntu for anything, don't like it. <vhns>Would it be ok to submit a patch that packages a program that may be used to connect to a nonfree network? <dariqq>i think this means that the guile that is being used is not compatible with the one that was used to build the .go files (but no idea how to solve it) <lfam>vhns: GNU doesn't really accept the idea of "free" or "nonfree" networks or services <ieure>vhns, I believe so, there's stuff like that in Guix already. <lfam>Like, is the internet a free network? <mra>hey, i'm trying to figure out where the gcc input for the `bash-minimal` package comes from to debug some weird issues that i'm having with some changes that i've made to derivations. this seems to be passed implicitly, but i can't figure out from where <gorilla>So after a minute of scrolling warnings, quix system image tells me `guix system: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory` <lfam>gorilla: Is the daemon even running? `ps aux | grep guix-daemon` <ieure>vhns, It's probably fine. Worst case, set up your own channel to host it. <ieure>One of Guix's best features is that it's extremely easy (relative to other distros) to set up your own channel that works just as well as the official one. <vhns>Does Guix have any stance on projects that use submodules? Git submodules, that is. I haven't packaged any of them, I just pull them in as-is. <gorilla>I didn't run the daemon. I didn't think it would be required to make a system image. <lfam>It's required for building anything, and Guix builds the images <mra>yeah, the daemon is responsible for managing the guix store <ieure>vhns, Submodules are fine, *but*, they're often used to vendor dependencies, which is generally frowned upon. <vhns>yeah, that is the case here <lfam>vhns: The project favors "unbundling". But, when I'm doing code review, I will accept the use of submodules uncritically <dariqq>vhns: i looked into packaging that application as well but gave up on unbundling the 17 (!) submodules <lfam>Unless they are really common things like zlib, and they are unmodified <lfam>It's basically luck of the draw depending on who decides to review your package <lfam>The important thing is that the submodules contain free software <lfam>We added the recursive? option to our git-reference procedure to support submodules. So it's not like they are forbidden <simendsjo>I just updated guix, and now stumpwm is idling at ~40% CPU and x at ~30%. Any other stumpwm users having similar issues? <mra>i'm not sure if this is absurd or not, but is there a way to completely nuke the guix store? <mra>i'm absolutely losing my mind trying to test this damn change... <Rutherther>mra: to absolutely nuke it you would have to manually remove it. But at that point don't forget to also remove /var/guix. And note that removing guix store is not going to fix any of your issues unless the issue is disk corruption <mra>Rutherther: yeah, probably not. i tried garbage collecting everything. i might restart the daemon too. i'm probably just overreacting to not understanding why the behaviour that i'm seeing in testing doesn't make sense <ieure>mra, Probably the best way to test is to use `./pre-inst-env guix system image' and run that in a container runtime or VM. <mra>ieure: oh, that makes sense <mra>the only remaining reason that i can see for my derivations not being substitutable is that `locale-directory` being non-substitutable is somehow propagating into everything <mra>it's my best guess, anyway <cbaines>mra, if you're still looking for bash-minimal, it's build system implicit inputs, and standard-packages in (guix build-system gnu) that you want to look at <mra>thank you very much! <vhns>Is there any recommendation as to whether include new package definitions at the top or bottom of the files? <cbaines>vhns, I don't think there's a strict rule, but avoid either the top or bottom since that raises the probability of merge conflicts <cbaines>some modules are roughly alphabetical, some group more by similarity <lfam>Heh, I always put mine at the bottom unless the module is sorted <lfam>It's true that it increases the chance of conflicts <lfam>mra: I saw your messages about nuking the store in order to be sure. It's tempting, coming from other types of systems. But on Guix, unless you suspect a hardware error or a non-deterministic compiler error, it's basically guaranteed to have no impact <mra>this is bizarre... every single `standard-package` except for `glibc` is marked substitutable, but when i construct the derivation, they're being fetched from cuirass <mra>lfam: yeah, i think i was just getting annoyed lol <mra>sorry, i meant non-substitutable in the above <lfam>I used to know this stuff pretty intimately, but now I've forgotten. Does the substitutable keyword change the package derivation? <lfam>I tested and the answer is yes <mra>lfam: yeah, it's an argument passed to the `derivation` function, ultimately <mra>it sets the "allowSubstitutes" environment variable, which I guess is for the daemon? <lfam>Have you tested building one of the derivations directly? Like with `guix build /gnu/store/...-foo.drv`? <lfam>I edited the dvtm package (my favorite test package) to include '#:substitutable? #f'. When I build that derivation, Guix actually compiles it. When I build the unedited package derivation, I get a substitute. So, the mechanism does work, in general, as of Guix commit dd1f05edab0a375a53bb489173489025498a38cb (recent) <lfam>To be clear, I use `guix build -d dtvm --no-grafts` to get the derivation file name for testing <lfam>I'm assuming you are testing a more general application of this option, right? <mra>i'm trying to change how `derivation` works so that derivations which take non-substitutable input cannot be substitutable, which i didn't think would be an issue in general, since so few packages are non-substitutable, but it seems like this change is making a lot of packages be marked substitutable? <lfam>Right. Whereas before they were not marked either way <mra>dammit, sorry, i keep kludging my words <mra>i meant it's making a lot of packages be marked non-substitutable <lfam>I tend to kludge my words when I'm on a roll. Thinking too fast to type <mra>it should probably be noted that i don't know what i'm doing <lfam>Note that there are different levels of graphs that can be explored with that tool, and the default is rather superficial <lfam>It's possible that you are effecting a change deeper in the graph than you realize <lfam>But also possible that your code is just not right since, as you say, you don't know what you're doing :) <mra>lfam: yeah, all of this seems very possible! i'll check out the dependency graph <aure84>flypaper-ultimat: thanks for the advices earlier today. It seems that the `guix gc --references` command would require a non-read-only /gnu/store filesystem. Since I'm building a qemu vm I could not run the command successfully. I suppose you did run it on your own host system. Any advice/workaround? <Rutherther>guix gc references shows you references of a store path, there is no reason it would require non-read-only /gnu/store filesystem. <Rutherther>in fact, no guix command requires non-read-only /gnu/store filesystem, the daemon makes sure to unlock it for writing when it needs to write something <lfam>What Rutherther said. Also, `guix gc --references` doesn't query /gnu/store, but rather the Guix database in /var/guix <aure84>Rutherther, lfam, it makes sense what you say. I would have thik the same. However, after assembling the qemu vm. I enter and `guix gc --references` yields: `guixgc: error: changing ownership of path '/gnu/store': Read-only file system` <lfam>What argument did you give to `guix gc --references`? It requires an argument <lfam>Also, did you do anything unusual in the config.scm you used to generate the VM? <lfam>I can reproduce it in a VM built from the bare-bones template <lfam>Not sure what's up there <aure84>guix gc --references /gnu/store/...-shepherd.conf <aure84>well, I'm quite fresh so I'm not sure what would qualify as 'unusua' :) <lfam>Nothing, as it turns out :) Since it occurs with the bare-bones OS template <lfam>Well, since you hit this roadblock, what are you actually trying to do? <aure84>bottom line I would like to `herd load root /gnu/store/...` to debug a custom-made service. Any workarounds or better workflows for debugging? <lfam>Well, the `guix system vm` is by definition immutable, so not useful for many tasks. Have you tried making a regular VM? <lfam>Something like `guix system image --image-type=qcow2 --image-size=10G config.scm` <lfam>Then you run it with QEMU: `qemu-system-x86_64 -nic user,model=virtio-net-pci -enable-kvm -m 1024 guix.qcow2` <lfam>You'd have to copy the VM image out of the store and chmod it to be writable <aure84>ohm, I haven't tried that. I could give it a try :) <lfam>And when using qcow2, the image file doesn't actually take up 10GB of space. It grows as necessary <aure84>lfam: do you have any tips to transition from vms to barebone installations? I'm interested on developing embedded systems that will eventually go to real hardware <lfam>To adapt the bare-bones template from a VM to real hardware, you'll need to correctly declare the bootloader and file-systems in the template. Depending on your hardware, you might also need to set some kernel arguments or add some kernel modules <Rutherther>aure84: why did you want herd load root for debugging a service anyway? why didn't you add that service directly to your system's config that you then guix system vm? <aure84>Rutherther: I'm writing the service...with not a lot of knowledge or fortune. flypaper-ultimat was helping me earlier today with that tip (he/she was able to find issues that way) <aure84>lfam: thanks. I'll follow up the conversation in guix-devel <lfam>Maybe it's expected, idk. <lfam>It could also be that the error message is misleading. It happens <civodul>lfam: hey! short answer is yes, it’s expected <lfam>Hi! Okay! I'm curious, what's being written? <civodul>the daemon assumes it can write to the store, but it can’t <lfam>But, for checking references, isn't it just a database query? <civodul>i think when you do an add-to-store RPC to add a file, it adds it whether or not it already exists <civodul>so in your example, it must be trying to add that .patch file to the store <lfam>Hm, I only "understand" this stuff at a very high level, but the file is already in the store <old>is it possible to make a native-inputs optional? I have a package that I want to build with --system=powerpc64le-linux, but one of the native-inputs is not supported for this arch <old>however, this native-inputs is entirely optional for the building <lilyp>you should be able to use the same optional input pattern as with regular inputs <old>the optional inputs itself failed to compile for powerpc <old>I could try to remove it from the list of native-inputs <old>wonder if --with-input=package= could do? <lfam>old: Look at the brltty package. It has an example <old>hmm I could get the bootstrap done for powerpc, but whenever my package gets compiled I get: <old>@ unsupported-platform /gnu/store/rnfiprqfwq25ald53blw74s1svd3wyvr-libsk-0.1.0-pre.drv powerpc64le-linux while setting up the build environment: a `powerpc64le-linux' is required to build `/gnu/store/rnfiprqfwq25ald53blw74s1svd3wyvr-libsk-0.1.0-pre.drv' <old> but I am a `x86_64-linux' <old>I don't have any problem compiling for aarch64 and armhf :/ <old>this looks like an error from nix builder <old>I did not configured binfmt for these platform <gorilla>with the daemon running, guix system image gives me a minute of warnings, then starts down a list of what looks like package names and freezes half way through subversion. <gorilla>Subversion? whaat? Ok. I guess. But the freezing is no bueno. <gorilla>(operating-system %simple-os) might be a little heavier than I was hoping. <eikcaz>wow, 2 hours to download a texlivetexmf substitute <gorilla>killing and re-running is surprising, though. It seems to start from subversion, or where it left off. That's cool. <gorilla>FWIW, the manpage for guix-system seems to be misformatted <old>hmm I guess there is no substitute available for riscv64 and powerpc <old>bootstraping foreign architectures is so long <old>i wouldn't mind if bootstrap substitutes were available for all systems :-) <podiki>gorilla: oh? "man guix-system" looks fine on my end <old>podiki: Feb 10 2025 12:47:02 (current) <old>maybe I'm too recent? <old>to have substitures for forein archs <podiki>old: you can check with guix weather i think (specify --system) <podiki>e.g guix weather gcc-toolchain --system=riscv64-linux shows a sub on bordeaux <podiki>gorilla: maybe a terminal setting? i just checked on foot as that's what i'm using currently <old>podiki: weird I do find the substitute now <old>even though my package build is trying to build glibc <old>it tries to apply a graft <old>is there a way to ask guix to not build a dependency is a substitute is not available? <old>I know I can just pass --no-grafts now and get the substitute I want from bordeaux <podiki>what do you mean not build a dependency? <podiki>maybe you mean like --keep-going if you are trying to build a bunch of packages but one fails <old>For example, if glibc is not available for powerpc-linux as a substitute <old>just abort the build of my package on that system <old>no I want to abort the built entirely. I want to avoid wasting building glibc and gcc whenever a substitute is not present for example <old>but I'm okay with building a small dependency <old>it's just that these are big dependencies <old>podiki: thanks for guix-weather btw, TIL <podiki>i don't know of any built-in options that are directly like that <df>old: I haven't found a way to do it in general <df>but you can ask guix upgrade not to build specific packages with --do-not-upgrade <df>so that's generally what I do when I see it start to build firefox or something <podiki>presumably the info is there between guix weather, so maybe you could hack something together (either in guix or shell script) without too much difficulty? <jaft_r>ngz: do you use any web browser plugins with KeePassXC? <sturm>hi folks, I'm having some trouble with `guix deploy` to Hetzner. I'm getting '[GSSH ERROR] Unable to import a key from the file: "/home/ben/.ssh/id_rsa"'. Feel like I must be doing something silly, but that key file path is right - I'm running the command as the same user who owns the key <sturm>I'm using the example config from the docs with minor changes <df>sturm: maybe check that the private key file is not world-readable (perms should be -rw-------) <df>and that it is actually a private key, don't post it obviously but the file should start with ----BEGIN RSA PRIVATE KEY---- <sturm>thanks df, permissons are 600 and the contents looks correct. I'm using it daily for SSH, so no issues there that I'm aware of <df>that's it for obvious ideas from me then I'm afraid :( <df>if you're using it successfully for normal ssh then I guess it must be something guix or guile specific (I assume gssh is a guile ssh lib?) <df>so, I'm trying to make a build fail and failing... <df>basically, I'd like to do a full rebuild from scratch of a package (girara), including downloading the source, but not building all the dependencies from scratch <df>but it looks like I have the source cached somewhere in my store, and --check doesn't force it to re-download <podiki>probably doesn't fail as guix sees in the store the source it needs already (by name and hash) <podiki>you can add a phase that will fail (like (error "blah") or something like that, try to chdir to something that doesn't exist, whatever) <vagrantc>you might get something like: guix gc --delete $(guix build --source SOMETHING) <df>so... is there a way to say "no, I really want to build this totally from scratch", like even in a container running a private build daemon if necessary <vagrantc>basically you have to remove the stuff from the store, otherwise it will use the stuff already in the store <podiki>need to gc, and then build with --no-substitutes <df>will no substitutes not rebuild all the inputs as well though? <df>so... I've done the gc delete command <df>now guix build --check --no-substitutes girara? <df>and suspiciously quickly too <df>worked as in the build command succeeded :D <df>will try, just checking the source hasn't reapppeared <df>the directory I gc --deleted is certainly still not there <meaty>I'm having an issue packaging a repo where setting up the configure flags for tests leads to ONLY the test binary being produced. How can I "build the repo twice" with different configure flags so that I can both test and have the target binary?