IRC channel logs


back to list of logs

<poet>maximed: Okay. Here's what I got at the end:
<maximed>poet: right, SSL_CERT_DIR is set in consumers, not producers
<maximed>try "guix environment --ad-hoc nss-certs openssl -- guix pull" instead
<poet>Okay. Running now...
<mekeor[m]>vivien: btw, also, the icecat version packaged for guix is still beta
<vivien>So, it’s obsolete before it’s mature ^^
<maximed>seems like the nss-certs in the guix you currently have installed is too old
<mekeor[m]>vivien: exactly x)
<maximed>Maybe update the Debian system first?
<maximed>Because the system's certificates are used if there are no certificates installed in the user's profile
<mekeor[m]>maximed: i'd guess guix-pull will always use the guix-installed nss-certs, not the host's nss-certs
<maximed>mekeor: but if there are no guix-installed nss-certs?
<maximed>Then I'd presume it defaults to /etc/ssl...?
<mekeor[m]>maximed: ah i see, i don't know :D
<poet>maximed: Is it possible to install the certificates in the user's profile without updating the whole system?
***lukedashjr is now known as luke-jr
<maximed>poet: the "guix environment --ad-hoc nss-certs openssl" temporarily installs the certificates, but
<maximed>the problem seems to be that the nss-certs (the certificate package) in your guix is too old
<maximed>I think I know a work-around, but it's insecure if you use channels
<maximed>Could I see the output of "guix describe", to determine if the workaround is secure/insecure?
<poet>maximed: Yes. One second...
<maximed>Oh, right, it's without provenance information. Presumably no channels, then
<maximed>poet: guix pull --commit=62a24dd9a125095362789dd4b3c3fe3fd650f017 --disable-authentication
<maximed>That command will update your guix to the exact version of guix I have installed
<mekeor[m]>why do you specify the commit-hash?
<maximed>mekeor[m]: For security. Suppose an attacker is listening in on this IRC conversation, and decides to MITM the (unverified) TLS connection
<poet>maximed: "error: disable-authentication: unrecognized option"
<mekeor[m]>maximed: nice
<mekeor[m]>poet: that's sad :(
<maximed>Seems like your guix is too old to support --disable-authentication.
<poet>mekeor[m]: Indeed. =(
<maximed>How did you initially install guix?
<maximed>If it is on Debian, you can do "apt-get update && apt-get upgrade" to upgrade the system-installed guix to 1.2.0
<maximed>(I'm assuming you are using the Debian package)
<mekeor[m]>or maybe clone the guix repository and build and install it yourself
<poet>maximed: I can't remember, my friend, It has been a couple of years. I *think* I used a shell script from Guix's site, but I'm not 100% sure. And no, I'm pretty sure I didn't use Debian to install it.
<mekeor[m]>or maybe remove guix completely first (i.e. rm -rf /gnu/store, i guess?), then install it again
<vivien>And /var/guix
<mekeor[m]>ok :)
<dstolfa>that'll be `systemctl stop guix-daemon.service && systemctl stop gnu-store.mount` and then you can remove /var/guix, /gnu/store and i believe /etc/guix (or something)
<poet>Wouldn't that break a lot of stuff? For example, the emacs I'm running now?
<mekeor[m]>i guess there are instructions in the manual how to delete guix
<maximed>poet: You can fall-back on the emacs provided by Debian (apt-get install emacs?), and later install the emacs from guix again
<mekeor[m]>i guess you could also replace the nss-cert-file in /gnu/store (the worst sind in guix-world) manually and then try guix-pull again
<maximed>Also delete ~/.guix-profile and ~/.config/guix maybe
<poet>I wish there was a better way. Seems awfully drastic. Oh well. I'll update Debian and see what happens. If that doesnt work, I guess I'll start wiping directories.Not like I have anything better to do. Thanks for trying to help. I appreciate it.
<maximed>poet: wait
<mekeor[m]>i wonder where debian installs its nss-certs. maybe you could replace your /gnu/store/nss-certs-*/ with debians nss-certs-folder
<mekeor[m]>probably /etc/ssl/certs/
<maximed>Err, wait again
<maximed>I think I know something less drastic that will work
<maximed>(once a command finishes, that is)
<mekeor[m]>i'd suggest to try `sudo mv /etc/ssl/certs /gnu/store/nss-certs-*/etc/ssl/certs`
<maximed>mekeor: sudo cp
<poet>mekeor[m]: Yeah, wow there's a ton of stuff in /etc/ssl/certs
<mekeor[m]>maximed: right
<maximed>sudo cp -r
<maximed>So it's still available under /etc/ssl/certs if something goes wrong
<mekeor[m]>`sudo cp -r /etc/ssl/certs /gnu/store/nss-certs-*/etc/ssl/certs`
<maximed>or cp /tc/ssl/certs/* /gnu/store/nss-certs-.../.../etc/ssl/certs/ maybe?
<mekeor[m]>oh, right
<vivien>Maybe there are many nss-certs directories in the store, I’m not sure what happens if its’ the case.
<mekeor[m]>`sudo cp -r /etc/ssl/certs /gnu/store/nss-certs-*/etc/ssl` should do it :D
<vivien>Ah ok
<vivien>Er, no
<maximed>poet: if you have substitutes enabled, you could try "guix build /gnu/store/wv5809dkczaklr3vb80ig7qj30b5zf0i-guix-1.3.0-7.ff77544.drv"
<mekeor[m]>vivien: yes, idk how to find out the right directory
<maximed>(That's the result of "guix build -d guix" on my x86_64 machine)
<vivien>That won’t do what you want
<vivien>You need an explicit for loop
<vivien>And, probably /gnu/store is mounted read-only
<poet>"cannot create directory '/gnu/store/nss-certs-*/etc/ssl': No such file or directory"
<maximed>(If you have another architecture, a different .drv is needed)
<vivien>Also, there should be a star before nss-certs
<maximed>poet: Does "guix build /gnu/store/wv5809dkczaklr3vb80ig7qj30b5zf0i-guix-1.3.0-7.ff77544.drv" work?
<poet>maximed: Lemme try...
<vivien>But don’t do that it will copy everything from /etc/ssl/certs AND everything for the first /gnu/store/xxx-nss-certs-... that it finds into the last /gnu/store/xxx-nss-certs-... directory
<vivien>I think
<maximed>If it does, it will substitute version 1.3.0 of guix, and you could run /gnu/store/k65k3slm1m7di2py9y1ivs8z5cvfr6bd-guix-1.3.0-7.ff77544/bin/guix
<poet>No such file or directory: "/gnu/store/wv5809dkczaklr3vb80ig7qj30b5zf0i-guix-1.3.0-7.ff77544.drv"
<maximed>poet: did you include "guix build"?
<maximed>"guix build /gnu/store/[bla bla].drv"
<vivien>If you don’t have the .drv file, you can’t invent it
<maximed>The "No such file or directory" seems strange, because guix (at least the latest guix) will try to substitute the derivation if it's not actually in /gnu/store
<maximed>vivien: guix build /gnu/store/wv5809dkczaklr3vb80ig7qj31b5zf1k-guix-1.3.0-7.fff77544.drv (a non-existend derivation, I modified a few characters) seems to disagree
<maximed>(if invent = ask
<vivien>Oh I didn’t know that, but maybe it was introduced after the prehistoric version poet is running
<maximed>poet,vivien: Nevermind, apparently poet's version of guix doesn't do this substitution
<maximed>poet: It will probably be simplest to update guix from a git checkout, or to reinstall guix, I think
<vivien>Reinstall it from the debian package, I would say
<maximed>If you're on Debian, you might want to give deinstalling guix and installing it with "apt-get install guix" a try
<maximed>(don't forget to "guix pull" so your package definitions will be up-to-date)
<poet>maximed: I think you're probably right. It's just that I really like guix and I'm afraid of breaking something. What would happen if I ran this script:
<maximed>That's the install scrpt, not the deinstall script
<maximed>* script
<vivien>It will say: A previous Guix installation was found. Refusing to overwrite.
<vivien>So, I guess it won’t help.
<poet>So, literally, because my version is so ancient, the only choice I have is to 'rm -rvf /gnu'?
<vivien>And /var/guix
<maximed>poet: That, or building from a git checkout
<maximed>If you build a recent version of guix from a git checkout, you wouldn't need to delete /gnu & /var/guix
<poet>Okay. I'll try that first and see what happens.
<maximed>poet: "guix environment guix" will create temporary environment with git & gcc & everyhing required to build guix
<maximed>don't forget setting --localstatedir appropriately
*maximed leaves
<vivien>That’s ./configure --localstatedir=/var
<poet>would running 'sudo -i guix pull' make any difference?
<mekeor[m]>poet: if root has a more recent guix-version, then yes
<mekeor[m]>(which most likely is not the case)
<poet>Nope. root has 1.0.1 too.
<mekeor[m]>poet: did you try the "cp -r ..." method? :D
<mekeor[m]>poet: for this method, first run `realpath /etc/ssl/certs`
<poet>mekeor[m]: Yes. I did what you suggested. 'cp -r /etc/ssl/certs /gnu/store/*nss-certs-*/etc/ssl'
<mekeor[m]>poet: and that did not have any effect?
<vivien>mekeor, this command will not do what you think.
<mekeor[m]>vivien: which command?
<poet>Okay. I did realpath, then cp -r again.
<vivien>If there are different nss-certs directories in /gnu/store, let’s say /gnu/store/aaa-nss-certs and /gnu/store/bbb-nss-certs, it will copy /etc/ssl/certs and /gnu/store/aaa-nss-certs/etc/ssl into /gnu/store/bbb-nss-certs/etc/ssl
<oriansj>mekeor[m]: here are the steps to manually update guix:
<LegoLoverGo>Hello is this working? This is my first time using irc
<oriansj>LegoLoverGo: you have posted to the channel #guix
<mekeor[m]>poet: sorry, my friend, but if /etc/ssl/certs is a symlink to /gnu/store/... already, then the cp-command won't make sense...
<poet>mekeor[m]: Okay. I understand.
<mekeor[m]>vivien: that's why i suggested to run cp -r without any stars/astericses. it was maximed who suggested that
<mekeor[m]>poet: is /etc/ssl/certs a symbolic link into /gnu/store/...-nss-certs?
<vivien>Well, poet said: mekeor[m]: Yes. I did what you suggested. 'cp -r /etc/ssl/certs /gnu/store/*nss-certs-*/etc/ssl'
<mekeor[m]>vivien: that's right
<vivien>There are two * in this command.
<poet>mekeor[m]: readlink says no.
<mekeor[m]>i'd suggest to find the correct path first, then run `sudo cp -r /etc/ssl/certs /gnu/store/nss-certs-xxx/etc/ssl`. assuming that /etc/ssl/certs is not a symlink into /gnu/store/...
<vivien>That’s the correct way to do
<mekeor[m]>poet: what does `realpath /run/current-system/profile/etc/ssl/certs` say?
<vivien>But I’m afraid /gnu/store is mounted read-only
<mekeor[m]>vivien: ah god damn
<LegoLoverGo>I'm having a problem with emacs-xwidgets in Guix not being launched by gdm instead launching regular emacs without xwidgets support. Any help would be appreciated.
<poet>mekeor[m]: realpath: /run/current-system/profile/etc/ssl/certs: No such file or directory
<mekeor[m]>vivien: well, packages are also written in the gnu-store during installation. so how come it's read-only?
<vivien>The guix daemon executes the code to build package, and it controls how stuff is mounted
<mekeor[m]>poet: it looks like your problem is debian/apt. you don't seem to have nss-certs installed. i'd suggest to download and extract it into /etc/ssl/certs
<poet>mekeor[m]: Okay. I'll try that.
<mekeor[m]>poet: correction: you don't have to seem to have nss-certs installed via guix
<mekeor[m]>poet: if that does not work, you might try the instructions oriansj posted above
<mekeor[m]>vivien: is there no way to write on the gnu-store without the guix-demon?
<poet>Geez a 78 mb cert file...
<mekeor[m]>it's a folder
<LegoLoverGo>Any help? I cannot figure out how to fix my issue
<poet>Okay. It's going to take my pathetic connection about 18 more minutes to download, so once that's done, I'll extract the contents and come back.
<mekeor[m]>sneek: later tell LegoLoverGo: did you consider to remove emacs (in favor of emacs-xwidgets)?
<sneek>Will do.
***Noisytoot is now known as GPLv3
<poet>Okay. The build failed.
<poet>I'm looking at the script at Towards the bottom, it wants to download a scheme file from, but I can't get that site to load.
<b3>Hi, how can I have a service defined in my configuration (e.g. openvpn-client-service) which is disabled by default, so I have to manually `herd start` it when I want to use it?
<dstolfa>b3: auto-start?
<dstolfa>set that to #f :)
<b3>dstolfa: Thanks! Do you know where exactly I set this? I am using openvpn-client-service-type which I think has already configured the shepherd-service to auto-start so I'm not sure how to change it
<dstolfa>b3: hm. i'm not actually sure. i don't think the discussions around making services extensible was pushed. you might have to "override" the service by manually creating one and creating your own service type. alternatively, you may be able to do the same thing that openssh-shepherd-service does, which is expose an auto-start (somewhat) in the configuration record
<b3>Makes sense, thanks for the info. I'll just manually override it for now with my own service type :)
<shoshin>anyone know if there's an irc bouncer service for guix?
***GPLv3 is now known as Noisytoot
<drakonis>shoshin: well, i use weechat as a bouncer
<drakonis>there is a znc package but no service afaik?
<apteryx>lilyp: for one thing its .pc file requires it I think
<apteryx>and it makes sense; librsvg's mean to become useful is to be dynamically loaded by gdk-pixbuf
<apteryx>I'm writing a profile hook for the gdk-pixbuf loaders.cache file
<apteryx>seems straightforward so far
***califax- is now known as califax
<apteryx>so with this change, we can deprecate gdk-pixbuf+svg in favor of librsvg (which propagates gdk-pixbuf)
<vijaymarupudi>Hello #guix, I have a beginners question. I have installed guix on my Arch Linux distribution as root and it seems to work well for the root user. However, when I'm a regular user and try to use it, it reports an error loading the shared library I suspect this is a common error so I wanted to ask if I was doing something wrong?
<vijaymarupudi>Maybe it has something to do with not having a profile for this user? The getting started guide doesn't mention anything like this
<iskarian>vijaymarupudi, guix operates essentially independently for different users
<sneek>Welcome back iskarian, you have 1 message!
<sneek>iskarian, excalamus says: Hey, it's been like a month, but I finally finished my write up. After reworking my website, the site generator, hacking together some CSS to represent diffs, and then remembering what the heck we did, the build experience preserved at I've got some follow up questions for next time you and I are able to talk. I appreciate your help and wanted to give an update from the ether...
<iskarian>the exception is "sudo guix" operates as the current user, not root
<vijaymarupudi>iskarian: Does that mean I have to install guix for each user?
<vijaymarupudi>The guide seems to suggest that the root user installing it and making it available for other users is fine?
<iskarian>mmm, guix itself can be installed by root, I was meaning the operation of guix
<vijaymarupudi>iskarian: Ah I see, indeed `sudo guix` appears to work. Can I make it work without sudo?
<iskarian>if you repeat all the e.g. "guix install" steps as your current user, that should do it
<apteryx>vijaymarupudi: you could export the profile's manifest and the install that
<vijaymarupudi>iskarian: I'm not sure what the guix install steps you're referring to are, I suspect this is because I use the install script
<apteryx>(sorry, didn't read back much, my answer is in the context of migrating a root profile to a user profile)
<vijaymarupudi>apteryx: Ah I see, it's all good!
<iskarian>vijaymarupudi, wait, do you mean even running "guix describe" as your current user fails?
<vijaymarupudi>iskarian: without sudo, yes
<apteryx>vijaymarupudi: shouldn't guix be available without 'sudo' ? I think the manual suggests adding the binary to /usr/local/bin or something similar
<vijaymarupudi>My user can access the binary, but not the shared libraries that it's using
<vijaymarupudi>I've tried this in multiple Arch Linux computers
<vijaymarupudi>Well, maybe it can access the shared libraries, I'm not sure
<apteryx>I've never seen such failure myself
<vijaymarupudi>But it has trouble finding it, an strace reveals that it can't find the right folder
<vijaymarupudi>apteryx: Do you use Arch?
<apteryx>probably it's missing things needed from /root/.config/guix/current-profile
<apteryx>no, but I have a bunch of foreign distributions with Guix on top around
<apteryx>granted, I usually go for the more 'normal' per-user setup, where everything must work more easily
<vijaymarupudi>I see, that's odd. Maybe I missed a step, this is what I did
<vijaymarupudi>1. Run install script as root user. Reboot computer. Run guix as normal user.
<vijaymarupudi>Nothing else...
<apteryx>which commands shows library resolution failures?
<apteryx>(I just connected to a remote box)
<vijaymarupudi>Just `guix`
<apteryx>seems to work fine on Ubuntu 20.04
<apteryx>I run guix with a user I've never used 'guix pull' with.
<vijaymarupudi>Huh... Maybe this is Arch specific? I'll try to do more debugging
<apteryx>good luck!
<apteryx>lilyp: hmm... do you think a profile hook produced file could be caught by a search path definition (on a package) ?
*apteryx tries
<iskarian>sneek, later tell excalamus: thanks for letting me know! I haven't had much synchronous time lately but you can drop me a PM or send email to my username -at- to talk :)
<sneek>Will do.
<apteryx>bah, sticking '(define-public gdk-pixbuf+svg (deprecated-package "gdk-pixbuf+svg" librsvg))' in (gnu packages gtk) (after removing the definition for gdk-pixbug+svg) throws a 'error: librsvg: unbound variable' at runtime
<apteryx>seems like there's a cycle caused when trying to use librsvg at the top level of the gtk module
<vijaymarupudi>Just for future reference if people google errors, my issue with or not being found with guix was because my LD_LIBRARY_PATH had a stray `:`. This didn't cause issues with any other problem (odd...), but fixing that fixed the issue.
<apteryx>vijaymarupudi: oh, neat! so this problem had nothing to do with Guix, right?
<vijaymarupudi>That is correct!
<vijaymarupudi>guix was just the first problem to give me an error
<apteryx>great! glad you figured it out
<vijaymarupudi>apteryx: Thanks :)
<vijaymarupudi>I'm curious why guix downloads libX11, when I have no graphics package
<vijaymarupudi>Is there a way to answer the question "what depends on this?"
<iskarian>vijaymarupudi, look at "guix refresh -l" and "guix graph"
<apteryx>typically by looking a the graph, or 'guix size $package'
<apteryx>what iskarian said :-)
<vijaymarupudi>Thanks apteryx and iskarian!
<apteryx>arg. the gdk-pixbuf loaders cache needs to be built also as a build phase, in case something runs there that needs support for a loader (e.g., inkscape needing svg)
***darosior0 is now known as darosior
***duponin4 is now known as duponin
***sneek_ is now known as sneek
<Jeremy[m]>Good evening everybody :)
<Jeremy[m]>I noticed the GNOME 40 branch seems to have been deleted?
<Jeremy[m]>What happened there?
<apteryx>it's been merged into core-updates-frozen I think
<apteryx>so it's lined up for the next release
<Jeremy[m]><apteryx> "it's been merged into core-..." <- Yaaaaay!!! 🎉🎉🎉
<Jeremy[m]>apteryx: so how do the branches work?
<Jeremy[m]>I ask because I am surprised that it was merged into core-updates-frozen rather than master
<apteryx>core-updates-frozen is being stabilized; it'll be used as the base of the next release
<apteryx>when it'll be in a good enough shape it'll be merged into master
***Xenguy_ is now known as Xenguy
<lilyp>apteryx: How about producing the loaders.cache a) as part of librsvg or b) as part of glib-or-gtk-build-system?
<lilyp>also, I don't think propagation via pkg-config should occur at all
<lilyp>you could try simply symlinking the gdk pc file into librsvg, that ought to catch build time errors
<lilyp>I made a similar proposal a while ago, but it's probably too late for c-u-frozen
<lilyp>perhaps next cycle
<PurpleSym[m]>I’m trying to figure out why the daemon’s `--disable-deduplication` is broken (see #50121). Is there someone with insight into why there’s two pieces of daemon code able to start a substituter?
<PurpleSym[m]>There’s `LocalStore::substituter()` and then very similar code in ``, which passes the `deduplicate` option, but apparently is not used, because a substituter is running already.
<b_>It may have been a mistake to update all KDE packages on master, since it only has gcc7. with core-updates-frozen there is gcc10!
***b_ is now known as brendyn
<brendyn>is anyone able to merge master onto core-updates-frozen again? is that the way things are done?
<nckx>brendyn: When needed.
<nckx>So these KDE packages break with GCC 7?
<brendyn>nckx, are you familiar with #include <filesystem> ?
<brendyn>i found libksysguard needed it, and thus need gcc9. and then everything that depends on it cant compile unless it also has gcc>=9
<nckx>It rings a very vague bell, I think I had to deal with it a while back.
<nckx>Right… So this stuff was (one hopes :) built & tested on something other than master?
<brendyn>its not it gcc7, although it has <experimental/filesystem>, but it's not complete
<brendyn>I'm currently migrating my patches over to core-updates-frozen, since it seems like that will be the next guix
<nckx>It will be, but master should never be broken.
<brendyn>this is all stuff im doing locally.
<nckx><It may have been a mistake to update all KDE packages on master, since it only has gcc7.> → Oh phew, I read this as somebody had actually just pushed them to master 😄
<brendyn>well, thing is, its not entirely broken, because there aren't many KDE packages in guix anyway. the issue arrises when i start adding new kde packages and run into new issues
<wigust>hi guix
<brendyn>na im not a committer
<nckx>Yes, ‘git merge master’ on core-updates is how things are done, but you'll be volunteering to fix all conflicts if there are any.
<nckx>There's no way around that.
<nckx>Hi wigust.
<nckx>brendyn: If this only affects libksysguard, could you get away with adding ,gcc-9 only to its dependents on master?
<brendyn>my project is 1: update all current KDE packages. 2. Add more KDE stuff and complete KDE plasma. I've submitted a v1 patchset for updating everything, but its not perfect
<nckx>(Thank you!.)
<brendyn>i just posted it to share that im working on it and see if anyone else was interested
<efraim>(guix gexp) doesn't compile on powerpc-linux with guile-3.0.2 :/ just hangs for hours
<user_oreloznog>hello guix!
<nckx>Hullo user_oreloznog.
<user_oreloznog>hi nckx o/
<nckx>My brain auto-reverses your nick but then breaks on ‘_resu’. Well played.
<itd>Hi. For some reason using the name "ghc-next" instead of "ghc" seems to break builds, e.g., ; not sure if this is expected.
<nckx>I guess that's the problem?
<nckx>My guess is that something is using (string-append … name …) (i.e., being clever) when it should just hard-code "ghc".
<nckx>Could it be make-ghc-package-database, itd?
*nckx not a Haskelleer.
<nckx>I don't even know what those conf.ds are.
<itd>Not sure, sorry. :/
<nckx>No prob. I'm testing that assumption.
<itd>Thank you. :)
<nckx>No, that wasn't it. /tmp/guix-build-custom-haskell-semigroups-0.19.2.drv-0/package.conf.d/base- really doesn't exist, and I don't know what's supposed to create if it's so mandatory (is it?).
<PurpleSym[m]>itd: This is fixed on wip-haskell, afaik.
<nckx>PurpleSym[m]: Thanks. Just FMI, what is ‘this’?
<PurpleSym[m]>nckx: The build systems assumes the package name will be just “ghc” and derives paths from it.
<PurpleSym[m]>I think it was commit 05eeeca536082bc3e2f4542e206a967a7e4f2228.
<nckx>Yeah, I noticed that, but even hard-coding "ghc" in ‘register’ didn't fix the build.
<nckx>Thanks, I'll try that.
<nckx>Same error. cherry-picking it didn't even rebuild custom-haskell-semigroups.
<nckx>ls package.conf.d/
<nckx>package.cache package.cache.lock
<nckx>It's not that the destination is invalid (which it would be without patching), but that there's no base- there.
<nckx>I just don't know what that means 😛
<PurpleSym[m]>Hm, the error message sounds like c731961aa45a21c3720daf1be5494602665dd64b might be happening.
<PurpleSym[m]>Might be worth to just try it on top of wip-haskell…
<nckx>Actually, I think something funky's going on with cached Guile modules (again)… Let me make clean-go just in case.
<PurpleSym[m]>Also you generally can’t just pass `#:haskell`, because all dependencies will be built with ghc-8.6 anyway.
<nckx>PurpleSym[m], itd: successfully built /gnu/store/8d4r1681c18nmqfbb4i8pss0shb4302y-custom-haskell-semigroups-0.19.2.drv \o/
<nckx>After cherry-picking 05eeeca536082bc3e2f4542e206a967a7e4f2228 and rebuilding Guix.
<itd>Nice! :)
<nckx>PurpleSym[m] last line probably still applies, though. That's beyond my (nonexistent) Haskills.
<nckx>Can we just all write C.
<ruffni>i thought Guile was the language of choice here ;)
<nckx>C is more functional. Guile only has lambdas.
<PurpleSym[m]>Haskell is a very nice language to teach students algorithms :)
<apteryx>lilyp: actually, the loaders.cache need to be produced both at the build system level and profile, because 1. it may be needed at build time 2. a guix environment (which is basically a profile) can mix any components not known in advance
<nckx>Sounds legit. Students are lazy too.
<lilyp>Sure, the latter is always needed, but the former could have been (inadvertently?) skipped.
<apteryx>indeed; building an icon theme made me realize of its necessity there too (inkscape needed SVG support to build the icons)
<lilyp>inkscape needed SVG support
<lilyp>quote of the day
<apteryx>gdk-pixbuf SVG support if it sounds less dumb :-)
<attila_lendvai>how can i identify a license? i'm having a hard time with this one:
<ruffni>attila_lendvai: not an expert, but the clause: "Neither the name of Google Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission" gives me the impression that it's a non-standard (think: roll-your-own) license
<attila_lendvai>ruffni, thanks! hrm... do you have any advise which guix license to pick for this in the package declaration?
<attila_lendvai>it also says: "I've forked the XGB repository from Google Code due to inactivty upstream."
<attila_lendvai>hehh, and this: "Unless otherwise noted, the XGB source files are distributed under the BSD-style license found in the LICENSE file."
<ruffni>searching the web a bit, it does not sound too uncommon.. apache license v1.1 has a similar clause (#4):
<ruffni>attila_lendvai: is there a LICENSE file?
<attila_lendvai>ruffni, yes, the one i have linked to it
<ruffni>lol, yes
<singpolyma>Smells like BSD license with that advertising clause?
<singpolyma>Like, original BSD
***pushcx__ is now known as pushcx
<nckx>It's just BSD-3.
<nckx>attila_lendvai: ☝
<attila_lendvai>thank you everyone! i'll go with bsd-3 then.
<maddo>hello, I have a question about how guix can work with a framework that has plugins
<maddo>basically, guix packages vapoursynth (an old release at this point, but recent release has changed its api and broke most plugins, reluctant to update), which is near useless on its own, but it has several "plugins"
<maddo>that needs to be compiled against vs api
<maddo>to my understanding, the optimal solution would be to package said plugins using the vapoursynth-* namespace
<attila_lendvai>iskarian, are you available for a quick look at a go import? this one fails: ./pre-inst-env guix import go and the issue is that the actual git tag is called 'service/route53/v1.1.1' as per
<nckx>Is the ld cache speedhack on master already?
<hiruji>Hi Guix
<hiruji>Anyone using connman? Does this error when launching cmst look familiar to anyone?
<attila_lendvai>so, guile has useless backtraces... is there anything planned to use a different scheme with better debugging capabilities?
<roptat>the plan would be to make guile have better debugging capabilities, rather than switching to something else :)
<ss2>hello, which of the following is the best way to set setuid-programs?
<attila_lendvai>roptat, there are so many scheme implementations already... sticking to guile is due to the licenses then, right?
<vijaymarupudi>I think Guile is pretty much the best Scheme there is, it's stable, and has a symbiotic relationship with Guix (judging from talks), I don't think switching is a good idea
<ss2>Most of the times I'm getting a error: ungexp: unbound variable, and don't know why yet..
<singpolyma>attila_lendvai: pretty sure guix started out as a way to give guile a killer app ;) (among other things)
<nckx>This is switching to Clang all over again :-/ Can we not have another ‘why does x use [y it happens to use] instead of [my favourite z]’ discussion.
<nckx>The ′Gui’ in Guix stands for ‘Guile’ by the way. ‌ ☺
<attila_lendvai>well, all i'm asking for is usable backtraces, nothing more.
<ruffni>attila_lendvai: go for it! :) Guile is AFAIU as open as guix and as hackable
<nckx>attila_lendvai: What's the gold standard in Scheme backtracing IYO?
<nckx>I'd like to see what's possible.
<vijaymarupudi>Optimization and speed are in direct conflict, so finding a balance is difficult.
<attila_lendvai>usually i get annoyed when the debugging facilities are holding me back, and get into hacking on them, instead of the project i'm working on. but hacking on the backtrace of yet another lisp feels too much of a detour for me at this point. i've been there too many times...
<vijaymarupudi>direct conflict with debuggability*
<attila_lendvai>nckx, i'm new to scheme. i mostly worked in CL, and hacked primarily on SBCL, including its error handling and debugging facilities.
<nckx>I sympathise, but improving Guile rather than forking Guix to run on another Scheme is the more fruitful approach here.
<attila_lendvai>vijaymarupudi, this is much more simple. judging by its look the backtraces are simply cut at list depth 2, and i couldn't find a way to make them more verbose
<nckx>attila_lendvai: Ah, never used CL I'm afraid (wholly due to prejudices of my own, which are almost certainly bogus).
<attila_lendvai>nckx, ok, understood. then i'll get back to debug prints... which reminds me that there's no logging infrastructure either.
<vijaymarupudi>attila_lendvai: That's a very fair concern, but fixable, as others have said. Inlining probably makes it difficult
<nckx>attila_lendvai: Have you asked in #guile or on a Guile mailing list? It's true that Guix tends to have the larger and therefore more responsive community but we tend to know less about the lower-level Guile implementation.
<nckx>attila_lendvai: I didn't mean to imply that Guile is the best (or even good enough in places). Just that improving it will benefit more people the most. Oh noes, I've become a utilitarian.
<ruffni>nckx: lol
<attila_lendvai>if backtraces of all things are lacking, then i guess there are a million more issues with basic infrastructure in guile. everything can be fixed, of course... the only question is how much duplicate effort is wasted in the process.
<attila_lendvai>but i don't want to be a PITA. so, to sum it up, the guix codebase badly needs logging facility, reasonable backtraces, auditing for not unwinding the stack at every corner, and in general better debuggability
<nckx>I don't know if it's what you mean, but you risk (and IMO do) coming across as ‘Guile isn't good enough and therefore should be discarded’. Which, OK, valid opinion, I guess, but it will get you a certain predictable result when you throw it over the wall of a community built around Guile.
<nckx>You're not a PITA.
<nckx>Guile can be.
<attila_lendvai>well, i had no idea people here are attached to guile, or that guix is so much interdependend on guile. until now i looked at guile as a random scheme that brings guix alive, nothing more, nothing less.
<hiruji>fun fact GNU maintains 4 scheme implementations (5 if you count Mes :)
<podiki[m]>attila_lendvai: I too really like CL and SBCL and have found the backtraces here not as helpful. but I wonder what things are like using a REPL, as I haven't done that for my limited guix (package) hacking
<nckx>There is a lot of community overlap, and the choice for Guile was very much not made by an outsider evaluating all then-available Schemes for debuggability. I wouldn't call myself attached to Guile. I don't think you have to be to believe that porting Guix is a poor fix.
<clacke>hiruji: which ones? guile, mes, GNU Scheme, ..?
*nckx swears out loud at Guile at least weekly. It keeps my skin fresh and young and my neighbours confused.
<hiruji>clacke: guile, gnu/mit scheme, kawa, scm, and mes
<attila_lendvai>podiki[m], guix repl and geiser feels very rough compared to slime and sbcl. maybe i'm just missing the required knowledge, though.
<hiruji>technically you can use slime with guile
<clacke>oh! didn't know kawa is GNU and SCM is maintained
<attila_lendvai>hiruji, i tried that using but i didn't get much farther
<hiruji>wait nevermind... forgot that guile doesn't like conforming to RnRS's
<podiki[m]>attila_lendvai: maybe that's a good route to explore, the emacs/geiser/slime/etc. set up and tooling
<hiruji>attila_lendvai: yeah...
<hiruji>clacke: surprised me too!
<ecraven>attila_lendvai: it's unfortunately very much a work in progress
<nckx>hiruji: How so?
<nckx><doesn't like>
<ecraven>I don't use guile myself very much at the moment, thus it isn't as well-supported as it should be
<hiruji>I didn't have a good experience with the compat layers... they felt incomplete
<podiki[m]>at the very least I find Guile code very readable (as a lisper), which is always very helpful to me
<janneke>"<attila_lendvai> so, guile has useless backtraces... "
<janneke>attila_lendvai: are you compiing your guile programs?
<attila_lendvai>ecraven, i used to hack a lot on slime/swank, too. but my main project currently is packaging bee (of and make it easy to start multiple nodes to join multiple swarms... hacking guile backtraces is just too many stack levels away from that... :)
<janneke>the interpreter is known to have lacking backtraces, but you are welcome to send a specific bug report to
<janneke>"backtraces are useless" is eh, kind of useless as a bug report ;)
<attila_lendvai>janneke, i can't really answer that, but every single backtrace that i've looked at is full of _ characters at argument positions that would be interesting to be.
<hiruji>I remember scratching my head at a one of guile's backtraces for way too long over a simple type error
<hiruji>record slot wanted a list, not a symbol, ha
<podiki[m]>janneke: would general reports of something like: here is the backtrace, the code, and actual problem that fixed it be useful (not a bug exactly, but need for more precise or helpful message)?
<hiruji>I think a more useful bug report would be one that takes a look at guiles architecture and comes up with some ideas of why things are the way they are :)
<janneke>podiki[m]: yes, i think it might
<nckx>‘More useful’ sure, but not the minimum requirement.
<hiruji>anyways the real flaw of guix for me is that it's too static.
<hiruji>I can't just connect to the running guix-daemon and hack on it in real time
<hiruji>this might be due to the nix codebase... not sure...
<hiruji>can't propagate package redefinitions from my system configuration file to the rest of the system either
<hiruji>it's always a tad annoying
<janneke>a good bug report is worth more than a 1000 complaints ;)
<hiruji>guix just needs to be more lispy in its architecture, that's all
<hiruji>janneke: I'll open one for discussion when I have some solutions in my head
<hiruji>I just to acquire a deeper understanding of Guix's current architecture first.
<hiruji>*just need to
<podiki[m]>and a good patch worth 1000 bug reports? :)
<hiruji>sure :)
<nckx>A *good* bug report can sometimes be worth up to 0.5 patches.
<excalamus>hi, Guix!
<sneek>Welcome back excalamus, you have 2 messages!
<sneek>excalamus, maximed says: some comments about your post:
<sneek>excalamus, iskarian says: thanks for letting me know! I haven't had much synchronous time lately but you can drop me a PM or send email to my username -at- to talk :)
<podiki[m]>as we like to say in the sciences, and as I have a fortune cookie tell me, "a well-defined problem is half the solution" (or so)
<nckx>Hi excalamus!
<excalamus> I think it was gi-Joe who said that knowing is half the battle
<excalamus>hey, nckx
<ruffni>i'm running into "#<record-type <operating-system>>: record ABI mismatch; recompilation needed" trying to build guix on wip-risc (it comes from gnu/tests/install.scm). any ideas what i should be looking for in install.scm?
<nckx>ruffni: Probably nothing. You're building from git, right? Have you run ‘make clean go’ and rebuilt Guix?
<nckx>The error means that a record definition has changed and the compiled objects no longer match.
<ruffni>"No rule to make target 'go'. Stop"
<nckx>Sorry, ‘clean-go’.
<nckx>Which clean probably implied already anyway.
<ruffni>nckx: thanks! "stray .go files: ..." means there is a compiled file without the corresponding file?
<ruffni>*corresponding source file?
<ruffni>nvm :)
<excalamus>sneek, later tell maximed: thanks for taking the time to read through and answer questions
<attila_lendvai>iskarian, FYI, i'm preparing a patch for the go importer that will deal with that
<nckx>ruffni: Sorry, I was away for a spot. And now for longer o/
<ruffni>nckx: np!
<old>Anybody has problem with emacs-org-super-agenda derivation? /gnu/store/amckrppdlq3331sf1k3wdwz2s2xq09j8-emacs-org-super-agenda-1.2.drv . Mine is stuck at `check` phase for ever
***notzmv- is now known as notzmv
<hiruji>anyone here using a vpn? specifically openvpn?
<hiruji>old: tried doing a 'guix build', interestingly mine fails getting org
<hiruji>download failed "" 404 "Not Found"
<hiruji>oh hmm, wait
<hiruji>is that trying to get a substitute?
<hiruji>that'd be weird
<hiruji>maybe source tarballs are also stored on
<hiruji>let me try a quick guix pull
<old>it hand at a prompt
<old>`guix build emacs-org-super-agenda` result:
<old>Running 66 tests (2021-10-03 16:38:42+0000, selector ‘t’)
<old>org-super-agenda-mode enabled.
<old>Non-existent agenda file ~/org/ [R]emove from list or [A]bort?
<hiruji>you can do an ad-hoc `--without-tests=emacs-org-super-agenda' but...
<hiruji>ah, there we go
<hiruji>a pull did it
<hiruji>lets see if tests pass on my end
<hiruji>hangs as well
<hiruji>that's good
<old>that's weird. A quick `git log` shows that last commit on this package dates from 2021-05-20
<old>or maybe it's org mode
<rekahsoft>Hi all, I am a little confused why a package transformation isn't being applied when I have it as part of a manifest but it is when its defined in a file or is built via 'guix build ...' with the appropriate package transformation option/s.
<rekahsoft>'guix build --without-tests=emacs-org-super-agenda emacs-org-super-agenda' works as expected
<rekahsoft>'guix build -f file.scm' works as expected; file contains (left out module includes for brevity): '(define transform--emacs-org-super-agenda (options->transformation '((without-tests . "emacs-org-super-agenda")))) (transform--emacs-org-super-agenda (specification->package "emacs-org-super-agenda"))'
<rekahsoft>However, putting the same file contents in a manifest and referring to the transformed package does not work.
<rekahsoft>What am I missing?
<maximed>sneek: later tell ss2: If you error: see "ungexp: unbound variable", that means the variable ungexp is unbound but you're trying to use it anyway, so you need to import the module that defines it.
<sneek>maximed, you have 1 message!
<sneek>maximed, excalamus says: thanks for taking the time to read through and answer questions
<maximed>sneek: later tell ss2: I.e., (guix gexp)
<sneek>Will do.
<maximed>sneek: later tell ss2: nevermind, it's a bit more complicated
<sneek>Got it.
<maximed>sneek: later tell ss2: Make sure you're using #$ (i.e., ungexp) from within a #~ (i.e., gexp) form. #$ is only available inside #~ forms. Or possibly you don't need #$ at all.
<hiruji>ah! think I found the stem of my issues
<hiruji>my /run/user is empty, aren't I supposed to have things in there?
<maximed>sneek: later tell ss2: Remove the #$ from wireshark
<maximed>sneek: later tell ss2: file-appends needs a file-like object, and wireshark is a package, and all packages are file-like objects, so the #$ isn't uuseful there
<maximed>sneek: later tell ss2: The G-exp mechanisms (#~, #$, #+) aren't used in setuid-programs
<sneek>Will do.
<maximed>sneek: botsnac
<maximed>sneek: botsnack
<ss2>hey maximed, thanks!
<ss2>maximed: but that is what isn't very clear how it should be invoked, and it has been discussed here before too:
<maximed>ss2: Right, the example in the manual is incorrect
<maximed>I'll send a patch
<jgart>hi is there an example of what to do when there is no somewhere?
<maximed>ss2: Removing #$ did fix the error, right?
<jgart>I'm trying to upgrade
<jgart>it has no
<jgart>there's no tests on pypi
<ss2>Well, it throughs this deprecated error, and actually fails.
<jgart>so I have to use that git checkout
<maximed>ss2: What is the error message + your setuid-programs
<jgart>any help is much appreciated
<ss2>oh, hang on..
<ss2>I have: (setuid-programs (append (list (setuid-program (program (file-append wireshark "/bin/dumpcap"))) %setuid-programs)))
<ss2>and get: guix system: error: #<<setuid-program> program: #<file-append #<package shadow@4.8.1 gnu/packages/admin.scm:803 7fe65653ddc0> "/bin/passwd"> setuid?: #t setgid?: #f user: 0 group: 0>: invalid G-expression input
<jgart>here's my WIP
<maximed>ss2: check the parentheses
<maximed>ss2: Does your text editor highlight the opening parenthesis if the cursor is at the closing parenthesis?
<maximed>ss2: (a ) needs to be placed before %setuid-programs
<ss2>heh, missed that one. Thanks :)
<ss2>yeah, I do have highliting though. Just missed it somehow.
<PurpleSym[m]>jgart: You also have to invoke poetry manually and essentially replace 'build and 'install, because python-build-system cannot handle pyproject.toml builds (yet).
<PurpleSym[m]>Or try python-pypa-build.
<rekahsoft>For posterity of record: figured out my issue from earlier. I had another package in the manifest that depended on a non-transformed version of the package.
<nckx>vivien: I wonder if Hexchat 2.16 will fix your _ problem.
<nckx>Oh right…
<nckx>…☝ that's an underscore. ☺
<vivien>I don’t have an underscore problem since I switched to a more reasonable font size :)
<nckx>OK. Well, it seems to add just a smidge (pixel?) between text lines here.
*nckx changed font size from 10 to 9.9 to compensate, but it does look better…
<iskarian>sneek, later tell attila_lendvai: I'm sitting on a patch for that at the moment, I've just been busy :)
<MeowcatWoofWoofF>Is there a convenient way to install from a .deb on Guix System?
<nckx>I can't think of any.
<MeowcatWoofWoofF>I tried the intuitive answer of installing dpkg via guix, but the defaults leave '/var/lib/dpkg' in a read-only file system under the gnu store.
<MeowcatWoofWoofF>Guix could install from source if I ran 'git clone' right?
<iskarian>MeowcatWoofWoofF, see and
<nckx>MeowcatWoofWoofF: Do you mean running ‘make install’ by hand? That will usually work (modulo many Makefiles assuming /usr etc. already exist) but you'll lose all the Guixiness. Writing a simple Guix package is really the recommended and assumed approach to installing anything on Guix System.
*nckx AFK.
<singpolyma>I want to work on more bi-directional import/export type idea with guix and debian, but I'm immersing my brain in packaging stuff up first
<singpolyma>From .deb into guix is probably the hardest one. From debian source package into guix should be doable I think, and guix pack to make a useful (if weird) .deb also
<singpolyma>From guix to usable Debian source should also be possible, but maybe not useful
<MeowcatWoofWoofF>Sounds like a cool idea, imo
<nckx>singpolyma: ‘guix pack’ already makes .debs. I'll leave estimating their usefulness and/or weirdness up to you.
<nckx>I'm sure there are wartz.
<MeowcatWoofWoofF>I was just looking at 'guix import' and 'guix pack'.