<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>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? <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? <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. <blake2b>tbh, I don't have much experience with FC. but it might help to have it installed at the user level. <blake2b>(which would mean "guix install fontconfig") <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 <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.) <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. <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>and its been like that the two years i've been using guix <nckx>blake2b: Which shell do you use? <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. <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 <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 <blake2b>GUIX_PROFILE=/home/user/path-to-profile <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>I get this after every `guix install` <blake2b>sorry, it must be after guix profile <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 <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>I meant ‘should not be needed by default’, my bad, blake2b. <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 <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 <Cairn>`/run/setuid-programs:/home/cairn/.config/guix/current/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin` <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>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. <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 'https://guix.tobias.gr'... 53.2%guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error in the pull function. <nckx>Cairn: My fonts aren't hip enough to render that 3-byte mojo yet. <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>If Matrix generated that s/// sed I am *seriously* impressed. They used to send the entire (edited) line again. <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. <Cairn>To be fair, I don't think a lot of people who use Matrix as an IRC bridge won't know seds <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. <clever>nckx: that sed just showed up as a sed expr in the matrix side <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 <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>there is also package inheritance ... package-minimanl inherits from package (or vice-versa) ... would you define those in separate modules? <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.) <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? <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>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. <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 :) <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 <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 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. <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? <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. <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? <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 <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 :) <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>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>Sorry for going off-topic though. I'll stop. <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. <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]>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'. <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 <nckx>Guix *is* too memory-hungry, no debate there. <nckx>Cairn: Updating to 2.54 made it... worse. Ugh. <Cairn>Not to make the problem worse, but I also can't build frotz-dumb-terminal <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>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>Why does the commit age say 6 days on savannah? <nckx>Because I'm a quirky snoflake. <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. <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 <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. <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 <nckx>Yah but 16 is like almost twice that. Only Jeff Bezos has that kind of RAM. <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.~ <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. <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>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>the_tubular: hello hello <atka>i've been incredibly busy, uprooted my whole life, but doing pretty damn good <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 <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 <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? <nckx>ZhuAisi[m]: What do you mean it was rejected? <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? <nckx>Quite possibly nothing, but that's for the arresting officer to decide. <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. <Cairn>nckx: Ah, so it was right in front of me the whole time, haha <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 all_but_last@163.com, 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 163.com. <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 <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. <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? <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>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 <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? <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 <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 <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. <nckx>They said it filled one, not quite the same. <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 <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>so I need to save energy part of the year <atka>still have 18 hours of daylight now <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? <atka>vagrantc: it would be fun to chat about our systems sometime, mines very minimal <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? <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 <vagrantc>the_tubular: just wrapped up ... a week or two ago <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>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 <pkill9>im on commit ae0c11f9209b1e09997c224b3df645f7ed4d6804 <pkill9>unmatched-paren: so what does that error message mean? <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>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 paste.debian.net? <pkill9>it may have been a custom package <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 <pkill9>how do i list all transofrmed 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 <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 <unmatched-paren>it's mostly used as a sort of staging/unstable branch in my experience <pkill9>actually 9may have run out of disk space <pkill9>why is it so difficult to find the issues page on sourcehut <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 <pkill9>or any indication that it is part of a project <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': https://paste.debian.net/hidden/b8bf2abe Where's my mistake? Thanks! ***Dynom_ is now known as Guest563
***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 <nckx>unmatched-paren: Thanks! I replied, although you might not like m'pinion. <nckx>It's still correct of course. <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. <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? ... <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>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 <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>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>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. <nckx>But since we specifically want to forbid only ‘install/package -i’, I'm not sure what that would look like. <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. <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? <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>The only usage of record-hint is in shell.scm, so no, there's no warning for `sudo guix package` on the first invocation. <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. <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. <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 :) <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? <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? <nckx>Lazy counterpoint: but it's in Debian, mum. <nckx>Which surprises me, Debian being if anything slightly more strict on average in pure licence matters, but there it is. <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>This is starting to sound like one of them humans vs. lawyers deals. <nckx>unmatched-paren: It occurred to me, but I'd personally disagree with that (hypothetical) assessment. <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>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? <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. <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. <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>maybe the workarounds in that thread for the cursor size issue will also work for you <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 <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. <pkill9>does anyone here have fish set as their user's shell? <nckx>kabouik, unmatched-paren, possibly. <pkill9>unmatched-paren: not even issues with /etc/profile? <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. <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. *nckx sorely missing emojo support; hopes a reboot will magically fix it. <unmatched-paren>We could also add that to `gwl` to tell users to set GUIX_EXTENSIONS_PATH <pkill9>currently i have bash runniong fish, but I'll set it up so the terminal emulater runs it instead <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) <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? <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>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]>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. <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*. <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.) <abcdw>I'm pushing my first commit, want to be sure everything is fine <abcdw>39465409f0481f27d252ce25d2b02d3f5cbc6723 <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 <andrew@trop.in>" [ultimate] <nckx>That is Git, not how Guix verifies commits. <two[m]>it looks like matrix messages aren't delivered to #guile <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 <nckx>Absolutely perfect timing. <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>Since there is literally no other way to fix this other than to rewrite history afaik. <nckx>The key marked as authorised is D963, not 2841. Subkey? <nckx>Yes, we've done so once. <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. <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>(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. <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>You might need to remove ~/.cache/guix. <nckx>'guix describe' confirms I'm on current master, stay calm nckx. <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 <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? <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. <nckx>I've been running Guix System on bcachefs for a few years now yes. <the_tubular>Well it's more like an open discussion, but it's a good way to get a status of the project <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 :/ <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. <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>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_>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_>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. <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. <yewscion>nckx_: copy that, thanks! (Sorry for the basic-ish questions.) <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. <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_>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? <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. <nckx_>97%. You are going to beat me. <nckx_>Oh, nope, those last 3% were a lie. <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 libssl.so, curl provides libcurl.so, unbound provides libunbound.so, and czmq provides libzmq.so <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. <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>All I want to do is mess with the build flags. I just don't quite get it... <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 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 <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... <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 ... <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 <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>yeah, OpenPGP normally should allow any valid signing subkey or the master key <vagrantc>you shouldn't have to specify the sub-keys explicitly <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) ...))) <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. <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 <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"))))` <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 <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>(operating-system ... (packages (list (package ...) (package ...)))) <Cairn>On this is late, but by guix pull worked perfectly. Thank you nckx_ <unmatched-paren>And if you use specification->package, that also returns a (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>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 :) <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 <atka>guix has boot priorty but fails every reconfigure with can't find bootable device <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 <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>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 <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_>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)