IRC channel logs
2024-04-03.log
back to list of logs
<podiki>sneek: later tell lfam gexiv2 also failed on... hydra 128. built fine locally. so something is up with that machine i'm guessing. will restart some of those builds and see what happens <cbaines>zamfofex, I've restarted it on bayfront and I think it's back <cbaines>I think NGinx is caching error pages though, which is probably not ideal <cbaines>(and there seem to be two processes) <podiki>cbaines: any thoughts on why hydra 128 is having build failures with errors meson.build file time is too far in future? <jab>bummer. I was hoping that the guix blog would have an april fool's day post. <lfam>jab: They moved the blog to TikTok <sneek>lfam, podiki says: gexiv2 also failed on... hydra 128. built fine locally. so something is up with that machine i'm guessing. will restart some of those builds and see what happens <lfam>That's the best you can get on April 2 <Googulator>well, given how close Easter fell to April 1st (indeed April 1st was still considered part of Easter in many countries), I'd say we got an early (and malicious) Easter-egg-slash-April-Fools this year... <lfam>It's going to take me a minute to decompress that sentence <lfam>We could spend a lot of time unpacking these jokes <jab>let's not us xz to decompress those jokes <jab>also, this is going to sound like a dumb question...I've been using guix deploy to manage gnucode.me for a while now. But 'ssh gnucode.me; gnucode $ guix system describe' shows the latest system generation from last august in 2023. <jab>I just deployed just now. and rebooted. Shouldn't the remote server show a new system generation? <jab>Or doesn't guix deploy update the server to a new system generation? <jab>in case anyone's wondering, here's the deploy file that I'm using for gnucode.me <lfam>Gotta be some other deploy-ers here! <lfam>jab: To rule out the obvious, are you deploying while using the newer version of Guix that you want to deploy with? <jab>lfam I am deplying from my T400. On my T400 'guix system describe' returns a date of March 31 2024. <lfam>How about `guix describe`? <jab>my T400 -> 'guix describe' -> March 31 2024 <jab>lfam: ok I've got it somewhat figured out. <jab>I'm using this is ssh into gnucode.me 'ssh gnucode.me' <jab>that says a very old version of guix is being used. <jab>but 'ssh 45.56.66.20' shows a very recent version of guix being used. March 31 2024. <jab>so apparently 'ssh gnucode.me' is taking me to a different server? <jab>'ssh 45.56.66.20' is just failing. <jab>I was checking the version of guix on my local machine, when I thought I was running 'guix describe' on the remote server. <jab>so I still have no idea why the remote server is running an old version of guix. <lfam>Do you see the right stuff in `guix system list-generations`? <jab>lfam: the latest generation is generation 20 with a date of August 17 2023 <lfam>I see. So, it seems like `guix deploy` is simply not working <jab>seems like it, but when I deploy, it appears to work. <jab>maybe I just need to update from the server manually. <jab>which is annoying, because that server only has 1GB of RAM. I could temporarily increase it. <jab>wow, I just did a guix system delete-generations on the server...it's pulling in a lot of substitutes... <lfam>My next guess would be to make sure the bootloader and filesystem stuff is declared correctly <jab>lfam: I don't think that stuff is wrong, but I'll check. <apteryx>I've pushed a 'hotspot' package, which is useful to visualize flame graphs from 'perf' profiler data, in case anyone is interested in trying it out <necto>Does anyone have experience running a `pipewire-service` from a `guix home` config on a foreign distro (ubuntu 23.10)? <necto>i.e., atop, or instead of the one Ubuntu already runs for me <troi>GUIIIIIIIIIIIIIIIIIIIIIX <Guest16>Hi, I just reconfigured my guix home to update stuff (no changes to my home config). But when I started Emacs after the reconfig, magit had disappeared! Which is odd since I thought magit was included with most Emacs builds. <Guest16>Also I'm using emacs-pgtk, but not sure if that makes any difference here <Guest16>And I tried adding the "emacs-magit" package for good measure (wasn't necessary before), but that still didn't bring magit into my emacs. <Guest16>peanuts: thanks! I must've pulled right before that patch. I'll pull again now <Guest16>peanuts: whoops, browser crashed - not sure if my thanks got through <jakef>Guest16: that patch hasn't been accepted yet so it still won't be fixed after a pull <jakef>you can just (require 'magit) as a work around for now <PotentialUser-92>Hello. What would be best practice for an admin in case a malicious package (similiar to xz or log4j) had infected GUIX. Can one force users to update or clean their profile or at least check if some of the users are affected? <jakef>PotentialUser-92: sudo -u guix pull and so on would work, right? you might not be very popular though <snape>it seems magit doesn't work anymore on Emacs? <snape>at least since I last updated <jakef>3rd person to bring it up in IRC in the last hour :) <civodul>janneke: that ‘wip-tarball’ branch is a great idea! <janneke>civodul: thanks, preparing a patch set <janneke>ACTION has been carrying it for years, but for guix it's not as trivial as for mes or gash <efraim>I know people are worried, so I want to reassure everyone that even after the latest emacs update vim-fugitive still works inside of vim <civodul>janneke: neat! i guess we could use a function for version-LANG.texi, to avoid copying it <rekado>for the record: to answer PotentialUser-92's question: "guix gc" can be used to find installations of known-vulnerable store items. <rekado>it's a little low-level, though. <rekado>perhaps it would be a good idea to write a command that provides a more convenient user interface (e.g. package name and version as an input, and it lists all profile generations in response) <janneke>it's always unclear to me on which gnu make functions automake barfs, and which ones it allows <civodul>or maybe a stem (%) would be enough? <civodul>Guix uses Automake with -Wno-portability so we’re free :-) <attila_lendvai>is this only me? gedit errors out with a missing symbol: undefined symbol: g_string_free_and_steal <attila_lendvai>ACTION is preparing a version update patch, but wants to know whether it's actually broken <jakef>attila_lendvai: when does it error? on startup? <attila_lendvai>ll `which gedit` => /gnu/store/zj5y9r6cn0mh4j9cglib3302w2csnqc9-gedit-44.1/bin/gedit <attila_lendvai>if i update to and build v44.2 or 44.3 locally, then those binaries work <attila_lendvai>"applying 61 grafts for gedit-44.1" -- that's quite a few grafts... <rekado>attila_lendvai: I just did "guix shell gedit -- gedit" and it works fine for me. <rekado>guix describe says I'm on commit 9e9ec741d0dc5ce58f8d21d31800ff2cafce128f <jakef>let me know if you want to discuss anything <rekado>jakef: oh, I didn't get a notification for this <jakef>no worries, this isn't an xz pressure the maintainer thing <rekado>jakef: I'll comment on the pull request with some change requests <attila_lendvai>rekado, i'm 3 (innocent) commits behind you. i have no idea how come it doesn't work for me. <attila_lendvai>damn! it works when started from a clean terminal, but not when i'm in my guix checkout (that uses direnv, whose state is probably obsolete). maybe i should reconsider my use of direnv... <attila_lendvai>yep, deleting .direnv/.guix-profile, and reentering the dir fixes it. <attila_lendvai>so, are people here using direnv? if not, what else? just plain old `guix shell -D guix`? (my direnv also makes guile-sodium, guile-eris, guile-fibers available) <MistOf>Back at exploring guix before completely migrating, is there something like a lock file in guix? And also, what is the nix option's equivalent in guix? <MistOf>Have been meaning to explore a modular setup and how I can make it work in guix (host based too) <rekado>attila_lendvai: for Guix work I use "guix shell -D guix" <rekado>I do use direnv for other projects, though. <rekado>MistOf: what do you mean by lock file? <rekado>MistOf: and what do you want when you say "nix option"? <MistOf>so for a flake.nix file we can generate a lock file that retains the different channel commits for us to make the system reproducible (as in installing the exact same version on all our hosts) <rekado>we do that with "guix describe -f channels", which prints the effective Guix version in a format usable by "guix time-machine -C channels.scm" <jakef>rekado: amazing comments on that PR, thank you sir! <efraim>I thought about using direnv but I mostly just work on guix <janneke>ACTION plunges into makefile hacking, reliving some old lilypond memories <janneke>and dreams of a guile make/build system that doesn't cache everything and their mother on disk <janneke>doc/local.mk:304: error: '#' comment at start of rule is unportable <theotherone>Hi, I am having trouble with an HP printer (7740 OfficeJet). The CUPS WebInterface discovers the printer and I am able to add it. However I can't print anything, not even a testpage. From my understanding, I only need to the cups-service-type with the hp extension <apteryx>theotherone: you may need the extra filters <apteryx>what's the skribilo job specification on cuirass? <apteryx>the logs say about it: warning: failed to fetch channels for 'skribilo' because ""commit ~a lacks a signature\n" arguments: ("76d411844466c9248c929452d6991298d110b945") <janneke>apteryx: i'm preparing a patch set to build a reprocucible source tarball <janneke>i was almost ready to send v1, but civodul already had a good comment <janneke>just fixed running `make dist V=2', will push that fixlet in a moment <apteryx>I see a lot of "ERROR: Clock skew detected." on the build farm, detected by meson; what could this mean? <apteryx>that the time sync daemon is not running or working, perhaps? <jpoiret>apteryx: we've already had this a couple of days ago, where the builds were failing because the unpacked files were older than the tarball itself or something <podiki>apteryx: i was noticing yesterday on some mesa-update builds <podiki>all were on hydra 128 if i remember <podiki>restarted those builds and all was fine (and locally) so something with hydra 128 <cbaines>there isn't an easy way to get backtraces for Guix test failures is there? <civodul>apteryx: i suspected a while back that ntpd stopped working (on Guix System) <cbaines>ok, luckily removing the test wrapping and just running the file provided one <civodul>yes, that’s what i do too (embarrassing :-)) <podiki>I believe lfam checked the clock on hydra 128 yesterday and it looked fine <MistOf>Going to ask again since I went afk for a bit and missed the messages, is there some sort of alternative to nixos module option? Or does guix not provide module files for configuring certain applications? I am thinking of something similar to what can be found in https://search.nixos.org/options?query=firefox or home-manager <zamfofex>I have no idea about what “NixOS module option” means. <MistOf>apologies for not explaining it properly, but it is something like linking the original setting in the program config language to a nix setting that we can enable like `programs.alacritty.settings.window ...` <MistOf>zamfofex what you sent is something similar to nixpkgs override <thaenz>There's a limited amount of those configuration thingys <MistOf>thaenz yes! Is there some sort of search or place people can contribute to these configurations? <MistOf>I see that there is no reason for their existence tbh, but sometimes it's cooler to do it the lisp way xD <MistOf>Do we have a matrix bridge here? Sucks to not be able to navigate history tbh... <MistOf>OH! That would be very helpful, thanks for linking them! <thaenz>And I thought I had a search engine for finding those configurations but nope <thaenz>You'll have to go into the info pages <MistOf>I wonder if they have one general format that they could be grouped under, for example in nix we do `services = { emacs = { ... }; };` or `programs = { emacs = { ... }; };` and whatnot <MistOf>Because why`home-bash-service-type (home-bash-configuration` instead of (service bash (config ( ...`? <NowAUser-76>I am trying to get a better grasp of some of the Scheme definitions and was wondering about the following: <NowAUser-76>According to the documentation, define-module is defined as: <NowAUser-76>Why is it (ice-9 popen) and not something like `(ice-9)? <db48x>NowAUser-76: that would work too <NowAUser-76>So is ice-9 a function? Or is this some Lisp macro magic happening? <freakingpenguin`>(define-module (ice-9)) would appear in ice-9.scm, (define-module (ice-9 popen)) would appear in ice-9/popen.scm. <NowAUser-76>Do you by chance have the place where define-module is defined? <NowAUser-76>freakingpenguin`: That's what I wanted to confirm. Thanks! <db48x>that's correct; it's a macro <db48x>NowAUser-76: incidentally, you don’t need the Guile source to confirm that sort of thing. In the manual, macros are always introduced as “syntax” instead of “function” or “scheme procedure” <apteryx>has someone an opinion on including nss-certs out of the box? apparenly guix itself fails to update when it's missing (though I haven't checked), per #62026 <efraim>how much does it increase the size of the image? <efraim>other than that it's something that's needed by just about every system <apteryx>probably just its own size, it's data <efraim>IIRC the argument against it is to allow providing your own certificates but I've never heard of anyone actually doing that <apteryx>and if someone was knowledgeable enough to do so they could probably manipulate at the API to remove the nss-certs package and replace it with one of their own. <efraim>I have it added to every one of my OS configs <ieure>I don't have it in any, but I assume something ends up pulling it in. <ieure>nss-certs is small, but takes ages to build. Not sure if that's a consideration here. <apteryx>it's like fonts, it's typically left out of packages as policy <ieure>It has an exhaustive test suite which takes like 45m to run. <efraim>it looks like I disabled the tests on ppc32 with a note they take more than 30 hours to run <apteryx>it basically runs a tiny C program to massage the data files. <efraim>22s normally means it was already built and downloaded a substitute <apteryx>efraim: OK, I'll perhaps bring it to guix-devel to give a chance to everyone to tip in <ieure>apteryx, Hmm, I'm definitely thinking of nss, which is the same source as nss-certs. But maybe nss-certs has a different build process which doesn't run the tests. <ieure>I have a patch out which updates nss, since my Librewolf package depends on newer nss than is in Guix. <efraim>looks like that would be me too, mixing up nss with nss-certs in the test duration <ieure>Opened 2023-11-28! Maybe it'll merge... some day <apteryx>ieure: oof. had you had it tested well, for dependent packages such as icecat and icedove? <efraim>I'm showing ~14000 packages rebuilt from nss <apteryx>yeah, it's definitely a core-updates one <apteryx>ok, that may (or may not) explain why nobody picked it up ;-) <ieure>apteryx, It's one of two patches, there has been review on the other stuff, just... very intermittent and bursty. <apteryx>a security branch could be nice, perhaps <apteryx>where all the *tls something gets updated <ieure>I'd patch LW to depend on the older nss and pull the nss update into core-updates... whatever... anything... just merge dangit <apteryx>if you promise to review 2 other packages waiting on the tracker, I'll do it ;-) <ieure>apteryx, I've actually reviewed several that I saw sitting around. <apteryx>alright. then I have no excuse. did you put some tag to make these easy to find? <ieure>There's a bunch of Clojure patches I've been meaning to sort through also, but there's several with conflicting and/or stale changes. <apteryx>see info '(guix) Reviewing the Work of Others', in particular the use of a reviewed-looks-good usertag attributed to the 'guix' user. <ieure>clojure-updates branch might be a good idea, the state of that is not great. <apteryx>I think you can do that via the QA web interface nowadays, haven't tried yet. <ieure>apteryx, I can check my personal email later, but I'm on the work box. <ieure>Yeah, I used that, it spits out an email template thing. <ekaitz>hi, gcc-toolchain provides libgcc_s, right? in which of its outputs? <apteryx>sent a mail to guix-devel about nss-certs in base packages <podiki>ekaitz: perhaps part of gcc:lib? <ekaitz>what I don't know now is why the package I'm doing is talking about it, as we specifically patch gcc to find it first <ekaitz>because now it's just impossible to: guix shell gcc:lib <podiki>for 63393 i think just adding gcc:lib to gcc-toolchain:out is simple and easy and is what people expect <podiki>guix shell -e '(list (@@ (gnu packages commencement) gcc) "lib")' <podiki>but it doesn't quite roll off the tongue does it <podiki>what I'll say to that issue/patch: patch 1/2 LGTM (though i'm not familiar with the details of what we do for making gcc-toolchain); then send a patch just adding gcc:lib to gcc-toolchain without adding or changing other outputs <apteryx>hm, I just tried: guix time-machine --url=https://gitlab.com/Apteryks/guix --branch=qtbug-123747 -- build qtdeclarative --keep-failed hoping to give this to a Qt dev to reproduce a problem, but it fails with: guix time-machine: error: could not authenticate commit 4d994f98a49e1a6e58b9b0b512a05efc1c431a50: key 6840 722E EEE4 D3A6 4EE5 3EAC 6AAC 1963 757F 47FF is missing <podiki>a keychain branch update missed? from new contributors in last year? <ekaitz>podiki: btw maybe you can help because this is driving me nuts: libgcc_s.so.1 must be installed for pthread_cancel to work <apteryx>I'm trying this from a very old guix I had laying around another machine <apteryx>from commit 19fe24c5b978a16cbca3cddbfa3ab9d1ee2c68f2 <ekaitz>that's the error, but if i search it i don't find it anywhere in the codebase <podiki>ekaitz: sorry, no idea! does whatever it is actually try to load libgcc_s? <podiki>apteryx: that would be my guess, it is missing the guix-authorization of the newer keys added since <ekaitz>i think it's clang trying to load that, but it's searching the .1.so instead of the .so...? <podiki>but this has inspired me to procrastinate "real" work and send a patch for gcc:lib issue <podiki>since i basically answer a question about it nearly every day here, it would be worth it for selfish reasons alone! :) <dariqq>is anyone using emacs daemon with Gnome 44? I can only seem to get a -nw session and not a new window when started with user shepherd <podiki>apteryx: was the keyring branch updated on that gitlab repo? though i'm not sure what keys from where are being checked <dariqq>Also this only occurs when using Gnome+Wayland. On Xorg it works. Also restarting the shepherd service does not change anything. <jlicht> Could we perhaps replace the `module-autoload!' for (charting) in (guix scripts size) by a #:autoload entry in define-module by now? <podiki>this time i'm so quick the new source isn't available on the mirrors yet.... <apteryx>podiki: oh, didn't remember that's how it works (pulling the keyring branch from the git url guix repo) <podiki>i don't know how it works for time-machine but i guess you found out? it checks on the given url's keys rather than the current guix keys i guess? <podiki>i only remember this because i've forgotten to fetch that branch sometimes after we get a new committer and get those errors locally <apteryx>ACTION retries the earlier guix time-machine command after having updated the keyring branch on that repo <podiki>CVEs in xorg server and xwayland, but i can't find the source for xorg-server yet <rekado>I think we forgot about the python-team branch <podiki>speaking of authenticating, my local guix has 73k commits to authenticate.... <podiki>rekado: thanks! i was involved in some patches after last core-updates and then sort of fell off while others did the work (was it Lars that has all the pyproject build system updates there?) <podiki>ACTION waits for new xorg-server sources to release; xwayland security update ready <jlicht>bah, more recent versions of llhttp (as needed for more recent Node.js packages) need yet another intermediate version of Node.js to stick around indefinitely :/ <rekado>ACTION pushed the rebased python-team <janneke>thanks, feared it might be just a tad too much :) <ghisvail>I am trying to install Guix with KDE + SDDM on Wayland, but I am getting an error about a duplicated xorg configuration. <podiki>open source developers love bug reports from guix with this one simple trick! <ghisvail>Can anyone point me toward a working config so I can learn what I am missing <podiki>ACTION pushes xwayland security update; xorg-server still doesn't have sources available <Franciman>is there any example guix home configuration using sway? <janneke>civodul: sorry for the warnings, possibly something can be done about that? also the difficult make-function and the silly target names, dunno -- answered by email, let's see if someone has some ideas <civodul>janneke: no worries, these are more like icing on the cake <civodul>i’m happy to see i can still learn about Automake :-) <janneke>civodul: now that's a nice perspective! <civodul>janneke: so, failure to reproduce, but there’s a simple explanation <civodul>which is that i don’t have the exact same commits <janneke>civodul: you've got mail -- try origin/wip-tarball maybe? <podiki>apteryx: patches for xorg-server? they say there is a new version out (4 CVEs) but i don't see the sources on their releases. presumably there is a git tag but i didn't check <civodul>janneke: that talk by Holger is amazing <ghisvail>podiki: thanks for providing your config. I was missing the explicit delete of GDM with `modify-services` <apteryx>ACTION will merge the qt-team branch shortly <janneke>freakingpenguin: thanks for trying; could you run diffoscope on our tarballs to find out which files differ? <civodul>janneke: i like the “writing our history” bit; i think that’s often missing in free software <civodul>people spend years or decades on a thing, make friends and colleagues, and then the whole story is lost forever <apteryx>cbaines: is qa overwhelmed? I can't use the web interface (it's irresponsive) <janneke>civodul: thanks for the pointer, guess i'll rewatch it some time soon <freakingpenguin>Apparently there's /a lot/ of things different, probably something wrong with my process. <podiki>(i believe it is "new" compared to last mesa-updates build from January; there are a few real breakages in there i'm seeing and fixing) <janneke>freakingpenguin: i tried a half-baken `clean some usual suspects', but doing something like <freakingpenguin>Somehow my tarball is smaller than your tarball by ~1M so I'm assuming I did something terribly wrong. <janneke>there are some things (subtleties?) that elude me wrt the po/pot/texi/info creating <janneke>freakingpenguin: or you rediscovered lossless compression :) <janneke>(or /me and added 1M of binary backdoors, har har har) <freakingpenguin>I had to kill diffoscope because it flooded my shell with so many lines Emacs started freezing haha <janneke>yeah, it doesn't seem to have a --name-only or --brief option? <lfam>I usually output diffoscope to a report file. No matter what, the output will be huge <janneke>you can redirect to > log and just look at the header which lists the file differences <lfam>`diffoscope --html report.html --exclude-directory-metadata=yes` <ghisvail>looks like there is one of the KDE dependency which fails to build <apteryx>saw that one, seems a matter of ignoring a test which expects mime data to be something and it slightly changed <freakingpenguin>I think my problems might be related to shell -C and locales. Some characters are replaced with ?? and some dates are off by a day. janneke would emailing the report be useful? <janneke>if you have found other problems, please send <apteryx>ieure re "I'd patch LW to depend on the older nss" either this or carry a nss-3.97 variant used by librewolf <apteryx>the nss-3.97 variant sounds easier and is more future looking <ieure>Yeah, I'll hack on that. It needs 3.98 now, I think because of the Firefox 123/124 CVEs. <apteryx>lilyp: I think (gnu packages wasm) may actually make sense, despite already (gnu packages web) existing (and being 10k lines long) <apteryx>wasm seems to be developping its niche where it has uses outside of the web <ieure>apteryx, I think you're looking at the earlier version(s) of those patches, I backed out the WASM stuff because it was going to be a lot of work. <ieure>I personally agree that (gnu packages wasm) makes sense, it's WASM-targeting toolchain stuff. <apteryx>I think if you break the wasm packages in individual commits and keep them in (gnu packages wasm), we could then review them <apteryx>run 'guix lint' on them to catch the easy problems <ieure>apteryx, Well. I didn't write those, I lifted them from nonguix, and don't have a great understanding of all the concerns. <ieure>There's some comments about the base guix clang stuff needing to be improved to make the wasm stuff work well, I don't really know what's involved there. <podiki>xorg-server updated (security fixes) <podiki>setting a new speed record, quicker than xorg pushed their sources and had to wait! <ieure>Seems to be working well, I'm running it daily on my Guix testbed machine. <apteryx>if it's working there's probably not big technical problems with it; it's probably mostly down to stylistic issues and conventions such as changelog commit messages and one package per commit <apteryx>if you could fix that (along obvious 'guix lint' problems such as too long line width), I think it'd be easier to review as a separate submission <apteryx>personally I'm OK keeping the packages in (gnu packages wasm) <ieure>apteryx, WASM stuff isn't in the latest version of the patch. The requirements to accept it which were presented to me (adding it in other browsers, too) wasn't something I was willing to take on, so I backed it out to move the stuff I care about forward. <ieure>The options were for me to add it to a bunch of other browsers, or take it out of LibreWolf, so I chose the latter. <ieure>I do not understand why this is the requirement, and I wish it wasn't the case. But that's what I was told. <ieure>Just want LibreWolf in Guix so there are more options. <apteryx>ieure: I think Clement's point was mostly to 1. split wasm packages to separate submission and 2. enable it for one browser at a time 3. in every browser that supports it <apteryx>I think 3 is nice to have but shouldn't be tied to your submission <ieure>apteryx, I specifically asked for clarification and was specifically told that I, personally, would have to add it to the other browsers as a condition of it being accepted at all. <ieure>Since I don't want to do that and it's taken months and months just for this one package, I backed it out instead. <ieure>I wasn't really signing up for a year-long project to enable WASM in every browser in Guix when I sent in a patch. <apteryx>I'd say point 2. of info '(guix) Reviewing the Work of Others' offer some advice on that <apteryx>"do not change the scope of the work being reviewed" <apteryx>to get the ball rolling, let's try this at first: 1. add an nss-3.9 variant, to be used by librewolf and 2. add librewolf itself, as in your v6 <apteryx>(but if you are serious at doing so you can already look into splitting it up as mentioned earlier and submit it to guix-patches as a separate submission) <ieure>I agree, it would be valuable. I'm not sure I'm the right person to get it in there, since I didn't write the patches and don't have a good grasp on the domain they operate in. <ieure>They're originally by Pierre Langlois, but he hasn't been reachable via email.