<awb99>but the user keeps being in the generated profile
<nckx>IIUUC, ‘being in’ a profile is just having a collection of environment variables set. You can reset them (env -i?), then source things like /etc/profile & the new profile's etc/profile file (by the seashore).
<nckx>Guix profile /etc/profiles just append stuff, they don't save the original values for easy undoing.
<cbaines>the actual issue I'm coming up against is more one of building something which is already in the store, as currently the Guix Build Coordinator just refuses if it can't remove the outputs
<civodul>cbaines: ah yes, it's not possible to just "rebuild" something already built, except in "check" mode
*zzappie looked up wth is komputilo for the first time
***link2xt[nm] is now known as link2xt
<zzappie>is there a reason why shepherd service record has modules field? Why not manage modules with gexps?
<cantillion_>Hello, I keep getting the dreaded 'hint: Consider installing the `glibc-utf8-locales' or `glibc-locales'' warning despite having both defined $GUIX_LOCPATH and installed glibc-utf8-locales. Last time I let it go, but I'm now setting up a new laptop and this time the annoyance threshold is reached. This warning won't go away. Yes, i logged out and logged back in, rebooted. Everything is done as advised. I even used the official Guix
<cantillion_>shell script to install guix, something I would normally never contemplate doing. Any clue?
<cbaines>as far as I'm aware, the message can appear when follwing the instructions won't help, unfortunately there's some thinking to do
<cbaines>cantillion_, what locale are you using? (LANG and LC_ALL environment variables)
<mbakke>cantillion_: do you have GUIX_LOCPATH defined in /etc/systemd/system/guix-daemon.service?
<cantillion_>well, thinking is possible, I'm here aren't I ;)? Checking: LANG=en_US.UTF8 LC_ALL= (according to the `locale` command output)
<cantillion_>@mbakke in guix-daemon.service I have: Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8
<mbakke>cantillion_: does the root user have glibc-utf8-locales installed?
<cantillion_>but that basically explains the problem. The warning should include the name of the user as which the glibc locale package should be installed, I think...
<cantillion_>@mbakke: are you aware of other packages that need to be installed as root? I'm updating my 'first steps after installing guix' checklist.
<mbakke>cantillion_: just glibc-locales, and you should run 'guix pull' as root regularly to get security updates for the daemon
<mbakke>or adjust the guix-daemon service to run from a different profile :)
<cantillion_>@mbakke: even if running from a different profile, the guix-daemon still need to run as root on a foreign distro, correct?
<leoprikler>there are some non-root Guix setups but they result in a performance penalty IIRC
<cantillion>@mbakke: you recommend running `guix pull` as root to get security updates. I thought guix pull was more like `apt update`, not `apt update + apt upgrade (security updates only)`. Did I miss something there as well?
<roptat>cantillion, guix pull is like apt update indeed, to get security updates, guix at least needs to know they exist ;)
<cantillion>@roptat: i run guix pull as *non-root* all the time, does it update a system-wide .git clone of the guix repo that is visible to the daemon?
<cantillion>now I'm worried that guix pull as root uses a different clone from guix pull as non-root, using twice the space, and needing twice the time to git fetch.
<canant>Hi team, I'm trying to figure out how guix-data-service getting job/build logs from my local build-coordinator.
<canant>Is there anyone familiar with guix-data-service and build-coordinator?
<bone-baboon>When I try to pull from a substitute server I have set up I get a authentication error. I want to get this working so that some of the computers I have Guix installed on with smaller system resources can take advantage of the build from source work of a computer with relatively more CPU and RAM. Here is further information on what I have done so far. https://lists.gnu.org/archive/html/help-guix/2021-04/msg00272.html
<canant>I've found the script called guix-data-service-process-job but have not successfully run it yet. FYI cbaines
<rgherdt>Hi all. I have a question regarding licenses of libraries. I was up to install some libraries and saw that guile-srfi-180 (Expat) relies on guile-srfi-145 (GPL 3, although the original srfi-145 code is licensed under MIT). According to GPL that's not allowed, right? Where should I report this? Is there a tool to check licensing compatibility issues in guix?
<rgherdt>nckx: I have no idea. I'm asking this, because I'm considering packaging a library that's MIT, and relies on srfi-180. So I was unsure, if the indirect usage of guile-srfi-145 would impose GPL to my code
<leoprikler>rgherdt: only if you distribute guix packs, that include the SRFI 145 code
<leoprikler>raghavgururajan: I think your v5 confuses mumi. "gnu: telegram-desktop: Update to 2.7.3." should not be part of this series, no?
<nckx>rgherdt: The combined work is absolutely GPL, you can't claim it's MIT, but it doesn't relicence your library itself if it just uses the GPL module's public API.
<nckx>I don't think automated detection licence incompatibilies between the free licences in Guix is realistic, because it depends on how things interact. At least the noise would outnumber the data.
<rgherdt>leoprikler: interesting. Is that so because the original SRFI is MIT, or it's a general rule? I.o.w., does it mean I can create a MIT package that relies say on readline (GPL) and only worry when distributing with guix pack?
<raghavgururajan>leoprikler: Oh it was sent by mistake. That message as 1/11. But the correct ones have N/10.
<rgherdt>nckx: I see, thanks for the clarification
<leoprikler>rgherdt: As a general rule, whenever you distribute a bundle, the most restrictive license (e.g. GPL or even AGPL) applies to that bundle.
<leoprikler>Due to the way Guix is structured, you'll most likely have some GPL stuff in there.
<rgherdt>ok, so say I write a library using guile-json's public API, which is completely GPL. Then my library should be GPL, correct? Or that only applies to the bundles I might release?
<leoprikler>raghavgururajan: python-colorful, python-yaspin, python-pytest-click, python-lunr, python-mkdocs-material have somewhat funky descriptions (some of them lacking information, some of them sounding like advertisements)
<roptat>hm, I'm having an issue building the website: Throw to key `match-error' with args `("match" "no matching pattern" #<<artifact> file-name: "static/packages/js/build-status.js" writer: #<procedure 7fb504aefc40 at haunt/artifact.scm:64:17 (output)>>)'.
<civodul>oh, that must have to do with the new Haunt release
<leoprikler>nckx: Installing Guix twice used to work at some point. I overwrote my Guix a few times before I arrived at my first workable system config.
<dongcarl>Just realized there are tshirts too! I’ve been meaning to get new ones :-)
<nckx>leoprikler: That's probably more common than not when first installing Guix, but this seemed different in that (1) the installation was successful and complete (2) they restarted cow-store and that's when old memories interfered with the new. I didn't look closer (in a VM etc.) yet though.
<nckx>* restarted cow-store without rebooting the installation environment afresh.
<civodul>hmm that makes me wonder about the status of the release song
<TheAsdfMan>Today i did a guix pull, there wasn't any critical updates, but when i did a guix system reconfigure it redownloaded and reinstalled every single package, after that the same thing happened when i did a guix upgrade, this is the first time i had to reinstall/recompile every package that's why i am asking, thanks!
<mbakke>sneek: later tell cantillion guix-daemon runs from root's 'guix pull' profile (separate from the 'package profile'). You can change the service to start any guix-daemon executable, but the daemon still needs root privileges.
<leoprikler>Okay, it seems tdlib is caught in some timeout. *Sigh*
***Server sets mode: +cntz
<bluekeys>Hi guix. I'm trying to install pidgin and not getting very far. I've done guix pull, then guix install pidgin. The error is build of /gnu/store/...gupnp-1.2.4.drv failed. Then its a could not find build log message, then a couple of cannot build derivation messages. Can anyone explain what any of that means? Is it just me?
<simonsouth>bluekeys: Seems gupnp is failing to build on your computer for some reason. This must be a package on which pidgin relies.
<simonsouth>Is it possible you're out of disk space? What does "df -h /tmp" show?
<simonsouth>Also, what kind of CPU does your computer have? Seems the Guix repository has a pre-built Pidgin package for 64-bit but not 32-bit PCs.
***iskarian_ is now known as iskarian
<mhj[m]>Seems like the most recent build is failing for me. Can't seem to build appstream-glib dot drv during a sudo guix system reconfigure after doing guix pull
<mhj[m]>Should I just wait for the next commits before doing another pull and reconfigure?
<leoprikler>mhj[m]: You can try a few commits earlier if that helps.
<leoprikler>It seems the most recent appstream-glib failed on CI, I'm investigating the cause
<mhj[m]>Well I'm not in any rush, and thanks for the hard work to keep Guix going!
<PotentialUser-60>How do I turn off logging in tty1? I'm getting a bunch of logs about seats(elogind?) and ntpd
<leoprikler>mhj[m]: Try pulling now (90b4890c630637d1eb4711a7a57f610bbf9cfa57)