IRC channel logs


back to list of logs

<blake2b>Cairn: Actually, I'm looking at the package definition
<blake2b>and the search path it needs to look for is not XDG_CONFIG_HOME
<blake2b>the correct path is XDG_DATA_DIRS
<blake2b>theres a note saying that it changed with version 2.13.94
<blake2b>so if "env | grep XDG_DATA" doesn't return a dir in $GUIX_PROFILE/share, you need to source your profile
<Cairn>blake2b: Thanks for the extra info. Looks like it does include my .guix-profile/share directory
<Cairn>So I guess that's not the issue
<blake2b>did you source your profile tho, just in case?
<blake2b>its one of those things that if not done can create all kinds of issues
<blake2b>also "env | grep -i fc" might give you some helpful info
<blake2b>(sorry if this is basic stuff you've already tried)
<Cairn>No it's good; I'm not that proficient
<Cairn>I did source my profile though
<Cairn>Should I fc-cache -rv afterwards? Not sure what difference this makes
<Cairn>`env | grep -i fc` doesn't give me any info
<Cairn>Either way, fontconfig isn't seeing my config.
<Cairn>Not sure why the profile matters, since I don't think I use it for anything
<blake2b>well your profile is where everything is installed
<Cairn>I've installed all my packages with `(packages (append (list)))` so far. I haven't used guix install at all
<blake2b>so you've installed your packages from a manifest?
<Cairn>If that's what that's called then yeah
<nckx>I merely implied this earlier, but running a fontconfig client (‘your terminal or whatever’) with FC_DEBUG=1024 will point out exactly where it's looking.
<nckx>Fontconfig has its groan moments but that debug output is *nice*.
<Cairn>nckx: Sorry, I didn't pick up on that. Where would the output be?
<blake2b>and you installed using guix shell?
<Cairn>blake2b: No?
<nckx>Cairn: stdout, so just open a terminal & run ‘FC_DEBUG=1024 foot’ or whatever you prefer instead of foot.
<nckx>s/out/err/ I dunno, doesn't matter here.
<blake2b>so if you didn't use "guix install" or "guix shell", what did you use?
<blake2b>"guix package -i"?
<Cairn>nckx: Is foot a terminal?
<Cairn>blake2b: 1 sec
<nckx>Any other will do.
<nckx>Other objectively inferior terminals exist.
<Cairn>Hadn't even heard of foot, haha. I'll check it out later.
<Cairn>blake2b: When I was using the iso to install, I just used `lightweight-desktop.scm` as my config and filled in all the info
<nckx>Beware, I think it's Wayland-only.
<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.
<Cairn>It returns a blank line
<blake2b>tbh, I don't have much experience with FC. but it might help to have it installed at the user level.
<Cairn>I'll try
<blake2b>(which would mean "guix install fontconfig")
<blake2b>but you should "guix pull" first
<Cairn>Oh, btw, when sourcing my directory... That only lasts until I close that terminal instance. Do I need to add it to my bash config or something?
<Cairn>blake2b: I'll guix pull, yeah
<blake2b>thats what I do.
<Cairn>Fair enough
<Cairn>I still see antialias: False when I fc-list
<nckx>Cairn: If you're using Guix System: absolutely not. If you're not: still almost certainly not.
<nckx>(Re: adding sources to user profiles.)
<blake2b>nckx, why is that?
<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>Cairn: R
<Cairn>nckx: Why does it recommend running those things then? If it's the system's job I mean
<blake2b>so why does guix tell us to do that?
<nckx>Cairn: There's no way for the guix you just invoked to change the environment of the shell that invoked it.
<nckx>So if you need to use new variables in that shell, you have to re-source the (modified) profile.
<Cairn>But it doesn't seem to update in other shells either
<Cairn>I always have to run those two sourcing lines
<nckx>blake2b: Guix will never tell you to add stuff to shell start-up files.
<blake2b>yes, but it tells us to source our profile
<nckx>Cairn: Guix can't modify other shell's environment either.
<Cairn>nckx: I'm confused. You're saying it's the system's job to set these variables, but that it'll never actually set them?
<Cairn>Like, I never have access to anything I've installed in my profile unless I run those two lines, even if I open a new shell
<blake2b>me too
<blake2b>and its been like that the two years i've been using guix
<nckx>Is there a bug report?
<nckx>blake2b: Which shell do you use?
<nckx>And Cairn too I guess.
<Cairn>I use Rxvt-unicode
<Cairn>And bash
<blake2b>so thats a bug?
<blake2b>its the default behavior of a new system
<nckx>Either you're not describing what I think you're describing or it's not.
<blake2b>ok let me explain step by step
<nckx>So, for my own enlightenment: each time you open a new terminal you have to manually . .guix-profile/etc/profile to use any software?
<blake2b>after running "guix pull", or installing new software
<nckx>blake2b: Yes please :)
<blake2b>guix will say (I can't remember the exact wording):
<lilyp>I don't think "guix pull" should require you to resource.
<lilyp>guix install might; this depends on search paths
<nckx>‘When nstalling [some] new software’ is normal.
<lilyp>note that the first pull and install will *always* show this message
<blake2b>"After running guix install be sure to source your profile with
<nckx>Because there's no way for Guix to clobber the environment of existing (running) processes (shells). But any new shell should just have the new environment variables loaded, full stop.
<Cairn>blake2b: Here's the message I think you're talking about:
<Cairn>I get this after every `guix install`
<blake2b>sorry, it must be after guix profile
<blake2b>i mean guix install
<Cairn>nckx: So new shells should have the vars set? Let me install something random
*nckx is reading the shell initialisation files.
<blake2b>I use guix home now so I haven't seen it in a while. but before, it used to always remind me, and without having the source in my .bashrc it wouldn't maintain the envars from /etc/profile
<nckx>Why are they always spaghettus.
<Cairn>I just ran `guix install chess`, then I opened a new terminal and tried to run it. Couldn't find the program
<blake2b>* i meant $GUIX_PROFILE/etc/profile
<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
<Cairn>nckx: correct
<nckx>I meant ‘should not be needed by default’, my bad, blake2b.
<nckx>Cairn: Absolute wat.
<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
<Cairn>nckx: Sorry for the hassle!
<blake2b>hmm, in my memory/experience its always been needed by default. I thought that this was to ensure that people can set their profile wherever they prefer
<nckx>I don't blame you for being confused, because that is certainly not intentional if I understand what you're describing (still not sure).
<Cairn>nckx: Ask away, I have the time. Here's my $PATH after opening a new shell
<nckx>blake2b: That should not preclude Guix setting sane defaults, though, IIUC.
<blake2b>nckx: did you look at the pastebin that Cairn posted?
<Cairn>Yeah, it gives me that message every time.
<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
<nckx>blake2b: Yes I did.
<nckx>I know that message, but it shouldn't be necessary to do that *every time* you open a shell, nor should it be necessary to run that merely to get ~/.guix-profile/bin in $PATH.
<nckx>blake2b: I'm kind of sorry you've been doing that for 2 years.
<blake2b>haha, no worries I just set it in .bashrc, its never been a problem
<blake2b>and it did have an didactic quality of leading me to explore multiple profiles
<Cairn>I'm glad it came up, cause I thought that it was something I hadn't read yet in the manual. I wanted a comfy system before I read further into the manual, so I've just been focusing on dotfiles
<blake2b>(either that or I have stockholm syndrome)
<nckx>There's still a non-zero chance we're not talking about the same thing. I think I'll hang on to that chance for now 😉 although I'm building an installer just to make sure.
<nckx>Probably won't finish before I yeet off to bed.
<nckx>blake2b: Welcome, compadre.
<blake2b>sourcing in .bashrc isn't a security issue though, right?
<Cairn>I'm around to ping and try stuff out. I tried my best to simply follow the manual installation method.
<nckx>At no point did I mean either of you were to blame, all my wtfs are aimed squarely at Guix if true.
<nckx>Assuming you didn't add the lines to any files anyway :)
<nckx>Well, you did, but you said it was screwed up before that, so it doesn't count.
<blake2b>nckx: 💆
<blake2b>ofc, no worries
<Cairn>Whoa, there's a massage emoji now?
<blake2b>i just found it, I was looking for the salute emoji and was out of luck
<nckx>There's no o7 emoji? Oh.
<nckx>Re: therapist: probably not. substitute: updating substitutes from ''... 53.2%guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error in the pull function.
<blake2b>Cairn: thats the one
<nckx>Cairn: My fonts aren't hip enough to render that 3-byte mojo yet.
<nckx>Which do you use?
<nckx>Ah, I know, never mind.
<Cairn>nckx: I'm connected through the Element matrix client as a bridge. So whatever they happen to ues
<Cairn>Ah shoot, I edited that. Speaking of Element; I have an awful habit of editing messages that I send in IRC, before I realize that they won't show up "edited"
<nckx>Unless they send your browser a bitmap it would still use local fonts, but I remember my issue (surprise, it is PEBCAK) being that I deliberately use an old emojo font.
<nckx>I'm not sure what you're talking about, but here's what I saw:
<Cairn>Whoa! No way!
<nckx>If Matrix generated that s/// sed I am *seriously* impressed. They used to send the entire (edited) line again.
<Cairn>It did!
<nckx>That's a genuinely impressive improvement.
<Cairn>I pressed the up arrow retyped use, then pressed enter. Wow.
<clever>nckx: i noticed matrix doing that a few days ago
<Cairn>I've felt bad editing my messages in the past thinking it was resending the whole lines like you said. That's an amazing update.
<Cairn>Now I'm gonna do it all the time 👿
<clever>it gets a tad hairy when you edit many words
<clever>it turns into a , seperated list of sed exprs
<nckx>What's funny is that I probably used seds on a person who had no idea what seds are because I saw them ‘use’ them themselves. Whoops.
<nckx>(Although if it's that new, maybe not.)
<nckx>Also, too many thems in that sentence, sorry.
<nckx>s/them them/seds them/
<nckx>Much clearer.
<Cairn>To be fair, I don't think a lot of people who use Matrix as an IRC bridge won't know seds
<cleverca22[m]>test foo bar baz
<cleverca22[m]> * test foos bar bas
<nckx>I don't mean this pejoratively, but I think people who don't know seds are more likely to be using Matrix than IRC.
<clever>nckx: hmmm, it didnt generate a sed expr that time
<nckx>So now the question is: does Matrix ingest seds too, and turn them into edits?
<nckx>s/Matrix/glorious Matrix/
<nckx>clever: Maybe it bailed out, and this was better anyway.
<Cairn>Testing some seds
<nckx>It's clearly using AI.
<clever>nckx: that sed just showed up as a sed expr in the matrix side
<Cairn>Nope, I guess
<nckx>clever: Thanks.
<clever>2022-08-02 17:41:55< cleverca22[m]> s/a/both/, s/single//, s/wire/pins/
<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
<lilyp>Because we're not Gentoo :)
<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.
<Cairn>It'd really have a lot of overhead?
<nckx>I'm not sure I want to accidentally tab-complete a gnu/packages with 22k files tho.
<vagrantc>what would get awkward is you basically have to define every dependency twice ... once for the module import, and once in the package definition
*nckx was not replying to Cairn. I did no tests. I was just musing.
<nckx>Tab completion would not be the main reason :)
<vagrantc>you can get some benefit from an a/apackage b/beanotherpackage and whatnot
<vagrantc>but ... i would think guile could make that not impossible? could a package definition import a module?
<vagrantc>some sort of import-as-input function?
<vagrantc>there is also package inheritance ... package-minimanl inherits from package (or vice-versa) ... would you define those in separate modules?
<Noisytoot>nckx: openmoji has 🫡
<vagrantc>Cairn: i'd chime in on a discussion on guix-devel :)
<nckx>Thanks but they ugly tho. (I feel bad saying that because I love the project but it true.)
<Noisytoot>I have them as a fallback
<Cairn>vagrantc: I'd love to, but I'm still so new at this whole system
<Cairn>I still haven't even finished reading the manual! And after that is the Guile manual, and more Emacs configuration...
<vagrantc>maybe i stir up that discussion ... i've often wondered about it
<nckx>Noisytoot: (Nicely following previous topic) So do I but it's not 100% reliable. Probably because XML, possibly for other reasons.
<nckx>Anyway, I am not going to debug fontconfig when I can debug Guix.
<vagrantc>i think once civodul explained some reasons, but ... i'd like a concreate list of pros and cons
<nckx>Cairn, vagrantc: I would ask why it matters?
<nckx>guix edit, boom.
<vagrantc>nckx: it would be so much simpler to know where to put a new package if you just had a naming file order
<vagrantc>a systematic place to put a new package
<vagrantc>nckx: guix pull would only compile files that changed
<vagrantc>so you could maybe get a much higher hit rate if you're pulling obsessively
<nckx>I'm not sure that's true but I can't deny it outright.
<vagrantc>i'm not sure either :)
<nckx>Once you're done tracking dependencies & ABI changes & the like I mean.
<vagrantc>oh, all the dependents would have to be recompiled ...
<Cairn>The genre problem is just an organizational problem, so if there's solutions with less overhead, then whatever.
<vagrantc>some packages do seem to land places somewhat arbitrarily
<nckx>I mean, we're Guix, we're pretty OK at recompiling only subtrees, but this is also not Guix :)
<Cairn>In a bit of a not-safe-for-guix idea, it'd make tracking a "guix user repository" trivial, since file submissions would not need to be organized into the genre structure.
<vagrantc>a whole different angle, why not put all packages in one file :)
<vagrantc>Cairn: and that!
<vagrantc>merge conflicts would be rarer
<Cairn>I think tracking separate files for package definitions a little nicer in git as well.
<Cairn>Yes, merge conflicts, exactly
<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>Indeed, it's not Gentoo.
<Cairn>I just feel like if it's possible to avoid the genre problem without a drawback, then it's worth doing away with the categories.
<Cairn>Makes everything simpler and more future-proof
<Cairn>I'm not very technical here. I've just been a music collector for a while, and I know the struggles.
<vagrantc>the solution to put diffoscope into it's own file was pretty much just because i ended up unable to find a set of modules to import because of recursive dependencies between modules
<vagrantc>and that felt ... weird
<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>Is kind of the vibe.
<nckx>vagrantc: I guess.
<nckx>The curve is ‘I see you take this too seriousl; don't’ but point still taken.
<vagrantc>it won't magically resolve circular dependencies, but it might make them more transparent?
<Cairn>nckx: If there's no reason for the structure, then it shouldn't exist.
<nckx>That's not how it works. Remember, all absolutes are bad.
<lilyp>Only a Sith :)
<vagrantc>all files much be places in a randomly selected .scm file, with the .scm filenames randomly generated
<nckx>I could rephrase that as ‘if a structure cannot be 100% followed at all times, no matter what the cost, it is not worth having’ and that is equally bogus.
<Cairn>Point taken, but I'll hold firm on thinking it'd be better to avoid adding an extra layer of structure.
<nckx>vagrantc: I was going to bring up 0000.scm 0001.scm 0002.scm as an example :)
<Cairn>Each package definition is already its own unit, so why does it need to be categorized?
<vagrantc>nckx: too little entropy
<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 did not deliberately capitalise Scheme.
*vagrantc claps
<Cairn>I guess I'd really like automatic module imports, if there's not gonna be a restructuring someday.
<Cairn>It's really bizarre having to not only list the names of the packages I want, but also the somewhat arbitrary .scm names as well.
<vagrantc>like, import a module because you asked for a package from that module?
<vagrantc>that sounds nice.
<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.
<nckx>> really like automatic module imports
<Cairn>I wouldn't complain about this with automatic module imports
<nckx>Apart from the ‘but from which module?’ question, that would be nice. Coming from Nix that was not a pleasant adjustment.
<Cairn>Well maybe a little bit, haha
<Cairn>How does nix handle it?
<nckx>I have to import fifty-seven what now.
<Cairn>Yeah, I'd love if I didn't have to know module names
<nckx>Well, not better, and arguably worse, but the silver lining is you don't have to import modules.
<nckx>It's basically one huge namespace in a tree that makes little sense if you're not very familiar with it.
<nckx>It's good proof that Guix's genre problem isn't that bad :)
<Cairn>Wow, fair enough
<nckx>You can browse it yourself:
<vagrantc>i guess ~20k mostly small files in every git tree might actually cause more inode problems :)
<nckx>It's not *bad*, it's just not intuitive to me, at least, and I was a Nix maintainer for god's sake.
<Cairn>I have a lot to learn about Guix before I can complain any further.
<nckx>But as you can see (I hope, even if you don't read Nix), there are no module namespaces, zlib and boost and python3 are all just there, chillin in the communal hot tub:
<Cairn>That's so awkward nckx
<nckx>Hygienic it is not, but it is convenient.
<Cairn>I'm surprised they let that happen
<nckx>Wait until I tell you about the unmitigated horror that is all-packages.nix.
<nckx>When you're older or less sober.
<nckx>‘(Sorry about that, but we can’t show files that are this big right now.)’ — GitHub, at a mere 1.4-MiB source file.
<nckx>But if you want to know how the above is implemented, there is no magic, it really is just:
<nckx>Sorry for going off-topic though. I'll stop.
<Cairn>Nah, it's relevant
<nckx>Hmm, I'm installing Guix System but it appears to be frozen on ‘service guix-daemon has been stopped./started.’…
<nckx>Maybe it's just slow despite enabling KVM.
<nckx>Ding ding ding.
<Cairn>The package frotz fails to build for me
<shcv[m]>so, I'm not sure that my `guix pull` issues are due to version conflicts, but either flakiness or taking too long / using too much cpu
<shcv[m]>I'm not sure, but it's possible my VPS provider is killing the process; not sure how it would exactly
<nckx>Unless it's OpenVZ or similar, so am I.
<nckx>Nothing in dmesg? (OOM?)
<shcv[m]>I'll look again after this next try
<shcv[m]>ah, yep; oom
<shcv[m]>so, any recommendations on reducing memory usage for guix on a vps?
<nckx>Besides -{M,c}1, which isn't magic, no :-(
<nckx>Cairn: It builds with GCC 9, but I see there's a newer frotz version too...
<nckx>GitLab's nomenclature ('deployments', 'evidence') is so bizarre you'd think GitHub trademarked 'releases'.
<shcv[m]>would adding a swapfile be enough?
<nckx>(But they use 'releases' deep in a submenu so that ain't it.)
<nckx>shcv[m]: It would help, as would configuring zswap to use something better than the default lzo+zbud, like zstd+zsmalloc.
<yuu[m]><shcv[m]> "so, any recommendations on..." <- remote builds on dedicated machines?
<nckx>That way Linux will use compressed RAM before disc, which is often faster.
<shcv[m]>huh, apparently docked and containerd are consuming >1GB each, despite no running containers
<shcv[m]>lets see if killing those is enough
<nckx>Guix *is* too memory-hungry, no debate there.
<nckx>Cairn: Updating to 2.54 made it... worse. Ugh.
<Cairn>Oh dear
<Cairn>Not to make the problem worse, but I also can't build frotz-dumb-terminal
<Cairn>frotz-sdl builds though
<nckx>Oh... there are multiple frotzen? I thought I was done :-(
<nckx>Can you test frotz, at least? No have Infocom games.
<Cairn>I'm clearly not paying you enough
<Cairn>Let me try
<Cairn>Or wait, you mean you updated it already? Or do you just mean you want me to help testing
<nckx>RTOS GUIX is now #1 on DDG for 'guix git'.
<nckx>Cairn: I updated it (but only the ncurses one) on master.
<nckx>If you pull it should build and even run.
<Cairn>Sweet, trying it
<Cairn>Why does the commit age say 6 days on savannah?
<nckx>Because I'm a quirky snoflake.
<Cairn>Hehe, ok
<nckx>Who runs git under faketime for 'privacy'.
<Cairn>Gosh guix pull takes forever
<nckx>One creep sending 'I can see you committing to GitHub [sic] you now f—ing answer me' was enough.
<nckx>Yes it does.
<Cairn>nckx: omg that happened? That's wild
<nckx>Yup. Their pretty little graph made it trivial to see my activity, so I opted out.
<shcv[m]>but I'm still not sure why `guix pull` would need so much ram that it OOMs
<shcv[m]>well, apparently my server doesn't have much ram
<shcv[m]>but still
<shcv[m]>it's just a pull...
<Cairn>That's a frustrating issue
<nckx>Even with -M1 -c1? Guile just isn't super-optimised and Guix even less.
<nckx>It shouldn't use that much RAM but it's a fact that it does, not just for you.
<nckx>It is a rather large codebase and 'just a pull' actually builds software, not like other PMs, but it's still an order of magnitude off.
<nckx>It's also substitutable but that's useless in your 'I just pushed, could you pull?' case where CI is still building. Sorry.
<Cairn>Poor Guix 😢
<nckx>The typical 'developer workstation' trap. Sure, more of us use old Thinkpads than Macbooks, but they still tend to be maxxed out compared to the average 'user'.
<nckx>I have 16 GIGABYTES of RAM. Only the most elite do.
<shcv[m]>I just added the -M1 -c1 and am trying again; then I'll try adding swap next (I tried adding it to the os and reconfiguring, but I got something wrong)
<shcv[m]>even lesser laptops usually have 8gb
<shcv[m]>my vps only has 1gb though
<AwesomeAdam54321>Isn't 4 GiB RAM the standard?
<nckx>Yah but 16 is like almost twice that. Only Jeff Bezos has that kind of RAM.
<shcv[m]>I have 32 in my laptop :P
<nckx>Then you can probably run Guix pull if you don't have too many tabs open.
<Cairn>nckx: Any more theories about the path issue I'm having?
<shcv[m]>AwesomeAdam54321: yeah, I think 4GB is like the minimum now, unless you get a chromebook
<Cairn>~There is a small mailbox here.~
<Cairn>nckx: Frotz works for me
<nckx>No, the installer VM is still installing. Which is suspicious in its own right but I didn't look into it.
<shcv[m]>scrolling through amazon, even most chromebooks have 4gb; only one or two had 2gb
<nckx>I won't volunteer for the other variants, unless they inherit and my update broke them.
*nckx checks.
<Cairn>Yeah frotz-dumb-terminal still has the issue.
<Cairn>But the sdl version never had the issue
<Cairn>Still I guess it's package updating.
<shcv[m]>how big do you think my swap should be?
<nckx>They don't inherit, which is frankly unexpected, but a relief. Also broken though.
<nckx>shcv[m]: 1, max 2 GiB should really suffice for guix pull. Building some software might need more, you might want to disable parallel builds globally (what -M... does).
*nckx restarts the installer >:-(
<shcv[m]>yuu: does that work for guix pull though?
<nckx>Sure. It's just builds.
<nckx>Hence substitutable etc.
<nckx>It's just moving the problem elsewhere but if you already have an elsewhere then you might as well use it.
<atka>hi guix
<the_tubular> Hey atka, been a while :)
<atka>the_tubular: hello hello
<the_tubular>How are you ?
<atka>i've been incredibly busy, uprooted my whole life, but doing pretty damn good
<nckx>Hi hi.
<atka>hey nckx, how are you?
<nckx>Well! Also busy, but yours sounds more fun. Hope it was (mostly) voluntary uprooting but glad to hear you're doing well either waf.
<nckx>Stumbled at the finish line.
<atka>glad to hear it! yes it was voluntary uprooting
<atka>one day I will get back to work on that fstrim patch... I have a fresh guix install but only 512Kbps internet
<atka>so things are a bit....slow
<the_tubular>Very buys also :(
<the_tubular>Damn 512 Kbps Internet ...
<atka>yeah, its really not that bad though, my work is remote meetings and ssh mostly
<atka>hopefully guix works well on a slower connection, some distros don't
<atka>its stable, decent latency and low packet loss, but I'm only downloading at 40KB/s most of the time
<nckx>Still better than pay-per-byte (assuming it's not).
<nckx>Well, that's just, like, my opinion, but I've had both.
<atka>nope, its just the cheapest internet I can get remote
<atka>$20/mo unlimited but 512Kbps down and up
<atka>just have to plan ahead, downloads and updates overnight etc
<atka>no, 40 mile 3g connection
<atka>using a sxt-r
<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.
<conjunctive>(as in calling `guix environment --load=guix.scm; ruby -v` produces ruby 2.7.4p191)
<conjunctive>I did also notice `(define-public ruby ruby-2.7)` in ,m (gnu packages ruby). Wondering if this might be related.
<nckx>You're not literally using ; but simplifying for IRC purposes, yes? You are in the environment?
<nckx>It would be related if you used 'ruby', and it seems clear that the 'default (build system?) ruby' is leaking in, but that's not because 'ruby-3.1' is ambiguous somehow.
<nckx>Hope that made sense; AFK a bit.
<conjunctive>nckx: yes, simplifying for IRC purposes (should've noted that)
<atka>wasn't there a #guix-devel channel?
<ZhuAisi[m]>What's the status of
<ZhuAisi[m]>I try to send my patches but it was rejected
<nckx>ZhuAisi[m]: What do you mean it was rejected?
<nckx>atka: Nevar.
<nckx>This is #guix-devel. Having to switch channels each time a conversation became 'too developmental!' would be madness.
<nckx>ZhuAisi[m]: Please send me a copy of the rejection mail.
<atka>nckx: ok, podiki earlier had mentioned a discussion on guix-devel, must've meant mailing list...
<nckx>Cairn, shcv[m]: Sorry for the delay, but on a brand-spanking Guix System (rebooted straight from the latest installer) echo $PATH contains ~/.guix-profile/bin from the get-go.
<nckx>I logged in from a VT. I wonder if your bug (let's call it what it is) is due to a display manager. Which one do you use, and which wm/desktop?
<Cairn>Well what did I do
<nckx>Quite possibly nothing, but that's for the arresting officer to decide.
<Cairn>Let me get my lawyer
<atka>smart move
<Cairn>I don't know what a display manager is specifically. I'm using the default GDM login system to log into an Xorg with the Picom compositor and BSPWM.
<nckx>The DM in GDM :-) Thanks.
<ZhuAisi[m]>nckx: I use another mail account and now sent it
<ZhuAisi[m]>Maybe something wrong with my 163 mail account?
<Cairn>nckx: Ah, so it was right in front of me the whole time, haha
<Cairn>DM=display manager
<Cairn>Can a GDM be given an xsession file? Or is it not even running Xorg?
<nckx>ZhuAisi[m]: Honestly, 163 might have been blocked because it's *such* a source of spam. I'll check. Thanks for the info.
<ZhuAisi[m]>nckx: My 163 account is, I used it to send many patches before(listed in the header of some file), plz check whether it's blocked or not, thanks!
<nckx>I was just going to say: you are even explicitly whitelisted.
<nckx>There's also no accidental ban on
<ZhuAisi[m]>maybe some other parts go wrong
<ZhuAisi[m]>I'll check it
<nckx>You said rejected. What exactly happened? We send a mail when rejecting posts.
<ZhuAisi[m]>the mail system of 163 told me my mail was rejected
<ZhuAisi[m]>Maybe it's rejected by 163 internally
<nckx>Could you send me that message? me@ the domain you see when you /whois nckx
<nckx>Redact parts if you want, although that might make it hard to tell what happened.
<nckx>Well, I'm assuming they told you via mail. If it was just an error pop-up there's not much I can do.
<ZhuAisi[m]>您发送到 的邮件被系统退回,以下是退信相关信息:
<ZhuAisi[m]>Yes, it seems to be the internal error of 163
<Cairn>nckx: I didn't use the installer; I followed the steps manually. Maybe the installer takes a step to add that to path by default?
<Cairn>I know a shell config can add stuff to path, so does it automatically set that up? Or does it add it to path some other way?
<nckx>ZhuAisi[m]: I see. Oh well. Thanks for the language practice. :-)
<nckx>Cairn: It doesn't. But this is a Guix System, yes?
<Cairn>Yep, Guix System
<nckx>Guix manages (i.e., generates, and not just once at installation time) /etc/profile, which takes care of that 'shell config'.
<Cairn>Oh, so that's where all the fancy envar stuff happens. Didn't know
<nckx>Guix System does this at boot time, there's no step you could have missed. It seems like GDM doesn't source it, which isn't implausible, but makes me wonder why this problem isn't universal.
<nckx>But I don't use GDM...
<nckx>Back to the VM we go.
<nckx>You could check whether your /etc/profile does this but I'm certain it does, it's just not being (correctly) run.
<Cairn>GDM isn't sourcing /etc/profile?
<Cairn>Yeah, I just pulled it up and it looks like there's some logic that would lead to my profile being sourced
<Cairn>Being added to $PATH
<Cairn>Guix is so fancy =)
<nckx>Hacky, fancy, eye of beholding.
<nckx>There's an argument to be made that it's too inflexible but that's obviously not your problem right now.
<Cairn>The /etc/profile thing, or Guix as a whole?
<nckx>Guix is too in some places, not enough in others, but that's true of every distro I've tried (and there's a reason I stuck with Guix).
*nckx just realised I've been using Guix longer than any other distro ever. Congrats?
<the_tubular>Same, but that's like 2 months :P
<atka>nckx: do you use more than one distro? or guix everywhere?
<nckx>ZhuAisi[m]: Re: 'please CC': you might know this already, but you could set a Reply-To header that almost every MUA will honour.
<nckx>atka: Excepting machines I administer but don't own, I've been Guix-only for a good few years now.
<atka>very cool, i'm getting there, though I do have a soft spot for alpine, I did switch one of my alpine servers to guix though!
<nckx>If the peoples insist on their Ubuntus or Beasties, who'm I to disoblige.
<nckx>I do recommend Guix because it saves me time and them money in the long run.
<nckx>For you, the same might be true of Alpine. Nothing wrong with that.
<the_tubular>I mean I would still like to see more names and more devs for Guix
<the_tubular>It's unique compared to countless distro
<nckx>I can only manage one such unbiased comment a day and it cost me great effort.
<atka>yeah, it fills a niche, i'm always on low power hardware, and low bandwidth connections, alpine is very well suited to taht
<the_tubular>"Niche" if you forget about docker ^^
<nckx>Yeah, Guix does not (yet) shine on low-resource machines.
<vagrantc>wait, i thought people got involved with distros to just spend endless amounts of free time packaging and fixing the distro? have i been doing this wrong the whole time?
<atka>also on solar, compiling all the time is too resource intensive
<atka>the_tubular: what about docker? I'm talking about how alpine is suited well to the niche of low power, low bandwidth machines
*vagrantc pretty much just uses computers to work on software distributions hoping other people will do something useful
<jackhill>but with Guix, my time wasting is more fun!
<nckx>atka: (solar) Oh cool. That use case has always tickled me but I haven't actually done anything about it.
<Cairn>The slogan
<the_tubular>I though you said Alpine was niche.
<nckx>They said it filled one, not quite the same.
<the_tubular>A lot of containers use Alpine
<nckx>I can have a niche that $popular_product fills for me, it's still a niche for me.
<vagrantc>i'm pretty much the same way about solar ... endlessly rebuilding my system to power my computers to work on free software distributions
<atka>vagrantc: do you know if the honeycomb has decent idle usage and power management?
<atka>or is it 30W all the time
<vagrantc>atka: with the power supply i had, it was pretty consistantly 20w ... but i hadn't really tried compiles or anything
<atka>that's unfortunate
<vagrantc>atka: that was a DC power supply
<nckx>jackhill: Oh, well put, Imma steal that.
<vagrantc>atka: two SSDs, a big quiet fan (200mm ?) and the little noisy fan it comes with
<vagrantc>plenty of sun to power it later, but not enough time
<atka>not terrible
<atka>I'm in alaska
<nckx>No need for fans.
<atka>so I need to save energy part of the year
<atka>still have 18 hours of daylight now
<atka>so no biggie
<jackhill>nckx: 😁
<vagrantc>atka: at about 46 degrees north, so still long days, but not that long :)
<atka>vagrantc: yeah, I get down to 4 hours in dec/jan though :( and I'm only on solar
<vagrantc>ok, i've talked about my two obsessions, where'd acrow go so i can briefly and politely ramble about the third?
<Cairn>What's the third
<atka>vagrantc: it would be fun to chat about our systems sometime, mines very minimal
<the_tubular>vagrantc unrelated, but isn't debcon soon ?
<the_tubular>debconf *
<Cairn>the_tubular: Thought it already happened?
<nckx>vagrantc: I missed the beginnings of this, so I'll ask now: so you're writing a tool to create hectokilobytes of uncompressed copyright info for Debian users?
<the_tubular>Ohh, then I missed it and need to watched some talk Cairn :P
<nckx>Is this to scare them into switching to Guix or a hard Debian requirement?
<vagrantc>atka: atka:
<the_tubular>No, I really like his guix talk at debconf and wanted another one ^^
<vagrantc>nckx: debian's interpretation of the GPL requirements, basically
<nckx>I see.
<vagrantc>the_tubular: just wrapped up ... a week or two ago
<the_tubular>Ohh, any talks that are must watch ?
<vagrantc>Cairn: aikido :)
<Cairn>vagrantc: Oh sweet
<atka>vagrantc: thanks for the link, I'll download it tonight. do you by any chance us victron/venusOS and grafana? I'm setting it up on a pi running alpine+podman right now.
<Cairn>atka Have you ever tried out git-annex? The author has very low bandwidth, so it might be relevant to your use
<atka>never heard of it, looking into it rn
<Cairn>I use(d) it for my music collection and a few other things. Hoping to use it even more someday soon.
<vagrantc>atka: trying to get away from the closed but pretends to be open victron stuff and back to the open but hard to find electrodacus platforms :)
<vagrantc>i better make some more contributions to guix before going wildly off-topic again :)
<atka>ok have a good one
<atka>Cairn: git-annex looks pretty good, thanks for the recommendation.
<pkill9>im randomly gettign problems with locales
<pkill9>e.g. waybar is refusing to load the clock because "locale name not valid", bashtop not running becaue "no UTF-8 locale found"
<pkill9>setting LC_ALL to "C" somewhat fixes it
***duds-_ is now known as duds-
<rekado>pkill9: is GUIX_LOCPATH set? Do you have glibc-locales (or a subset thereof) installed?
<pkill9>yes and yes, looking at the locale directories they are versioned, so might also need to update the programs
<rekado>our glibc looks at the versioned directory.
<unmatched-paren>how can i get rid of the dir-locals popup? `!` doesn't work because it tries to modify .emacs, which is managed by guix home and so is read-only
<pkill9>i'm getting this error when running guix package -u: guix package: error: fluidsynth: package not found for version 1
<pkill9>i don't have fluidsynth installed, idk how to fix thsi
<unmatched-paren>pkill9: That's pretty strange; are you on the latest commit?
<unmatched-paren>Could you do `guix describe`?
<unmatched-paren>`guix install guile@2 && guix upgrade` works for me.
<pkill9>im on commit ae0c11f9209b1e09997c224b3df645f7ed4d6804
<pkill9>Aug 03 2022 11:35:48
<pkill9>unmatched-paren: so what does that error message mean?
<unmatched-paren>Okay, not that long ago. I guess you could try to guix pull.
<pkill9>doesn't really help much
<unmatched-paren>pkill9: I have no idea.
<pkill9>doesn't say what package needs fluidsynth
<unmatched-paren>It seems to want, somehow, to install fluidsynth@1, but there's only fluidsynth@2.
<pkill9>well if i knew the package that wnats fluidsynth i could just remove it
<unmatched-paren>I don't think a package could possibly cause that
<unmatched-paren>because package inputs are <package> objects, not specifications
<unmatched-paren>Somewhere, someone is trying to use `fluidsynth@1`, but that wouldn't be possible in a package that doesn't use specification->package (= all of the packages in Guix)
<pkill9>right, well i need to find the package that demands fluidsynth since that error doesn't do the obvious thing and just tell me
<unmatched-paren>If it did try to use as input `fluidsynth-1`, you'd be getting unbound variable, not no such package
<unmatched-paren>Could you put the whole output of `guix upgrade` on
<pkill9>it may have been a custom package
<unmatched-paren>could you show your channels.scm?
<unmatched-paren>Or just say which channels you're using
<pkill9>package transformatiosn get saved so migth still be tryying
<pkill9>this is the complete output of guix upgrade: guix package: error: fluidsynth: package not found for version 1
<unmatched-paren>Oh. Hmm.
<pkill9>how do i list all transofrmed packages?
<unmatched-paren>Not sure what you mean by listing transformed packages
<pkill9>when you do for example guix package --with-source=..
<pkill9>that kinda transformation gets saved, so on every upgrade it will continue buildign witht hat source
<unmatched-paren>Maybe `guix package --list-installed` shows transformations?
<pkill9>i'm just building a new profile using the list of packages from current profile
<pkill9>and if that works then just install everything that way
<pkill9>also guix needs wayfire
<unmatched-paren>i think guixrus has wayfire
<unmatched-paren>pretty sure it was florhizome[m] who worked on it
<unmatched-paren>it's a channel
<unmatched-paren>it's mostly used as a sort of staging/unstable branch in my experience
<unmatched-paren>for packages that aren't ready for upstreaming
<unmatched-paren>this commit above wayfire:
<unmatched-paren>;;;TODO make tests work (add doctest + cmake to build them)
<unmatched-paren>probably indicates it isn't ready for upstreaming yet :)
<pkill9>doesn't buidl for me sadly
<pkill9>wlroots-for-wayfire fails
<unmatched-paren>Hmm. I'll open a ticket.
<pkill9>actually 9may have run out of disk space
<pkill9>but idk
<pkill9>actually not sure
<pkill9>no i haven't
<pkill9>only on my storage partition
<pkill9>not the system one
<pkill9>why is it so difficult to find the issues page on sourcehut
<unmatched-paren>pkill9: has a tickets tab at the top
<unmatched-paren>tickets are not linked to repos, and neither are mailing lists
<unmatched-paren>you need to create a 'project' to unify them
<unmatched-paren>which is found on the top-level domain
<unmatched-paren>and links to the source, mailing list, tickets, etc that have been configured in the project settings
<pkill9>teh problem is there is no link to the project from the repo
<unmatched-paren>that's fair enough
<pkill9>or any indication that it is part of a project
<unmatched-paren>usually you can try s/git\\.// and it will probably work though
<unmatched-paren>maybe we should link to the project page on the readme
<pkill9>better than nothing but it would make more sense for sourcehut to do it automatically
<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': Where's my mistake? Thanks!
<unmatched-paren>can i do `make` in the guix repo _without_ building the docs?
<unmatched-paren>the docs take a while
***Dynom_ is now known as Guest563
<unmatched-paren> <> I've made this patch that forces `guix package`, `guix pull`, and related commands to fail if Guix is run as root, eliminating a common source of beginner frustration (in my experience) :)
***Lumine_ is now known as Lumine
<pkill9>unmatched-paren: i found the transformed package, it was freedoom and gzdoom
<pkill9>i accidentally found it by running `guix package --export-manifest` and it creates scheme code to do the transformation
<unmatched-paren>ah, cool
<nckx>unmatched-paren: Thanks! I replied, although you might not like m'pinion.
<nckx>It's still correct of course.
<unmatched-paren>I didn't realize the `guix pull` issue was fixed earlier :)
<unmatched-paren>I guess it isn't really needed in that case, so I'll close it if you think it won't be helpful
<nckx>Right. That implied to me that a bit more investigation/thinking might be needed.
<nckx>Hm, I don't know. I believe you if you say there's a real potential danger.
<unmatched-paren>It was a while ago that I broke my system with `sudo guix pull`
<nckx>Does running ‘sudo guix install foo’ bork ownership?
<nckx>Same for other ‘package’ ops.
<nckx>unmatched-paren: Sadly it happened to too many people, but you might well have been [the] one that finally made me grunt ‘enough!’ and fix it.
<nckx>I don't remember who was the poor sod.
<singpolyma>unmatched-paren: how will I install packages for my root user, then? ...
<unmatched-paren>singpolyma: The patch added --allow-root
<singpolyma>Oh. Ok. That's fine :)
<singpolyma>Was gonna say, I run install as root almost every week ..
<unmatched-paren>Though since nckx pointed out that it wouldn't be much use anymore, I'm probably going to close the issue :)
<nckx>…for ‘guix pull’.
<nckx>I do not know if you observed problems with the other subcommands your patch gates.
<unmatched-paren>sudo guix install kakoune && sudo stat -c %A /root/.guix-profile/bin/kak
<unmatched-paren>that looks alright
<nckx>Permissions should be fine, but is ownership?
<nckx>I could test this myself but you're willing 😛
<nckx>Oh no, I broke my own emojo support. How'd I do that.
<unmatched-paren>Nope, owned by root.
<unmatched-paren>My reasoning was, as i said in the commit message, beginners thinking 'hmm, i need root to run apt, so i'll use sudo with guix'
<unmatched-paren>(not knowing that it provides per-user package management)
<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`.
<unmatched-paren>Unlike the non-pitfall of `sudo guix package`, I have no idea how to go about doing that :)
<unmatched-paren>Are there any situations where someone might do `guix install guix` and not be wrong?
<nckx>No. I've been musing about the equally ‘proper’ way to do that, so very much not (when (string=? name "guix") (error "I is robust soft wares")) TYVM.
<unmatched-paren>We can't make it a hidden package because `guix shell -D guix`
<unmatched-paren>nckx: Right.
<nckx>But since we specifically want to forbid only ‘install/package -i’, I'm not sure what that would look like.
<nckx><guix shell> Exactly.
<unmatched-paren>Should I just close #57016 now?
<nckx>I just don't have the simmering/walk-in-the-woods downtime I tend to need to see obvious solutions right now, so if you'd come up with one, I'd be much obliged.
<unmatched-paren>(dont-install-this-package (package (name "guix") ...)) :P
<nckx>unmatched-paren: If you're not aware of remaining ways to trivial break something with sudo, I guess so. You can always reopen/revisit it later.
<nckx>I do appreciate the effort.
<nckx>> beginners thinking 'hmm, i need root to run apt, so i'll use sudo with guix'
<nckx>Certainly true. ‘--allow-root’ was way too extreme, as is printing a hint on each root invocation, but I think we have code in place to print hints exactly once per user?
<unmatched-paren>We do?
*unmatched-paren looks
<nckx>[Long pause between lines == keyboard cat party.]
<nckx>I'll look later if you don't find anything. I don't think I dreamt it…
<nckx>Like, what does ‘guix shell --check’ use. Anyway, TTYL.
<unmatched-paren>Oh, record-hint.
<unmatched-paren>The only usage of record-hint is in shell.scm, so no, there's no warning for `sudo guix package` on the first invocation.
<unmatched-paren>I guess I'm adding one then :)
<nckx>Sorry, I didn't mean to imply there was one, just that we have the software infrastructure frameworks in place to make it relatively pleasant to add one.
<unmatched-paren>Right, yes, I misread.
<nckx>It was ambiguous.
<nckx>Since FSDG issues should move rather swiftly IMO, feel free to comment on <> to build consensus.
<nckx>(Ideally with facts tho' :)
<orneb>Hi! Have you ever got this error with gpg "gpg: problem with the agent: no pinentry"?
<nckx>Despite my reply I'm always saddened to see historic art become less accessible due to (legitimate) freedom concerns.
<unmatched-paren>orneb: You need to install `pinentry`
<unmatched-paren>or `pinentry-gnome`, or `pinentry-qt`
<orneb>I installed it and I still get that error.
<nckx>And also, crucially, put something like ‘pinentry-program /home/nckx/.guix-profile/bin/pinentry-gtk-2’ in ~/.gnupg/gpg-agent.conf.
<orneb>I installed the pinentry package
<nckx>I don't think a relative name works but haven't tried recently.
<nckx>(Then kill or graciously restart the agent.)
<unmatched-paren>I was going to say 'you might need to specify the path in gpg-agent.conf' but nckx beat me to it :)
<nckx>For once! Yay.
<orneb>nckx: Ok thanks! I'll try that later.
<nckx>I guess the GPG upstream argument is ‘security’, I don't know.
<unmatched-paren>That thread looks pretty conclusive :) Are other opinions really needed, other than an okay from ludo, maxim, or someone else?
<unmatched-paren>s/okay/'yes, remove them'/
<nckx>Even those are not strictly needed. You're right, I was mainly hoping someone would point out alternate facts, or a missed source package somewhere, but as it is it looks sadly conclusive.
<nckx>I didn't mean discuss it for days, it's just a very young bug and there's still time.
<nckx>At least in their current form the packages have no future in Guix.
<unmatched-paren>even if they did have sources that we missed, the license would still be a serious problem, no?
<unmatched-paren>I guess somebody could add them to that other channel.
<nckx>Lazy counterpoint: but it's in Debian, mum.
*nckx investigates why.
<nckx>There is no ‘why’ beyond ‘they are OK with that same licence’.
<nckx>Which surprises me, Debian being if anything slightly more strict on average in pure licence matters, but there it is.
<unmatched-paren>"several" issues? surely they'd have spotten clause #3
<nckx>Wish there were a sanity clause for licence restrictions that are trivial to legally work around (‘€5 for this Drascula-and-my-hello_world.c-that-won't-compile-software-bundle please’).
<nckx>unmatched-paren: IKR?
<nckx>Mystical ‘initial feedback’ —
<nckx>This is starting to sound like one of them humans vs. lawyers deals.
<unmatched-paren>Maybe their reasoning is "this is data, not code".
<nckx>Is this real life:
<nckx>unmatched-paren: It occurred to me, but I'd personally disagree with that (hypothetical) assessment.
<unmatched-paren>So would I.
<unmatched-paren>Does Guix forbid nonfree data, or just software?
<unmatched-paren>s/art/and nontrivial data
<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>Now, what that is is up for interpretation.
<nckx>But I'm tough to convince that this is that.
<unmatched-paren>The most literal interpretation of the phrase 'non-functional data' would suggest that such data would be completely useless.
<nckx>E.g. sprites and fonts are considered non-functional.
*nckx agrees.
<nckx>I guess I'll draft up a very confused mail to the FSF.
<nckx>Now, I'm no ScummVM expert (I've played Monkey Island and that's it). Maybe its games are considered very declarative?
<nckx>That could work.
<unmatched-paren>You could reasonably argue that, say, a PNG is just compiled bytecode for an image viewer :)
<nckx>Sure, and that's where some vague notion of procedural/declarative might come in.
<nckx>Emphasis on vague.
<unmatched-paren>A nonfree Haskell program intended to be interpreted by Hugs would be declarative data. Technically.
<unmatched-paren>If usage of `IO` is procedural, then okay, maybe it's a nonfree Haskell file full of pure utility functions for loading into Hugs :)
<nckx>The monad loophole? Oh dear.
<unmatched-paren>Suddenly, the nonfree software industry develops a remarkable interest in functional programming papers.
<nckx>NX considered harmful.
<Cairn>Morning Guix
<unmatched-paren>hello Cairn
<Cairn>My terminal seems to have a mind of its own with cursors. I set up the Adwaita theme for my cursor, but when I hover over rxvt-unicode, it switches to whatever the previous theme seemed to be
<Cairn>I can even run `XCURSOR_THEME=Adwaita urxvt` and it doesn't solve the issue
<unmatched-paren>i vaguely remember this. you're on a foreign distro?
<Cairn>No, Guix System
<unmatched-paren>Hmm, okay.
<unmatched-paren>I can't find anything other than
<unmatched-paren>maybe the workarounds in that thread for the cursor size issue will also work for you
<unmatched-paren>xsetroot looks promising
<Cairn>Ah, I didn't realize what the xsetroot option did when I found it yesterday. Cool that I don't have to see the cross cursor on my desktop anymore!
<Cairn>However, it didn't solve the issue in urxvt
<unmatched-paren>I use Wayland so I'm afraid I can't help you :/
<Cairn>No worries. I'm gonna keep reading that thread
<Cairn>Seems like the suggestions in that thread work like they should, but not in my terminal. So I guess my terminal really is overwriting the cursor theme somehow.
<Cairn>Doesn't happen in xterm or kitty.
*nckx sends
<pkill9>does anyone here have fish set as their user's shell?
<nckx>kabouik, unmatched-paren, possibly.
<unmatched-paren>I do, yes.
<pkill9>do you encounter any issues?
<unmatched-paren>as long as i use guix home to manage it
<pkill9>unmatched-paren: not even issues with /etc/profile?
<unmatched-paren>pkill9: I don't set the login shell
<unmatched-paren>I just set it as the shell in foot.ini
<unmatched-paren>pkill9: you probably shouldn't chsh on guix system
<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’.)
<nckx>I sound like sneek there.
<unmatched-paren>Oh, nice.
<singpolyma>nckx: s/bournish/strictly posix compliant
<nckx>I would've said that if I meant that.
<nckx>Calling bash ‘strictly POSIX compliant’ is a stretch, even in POSIX mode, but it tries, and we shouldn't hurt its feelings.
<singpolyma>Using bash for such a case is a bug
<singpolyma>Bash is a fine interactive shell to spawn later
<nckx>It's hot take Saturday.
*nckx sorely missing emojo support; hopes a reboot will magically fix it.
<unmatched-paren>nckx: Ooh, I have an idea for fixing `guix install guix`:
<unmatched-paren>(package (post-install-hint "..."))
<unmatched-paren>Would that work?
<unmatched-paren>We could also add that to `gwl` to tell users to set GUIX_EXTENSIONS_PATH
<unmatched-paren>and for any other package that requires manual intervention
<unmatched-paren>Or maybe just
<unmatched-paren>(package (post-install-hook (begin ...)))
<unmatched-paren>Though that would break purity...
<pkill9>currently i have bash runniong fish, but I'll set it up so the terminal emulater runs it instead
<unmatched-paren>That's probably the least risky setup, yeah :)
<pkill9>it is done
<Cairn>If anyone sets a cursor theme, could you try installing urxvt and hovering your mouse cursor over it?
<Cairn>The trouble I'm having is that its overwriting my cursor theme (which is just Adwaita)
<cehteh>x11 or wayland?
<yuu[m]>Cairn: did you set Xresources?
<yuu[m]>Xcursor.theme: cursor_theme_name
<pkill9>my ~/.profile isn't being executed on login
<Cairn>Yep, that's how I set the theme
<yuu[m]>Cairn: no idea then. works for me on alacritty
<Cairn>Could you try installing urxvt? Trying to see if it's reproducible and I talk to the dev
<pkill9>oh does it only get executed by login managers and not the console login?
<Cairn>* so I can talk to the dev
<pkill9>ok fixed that, it's because .ash_profile existed so it *doesn't* execute .profile
<yuu[m]>pkill9: yeah it doesn't pick up Xresources. i remember back when i used to use urxvt it worked though
<Cairn>Wait, so the same issue's happening for you then?
<Cairn>It's definitely picking up .Xresources, since I configure a bunch of settings for urxvt in it. The cursor's just using the theme
<Cairn>nckx: /home/cairn/.guix-profile/bin is in my $PATH today. I did multiple reboots without that happening, but now it is
<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
<Cairn>That's gotta be it
<Cairn>yuu: Interesting. Yeah, it used to work in arch for me too. Although mine is definitely picking up on all the other .Xresources
<Cairn>yuu: Maybe you're right about gtk. I'll look into it
<yuu[m]>Cairn: did you set userresources = ~/.Xresources and and xrdb userresources?
<yuu[m]>on your xinit/shell init
<yuu[m]>well you probably just need `xrdb ~/.Xresources`
<pkill9>oh waybar is running, so it's just not appeared
<nckx>I'm not in a position to disagree (not at PC) but I'm sure /etc/profile explictly addresses that.
<nckx>Empty or not should not matter for adding /bin to $PATH. Not sure about sbin.
<nckx>Cairn: ^
<Cairn>Huh, interesting
<Cairn>Well then I'm not sure nckx. Maybe there's some bug with it. I'll try to more empirically in a little bit
<Cairn>yuu: Yeah, I run that line in .xsession.
<Cairn>I also use my ~/.Xresources to set the xft dpi. All the settings in .xresources are working (including the cursor one)
<Cairn>The only time the cursor isn't working is when I hover over urxvt
<Cairn>I wonder if there's a missing dependency somehow.
<nckx>Uhm what: 'WARNING: compilation of /gnu/store/...scm failed: No such language scheme'
<nckx>This is in the *initrd*.
<nckx>My machine is trying to build Guix in the *initrd*.
<abcdw>Hi guix!
<nckx>Or Guile, I'm not sure (I thought it was a grand idea to set a boot logo with only 5 lines of console under it.)
<nckx>Hiya abcdw.
<abcdw>I'm pushing my first commit, want to be sure everything is fine
<nckx>Congrats. Which commit?
<nckx>Nuts. After interpreting half of Guile *in the initrd*, my system boots as if it didn't just go utterly insane.
<abcdw>guix pull: error: commit 39465409f0481f27d252ce25d2b02d3f5cbc6723 not signed by an authorized key: 2841 9AC6 5038 7440 C7E9 2FFA 2208 D209 58C1 DEB0
<nckx>Oh, you pushed it already.
<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 <>" [ultimate]
<nckx>That is Git, not how Guix verifies commits.
*nckx 's kernel panics.
<nckx>Hi two[m].
<two[m]>it looks like matrix messages aren't delivered to #guile
<Cairn>Lemme try
<two[m]>but they do here
<Cairn>Welp, I sent a message there, but the channel logging service isn't up to date yet, haha
<yuu[m]>nckx: how does it? with gpg directly
<nckx>Shit, my laptop won't boot any generation now.
<nckx>So is 'guix pull' broken for everyone now? Please say no.
*unmatched-paren tries it
<yuu[m]>nckx: is it just an issue with the bootloader? otherwise backups to rescue
<abcdw>nckx`: it seems so :(
<nckx>Absolutely perfect timing.
<abcdw>Sorry for that :/
<unmatched-paren>It's okay :)
<unmatched-paren>Shouldn't be hard to fix, right?
<unmatched-paren>Right? Oo
<nckx>yuu[m]: I don't know what it is yet, but it's not the boot loader.
<abcdw>unmatched-paren: AFAIK, force push is forbidden, so there is no easy way to "remove" latest commit
<nckx>I've found a laptop that I can use to ssh into a Guix system. This will be slow.
<unmatched-paren>abcdw: We can probably make an exception here...?
<unmatched-paren>Since there is literally no other way to fix this other than to rewrite history afaik.
<itd_>abcdw: & [0] there
<nckx>The key marked as authorised is D963, not 2841. Subkey?
<nckx>Yes, we've done so once.
<nckx>I think.
<nckx>Oh yep that's what that link is.
<abcdw>nckx`: yep, I have a subkey for signatures
<nckx>That's plan Z because it's horrible for everyone and involves groveling before the Savannah admins.
<nckx>abcdw: OK, so do I, so that is not fundamentally unsupported...
*nckx installs gnupg, that might help.
<nckx>OK, we need to authorise the subkey.
<abcdw>nckx`: but authorization should happen before the commit, isn't it?
<pkill9>gradually decomplexifying feelsgoodman
<nckx>There is a server-side hook that ensures that the commit is signed, and Savannah ACLs take care of who can push.
<nckx>You'll note a lack of connexion between the two.
<nckx>If I sign as Bozo the Clown and push with nckx's SSH key, the hook is fine with that.
<nckx>Is bad.
<abcdw>Yep, efraim mentioned that recently.
<yuu[m]>we just need to get back in time in that case, but if the universe is deterministic, then that would just happen again 🤔
<nckx>Now I need to build pinentry from source because after all why not at this point.
<blake2b>are there *any* good reasons to want syntactically significant whitespace in a configuration language?
<nckx>No, in any language.
<nckx>Make was a mistake.
<blake2b>guile make will eventually prevail
<unmatched-paren>Sadly, most of the alternatives to Make are even bigger mistakes :)
<nckx>(Genuinely. 'Compatibility' precluded a fix. Sound familiar?)
<nckx>Which is tragically funny because that probably meant 10 people would have been mildly inconvenienced at the time.
<blake2b>i guess with projects like dhall the argument can be that its kind of geared towards haskell users, and the dependent types allow for decent error messages
<pkill9>does anyone know of a tool that lets you go down a text file and line by line you choose which other text file to move that line to?
<blake2b>but i heard in practice dhalls error messages are pretty bad
<pkill9>I'm spliting up my mess of a guix profile into sub profiles
<pkill9>all those little utilities with esoteric names
<nckx>abcdw: You owe me inordinate amounts of Free beer.
<nckx>Doesn't matter that it wasn't your fault, the law is clear.
<PotentialUser-47>Hi there!
<PotentialUser-47>I have just run `guix pull` to get a not signed commit error D:
<abcdw>nckx`: Will orange juice do the trick? ^_^
<nckx>If you are here to report a gui--hah.
<nckx>Just run it again, guix sometimes does that, it's fine.
<nckx>abcdw: At least make it chocolate (soyboy) milk.
<PotentialUser-47>`guix pull: error: commit 39465409f0481f27d252ce25d2b02d3f5cbc6723 not signed by an authorized key: 2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0`
<nckx>That message was for you.
<nckx>We had an oopsie.
<the_tubular>I get the same message
<nckx>You might need to remove ~/.cache/guix.
<nckx>He said, desperately.
<unmatched-paren>Whoa, `rm -rf .cache/guix` made noises come out of my disk.
<nckx>'guix describe' confirms I'm on current master, stay calm nckx.
<unmatched-paren>Must have been a pretty large directory.
<nckx>Yes that is where all the noises are stored.
<pkill9>nice i did it ina single line, for i in (cat pkglist) ; ls | fzf
<pkill9>--cycle --prompt "$i: " ; end
<unmatched-paren>"You monster! Don't you hear the files screaming in agony?!"
<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?
<unmatched-paren>lagash: I think that's the introduction key
<unmatched-paren>not the offending key
<unmatched-paren>lagash: Do `rm -rf .cache/guix && guix pull`, it works for me
<lagash>unmatched-paren: right, mixed those up..
<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.
<the_tubular>nckx you were interested in bcachefs right ?
<nckx>I've been running Guix System on bcachefs for a few years now yes.
<the_tubular>A good talk just came out :
<nckx>Sweet, thanks.
<unmatched-paren>Oh, nope. It doesn't work for me :(
<the_tubular>Well it's more like an open discussion, but it's a good way to get a status of the project
<the_tubular>Why ?
<nckx>I'm reading conflicting reports or misread. So removing ~/.cache DOES fix guix pull? Can someone corroborate?
<abcdw>nckx`: rm -rf ~/.cache/guix && guix time-machine -- build emacs-geiser-guile fails too :/
<unmatched-paren>nckx: I thought it did, because it was running for a while
<unmatched-paren>but then it failed :/
<lagash>unmatched-paren: actually I think the offending key is a subkey of his..
<nckx>the_tubular: My version of fun, nothing more, although I do think it will be a great fs if all continues to go well.
<the_tubular>Your version of fun ?
<lagash>At any rate, I decided to do mv .cache/guix{,.old} instead of rm -rf
<nckx>lagash: Needlessly cautious but fine too.
<the_tubular>Ohh, my bad. I though you said the talk wasn't working, I'm tired :(
<nckx>And I thought you were asking me why I used bcachefs.
<nckx>Yes, I thoroughly enjoy that particular kind of kernel-based masochism.
<nckx>Oh look there goes my root fs.
<abcdw>nckx`: guix pull fails as well.
<nckx>That hasn't happened in years though.
<nckx>abcdw: Post .cache erasement?
<nckx>.cache/guix really.
<nckx>Not that it $should matter.
<lagash>nckx: pardon, but wouldn't that commit need to be authorized.. and it would, since it's Tobias.. but doesn't the previous commits have to be authorized first??
<nckx>OK, I missed unmatched-paren's correction.
<nckx>So it doesn't work for anyone. OK.
<abcdw>nckx`: yep, rm -rf ~/.cache/guix && guix pull --allow-downgrades
<lagash>abcdw: isn't that a little dangerous? :P
<nckx>lagash: I am Tobias, and I was just pointing to the diff, not the metadata.
<nckx>That was a partial fix in the hope that a force-push would not be needed.
<lagash>nckx: sorry, it's been awhile since I was active here!
<abcdw>lagash: I'm Andrew and I was the one who pushed the commit, which broke master :) So I don't think guix pull --allow-downgrades will do something worse for me =)
<nckx_>That's OK.  I literally wrote and am struggling to remember everything I knew then.
<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[2]. Any committer can DoS guix pull in a way that even the maintainers can't fix unaided.'
<nckx_>Good point, Tobias.
<nckx_>Maybe you should do something about that.
<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_>No, it's too late (chronologically).
<unmatched-paren>then if someone accidentally pushes a broken commit to master-staging, the ci will catch it
<unmatched-paren>and we can rewrite history on master-staging without doing the same to master
<Cairn>abcdw: It'll only be uphill from here =)
<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.
<unmatched-paren>I guess I can just `guix pull --disable-authentication` for now.
<nckx_>Caveat yourself, but you can.
<abcdw>Cairn: I really hope so, I feel so bad for making Tobias work at the middle of the weekend
<yewscion>Yup, failed with 394654. Is C1DBE0 a valid key?
<pkill9>i suppose I should just use either a manifest or guix home to organise the applications I install
<nckx_>It's OK abcdw (but thanks <3).  It's the ridiculous coincidence of my laptop breaking literal minutes before you walked in that really made it :)
<nckx_>s/my laptop breaking/me breaking my laptop/ let's be honest.
<nckx_>This poses a problem if I want to prove my identity to Savannah sysadmins, but I'm not there yet.
<nckx_>yewscion: Assuming you mean C1DEB0, yes, it is.  All these keys are valid:
<yewscion>nckx_: copy that, thanks! (Sorry for the basic-ish questions.)
<nckx_>Was a good question.
<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.)
<lagash>yewscion: that's what I just did, yeah
<kimjetwav>yewscion: Wait is this an ongoing thing? Just dropped in.
<kimjetwav>Ahh, I see, new key. Gotcha.
<abcdw>kimjetwav: kind of :)
<kimjetwav>"Let us all pray" oh boy.
<nckx_>Faith-based software development FTW.
<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.
<Cairn>Oh is that true? By bad then
<nckx_>Did so anyway.  All ports in a storm.
<abcdw>nckx`: BTW, do we need to rename a file in a keyring branch to match the subkey suffix?
<nckx_>For those not subscribed:
<nckx_>abcdw: I tried that locally and it didn't work.
<nckx_>I'm hesitant to add further upstream noise.
<nckx_>(That was one of the 'things I was trying' above.)
<nckx_>Although, if I don't get a response soon, adding upstream noise is exactly what I'll do, since there's nobody listening now anyway.
<nckx_>abcdw: To clarify, this machine's old storage is so slow 'guix pull' is *still cloning* after 30 minutes.  Did you mean that you've tested that and it worked?
<nckx_>It's at 86% now.
<abcdw>nckx_: Not, yet, I removed cache and pulling from local checkout rn, will let you know when it finishes
<nckx_>F it, I'm going to push it and eat.  I'm pretty sure it's the right thing to do.
<nckx_>Hangry debugging is not good debugging.
<abcdw>nckx_: 85% already
<nckx_>97%.  You are going to beat me.
<nckx_>Oh, nope, those last 3% were a lie.
<abcdw>93 :)
*nckx_ AFK.
<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.
<unmatched-paren>0x151: openssl provides, curl provides, unbound provides, and czmq provides
<Ox151>unmatched-paren: thank you for the confirmation
<abcdw>nckx_: renaming file in keyring branch didn't help (kinda expected). "Unauthorized" commit still comes before authorization commit (we can't backwardly authorize keys).
<nckx_>Yes, that's the crux of the problem.
<abcdw>nckx_: Sorry for bringing troubles at the middle of the weekend :) I'm not much help rn, so I'll go to sleep and come back tomorrow. See you in a bit!
<nckx_>Renaming isn't strictly necessary, I think.  My key is named after my subkey, but bavier's isn't.
<nckx_>See you!
<yuu[m]>at least you guys have some commit authentication in place. Nix[pkgs] hasn't much of a policy on that front afaik
<Cairn>So I want to make a package variant of
<Cairn>All I want to do is mess with the build flags. I just don't quite get it...
<yuu[m]>Cairn:... (full message at
<yuu[m]>that was for emacs, but ig it also applies to what you want
<Cairn>I guess what I mean, is that I don't know how to make the changes
<Cairn>I guess I'd modify this list:
<Cairn>I haven't read the Guile manual yet, so I'm floating in the ocean
<yuu[m]>(package (inherit rxvt-unicode (arguments everything and the changes you want))?
<yuu[m]>there's a section on the guix manual on this package inherit
<civodul>Cairn: yup:
<yuu[m]>i haven't looked into package transformation yet
<Cairn>I saw that page, but I just couldn't get a lot of it yet
<Cairn>Do I have to add the entire arguments section of the original definition and then make my changes?
<Cairn>Or should I somehow directly modify the (#:configure-flags) statement?
<nckx_>Thanks to bandali, upstream git master has been rolled back by two commits, and I'm currently testing a fresh (rm -rf ~/.cache/guix) guix pull...
<Cairn>👏 Thank you bandali
<nckx_>The keyring branch has also been reset to before my futile tests, for those following guix-commits@.
<nckx_>So *in theory* we are good to go.
<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.
<nckx_>I say this as an expert in that field.
<bandali>cheers nckx_ Cairn :) here's hoping it's helped resolve this instance
<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.
<unmatched-paren>(substitute-keyword-arguments ARGUMENTS ((#:KEY OLD-VAL-BINDING) NEW-VAL) ...)
<Cairn>unmatched-paren: What does that first "ARGUMENTS" represent there? Everything else makes sense.. I think..?
<unmatched-paren>Cairn: It represents the old arguments list that you want to manipulate
<vagrantc>i guess one way around the guix pull thing is to start pulling from a different branch ...
<unmatched-paren>it's usually (package-arguments SOME-OTHER-PACKAGE)
<vagrantc>e.g. guix pull --branch=theproperlysignedmasterbranch
<civodul>nckx_: i didn't follow guix-commits recently, but yes, we can discuss what to do with subkeys, i don't have a strong opinion
<vagrantc>what kind of subkey? i've only ever used a subkey for signing
<civodul>yes, that kind i guess
<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)
<unmatched-paren>basically whatever you have in the (arguments ...) field
<vagrantc>yeah, OpenPGP normally should allow any valid signing subkey or the master key
<unmatched-paren>(package-arguments PKG) gets the arguments list of PKG
<vagrantc>you shouldn't have to specify the sub-keys explicitly
<unmatched-paren>so a common pattern is
<nckx_>Maybe it's my understanding that needs loving correction, and the way we do things has a security advantage.  It's definitely more strict.
<nckx_>vagrantc: That's what I thought.
<unmatched-paren>(package (inherit OLD-PKG) ... (arguments (substitute-keyword-arguments (package-arguments OLD-PKG) ...)))
<unmatched-paren>And don't worry, you're not wasting my time at all :)
<vagrantc>nckx_: i think you think correctly :)
<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>e.g. it should be safe-ish to put a signing subkey on a pretty well trusted device (as opposed to a totally trusted device)
<nckx_>I didn't do extensive testing but I think that's how other software behaves.
<unmatched-paren>It's a bit like how you do (modify-phases %standard-phases ...)
<unmatched-paren>%standard-phases is a phase list
<unmatched-paren>which contains the default phases for the build system in use
<nckx_>vagrantc: That's my use case exactly, and one I think makes sense.
<vagrantc>i think the security disadvantages of the current approach in guix is that it breaks conventions typically used by OpenPGP and gets guix stuck in an awkward situation more easily
<vagrantc>it does allow, say, having multiple subkeys, and to only trust some of them, though
<vagrantc>not sure it is worth that, though
<Cairn>So does this look right unmatched-paren? `(package (inherit rxvt-unicode) (arguments substitue-keyword-arguments (package-arguments rxvt-unicode) ((#:configure-flags (list "--enable-256-color")) (list "--enable-everything"))))`
<Cairn>For trying to modify this line:
<unmatched-paren>Cairn: Not quite
<unmatched-paren>(arguments substitute-keyword-arguments ...) -> (arguments (substitute-keyword-arguments ...))
<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
<unmatched-paren>Also, the OLD-BINDING is supposed to be a variable name
<vagrantc>HAH. maybe this is a good time to consider the switch from "master" as the default branch to "main"? :)
<unmatched-paren>((#:configure-flags old-flags) (cons* "--enable-everything" old-flags))
<vagrantc>and then set up betterer validation systems
<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))?
<unmatched-paren>it needs to go in (packages)
<unmatched-paren>(operating-system ... (packages (list (package ...) (package ...))))
<unmatched-paren>or maybe
<Cairn>On this is late, but by guix pull worked perfectly. Thank you nckx_
<unmatched-paren>(cons* (package ...) %base-packages)
<Cairn>Hm ok
<unmatched-paren>because base-packages is just a list of (package ...) objects :)
<unmatched-paren>And if you use specification->package, that also returns a (package ...)
<unmatched-paren>specifications->packages returns a list of (package ...)
<unmatched-paren>technically the type of (package ...) is called <package>
<Cairn>Let me give this a tentative shot...
<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>would be trivial to switch...
<vagrantc>you'd probably want to leave master around indefinitely just for time-machine and all that, but maybe freeze the last commit to "switch to some other branch"
<atka>vagrantc: how would one check efi's nvram status?
<vagrantc>atka: i don't know! EFI baffles me and there are a few stumbling blocks i barely understand
<atka>Cairn: config is fine, its just this laptop that has the issue thankfully
<atka>vagrantc: ok, i'll see what I can dig up if it annoys me enough :)
<Cairn>Ah ok
<atka>luckily I don't have to ssh into this machine, so failed reboots aren't too big of an issue
<vagrantc>atka: though if the nvram was full, updating other distros should still fail ... although they maybe update less often and just rely on changes to, say, the grub.cfg
<atka>I have 3 distros on 3 drives in this laptop and its just guix
<atka>I'm testing it now to see what I can find out
<vagrantc>how recently did you install the other distros?
<atka>one is a year old, this guix install and alpine install are a month or two old
<atka>but it has happened with guix way back
<atka>I have kinoite, alpine, guix
<vagrantc>atka: might be a red herring, but this seems to touch on the issue i ran into once:
<atka>guix has boot priorty but fails every reconfigure with can't find bootable device
<atka>ok, sounds promising
<atka>at least somewhere to start
<vagrantc>ok, guix on the mnt/reform, or guix on the honeycomb lx2? which first? or something not guix at all, while the git repository is wonky? :)
<atka>honestly both would be cool
<unmatched-paren>vagrantc: The repo is fixed now, I think :)
<atka>guix is a bit heavy for the reform no?
<vagrantc>atka: a bit, but not unbearable ... ran it on the pinebook-pro ok, which is similar amount of ram, and only a couple faster cores
<atka>any problems with substitutes on the arm64 stuff?
<vagrantc>frequently not available?
<vagrantc>anything that depends on rust ... as it wasn't yet bootstrapped properly on aarch64
<atka>yeah, I imagine subs aren't ready as often
<vagrantc>bordeaux seems to get some of the important ones that ci misses (e.g. linux-libre*)
<vagrantc>so it was better last i looked, but admittedly, it's been a while
<atka>well just offload arm builds to the honeycomb :)
<vagrantc>rust not being bootstrapped on some architectures is getting increasingly difficult
<vagrantc>there was work to fix that, not how far along it is
<vagrantc>not sure ...
<atka>do you work with rust a lot?
<vagrantc>no, but numerous other packages are directly or indirectly depending on it to build
<atka>yeah, I've been avoiding rust stuff, seems like rust always has huge deps
<civodul>nckx_: ah yes, got it; that subkey thing a known-to-some-but-undocumented "feature"
<nckx_>Not a fan I see, OK.
<nckx_>I am :)
<nckx_>But fair that you didn't volunteer to implement it.
<nckx_>(13 Guix committers do use them.)
<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)