IRC channel logs


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
<sneek>Got it.
<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 file time is too far in future?
<peanuts>"Build 3821982"
<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, you have 1 message!
<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
<jab>lfam: haha!
<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
<Googulator>"decompress", indeed :)
<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 for a while now. But 'ssh; 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
<peanuts>"jbranso/linode-guix-system-configuration: This is my linode Guix System configuration. - Free code hosting"
<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 'ssh'
<jab>that says a very old version of guix is being used.
<jab>but 'ssh' shows a very recent version of guix being used. March 31 2024.
<jab>so apparently 'ssh' is taking me to a different server?
<jab>'ssh' 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'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>Hey jo!
<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
<munksgaard> is returning a 502 for me
<necto>munksgaard, me too
<jakef>hello guix, what's next for progressing this patch?
<peanuts>"Magit autoloads missing in Emacs 29.3"
<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.
<janneke>Guest16: see
<peanuts>"Magit autoloads missing in Emacs 29.3"
<Guest16>peanuts: thanks! I must've pulled right before that patch. I'll pull again now
<peanuts>Guest16: Hi, for comments please contact my maintainers at
<Guest16>peanuts: whoops, browser crashed - not sure if my thanks got through
<peanuts>Guest16: Hi, for comments please contact my maintainers at
<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
<snape>the auto-loads don't work
<peanuts>"Magit autoloads missing in Emacs 29.3"
<jakef>3rd person to bring it up in IRC in the last hour :)
<jakef>2 hours*
<civodul>ah yes, i noticed that too!
<snape>jakef, well I pushed it
<civodul>thank you :-)
<civodul>janneke: that ‘wip-tarball’ branch is a great idea!
<snape>np, have a nice day!
<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
<jakef>thanks snape!
<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)
<civodul> mentions the ‘guix gc’ trick
<peanuts>"Security Updates (GNU Guix Reference Manual)"
<janneke>civodul: ah, that would be nice
<janneke>ACTION will have a look
<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>like the guix.%.texi rule
<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
<janneke>hmm, /me ponders about stem (%)
<janneke>thanks for the ideas anyway!
<jakef>attila_lendvai: when does it error? on startup?
<attila_lendvai>jakef, yeah, it doesn't even start for me
<jakef>it just started for me, hmm
<attila_lendvai>ll `which gedit` => /gnu/store/zj5y9r6cn0mh4j9cglib3302w2csnqc9-gedit-44.1/bin/gedit
<attila_lendvai>that's rather strange...
<attila_lendvai>if i update to and build v44.2 or 44.3 locally, then those binaries work
<attila_lendvai>`guix build --check gedit` is clean
<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
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<jakef>hi rekado, i submitted a PR to guix-science a couple of weeks ago
<peanuts>"Add Geant4 packages. by jakeforster ? Pull Request #36 ? guix-science/guix-science ? GitHub"
<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)
<MistOf>nix option as in someting like
<peanuts>"NixOS Search"
<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/ error: '#' comment at start of rule is unportable
<janneke>stop helping :)
<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
<theotherone>and then it should work. Am I missing something?
<apteryx>theotherone: you may need the extra filters
<apteryx>another cuirass observation: it seems the aarch64 builds are under-represented from (and most aarch64 workers are idled)
<peanuts>"Running builds"
<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>okay, so help2man fails with V=2
<janneke>happy debugging \o/
<apteryx>janneke: what are you pursuing? :-)
<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?
<apteryx>one such example:
<peanuts>"Build log of build #3839326"
<apteryx>from the tFCAhGZw worker
<janneke>that's usually a fair guess
<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)
<civodul>cbaines: nope
<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 or home-manager
<peanuts>"NixOS Search"
<zamfofex>MistOf: Is this what you want?
<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 ...`
<thaenz>Something like this?
<peanuts>"Shells Home Services (GNU Guix Reference Manual)"
<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...
<thaenz>There's logs
<peanuts>"guix IRC channel logs"
<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
<thaenz>I will link it here anyways incase you find it usefull: https://toys.whereis.xn--q9jyb4c/
<peanuts>"Toys / Webring for GNU Guix channels" https://toys.whereis.xn--q9jyb4c
<MistOf>Well.. that sucks
<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 ( ...`?
<MistOf>Cannot edit that one.. lol
<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>syntax: define-module module-name option …
<NowAUser-76>module-name is a list of one or more symbols.
<NowAUser-76>Example: (define-module (ice-9 popen))
<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.
<db48x>it's a name
<db48x>here’s an example:
<peanuts>"gnu.scm - guix.git - GNU Guix and GNU Guix System"
<db48x>and here’s another:
<peanuts>"packages.scm\gnu - guix.git - GNU Guix and GNU Guix System"
<NowAUser-76>Do you by chance have the place where define-module is defined?
<db48x>it’s part of Guile
<freakingpenguin`>NowAUser-76: Pretty sure define-module is a macro. so (ice-9 blah) isn't evaluated like a normal function even though it's not quoted.
<peanuts>"boot-9.scm\ice-9\module - guile.git - GNU Guile"
<NowAUser-76>freakingpenguin`: That's what I wanted to confirm. Thanks!
<db48x>that's correct; it's a macro
<freakingpenguin`>The macroexpansion for it isn't actually that scary, huh.
<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”
<NowAUser-76>db48x: Good to know, thanks!
<db48x>you’re welcome
<apteryx>another meson detected clock skew:, from a different worker: c6qn6tXZ
<peanuts>"Build log of build #3839375"
<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
<peanuts>"[PATCH] %base-packages-networking: Add 'nss-certs'"
<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
<apteryx>so, 0.3 MiB
<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.
<apteryx>it shouldn't be pulled by anything
<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
<efraim>I think we add it in
<apteryx>ieure: I think you are confusing packages, it took 22 s to build on an armhf-linux machine:
<peanuts>"Build 1712845"
<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
<efraim>also a good plan
<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
<ieure>apteryx, Nope! lol
<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
<apteryx>gnutls, openssl, nss, etc.
<ieure> if anyone's inclined to push this forward. I'd really like to get this merged, tired of recompiling it myself.
<peanuts>"[PATCH 0/5] Add LibreWolf"
<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?
<ekaitz>i can't find it
<apteryx>sent a mail to guix-devel about nss-certs in base packages
<ekaitz>(or is it in gcc:static only?)
<apteryx>did you try 'guix locate' ?
<podiki>ekaitz: perhaps part of gcc:lib?
<ekaitz>podiki: yep! just found it!
<podiki>which is my daily reminder of
<peanuts>"[PATCH 0/2] Fix and gcc-toolchain"
<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>(i discovered this later)
<ekaitz>yup I like that patch
<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
<ekaitz>too much, yeah
<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= --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
<peanuts>"Maxim Cournoyer / GNU Guix ? GitLab"
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<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: 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>Nov 08 2023 03:52:04
<apteryx>from commit 19fe24c5b978a16cbca3cddbfa3ab9d1ee2c68f2
<ekaitz>that's the error, but if i search it i don't find it anywhere in the codebase
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<apteryx>I guess I need a newer 'guix'
<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 instead of the .so...?
<ekaitz>* .so.1
<podiki>:-| don't know
<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! :)
<ekaitz>podiki: good! thanks!!
<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
<apteryx>podiki: weird, I upgraded with 'guix pull', re-ran guix time-machine --url= --branch=qtbug-123747 -- build qtdeclarative --keep-failed and got the same error
<peanuts>"Maxim Cournoyer / GNU Guix ? GitLab"
<apteryx>ACTION afk
<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.
<podiki>update sent to simple patches, hopefully we can apply it soon finally!
<peanuts>"[PATCH 0/2] Fix and gcc-toolchain"
<jlicht> Could we perhaps replace the `module-autoload!' for (charting) in (guix scripts size) by a #:autoload entry in define-module by now?
<jlicht>Given (Guile issue) seems to be closed by now
<peanuts>"psyntax defeats autoload"
<podiki>weee more CVEs in xorg....
<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
<apteryx>worked. thanks!
<podiki>i'm on fire
<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
<rekado>just rebased it
<rekado>and when I say "we" I mean "I".
<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>civodul: wip-tarball:
<peanuts>"[PATCH 0/7] Reproducible `make dist' tarball in defiance of Autotools and Gettext"
<civodul>i like the title :-)
<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.
<apteryx>podiki: guix time-machine applied to issue reproducers:
<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
<tricon>podiki: haha
<civodul>ACTION tries “make dist”
<podiki>ghisvail: here is my messy config, not with kde but with sddm and an xorg config. i removed the default gdm.
<peanuts>" at master ? podiki/ ? GitHub"
<janneke>ACTION crosses fingers
<podiki>ACTION pushes xwayland security update; xorg-server still doesn't have sources available
<apteryx>you mean patches?
<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: oh!
<civodul>silly me
<civodul>janneke: that talk by Holger is amazing
<peanuts>"Reproducible Builds - the first ten years"
<civodul>hadn’t seen it before
<freakingpenguin>civodul: I'm also having a go at it and made the same mistake
<janneke>civodul: oh yeah, liked it a lot
<ghisvail>podiki: thanks for providing your config. I was missing the explicit delete of GDM with `modify-services`
<freakingpenguin>janneke: Didn't match, this is what I ran.
<podiki>ghisvail: glad to help!
<peanuts>"debian Pastezone"
<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)
<podiki>if anyone is looking for recent breakage on master to fix, seems a lot of the "newly" failed on mesa-updates is from master:
<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
<janneke>git clean -fdx -- '.am*' po doc
<janneke>might help a lot; dunno
<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
<civodul>ACTION sent a diffoscope analysis
<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>freakingpenguin: not if it's covered by civodul's report --
<peanuts>"[PATCH 0/7] Reproducible `make dist' tarball in defiance of Autotools and Gettext"
<janneke>if you have found other problems, please send
<janneke>so, nice try, more tomorrow!
<janneke>ACTION -> zZzz
<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
<apteryx>forward 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>apteryx, I did do a bit of hacking on the wasm stuff, but mostly just factoring out the firefoxen bits. Wrote a function that returns a package variant with wasm sandboxing enabled:
<peanuts>"atomized-guix/atomized/packages/wasm.scm at main - ieure/atomized-guix -"
<ieure>Seems to be working well, I'm running it daily on my Guix testbed machine.
<ieure>It's stuff like and which I'm not up to speed on.
<peanuts>"atomized-guix/atomized/packages/wasm.scm at main - ieure/atomized-guix -"
<peanuts>"atomized-guix/atomized/packages/wasm.scm at main - ieure/atomized-guix -"
<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>(for the wasm stuff)
<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>we can look at enabling wasm later
<ieure>Sure, I can do that.
<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)
<apteryx>I think it'd be valuable
<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.