IRC channel logs
2024-09-28.log
back to list of logs
<podiki>if you haven't done a system reconfigure, updated all profiles, and rebooted in a few weeks, it could be from the big core-updates merge <panosalevro>isn't system reconfigure and guix pull the same thing? <opalvault>I am using guix on a foreign distro. Guix pull + reboot did not fix the issue unfortunately. <opalvault>Failed to create DBus Proxy for :1.28 /org/ayatana/NotificationItem/blueman: Failed to load /usr/share/icons/Papirus-Dark/22x22/status/image-missing.svg: Unable to load image-loading module: /gnu/store/77mgh7yfzl0xrnsxggx8271z7x9mkp0h-librsvg-2.56.4/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /lib/x86_64-linux-gnu/libm.so.6: version <opalvault>`GLIBC_2.38' not found (required by /gnu/store/77mgh7yfzl0xrnsxggx8271z7x9mkp0h-librsvg-2.56.4/lib/librsvg-2.so.2) <opalvault>Waybar is from apt fwiw. As is Blueman. ldd --version gives me: ldd (Ubuntu GLIBC 2.35-0ubuntu3.8+11.0trisquel1) 2.35. <mirai>from what I understand pull only updates the current guix binary + commit in your profile <mirai>but it doesn't change any packages you've got installed <gnucode>Guix pull seems to be taking much longer for me lately. I'm having a harder time when I want to update. I turned my laptop off for a month, and when I ran "guix pull" I was seeing cmake-bootstrap as a package that it was building...That seems odd. <jfred>It seems to be using a CPU core, so it's doing *something*, but I let this run overnight last night and it hadn't finished by tonight. Does building glibc just take a very long time? :) <jfred>it's being built as I try to build my home configuration, presumably there are no substitutes available for my architecture (aarch64) <gnucode>I don't think there are very many AArch64 users... <jfred>the build timed out at the same point mine is <podiki>that build timed out for some reason. i restarted it now <podiki>aarch64 coverage is better on bordeaux (though i don't think you can look up builds from the web, you can see from guix weather) <wisconsin>what is the situation in guix with gpu drivers given that nvidia is transitioning to open source? <nikolar>wisconsin: who said that nvidia is transitioning to open source lol <nikolar>kernel modules are the least important part of the gpu drivers <apteryx>alright, retroarch looking good, now to add some cores <nikolar>all of the magic is happening in the userspace portion <nikolar>so, sure, you can get the open source kernel drivers once they are upstreamed (if ever) <jfred>I will be curious to see if the restarted build for x86_64 succeeds <podiki>i don't think anything should depend on it at this point <opalvault>Still getting the GLIBC error that was mentioned above: Unable to load image-loading module: /gnu/store/77mgh7yfzl0xrnsxggx8271z7x9mkp0h-librsvg-2.56.4/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by <opalvault>/gnu/store/77mgh7yfzl0xrnsxggx8271z7x9mkp0h-librsvg-2.56.4/lib/librsvg-2.so.2) <opalvault>Is that a regression or something I've done incorrectly? I've tried installing glibc via GUIX and it didn't solve the issue. <opalvault>Unsetting GDK_PIXBUF_MODULE_FILE env var (that was pointed to .guix-profile/lib) seemed to fix the issue but I assume that unsetting that permanently probably isn't ideal ;p. <jfred>podiki: hmm, I'm not sure what's pulling it into my home config <jfred>...oh. wait. for some reason I have "glibc-utf8-locales-2.29" specifically in my package list <podiki>jfred: that would be why then, no reason to have an old glibc/locales <jakef>"a package, origin, or other “file-like object” (see G-Expressions)": can a file-like object effectively be an origin with a string label? <jakef>trying to get away from the old input style <jakef>i would use a package instead of an origin, but i don't need a build system <kskarthik>hello! is it common to use guix as package manager on foreign distro ? <jaft_r>kskarthik: sure; one use case I know some people use it for is on Debian, to run more up-to-date packages than may be present on Debian stable. <kskarthik>jaft_r: nice! any edge cases to consider? i wanted to tryit on opensuse tumbleweed <jaft_r>Unfortunately, I wouldn't know; I've only ever used Guix system, never on a foreign distro. But hopefully someone else here might. <kaij>does someone here know/have a more complex server GuixOS setup? how is the code structured? Really unhappy with my current approach so hoping for some input <simendsjo>Hi, I sent a trivial patch to upgrade some fonts 18 days ago, but it's still not merged. I'm wondering if I did something wrong, or if the review queue is just very long (bug#73174). <unwox>simendsjo: probably the latter <simendsjo>Ok, thanks. A very low priority issue, so I don't care that much. I can add them to my own channel until it gets merged. <apteryx>yay, retroarch fully functional, with assets and info files packaged <futurile>simendsjo: if it wasn't processed or it failed that it's unlikely to be reviewed <apteryx>it's a frontend to console emulators <apteryx>it's perhaps the fanciest one out there. Think Kodi, but for emulators. <futurile>oh cool. I've never got into emulators, should play with that area at some point. <futurile>ooh want to give a short talk at Guix Social when you've finished the package? ;-)) <apteryx>hm, not for this topic, perhaps another one? :-) <futurile>We would love any topic, at any level and at any length. We're pre-recording talks so you can fit it into your schedule, and then only the Q&A live. I'm really trying to encourage people to talk about what ever they like and just share their interests <attila_lendvai_>is there an exaple for a package that is built from a github PR as source? <attila_lendvai>great! it seems to be as simple as specifying (commit "pull/544/head") <attila_lendvai>damn! i wish patchelf was built from git... it has a ton of dependencies, and compiling a PR of it would be so much simpler... <Rutherther>hm, maybe would be easier to just add the pr as a patch? <attila_lendvai>Rutherther, i'm probably facing several attempts at finding a patchelf PR that fixes my issue. so, the less pain, the better. i converted the patchelf package, but it has countless dependants... <AwesomeAdam54321>attila_lendvai: Have you tried inheriting the patchelf package as a new separate one? I had to do something similiar with libgc to prevent lots of rebuilds when trying to package pnet <attila_lendvai>AwesomeAdam54321, yeah, i can avoid the rebuilds. what i'm lamenting about is that the guix packages seem to prefer release tarball origins, while i find them clearly inferior to building from git <sham1>Why do you find building from tarballs inferior to building straight from git? I mea, if you have a tagged release, that should be pretty much the same, no? <attila_lendvai>sham1, tarballs are another layer for security breaches (see recent history), and with e.g. patchelf i cannot just simply inherit and pick a different commit. i need to modify native-inputs, and whatnot. <attila_lendvai>sham1, my primary argument is that it's much easier to experiment with different versions of packages by simply overriding their source origin and off you go <sham1>And for most things you can do that <attila_lendvai>sham1, note that release tarballs have already run the auto* tools. you build tarballs differently than git tags <sham1>If they're the tarballs from github, they absolutely have not run the autotools <futurile>what was that security issue where the attacker injected something into the release tarball <futurile>too early - the name's slipping my mind now <attila_lendvai>sham1, i'm obviously talking about real tarball releases, not the github API to fetch git tags as tarballs <sham1>Right, and I'm saying that those should not be used and that tagged point releases could be used instead <futurile>oh the xz security issue - that seems to demonstrate the using revision controlled tags is better than using a release tarball which may not line-up with the source <sham1>That people assume that `make dist` is a good way to do release tarballs is frankly outdated <futurile>it's a pity because 'release tarballs' in my mind has always meant 'what the upstream thinks is a release for users'. But, that's so out of date now heh - I'm still in the 90's <sham1>That only works of course if the upstream isn't malicious <futurile>yeah, that breaks my mind - free software is a collaborative element - I get 'malicious attackers', but until xv subconsciously attacks were 'external'. <sham1>Free software becoming this embedded into the basic infrastructure of computing is botha blessing and a curse. A blessing because it means that there's always going to be some interest in this stuff working, but a curse because now we have to be vigelant against attacks <futurile>yeah, it's amazing how it's moved from an alternative thing, to become embedded and relied on. But the dynamics have changed, for sure. <futurile>attila_lendvai: do you run a channel as well for the patches you generate but that aren't upstreamed into Guix yet? <attila_lendvai>futurile, i do use it as a channel, but it requires a channel intro that must be updated every time i rebase it <sham1>Setting up an alternative channel isn't that bad, of course <futurile>hmm I need to look at channels a bit. Sharlatan seems to have a system for tracking their patches that are WIP <attila_lendvai>i'm not aware of a simple way to set up a separate channel for pending changes (as opposed to a patched guix channel) <attila_lendvai>i guess for simple packages it's enough to define them under a new version, but anything more complicated requires a forked guix repo <attila_lendvai>and it's much easier to notice merge conflicts when the underlying package is modified in the several months while patches are pending... </sarc> <futurile>attila_lendvai: why don't you apply for commit rights, you must have more than enough history in the project by now? <attila_lendvai>futurile, i strongly disagree with some fundamental stuff like the ChangeLog format in the commit messages. to the point that i can hardly force myself to write them, let alone policing them... <Rutherther>attila_lendvai: could you elaborate on what you disagree with? <sham1>Probably the idea that you'd write into the commit body each of the files affected <sham1>Since that can already be seen in the commit/patch <attila_lendvai>futurile, i also don't really feel welcome as a contributor. e.g. my work on shepherd to clean up error handling and to make it more debuggable/inspectable is ignored pretty much without comments. even though the commits were needed to find a long standing bug that even caused multiday outage of guix services. the oneliner fix got in, the rest was left to bitrot, and i got bored of rebasing it. <futurile>attila_lendvai: so on the commit log what's the issue, is it what sham1 said - that it's repetitive? <attila_lendvai>Rutherther, i often feel that the admin work with a patch is several times (!) the effort it took to writing the code itself. this annoys the hell out of the engineer in me. a big part of that is the insistance on the ChangeLog format, which is from an era of CVS... <attila_lendvai>first of all, the changelog format is a loosely defined format that i find hard to learn. i keep going back to past commit messages to learn what to write there. then when i make some mistake, then some of the maintainers take the effort to write multiple email exchanges until i "learn" to... jump the hoops properly... i guess. <attila_lendvai>and yeah, the commit log is also repetitive. we have tools now to grep in the git commits... <sham1>(file/path/here): This is the change of this file <sham1>I'm a bit more lenient towards that style, since if a patch is large enough, it may get confusing just what things changed in a file, but yeah, it's a bit silly <futurile>attila_lendvai: I agree it's pretty finicky, and some people are picky. I think it's interesting that it's what put you off becoming a contributor <futurile>attila_lendvai: yeah - surprisingly in the age of tik-tok not many people make it pass 3 mins heh heh - but I'm trying to reach out to people who don't read manuals - so thought it was worth a try <futurile>attila_lendvai: I swear I spent ages trying to find the simplest "correct" set of steps that a contributor is supposed to go through <futurile>uh that doesn't involve learning emacs - though there is a bit involving emacs in there <futurile>nckx: technically I think most people just assume CI does it - or it's not a problem - but the whole 'we can't merge python-team' reminded me it's actually a problem <attila_lendvai>futurile, i have some psychological trait that makes it hard for me to tolerate unjustified social rituals, especially among programmer colleagues with whom our interaction should mostly be based on reason. life is too short for these (i'm already on the B side)... <futurile>attila_lendvai: ack, I get it. It's a pity because you contribute lots of patches and the project would benefit from that energy. But if it would drive you mad then for sure that wouldn't be useful :-) <attila_lendvai>e.g. i'm yet to hear a rational justification how searching in the git commit log is boosted with equal or more efficiency as the collective effort it takes to produce the strictly enforced changelog format. and what bothers me most is that this discussion is not only not happening, it's not really welcome... <futurile>I don't think it's 'unwelcome', so much as 'other people' will consider your 'unjustified' steps to be 'simple and useful' so can't see it. And the project doesn't really have any way to make decisions that are not a consensus. That desire for consensus is good, but also bad. <jakef>maybe someone would be willing to do the commit log formatting for you <ekaitz>attila_lendvai: i wish i could disagree with you, but I can't <ekaitz>i'm pretty much ok with the main part of the changelog format <ekaitz>with the "* module (variable)[field]: whatever" i'm not <nckx>Wait, what's the 'main part' for you then? <ekaitz>like the introduction and all that <jakef>but on your gripes with contributions not being accepted, surely that's a matter of discussing them with the maintainer beforehand so they have a chance of being accepted in the first place <attila_lendvai>a lot of the social rituals have costs that are not obviously observable. i don't see any maintainer ever considering how certain things can turn away contributors _without any noticable sign_. i've seen myself looking at e.g. the disorder in the project's filesystem, or non-archived but long obsolete repos left there to eat up attention... and then quietly turned away from such a project... <sham1>The introduction. As in, the actual commit message :P <nckx>ekaitz: Oh, OK, I don't consider the free-form description part of the 'changelog format', all good projects expect that. <nckx>Single-line commit messages are a great indicator of low-quality diffs. <ekaitz>but the changelog format also forces the title of the commit and so on, doesn't it? <ekaitz>I like a good title: "gnu: commencement: blablablah" followed by a proper explanation <futurile>ekaitz: so your format would be: "* location/file: Add (variable) to X." and that would be it <attila_lendvai>guix has several of these turnaways for me, but i'm enthusiastic enough as a user to tolerate them and to speak up about them... which is probably part of the reason i don't feel that welcome as a contributor... <ekaitz>the details of "removed this variable" and then "added this variable" sometimes are just hard to write because: how much granularity we need? <ekaitz>for example, i rewrote the whole PEG module of Guile. Should I list every single variable I deleted? <futurile>attila_lendvai: I can see what you're saying - and generally the project is slow to change - but equally "social credit" has a lot of importance in volunteer projects. So your chances of seeing the sorts of changes you want are more likely if you are more involved. Though in fairness it sounds like you wouldn't get most of the changes you would want heh <ekaitz>sometimes it's great to surgically detail which change you made, specially in guix packages, but sometimes it's superhard to say <attila_lendvai>FTR, i'm ok for a title line format, and with demands for explaining parts of the commit that cannot be for formalized in the diff itself. i'm also ok with an optional /file/path: nature of the change format. what bothers me is that i often feel that i'm rewriting scheme code in the changelog format... <ekaitz>attila_lendvai: that's more or less my feeling <ekaitz>or that i'm copy pasting the list of changes Git mentions in the comment part of the commit message <futurile>attila_lendvai & ekaitz - write a RFC to guix-devel asking for this change ;-) ... only half joking - who knows? <attila_lendvai>what also bothers me is that in every single project i have participated in the past 30+ years it was a major offense to commit something that breaks the build. in guix it's demanded. <ekaitz>also, many times there are commits that don't explain anything really because people don't bother to actually explain the intent of what they did. They only list what they changed. <futurile>ekaitz: yeah that I've noticed. The format actually doesn't make it clear how you should explain 'why'. <ekaitz>futurile: the RFC process is done already? if it is, i might suggest some things <attila_lendvai>futurile, i already have way much more valuable contribution lying wasted (see shepherd)... and i hardly have much social credit to be taken seriously, so... i'll pass on that. <futurile>ekaitz: no, I'm just shortcutting - ne way for the RFC process to be done is ... - start using it. <futurile>ekaitz: in many ways it's 'done' when it gets used - because until it gets used it will just devolve into a navel-gazing session <attila_lendvai>ekaitz, yep, i agree with that, too (lack of explanations in the commits, while the changelog format is nice'n'tidy) <ekaitz>attila_lendvai: i don't know about the rest, but I don't consider you have a low social credit in this community. I think you are a valid member that made significant contributions. <futurile>attila_lendvai: OK, understand - just thought I'd ask as I've seen you're contribution, and saw you wanted to speed up contributions <nckx>I always thought you were more of a Guile contributor who sometimes came over to drop a Guix patch, but that might just be because I don't follow Guile that closely. <ekaitz>the social credit part might be part is tricky... I also feel "outside" quite often... <attila_lendvai>ekaitz, thank you for pointing that out! i have a different impression. i don't think it's necessarily personal. maybe it's just the way guix is unable to graduate to a more serious level of cooperation, and struggles with the bandwith limits of the core maintainers and project structure <attila_lendvai>nckx, i'm a longtime lisper from the CL side of the isle. and i have even more issues with guile... :) <ekaitz>attila_lendvai: I understand your feeling, because I feel it too. I try to be a little bit more active here to reduce that friction but it's very hard, because I'm not a "core" guy. <attila_lendvai>re guile: e.g. if i join the project then i refuse to do anything serious until there's at least proper logging and backtraces. and i have a hard time to fathom how come that guile has so enormously useless backtraces, and that people spend a lot of effort on debugging stuff, while a tiny portion spent on the tools would enormously increas the output... <ekaitz>attila_lendvai: in fact, I recently had this kind of interaction in Guile and I even complained publicly about it. Some people misguided me to think I was wrong with something that was very easy to check and discouraged me from changing things that are simply wrong. I think because "no change" is better than a "change" in a project that is so limited in terms of human power... <nckx>attila_lendvai: I thought Scheme side. Shows what I knew! <ekaitz>i think guix is a pretty welcoming project in terms of adding your simple patches to it, but it is true we could improve other parts <ekaitz>in guile, even that part is very hard to do <nckx>attila_lendvai: This is really just a question, but did you contribute any improvements to Guile backtracing that were ignored? <rovanion1>I want to read a list of packages from a file in a system manifest. I also want this list to be readable from Bash. On top of this I would like to attach a comment to each package explaining why it's listed. Any ideas on how to format this file? <attila_lendvai>i'm also easily irritable with backward compatibility... version control is there to solve backward compatibility. but not fixing stuff just to remain comatible... is not for me. and i do see that impulse around guile. <futurile>ekaitz: don't you think that's primarily a bandwidth and 'imposter' issue. There just aren't enough active committers to handle the overall throughput. Particularly as a fully volunteer project. <ekaitz>rovanion1: an s-expression, and use a simple guile program that `read`s it for your bash process? <attila_lendvai>nckx, i didn't, because i had the impression that it would be ignored. and i also need a narrative that explains why they are so crappy before i embark on a quest to make them better. and another narrative why we must deal with guile when there are much better schemes that contain only trace amounts of C <nckx>There was no way to ask it that didn't sound like bUt DiD yOu SuBmIt PaTcHeS. <ekaitz>futurile: no, because I could be that people is not able to spend time in things, but in this case they are actively discouraging change, based on the fact that they look like they know the project better than you do. It might be a symptom of the same problem, but it doesn't feel good. <attila_lendvai>just FTR, the debugging experience in slime and SBCL is incomparably better than guix and guile <rovanion1>ekaitz: Sadly Guile isn't installed on the other systems I set up using these scripts. Though I could of course add a bootstrap step that installs Guile before anything else. <ekaitz>rovanion1: or awk it for the win? <futurile>ekaitz: do you think people object to change for legitimate technical reasons, or are you saying they're objecting for reasons of habit (what they're used to?) <ekaitz>futurile: in this case i think is habit or not wiling to do more work... or idk maybe a weird manifestation of RTFM <rovanion1>Looking around, the "Convert it into Scheme and eval it" seems to be a common answer given to people asking "How do I do data input in Scheme?" Is it cumbersome to load data in other ways? <ekaitz>rovanion1: that's how manifests, and packages and so on are loaded in guix <ekaitz>rovanion1: you could make a parser and stuff, too <attila_lendvai>futurile, if it's indeed just a bandwidth issue, then i'd like to see discussion about the project stucture and organization, or at least admitting that it's a problem. but i don't really see that. <attila_lendvai>futurile, quick feedback on the video: it's very quiet. maybe apply some dynamic range compression after recording. <futurile>attila_lendvai: ah thanks, that's useful to know. I'm still really learning how to do videos (as you can tell I'm sure). I've been struggling with the audio. <ekaitz>futurile: good think you are speaking slowly in the video, the other day when we did the questions for the guix social i was afraid of not understanding your british accent without being able to read your lips hehehe <futurile>ekaitz: yeah, it's very hard - in my area of Britain we speak really fast (particularly when we're excited), so I know I have to slow down - but to my own ear it makes me sound really "dead". I actually landed up having to re-edit the audio to try and have some "aliveness" in the voice and then cutting bits of it so it was slow heh heh heh - way too much <futurile>ekaitz: also involved listening to myself speak lots and lots - and you know that's just yuck - "you sound like a really slow brained idiot, and can't say the word G-e-e-k-s properly" heh heh <ekaitz>futurile: i think non-native speakers are not used to the richness of accents of the british islands... but that's more our fault than yours <ekaitz>i also speak very fast in spanish and it's really difficult for me to make non-native speakers understand me... <futurile>ekaitz: well my partner laughs at me because after 25 years in London I still can't say "here" - I always say "h-e-e-e-a-r-e" - and she says the angrier I get the longer it gets <ekaitz>and my english accent is funny (people in fosdem thought i was greek, also because of my name) <futurile>well I'm interested to see if someone finds the video useful - I personally prefer reading - but video content does very well for lots of people learning. <futurile>definitely need to find ways to make things less of a "lecture" and shorter like attila_lendvai - the same thing is happening with the blog posts - just getting too long <futurile>yeah I figured people could always "speed it up" but not so easily "slow it down" - on youtube anyway <attila_lendvai>futurile, “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” — Antoine de Saint-Exupery (1900–1944) <ekaitz>i wouldn't stretch it too much. Be yourself and enjoy the process. People will get used to it and enjoy it more if they see a person behind the video. <futurile>attila_lendvai: right, that in part depends who you're writing for - I can't figure out if I'm writing for myself "started using free software in 1996"; or more someone who is "I use github and I've never built a Linux package in my life" <attila_lendvai>futurile, i think the magick is in writing for yourself, but in a way that others also find meaningful and interesting <jakef>speaking for the latter group, your blogs are a gold mine Steve! <futurile>jakef: thank-you, I appreciate the feedback - definitely hoping it's helping people along a journey (that I'm on myself) <attila_lendvai>futurile, indeed, very interesting posts! i even have a feeling that most of them could be guix cookbook entries <sham1>"base use of '=>' syntactic keyword in subform => of => <sham1>The problem was that I wasn't importing (gnu services). Still though, that's a confusing error message <sham1>Also, apparently a record made via define-configuration cannot use (inherit) to propagate keys. That's a bit irritating <sham1>Should probably file a report about that <Rutherther>sham1: that doesn't seem right, I think it is possible to use inherit with define-configuration <sham1>Oh, problem actually existed between keyboard and chair <sham1>I wrote (home-gpg-agent-service-type ...) instead of (home-gpg-agent-configuration ...)