<Cairn>I added the packages I needed under the `(packages (append (list)))` section and I've pretty much been using that since then
<blake2b>gotcha, so its a system level installation, rather than user level. and where does "echo $GUIX_PROFILE" point to?
<Cairn>Whenever I add a package in that list, I have access to it. Not sure if I've done something wrong or not I suppose. But when I've used guix install, I've removed the package later and added it to my config.
<nckx>Cairn: But you're not sure that it's supposed to change?
<Cairn>nckx: Yeah, I don't actually understand it much. My hope was to be able to get anything to change so I can at least know if the config works
<nckx>You might be chasing some side effect that isn't even expected to happen. Instead, if you disable anti-aliasing for all fonts, do new clients have pixely fonts? Try observing something at that level, rather than trusting fc-list to display what it might not be intended to.
<blake2b>nckx: what is the proper way to ensure your envars are always sourced?
<nckx>I can quite easily make new terminals without antialiased fonts just by putting <edit name="antialias" mode="assign"><bool>false</bool></edit> in my fonts.conf, for example.
<Cairn>Also yeah, why is that re: sources? `guix package install` always recommends "setting the necessary envvars by running:"
<nckx>blake2b: If you use Bash: nothing. That's the system's job.
<nckx>To complicate matters I do not use Guix Home and I use a display manager/compositor combination that buggily refuses to properly source profile (SDDM/Sway) so I have to manually hack around it. But that should *not* be the default.
<Cairn>Yeah, so after I installed chess, I can't get it to run in a new terminal. But if I run the recommended two lines that you see in the paste I shared, then I can run the chess program
<nckx>Cairn: What you describe is not normal. So in a new shell, $HOME/.guix-profile/bin isn't even in $PATH?
<blake2b>the suggestion is default, putting the source in .bashrc is not
<nckx>Something ain't right. This is going to end with me running a VM, isn't it. I hate VMs. Dangit.
<Cairn>I've been confused since I installed the system. Like I said, I don't often use a program installed in my profile for long without adding it to my config. But when I do, I have to run those two lines to get access to the program
<nckx>The problem is that this part of Guix is quite stateful, or can be, because it's literally old-skool ‘skeleton’ files that get installed once, so there's no guarantee that what my 7-year-old system has is the same as what yours has. Even if I hadn't edited them. Hence the VM. And no apologies needed, I'm currently as confused as you are.
<blake2b>nckx: I agree that sane defaults should be the norm, but it also seemed in line with Guix's philosophy of letting the user design their own system
<clever>nckx: an example of something matrix did a few days ago
<Cairn>Hey, I've been curious about this: Why does Guix group package definitions instead of giving each definition its own file? Feels like it'll only become a more cumbersome example of the genre groblem
<Cairn>Not familiar with how they do stuff, although if they avoid the genre problem, that seems pretty sensible
<lilyp>But honestly, Guile as a programming language makes file-based modules more meaningful than alternatives.
<vagrantc>Cairn: i've wondered this as well ... basically all files already declare their module dependencies ...
<nckx>Well, first of all, don't take the genres too seriously (Guix does not use them to present ‘categories’ to users, somewhat by design, because we know many placements suck). I can't speak for the origins but I think single files would not be worth the overhead, not magically solve loops, and bring new problems. Not that I tried.
<nckx>Cairn: Hence my previous note, it might help that we don't pretend that it's *that* meaningful a categorisation. We'll happily put a package in a spot that doesn't make perfect taxonomical sense if it helps fix a technical problem, and not feel bad about it. And then there's admin.scm, sigh.
<nckx>Maybe there's a specific definition of ‘genre problem’ that I'm not aware of, but I still don't see the problem if we're not *trying* to be accurate.
<vagrantc>nckx: if you have a bunch of files that *look* at a quick glance like there's some order to it, and then you have to know the lore that they actually really don't have an order ... that is a weird learning curve
<nckx>‘Oh noes, I should put this package in foo.scm but that causes some technical module problem unless I put it in bar.scm which isn't the taxonomically corr—’ ‘Nah just put it in bar.scm we don't care’.
<nckx>The names are there for humans, but not as part of a meaningful genre tree.
*vagrantc notes debian has this concept of Sections that are basically not used by anything but are still required by Debian Policy and sometimes break things for no particular benefit
<nckx>Cairn: As I said, it likely lowers overhead (not just computational) in the current implementation. If you want to suggest a different implementation (e.g., automatic module imports) that might solve other annoyances at the same time that would be pretty great, but even then the ‘genre problem’ is irrelevant in the Scheme of things.
<nckx>I just mean any whiff of technical advantage would outweigh our extremely informal categorisation which is not, I'll stop saying this now, intended to be meaningful in the first place, but that doesn't mean it has no reason for existing, just that the reason is technical, and it helps to give names to things even if they are vague guidelines.
<conjunctive>Hello, when writing a development environment (as guix.scm in a repo), how should I constrain the version of Ruby being used? Added ruby-3.1 to native-inputs but the environment still loads it with ruby-2.7.
<nckx>Guix doesn't do constraints, certainly not when using variables like you are. So something else is going on (not that I know what).
<nckx>Mako sure your environment is --pure is my first thought.
<itd_>Hi. I'd like to use GUIX_PACKAGE_PATH with 'guix import json' but end up with 'no code for module'. E.g., I'd like the imported 'hello' package to depend on 'my-foo-bar': https://paste.debian.net/hidden/b8bf2abe Where's my mistake? Thanks!
<unmatched-paren>but i suppose that kind of handholding may be quite annoying for people who actually do `sudo guix package`
<nckx>Never mind, I'm a ding-dong. .config.guix-profile is a symlink to the store. It's *always* going to be owned by root. So what determines hypothetical borkage would be the ownership of the parent (~), which is what we'd check for but is already correct, so all seems good.
<unmatched-paren>The other (more common?) pitfall I was thinking of addressing somehow was `guix install guix`.
<nckx>‘Non-functional data’ is allowed (nitpick for onlookers, you probably know: Guix merely follows its interpretation of the GNU FSDG in such matters). Guix-only criteria like the CoC don't seem to apply here.
<nckx>Hot take: global init files should always be written for & sourced by a Bournish shell, and any altshells launched afterwards. (Although I've heard fish can source Bournish files with something called ‘bass’.)
<Cairn>Theory: maybe it only gets added to my path if I have packages installed in my profile when I log in.
<yuu[m]>Cairn: doesn't seem to pick anything including cursor. so idk, i'm testing on a nix shell tho. haven't set a gui for my guix yet
<yuu[m]>Cairn: i remember it used to work on arch linux
<pkill9>now weirdly waybar doesn't start when sway starts, but it does when I run it from terminal after
<yuu[m]>maybe you also need to set gtk2 gtk3 cursor
<Cairn>nckx: I've done most of my reboots after a guix system reconfigure, which I've generally done after adding locally installed packages to my system config (and then removing those local packages). So I've probably rebooted with nothing in my local profile, so it hasn't been able to set a path to a nonexistent location
<abcdw>git verify-commit 39465409f0481f27d252ce25d2b02d3f5cbc6723 gpg: Signature made Sat 06 Aug 2022 07:28:23 PM MSK gpg: using RSA key 28419AC650387440C7E92FFA2208D20958C1DEB0 gpg: Good signature from "Andrew Tropin <email@example.com>" [ultimate]
<nckx>I'm ~pretty sure~ that master is OK now, maybe there is residual state (I'd expect a 'descendant' error, not this one, though).
<lagash>Hey all! I got access to a much faster machine recently and have decided to try Guix again, in a VM. I see PotentialUser-47 beat me to discovering `guix pull` no longer works..
<nckx>Doing this on a borrowed netbook with azerty keyboard ssh'd into a server that didn't even have GPG or keys over a wireless link that keeps dropping whilst relaying my progress over a phone is my own private checkout of hell.
<lagash>It appears the offending key is from a certain Andrew Tropin, hmm?
<nckx>lagash: Sounds like an evil hakkor to me. I'm trying to pull on a different machine than the one on which I 'fixed' it, and that never pulled the invalid tip. If that works, we just have to figure out which local state y'all need to purge.
<nckx_>I can't puzzle my way out of this box, maybe some coffee will aid me in this quest.
<nckx_>'The less-good news is that our remote git hook should never have allowed this to happen in the first place, and that this weakness has been known for... well, a while. Any committer can DoS guix pull in a way that even the maintainers can't fix unaided.'
<abcdw>lagash: I usually pull of my local checkout with a few patches, so I need to use --allow-downgrades if I want to pull from original repo.
<unmatched-paren>proposal: deferring master using the CI. push commits to a master-staging branch. when a push to master-staging happens, the CI does a few basic sanity checks like making sure guix pull works, and forwards the commits to master automatically if all is well.
<lagash>so wait, let me get this straight.. guix pull git clones or whatever to ~/.cache/guix/checkouts/ - could I manually apply that one patch to get the authorization working??
<nckx_>unmatched-paren: We should do something like that for other reasons, but the correct fix here is the git push hook, and we've known this for *ages*. It has to hurt (like now) to remind us of that simple fact. Until then it's alway to-do.
<nckx_>Invalid commits making it to the CI is too late (it's a good sanity check, but not the right place to address the root cause).
<lagash>So where is the "system" guix authorization file at?
<yewscion>Just wanted to share: I love this community. This was the fastest resolution to what could have been a long issue that I've ever experienced as a user in FLOSS. When guix pull failed, I thought I would be stuck on my current pull for days. The fact that I was able to fix it for myself with a single command <5 minutes after discovering it is amazing to me. So glad to be a (small) part of Guix.
<nckx_>Unfortunately, it has not been resolved yet.
<nckx_>I thought (well, hoped, really, because it was all a bit hectic) that it was.
<nckx_>But thanks for the spirit of the reply; I'm trying other things :)
<nckx_>Unless you're here to say no, it really did work for you...?
<nckx_>Then I'm very confused but I'll gladly take it.
<yewscion>Haha, it's still running, but I'll let You know. Regardless, I'm still happy that things are being discussed and tried and fixed this quickly.
<nckx_>I maintain that I did nothing special on the first host (sorry if this is getting confusing), merely pushed to Savannah master, then ran 'guix pull' with no custom channels, and it worked.
<nckx_>Since Guix does not care about your user gnupg installation or anything so stateful, it *must* have considered the commit valid based only on what's upstream.
<yewscion>In case You don't want to disable authentication: I've pinned the guix channel at ad878a and pull has worked fine. There are currently no new commits past that other than the problematic one and an attempted fix.
<yewscion>("You" being anyone who might see that message, not anyone specifically.)
<kimjetwav>Getting a good bargain from Lord Vader on the trustability of the committer pool.
<df>so what is the current advice? I don't have an urgent need to do a pull so happy to wait if there are plans afoot to make it easier, or is there some hack I should just do now?
<nckx_>So, where we are: I've pinged Savannah admins I know here, but no answer of course (these things always happen on week-ends, and ideally in summer or on holidays). I've sent a mail. Now we wait.
<kimjetwav>Yeah I noticed there was nothing about it on the lists.
<nckx_>df: (1) If you don't need to pull, just don't, that's fine (2) if you do, use 'guix pull --commit=ad878a2c5e5313c534ccf2546cb8c978e5295ae1' which is the latest commit that authenticates.
<nckx_>I would not recommend disabling authentication. Even though the chances of somebody subverting your Guix just now are miniscule, there's simply no benefit. You'd get one commit that (IIUC) doesn't fix any user-facing bugs.
<nckx_>kimjetwav: Too soon, I've been trying other things.
<Cairn>nckx did you message b andali? He's normally online
<nckx_>I explicitly didn't because I thought he left that role.
<Ox151>hello I am trying to convert my first pacakge from source to a guix package. it has the build requirements libssl libcurl libunbound libzmq, but i cannot find those in the guix package repo. i see openssl, curl, unbound, czmq, but i am not sure if those include the libraries needed to build this package.
<nckx_>Next up is discussing how/whether Guix should authenticate subkeys, if that makes sense to you civodul. If you think the current (strict/naive) design has the advantage of simplicity, I can see that, but it needs to be documented as an important detail.
<nckx_>I don't think anyone made a stupid mistake here.
<Cairn>Gosh, I think I'll give up on this package modification stuff until I actually read the full manual.
<nckx_>I haven't been following your subplot but I think you might be in want of substitute-keyword-arguments. Which is... not the most newcomer-friendly construct, and I don't know if it's (well-)documented, but it's nice and powerful once you get it.
<Cairn>I was sorta trying to take my issue into my own hands in the hopes that maybe I could submit a bug report. But that might have to wait a week until I work through this manual.
<nckx_>I think we're good to go. Try 'guix pull' and report your user experience index.
<Cairn>unmatched-paren: I don't wanna waste your time with handholding me through it, but unfortunately that still doesn't quite make sense to me
<vagrantc>feel like i missed out on some exiciting discussion ... but i'm very curious about this testing of guix's signing procedures
<nckx_>Short synopsis: Efraim put the (what's the term?) 'main key' in .guix-authorizations, but Andrew uses a subkey. Which works, but you have to authorise *that specific subkey* (I'm an example of this). This is not how GPG usually works, or at least how I understand it.
<Cairn>And I have a bunch of larger questions about how I'm supposed to apply this in my own config anyway, so I'll just leave it for now
<unmatched-paren>Cairn: Well, it basically takes a list of arguments, like (list #:tests? #f)
<vagrantc>the whole point of subkeys is kind of to be able to revoke them willy-nilly as long as the master key is still valid
<nckx_>I'm an exception because I'm vaguely aware of this gotcha and would double-check, but I don't think it would be unreasonable for any other committer to change (only) their subkey, and continue pushing to master in good faith.
<vagrantc>though, also with the guix model, since the "keyring" branch is kind-of in-band (e.g. from the same git repository), any keyring updates need to land there in order to start signing with a new key
<Cairn>And if I add a functional version of this to my config, does it itself count as an included package? Like can I just throw it in (operating-system)? Or do I need to put it in (opterating-system (packages))?
<vagrantc>does guix explicitly check out the master branch, or just the default branch set for the repository?
<atka>hi guix, any reason my uefi forgets about guix after every guix system reconfigure? I manually have to point to grub every time in uefi
<Cairn>unmatched-paren: Nah, sorry. This is too complicated for me right now, haha
<atka>other than buggy uefi implementation, but it only happens with guix and only after a system reconfigure
<Cairn>atka: What's your config look like? I thought the bootloader and file-systems section were supposed to handle that?
<vagrantc>atka: did EFI's NVRAM storage run out of space?
<jackhill>vagrantc: would be nice to swtich, but it looks to me like %default-guix-channel in guix/channels.scm specifies master
<jackhill>so it won't get us out of this situation, but I suppose we could start pusing the same commits to both master and main (or whatever) and update the default channel, and remove master at some point in the far future
<vagrantc>well, could start using $otherbranchname now, and people can explicitly guix pull --branch=$otherbranchname ... and then eventually slap that on top of master, or make the first commit change %default-guix-channel to point to $someotherbranch
<vagrantc>and then just put that one commit on top of master once it gets reset...
<vagrantc>wonder if anything else in guix assumes master, or if it is just properly %default-guix-channel everywhere
<jackhill>oh yeah, maybe we don't have to wait that long. It would switching would just mean pulling twice and maybe updating and non-default references to that branch
<jackhill>I wouldn't think so, as I don't even have to use the %default-guix-channel, and instead use the jackhill branch on my custom fork
<jackhill>I suspect the master term is used a fair bit across the package collection descriptions…
<vagrantc>i typically guix pull --url=/home/vagrant/src/guix --branch=master but that's just an optimization to only download git once
<vagrantc>that people don't use subkeys actually makes me nervous
<vagrantc>i mean, i know openpgp is hard enough ...
<pkill9>has anyone configured their guix so guile is the default shell?
<nckx_>Sure. And renewing my subkeys ever 2 years is always a journey of rediscovery. But if I, computor genious, managed to set up subkeys, then anyone can.
<vagrantc>i mean, i know basically forcefully resetting the master branch on savannah is the only way to technically recover, and i guess that is what was done ... but that seems a bit ugly in it's own way
<nckx_>I think we agree on all separate points but I don't see the connection between them.
<yuu[m]>can someone give me a basic example in defining a module and use-modules that module in another module? i can't seem to make it work
<yuu[m]>(suposing the files are in the same directory)