IRC channel logs

2024-09-05.log

back to list of logs

<oriansj>(explicitly done as possible)
<aswjrisp>oriansj: I like the sounds of that. After I get sway working I will spend some more time reading your config.
<aswjrisp>oriansj: is the file name x200.scm refering to a corebooted thinkpad x200?
<oriansj>aswjrisp: librebooted thinkpad x200
<ieure>I have one of those I ought to LibreBoot.
<ieure>I also think T440p can be LibreBooted these days? At least Corebooted. I patched the BIOS to remove the allowlist and enable the advanced menu, but haven't gone further.
<ieure>T440p is still plenty fast to daily drive, especially if you rustle up a quad CPU. Thermals and battery life aren't great, though.
<Isaz>how long of a battery life do you get?
<aswjrisp>oriansj: I think I am getting closser. Now when recnofiguring I get "guix system: error: supplementary group 'seat' of user 'name' in undeclared". I do not see it declared in your config. Do you know how to deal with this error.
<aswjrisp>Looks like I have dealt with that error by explicitly listing all the groups.
<aswjrisp>Now I have a new error when reconfiguring "guix system: error: service 'term-tty1' provided more than once".
<oriansj>aswjrisp: well the one up side of being explicit is every error becomes a simple problem to fix and tweak. Otherwise you'd have to figure out where things are coming from and do things implicitly correct.
<oriansj>for example that is part of %base-services
<oriansj>which you can find defined in guix's checkout
<oriansj>but that error really wouldn't point you in that direction.
<aswjrisp>oriansj: Looking at your config I notice that you are not using %base-
<aswjrisp>services or %desktop-services.
<aswjrisp>You have explicity stated all the services.
<aswjrisp>I think I will change my config so it is like that borrowing from you config and parts of %base-services.
<aswjrisp>Then hopefully in the process I will eliminate this current error.
<jfred>I've noticed that guix has to compute a derivation each time I run 'guix time-machine' with the same list of channels, is there a way to avoid that?
<mange>Is there are any committers around, there are some patches to fix gd/PHP around hoping to be pushed: https://issues.guix.gnu.org/72943#6
<mange>s/Is/If/
<aswjrisp>oriansj: So that previous error is gone now that I have removed %base-services. But now I have the error "guix system: error: the group "guixbuild" specified in 'build-users-groups' does not exist". You have a comment in your config about this group.
<oriansj>aswjrisp: weird; build-users-groups isn't listed anywhere in the guix package source tree
<aswjrisp>oriansj: I think I had broke my system some how. I have rolled back to a previous generation and will see if that allows me to regonfigure.
<aswjrisp>Doing a roll back to a previous generation worked. I can continue working on my config as I can reconfigure again.
<jaft_r>🎉
<aswjrisp>jaft_r: yes indeed. Hooray for Guix.
<meaty>hello! does guix have a mechanism to de-clutter my home directory from loose dotfiles?
<meaty>specifically I'm trying to get rid of things like .Xdefaults, .zprofile, etc. that seem to have been put there by guix
<meaty>can guix make an exectuable "hallucinate" that its dotfiles are actually in the home dir when really they're in a more modern place
<mange>Not that I know of, but you can do things about it. For these specific examples, https://superuser.com/a/420890 and https://zsh.sourceforge.io/Doc/Release/Files.html#Files (specifically $ZDOTDIR) might help?
<aswjrisp>meaty: are symlinks good enough?
<meaty>seeing as most are generated from the guix config I think it would just be unnecessary complexity I think
<meaty>aswjrisp: i mean there is already a gnu stow service i think if i want to go that route, but i think I'll just accept it
<meaty>also does anyone know why the `environment-variables` field of home-bash-configuration can't set PS1, it has to be in the `bashrc` field
<mange>What are you trying to achieve, meaty? Like, I assume just moving the files is not the total thing you're looking for?
<meaty>mange: I wanted the home directory to be empty of dotfiles on a whim, im not attached to that quandry
<oriansj>meaty: support for the XDG standard is hit and miss with applications; not to mention shells generally predate the standard and refuse to support it.
<oriansj>you can manually configure many programs (details here: https://wiki.archlinux.org/title/XDG_Base_Directory ) but you'll still end up with a few dot files remaining.
<meaty>oriansj: I've been going through that page and doing just that lol
<aswjrisp>meaty: I have left all my dot files in /home/user/ and made another directory /home/user/mine/ where all my stuff goes and there are no dot files in it. I think it is close to accomplishing what you are looking to accomplish.
<meaty>but now I wonder if it's really worth it outside of just Recreational Configuring(R)
<meaty>aswjrisp: that may be the solution
<meaty>I've been thinking of adopting some esoteric XDG setup where documents is my real home directory and the media-specific dirs (images, video, music) all point to a separate "media" server, and the files are symlinked to from documents
<meaty>maybe the right topology could give 'desktop' a purpose
<elpogo`>how can i tell which guix (channel) version a particular profile was built with?
<oriansj>meaty: well XDG can be useful for cleaning things up
<oriansj>elpogo`: look at the provenance
<oriansj>it should show the repository, branch and commit
<elpogo`>oriansj: are you referring to "guix describe"? i know guix pack and guix system have a --save-provenance option, but guix package does not.
<aswjrisp>oriansj: I have a config that is explicit for packages and services. The services section is a combination of the %base-services and the seatd and greetd from your config. It can be reconfigured successfully.
<aswjrisp>The problem I am having now is that when I run saw I get an error message that looks to be related to mesa.
<aswjrisp>The sway error output is https://termbin.com/4udk
<aswjrisp>The error message says that i915_dri.so is missing. When I go into that directory it is missing.
<aswjrisp>guix locate i915_dri.so tells me that it is from mesa 21.3.8 but guix search tells me that the current version of mesa is 24.0.4 which is what I have installed.
<aswjrisp>This looks like a mismatch in package versions. I am not sure how to deal with this issue. Any suggestions?
<aswjrisp>Maybe I could use mesa 21.3.8
<aswjrisp>Is there a way to specify the use of a previous version of a package.
<aswjrisp>s/saw/sway/
<aswjrisp>I am going to try a pull, reconfigure and restart to see if that fixes it.
<mange>elpogo`: If you look in the profile's manifest file ($PROFILE_DIR/manifest), does it have provenance entries? Otherwise guix home and guix system store provenance information in provenance ~/.guix-home/provenance and /run/current-system/provenance respectively (or the provenance files in their /var/guix/profiles/... directories).
<elpogo`>ah. thanks mange. I see each package i installed has a seperate provenance entry, which makes sense because they might have been installed at different times. thanks for the pointer
<fireking04>Hi, is anyone able to execute ~guix shell python-robotframework~ properly? I try it but when I do, the ~python-pygithub~ fails during the ~check~ step. I checked the logs and its a bunch of FAILED test cases. My guix channel is on commit ed95ddeb1e58c314f2e22b4cd35986042f3e2f21.
<mange>Looks like it's failing on CI, too. robotframework https://ci.guix.gnu.org/build/5606214/details and pygithub https://ci.guix.gnu.org/build/5545513/details
<fireking04>got it, didn't check that one. Thanks
<aswjrisp>I have a slow internet connection. So I can see things as they download during a reconfigure. I just watched it download coreutils-9.1 twice one after the other. Why would a reconfigure need a package to be downloaded two times?
<mange>Looks like "guix shell python-robotframework --without-tests=python-pygithub" might work, but the robotframework tests take a while. You could skip them, too, in the same way.
<aswjrisp>It said the first one was 2.5MiB and the second was 2.4MiB.
<mange>aswjrisp: Whenever I see things like this that seem strange, I assume it's due to grafts. I can't fully explain why it happens, though.
<aswjrisp>mange: another guix topic for me to learn about, grafts.
<fireking04>Okay. Will try this. Thanks mange. New to guix here so didn't know this.
<mange>Yeah, they're dynamic rewrites of dependencies. It makes it cheaper to deliver ABI-compatible security updates by rewriting store references in the output (and not redoing the whole compilation). This is a dynamic property, so Guix needs the substitute in order to work our what to graft. Or something like that.
<mange>The tests for python-robotframework just finished, and I'm in a shell now, fireking04. Hopefully it works for you, too! Now that we know it can pass its tests, you can probably just use --without-tests=python-robotframework to save some time.
<fireking04>mange: I got it. It works fine now. Thanks a lot!
<podiki>fireking04 and mange: saw the above messages, I have a fix for pygithub; building robotframework now
<podiki>fireking04 mange: fix pushed, thanks for pointing it o ut
<mange>While you're here, podiki, do you have any time to have a look at a fix for gd/PHP that I'd love to get pushed so I can rebuild my servers on master? https://issues.guix.gnu.org/72943#6
<podiki>not at this moment (late here) but i'll try to look tomorrow. in a quick glance, not sure what is better (restoring patch might mean needing to maintain it while we do propagate for requires.private...but propagating can cause issues)
<mange>No worries. Yeah, it's a bit unclear what's best, but I ran into mesa earlier today which uses propagated-inputs, so that's at least one data point in support of propagated-inputs.
<podiki>yes we do propagate inputs for requires.private (not sure if always, but that is a prime reason i know of to do it)
<podiki>i'm a little more wary here since it they are very common packages and some more user-facing ones. not sure if that would be more likely to cause an issue or not. hopefully someone more knowledgeable on that front can chime in
<podiki>i would ping here and/or guix-devel in a few hours, during more peak europe time
<podiki>ACTION zzz
<mange>Yeah, unfortunately my time zone doesn't work as well for then. I'm sure someone will have a look eventually. :)
<civodul>Hello Guix!
<Rutherther>Hello
<meaty>hello!
<meaty>how can I get one package to take precedence over another? specifically I'm trying to use the perl-based 'rename' command from the package of the same name but manpages and --version keep indicating the util-linux version
<meaty>wait nevermind i guess
<Lumine>Morning #guix
<civodul>meaty: the one that comes first in your profile (or manifest, etc.) “wins”
<fnat>Anyone familiar with Go that might be able to see why this fails 'guix import go --recursive github.com/Azure/azure-sdk-for-go/sdk/storage/azblob'?
<fnat>This is how the dependency is listed here: https://github.com/restic/restic/blob/master/go.sum#L24C1-L24C60
<fnat>By browsing the azblob repository, it'd seem to me that the project is not directly hosted at the path above but in a subfolder - this might explain why the import fails?
<fnat>Haha, I haven't gone through it yet, but I'm already laughing... https://issues.guix.gnu.org/52362 this came up as top result when searching guix import error... Azure seems to be the culprit again, go figure.
<civodul>fnat: oh but there’s a fix there that just wasn’t applied, right?
<yelninei>after core-updates i seem to have problems offloading to a childhurd with remote daemon logging: unexpected build daemon error: stoi.
<civodul>yelninei: oh right, i have that too :-/
<fnat>civodul: Not sure if the patch was ultimately applied. Will investigate.
<civodul>neat
<yelninei>civodul: running the daemon just as root works, is there something the shepherd service does different
<civodul>weird thing is that the childhurd test passes: https://ci.guix.gnu.org/build/5484566/log
<civodul>oh but that might be pre-merge
<civodul>yelninei: the environment variables may be different
<civodul>the locale in particular
<civodul>is stoi locale-dependent?
<yelninei>i found a mention of stoi in 21deb89e287b5821975544118bf137562a91d4e1 which suggests loclae problem. But glibc and glibc/hurd are the same now i think
<civodul>the service has "LC_ALL=en_US.utf8"
<civodul>right
<civodul>i think the fix is to remove the GUIX_LOCPATH thing and set LC_ALL=C.UTF-8, which is guaranteed to exist now
<civodul>though i’m not sure what the problem is in the first place
<civodul>yelninei: what if you run it manually with LC_ALL=en_US.utf8 ?
<yelninei>with or without GUIX_LOCPATH?
<civodul>both
<yelninei>both result in the same stoi error
<civodul>do you see more output on the console?
<fnat>Re the go import error, it seems there's actually multiple patches as explained here https://issues.guix.gnu.org/issue/63647#14-lineno45
<fnat>Possibly none of them has been finalised and applied in the end.
<civodul>Guix style :-)
<fnat>:)
<civodul>fnat: maybe you can ping Simon in the relevant issue?
<civodul>i’m not sure if Timo is still around
<fnat>Yeah, sure, happy to do that.
<yelninei>no and --debug is also not helpful
<yelninei>also setting LC_ALL=C.UTF-8 (and GUIX_LOCPATH) produces the same stoi error
<pelzflorian>fyi the guix website 1.4.0 and latest manuals and cookbook are all inaccessible with 404
<pelzflorian>i’ve pushed a fix to version-1.4.0 branch to fix dealing with zstd compression
<pelzflorian>but cookbook and latest had the zstd fix in doc/build.scm already
<cbaines>pelzflorian, can you clarify what URLs aren't working?
<pelzflorian>they are still 404
<pelzflorian> https://guix.gnu.org/en/manual/devel/
<cbaines>right, I think the correct URL is https://guix.gnu.org/manual/devel/en/
<pelzflorian>ohh thank you
<pelzflorian>then the redirect / rewrite rule in maintenance.git might have disappeared?
<cbaines>it used to be that if the path ended with /manual, then you'd get the manual (e.g. /foo/manual would work)
<cbaines>but that changed recently https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=3de9f2119371038650045946ba6e7de6e90f68e5
<pelzflorian>this breaks the links on the website
<Rutherther>Yesterday someone changed it since the urls could start with anything as only the last parts were matched
<cbaines>Ok, I guess they relied on that behaviour
<cbaines>someone was me, I was/am someone
<Rutherther>Oh, okay
<Rutherther>I will remember you from now on :)
<pelzflorian>should we revert the rewrite change, or get rid of the old URL cruft?
<cbaines>I'm still trying to work out what the authoritive URL is...
<cbaines>it seems like /manual/en/ should be the path
<pelzflorian>yes
<pelzflorian>Google, Duckduckgo use it
<pelzflorian>other manual links on the website use it
<cbaines>but here the locale is prepended https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/apps/base/utils.scm#n117
<cbaines>although the manual-url helpers in that same file append the locale
<pelzflorian>the manual is special
<cbaines>maybe I'll just add another keyword argument to that helper for now...
<pelzflorian>why? no
<cbaines>well, to get it to append rather than prepend the locale
<cbaines>that seems preferable to creating a guix-url-but-append-the-locale helper?
<cbaines>maybe a 4th manual URL helper is also an option, a manual-root-url
<pelzflorian>preserve the old lingua code in URLs; they are used in cookbook and perhaps outside websites and blog
<cbaines>what do you mean by preserve?
<pelzflorian>that https://guix.gnu.org/de/help/ must remain valid
<pelzflorian>not sure about https://guix.gnu.org/de/manual/fr/html_node/Invoquer-guix-time_002dmachine.html
<cbaines>I'm not suggesting changing that, I'm still just trying to work out how to fix the broken manual links in the header
<fnat>Is it possible to have 'mumi compose' to pick up and reply to a specific message in a thread?
<futurile>fnat: doesn't look like it
<pelzflorian>@cbaines: thank you for repairing the website so quickly; this #:append-locale is a great fix; it works in a local rebuild of the website
<pelzflorian>could you follow up with a fix for cookbook as well?
<futurile>Q: has some change to pyproject-build system or SSL - I can get python-apprise to stop failing by turning some tests off that use python-paho-mqtt, but neither of these packages have been touched in ages so it's very odd that this fail's started happening
<fnat>futurile: Thanks for checking! I can probably just copy and paste-as-quote, so that's fine. :)
<cbaines>ah yeah, I'll fix the cookbook link...
<pelzflorian>@cbaines: in append-locale, we would need to special case pt-br and zh-cn (there is no zh-tw)
<pelzflorian>instead of pt-BR
<pelzflorian>@cbaines: regarding append-locale, and ko and sv have no manual but only a (mostly empty) cookbook
<pelzflorian>needs more thought
<pelzflorian>i still would not revert
<pelzflorian>i'm offline now and maybe i will not see IRC messages soon
<pelzflorian>goodbye
<cbaines>hmm, the website links to https://guix.gnu.org/manual/zh-CN/
<cbaines>but it seems like it should link to https://guix.gnu.org/manual/zh-cn/
<cbaines>presumably it just previously showed the english manual?
<cbaines>although maybe in this case the manual URL should be zh-CN?
<mange>Any chance I could get the attention of a committer on some patches to fix gd/PHP? https://issues.guix.gnu.org/72943#6 I'd like to reconfigure my systems on master, but this is holding me back.
<futurile>mange: it looks like Tobias already merged the issue, though QA is showing a collission.
<mange>When you say "merged the issue", what do you mean? There have been several reports of PHP being broken, which I've seen merged into the one report, but no code has been pushed to fix it, right?
<futurile>mange: it looks like QA started to build it but then it failed - https://qa.guix.gnu.org/issue/72940
<mange>Right, thanks. I don't really understand what I'm reading on that page, but it seems like the profile collision is not new (hashes changed, but packages are the same - although it also looks like the same package conflicting with itself?). What can I do to get this change merged?
<mange>Someone else has independently applied the patches and built PHP, so I have some confidence that the patch works for solving the intended problem, at least. If the propagated inputs are a problem then there's an alternate first patch in #72943 which solves the problem in a different way.
<futurile>mange: hmm (a) see if you can figure out why it's failing (b) try and catch Tobias to see if he's solved/solving it (c) build/run it locally as a 'channel' if it's super urgent for you
<futurile>mange: for (c) that way you're not depending on someone putting it into master in the next period of time - as a bunch of things are queued now that core-updates has gone forward
<mange>I don't even know how to read the output to tell that it's failing. :) All the "failing" numbers under "with branch changes" say "0", which seems to indicate it's not the branch failing it?
<futurile>mange: not certain what that means honestly
<apteryx>ugh, finally reconfigured successfully a new machine, only to notice I failed to copy the edited config.scm somewhere persistent
<sneek>Welcome back apteryx, you have 1 message!
<sneek>apteryx, podiki says: I haven't had a chance to try to fix it, but git:send-email is broken on master, missing paths from PERL5LIB wrapping. not sure if it was from your recent git changes or build-system changes (something about phase evaluation changed from core-upates)
<apteryx>any chance that Guix has copied it somewhere (in the store, say) for silly me?
<civodul>apteryx: hey! ‘guix system describe’ shows the link to the config file
<apteryx>awesome! thank you (and hi!), civodul :-)
<elpogo`>I was following instructions here -> https://guix.gnu.org/manual/en/html_node/Building-from-Git.html and everything worked until "make authenticate" which just stays "make: *** No rule to make target 'authenticate'. Stop."
<elpogo`>Although I must note that "make check" failed. Would that explain the missing "authenticate" target?
<mange>futurile: Okay, so the change is non-trivial to merge because the change to gd would require recompiling 5735 packages. I see. In that case I guess it might be better to push a temporary fix that "manually propagates" the dependencies to PHP, rather than rebuilding everything that depends on gd. Luckily there is already a patch to do that here: https://issues.guix.gnu.org/72968
<andreas-e>mange: There are still the test failures, and I agree with the comment that we should not just disable tests because they fail.
<mange>andreas-e: The tests fail because gd 2.3.3 broke something (in 2021), and it wasn't fixed until 2023 and there hasn't been a release since then. I guess we could carry a patch for the fix until a new gd release, if we really wanted to.
<mange>You can see the issue for gd here: https://github.com/libgd/libgd/issues/847 (also linked in my change at https://issues.guix.gnu.org/72943#7) and for PHP here: https://github.com/php/php-src/issues/11252
<andreas-e>mange: Okay, thanks. I am happy with applying your "[PATCH 2/2] gnu: php: Disable tests relating to BICUBIC interpolation." then, since it gives an explanation why the tests are expected to fail.
<andreas-e>To get PHP running, I would for now prefer to apply https://issues.guix.gnu.org/72968 instead of propagating inputs to gd, although this seems to be the correct solution. Maybe we should add comments to gd and php to revisit this situation in the future?
<andreas-e>I do not quite understand, however, why the more than 5000 packages depending on gd do not fail to build. Is it only php that is checking for a rare feature of gd? Then maybe it would make sense to not propagate the gd inputs all the time, but only in the rare cases where they are actually needed.
<andreas-e>Propagated inputs are rather annoying and tend to create compatibility problems (different packages propagating the same inputs in different versions).
<mange>I don't really understand, either. The change specific change that causes this issue was this PR: https://github.com/libgd/libgd/pull/537/files but I don't understand pkg-config well enough to know why that's a problem here specifically.
<meaty>is there a way to have recsel preserve the highlighting that `guix search` makes?
<cow_2001>is there a way to guix pull only from my personal channel?
<cow_2001>and not from guix's official mainline channel
<rekado>cow_2001: yes, you just need a channels file that contains a list of your single channel.
<cow_2001>hmm
<cow_2001>now it complains: error: 'guix' channel is lacking hint: Make sure your list of channels contains one channel named `guix' providing the core of Guix.
<futurile>Q: is there a way to stop the magic of the maintainer-script running when I try to use git-send-email
<civodul>cow_2001: if your channel is not a fork of Guix itself (i.e., it only contains additional packages), then you need to have both Guix and your channel in the ‘channels.scm’ file
<civodul>but then you can “pin” the ‘guix’ channel, either directly in ‘channels.scm’ or with --commit=XYZ
<civodul>that way ‘guix pull’ will effectively update only your channel, not ‘guix’
<cow_2001>hmm!
<civodul>see https://guix.gnu.org/manual/devel/en/html_node/Specifying-Additional-Channels.html
<civodul>and regarding pinning, see https://guix.gnu.org/manual/devel/en/html_node/Replicating-Guix.html
<meaty>hi guix, has anyone gotten the `mate-applets` package to work? I've installed it, but it's not showing up in the interface to add them to my panel. Am I supposed to be doing something different?
<rynn>Anyone here running GuixSD on a Purism Librem Mini? How's the performance?
<meaty>Also, the backends for zathura seem similarly inaccessible
<meaty>nvm
<meaty>but the applets are still missing
<yelninei>civodul: the stoi error seems to only happen when LC_ALL is set to something. Maybe an issue with setlocale? The childhurd system test now also failed on ci.
<yelninei>also is there a way i can make a i586-pc-gnu cross gcc? with cross-gcc-toolchain i get an issue with unsupported system
<civodul>yelninei: ‘guix build whatever --target=i586-pc-gnu’
<fnat>futurile: Oh my! I cracked a little Mumi secret (lol, this might as well be documented and perhaps it was mentioned during jgart's presentation), to reply to a specific message in a thread: 'mumi compose --reply-to=@N' where N is the message number, e.g. 2 for second (or perhaps, second last?).
<fnat>I'm going to open a little bug report though because, apparently, this is not documented in the command-line help, e.g. if you type mumi with no arguments.
<nikolar>what's a mumi fnat
<cow_2001>no, it still takes a ton of time ~_~
<cow_2001>guix describe showed me the current guix commit, and then i used guix pull --commit=$the_commit_i_got_from_guix_describe
<cow_2001>and the processing propeller is spinning
<Rutherther>nikolar: its a tool to use for reviewing guix issues. It can apply patches, send email to specific issue etc.
<nikolar>ah it's a guix specifing thing then
<Rutherther>cow_2001: If I wanted to update just one channel I would save output of "guix describe -f channels" to a file, and then remove commit of the channel I want to update from the file, and use this file in -C of guix pull
<cow_2001>Rutherther: HMM!
<apteryx>hm, it seems php 8 is currently broken, as well as libjami
<Rutherther>For php see https://issues.guix.gnu.org/72943
<fnat>nikolar: Sorry for the lack of context. Mumi is a command line and web interface to debbugs, which is the bug reporting system used by various GNU projects, including Guix. Apologies in advance if this is not 100% correct - perhaps others may chime in and correct me/integrate what's missing.
<nikolar>nah it's all good
<aswjrisp>I know that sway works on guix. I have been trying to get it to work by running the command `sway` on the linux console. So far I have not been able to get it to work.
<ieure>Holy crap, just `guix gc'd 85gb.
<aswjrisp>When I run sway as root I get these error messages https://termbin.com/ne1w
<apteryx>Rutherther: thanks
<apteryx>will look into it soon, now that my new system is up and running!
<aswjrisp>When I run sway as a non root user I get this error "XDG_RUNTIME_DIR is not set in the environment. Aborting.".
<aswjrisp>Ops, the error for root are https://termbin.com/mjeu
<aswjrisp>My config file is https://termbin.com/ne1w
<aswjrisp>I have just done a pull, reconfigure and restart.
<Rutherther>aswjrisp you dont seem to have the pam service
<Rutherther>That is the thing that sets it normally do its not surprising you dont have that variable...
<aswjrisp>The root error message looks weird to me because it says that i915_dri.so for mesa 24.0.4 is missing and when I check the store at the path in the error there is no i915_dri.so. But `guix locate i915_dri.so` tells me that i915_dri.so is from mesa 21.3.8 and guix search show the current version of mesa is 24.0.4. Is this mismatch of mesa versions a problem?
<aswjrisp>I do have mesa 24.0.4 installed.
<aswjrisp>Rutherther: okay I will look at the manual to see how to setup a pam service.
<aswjrisp>Rutherther: I see there is a PAM Mount Service section in the guix manual. Is that the PAM service you are refering too?
<Rutherther>No, I am refering to pam root service type. Though Ive checked once more and login service type extends it, so you actually have it
<aswjrisp>Rutherther: okay
<apteryx>does asking the system from GNOME to sleep functional for someone? for me, the screen goes black but it comes back after a few seconds
<apteryx>that's using the top right disconnect button, then choosing 'sleep'
<cbaines>yep, works for me
<Rutherther>aswjrisp I am not sure why you are getting the mesa error, but please dont install libraries on guix. Packages are made to point to proper libraries tbemselves
<apteryx>cbaines: thanks
<aswjrisp>Rutherther: okay, I have removed mesa from my list of packages. I have reconfigured and I still get the same error for root and non root user.
<civodul>yelninei: could you share your findings in an email at bug-guix@gnu.org, so we can more easily keep track of it?
<civodul>i’ll try to take a closer look later
<podiki>what's the procedure for rebasing a branch? we can't force push so delete and recreate? or some better way to coordinate (though right now just me on mesa-updates)?
<cbaines>podiki, delete and recreate is the way
<podiki>and when you have multiple people on a branch...? they can just pull or do they need to be aware of a rebase?
<ekaitz>we changed the url to the manual, right?
<Rutherther>You cant just pull when history is changed, its a bit more effort
<cbaines>they need to have some awareness, fetching and doing a hard reset is what I do
<apteryx>cbaines: it was the onboard wifi controller of my motherboard (which needs nonfree firmware) that caused the issue. I disabled it in UEFI
<apteryx>(and now it works fine!)
<cbaines>ekaitz, not really, but an infinite number of URLs now don't work
<ekaitz>oh but were's the "devel" manual?
<ekaitz>disappeared then?
<cbaines>apteryx, interesting, I wonder how many other people are going to hit that same issue
<cbaines>ekaitz, the links on the website were broken, but they should mostly work now, it's https://guix.gnu.org/manual/devel/en/
<apteryx>for reference, the errors looked like as reported here: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1958286
<apteryx>(in dmesg)
<Rutherther>It didnt ekaitz, make sure to remove "en" at beginning of URL
<podiki>cbaines: thanks, that's what i figured. i really need to create a mesa/graphics team with some people first!
<apteryx>ACTION should go sleep. later! o/
<ekaitz>cbaines & Rutherther: right that /en/ was mixed in there
<ekaitz>thanks both!
<cbaines>podiki, what's your concerns about the lack of a team?
<podiki>no concerns, just figured help is always good :)
<podiki>which i do get, but kinda ad hoc. and i know a few people will want to work on these updates too
<janneke>what do i need to do to have dovecot support sieve/pigeonhole? would this be enough (and where does dovecot read a user's .sieve file?) -- https://paste.debian.net/
<Rutherther>podiki: does libdrm update go to mesa updates as well? Its a dependency brought mainly by mesa
<cbaines>podiki, I think to make more branches work it's going to require a lot more coordination between people working on different things, rather than building out teams/silos
<cbaines>but yeah help around specific topics/issues is also good
<podiki>Rutherther: yes, and it is updated on mesa-updates (along with a few others including mesa itself)
<Rutherther>To what version is libdrm updated? 121 or 122?
<podiki>cbaines: yes, i think especially getting more contained updates which require more rebuilds to be done quickly as part of whatever branch is up next will be helpful and require wider communication
<podiki>Rutherther: whatever was the latest as of ~a week ago
<podiki> http://git.savannah.gnu.org/cgit/guix.git/log/?h=mesa-updates 122
<Rutherther>Great. That means wlroots 0.18 can be packaged now on mesa updates. I think I could do a patch in a few days if no one did yet.
<podiki>simple update do you know? or require some more effort than version bump?
<Rutherther>Quite simple, but also requires wayland 1.23 and wayland protocols 1.35
<Rutherther> https://github.com/Rutherther/guix-exprs/blob/main/ruther/packages/wayland.scm#L97I have it all here
<podiki>protocols also updated to 1.36 already
<podiki>do you happen to know if the different wlroots packages are due to incompatibilities of some packages with newer wlroots? if it is just rebuilds that is fine
<Rutherther>Probably will have jncompatibilities, wlroots changes a lot
<podiki>ok. well if 0.18 package form is similar to others, i would go for making that the one others inherit from. other than that detail seems easy enough
<Rutherther>I agree
<podiki>i might just do that later today anyway, when i rebase, but let me know if you submit a patch today or tomorrow
<podiki>i also need to see why gtk-4 is failing some tests on that branch, unclear to me
<podiki>hmm or maybe it is gst stuff...
<aswjrisp>Is there a way to specify earlier versions of a package? I think I might try getting an earlier version of sway to start.
<ekaitz>aswjrisp: if they are included in current guix with @ if they are not you can do time-machine or inferiors
<ekaitz>depending on what you want
<podiki>e.g. sway@<version>
<aswjrisp>ekaitz: Where do I look to find out if previous versions of a package are in current guix?
<ekaitz>guix search sway should show all that we have currently
<ekaitz>try with `guix show ffmpeg` to see who that looks like
<ekaitz>we have many, but sway we only have 1.9
<ekaitz>i think you are looking for an inferior
<aswjrisp>ekaitz: I see what you mean with ffmpeg.
<ekaitz>:)
<aswjrisp>The Inferiors section of the guix manual opens with that inferiors are a tech preview as of version 0.0-git. Is the "0.0-git" a typo?
<ekaitz>idk
<aswjrisp>It is a very odd version number.
<ekaitz>yeah... looks like it is broken, because we have proper versions
<ekaitz>let me take a look
<ekaitz>oh ok, what link to the docs are you reading?
<nckx>aswjrisp: https://issues.guix.gnu.org/42212
<ekaitz>oh nckx good catch
<ekaitz>that explains it
<nckx>Wish I could claim some encyclopaedic knowledge of the Guix bug tracker, but I just happened to read that report yesterday.
<ekaitz>HAHA
<aswjrisp>ekaitz: I am reading the docs with info guix. As I was getting 404 error on the guix website for the documentation.
<nckx>Erm, anyone's backspace key broken after the core-updates merge?
<ekaitz>aswjrisp: I just asked a little bit earlier about it, the urls are broken a little bit
<nckx>My backspace key sends a <ScreenSaver> keycode now.
<aswjrisp>nckx: I just did a pull and reconfigure yesterday evening and my backspace key is working. I have been using it while reading the manual with info.
<Kabouik>Damn that sounds like an April fools' joke. I haven't updated yet, but I'm not taking the risk. OO
<nckx>I assume I'm the only person affected. I have been chosen. Happens a lot for some reason.
<nckx>aswjrisp: Thanks.
<Kabouik>With great power come great responsibilities.
<Kabouik>Singular form, even.
<aswjrisp>I get the same version number issue at the top level of info guix as well.
<nckx>I'd expect it to appear everywhere, except maybe ‘release’ manuals.
<nckx>I wonder why it was never merged. I submitted a much worse patch (to which I won't link) 3 years after this one to fix the same problem, which was LGTM'd, but I think I like this one much better.
<nckx>futurile: I'm Tobias but I haven't worked on fixing PHP yet, sorry. If literally nobody else does I probably will, since I use PHP, but then so do many people so it seemed unlikely that I'd need to.
<rynn>I just tried to install gnucash but it for some reason cratered. Anyone know where to begin fixing it? https://paste.debian.net/1328541
<luca>Hi, is anyone else having trouble with www.gnu.org?
<ekaitz>luca: yes
<luca>all right, I'll try again later
<luca>Unless someone here happens to know how I could s/./- a string in guile?
<nckx>They've been under attack for a few weeks now, plus there's also a dodgy switch (I don't know if that one affects gnu.org or only Savannah, but it doesn't help).
<nckx>luca: string-replace, probably.
<luca>Do you have an example on how I can use it?
<nckx>There's probably a faster version for the 1-character case but this one will serve fine as sed replacement.
<nckx>luca: (string-replace my-string "gnu" "cow").
<luca>Thanks!
<nckx>Except the name is wrong, should be string-replace-substring, not string-replace.
<nckx>But otherwise a 100% flawless example.
<luca>And another really basic question, how do I define a function that takes an argument?
<luca>Oh `(define (func-name arg)`
<nckx>(define (my-proc arg1 arg2…) (do-some) (cool-stuff))
<nckx>Yes.
<nikolar>(define (function-name arg) body)
<nckx>It's actually syntactic sugar for (define my-proc (lambda (arg1 arg2 …) (do-some) (cool-stuff))).
<lilyp>Anyone know why gnome-maps is no longer part of gnome in Guix?
<luca>Anyone got any tips as to how I can add recursively files in a folder into home-files-service-type? This is what I have so far, but it isn't working https://git.lucamatei.com/dotfiles.git/tree/home-configuration.scm?h=guix&id=7208013281a14ac1bc370138913ba95f60be6ff5#n61
<lilyp>as for fun gnome stuff: Who wants to package https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs ?
<lilyp>luca: there is directory-union and local-file should also have a recursive option
<luca>I definetely do not want local-file with the recursive option. I am adding a folder in a path that guix services like to add stuff to, so that will break. I need to add each file individually with local-file
<nckx>lilyp: Isn't it? I don't use etc. blah blah but the gnome service seems to pull in gnome-meta-core-utilities at first glance?
<nckx>rynn: I can't reproduce that, and there seems to be a substitute for gnucash on master, but if I were to debug that I'd start at the actual test error message, if any. It's missing from your paste but many test suites don't bother to print it to stderr. In that case you'll have to use --keep-failed and look for a log file.
<nckx>But if all you want to do is count your coin and get on with your life, you might want to investigate why you didn't get a substitute instead.
<lilyp>okay, this looks weird
<lilyp>gnome-weather is at a newer version than the .desktop-file suggests
<lilyp>ah, no, I'm just stupid, confusing maps and weather
<rynn>Thanks nckx, I'll investigate the substitutes issue I think.
<rynn>Ohh, wait. The substitutes are being pulled from a gnu.org address, which is currently having issues.
<freakingpenguin>luca: I expect you'll want to look at (info "(guile) File Tree Walk") and assume-source-relative-file-name in Guix.
<luca>oh wow, I have the manual downloaded. I had no idea
<nckx>rynn: Alas, that won't be the cause here. guix.gnu.org and everything under it is delegated to us & hosted on our own hardware.
<rynn>Oh, darn
<nckx>I got a substitute from <https://ci.guix.gnu.org/nar/zstd/0p875mw7nvgi1cymgbnxrfzr9c2rnaai-gnucash-5.8>. If ‘guix build -d gnucash’ returns /gnu/store/wxw9s0ryp276954ci5awrbwgyxky3jwl-gnucash-5.8.drv for you, then you should to.
<nckx>o.o
<rynn>Hmm, looks like it might be a locale issue.
<rynn>> C++ exception with description "locale::facet::_S_create_c_locale name not valid" thrown in the test body.
<nckx>Oh those are the worst.
<nckx>(Not that error specifically, just locale hell in general.)
<rynn>Which tracks, I keep having weird locale issues in this install.
<nckx>Due to the way that glibc handles locales that's somewhat a tradition after each core-updates merge & glibc update, but I wouldn't have expected it to affect the build environment in a non-reproducible way.
<nckx>Even if it shouldn't happen, is your running guix-daemon up to date with the rest of your system?
<nckx>ACTION away a bit.
<rynn>I don't believe so, currently updating everything, so going to see what happens after the reboot.
<xelxebar>The documentation for `guix package --export-channels' says it outputs channels for the "chosen profile(s)". However, how does one choose a non-default profile?
<civodul>xelxebar: using ‘-p’ (or ‘--profile’)
<xelxebar>But that option says it "must be the name of a file that will be _created_ upon completion."
<Rutherther>the description is wrong then
<xelxebar>Really, I'm just trying to run a program from a previous generation. Maybe I'm going about it the wrong way.
<Rutherther>so have you tried the -p option?
<xelxebar>Rutherther: Tried, but `-p <generation id>' errors, so I assume I'm doing it wrong.
<Rutherther>the path to the profile, not the gen id. But anyway if you just want the channels it will be easier to check the channels.scm in the profile folder directly
<xelxebar>How do we get the profile path for a given generation?
<xelxebar>Manually munge about in /var/guix/profiles?
<aswjrisp>xiews: /run/current-system/profile/
<aswjrisp>ops
<aswjrisp>xelxebar: /run/current-system/profile/
<Rutherther>for system profile it's better to use guix system describe, not guix package
<xelxebar>aswjrisp: I want the profile directory for a given generation, not the current system one.