IRC channel logs
2024-03-29.log
back to list of logs
<Mist64>So guix shell is almost nix flakes, interesting <Kolev>Does anybody have experience using Guix on Fedora? <Kolev>I'm worried about SELinux and stuff. <db8x>I prodded the SELinux policy a few times; it’s not perfect <db8x>Kolev: do you have a specific question? <apteryx>nckx: hi! could you please set my passwd on p9.tobias.gr? <apteryx>I'm trying to debug some problem with 'perf', and it complains that "Access to performance monitoring and observability operations is limited." <Kolev>db8x, I want to use Guix on Fedora, but SELinux makes it difficult. <db8x>Kolev: yes, the policy worked a few years ago when I messed around with Guix last. it may need updating, but that’s not super hard <Kolev>db8x, what all do I need to do, to get Guix to work on Fedora? 🙁 <Kolev>Fedora deprecated one of the things that Guix relies on. <wingo>i have to get my guix driver's license back in order. how does one go about updating gdb <wingo>14.1 has a bug, 14.2 fixes it. i understand there are tools to do this automatically but also that you need to be on a gpg keyring or something <wingo>for the moment i can build --with-source=gdb=mirror://... <wingo>but oddly i could not build with --with-latest=gdb; some error about GDB's signing key not being in my keyring <wingo>which prompted me to add the key to my keyring, but in a background terminal or something <sneek>Welcome back civodul, you have 3 messages! <sneek>civodul, rekado says: I've pushed a fix for the logs, and I'm working on replacing datatables now. <sneek>civodul, apteryx says: what does suspendable means for a thunk? <sneek>civodul, rekado says: I've restored missing JS in the cuirass main branch. I'll remove the rest once the switch from bootstrap to pico is complete. Will do that in a separate branch. <civodul>apteryx: “suspendable” as in you can abort-to-prompt any time from within the thunk (there’s no continuation barrier) <civodul>PotentialUser-47: just write and people can read and answer :-) <guestmeow>Hi, I'm still kinda new to Guile. I noticed that to remove a service from %desktop-services a lambda like this is used: `(remove (lambda (service) (eq? (service-kind service) gdm-service-type)) %desktop-services)`. <guestmeow>What would the correct way to do this be if I also wanted to remove, say, geoclue-service-type? <guestmeow>I've tried a bit in the Guile shell but can't use `remove` there for some reason I'm probably missing as a Guile beginner <df>also, if I just install 1.4.0, do I just need to guix pull (as root?) to upgrade to the dev version? <df>er, guixsd this is, btw <civodul>df: hi! yes, you can install 1.4.0 and then run ‘guix pull’ + ‘guix system reconfigure’ to upgrade <futurile>civodul: out of curiousity, did you get an answer on the state of core-updates? <futurile>civodul: I think I'm lost on what has to merge first, before core-updates get's merged. <futurile>civodul: I think we're seeing a few challenges along these lines around the 'branch' what of working - long running branches and co-ordination <civodul>to me, the problem with core-updates is when we try to lump together too many changes <civodul>i know because i mad that mistake a number of times :-) <civodul>then at some point you lose steam, somebody else comes up with unrelated changes, etc. <civodul>and it takes a long time to converge <df>(apologies in advance if this violates the non-free software rules) - the installer didn't recognise my wifi card, but neither did it report it as requiring non-free firmware, is it possible I just need to load a kernel module or something? <civodul>df: good question; can you check what model this is and/or whether anything relevant appears in /var/log/messages? <civodul>then the installer could at least warn about this specific model <df>the model is realtek RTL8822CE, just looking at logs... <apteryx>my emacs consumes 1 GiB for no obvious reasons <apteryx>it used to be that it'd stay around 300-400, if I recall correctly <tricon>emacs_is_good: Guile is a big difference. <tricon>emacs_is_good: You get to use a Real Programming Language (TM) instead of the Nix-specific config lang. <df>can't seem to find it in the logs, there are a few other realtek devices mentioned <df>but it's definitely there, lspci knows about it <tricon>df: what's the lspci identifier? <df>is that the first bit of the line? <df>or do I need an extra param to lspci? <emacs_is_good>i have lenovo v15 amd most like every distro i tried is supported, anyone know it will support guix ? <tricon>df: let's start with just the full line of the device. <df>ok, but I'm copying this manually so mistakes are possible... <df>02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8822CE 802.11ac PCIe Wireless Network Adapter <df>emacs_is_good: the overall device? it's just a cheap lenovo desktop <df>"IdeaCentre 3" apparently <apteryx>civodul: I guess we should restart our emacs and issue M-x profiler-start, choose 'mem' <apteryx>later when it bubbles up to 1 GiB M-x profiler-stop, and M-x profiler-report <civodul>restarting Emacs is annoying though… <df>emacs_is_good: yes, ryzen 3 3250u <podiki>perhaps one "solution" to core-updates scope is to just rename it to drop that historical baggage. or rather remove and have specifically named branches only (gcc-updates, glib-updates, etc.) <df>is a message in the logs about a PHY driver relevant? (I have no idea what a PHY driver is) <tricon>df: Yes. It's the physical layer. <apteryx>civodul: I've been distracted by the qt-team branch as of late, but I think core-updates was looking fine <podiki>i definitely understand the feature creep as people want to get in patches <df>tricon: of the wifi card? <apteryx>podiki: I don't really see an efficient alternative to 'bunch core stuff upgrades'; rebuilding N times the world just to know if each core tools had an impact seems wasteful <podiki>we should be doing the world rebuilds more frequently so patches can be merged more regularly instead of waiting for one big build with tons of stuff <podiki>apteryx: yes, but the name has become associated with "anything that needs 1000s of rebuilds" i fear <df>hmm, it looks like it's loaded a kernel module called rtw88_8822ce <tricon>df: Possibly. It's part of the kernel. <podiki>i do think we need a "core" scope and branch, but it has always grown immense in scope for my few years here <tricon>df: and `ip -a` doesn't show your wifi device? <df>searching for that module name finds a lot of stuff about failing to load firmware, I guess it's not supported <mdupont>here is an idea I wanted to share, imagine a curiass guix build channel that is specialized to a cluster and has side effects, each derivation is a cluster state and we manage the state of the server in curiass. maybe we would have to add a few more tables and functions to the existing system. <futurile>podiki: what do you think about gating with a time limit on it? For example, it gets merged every 3 months no matter what <futurile>podiki: it's closed two weeks before the merge, so everyone knows - and it reopens after the merge - so at worse you wait 3 months <podiki>a timeline would be good yes; maybe with a (rotating) person responsible for having to make some decisions that invariably will come up <podiki>may need delays/adjustments sometimes, but that should be an exception and for good circumstances. or having to cut out some changes that won't be ready in time and given priority in next round <futurile>podiki: yeah that seems fair enough - so you know that if you missed out you're "at the front of the queue" for the next round <futurile>podiki: getting people willing to be the rotating person might need some social engineering heh - but yeah that would be brill <podiki>well the side benefit is you get to help steer it :) <podiki>just a taste of power, nothing too much tough! <podiki>small branches with fewer people will tend to be more agile, but we do risk losing the hard work that fewer want to do <remyd1>Hi, I am looking for packaging kcolorscheme. It looks like KDE source frameworks are retrieve with url-fetch. The mirror string is: (uri (string-append "mirror://kde/stable/frameworks/" (version-major+minor version) "/" name "-" version ".tar.xz")). I do not know what is "version-major+minor version" here. Any idea ? Thanks <Kolev>I'm disappointed that nscd is being deprecated on foreign distros. Makes it hard to install Guix on them. <podiki>looks like a function versio-major+minor taking version as an argument to make a string of some form? <remyd1>Ooh, that is a kind of function... ? <podiki>it should be based on the code you pasted <podiki>so i would guess it is a helper function to format from "version" (the variable) to a string of a particular format for getting this source <remyd1>podiki, I think it is in a module imported, but which one ... ? I don't know actually <Kolev>Had to install Guile modules from source because Fedora doesn't do nscd. <apteryx>uh, libvirtd is using 533 MiB of memory on my system <apteryx>restarted it, it's now at 1 MiB. Odd. <apteryx>ah, tEre are dnsmasq errors in my /var/log/messages <apteryx>so hm, libvirtd == 500 MiB of memory <apteryx>my emacs config freshly restarted is about 150 MiB. <ieure>Fortunately(?) the version in Guix is too old to be affected. <h3>How to set `ungoogled-chromium`/`icecat` organization policy plug-ins/add-ons in /etc/config.scm? How to know what happened to a patch/bug/commit from Guix mail lists? Like if it was merged somewhere, appeared somewhere, if it was only on that mail exchange? And if it's only on the mails, how to apply them all to have the actual work done to execute it? I try to insert a package into Guix channel to test it with `guix shell` before pushing it but all I get is that the p <h3>ackage is unkown. How to make it known by Guix? <civodul>ieure: yes, and *if* it only affects sshd-linked-with-liblzma, we’re ok too <ieure>civodul, Right? I don't remotely condone the behavior, but you have to admire the ingenuity of the attack. Probably doesn't affect Guix, reading more, I see that stock OpenSSH doesn't link against liblzma, but RH/Debian patched it to enable systemd, which pulls in the compromised lib. <ieure>Wonder if that dev was compromised, or if they were playing a long game to carry out this attack. <podiki>haven't given a full read, but was something about a binary test file and using the autotools generated build/install procedure? <ieure>podiki, Yeah, the payload was in test files and the build scripts compromised to inject that into the output tarball, so it wasn't directly in the code. <podiki>and a good reason to always build directly from source (as we do); at least one less vector <futurile>hmm this h3 person bounces in - asks these questions and then bounces back out - it's like they're a script or something <podiki>not that you don't get source backdoors, but easier to audit if people are looking <ieure>podiki, The *source tarballs* were compromised. <ieure>BFS wouldn't have helped here -- only building directly from the source *repo*. <podiki>right, going directly to a git checkout for instance <futurile>I think you're overestimating the amount of 'looking' that happens by distro packagers honestly <podiki>just that it is a possibility that is very slightly more likely at least :) <dthompson>this backdoor is wild. haven't seen something like this in awhile. <podiki>maybe we should always use a git commit directly <podiki>and found basically because someone was like "why is this slow/weird" <ieure>podiki, I think preferring the source repo over the tarball makes a lot of sense. <podiki>i would guess there's some overhead and mirroring that factors in a practical sense, but ideally i would think so, using source repo to always be as "direct" from the starting code <podiki>fascinating. at least from a prospective where we are not scrambling to fix something right now <podiki>though seems a big audit of xz and possibly other projects with contributions from that account is needed immediately <ieure>Git clones are usually heavier than a source tarball. Using ex. Github's feature where you can get a tarball of a tag could be a reasonable middle ground -- though you have to trust Github in that scenario. I personally do not. <podiki>those tarballs are not stable i believe <podiki>not sure what/when they change but that's what i've heard commented in guix <podiki>or at least the source tarballs on a release page (i assume same thing?) <podiki>clearly we should just have a local git mirror of All The Source <stikonas>you would have to rewrite quite a bit of commencement.scm if you want to use git snapshots... <podiki>or maybe create/host our own tarballs for commencement.scm (and bootstrapping in general?) <civodul>using Git snapshot is something we’ve been discussing for a while <civodul>problem is, i’m not even convinced that we should focus on Autotools alone <civodul>i mean, sure, hiding stuff among those spaghettis is easier <civodul>but it could be something else too, there’s no shortage of complex systems <futurile>given that the person was in the project for 2 years, it seems like they could have done nasty things in the normal source, as much as in the release tar balls <civodul>this person managed to trick developers for 2 years <civodul>(developers of multiple orgs even, like people from distros who reported “bugs”) <podiki>so seems likely always malicious, not a recent e.g. account compromise? <podiki>either way all previous actions need to be audited <podiki>guess i better keep tabs as part of guix-security <ieure>Yes, very likely will have Guix impact, just not on xz. <podiki>i believe this has come up before (and is documented?) but guix time-machine means you can/will go back to vulnerable versions of software huh? <podiki>and nothing we can do about that other than warning? maybe a list of known backdoored/vulnerable sofware that time-machine can print out if you are at a commit with those versions? <podiki>e.g. we have guix lint which checks CVE database already <ieure>Yeah, that'd be a really nice feature. <ieure>You have to use stuff like time-machine with care, not unlike the Windows XP machine I keep around to run some vintage hardware (Data I/O Unisite device programmer, mostly). It's airgapped. :) <podiki>as a quick (maybe?) hack, running guix lint on packages named in a manifest (using current guix source) <ieure>Nothing wrong with it, you just need to know to take care. <podiki>i remember winxp would be remote compromised basically instantly when connecting to network if it wasn't pre-patched with whatever was big security updates <podiki>civodul: great. what do you think about using guix lint machinery to warn about a manifest with vulnerable versions? would that be a reasonable way to do some more precise warning? <ieure>podiki, Yeah, WinXP wasn't a great idea to put on the network even when it was supported. <civodul>podiki: there’s even an old prototype ‘guix health’ in the patch tracker <civodul>it had shortcomings we should be able to address today <civodul>but anyway, my concerns (panic?) right now aren’t addressed by such tools <podiki>civodul: right. there are fundamental issues <moesasji>I'm trying to figure out how to create a service that needs a config-file in a sub-directory in /etc. Does anyone know of an example how to do that? <tricon>moesasji: I was pursuing the same but ended up making a service that permits passing a config file. It uses `(string-append "--sysconfdir=" (assoc-ref %outputs "out" "/etc"))` for the default conf path, which ends up being /etc within the package output. <tricon>It was a WIP that was abandoned due to the project stalling and surely could use some cleanup. I could share the example with the project name generalized if you wish to take a peek. <moesasji>Not sure that would work for this. This program looks for multiple files in that subdirectory in /etc <moesasji>very strange there isn't an obvious way to do this <podiki>(finally read the xz security report and how it gets to ssh authentication...wow, sophisticated. lucky it was caught relatively quickly but easily could have been missed for a long time) <moesasji>tricon: both ssh and dropbear indeed use activation-services to create a subdirectory in /etc. Strange pattern <tricon>podiki: I just read up on this. Fascinating, and the CVE score is a 10.0. <tricon>Interesting that some of the exploit was only in release tarballs. <podiki>tricon: yeah, pretty clever and devious <tricon>Another good case for source-only builds... and against vendoring libs. <tricon>I like how Guix approaches source-only + binary w/ the challenge option. <pret7> https://issues.guix.gnu.org/70082, just packaged pass-import. sorry about the prerequisite patch id stuff in the patch. happens because I have a branch running in an inferior locally (I hope the length of that email didn't get me banned or something because the replacement patch and stuff I sent aren't showing up on the web tracker lol) <pret7>oh my explanation email shows up now, but the replacement patch I sent didn't, weird <pret7>btw how does one mark revisions using mumi? <podiki>note that mumi syncs every so often, 15 minutes maybe? so it won't show right away often <civodul>podiki: should we publish a statement that Guix is (to our knowledge) not affected? <podiki>sure. like a quick blog post or just to mailing lists? <podiki>"and this, kids, is why we never trust binaries" <civodul>OTOH people are going to wonder and there are likely users who don’t follow mailing lists <podiki>which reminds me, did a note ever go on guix-info about the last cve? i don't know if i'm subscribed actually <podiki>yes, but lucky is better than unlucky :) <civodul>we’re lucky because we have and old version and don’t use systemd <podiki>what is the saying, i'd rather be lucky than good? (or is it the opposite?) <podiki>i've been spending most of the afternoon following this, really interesting. seems the maintainer (or maintainer's account) responsible joined the xz project a couple of years ago. this was a long plan. find a widely used project in need of maintainer, basically <civodul>yes, the social part is what’s most impressive <podiki>or, as some HN commentators pointed out, did an agency help engineer circumstances to put a maintainer in such a position to need help... certainly plausible scheme I would think, but who knows <bjc>well, that puts my plans to agitate for a systemd package on the back burner ;) <db48x>is there any way to make guix system reconfigure do less work? I just changed my pulseaudio config and it seems to have redownloaded the whole OS <bjc>if you didn't pull since the last build, and all you did was change the config, it shouldn't have had to do that much work <db48x>I installed this the the day before yesterday <bjc>after the install, did you pull and build again? <bjc>the first pull after install probably updated a lot of stuff <db48x>my bash history says yes. I did a guix pull followed by a guix system reconfigure <bjc>not sure, then. but, in general, you're right. a simple config file change shouldn't create a lot of work in system reconfigure. though it will probably do more than you'd expect coming from other distros <zamfofex>db48x: Did you pull after your first system reconfigure? <vagrantc>move slow and avoid insidious security bugs <Aurora_v_kosmose>By the way, is it part of the package development practices recommended to crosscheck repository and tarball when writing the definition of a package? <Aurora_v_kosmose>It looks like a good way of ensuring that the mechanism used for today's vulnerability is impossible to silently exploit on Guix. <podiki>probably a good idea, but i doubt people do that <podiki>preferring a git checkout is maybe better then <Aurora_v_kosmose>For certain. Though a mismatch could itself indicate issues and could lead to discovery of a repo having been compromised but tarballs not having been updated yet. <podiki>though aren't tarballs different often anyway, because they have autotools generated stuff? (which we don't use, we run autotools) if i understand <Aurora_v_kosmose>If both are compromised in lockstep then yeah, situation's FUBAR unless mundane auditing catches it. <Aurora_v_kosmose>podiki: That's a practice that just plain needs to die. "autoreconf -ri" isn't hard to run. There's no reasonable excuse to bundle it anymore. <podiki>i would say reducing steps and failure points between the upstream source and a distro package is good practice <podiki>right. and if it is confusing for a "typical user", whatever that means, it is more handled by distro packagers, who should know <Aurora_v_kosmose>Plus it's not like it's hard to add a mention in the README or BUILD file of a project. That's how I learned about it in the first place, long before I actually sat down to read a book on how autotools works. <podiki>unfortunately we know good documentation seems to be difficult. or even just listing the actual dependencies :( <db48x>and when I run it myself in a shell it does work <db48x>but when gdm runs it at startup it just doesn’t <db48x>no extra log messages either <db48x>it is listening on the same port in both cases <db48x>but it doesn't actually accept connections <db48x>ok, then I quit pulseaudio, and I guess gdm restarted it’s copy