IRC channel logs

2024-04-01.log

back to list of logs

<PotentialUser-76>Is ungoogled-chromium really free? I would have expected it to include DRM and the like
<apteryx>it doesn't/its stripped/disabled by the ungoogling script
<PotentialUser-76>Ah I see
<db48x>ACTION laughs
<jakef>It looks like emacs-magit broke in the last couple of days
<jakef>installed but isn't available in emacs
<jakef>rolling back the profile fixes it for me, but it's the same version of emacs-magit (3.3.0-7.dda332b)
<apteryx>jakef: the emacs-team branch was merged today
<apteryx>perhaps it introduced a regression
<jakef>yep i did reconfigure the system as well. would it help if i submitted a bug report?
<jakef>though I'm sure it will be discovered quickly
<apteryx>a bug report could be useful to communicate it's known
<apteryx>and to communicate when it'll be fixed!
<Guest69>Does `guix system reconfigure` also do a `guix package -u`? i.e. Is `guix system reconfigure` (after a pull) sufficient to upgrade the system (not counting guix home stuff)?
<podiki>reconfigure just updates the system configuration and packages included in that configuration, nothing else
<podiki>jakef: magit broke how?
<jakef>more on the emacs-magit problem, emacs changed from 29.1 to 29.3. that's probably related huh
<jakef>emacs-magit is installed. M-x magit not found
<podiki>did you upgrade whatever profile has emacs and magit?
<jakef>yep. and rolling back the profile fixed it
<podiki>i sometimes have to do things like clear/regenerate the quickstart cache
<podiki>"magit not found" suggests that it isn't finding the package load path, which will have changed with the updates (new hash in the store)
<podiki>does guix shell emacs emacs-magit -- emacs -Q work for loading magit?
<jakef>no
<podiki>with same error?
<jakef>yeah the [no match] thing
<podiki>no match? i thought it was magit not found
<podiki>i.e. (require 'magit) says package not found?
<jakef>ok sorry. i said the wrong thing. emacs couldn't find magit so i said emacs not found
<podiki>i tried in a guix shell --pure emacs emacs-magit -- emacs -Q
<podiki>and after evaluating (require 'magit)
<podiki>i can then M-x magit
<podiki>can you reproduce? the magit command won't be available until after loading magit of course, and with emacs -Q it is not using your init file (likely where you loaded the package normally)
<jakef>ok yep evaluating the require works. not sure why i didn't have to do that before. maybe emacs changed that on purpose!
<jakef>i have magit deferred in a use-package block, but could always call M-x magit
<podiki>could be your config, a change after updating with some paths? or environment. or maybe you were still running older emacs (e.g. as a server and opened a new client)
<podiki>ah
<podiki>yeah i dunno, time to read up on changes from emacs 29.1 to 29.3 :)
<jakef>thanks for your help
<podiki>there was some change in loading code (security issue) though I think that was in org-mode more, but maybe some thing has changed
<podiki>welcome!
<podiki>i was going to update my system and profiles soon too, so i had a vested interest
<podiki>i do know some commands i don't get until after using somethign else in the package, maybe something similar with what is defer loaded with use-package
<jakef>yeah i thought magit was an autoloaded function. so calling it makes magit load
<jakef>maybe it is still a bug, if magit's autoloads aren't being provided
<db48x>jakef: yea, that does sound like a problem with the autoloads
<db48x>ACTION yawns
<db48x>too tired to investigate tonight, but tomorrow maybe
<jakef>no worries db48x
<jakef>this should reproduce:
<jakef>guix shell --pure emacs emacs-magit -- emacs -Q --eval "(call-interactively 'magit)"
<jakef>sorry, lower case q
<podiki>but did that change now? in my current profile (emacs 29.1, some weeks old guix) that also doesn't work
<jakef>guix shell --pure emacs emacs-magit -- emacs -q --eval "(call-interactively 'magit)"
<jakef>did it work with lower case q podiki?
<podiki>did with lowercase q. what is the difference, lower q still loads some settings? (i've only ever used -Q for testing to see if is my config)
<jakef>from the man, -q is no init file, -Q means quick and does less
<podiki>i see -Q as including -q and more, are you sure?
<jakef>does less -> loads less
<podiki>ah
<jakef>-Q is "similar to '-q --no-site-file --no-splash'. Also, avoid processing X resources."
<podiki>right
<podiki>so I usually use -Q to test to make sure it isn't my config/settings
<podiki>i can compare after i upgrade tomorrow
<podiki>might want to ping lilyp later, they would likely know if there is something up/what to check
<jakef>cool. i'm in a timezone that means i usually sleep when this channel is busy
<podiki>gotcha. well a bug report is always good then :)
<jakef>done :)
<adanska>why is electron nonfree? it appears to be licensed under the MIT license
<podiki>it is a bootstrapping/build from source issue
<podiki>doesn't seem practically possible to properly build such javascript reliant packages from source, e.g. https://www.spritelyproject.org/blog/javascript-packaging-dystopia/
<podiki>so it is not nonfree, but not (currently) possible to package per guix standards and guidelines, from what i understand
<adanska>right... that makes sense.
<adanska>what makes it different from other non-bootstrappable packages like ghc or ccl?
<adanska>or i should say not easily bootstrappable packages
<podiki>i don't know all the details, but there you can start from some older version and bootstrap; maybe from a binary built with another compiler? or at some point down to some minimal binary seed
<podiki>(not an expert, just trying to remember what i have heard)
<podiki>but for js it seems just untangling the dependency tree is hard/impossible? with cycles?
<adanska>i see. so really its just a matter of js being a complete horrorshow to package in Guix. similar to how the Rust situation is trending
<podiki>from my limited perspective at least rust we have gotten somewhere
<podiki>doesn't seem like we have gotten very far with js
<podiki>but yeah, all seems very messy from what i can see
<podiki>though i'm not expert, just repeating what i've heard
<jakef>comparable to npm?
<adanska>cool, that makes sense then. its a shame, packaging an otherwise free electron app has to be done using the nonguix channel since electron is only packaged there.
<podiki>there is some node/js binary build system proposed for guix if i remember, might just have to make some compromise on the bootstrapping
<adanska>interesting
<adanska>by the way, kinda off-topic does anyone know how to use GNU Parallel to dispatch multiple different commands at once? something similar to `foo & bar & baz &` in bash
<adanska>i only know how to dispatch the same command with different inputs
<Guest69>Hello, is there any way to use nouveau for wayland?
<adanska>Hi, how do i make a specific version of a package as an input? for example qtbase@5
<iyzsong>adanska: if the specific package is available in the code, reference it directly (eg: qtbase-5). or define a new package with the version (can use 'inherit' to save some code)
<adanska>ok, thanks!
<podiki>mesa-updates has been pushed, time to let it build....
<podiki>updates to: cairo, mesa, libdrm, vulkan, sdl2
<adanska>nice!
<lilyp>Nice catch on the magit autoloads, everyone
<jakef>we got there eventually xD
<efraim>adanska: for your parallel question, that one to run the three commands (without the &): parallel {} ::: foo bar baz
<adanska>oh yes of course! that makes so much sense
<adanska>thanks efraim :)
<efraim>the one-liner I use to build most of the "interesting" rust programs: time parallel --eta --halt=now,fail=1 --shuf --jobs=3 ./pre-inst-env guix build --no-grafts --max-jobs=1 {} ::: $(./pre-inst-env ~/list-all-cargo-build-system-packages | grep -v rust-)
<adanska>has anyone had any luck using gnome-online-accounts to sync their calendars and contacts with gnome-calendar and gnome-contacts etc.?
<adanska>simply doesnt work for me, although i can sign into my google account
<lilyp>you might need evolution-data-server in the middle, but that's about it
<adanska>okay, ill give that a go :)
<adanska>awesome, its working now!!! thanks lilyp :)
<futurile>Morning all
<efraim>o/
<adanska>good morning from the future afternoon!
<futurile>heh morning adanska
<futurile>anyone want to look at a patch for the Rakudo build system - it's too hard for patch review sessions - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58235
<peanuts>"#58235 - [PATCH] rakdo-build-system - GNU bug report logs" https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58235
<efraim>Someone™ should probably gather all the rakudo patches and make a decision about how to deal with raku overall
<futurile>It looks they have tried to do that on this series - or at least they refer to other attempts at updating it
<futurile>jpoiret: you might be interested in this update of Make to 4.4.1 for core-updates: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61843 (looks like it's 4.3 on core-updates)
<peanuts>"#61843 - [PATCH] gnu: make: update to 4.4.1 - GNU bug report logs" https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61843
<efraim>that might need a newer sed, like most of the other core packages
<futurile>are we avoiding updating sed for $REASON?
<efraim>no, just we've managed with gash-utils until now and no one wants to actually do the work to add in sed and then make sure its pulled back out later before %final-inputs
<efraim>and to figure out which version of sed to use
<futurile>ah - well given that core-updates is already needing to be pruned back to something reasonable I guess this will have to update
<efraim>we're all hoping someone else will add the 'w' command to the sed in gash-utils
<futurile>I have a new usertag report 'escalated-review-request' for stuff that's too hard - I'm going to put both make/grep requests in there
<futurile>It's satisfying to put something in a list - even if you're not doing anything with it heh
<efraim>add in coreutils if there's any patches for that
<futurile>OK
<efraim>I might dive down the rabbit hole today looking at busybox to see if I can build just enough to be useful
<jpoiret>right, i'd rather not have any new updates to core-updates from now on, it should be time to stabilize
<efraim>jpoiret: If i were to magically get it ready today I'd aim for a next round anyway, since it'd be a sudden upgrade of a bunch of core packages
<jpoiret>i've built most of the more time-consuming packages but have not yet reached gnome again, and i'm away for a conference this week. I'll still try to work on it though.
<efraim>also, looking at gpl2 C sources to port to gpl3+guile code is ok? or should I look at toybox with its bsd license to see if it can show me what to do with sed, if I go that way and add to gash-utils
<efraim>I don't even know what this magic 'w' command in sed does
<efraim>thinking outloud, I'm pretty sure gpl2 -> gpl3+ is ok, as long as I actually "add something" to it
<futurile>most gpl2 code is 'gpl2 or later' isn't it
<efraim>We list busybox as gpl2. IIRC they did a code audit and realized they were gpl2-only and not gpl2+
<PotentialUser-76>Do I have to manually set the GUIX_PROFILE environmental variable, even if I installed the Guix System?
<lucy>woop waybar 0.10
<lucy>congrats gnome team, thanks
<PotentialUser-78>Hello guix. After using guix home on Asahi Ubuntu I got an error when opening a shell. sed: -e expression #1, char 7: unknown command: `\'
<PotentialUser-78>Any idea what causes this?
<PotentialUser-78>I suspect the alert alias in configuration.scm, but do not know how to fix this
<attila_lendvai>PotentialUser-78, are you reconfigured into a newish guix home? i remember some quoting issues have been fixed, but it was several months ago...
<PotentialUser-78>attila_lendvai Yes right after guix home import I did a reconfigure
<PotentialUser-78>I am on the latest guix. Few minutes old
<attila_lendvai>PotentialUser-78, no idea then. you'll need to share some stuff. is that configuration.scm that you mention your config? can it be shared?
<PotentialUser-78>attila_lendvai: https://pastebin.com/EKcuAgiH
<peanuts>"home-config - Pastebin.com" https://pastebin.com/EKcuAgiH
<attila_lendvai>PotentialUser-78, right, a bit of quoting hell from lisp to shell to sed... :) annoys the shit out of me, especially the shell part
<attila_lendvai>PotentialUser-78, was that alias created by `guix home import`?
<PotentialUser-78>attila_lendvai: I think so. Maybe it was defined on Ubuntus side and imported somehow. But I did not touch it
<attila_lendvai>PotentialUser-78, as a quick workaround you can just comment out that line using ;
<attila_lendvai>then guix home reconfigure
<PotentialUser-78>attila_lendvai: The alias was also in my home-config.scm. I removed it and it works now. Thanks
<attila_lendvai>PotentialUser-78, i'm glad it worked out! i thought it's something that you use regularly and thus need, and cannot be commented out. i'll report it as a bug.
<attila_lendvai>reported as https://issues.guix.gnu.org/70125
<peanuts>"`guix home import` doesn't quote aliases properly" https://issues.guix.gnu.org/70125
<PotentialUser-78>good catch. Thank you for creating the issue
<erikeah>Hi! The last day ngz (and nitpick I think) gave me feedback on https://issues.guix.gnu.org/69219, I did my job and I would like to get my patch reviewed again, Thanks!
<peanuts>"[PATCH] gnu: Add sandbar." https://issues.guix.gnu.org/69219
<NowAUser-76>How do services work? As in, assume I install something like fcitx5. Since it didn't start itself, I guess I need to add it as a service. But the package definitions does not seem to contain any hints regarding that. How does that work?
<rekado>db48x: the SELinux policy certainly is not perfect. It was not when I first added it in the distant past, and unless there has been constant work to keep it up to date with changes to the policy set in Fedora it won't be perfect today either.
<rekado>I haven't been using Fedora in many years, so I encourage others who do to identify missing permissions or mistakes in the policy, test corrections, and submit them for inclusion.
<futurile>Q: what package is the actual 'man' command in?
<futurile>I can find mandoc?
<rekado>futurile: guix locate man says it's in man-db
<futurile>rekado: oh hah - totally forgot about that command! thank-you
<attila_lendvai>NowAUser-76, services are independent from packages (except that they refer to the packages to get the binary from them). so, installing a package will never start a service in guix, just make the package available in the profile.
<NowAUser-76>attila_lendvai: What do you mean with making the package available in the profile? I used guix install fcitx5-anthy, and after a restart it didnt seem to start fcitx5
<attila_lendvai>NowAUser-76, unfortunately, currently such service definitions code needs to be written by hand, and i don't see anything beyond the package definition
<attila_lendvai>NowAUser-76, a guix profile is a bunch of symlinks that integrate several packages into a profile that can be "entered" (e.g. using guix shell), or "activated" (e.g. by booting into it from grub).
<attila_lendvai>NowAUser-76, now, how you start that binary, is a completely different story. you can start it as a system service using the root shepherd instance (systemd equivalent), or a user instance of shepherd, or just from some gui startup file (in this case the most probable way, as it's some input method system)
<NowAUser-76>The reason I was thinking of starting as a service, is because I think on Arch I would have used systemd iirc
<attila_lendvai>NowAUser-76, https://fcitx-im.org/wiki/Setup_Fcitx_5 explains how to auto start it
<peanuts>"Setup Fcitx 5 - Fcitx" https://fcitx-im.org/wiki/Setup_Fcitx_5
<NowAUser-76>Ah I see, seems like I was on the wrong path. Thanks!
<futurile>NowAUser-76: yeah it can be a bit difficult sometimes to get your head around the concepts - or previous assumptions from other Linux distros can catch you out a bit sometimes :-)
<attila_lendvai>it's really just some systemd automation missing from shepherd+guix... but then i'm not sure i like the idea that installing a package also implies automatically starting it as a service.
<attila_lendvai>also, if it had any reputation left, then systemd has just lost it with the recent xz backdoor incident...
<attila_lendvai>ACTION is fixing gpaste that was not updated with the recent gnome commits
<NowAUser-76>I noticed that when I installed fcitx5-anthy and fcitx5-configtool, I did not get fcitx5 even though the tool was able to start fcitx5 somehow. I would have expected to be able to access the fcitx5 binary myself, especially since its a dependency for both. Am I missing something?
<attila_lendvai>NowAUser-76, in guix references between packages are directly encoded. e.g. fcitx5-configtool has direct paths to /gnu/store/[hash]-fcitx/bin/fcitx. if you want something available in your profile's path, then you need to add it explicitly.
<attila_lendvai>NowAUser-76, this is what makes it possible that in guix you can have multiple versions of the same app available in your profile, as they refer to their dependencies directly (as opposed to e.g. through opening libfoo-1.so in /lib/)
<NowAUser-76>Is there a way for me to say "I want exactly the fcitx5 that fcitx5-anthy  has as its dependency" somehow?
<attila_lendvai>NowAUser-76, if you just refer to these packages from the same guix pull, then you'll automatically get compatible versions (unless the packager made a mistake, or there are multiple versions maintained within guix, but it's not frequent)
<NowAUser-76>Ah I see. I've made some progress, but it seems that it fcitx5 is not working in IceCat. I tried to install a bunch of fcitx5-gtk package and set the environment variable, but it doesn't seem to help.
<db48x>rekado: did the hole where any file in /gnu/store named guix gets elevated permissions?
<NowAUser-76>I fixed the fcitx5 problem; by trying something from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35610#38
<NowAUser-76>I think the key is   export GUIX_GTK3_IM_MODULE_FILE="$HOME/.guix-profile/lib/gtk-3.0/3.0.0/immodules-gtk3.cache"
<NowAUser-76>How could I have fixed this myself? Any ideas?
<peanuts>"#35610 - Freshly installed IBus intput method is not listed as an input source - GNU bug report logs" https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35610#38
<attila_lendvai>NowAUser-76, sometimes for integration to work you need to install packages that are not obvious. e.g. you need to `guix install python python-foo` for python-foo to be available as a python lib (the installation of the python package triggers the merging/handling of the PYTHON_PATH env var, or something along these lines).
<attila_lendvai>NowAUser-76, there are two packages that refer to that env var: ibus and gtk+
<attila_lendvai>try to add ibus to your packages when you install fcitx5
<NowAUser-76>But I don't really need ibus
<NowAUser-76>The issue I have was also different from what is in question: I was able to use JP input, except for in IceCat
<NowAUser-76>I did suspect there to be a GTK problem, but not there being a specific guix environment variable that needs to be set
<attila_lendvai>NowAUser-76, sorry, but that's about all i know about gtk and input methods...
<NowAUser-76>attila_lendvai, ah no, that's quite alright. You have already helped me a lot today :)
<NowAUser-76>I think there were some hints, because fcitx5 did complain about im modules, and it is GTK after all. Sadly, I don't have a lot of experience with those either, which made the debugging harder.
<NowAUser-76>Although it is probably solved now, so it can be something to maybe write a post about and then investigate further if time permits
<attila_lendvai>NowAUser-76, if this is something you think should/could be handled automatically by guix, then you may consider filing a bug
<NowAUser-76>I am not sure; is setting environment variables something that Guix handles automatically?
<attila_lendvai>NowAUser-76, if it's something along the lines of e.g. making a plugin available for some app through an env var, then yes, it usually does.
<rekado>db48x: a verb seems to be missing in your question.
<rekado>is there a bug report about this?
<db48x>heh, I guess I did the verb
<db48x>I assume there was one
<db48x>a bug report, that is
<NowAUser-76>I have the following snippet in my config now:
<NowAUser-76>(simple-service 'fcitx5-env session-environment-service-type
<NowAUser-76>               '(("GTK_IM_MODULE" . "fcitx")
<NowAUser-76>                 ("QT_IM_MODULE" . "fcitx")
<NowAUser-76>                 ("XMODIFIERS" . "@im=fcitx")
<NowAUser-76>                 ("GUIX_GTK3_IM_MODULE_FILE" . "$HOME/.guix-profile/lib/gtk-3.0/3.0.0/immodules-gtk3.cache")))
<attila_lendvai>NowAUser-76, use a pastebin to paste larger fragments
<db48x>I see that it hasn’t been: https://git.savannah.gnu.org/cgit/guix.git/tree/etc/guix-daemon.cil.in#n473
<peanuts>"guix-daemon.cil.in\etc - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/tree/etc/guix-daemon.cil.in#n473
<podiki>did someone cancel the mesa-updates evaluation? shows as canceled but maybe is still going?
<efraim>podiki: no idea. I just told it to restart that evaluation
<podiki>....yeah me too
<podiki>will check in on it later
<podiki>a handful of packages did build, but some builds looked stalled or something
<NowAUser-76>I started with this https://paste.debian.net/1312681/ and came up with https://paste.debian.net/1312683/ to fix the fact that I dont want $HOME to be part of the env. But reconfiguring now just tells me "build of /gnu/store/f225m17y5r0gx850547sg31dbr4y16q1-environment.drv failed". Is that a random failure, or did I make a mistake?
<peanuts>"debian Pastezone" https://paste.debian.net/1312681
<peanuts>"debian Pastezone" https://paste.debian.net/1312683
<rekado>db48x: do you have a recommendation to address this?
<db48x>rekado: just the obvious one. require that guix-daemon is in a different store directory
<db48x>normal packages would be in /gnu/store, while guix-daemon would go in /gnu/elevated or whatever
<podiki>efraim: well one of our restarts did the trick I think...evaluation complete and i see a lot of builds scheduled (not as much as last mesa-updates round, so far)
<efraim>well that's at least good. We'll have to see if the build farm speeds up its building or not
<efraim> https://ci.guix.gnu.org/metrics the new builds list is shooting up
<peanuts>"Global metrics" https://ci.guix.gnu.org/metrics
<NowAUser-76>I just tried to run the binary of Anki, and I simply get that it couldn't find the executable. Any ideas why?
<podiki>efraim: workers still not doing anything (though I can relate, I'm slow to get moving myself). I think the last few biggest spikes on new builds have been mesa-updates....one day mesa-updates will just be mesa
<futurile>on https://ci.guix.gnu.org/metrics - which stream is the qa.guix.gnu.org - the incoming patches ones?
<peanuts>"Global metrics" https://ci.guix.gnu.org/metrics
<futurile>I'm thinking of this list https://qa.guix.gnu.org/patches - which seems to get stuck
<peanuts>"Patches Guix Quality Assurance" https://qa.guix.gnu.org/patches
<rekado>db48x: we could recommend that a sysadmin places the binaries there (and adjust the policy), but we cannot change Guix to install things outside of /gnu/store.
<Guest96>Is ther a good rule of thumb for when to use 'define-configuration' vs 'define-record-type*'?
<Guest96>I can't use serialize-configuration, which seems like the main use-case for the guix-specific define-configuration
<rekado>Guest96: why can't you use it?
<NowAUser-76>I am slowly losing my mind over getting Anki to run
<NowAUser-76>I pass guix shell --container --network --emulate-fhs --development ungoogled-chromium libgccjit - ./anki to it, and it complains about not having UTF-8
<apteryx>try adding in glibc-locales perhaps
<NowAUser-76>Now I get that it cannot find libstdc++
<NowAUser-76>And the only thing I can find online is that it used to be part of gcc:lib, which is not available anymore :/
<apteryx>efraim podiki I think Cuirass accumulated so many builds pending that the postgresql queries made to select workers and dispatch jobs such as for aarch64 must have slowed down to a crawl
<apteryx>the aarch64 machines are idling
<apteryx>though there are thousands of pending builds that they could process
<podiki>apteryx: i see everything idling. so a db query bottleneck then...db too large? something in the design which will get choked by too many queries?
<efraim>might need to GC the postgres database again
<futurile>NowAUser-76: if you're a new user - you might just be better off building a VM and running Anki inside that on a standard distro that you're familiar with - until you build up some experience
<futurile>NowAUser-76: running proprietary stuff with --emulate-fhs is quite hard in my experience
<podiki>NowAUser-76: use -e '(list (@@ (gnu packages commencement) gcc) "lib")' for gcc:lib for now. really need to deal with that pending bug, maybe today is the day i submit a new patch
<podiki>we have packaged anki, so that should be fixed if it doesn't work. there's always flatpak too
<NowAUser-76>podiki: Thanks, I used that. Now it is complaining about Qt6 .-.
<NowAUser-76>futurile: That's a good point; although Anki isn't proprietary
<NowAUser-76>podiki: The anki version is too outdated - it cannot sync anymore with the service (complains about new timezone settings)
<futurile>NowAUser-76: I watched a new user a couple of weeks ago break themselves trying to run some stuff - they weren't having fun - that's the only reason I'm saying it :-)
<NowAUser-76>futurile: My biggest concern would be that I am able to run a project where we have to optimize C code, but we will get there when the time comes :P
<podiki>efraim: we don't have a periodic db maintenance job of some sort? maybe we should?
<Guest96>rekado I can't use serialize-configuration because it is restricted to situations where the resulting file is simply a concattenation of each entry converted to a string, but my situation requires nesting strings, which breaks that assumption
<Guest96>Are there other reasons to use define-configuration over define-record-type*?
<efraim>don't think so. I think I convinced rekado do do the honors last time
<Guest96>and wow was I missing out trying to code my custom record serialization without match-record-lambda
<NowAUser-76>Does xcb-cursor0/libxcb-cursor0 exist in Guix? (i.e. is it something different than xcb-util-cursor)
<Baughn>Does anyone have experience using the open-source nvidia driver (NVK, not nouveau) on GuixSD? Is it well supported?
<lilyp>there ought to be work in that direction on the mesa team
<Baughn>Hmm. Then I'll check back in a year.
<Baughn>I need to somehow get ZLUDA working on the GPU as well, which I'm not sure is possible. Would rather not fight that at the same time as the OS.
<Baughn>(Not exactly sure that will work... and it doesn't seem to be packaged? Huh.)
<podiki>Baughn: we have patches for enabling nvk but i decided to aim that for 24.1 (in the next couple of months)
<podiki>but it should work if you want to try it locally
<podiki> https://issues.guix.gnu.org/69637
<peanuts>"[PATCH mesa-updates 0/6] gnu: mesa: Update to 24.0.2." https://issues.guix.gnu.org/69637
<podiki>technically 24.1 is when NVK will be officially "stable"
<NowAUser-76>I just shotgunned any package that had xcb in its name; it works now
<podiki>NowAUser-76: for anki? what was the final incantaion
<NowAUser-76>It is extremely bloated, but currently it looks like this
<NowAUser-76>QT_DEBUG_PLUGINS=1 guix shell --container --network --emulate-fhs     --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --preserve="QT_DEBUG_PLUGINS" --preserve="^LANG$" --expose=$XAUTHORITY ungoogled-chromium --development ungoogled-chromium zstd:lib libxkbfile --development libxcb libxkbcommon rust-xcb xcb-util-errors python-xcffib
<NowAUser-76>xcb-util-image xcb-util-xrm cairo-xcb xcb-util-keysyms xcb-util xcb-util-cursor xcb-util-renderutil xcb-proto guile-xcb rust-xcb xcb-util-xrm xcb-util-image xcb-util-errors xcb-util libxcb xcb-imdkit xcb-util-wm xcb-util-renderutil xcb-util-keysyms rust-as-raw-xcb-connection perl-x11-xcb xcb-util-cursor cairo-xcb python-xcffib xarcan -e $'(list (@@
<NowAUser-76>(gnu packages gcc) gcc) "lib")' -- ./anki
<NowAUser-76>A good bit of them are duplicated
<NowAUser-76>I will take some time to reduce them now
<podiki>but it works, nice!
<NowAUser-76>yup, that's progress :D
<NowAUser-76>maybe this will be useful if someone wants to package it
<NowAUser-76>no clue how that would work though
<Baughn>podiki: I'll probably need to run CUDA on top of it anyhow, but ideally that can be sandboxed. Will wait for 24.1 then.
<Altadil>NowAUser-76: Sorry, I have not followed your previous message, but if you’re trying to run anki, it’s already packaged. :)
<NowAUser-76>Altadil: I know, but that version's sync is not usable.
<Altadil>NowAUser-76: oh I see, makes sense then. ^^
<jackhill>hmmm, I wonder why QA has yet to process https://qa.guix.gnu.org/issue/69659
<peanuts>"Issue 69659 Guix Quality Assurance" https://qa.guix.gnu.org/issue/69659
<podiki>all workers idle all day on berlin, apteryx or rekado can we nudge it along? a db vacuum was suggested (or has someone started that?)
<db48x>rekado: why not?
<redacted>The "networking" service in the vm I've built is stuck on "starting". Is there any way to get more information on what it's stuck on? It's not leaving anything in /var/log/messages
<db48x>there must be some function or method that takes a package and returns its storage location
<db48x>one little special case there and now guix-daemon has it’s own directory
<db48x>s/it’s/its/
<blum>How should my .config/guix/channels.scm look like if i wanna use my clone of the guix repo ~/guix?
<blum>Currently it's (list (channel (name 'guix) (url (string-append (getenv "HOME") "/guix")))) is that right?
<apteryx>podiki: there are like 100k+ builds queued, I'm not sure if a vacuum would help
<apteryx>not that I know how to do that (I think stop cuirass, dump the db, then replace it?)
<podiki>so we just wait? mesa-updates was pushed around 13 hours ago and the evaluation failed/canceled somehow (though a few builds went through)
<podiki>and since i/efraim restarted that evaluation around 4 hours ago, no activity
<podiki>well the evaluation completed at least, but no builds
<apteryx>I think we need to again contribute some of our time to better understand what's going on, hopefully getting clues at what's to fix
<podiki>if I remember at least one time it was as you said, database queries too slow/stopped
<podiki>but i unfortunately have no idea what is supposed to happen under the hood
<apteryx>I'll take a quick dive in the cuirass code to see if I can see what kind of queries are at faut
<apteryx>fault
<apteryx>seems the component misbehaving would be called the 'remote server', which is not remote
<apteryx>it's tE one dispatching build requests to the connected remote workers
<apteryx>I've checked the remote aarch64 workers were correctly reachable via wireguard already
<apteryx>so it should be able to talk to them
<apteryx>one interesting observation (?) is that this seems to mostly affect the aarch64 workers, not the x86_64 ones?
<podiki>is it not trying to dispatch builds at all (to x86 for instance)?
<podiki>so x86 isn't getting requests to workers, or it is but the workers aren't err working
<podiki>the aarch64 i know we've had issues with at other times, maybe that is why? but in this case no worker is working
<NowAUser-76>Sad news, when I use --share, the application crashes with an invalid free :/
<NowAUser-76>At this point, I am willing to give out a coffee or two for anyone willing to update the package :p
<blum>`guix pull` on my personal guix clone is reaaaly slow. How can i have a faster feedback loop for developing my package?
<apteryx>I think GUIX_PACKAGES_PATH is a thing
<apteryx>GUIX_PACKAGE_PATH *
<apteryx>you just extend the guix packages search path instead of computing your own fork or something
<apteryx>or if it's a package to be added to guix itself, then you simply test if using './pre-inst-env guix build your-package', and run it from the store
<apteryx>or spawn an environment where it's available with: ./pre-inst-env guix shell your-package
<blum>thx!
<blum>apteryx: is there a reason to use ./pre-inst-env instead of setting GUIX_PACKAGE_PATH / -L?
<cbaines>futurile, regarding QA, there's some information about the setup here https://qa.guix.gnu.org/README#org3f37893
<cbaines>it doesn't currently interact with CI
<cbaines>(even though it's for doing CI)
<peanuts>"Guix Quality Assurance" https://qa.guix.gnu.org/README#org3f37893
<attila_lendvai>since i pulled into the gnome changes i'm having a lot of problems. the primary issue is that after password the GUI just hangs, with a simple (unmoving) pointer. restarting elogind gets me back to the GUI login, but once it even froze completely, i had to hard reboot.
<attila_lendvai>it didn't even work when i tried to boot into a previous known working generation from grub. i guess due to some modified/migrated gnome config files?
<attila_lendvai>did anyone else complain? i guess i should search the irc logs...
<Guest69>Hi, I am trying to boot one of my guix systems but it turns out the /boot partition is totally missing its grub files. It only has one file: EFI/Guix/grubx64.efi
<Guest69>The odd thing is I was booting fine yesterday without changing the mapped devices or filesystem stuff in the OS declaration.
<attila_lendvai>ACTION reboots to try again
<Guest69>Further (and not guix related), I am not able to boot with a different physical device that I swapped out for one with the new guix. I haven't investigated the contents of the old /boot yet, but just thought I'd throw that out there if there are some dots I'm not connecting.
<Guest69>Is it safe to run grub-install manually on the Guix /boot partition? I'm in the shell of an install ISO at the moment.
<Guest69>It seems suspicious for me to just run grub-install since Guix's grub is customized... Not sure what to do. Also not sure what could have caused the grub files to disappear from /boot in the first place.
<Guest36> https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024 is there may a recorded session to watch?
<peanuts>"Group:Guix/PatchReviewSessions2024 - LibrePlanet" https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024
<blum>anyways, i've finally got my packaging environment working without needing to pull all the time. just made myself a dir ~/bluix and set GUIX_PACKAGE_ATH :DD
<attila_lendvai>FTR, gnome starts up if i move away my extensions (~/.local/share/gnome-shell/extensions). now, on to finding which one hangs it.
<futurile>cbaines: ah right - yeah remember the diagram - so is there any 'public' way to see if qa is moving along?
<cbaines>futurile, yep, the heavy lifting is done by data.qa.guix.gnu.org, and there's the recent events bit here https://data.qa.guix.gnu.org/jobs
<cbaines>(you can also see more activity here https://data.qa.guix.gnu.org/jobs/events )
<peanuts>"Recent events Guix Data Service" https://data.qa.guix.gnu.org/jobs/events
<futurile>ah cool
<cbaines>I think things are going OK at the moment, although prioritising branches over issues/patches is both good and bad
<cbaines>it's good when it helps to quickly build gnome-team/emacs-team/qt-team when they're being worked on
<cbaines>but it's bad when it's just back to building master over and over again
<futurile>ack - it's really just knowing that the build farm is 'busy' - I personally don't mind waiting if it's busy doing more important things!
<cbaines>the data serivce is separate but related to the build farm
<cbaines>the WIP bordeaux build farm activity page is here https://bordeaux.guix.gnu.org/activity
<cbaines>currently the bottleneck for QA is the data service (and it's generally the data service)
<peanuts>"Activity bordeaux.guix.gnu.org Build farm" https://bordeaux.guix.gnu.org/activity
<futurile>does the data service run on your servers? and then bordeaux builds the patches that I look at on QA?
<attila_lendvai>gedit seems to be broken: "/gnu/store/492487vr2sy5jw3z9z6hqr2wzwp3sw45-profile/bin/gedit: symbol lookup error: /run/current-system/profile/lib/gio/modules/libgvfsdbus.so: undefined symbol: g_string_free_and_steal"
<cbaines>futurile, yep, I have a Hetzner VM (beid) which runs the QA data service. That's part of the problem as even though it's a somewhat powerful VM (32G of memory, 16 cores), that's very little resources when trying to process guix revisions at pace
<cbaines>throwing more resources at this would help
<cbaines>there's the start of a plan for the project to take over the hosting, which I'm hoping will enable a discussion about how to potentially improve this, but it hasn't happened yet
<cbaines>futurile, as for bordeaux, the data service says this patch series adds 2 new packages and changes 3 others, then QA tells the bordeaux build farm to build those new and changed packages so it can show if they build or not
<jakef>i'm rooting for you
<cbaines>(is a rough summary of what happens)
<attila_lendvai>could someone please fast-track this simple version update: https://issues.guix.gnu.org/70133 (gpaste plugin for gnome 44)
<peanuts>"[PATCH] gnu: gpaste: Update to v44.1." https://issues.guix.gnu.org/70133
<attila_lendvai>lilyp, kindly pinging you for this^
<attila_lendvai>ACTION is AFK
<civodul>“The GNOME Display Manager uses Wayland by default” oh!
<blum>what do i have to do to make the "warning: XDG_RUNTIME_DIR doesn't exists" warning go away? manual says i need elogind or systemd or "a similar mechanism". i dont want to use desktop-service, cus this is for a server.
<blum>i'll try elogind-service
<apteryx>blum: if you're going to submit your package for inclusion, ./pre-inst-env makes the most sense since you're working from guix itself, not a e.g. a channel
<apteryx>got hotspot packaged (perf data visualizer)