IRC channel logs
2024-04-04.log
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. <apteryx>we can't graft across a version bump, unless it's a patch release <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>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 <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 <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 <podiki>let me find the message somewhere i had... <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 <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 <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>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. <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 :) <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>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 <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>that you could autocmd for, too, right? <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. <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>...it 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>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 <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? <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 <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? <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? <dariqq>dbus-verbose in verbose mode is appearently really verbose. I now have a 350 MB log file <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! <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 <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>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 <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? <df>the terminal possibly requires a restart for it to take effect? <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) <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! <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 <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 LLVMgold.so? <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) <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 <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]>looks like Kruse just changed the default gdm-configuration to enable wayland by default