IRC channel logs


back to list of logs

<drakonis>gash is very basic though
<vivien>So, I rebooted. I had no more funny files in /tmp, but still nautilus, epiphany and the system preferences dialog all froze, and I had no network connection this time (I’m connected via a wire). I had to manually run dhclient to report to you :(
<nckx>OK but have you seen ,bournish.
<drakonis>you can invoke guile functions with it but not a lot in the way of advanced shell functionality yet
<nckx>It's far worse^Wunbloated.
<nckx>Unencumbered by features.
<drakonis>unencumbered by the ability to do anything
<drakonis>getting gash and gash-utils up to snuff for usage inside guix would be a killer app :V
<nckx>I'm being unfair; it's better than nothing, and sometimes it's all there is besides a whole lot of nothing.
<nckx>But yes ‘gash in initrd when’ absolutely yes.
<jonsger>ah command back, its not XFS fault. Its just mine ^^ -> (flags '((create-mount-point? #t))) is a bad idea. you will see on your next boot...
<nckx>I will happily stare uncomfortably long at random other people to help make this happen.
<nckx>jonsger: Oof.
<vivien>The sad thing is I can graphically log in as root and open nautilus, no problem.
<jonsger>the best thing I corrected this syntax error for one mountpoint but overseen it for another ^^
<nckx>jonsger: It's a funny error (how did you get… there?) but worth a bug. These aren't strings passed to the kernel so there's no excuse for any run-time error.
<vivien>Oh, it opened!
<jonsger>ehm. don't know. I looked into the manual, didn't read it really and thought thats how one should do it. no errors during reconfigure -> all right. reboot 5 days later -> uff...
<nckx>Yeah. It's perfectly possible to validate all flags at reconfigure time (unlike mount options, where the best we can do is ‘is it a string? great’).
<jpoiret>nckx: im gonna catch some zs but expect patch v2 tomorrow with some changes
<jpoiret>only one swap-space record with priority and discard? fields, the rest is pretty much the same (will write doc tomorrow too)
<jpoiret>hibernation support is the next goal
<jpoiret>but that'll be a bit more *dangerous* as i'll have to change how the early userspace does its things + you can lose data if you mess up
<jpoiret>also I'll look into adding luks2
<ajarara>wait, you mean luks2 support for grub? Exciting!
<bdju> hit this issue during updates with openjdk. never seen it before. "Error decoding the received TLS packet."
<bdju>network issue on my end maybe? I'll try updates again
<jonsger>nckx: :)
<vivien>I’ve got a few new warnings: when I run dconf-editor, I get: "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/ version `GLIBC_2.33' not found (required by" and then a bunch of libraries: libproxy, gnutls, libgvfsdbus, libgvfscommon)
<nckx>jpoiret: Same re: zs. I'm not against adding uswsp, just about downgrading to it for *all* set-ups, even the IMO common/‘normal’ ones that don't need it. Involving user space at all is extra fragility and hibernation of all things should be stupid, simple, and reliable.
<nckx>There's no reason to leave the kernel when there's no reason to leave the kernel :)
<nckx><you can lose data if you mess up> This, but the ‘you’ who loses data is very likely not the ‘you’ who messed up, and now you have two people feeling terrible instead of one just feeling sheepish.
<nckx>Anyway, let's both go chase those zs. Night jpoiret; all.
<nckx>jonsger: Thanks!
<jab>drakonis: and nckx would it be worthwhile to port the scheme-shell back to guile again?
<drakonis>i dont know, wouldnt it?
<drakonis>it would certainly be quite good
<jab>it seems to be one of the "better" scheme shells...
<breatheoutbreath>Hello! I'm having an interesting problem with gpg-agent and pinentry.
<breatheoutbreath>I have installed gnupg and pinentry declaratively in one of my profiles.
<breatheoutbreath>When I run `echo test | gpg --clearsign`, I get
<breatheoutbreath>gpg: signing failed: No pinentry
<breatheoutbreath>Then, if I go ahead and run `guix install pinentry`, everything works as expected
<breatheoutbreath>From the mailing list and IRC logs, I learned that I must specify `pinentry-program` in .gnupg/gpg-agent.conf
<jab>breatheoutbreath: I wish I knew how to help you. I have up using gpg a while ago. I could get it to work for a while, and then not so much...
<jab>sweet action, my opensmtpd service works for (service opensmtpd-service-type (opensmtpd-configuration)) now I've got to try stress testing it...
<breatheoutbreath>jab: Thanks for the condolences ;)
<jab>yup. :)
<vivien>Maybe my problem is I’m running a guix home from master in a guix system from core-updates-frozen, I’ll bring the home to core-updates-frozen too to see if it persists...
<vivien>(oh no I have to recompile qtwebengine for jami)
<GNUHacker>yeeeah Im Guix System user :DDD
<GNUHacker>new user
<GNUHacker>how i update all my packages? guix package -u ? need I do guix pull before ?
<raghavgururajan>rekado: Glad! I only updated and added new core libraries. mothacehe updated the main packages. Also, couldn't have done without the help from lilyp and maximed.
<breatheoutbreath>GNUHacker: yes, guix pull before
<raghavgururajan>GNUHacker: FYI, `guix package -u` upgrades the packages in your user profile. To upgrade/reconfigure your system, you need to do `guix system reconfigure /path/to/config.scm`.
<vivien>And guix pull before each.
<GNUHacker>breatheoutbreath, raghavgururajan thanks
<breatheoutbreath>GNUHacker: welcome :)
<jab>vivien: why does it require qtwebengine?
<jab>GNUHacker: awesome! welcome to the exclusive club!
<jab>GNUHacker: I seem to recall that you need to do a "sudo -E guix pull" ... at least once...
<vivien>jab, I don’t know, maybe the devs prefer it.
<jab>vivien: ok. is the whole thing built on a web browser? Is that how it's displayed?
<vivien>I don’t have that feeling, there’s no URL bar, back button, refresh, … or other web browser UI elements.
<breatheoutbreath>I solved the gpg issue I ran into earlier. In `~/.gnupg/gpg-agent.conf`, I had specified `pinentry-program pinentry`, when it was necessary for me to specify the full path to the program.
<breatheoutbreath>so with `pinentry-program /home/joseph/.guix-extra-profiles/base/base/bin/pinentry`, pass and all my other goodies are working fine :)
<jab>breatheoutbreath: yeah. That is a slight annoyance with guix. many programs assume /usr/bin/program-name, which doesn't work in guix system.
<apteryx>breatheoutbreath: for what it's worth, it's supposed to work OOTB without specifying pinentry-program since commit c7af9d0b5ebaa1fdb08ff5d8a56004998bcd8103 (Mar 26 2020).
<apteryx>gnu: gnupg: Use ~/.guix-profile/bin/pinentry by default.
<apteryx>so I guess either you must specify the full path if you use pinentry-program; else not specify it at all
<apteryx>I personally have the former, since my setup predates said commit
<apteryx>uh: guix: offload: command not found\n hint: Did you mean `offload'?
<apteryx>could be that I'm running my own daemon locally with sudo -E ./pre-inst-env ./guix-daemon --build-users-group=guixbuild --max-silent-time 0 --timeout 0 [...]
<apteryx>seems like it
<apteryx>sneek: later tell civodul thanks for the better ergonomics of 'guix shell' ;-)
<sneek>Will do.
<apteryx>vivien: the qtwebengine is used by jami-qt for the 'chat view'; mainly for rendering URL previews. Since URL preview is optional, I think it should be possible to make the dependency on qtwebengine optional too. That'd greatly shrink down the closure size of jami.
<apteryx>talking about jami, here's perhaps the first use in the wild of 'guix pack -f deb':; to see exactly how it's produced you can have a look at the Makefile here:
<podiki[m]>vivien: also seeing some odd GLIBC errors on core-updates-frozen (and not on Gnome) like `/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/ version `GLIBC_2.33' not found (required by /gnu/store/pir0fgniik2ca63fmh8qq9piinz19k5k-libproxy-0.4.17/lib/
<podiki[m]>Failed to load module: ~/.config/guix/profiles/desktop/desktop/lib/gio/modules/`
<apteryx>mbakke: I've refreshed the cufbc branch if you'd like to try e8a843a265 gnu: elogind: Update to 246.10.
<bdju>which browsers on guix work for video conferencing? I might need to do it soon for an interview. I've avoided having to figure it out until now
<bdju>qutebrowser audio is broken for me so I'll have to at least use icecat or something, but I don't know if webrtc and such work in icecat
<bdju>I'll grab ungoogled-chromium-wayland and experiment with stuff later
<rekado_>I see that LD_LIBRARY_PATH is still set even on Gnome 40.
<rekado_>podiki[m], vivien: have you upgraded your user profile to core-updates-frozen as well?
<rekado_>I don’t see these glibc errors.
<rekado_>since yesterday I’m trying to build ungoogled-chromium…
<davidl>I am preparing a patch series and I am adding a package in python-web.scm but also dependencies in python-xyz.scm and databases.scm, however, the dependencies are not recognized when I try to build with ./pre-inst-env guix build -K ... even though the dependency modules are loaded from python-web.scm. This is the backtrace Im getting:
<davidl>I started from commit 0a42998a50e8bbe9e49142b21a570db00efe7491 from yesterday and have added 3 packages in individual commits since then, but cant add the final package python-flask-combojsonapi
<davidl>(which otherwise builds fine if all the dependencies would be put in the same module)
<efraim>davidl: I don't think you need the -L $(pwd) with ./pre-inst-env
<davidl>efraim: true. I added it for testing things when stuff didn\t work. I solved it now though: I have a separate guix channel with a package of the same name that I was trying to add, so after changing the package variable name it started working.
<dragestil>i just installed guix on a debian system, and i can't get rid of the warning about locales even though i installed glibc-utf8-locales and exported GUIX_LOCPATH
<dragestil>does anyone know how i can fix this
<dragestil>(my third try on guix ;)
<dragestil>the warning is: hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package and
<dragestil>defining `GUIX_LOCPATH', along these lines:
<vivien>rekado_, I’m trying, but there are quite a few packages that are failing to build and that I must disable.
<thorwil>dragestil: well, i gave up on trying to get rid of that warning long ago. to no ill effect. :)
<dragestil>thorwil: ah ok, well i thought the warning has something to do with the error when i try to guix install nss-certs: Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert wide string to output locale" 84 #f #f)'.
<thorwil>what to do about a license like this? plus copies of LGPL-2.1 and MPL-1.1 from cairo
<thorwil>dragestil: maybe this helps
<dragestil>just read <>. tried a bunch of things mentioned there, but no luck :p (guix pull complains about certs which presumably should be fixed if i can install nss-certs)
<dragestil>thorwil: yup, i tried all of that, but the problem persists
<dragestil>ah, ok, editing guix-daemon.service fixed it. it was Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8, and i changed it to Environment=GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale
<dragestil>now it works
<dragestil>hmm, after installing nss-certs, guix pull still complains about ssl cert being invalid
<jpoiret>I think I had some certs problem when using guix for the first time on debian
<jpoiret>You can 'guix pull --url=http://git.savannah.. ..' to pull the newest guix first
<dragestil>will this fix future pulls?
<rekado_>vivien: could you please share the list of packages that fail? It’s good to have a public record so we know what packages need our attention before the merge.
<rekado_>I fixed all packages in my profile already, and a lot of bioinfo tools, but there are still some packages (dependencies of pigx) that are failing.
<jpoiret>This is dragestil
<dragestil>jpoiret: thanks
<davidl>I sent in a patch series but accidentally sent it to bug-guix instead of guix-patches - does it matter or should I resend it?
<dragestil>it's kinda weird because with --url http://... guix decided to download from https://... anyway
<dragestil>ah it's not git.savannah
<mothacehe>apteryx: i fixed the core-updates-frozen-batched-changes evaluation in the CI
<mothacehe>running make cuirass-jobs gives much more info than the Cuirass evaluation logs, something to fix here probably
<qzdlns[m]>hi guix
<thorwil>can anyone here build faust@2.5.23 successfully?
<breatheoutbreath>apteryx: thank you - my setup is new, and I think I was getting the same issue even without `pinentry-program` specified in .gnupg/gpg-agent.conf
<breatheoutbreath>I'll do some testing and report back :)
<rovanion>Congrats on `guix shell`!
***wjc is now known as wonko-tmp
<thorwil>so foo-yc20 in the 1.3 release packaged aparently doesn’t implement LV2 like it is now. plugin won’t even be listed in ardour and ingen.
<thorwil>foo-yc20 git doesn’t build with faust-1. faust-2 itself fails to build here.
<thorwil>is the universe trying to tell me to forget about that one plugin? :)
<efraim>civodul: I almost have python-aiohttp test suite working. Adding python-pytest-6.1 brought the test failures down to 12
<jpoiret>what do we think about renaming root-file-system to file-system-/? I'm currently finishing the touches to the swap rework, and noticed that I naturally added the root file system to the list of dependencies of my swap file *twice*, so that might be something that people will mistakenly do
<jpoiret>since the root file system service doesn't follow the convention, this will prevent the service from starting up, but with the renaming it would work
<abrenon>hi guix
<jpoiret>mhmmmm, just noticed that mapped devices needed for boot don't get their own stub shepherd service entry, so might need to add that as well...
<wonko-tmp>I've got a bunch of broken things that I suspect all come from bad/weird permissions on the filesystem. Things are not readable for "other" in /etc for example: hosts, hostname, timezone, shells
<wonko-tmp>I ran a system reconfigure, but that didn't change anything
<wonko-tmp>where could this come from? how can I reset those permissions?
<wonko-tmp>maybe my umask as root during the initial installation from a foreign distro?
<civodul>efraim: nice, well done!
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, apteryx says: thanks for the better ergonomics of 'guix shell' ;-)
<jpoiret>wonko-tmp: that is very possible, it's all a+r for me
<jpoiret>wonko-tmp: is the umask on the foreign distro default?
<efraim>civodul: well that was a rabbit hole, python-pytest-mock was propagating python-pytest-asyncio and that was causing the remaining test failures. tests pass!
<wonko-tmp>jpoiret: 0022
<wonko-tmp>0027 currently on guix
<wonko-tmp>how should I rebuild a system with correct permissions? system reconfigure didn't change anything
<jpoiret>i think you're right, most directories created by init don't have an enforced mode
<jpoiret>wonko-tmp: maybe we can patch this quickly and you could guix system init again? or i can give you the list of dirs that should have their perms changed
<jpoiret>you can find the directories created by init here:
<jpoiret>if they have a mode then it should be all good, but be sure to change the permissions of the others
<jpoiret>although is the mode inherited by the directory it's in?
<wonko-tmp>jpoiret: I can test init after a patch if that helps
<jpoiret>if you can afford to that would be great
<jpoiret>uhm but you mention umask is 0027 on guix and 0022 on foreign, that means that foreign grants by default *more* permissions than guix
<wonko-tmp>but I only did the init on foreign
<jpoiret>how is umask 0027 on guix i wonder, mine is 0022
<jpoiret>logging in with root also grants 0022
<jpoiret>that might be it, rather than the foreign distro
<wigust>hi guix
<jpoiret>wonko-tmp: are 'umask' and 'sudo umask' the same on your user account?
<wonko-tmp>su -> umask is 0022, sudo su -> umask is 0027
<wonko-tmp>as user umask is 007
<jpoiret>alright yes that's it
<jpoiret>sudo looks at the current umask and ORs it with the default one
<jpoiret>so when you sudo guix system reconfigure, it has the wrong umask
<jpoiret>should we set a default umask when calling guix system commands?
<wonko-tmp>I vote yes
<jpoiret>or we could print an error and exit when umask is not 0022, instead of silencing the warning
<jpoiret>i'll go eat something and look at that afterwards
<bost>Hi. Does anybody know how to install pdflatex? Searching with `guix package --search=pdflatex` returns no usable information.
<sneek>bost, you have 1 message!
<sneek>bost, bdju says: did you have audio when you tried qutebrowser?
<jpoiret>bost: i believe it is texlive-bin
<bost>jpoiret: Indeed! The pdflatex *is* in the texlive-bin. Thanks!
<bost>bdju: you asked me on 2021-10-20 if I had audio in the qutebrowser. ( I removed it from my system on the same day and now I installed it again and the audio works.
<excalamus>good morning, Guix
<vivien>rekado_, and others, it seems that I have identified some packages that I can’t install on core-updates-frozen, because they don’t build or a dependency fails: deja-dup, deluge, gnunet, unison, yt-dlp (it has not been merged from master yet), frescobaldi, gnome-builder (it needs to be updated too), emacs-tuareg.
<vivien>And guile-gi, I forgot.
<pinoaffe>hi guix! I'm looking into packaging emacs-mentor (a torrent client for emacs based on rtorrent) - it can connect to "external" rtorrent processes, or it can launch and manage it's own rtorrent process - in the latter case it needs an rtorrent binary, in the former it does not
<pinoaffe>should rtorrent be a dependency of emacs-mentor?
<pinoaffe>and if so: by default, emacs-mentor looks for the rtorrent binary in PATH, should this be patched out so that the rtorrent binary location is hardcoded in the lisp source, or should rtorrent be a propagated input?
<vivien>What do you mean, external? If it is expected to run on the same machine, then I guess emacs-mentor can’t work without an rtorrent, so it is a dependency.
<pinoaffe>vivien: it can connect to rtorrent via a socket, via http, etc
<pinoaffe>never mind, vivien is gone
<jpoiret>i don't think it should be a dependency
<jpoiret>if the user wants to run their own rtorrent, then they should install it alongside in their profile
***brettgilio7 is now known as brettgilio
***herlocksholmes1 is now known as herlocksholmes
<excalamus>hooray! FINALLY got icons to show up in the Plover gui. Looks like Qtsvg was missing
<excalamus>so, I guess that would need to be listed as a propagated-input?
<mbakke>excalamus: looks like another instance of
<mbakke>excalamus: it's better to 'wrap' the executable with the required variables (QT_PLUGIN_PATH?) instead of propagating
<mbakke>if the package uses cmake-build-system, you can switch to 'qt-build-system' to make the wrapping happen automatically
<excalamus>propagating seemed extreme
<excalamus>it uses python-build-system
<davidl>Hi, would someone like to review my 4 patches for a python package w/ dependencies?
<excalamus>export QT_PLUGIN_PATH= and restarting Plover, there are no icons, so I assume that's what needs wrapping
<excalamus>so, my question is, how do I wrap the executable with the environment variable?
<davidl>excalamus: there is a procedure simply called wrap-program
<excalamus>okay, I see it in some other definitions. Thanks
<vivien>deja-dup needs an upgrade on core-updates-frozen so that it can build:
<jpoiret>hmmmm, are there any disadvantages to %guile-static-stripped instead of guile-3.0?
<jpoiret>i'm wondering if we could simply launch shepherd in early userspace and let it handle everything 🤔 that'd be a nice experiment I guess
<ajarara>new to mailing lists, if I email the debbugs ID, does that 'bump' the thread?
<apteryx>sneek later tell mothacehe thank you for unlocking cufbc on the CI! What was it related to? Was it a Cuirass issue, or something else? I've recreated the branch, and Cuirass has yet to rebuild it it seems (~9 hours ago)
<jpoiret>ajara: you mean the one on ?
<jpoiret>if so no
<ajarara>no, the mailing list to contribute patches
<ajarara>Looks like it does if you go by date. (the email I have there is on an older thread)
<DynastyMic>Hi, I'm trying to fix the latex2html package that is already in gnu packages
<DynastyMic>However when trying to actually use it (i.e., latex2html file.tex)
<DynastyMic>it brings the following error: Error: '/tmp/guix-build-latex2html-2021.2.drv-0' not usable as temporary directory.
<DynastyMic>What could be wrong?
<roptat>hi guix!
<roptat>DynastyMic, that's an interesting error message
<roptat>looks like it records a temporary directory name at build time?
<abrenon>hi roptat
<roptat>DynastyMic, maybe try to run with "-tmp" option?
<roptat>mine is even less happy: "Error: No such image type ''." :/
<civodul>efraim: congrats!
<apteryx>uh openssl@1.1.1l: can be upgraded to 3.0.0; is there a reason we stick to 1.1.1 on core-updates?
<DynastyMic>roptat, yeah that was the mistake I'm trying to fix
<DynastyMic>it seems it lacks a few dependencies
<vivien>I’m back from my core-updates-frozen excursion. I noticed a few failing packages, the impossibility to run a new guix system with a guix home from the other branch, and a weird thing where network manager creates a new interface for wired connections, but I don’t know if that is reproducible.
<DynastyMic>so I'm trying to add them
<DynastyMic>when using -tmp, drops the following: Error: 'try.tex' not usable as temporary directory.
<vivien>I have yet to report guile-gi failing and frescobaldi, but I want to try and patch them first.
<apteryx>vivien: thanks for trying it out!
<roptat>DynastyMic, you need to say something like -tmp=/tmp
<roptat>(well that's my vague understanding of the code ^^')
<talos>Hi guix! Is there any official Guix dev here? Just a quick social media related question... does Guix use Mastodon any?
<apteryx>OK, openssl 1.1.1 is LTS
<vivien>Also, I’d like to have gnome-builder, but it is a pain to update because it requires the latest version of glib.
<apteryx>3.0.0 will probably break many things that'll need to be ironed out in time
<roptat>talos, there's no official mastodon account, but a lot of us are on mastodon
<talos>As in, do they have an account on there I can follow lol
<talos>Well, that answers that! Just wondering lol
<roptat>apteryx, this morning I saw some CVE on webkitgtk, tried to fix it and in the end we need a newer version of glib that on master or wip-gnome
<DynastyMic>roptat, it actually worked
<roptat>talos, #guix receives one or two toots a day
<talos>roptat: I see!
<DynastyMic>so one should always use the -tmp=/tmp flag?
<vivien>talos, I think you can set up a CI server and notify you on mastodon, if you want to socialize with bugs.
<DynastyMic>sorry, I'm new to linux in general
<talos>vivien: Thnx!
<vivien>Otherwise, look at #guix on big servers, there are a few people talking about it :)
<roptat>DynastyMic, maybe we can add a phase to fix that; looks like we want to fix $TMP in bin/latex2html
<roptat>I have no idea why they think the build directory is a good temporary directory instead of $TPMDIR or similar...
<DynastyMic>so is that a bad practice?
<DynastyMic>should i change it in the guix package somehow?
<roptat>that would be ideal if you can make and send a patch
<talos>vivien: I getcha
<roptat>maybe we should discuss it with upstream too
<DynastyMic>so shuold i use $TMPDIR or $TMP
<talos>I'm on 3 mastodon instances, might as well follow the #guix hashtag on all 3 lol
<roptat>DynastyMic, ideally you would create a patch for latex2html, to read $TMPDIR (the environment variable) by default and put it in $TMP (the perl variable)
<roptat>but looking at the code, we could as well set TMPSPACE at configure time, though I'm not sure how
<DynastyMic>right, I'll reach the latex2html devs then
<DynastyMic>to see how could we fix that
<DynastyMic>thank you~
<roptat>looks like this line is the one that ends up in our package:
<jonsger>nckx: do you know if the path under which PPDs for cups are saved is arbitrary? or is cups expecting something like share/cups/model/MANUFACTURE/name.ppd ?
<roptat>so maybe just add #:configure-flags '("TMPSPACE=/tmp") in the package arguments
<DynastyMic>let my try that
<apteryx> roptat newer than 2.70 ?
<roptat>ah no, I think it was >=2.69
<apteryx>then cufbc has it
<apteryx>and it has webkitgtk@2.34.0 (updating to 2.34.1 just now)
<roptat>is it on savannah? I don't see it
<apteryx>it is!
<apteryx>uh, unless I forgot to repush it
<roptat>I don't see it in the list:
<apteryx>my git push yesterday late night must have failed or something
<apteryx>sorry about that, will shortly
<DynastyMic>roptat, already added the #:configure-flags
<DynastyMic>still the same error (i.e., Error: '/tmp/guix-build-latex2html-2021.2.drv-0' not usable as temporary directory.)
<roptat>yeah, it doesn't seem like you can set TMPSPACE in any way from the configure script
<DynastyMic>so should i reach latex2html devs?
<DynastyMic>i could work with the tmp flag by now
<DynastyMic>and push the fix to guix whenever it is ready
<roptat>I think it's our best option; maybe also send a bug report to bug-guix, and link to your issue with upstream
<roptat>so we can follow progress
<DynastyMic>I'll do it right now
<DynastyMic>I'm so embarrased to ask you this
<DynastyMic>but, what is the upstream problem?
<roptat>don't feel embarrassed, it's ok :)
<apteryx>my substitute server started throwing: "guix: offload: command not found" errors as of late. I guess it needs an updated guix-daemon, but I'm puzzled as to what causes it. ideas?
<roptat>I think the problem is that we don't build with latex, and in that case, the temporary directory is set to whatever @TMPSPACE@ is set to, which seems to default to the current directory, but the directory doesn't exist after the build on guix
<roptat>the issue is that, even though config/ seems to be able to set TMPSPACE, there doesn't seem to be any option in the configure script to call it with that option (
<silicius[m]>Is there a list of all the env variables that a Guix user should declare in their shell profile?
<DynastyMic>oh yeah, since guix uses the /gnu/store and all that jazz, right?
<DynastyMic>thats why it doesn't exist
<roptat>DynastyMic, well not necessarily, it's just that it builds in /tmp/guix-build-... and that's only a temporary directory that disappears after the tool is installed
<roptat>so, most distros would have the same issue
<DynastyMic>oh, yeah, I see
***cbaines_ is now known as cbaines
<roptat>unless we're doing something completely wrong, which can also happen ^^'
<DynastyMic>lol, maybe
<DynastyMic>then let me reach to the latex2html devs
<DynastyMic>and see if we're messing up
<roptat>thanks :)
<DynastyMic>thank YOU, you're smartest guix user I've ever met :p
<roptat>I'm a guix dev :p
<DynastyMic>lol, that explains
<DynastyMic>well I'm gonna go have breakfast
<DynastyMic>and then i'll do the work
<DynastyMic>see you =)
<roptat>thanks for your time :)
<apteryx>roptat: fyi, I also have a python-3.10 local branch but it won't make it for the next release -- it causes a couple silly issues with a deprecated namespace, got stuck on mozjs
<roptat>ok, I didn't plan to work on this anyway
<roptat>I want to focus on OCaml for a bit, I'd like to get rid of most ocaml4.07-* packages, and add ocaml 4.13
<apteryx>OK :-)
<civodul>an actual static network setup interface:
<civodul>roptat: ↑ :-)
<roptat>civodul, !
<civodul>IPv6 is the future!
<roptat>great work, thanks!
<civodul>(has been for so long)
<civodul>lemme know if the interface makes sense
<civodul>also on the "links" thing, which i don't know how to use
<roptat>I don't think the links thing is necessary
<roptat>well, you probably need it to set them up
<apteryx>weird, while building a guix in a derivation for 'guix deploy' is outputing: In procedure load-thunk-from-memory: ELF file does not have native word size
<civodul>the code already does (link-set device #:up? #t)
<roptat>so one issue I can see is that it probably won't work on the hurd
<apteryx>civodul: awesome!
<civodul>but i thought maybe there are some cool secret things to be done with links?
<roptat>unless they implement netlink too
<civodul>no, the Hurd won't implement links
<civodul>but that's okay, we can still provide that interface
<roptat>yeah, you can create a veth pair, and switch one end to another network namespace
<roptat>then you can get two network namespaces to communicate through the veth interface
<roptat>that's how we should reimplement networking in containers
<civodul>ah, see? i knew there were cool things of that kind to be done :-)
<civodul>does this interface allow us to do that?
<roptat>you can create the veth pair, but I don't have anything to manipulate network namespaces
<roptat>unfortunately my server is down again :/
<BlackMug[m]>hi there
<roptat>civodul, the example I have in the manual is (link-add "v0p0" "veth" #:type-args '((peer . "v0p1")))
<BlackMug[m]>guix-packages-base.drv.bz2 failed to build
<apteryx>seems to be building for i586-pc-gnu of my remote machine, although I haven't specified anything for that: warning: [...]: program "i586-pc-gnu-strip" exited with non-zero exit status 1
<roptat>this creates a veth pair v0p0 and v0p1 that communicate with each other
<BlackMug[m]>BlackMug[m]: anybody facing this error when upgrading?
<roptat>BlackMug[m], can you share the log file it created? (guix should have printed a message telling you where to find it)
<BlackMug[m]>the one which is saved as bz2 right?
<apteryx>uh, nevermind, that must be for my child-hurd service :-)
<civodul>roptat: nice; could you turn that into a commented example for the manual? it'd be great to have that!
<roptat>civodul, it's already in the manual, what do you need more?
<roptat>civodul, about the patch to allow cross-compilation, is there anything I can do in my repository?
<BlackMug[m]>@civodul IPv6 has privacy issues, did they solved? or not important
<zimoun>civodul, this moring I came with the idea to add an option to “guix describe” (for instance --archive) to send a save request to SWh for all the channels. WDYT?
<BlackMug[m]>roptat: the process killed due to signal 9 , 1 dependency couldnt be built
<BlackMug[m]>thats the terminal error message
<roptat>BlackMug[m], in the context of a static IP anyway, there's no more privacy concerns with IPv6 than IPv4
<roptat>zimoun, I think you can achieve the same with guix lint -c archival
<roptat>oh you mean channels, not packages in them?
<roptat>BlackMug[m], weird, maybe try again, or maybe it's an oom issue?
<zimoun>roptat, yeah channel :-)
<zimoun>now, one has to open my browser blabla.
<zimoun>The workflow for scientific folk would be: “guix lint -c archival” and “guix describe --archive”, then publish manifest.scm and channels.scm. Bang! Reproducibility for ever (on principles :-))
<BlackMug[m]>they solved them? MAC address and many stuff where horribly linked to the uniqueness of the IPv6
<jpoiret>hmmm, does anyone know how to add scissors lines in emacs when writing mails?
<BlackMug[m]>whats the command that debug the output from guix?
<roptat>BlackMug[m], if you choose the address yourself, it's unrelated to your MAC address
<roptat>your concern is about the address suffix when you switch network, which I think is fixed in many DHCPv6 implementations, and in Linux (when using RA)
<roptat>but that's not compatible with a static IP anyway, so your concerns are not valid for that case :)
<BlackMug[m]>i see, cant agree or deny been 10 years since last time i viewed ipv6 , it was piece garbage in all the ways
<BlackMug[m]>thats why i asked if they fixed it then yeah why not using it
<dissent>hey guys, currently unable to get past the tty. i'm attempting to go without gdm or any other display manager and log straight in through the tty. unfortunately when I invoke startx with xmonad it just goes to a black screen without anyway to backout or switch to another tty. any idea what could be the issue?
<BlackMug[m]>roptat: yeah seems to be out of RAM... :(
<apteryx>BlackMug[m]: you could try adding some swap, and after that's resolve configuring some zram.
<apteryx>you'll need to be very patient for the build though
<BlackMug[m]>i thought guix use substitute when using its own distro for its own packages
<vagrantc>anyone else notice python-numpy failing on core-updates-frozen?
<lfam>A kind of philosophical patch: <>
<lfam>Feedback is requested
<lfam>I think it's totally fine, but I don't want to push it without a consensus
<civodul>zimoun: re "guix describe --archive", why not; "guix describe" is not the best place for it, but i don't have any other idea
<civodul>lfam: b2sum isn't yet in master, right?
<lfam>It is
<vagrantc>lfam: wouldn't that still cause issues with offloading?
<lfam>I don't know, would it?
<civodul>it just made it, then?
<vagrantc>lfam: the issue is building for the local CPU? and if you offload to a machine with a different CPU ... wouldn't that ... cause issues?
<lfam>So, I guess the patch would also need to do '#:local-build? #t'
<lfam>I've never offloaded so it's not easy for me to answer questions about offloading
<podiki[m]>rekado_: I have updated my main profiles, but something weird in one of them (some package I need to remove maybe); I do have one set I bring from master though
<podiki[m]>rekado_: I'll investigate tonight. the only other thing on core-updates-frozen for me is wine (last I tried was failing due to gtk? maybe on i686?) and some python failures:
<zimoun>civodul: initially, I thought “guix pull” but it is worse. Then “guix describe”. Otherwise, a special under “guix git”. For insance “guix git archive-channels”. WDYT?
<podiki[m]>if batched-changes is built on the CI tonight, I will try that as well
<civodul>lfam: just replied; and yes, you need to disable offloading as well
<civodul>but really, "guix hash" FTW :-)
<GNUHacker>hi, Ive installed #icecat in guix system from guix package manager, how can I install locales/translations
<civodul>zimoun: maybe "guix git archive"? could apply to any Git repo
<lfam>I will benchmark `guix hash` and `cksum` :)
<lfam>Really, I'll probably use b3sum, which is incredibly fast
<lfam>What takes b2sum 12 seconds, b3sum needs ~1.5 seconds
<civodul>and does it actually compute the same thing? :-)
<lfam>It's a different algorithm
<civodul>ah right, so...
<lfam> <>
<lfam>But b3sum is a Rust program, which is still kinda poorly-supported in Guix
<civodul>not sure if efraim would agree :-)
<lfam>I think efraim would understand what I mean :)
<civodul>ah yes :-)
<lfam>I went to check on the supported algorithms in guile-gcrypt, based on this page:
<lfam>But it's a 404
<lfam>I guess it's kind of aspiration hyperlinking?
<lfam>`guix build guile-gcrypt` ftw
<civodul>"info guile-gcrypt"
<civodul>but they're not actually all listed :-)
<civodul>so you really have to check (gcrypt hash)
<civodul>(i went to Geiser, which helpfully shows available options for (hash-algorithm ...))
<lfam>Berlin is garbage collecting
<zimoun>civodul, you mean “git archive <url>”. For instance, it would become “guix git archive $(guix describe -f recutils | recsel -C -P url)” for saving the current channels.
<apteryx>arf... guix deploy: sending 298 store items (4,110 MiB) (because it won't know to copy /gnu/store/kbghqa2sgy630bi2p6y575kwz0v4lr08-remote-exp.scm.drv when using #:build-locally? #t)
<apteryx>that gexp is basically just: (primitive-load "/gnu/store/6nhnk471027c6wdd2v0ygcv3in4g0219-switch-to-system.scm")
<apteryx>s/#:build-locally? #t/#:build-locally? #f)
<efraim>what did I do this time?
<apteryx>that's by the way (the guix deploy annoyance/bug)
<efraim>ah, rust. I planned on overhauling all the inputs before packagecon but that's probably a bad idea
<lfam>You mean, overhaul how inputs are specified?
<efraim>I was going to shove cargo-inputs -> inputs and cargo-development-inputs -> native-inputs and then go around removing things and skipping tests until I made it work again
<lfam>It would be nice... I seem to remember that it's the way it is because there were a lot of dependency cycles
<lfam>But, we've worked around cycles before, within the regular dependency specification system
<efraim>and we had no way setup yet to use the sources, but now we're generating our own crates pre-patched with references to our jemalloc and stuff so it should just work
<efraim>I still have to try it, but using $GUIX_ENVIRONMENT/share/cargo/something as a local cache is something I'm aiming toward
<civodul>apteryx: re #46756, do you have a backtrace showing current line numbers?
<apteryx>it's not much:
<apteryx>but it seems somewhere in (guix ssh) it forgets on filter out the switch-to-system gexp file
<apteryx>forgets or filter out
<apteryx>civodul: actually I had tried understanding the issue in the past and had that backtrace (from a REPL I guess):
<apteryx>civodul: could it be that export-paths in (guix ssh) need its #:recursive? argument set to true?
<apteryx>haven't pk'd anything yet, but that's one thing I want to look at
<lfam>efraim: Sounds promising!
<jab>afternoon guix!
<mikolajw>Please update project URLs of packages kicad, kicad-doc, kicad-footprints, kicad-packages3d, kicad-symbols, kicad-templates to
<roptat>hi mikolajw!
<roptat>why? seems to be working?
<mikolajw>The project has moved to a new site in 2020
<mikolajw>Dick Hollenbeck, former project leader, has betrayed the community and sold to a third party
<roptat>ah I see
<mikolajw>The site is fake and probably used to host malware
<vivien>I don’t know anything at all, but are we sure it’s not the opposite?
<mikolajw>You can confirm that by checking our mailing list and forums. Several independent sources: digikey, hackaday, adafruit, also wrote about that
<vivien>Why do you say, "betrayed the community"? Reading that email, it looks like he forgot to renew the domain name.
<vivien>Also, wikipedia says
<vivien>Same for both and
<pkal>Hi, does anyone know how far back does time-machine works?
<pkal>In the sense of can I build packages from 2013 or something or has something changed since then?
<roptat>I think 2013 is too old
<jab>roptat: I was born in 1991...what does that say about me? :)
<pkal>roptat: Is there any other way to use older package versions besides time-machine?
<roptat>I think the earliest you can go is around 2018 (around that blog post:
<roptat>pkal, no easy way, but you could copy the package graph from back then and build it with a recent guix
<roptat>or create your own packages, use transformation options...
<vivien>I thought guix past was made to do that
<pkal>I am asking because I'd like to use Guix via sourcehut CI system to test Emacs packages on older versions. I am not sure if copying packages would work well in that case?
<mikolajw>vivien: he did not, the domain was due to renewal in 2023 to my best knowledge
<Olivetree>Hey! Any chance this doesn't happen after `guix gc'?
<Olivetree>Also, dvtm is broken for me: is not anywhere in my system
<apteryx>civodul: here's a fresh trace:
<apteryx>when building locally, the files sent are: ;;; (files-to-send/local-build: ("/gnu/store/0m0vd873jp61lcm4xa3ljdgx381qa782-guile-3.0.2" "/gnu/store/1q9118pw4d18ihj91csfilbg6x2x29am-module-import-compiled" "/gnu/store/ljs768gwp9dbd7y4y0ncyz4pdvsi8r92-remote-exp.scm" "/gnu/store/gai5i4ba2xf084big8h56q6pc0vwx2sj-module-import"))
<apteryx>so instead of sending the derivations, it sends the prebuilt items (...-remote-exp.scm instead of ...-remote-exp.scm.drv for example)
<Guest5195>Hi guix, I'm working on some home services. Some programs like oneko and workrave require the desktop environment to be running when they are started. How can I check for that?
<roptat>Guest5195, I think it's always the case? at least my understanding is that home services are started at user login, not at computer startup
<roptat>otherwise, it's probably in too early a dev phase to support that kind of thing
<roptat>(but help is always welcome, of course ;))
<jpoiret>did anyone receive my mail to bug-guix?
<roptat>jpoiret, if it's your first message it can take up to 24 hours for moderation to validate it
<roptat>I don't think we've received it yet, unless your name is very different from your nick
<jpoiret>oh yeah, i forgot bug and patch weren't the same list
<Guest5195>roptat My oneko services don't render to the desktop when I log in, I don't see them until I restart them. I suspect sleeping for a little may help.
<Guest5195>I'll test it. BRB.
<Guest12>I'm back. Sleeping for a second works.
<apteryx>civodul: the derivation sent is actually buildable; so it looks like something depends on it before it actually is built/finished building
***iyzsong- is now known as iyzsong
***potatoal- is now known as potatoalienfo13
***potatoalienfo13 is now known as potatoalienof13
<apteryx>appears related to the trampoline procedure in (guix remote)
<gbrlwck>hello guix! i've run into this:
<gbrlwck>is there an easy and guixy way to resolve this?
<excalamus>I'm trying to wrap a new build of Plover with the QT_PLUGIN_PATH. It's failing on "In procedure string-append: Wrong type (expecting string): #f". I copied the modify-phases code from obs and updated the bin path.
<excalamus>I'm not sure how to introspect the code, so it's not clear where it's failing and what precisely is going wrong.
<vivien>excalamus, if QT_PLUGIN_PATH is unset, then maybe getenv returns #f and wrap-program concatenates it with something else.
<vivien>Try displaying plugin-path
<vivien>I see no reason to believe QT_PLUGIN_PATH is set. You might need to set it up yourself.
<excalamus>okay, thanks
<nckx>jonsger: Good question. AFAIK, and reading CUPS's load_ppds(), layout is entirely arbitrary as far as CUPS itself is concerned. It just scans all of model/ recursively.
<roptat>gbrlwck, from what I see, you have mes in your profile initially but not nyacc; you try to install it but it fails because of a conflict; you print mes's version; you try to remove nyacc but it's not present since it failed to install
<roptat>gbrlwck, did you try the hint? "guix install nyacc mes"
<excalamus>honestly, I'm not sure what to do with that. Within the let form, I can put a format next to display and I don't see it in the output:
<gbrlwck>roptat: don't you think guix finds two different versions in my (user) profile?
<roptat>maybe we could make the hint a little more obvious, because understandable "upgrading mes" when "mes --version" says it's the latest version is confusing :)
<vivien>excalamus, the syntax is (format #t "Hiiii\n")
<nckx>excalamus: (format #t …) to print, (format #f …) to not.
<vivien>The #t is for "print to standard output)
<gbrlwck>roptat: the hint doesn't help (i get the same hint again)
<nckx>(format "…") is deprecated.
<apteryx>a pity; what beauty is there to (format #f ...) ;-)
<excalamus>okay, cool, thanks
<roptat>gbrlwck, I think what happens is you installed mes in the past, and that propagates nyacc from the past; then you ran guix pull, updating the available packages (but crucially not your user profile), so you still have the old nyacc that you can't install with the newer nyacc
<roptat>gbrlwck, mh, nevermind, mes propagates an old nyacc even in the current version
<roptat>so I think you're not supposed to install nyacc, since it's already made available by mes
<gbrlwck>:) i only tried it, because mescc couldn't find it
<excalamus>yes, that's issue, that plugin-path is #f
<vivien>excalamus, maybe you need to add Qt to your inputs, and compute the plugin-path by appending the correct suffix to it.
<vivien>I’m not sure however.
<roptat>I see that this old nyacc uses guile 2.2 and not 3.0, so I'd install guile-2.2 in the profile, then guix should set some new environment variables for you, and it might be able to find nyacc
<roptat>ideally, you'd create a separate environment for that, if you already have guile 3.0 in your user profile
<excalamus>okay, I'll see what trouble I can cause
<gbrlwck>oh dang. `guix install guile@2.2` downgrades my guile :(
<roptat>using the new guix shell, I think you want something like "guix shell guile@2.2 mes", that'll drop you in a shell with the right environment variables and hopefully a working mes
<nckx>apteryx: Agreed, (display (format …)) was far more readable than a completely arbitrary yes!/no! (…to what?).
<roptat>if you don't have guix shell yet, then that's "guix environment --ad-hoc mes guile@2.2"
<roptat>seems to work for me :)
<gbrlwck>it even works with just `--ad-hoc mes`
<gbrlwck>ahhh, that's why i love guix :)
<roptat>--ad-hoc mes doesn't work for me though
<roptat>I get the same error message as you
<roptat>did you downgrade your guile?
<gbrlwck>yes, it now uses guile 2.2
<roptat>so I bet you can even use mescc from your profile now :)
<gbrlwck>makes sense :)
<roptat>I was suggesting to keep guile 3.0 in your profile, and use a shell/environment for mes
<gbrlwck>i'll do that; for that's the way to do it
<philip>When running e.g. `guix build libgit2 --root=foo`, foo-0 gets linked to the :debug output and foo-1 to the :out output. Is there a good way to specify just the :out output and have the name used exactly? It would be much more convienient for scripting.
<podiki[m]>vivien: did you narrow down or resolve the GLIBC errors on c-u-frozen? (I'll investigate on my end later tonight)
<vivien>podiki[m], they happen if and only if I have a core-updates-frozen guix system with a master guix home
<podiki[m]>was that the only thing you had from master?
<vivien>Now I only have a guix system and a guix home, I don’t have packages installed.
<podiki[m]>maybe the same with me then (but not guix home, a package that must pull glibc?)
<podiki[m]>okay. probably core-updates-frozen is due to pull in master, though also c-u-f-batched-changes it looks like
<podiki[m]>(looking forward to getting to the full new guix release!)
<vivien>podiki[m], there’s no rush, I’d like to migrate when unison and guile-gi are fixed ^^
<civodul>recommended reading on the topic of "review incentives" (and more):
<civodul>apteryx: thanks!
<apteryx>any idea what could be wrong with trampoline in (guix remote) in the context of remote-eval (when it is actually remote) ? ;-)
<podiki[m]>civodul: will read! been meaning to chime in on that thread as a newer user/contributor
<civodul>apteryx: nope; could you show the (possibly redacted) contents of "/gnu/store/rdzgpp9vq6mbvih3q12m8sq3qy50861z-remote-exp.scm" ?
<apteryx>doesn't look sensitive; here it is:
<apteryx>perhaps caused by the use of local-file in the config?
<apteryx>a strange thing is that the remote-eval seems to occur twice
<civodul>that expression comes from machine-boot-parameters in (gnu machine ssh)
<apteryx>e.g. guix deploy: sending 0 store items (0 MiB) [...] gets output twice
<apteryx>I've commented out allthe local-file usages from my system config, retrying
<civodul>that shouldn't make any difference
<civodul>AFAICS, that remote-exp.scm should be sent
<civodul>you added pk calls in remote-eval, right?
<civodul>can we reduce the problem to a remove-eval call? that'd be sweet
<civodul>if i do: ,run-in-store (remote-eval #~(uname) s)
<civodul>i see:
<apteryx>this is the debug edits:
<civodul>building path(s) `/gnu/store/7sg8rx4xzff28j242rb7fqq10f4g9hwk-remote-exp.scm'
<civodul>sending 1 store item (0 MiB) to 'xyz'...
<civodul>so it's working as intended
<civodul>could it be GC was running on the target machine?
<apteryx>no chance
<apteryx>(no mcron job doing that there)
<apteryx>i can reproduce at will with my config
<civodul>built-locally? = #f is kinda untested, don't do that
<civodul>oh but that's precisely what you're donig?
<civodul>i didn't know one could actually choose :-)
<apteryx>yes :-)
<apteryx>(build-locally? #t) at the level of the machine definition
<apteryx>otherwise it shuffles 4 GiB on the network
<apteryx>(probably most of it attributable to the hurd-vm-service-type)
<civodul>so (build-locally? #t) is fine, it's the default; #f is not
<civodul>you're setting it to #false, right?
<apteryx>ah, yes, that's what I meant of course
<apteryx>I'd like to use (build-locally? #f), so that my powerful offload machine builds its config itself
<apteryx>and hopefully save on bandwidth too
<civodul>i'd need to wrap my head around it because i'm not sure why (build-locally? #f) doesn't work
<civodul>but i think it doesn't
<apteryx>yep, that's what doesn't currently work
<apteryx>but the code seems to be ready for it
<apteryx>so it's probably something small, or so I hoped :-)
<breathe>Hello! I set up some mcron jobs in ~/.config/cron/ and I am able to execute them by invoking `mcron -d`.
<breathe>What's the recommended way to invoke `mcron -d` on startup? Should I put that line in my .bash_profile?
<civodul>apteryx: at first sight ",run-in-store (remote-eval #~(uname) s #:build-locally? #f)" works
***breathe is now known as breatheout
<drakonis> so i didnt know about this blog post
<drakonis>this update cycle is turning out to be quite fruitful
<civodul>it's gonna be a big bang
***pkill9_ is now known as pkill9
<apteryx>civodul: what is the 's' in your expression?
<apteryx>the store?
<civodul>a session as returned by open-ssh-session
<apteryx>ah, session
***breatheout is now known as breathe
<drakonis>ah i love this
<apteryx>civodul: the snippet works here as well
<vivien>At home, I have 2 machines: one with a large spinning disk, but too weak for heavy compilations, and one fast machine with a small SSD. The local network is fast, but connecting to the internet is slow. When I run guix gc on my fast small machine, I’d like to copy the deleted element of the store to the slow machine with lots of storage, so that I can download them again without connecting to the guix substitutes. Is it possible?
<DigitalKiwi>could you just set the large machine as a binary cache and skip the "copy when i delete" requirement and just 'always check big machine'
<DigitalKiwi>on nixos i'd use don't know if guix has something like it
<vivien>DigitalKiwi, that could work if I could find a way to copy everything I build locally there automatically.
<apteryx>civodul: ,run-in-store (remote-eval (trampoline #~(uname)) s #:build-locally? #f) worked, too
<vivien>For instance, suppose I want to have the full texlive in the small-fast machine. If it’s not already present on slow-large, I will download it from guix substitutes, and that’s it. If I guix gc the small-fast machine, it will never get into the slow-large machine.
<civodul>vivien: you could manually invoke "guix copy", though that's not convenient
<civodul>there's no way to say "copy things i built locally"
<vivien>civodul, I tried to invoke guix copy with a bash glob (/gnu/store/*), but it fails because the command-line is too large. I have to do /gnu/store/aa*, then /gnu/store/ab*, etc.
<roptat>I don't remember who reported that but thanks, I just updated kicad's home-page
<civodul>vivien: heavy-handed!
<drakonis>DigitalKiwi: ohai
<DigitalKiwi>hi drakonis
<vivien>roptat, mikolajw
<drakonis>DigitalKiwi: it does
<drakonis>guix publish is what you want
<drakonis>but what it does is serve the store
<DigitalKiwi>is it like nix-serve
<drakonis>but its turnkey
<drakonis>the guix cli can detect the presence of such servers on the network and instead pull from them