IRC channel logs


back to list of logs

<podiki>speaking of nss we need to update it
<podiki>i tried but then some of the 14k (or 44k?) tests failed
<podiki>so we should graft nss to latest on master (and ungraft on core-updates or any branch about to build)
<ieure>podiki, You can steal my patch out of bug #67512, it updates it to 3.98 and the build seems fine. It needed an update to the faketime.
<peanuts>"[PATCH 0/5] Add LibreWolf"
<apteryx>we can't graft across a version bump, unless it's a patch release
<ieure>Or from here, same code:
<peanuts>"atomized-guix/atomized/packages/nss.scm at main - ieure/atomized-guix -"
<podiki>don't we just have to check for ABI changes?
<podiki>(and make sure same packagename-version length)
<apteryx>I think so; or do we check for this across minor version bumps?
<podiki>nss explicitly mentions compatibility of 3.x in release notes, for what that might be worth
<apteryx>oh! then a graft would probably be OK
<podiki>i would definitely build some packages and check they graft okay and still work, of course
<apteryx>great! so are you going to work on this soon? or would you rather I try? I don't mind either.
<podiki>if you wouldn't mind that would be great
<podiki>i'll give a quick read through release notes now, but all the version i checked all say 3.x should always be backwards compatible (and forwards if restricting to NSS Public Functions)
<ieure>podiki, apteryx, This is the only thing I had to update in nss to get it to work (other than version/sha):
<peanuts>"atomized-guix/atomized/packages/nss.scm at main - ieure/atomized-guix -"
<podiki>yes, all 3.x is listed
<ieure>Test suite is a real bear to run.
<podiki>ieure: thanks! it even has a comment saying to update it...should have read it
<ieure>podiki, Maybe the comment ought to get moved up near the version, so folks are more likely to see it when updating.
<apteryx>podiki: OK, so I'll try tackling the nss update via a graft
<podiki>thanks apteryx! we have examples in the past from git log, e.g. 3.85 to 3.88 if i remember
<ieure>Or could let-bind it around the (package) form.
<podiki>not sure what we do with nss-certs, also graft? or is that less critical than the actual nss library (and CVEs it has in older versions)
<podiki>apteryx: my thanks in advance for patiently waiting for the million tests of nss to run
<sadie_>do i have to do anything special to use `(which <prog>)` in a trivial-build-system builder? i have bash in my native-inputs but which returns #f.
<podiki>probably need to add the which package
<podiki>trivial-build-system is usually anything but trivial since it needs lots of manual steps :)
<lfam>nss-certs can be updated on master, podiki
<sadie_>would you recommend i use a different build system then? all i need to do is run a shell script and shuffle some files around :)
<podiki>lfam: oh? i see 700 dependents, but i do think for something like this it shouldn't be an issue (certificates), and good to be timely with updates
<ieure>sadie_, copy-build-system maybe?
<lfam>Also, it's almost always a mistake for a package to depend directly on the certificates. Programs should find the certificates from the environment
<sadie_>i will give that a try, ta
<podiki>i'm kind of surprised that many depend on nss-certs
<lfam>Yes, 700 builds... it's 2024 and we should just go for it. Maybe schedule it for a slow time
<lfam>Yeah, it's a common mistake
<lfam>Trying to remember how to find the biggest culprit in terms of reverse dependency graph
<lfam>Which package is introducing the most rebuilds
<lfam>Like, from nss-certs
<podiki>i also vote for more branches: nss should have one as it is security critical and gets updates pretty regularly
<lfam>If you link directl to the certs, then your derivation will expire when the certs expire
<podiki>it just gets a version bump, faketime bump, make sure it builds and then merge. especially as seems mozilla stresses backwards compatibility
<lfam>`cat ~/tmp/local-package-dump | recsel -e 'dependencies = "python-pytz"' -p name | cut -f2 -d: | tr -s '\n' | while read package; do echo $package; ~/work/guix/pre-inst-env guix refresh -l $package | cut -f1 -d:; done | tee ~/tmp/output-pytz`
<lfam>Where the package dump is `guix package -s .`
<lfam>Well it broke. But you can get the idea
<lfam>Ah, just had to do s/dependencies = /dependencies ~ /
<lfam>podiki: The java packages are the culprit wrt directly depending on nss-certs. icedtea / openjdk. IIRC that is old news
<lechner>lfam / ++ on finding certificates in the environment
<podiki>lfam: thanks. i think there is a question about python (or something in python) and how they handle certificates as well
<lfam>Oh yeah
<podiki>let me find the message somewhere i had...
<lechner>lfam / re borg
<peanuts>"View paste RZXA"
<podiki>lfam: python-certifi bundles certificates, and we could do as debian to use our nss-certs
<peanuts>"debian/patches/0001-Use-Debian-provided-etc-ssl-certs-ca-certificates.crt.patch ? debian/2023.7.22-1 ? Debian / python-certifi ? GitLab"
<podiki>efraim has some patch about this (i don't think submitted) but i'm behind on the email from some time ago
<ghisvail>is there a way to send the result of the failed compilation when installing kde using the guix system dev image?
<ghisvail>all I am getting is an error message reporting the compilation failed, but no idea if or how I can get the actual logs
<lfam>I see lechner. I think you should look into / ask how the environment is set up for these timers, and see if you can add ssh to it
<lfam>That's ripe for fixing podiki
<lechner>lfam / okay, thanks!
<peanuts>"Some packages depend on nss-certs, some bundle it."
<lfam>It's a similar issue to tzdata, the time zone database
<lfam>I guess it's one of my pet issues
<podiki>certainly agree things should and can be better there, no argument from me
<lfam>Yeah, didn't mean to sound like an argument. It's just one of those things
<zilti>I tried setting up Flatpak on my machine by calling flatpak add-remote, but all I get is "Can't load uri While fetching [77] Problem with the SSL CA cert (path? access rights?)"
<freakingpenguin>zilti: Might have something to do with missing the nss-certs package?
<podiki>maybe need flatpak --user ? (we only run as user)
<zilti>freakingpenguin: I thought so as well, but it is clearly in both the system config.scm and the home config
<zilti>podiki: the command I am running is "flatpak --user remote-add --if-not-exists flathub"
<freakingpenguin>Hmm, that does run on my machine so it /should/ work fwiw
<podiki>i've done it before, long ago
<zilti>I have another machine with the same config where it worked. But this machine here was freshly installed yesterday
<freakingpenguin>Is it on a recent Guix commit? If it's 1.4.0 nss-certs might have a bunch of expired certs.
<zilti>I'm on latest
<freakingpenguin>I have run out of ideas and will proceed to my backup plan of crossing my fingers for you.
<zilti>Maybe it will resolve itself over the next days. Thank you nonetheless!
<podiki>zilti: if you didn't already a logout/login or restart might help if it was just after an install and env isn't seeing all the new stuff
<zilti>podiki: I did do that, but thanks for the reminder :)
<podiki>ah. mysterious
<efraim>podiki: I can grab the patches I have for unbundling ca-certs from python and send them to the mailing list
<podiki>efraim: that would be great. sorry i never responded to that email (I don't think?)
<efraim>I sent it to the guix-security mail because I wasn't sure if it was a security issue or not
<podiki>I think that was fine, but also since this is known and Debian patches, a public patch is also good
<podiki>i would have basically just said that, just kept pushing it back sorry
<efraim>I have some really old emails I keep meaning to reply or work on, it's not just you :)
<podiki>i have been known to finally respond to a (personal, social) email like a year or two later :(
<podiki>but i have a system of sorts, it was never lost or forgotten!
<podiki>thanks in advance efraim! off to bed now
<efraim>SLEEP WELL
<cbaines>qt-team has been merged, right?
<thaenz>good morning
<peanuts>"Request for merging "qt-team" branch"
<efraim>cbaines: yep
<cbaines>cool, I'll update the issue
<civodul>Hello Guix!
<efraim>oh, I see mesa-updates has a request to merge. I was thinking of sliding one in for rust-team before I go away for Passover
<efraim>good thing I'm testing mesa locally. glslang failed to build on riscv64
<ekaitz>efraim: i have some thoughts about your guix.vim thing... I'm a neovim user and I have treesitter configured. Your guix.vim package is great but it changes the filetype and screws up the treesitter highlighting for scheme
<ekaitz>and in guix we have very large files, so the default vim highlighting is not good
<efraim>Are you sure it affects scheme files and not just ones with filetype=guix?
<ekaitz>only the ones with filetype=guix, but the scheme highlighting is better than the one provided for guix
<ekaitz>and guix files are just scheme after all
<efraim>I was never happy with the highlighting I setup
<ekaitz>maybe instead of playing around with the filetype, you can internally detect and leave scheme as the type
<efraim>also I bet there's an option to tell treesitter to consider 'guix' files as scheme
<ekaitz>that could be, too
<efraim>the reason for changing the filetype to guix was so I wouldn't pollute the scheme namespace for other scheme projects with all the guix function names. Perhaps I can use the same filetype detection, leave the filetype as scheme, and then only add the extras on the specific files
<efraim>currently it specifically looks for guix.scm, manifest.scm and /etc/config.scm
<ekaitz>i see
<ekaitz>that you could autocmd for, too, right?
<ekaitz>using a pattern match
<ekaitz>i'll try to take a look into that
<ekaitz>or even make a similar plugin for neovim in lua
<efraim>so I think that would mostly be the syntax bit
<efraim>I was thinking of rewriting that part, taking inspiration from syntax/chicken.vim and syntax/scheme.vim to fit better in with extending what's already there
<efraim>anyone know why we dropped the i915 driver from mesa?
<mekeor>does anyone know if unmatched-paren is fine, healthy, sastisfied, happy, content, doing well? haven't heard much of them lately
<tschilp>Hi guix! Any gnome-users online? I'm wondering how to get the gnome-screenrecorder working on my guix system laptop. On my work-laptop running debian bookworm I hit the print-button on my keyboard and then can chose whether to take a screenshot or do a screenrecord. Here I only see the camera-icon, but no screenrecord-icon. My workaround until the change to wayland shortly ago was to use the tool 'simplescreenrecorder', but it does
<tschilp>not support wayland. Maybe I'm just missing a package or two, would be happy about a hint!
<rekado>just a reminder: the certificate timebombs still exist in our more recent JDK packages. I only fixed them up to a point.
<rekado>openjdk11 was the last I touched. See commit 3bf2465faa85b8a14b1cedaad43e2c2d0337cf6b for how to fix the other JDKs.
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<efraim>looks like the asahi driver for mesa needs libclc
<dariqq>tschilp: From what i learned from a quick online search the screenrecord mechanism is handled through a dbus service and playing around with d-spy says that org.gnome.Shell.Screencast has some errors. hmm
<efraim>I was able to enable screensharing on sway by adding the home-pipewire-service to my home-config
<rekado>I have home-pipewire-service but the gnome screen recorder does not work
<rekado>(i.e. I can only take screenshots, no videos)
<dariqq>ACTION wonders where to find dbus logs
<dariqq>all i get is : Process org.gnome.Shell.Screencast exited with status 1
<mfg>Hi, has anyone tried to package intels compute runtime (maybe in some custom channel)?
<zilti>Oh no, `guix system reconfigure` acts as if everything is okay, but doesn't do anything anymore. I hate when this happens
<zilti> is overwriting the /etc/guix/channels.scm, wtf
<tschilp>dariqq, efraim, rekado: thanks for your feedback. I've decided to set 'Gnome on Xorg' at login, so I can use take screenshots using gnome and (in the rare case that I need it) use simplescreenrecorder as screenrecorder.
<efraim>I hope screenshots work for you in that case :)
<efraim>in unrelated news, the debian time_t64 transition is far enough along that I was able to install debian on my second ibook g4! soon I should have another ppc build machine
<tschilp>efraim: screenshots do, it's just recording my strange screen-movements :)
<tschilp>dariqq: how did you call org.gnome.Shell.Screencast at all? did you search /gnu/store for it?
<rekado>zilti: that's expected behavior when guix-configuration has the channels field
<rekado>see the manual chapter 11.10.1 Base Services
<nowcubed>A beginner question: The default in Guix is to compile the package that the user wants to install beginning with Mes and Gcc etc. up to the package. Right?
<nowcubed>(Of course if the binary cache - whatever that is called - is not specified.)
<dariqq>tschilp: Via D-spy
<dariqq>but i have no idea how dbus , etc works and was just messing around
<zilti>rekado: I hadn't even set that field, but it seems it has (always had?) a default. Then again, there is no information at all how to set it. Apparently, just putting there what I'd put in channels.scm does not cut it, I get errors about undefined variables when I do that
<zilti>Seems like I am not the only one with that issue
<peanuts>"[PATCH 0/2] Add channels field to guix-configuration"
<tschilp>dariqq: thanks, I did not know about this tool so far!
<zilti>So I have no idea how to set that field, and there is absolutely no documentation about it either, apart from "it exists"
<zilti>The whole thing is falling apart anyway now, geez... Can't log in on the console anymore, sddm is only a black screen, where will it end?
<fnat>Any recommendation in terms of a startx-like script for Guix? I've been using the script mentioned in this thread and that's served me well. However, some Guix native solution would be nice. Anything I've been missing?
<peanuts>"[HOWTO] Start X server manually instead of using a login manager"
<efraim>have to figure out fixing the wifi on my second ibook g4, but for now it's using the ethernet cable from my pine64 and is building packages
<zilti>Where is "channel" defined?
<freakingpenguin>Hi Guix! Noticed on 188d18fc47 SDDM gives a black screen. Anyone else encounter this? Here's the sddm.log:
<peanuts>"debian Pastezone"
<freakingpenguin>Seems like it's might something to do with sddm-helper talking to PAM? PAM normally prints "Conversation with 1 messages" after preparing to converse.
<zilti>Franciman: I have not seen my logs yet, but yes, I also just get a black screen from SDDM since yesterday evening
<zilti>Seems no one on the entire internet has ever used the `channels` field in `guix-configuration`. At least I didn't find any example using any of the usual search engines when looking for peoples' dotfiles
<freakingpenguin>c9cd16c630 works fine, so it's one of the commits in between that messed up SDDM.
<freakingpenguin>zilti: I think guix-configuration-channels was added very recently? Like, last few weeks.
<zilti>Ah, I have to `#:use-module (guix channels)`
<apteryx>ACTION can never remember how to use define-deprecated
<tschilp>mhm, since my yesterday's update from 66b20dc567ed9801ab55209fc412e4db92d7b0b0 to f26b42f6c07a00dd2cecb006846e672b88748b84, it seems I cannot access ~M-x magit-status~ anymore, also ~M-x magit-clone~ does not seem to be available. Quite some magit-commands are still there, but not the ones, I'd be using often. Looking at ~guix pull --news --details~ I cannot make out that magit itself has changed, nor my completion package vertico.
<tschilp>It's just emacs going up to 29.3, maybe too new for magit?
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<rekado>zilti: can you share your system config? Otherwise it's hard to figure out what you're trying to accomplish and see where you're failing.
<civodul>tschilp: i believe a fix for Magit autoloads was pushed yesterday or so, no?
<civodul>at worst, M-: (require 'magit)
<dariqq>dbus-verbose in verbose mode is appearently really verbose. I now have a 350 MB log file
<efraim>that seems a bit excessive
<tschilp>civodul: thanks, maybe I pulled too early yesterday, will do now :)
<dariqq>but no mention of the org.gnome.Shell.Screencast :(
<tschilp>I guess I just should restart my emacs. pressing RET after an expression in ~Eval:~ just brings me to a new line, not executing anything...
<tschilp>mhm, now I've put ~(require 'magit)~ into my init.el, I've never used that before, but it works!
<zilti>rekado: sure, here:
<peanuts>"guixconfig/config.scm at master - guixconfig - Gitea: Git with a cup of tea"
<futurile>Afternoon all
<anemofilia>Hello, I am trying to make greetd use the $SHELL of the user when logging, but my user services simply don't start when I do so
<anemofilia>When I run the ~/.guix-home/on-first-login script manually, every user service but wireplumber start
<anemofilia>~/.profile seems to be sourced by the shell normally though, since all my env var set using home-environment-variables-service are being properly set
<blum>Good morning
<futurile>mornign blum
<cdo256>If I am packaging where an upstream test is missing a header, should I create a patch to add the header or try to add it with substitute*?
<cdo256>Or something else?
<cdo256>I'm creating a patch for it, but I see that substitute* is used a lot more than patches, so I want to check whether I should prefer that to patches generally.
<futurile>cdo256: doesn't actually make any difference AFAIK, it's just a question of personal style.
<futurile>cdo256: I personally find it easier to read substitute* for small stuff like that - but again, possibly personal style - I don't think there's a hard rule
<cdo256>Okay, substitute* it is then
<Noisytoot>The cl-caveman package is broken: you can't actually load it unless you also install cl-project and cl-dbi. cl-project and cl-dbi should be added as inputs.
<euklid_the_guix_>Hi. I'm still very new to guix. I am not so sure how I configure my keyboard layout. Currently I have one user. To change the layout in the current session (what I want), I used this command:
<euklid_the_guix_>setxkbmap -layout us. However, this layout change only affected the browser and not my actual terminal. I also used "loadkeys us" with root priviledges, but this didn't change anything.. What do I do now?
<zamfofex>euklid_the_guix_: Are you using a DE like GNOME or Plasma?
<euklid_the_guix_>I use sway
<df>the terminal possibly requires a restart for it to take effect?
<euklid_the_guix_>didn't help, no..
<df>sway is apparently a wayland compositor so maybe your terminal is using wayland and that's configured differently (I'm just guessing wildly here)
<cdo256>euklid_the_guix_: Sounds like a sway configuration issue. Maybe have a look at
<peanuts>"Home ? swaywm/sway Wiki ? GitHub"
<euklid_the_guix_>Ok I will have a look. Thanks
<df>this might be helpful, it's from a sway user:
<euklid_the_guix_>Ok. Got it now. Not sure why I didn't figure it out myself.
<lechner>Hi, what does the --check option do in 'guix build' do, please? Locally, it just links to an existing build via graft. Thanks!
<lechner>Specifically, I'd please like to force a rebuild and keep the sources. I had envisioned --check -K but that does work. Thanks!
<lechner>sorry, does not work
<rekado>"-K" only keeps the build directory when there is a build failure
<rekado>"--check" reruns the build (use with "--no-grafts" to avoid just building the graft derivation); with "-K" it keeps the "-check" output when it differs from what you already have in the store.
<dlowe>I had a file in /etc/guix/channels.scm that's been replaced with a symlink into the store. The docs say I can put the file in ~/.config/guix/channels.scm but I'm suspicious since there's a symlink called current in that dir
<dlowe>So ~/.config/guix/current/etc/guix/channels.scm?
<dlowe>The presence in the store would suggest that there's some store-using tool to manage channels now but I don't see one.
<dlowe>(thanks for saving the previous contents of channels.scm to channels.scm.bak)
<cdo256>lechner: I use something like (add-after 'check (lambda _ (exit 1)))
<lispmacs[work]>it seems that gnome shell just switched to wayland, but know I've got a real bad latency problem
<lispmacs[work]>some tweak I need to do?
<cdo256>Though this won't show any of the installed files, and it's a bit of a nuisance to do if you need to do it a lot
<lispmacs[work]>am a little confused - wayland does not appear to be a dependency of gnome-shell
<dlowe>nope, ~/.config/guix/channels.scm still works. who knew
<mfg>Is there a particular reason why our llvm package does not contain
<rdrg109>[Question] I'm reading the Info manual "(guix) Using the Configuration System" and I have noticed that in the operating-system example configuration, the following is shown under openssh-service-type: (openssh openssh-sans-x). Can someone explain me what does that line does? I tried reading openssh-configuration in the Info manual, but the field "openssh" is not listed there.
<mfg>rdrg109 it specifies the package you want to use as openssh for that service
<mfg>you could use a custom openssh package with (openssh custom-openssh)
<rdrg109>mfg: Thanks, got it!
<jpoiret>rdrg109: most services have such a field
<graywolf>Hello, I installed guix home on a foreign distro, and am having problem with locales. It seems that GUIX_LOCPATH is missing the ~/.home-profile, any idea why?
<graywolf>I just did guix home import, guix home reconfigure, so maybe I missed some step?
<futurile>graywolf: I don't use guix-home - but presumably it wants the locales package installed?
<graywolf>I have glibc-locales in my packages in the home configuration. And in the ~/.guix-home/profile/lib/locales I do see the files
<graywolf>But the env var GUIX_LOCPATH does not seem to be adjusted to include ti
<graywolf>So I wonder if I did something wrong, or it needs to be done manually
<futurile>you have to source it under normal conditions - but I don't know about guix home - I suggest you search the user mailing list
<graywolf>K, will do, thanks
<lechner>cdo256 / thanks!
<lispmacs[work]>hi, it appears that gdm has switched now to wayland. the latency was really bad, though, so I had to roll back. Do we still have the option to use X11?
<lispmacs[work]>or is there some way to fix the latency issue?
<lispmacs[work]>looks like Kruse just changed the default gdm-configuration to enable wayland by default
<lispmacs[work]>Kraus I mean