<bone-baboon>What suggestions do people have to help speed up commands like `guix pull --no-substitutes` and `guix system --no-substitutes reconfigure configuration.scm`? <nckx>rekado_: <firewall> Thank you! <awb99>when using guix as package manager, how do I add a second profile to my user and how do I switch between them? <awb99>I cannot get to work it with this links though <awb99>this link explains how to create a profile <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. <nckx>It wasn't much of an answer but I hope it helps. <awb99>I am surprised that my question does not come up more frequent. <awb99>I use guix only as package manager, <awb99>and some packages only work inside a guix environment, because they fuck up the host programs (python and ssl certs come to mind) <awb99>so I have to have multiple profiles, <awb99>and just to make sure the garbage collection of old guix packages does not delete all my packages in other profiles <awb99>this means I hae to run also a profile with allpackages <nckx>The canonical way to use multiple profiles is to use ‘guix environment’, because that's what they really are. I don't understand why you say GC'ing one profile deletes packages in others. *nckx is nodding off in front of the laptop and needs to 😴, I'll catch up tomorrow. ***sneek_ is now known as sneek
<apteryx>sneek: later tell civodul at last, RC1 is out <Noclip>guix graph --list-types mentiones them <Noclip><Noclip "What are implicit inputs?"> Seems like implicit inputs are those inputs that are defined by the build system and not the package definition itself. <nckx>Noclip: Your understanding is correct. <mroh>Good morning nckx & #guix <g_bor[m]>Do we have a summary on what's new in 1.3 rc1? <g_bor[m]>I would like to bring more attention to this, but recently I was not active, and do not know what to highlight. ***zap1 is now known as zzappie
<nckx>That's 2 people in as many days asking for a Fractal. What is it? <zzappie>there is another client available already btw: quaternion *nckx gets zzappie's haha now. *zzappie sorry for cheesy joke <PurpleSym>Hm, the key used to sign releases changed from 1.2 to 1.3rc1? Is there no key used for releases only? ***bdju_ is now known as bdju
<nckx>PurpleSym: The ‘key to sign releases’ didn't change. The RC was cut by a different person than civodul who will sign the final release. There's no separate release key. <PurpleSym>Oh, I see there’s now two keys listed in guix-install.sh, which breaks our CI, since it only imports Ludo’s. <nckx>PurpleSym: By ‘our’, do you mean ci.guix? <PurpleSym>No, sorry, bad phrasing, “our” means my GitHub Guix action. <nckx>Maybe we could publish a list(s) of keys to sign releases & RCs, but then who signs that... :) <nckx>(Or the obvious ‘release key’ method, but it has its drawbacks. I think the current model was deliberately chosen, but ask civodul.) <cbaines>there's no easy way to find the GC roots for a live store item is there...? <PurpleSym>I was just confused until I noticed the script prompts for a different key after you import the first one. Just an UI issue. <civodul>cbaines: not really, we should address that! <sneek>civodul, you have 1 message! <sneek>civodul, apteryx says: at last, RC1 is out <civodul>cbaines: you can check whether a store item has referrers <civodul>if it doesn't, then check "guix gc --list-roots" <cbaines>civodul, yeah, I think I managed to trace the references manually <nckx>Oh, ‘--list-roots’ not taking an optional argument surprised me. <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_>so the warning is coming from the daemon running as root, and the user will install as non-root a package that has no effect on the daemon, correct? <cantillion_>i'm not clear yet on what needs to be guix installed as root. I install everything as non-root, always, to understand these edge cases. <mbakke>cantillion_: yes, installing glibc-locales for your user has no effect on the daemon. You could change guix-daemon.service to refer to your user instead of root however. <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? <nckx>rgherdt: That sounds fine? Could you explain why you think it's a problem? <rgherdt>nckx: as I understand, code that uses GPL code should be released under the GPL <nckx>rgherdt: Is ‘relies’ such a tight coupling that it can't be considered a dependency between two free components? <nckx>rgherdt: Depends on ‘uses’. <nckx>There's no tool (at least not part of Guix proper). You can report licencing bugs to bug-guix@ or guix-devel@, depending on how sure you are it's a problem. But either is fine and will be read. <leoprikler>As far as I understand it, the guile-srfi-145 dependency should be able to be swapped with any other implementation of SRFI 145 <leoprikler>as long as guile-srfi-180 follows the SRFI to the letter and does not depend on any implementation detail <nckx>And if you ship them together the GPL applies, but that's fine. <rgherdt>nckx: I didn't find the source, but this comment refers to "relying on API" as derivative work: <nckx>Does that not imply that an implementation owns its API and that APIs are copyrightable and other such dangerous things? <rgherdt>leoprikler: that makes sense, thanks <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. <leoprikler>Guile-readline is completely GPL and as a result if you form derivative work of it, you must also be GPL. <leoprikler>But the SRFI 145 is Expat by SRFI rules. Only the Guile implementation of it is GPL, which brings you into this weird spot. <leoprikler>If you wrote a non-GPL guile-srfi-145 without looking at the GPL one and used that, the bundle could be Expat as well. <rgherdt>leoprikler: I thought about that, but having two packages only due to license issues would be lame <raghavgururajan>leoprikler: So messages #51 to #61 are the correct ones of v5 series. <nckx>pineapples: <seatd> OK! Happy migration. <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) <leoprikler>rgherdt: since everything about guile-json is GPL, your code would also need to be GPL (my understanding) <civodul>now's a good time to try it out and report bugs! <apteryx>yay! I gave one week in the announcement message on guix-devel; I hope that wasn't too optimistic <apteryx>on my side I'll have the NEWS and blog post to complete <civodul>apteryx: i think 7-10 days is realistic <civodul>we can have an rc2 in a few days, then leave a couple of days, and then redo "make release" without changes if there are no serious issues <leoprikler>raghavgururajan: "Colorful provides an array of text styles, that can be used as functions or string constants to form colored terminal output." <civodul>apteryx: let me know if you need help with NEWS too; for now i assume you "hold the lock", sounds good? <apteryx>Perhaps I'll create a new issue to track its progress and share patches there, so that if something missing they can be tacked on <civodul>yes, or you can push changes straight into version-1.3.0, whichever is most convenient for you <apteryx>ah, that does sound more easy, if we don't mind the git history too much ***jonsger1 is now known as jonsger
<leoprikler>I just discovered guix build -m and now I'm happy <raghavgururajan>leoprikler: For Yaspin, "Yaspin provides a terminal spinner to show the progress during <leoprikler>"to show the" => "to indicate" sounds better to me personally <leoprikler>"during long terminal" => "in the terminal during long" <leoprikler>the operations themselves happen elsewhere most of the time :P <leoprikler>or wait, we already have "terminal" in front of spinner, so just "during long operations" is fine <civodul>roptat: i "fixed" the devel manual and cookbook at guix.gnu.org, basically by building guix-translated-texinfo.drv with --cores=1 <raghavgururajan>leoprikler: Pytest-Click: "ytest-Click provides plugin for Python testing framework, <leoprikler>I'm not sure how well "this package" is perceived, but I would personally tend towards "This package provides a plugin to test Python click interfaces with pytest." <leoprikler>Now listening to: Utada Hikaru - Simple and Clean <roptat>civodul, ah, sure I can take care of that, will push shortly if all goes well :) <civodul>i think we owe it to a colleague of mine <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>does anyone have data on how long the tdlib tests should run? ***jonsger1 is now known as jonsger
*raghavgururajan forgot about tdlib <leoprikler>Hmm, if we do, we also need to move emacs-telega there. <civodul>roptat: i pushed a fix to guix-artwork, should be fine now <civodul>the i18n module was accessing Haunt internals that changed in the meantime <leoprikler>raghavgururajan: w.r.t. python-lunr, instead of mentioning lunr.js, which is dubious practice at best, I think copying parts of "What does this even do?" makes more sense. <leoprikler>In particular "[python-lunr] parses a set of documents and creates an inverted index for quick full text searches." <leoprikler>"is a static site generator that’s geared towards" => "is a static site generator geared towards" <leoprikler>btw. don't take my python-lunr blurb as the full description, it is probably better to be a little more verbose for this package <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 <civodul>apteryx: one thing that's suboptimal with the release process is that guix-1.3.0rc1.drv (which is the one people need when the install Guix System) is never picked up by ci.guix <civodul>because we usually push that commit and the next one at once <civodul>i've started a build of this derivation manually on berlin <leoprikler>I haven't built or run the package, so I'll have to trust you on that front <leoprikler>w.r.t. python-nltk what's the rationale for jumping to 3.6.2? <leoprikler>btw. since you use git for 3.4.5 it might make sense to use git for 3.6.2 as well <raghavgururajan>leoprikler: Since I was around nltk, I updated it to the latest version. <leoprikler>I just saw that doing so is fine, since there's no other dependant. <raghavgururajan>It think PyPi is fine for it, because we intend to keep the other lower version temporarily. <leoprikler>well, in that case you can also use pypi zip for 3.4.5, no? <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! <leoprikler>not atm, but let it rest a day or two. others already gave you pointers in the ML, there's a chance I overlooked something <sertified>I got an error when guix is building appstream-glib <lfam>We use something called "grafting" to deliver security updates of core packages without requiring recompilation of all the dependent packages <raghavgururajan>leoprikler: Btw, what's wrong with mentioning .js? I have seen things like "foo is an implementation of bar, written in xyz". <lfam>So, recently we "ungrafted", which does cause recompilation. Those who use binary substitutes will have to download many new packages, and everyone else will have to recompile <TheAsdfMan>@lfam oooh that explains it, i knew about grafting that's why i thought it was weird, because grafting is made so we don't have to compile every time there is a security update <leoprikler>Well, the advice I got when I packaged oshu was "don't make it sound like a cheap copy" <lfam>`guix pull` won't have reported any changes because these updates were already delivered weeks or months ago <TheAsdfMan>lfam does "ungrafting" happend often? or is it just this time <lfam>It's not a one-time thing. Every graft must eventually be "absorbed" <lfam>So, it happens periodically. <lfam>Grafting is kind of cheating, when you think about it in terms of how Guix is supposed to work. So, eventually we have to pay the piper <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) <leoprikler>PotentialUser-60: try booting the kernel with quiet <leoprikler>(Disclaimer: I didn't actually try this, found it on Arch Wiki) <mhj[m]>It built appstream-glib successfully, now to see if the rest goes through <nckx>Did something gnomey change to cause all these schema-based test failures? <nckx>Resident gnomologist raghavgururajan ☝ <leoprikler>that touched on some of the glib stuff and if any of those propagated glib-desktop-schemas while the newer one doesn't, well then you're in trouble <mhj[m]>Still wouldn't completely build. It successfully built appstream-glib, but some of the other stuff like gupnp failed and then it wouldn't build icecat or anything else lol <mdevos>sneek: later tell nckx: I can send the patches with "git send-mail" if that is more convenient <PotentialUser-60>leoprikler: already tried that, didn't help. I don't think these are kernel messages, they're different from dmesg output. ***stikonas_ is now known as stikonas
<leoprikler>for anyone who wants to take it: gupnp has the exact same issue as appstream-glib <bluekeys>@simonsouth df-h shows only 30% usage and I'm on a 64 bit machine. <bluekeys>Are there any good package building guides. I feel like I'll never manage it. I'm trying to build zig from ziglang on github. <simonsouth>bluekeys: Seems there is an issue with the gupnp package at the moment. If you scroll up there's some discussion above. <rekado>nckx: <firewall> is it actually working now? <rekado>(just need to know so I can tell the IT folks to close the ticket) <awb99>is there an easy way o install node-js that is more up to date than lts (currently v14) in guix? <vagrantc>was python affected by the recent ungrafting? i just had a build failure on aarch64 :( <nckx>raghavgururajan: OK. It's just striking that several ‘gnome’ inputs no longer build. <mdevos>nckx: did you receive my sneek-mail? <nckx>raghavgururajan: Presumably a heavily used meta-package :) <mdevos>sneek: did you send my sneek-mail to nckx? <nckx>mdevos: I was just about to respond. sneek is... sleeping? Dunno. <mdevos>sneek: later tell mdevos: Testing ... <mdevos>sneek didn't tell ‘Got it.’ when I send my sneek mail <sneek>mdevos, mdevos says: Testing ... <sneek>‘Got, mdevos says: it.’ when I send my sneek mail <vagrantc>maybe sneek is only taking complments for mayday <bluekeys>What does "source expression failed to match any pattern" mean? <vagrantc>hrm... python failure was transient, all seems fine now ... which is kind of :) ... but also :/ <civodul>bluekeys: it means there's a syntax error, for instance if you write (let (x 1) x) instead of (let ((x 1)) x) <bluekeys>Hmm... I can't understand the difference between the 2 expressions you gave. I've got a lot to learn! <sneek>Welcome back leoprikler, you have 1 message! <leoprikler>I'm currently running guix build gnome from my pre-inst-env, but it seems to behave fine so far <leoprikler>Hmm, what's the rationale between inputs vs. native-inputs for gsettings-desktop-schemas? <nckx>leoprikler: I don't see any executables in g-d-s. <nckx>Maybe some database format isn't stable across architectures. <nckx><what's the rationale> I thought the fix was yours anyway.