IRC channel logs

<loquatdev>I apologize if that doesn't make a lot of sense. I'm having trouble wording it since I'm not sure of the proper terminology.

<loquatdev>I have a package/store item and I need to read the contents of it and pass it to a service during reconfiguration. There, that makes a bit more sense.

<loquatdev>I feel like I need to use a gexp but I'm not sure how exactly that fits in this scenario.

<apteryx>interesting, this proposes a FHS 4 that would take into account store-based systems like Guix and Nix: https://gitlab.freedesktop.org/FHS/fhs-spec/-/merge_requests/4

<podiki>i think someone sent this to guix-devel but was missing the link? i'm very behind on the list

<podiki>attention all, please guix pull, update, reconfigure, and reboot due to a graft in glibc with security implications

<trev>substitutes aren't ready yet for glibc?

<podiki>should be by now i think

<trev>building /gnu/store/ksfvbqr6mxawra4jisd7gn2dv3g92a6z-glibc-2.41.drv...

<trev>my worst nightmare

<yarl>Hello!

<trev>HELLO

<futurile>Morning all - morning yarl, trev

<yarl>Hi futurile

<csantosb>Morning Guix ! This is just me, or the red button with new failures is something new ?

<csantosb> https://ci.guix.gnu.org/eval/2132798?status=failed

<csantosb>Feel like Cuirass is getting better !

<rustyguix>hi

<rustyguix>For packages already deployed in production environments, how can we assess how the glibc related security flaw affects our deployed packages?

<rustyguix>Hmm, ok, does the following assessment look correct to you all: "The vulnerability affects the build environment, not the firmware output. During Guix builds, if an attacker could control GUIX_LOCPATH, they could potentially exploit SUID programs in the build sandbox."

<yelninei>Hi, could the core-packages-team branch get rebased on master? There seems to be a merge conflict in copyright headers.

<rustyguix>Any updates on the progress with merging the rust-team branch?

<cbaines>rustyguix, where is "firmware output" coming from?

<futurile>rustyguix: https://qa.guix.gnu.org/ - useful link - it's first in the queue and andreas messaged on the ticket

<rustyguix>futurile: thanks

<rustyguix>cbaines: let me rephrase the question with: Is it accurate that the potential glibc security flaw mainly affects build environments, and that previously built packages are not affected, as long as they don't depend on glibc?

<cbaines>I don't believe so, but I don't have a complete understanding of it

<yelninei>*every* package depends on libc. If it only affects the build environment a graft would not solve anything

<rustyguix>yelninei: cbaines: The context I'm concerned with is rust embedded firmware that has been built, targeting a baremetal target.

<trev>when you download a file like /nar/zstd/m4kzaik6ki4nszzqg7p1l062i69vx79x-linux-6.18.10, can that be imported with guix archive?

<yelninei>does your firmware use the guix libc at runtime?

<thomas90>Hi there. I have some questions related to cuirass and hope somebody can help me: I recently setup an experimental Guix channel for specific use-cases with software for electronic design automation. I also setup a cuirass CI to build substitutes. This works basically. However, I repeatedly run into the problem that some package fails to build

<thomas90>(because of memory limits or disk space) and then I can't restart the build anymore once the problem should be solved. For example see https://ci.f-si.org/eval/320?status=pending . This build failed because the substitute of vtk@9.6.0 was not available, then it tried to build vtk from source but didn't have enough memory. Now I reduced the threads

<thomas90>and if I build it manually works fine. I tried to restart the build, but it remains 'pending' for many hours. What am I doing wrong? The specification of my server is here: https://codeberg.org/fsi/reproduceables Thank you!

<yarl>Someone uses guile-ares-rs/emacs-arei? I would like to know how.

<yarl>(for guix of course)

<csantosb>thomas90: I'm not familiar with Cuirass, but there is an ongoing related discussion, see https://yhetil.org/guix-devel/87o6ltzyal.fsf@inventati.org/

<csantosb>Maybe pinning to a 1 week or so guix commit would improve the situation for you

<csantosb>By the way, using the same alias here and in codeberg helps to identify people, just saying

<yarl>I use theses https://paste.debian.net/hidden/9c272bc8 and https://paste.debian.net/hidden/226e6cd8 but I wonder if there is a simpler use.

<yarl>Well, I just realize I could probably run ares inside "guix repl"...

<yarl>I think guix repl needs a -c flag.

<yarl>Am I alone in that case?

<yarl>better for home/system conf: https://paste.debian.net/hidden/bbcc019c

<trev>yarl: look through all the RDE configs...the creator uses guix, emacs and ares-rs (obviously)

<aaavigatori>o/

<yarl>trev: I won't do that.

<identity>yarl: i use ares-rs+arei

<trev>lol

<identity>the ares-rs package should have an ‹ares-nrepl› script, which simplifies starting it greatly

<identity>most of the time i just do ‹ares-nrepl -- -L .› and that does the job

<yarl>I see

<futurile>can you use it with the cli repl (i.e. not with emacs)?

<futurile>I know it's an nrepl implementation, I just assumed you needed an nrepl client of some form

<yarl>Still, when hacking on guix sources, it's useful to give ares-rs access to compiled objects, that's the purpose of https://paste.debian.net/hidden/9c272bc8

<yarl>And when you hack on you config (home or system) how do you get the guix load-path?

<avigatori>what is nrelp?

<yarl>That's the purpose of https://paste.debian.net/hidden/bbcc019c

<identity>avigatori: <https://nrepl.org/nrepl/index.html>

<yarl>futurile: I don't know.

<identity>ares-rs should work with any nREPL client, but the Emacs arei is the recommended one

<avigatori>identity I read that but I still don't understand ._. I am quite new to all of this

<identity>avigatori: basically, it is a network protocol for code evaluation

<avigatori>oh so that you can use the repl on somthing running on e.g. a remote server?

<identity>so you can send (display "hello world") to the server, which evaluates it, and returns the result of the evaluation to you

<identity>avigatori: right, that too

<avigatori>that sounds cool

<identity>but you can also run the REPL concurrently with your program, so you can modify it at runtime

<identity>at least, that is the idea

<avigatori>I was wondering, do people here use geiser to hack on guix or something else? I am quite new to the emacs world etc.

<avigatori>but I have decided to join your cult

<avigatori>for now at least X)

<avigatori>noo, not the ugly emojis again > : [

<identity>i would imagine most people use geiser, and probably guix.el. but ares-rs+arei should work fine, even if a fringe choice

<avigatori>maybe I should focus on mastering org for now :<

<yarl>I personnaly tried geiser some time ago. I could not get xref work. I went to ares-rs/arei when I heard about it.

<avigatori>yarl: do you like it?

<yarl>identity: I'd like your opinion on the two issues I mentionned.

<yarl>avigatori: sure, still, I'm not entirely comfortable with it, as you may have read.

<avigatori>is there a way to force guix to stick to a version with substitutes available? Or maybe denylist particularly big builds?

<andreas-e>I do by hand a "guix package --do-not-upgrade ungoogled-chromium -u ."

<avigatori>andreas-e do you always check guix weather before you install something? Because it has happened to me quiet a few times now that I start unexpected big builds. Like deleting old system configuration generations and suddenly building qemu, or installing quassel and building Qt. I am just wondering if it is my habits that suck X)

<rustyguix>yelninei: it does not use guix libc at runtime as far as I understand -- file /gnu/store/.../*.elf : ELF 32-bit LSB executable, UCB RISC-V, RVC, soft-float ABI, version 1 (SYSV), statically linked, not stripped

<andreas-e>avigatori: I check nothing and then just exclude packages when I notice that there are no substitutes :)

<avigatori>haha, living dangerously too

<andreas-e>Well, there is no risk. When a big package starts to build, I usually exclude it from the update, and then run another update on another day.

<avigatori>What do you all use as IRC clients?

<avigatori>inb4 emacs

<csantosb>Erc

<avigatori>I once was very fond of quassel

<efraim>I still use quassel

<avigatori>efraim how long did it take for you to build it?

<efraim>The server runs on a VPS running debian, but I can check how long it takes to build

<avigatori>that would be neat!

<efraim>I'm also getting nervous that they still haven't had a release using qt-6

<avigatori>Yeah it would be a shame if it became abandoned. It strikes a nice balance between featureful and nice to use for me

<efraim>I also sometimes respond to messages from my phone :)

<avigatori>also, does the guix package give you two binaries, the server and the client or is it the monolithic build?

<efraim>on my 24 core machine it took 70 seconds

<avigatori>:O

<efraim>I get 3 binaries, quassel, quasselclient and quasselcore

<efraim>so I guess the monolithic one and the split client/server binaries

<avigatori>I guess on my potato from 2011 it will take at least 3 days then X)

<efraim>There was a substitute for it also though

<efraim>I can check on my RPi5 how long it takes

<getstate>I've been using nu as my login shell for a while, would there be interest in getting stuff upstreamed to allow people to do that? It would involve changing some things, as well as fixing the 'guix shell --check'?

<avigatori>oh that reminds me: what is the difference between a "core" and a "job" in terms of argument for guix? I head that a job ~= core, but what would be the use of having both options then?

<efraim>core is the number of cores each build can use, job is the number of concurrent builds (and/or downloads) that can happen at once

<efraim>the default is all the cores and 1 job

<avigatori>so if I just specify `-M 2` it means that all builds run sequentially but any one build may use two cores at once?

<efraim>`-M 2` would be 2 concurrent jobs, each of which can use (all) 2 cores on your machine

<avigatori>what is the difference with -j 2 then? Two concurrent jobs but only 1 core?

<efraim>`guix build` doesn't have a -j option, the closest is the -c option

<getstate>Is there anything to prevent adding support? It would mean adding specific paths to support nu, which means it won't be as agnostic.

<getstate>which IIRC was a "no-no"?

<avigatori>efraim: I confused `-M` and `-c`. So would just `-c 2` mean one concurrent build using two cores?

<efraim>avigatori: correct. I normally use the long options for those two myself

<avigatori>efraim ok, gotcha, thank you

<avigatori>getstate what do you mean by adding specific paths?

<getstate>avigatori: Right now, when running certain guix commands like guix shell --check, it spawns a shell and sends a command to run. Right now that command works for fish and other posix shells, but if I were to add support for nushell, then it would have to detect that the shell is nushell, and send a nu specific command.

<getstate>code that was agnostic, would now depend on which shell a user is using.

<efraim>I don't think that would necessarily be a bad thing

<efraim>I haven't looked at it closely, but does it just use bash for a subshell for everything now?

<avigatori>getstate I am no expert in anything, but IIRC fish isn't 100% compatible with posix shell/bash and instead you can specify that a script should execute in a different shell. Maybe something like that could be done for nu, too?

<getstate>nope, it currently spawns the default shell (at least for --check).

<getstate>avigatori: yup! it's not 100% compatible, but sometimes the same thing will run just fine. nu is completely different

<efraim>oh, right, from `guix shell`. I was thinking for other commands. I definately need more coffee

<efraim>I guess it would also work to check the SHELL environment variable and decide based on that?

<avigatori>it definitely sound interesting (to me. Again I have no authority here or in anything)

<getstate>efraim: will try that and look into it a bit more

<efraim>getstate: I meant it mostly as spitballing, I don't know if you already had working code

<efraim>s/had/have

<getstate>efraim: I've mostly just got a script to inherit the correct env (eg: spawn a bash login shell and inherit everything).

<getstate>and mostly just read the environment code, didn't do anything yet.

<getstate>but right now it works for basically everything else

<avigatori>maybe you can open an issue or send an email to the mailing list to gauge if there is interest in accommodating this

<efraim>building quassel on my RPi5 took 15 minutes

<efraim>ACTION goes afk

<getstate>avigatori: good idea

<avigatori>thank you efraim!

<avigatori>I now know why I couldn't download a quassel substitute ... I somehow managed to unauthorize all the substitute servers :o

<identity>yarl: i just bother with neither GUILE_LOAD_{,COMPILED_}PATH, nor the guix load path when hacking on my config (it is pretty much just a list of packages and not much more)

<identity>i probably should figure it out sometime

<avigatori>efraim did you use the default options when building it on the pi?

<yarl>identity: right. What about hacking on guix's git? look at https://paste.debian.net/hidden/9c272bc8, works well. better than letting ares compiles everything again in ~/.cache/guile/

<yarl>WDYT?

<avigatori>Can someone explain why this system configuration https://paste.debian.net/hidden/330e205f would pull gnome-shell and friends? https://paste.debian.net/hidden/0ac90d19 (I had to censor a bit to make debian paste happy

<avigatori>ahh, maybe it's because I still use GDM

<trev>thanks trev for helping me fix my broken guix by having to manually archive --export the linux kernel from a VPS (could locally wget the .nar file! 🥴) and unblock system reconfigure

<janneke>gabber: forgot to say that i support[ed] your interesting experiment, even with me having questions about it ;)

<janneke>and maybe that message was implicit

<untrusem`>So I am getting `guix system: error: EFI bootloader required with GPT partitioning` when I try to make a vm of my config

<untrusem`>here is my config https://paste.debian.net/hidden/8b817ea2

<untrusem`>I have defined the bootloader field though

<ieure>untrusem`, Are you making a qcow2 system-image?

<untrusem`>ieure: the I always test with a `guix system vm` before I reconfigure my system

<untrusem`>~the~ naah

<ieure>untrusem`, `guix system build' should do what you want with less hassle.

<untrusem`>the indentation is messed up because I tangle the file from a org file

<ieure>My experience making system-images hasn't been great, making them 100% declaratively is very fiddly (you have to care about partitions and offsets), and certain aspects of that have seemed not to work properly, so I ended up needing CLI options as well.

<untrusem`>ohh guix build found out the cause

<untrusem`>lol

<ieure>Welcome back, Rutherther.

<Rutherther>Hello, ieure

<Rutherther>been trying to get off so I do not spend too much time with Guix, but I seem to be unable to do so.

<ieure>Rutherther, I noticed you hadn't been around as much, figured you were taking a post-release break.

<Rutherther>yes I am. I was spending 20 - 60 hours a week on Guix for like 2 - 3 months, some weeks more

<futurile>Rutherther: well deserved and good for mental health - don't burn out on a hobby!

<trev>thanks for your work Rutherther

<trev>and nonguix proxy which saved me (but for some reason is missing linux substitute that substitutes.nonguix has)

<ieure>...huh. Something in this commit range broke a ton of Emacs packages in my channel: https://codeberg.org/guix/guix/compare/785cc14...40dbab3

<ieure>Cuirass is not very helpful, they all say "Failed (dependency)" and have no logs at all.

<Rutherther>have you updated cuirass to 1.3.4? that fixed this issue

<vagrantc>anyone have an idea why the evaluations for the kernel-updates branch are effectively getting thrown away? I am concerned about pushing to master and having zero substitutes...

<Rutherther>vagrantc: wdym thrown away?

<ieure>Rutherther, I haven't, thanks for the tip, will give it a shot. I rarely update the box running Cuirass.

<vagrantc> https://ci.guix.gnu.org/eval/2135915 shows most of the kernels as successfully built, but guix weather, guix build, etc. do not have any substitutes for either x86_64-linux or aarch64-linux

<ieure>I generally like to reboot after reconfiguring the system, but that machine is in a different physical location and I have to be there to enter the LUKS password twice.

<vagrantc>i can only guess that some aggressive GC jobs are pruning out the build

<Rutherther>vagrantc: https://ci.guix.gnu.org/bbjlxs7zgmi13s3y44jvyxp2jka1ars2.narinfo as you can see here it's in a quasistate of 'baking it'

<vagrantc>for the last 32 hours?

<Rutherther>vagrantc: I think there is an issue with CI for multiple days, but I messaged to guix-sysadmin and it didn't seem like there would be agreement with me. But I don't know. I don't think it's normal to take so long

<vagrantc>with some builds only as recent as 6 hours, i guess ... but ...

<Rutherther>vagrantc: well the one reported few days ago was librewolf and that took like 16 hours, but I think only restart of guix publish has fixed it.

<Rutherther>vagrantc: as long as it says that it's being baked, I think the store path is there. So it definitely is not thrown away

<vagrantc>hrm.

<ieure>"being baked" is the on-demand creation of the NAR?

<Rutherther>yes, and according to a comment in the code it should take 5 minutes or so

<ieure>I see.

<Rutherther>but it seems it has been taking multiple hours if not tens of hours on at least some narinfos

<ieure>At least on my setup, the time to create it is highly dependent on the size of the NAR. LibreWolf takes a few minutes, most other stuff is pretty much instant.

<vagrantc>also curious if bordeaux could pick up the kernel-updates branch ... that would be a big help too

<Rutherther>vagrantc: you can definitely make a request for merge. But there are 6 teams in the queue now...

<vagrantc>giving at least two reference points to check against ... sometimes one or the other fails to build a given kernel

<vagrantc>request for merge is generaally for things not eligible for pushing to master?

<vagrantc>which, curiously enough, is not the kernel updates

<yelninei>can i rely on the order things are getting substituted with substitute* ?

<janneke>yelninei: yes

<yelninei>so if first "/bin/sh" gets substituted and later a macro that expand to /bin/sh i first need to change the literal to prevent it getting substituted twice

<janneke>yes, i think so...but the computer is sometimes better at computering that /me ;)

<yelninei>janneke: as i am messing with coreutils again, did you see my workarounds to build a newer coreutils-mesboot?

<janneke>yelninei: nope, haven't seet it yet

<janneke>we were stuck, great if you managed to upgrade!

<mwette>janneke, others: I saw nyacc-3.02 was added to mes.scm, pulling from sv.gnu.org. For 3.03, I'm working on package dev that pulls from git at github. Would it be better to be pulling v3 series from github?

<mwette>er, package def

<yelninei>janneke: that is part of https://codeberg.org/guix/guix/pulls/4058/commits , especially i am unsure about why i need to adisable vx2 (there is an error otherwise) and a missing linux header (linux/fs.h)

<yelninei>to test you need a newer gash tarball

<janneke>mwette: sure, if nyacc is moving to microsoft, we'll surely [have to] follow

<janneke>i believe ekaitz fixed the url to github recently

<mwette>janneke: I got tired of moving from gitlab to notabug to codeberg etc.

<janneke>yelninei: 57 commits? wow

<yelninei>some were stolen from apteryx

<janneke>mwette: it's your project, it's your choice -- sorry for being obnoxious

<mwette>here is my shot: https://github.com/mwette/nyacc/blob/dev-3.03/etc/nyacc-guix.scm

<yelninei>and some are probably squashable. This whole branch just got stuck a bit waiting for gash

<janneke>savannah has become next to unusable

<janneke>mwette: nice

<mwette>thanks (coming from a guix rookie)

<janneke>(y)

<untrusem`>how can we make guix select the fastest substitute mirror?

<untrusem`>ieure: `guix system build` is still going on, so much things to download

<Rutherther>untrusem: there is nothing automatic, so you will need to sort them manually to in the guix-daemon --substitute-urls argument

<untrusem`>also tor browser has been without substitutes for like 2 days

<yelninei>ACTION figured out why coreutils 9.9/9.10 were failing

<ieure>untrusem`, I'm not sure how substitutes pick a server in the case of multiple with it. But I don't think it takes speed into account at all.

<untrusem`>now I am thinking about someone proposed pushing commits to master only when a substitute of it is available

<ieure>untrusem`, Debian makes you pick a mirror ahead of time, and has a thing that distributes to all known mirrors, which I think has some kind of (at least) locality routing.

<ieure>IMO this is not something that belongs in the substitute mechanism itself, but it'd be nice to have a thing that would help determine the fastest for you and configure the system to use it.

<untrusem`>Rutherther: so like this https://paste.debian.net/hidden/6d8a7eb5

<untrusem`>will it select guix.moe mirror in last

<untrusem`>?

<untrusem`>seems like it

<untrusem`>I can work with that :

<untrusem`>:)

<cbaines>the substitute script already tries to pick the best nar compression based on those available

<untrusem`>now I am getting 1.8MiB/s rather than 100kib/s :)

<cbaines>it'll also fall back to other servers if the first one isn't working

<untrusem`>time to donate to https://guix.moe, but international payment doesn't work for me like 95% of the time

<cbaines>so it's not much more to get it to try to prefer servers by download speed

<untrusem`>cbaines: what nar compression level does your mirror uses?

<untrusem`>is there a way to see this info for other mirrors as well?

<cbaines>I doubt mirrors offer different compressions or compression levels

<cbaines>the two mirrors I run just offer lzip or no compression, as that's what bordeaux.guix.gnu.org stores the nars as

<untrusem`>ohh I can see guix.moe provide zstd compression

<cbaines>the default substitute servers provide zstd compression as well (at least for some nars)

<untrusem`>now I really ought to donate to guix.moe :D

<cbaines>my unevidenced view is that compression isn't the main bottleneck, but I added support for generating additional compressions to the nar-herder just in case

<cbaines>untrusem`, more importantly, I'm unsure guix.moe is a mirror, I don't know anything about it, but from the description it seems to be a build farm rather than a mirror of another build farm

<cbaines>which is pretty important for security considerations

<untrusem`>hmm, you are right

<cbaines>now having more build farms is great in my opinion, and ideally users would be able to do K of N trust in substitutes

<cbaines>but we're not there yet, and until then getting substitutes from more places increases risk in my opinion, rather than reducing it

<untrusem`>right, but guess I trust hako as they are a quite a contributor to guix

<untrusem`>like the new rust build system and various other things

<acid-bong>evening. what permissions should Guix TMPDIR have? I created a non-tmpfs one with `sudo mkdir` (755, owned by root), but Guix complains about not having permissions

<acid-bong>and on a semi-related note: is it possible to share non-home directories with the `guix shell` container?

<Guest18>anki package is missing. i assume this is because of the issue with packaging rust based software?

<Rutherther>acid-bong: my /tmp is 777. I am not sure this is what is required by Guix, but I would assume so. And I would also think it's necessary by many applications, I think it's sort of assumed everyone can write to /tmp

<Rutherther>acid-bong: you should be able to share any directories with guix shell. However there might be some limitations where you can map them. I am not sure if it will all work well if you for example did something like --share=/tmp/test=/gnu/store.

<mwette>I guess tmp needs to be writable by group guix-daemon.

<mwette>or maybe group guixbuild

<vagrantc>untrusem`: you could just add guix.moe without adding it to authorizations, and then it will download the signatures from the authorized servers, but the content from guix.moe (when the signatures match the contents)

<vagrantc>that is one of the coolest features of guix, in my opinion

<vagrantc>i have a handful of local untrusted machines running guix publish, and they can effectively share substitutes without trusting each other because of that

<untrusem`>vagrantc I have my own channel added there as well, so I would need to authorize to download my stuff from there

<vagrantc>untrusem`: sure, if it is not stuff on the other servers, obviously you'll get no signatures for it :)

<untrusem`> https://ultrarare.space/en/posts/guix-build-farm/#:~:text=8TB-,Helping%20out

<untrusem`>but you are right vagrantc , this is a very cool feature indeed

<untrusem`>btw I manually authorized some keys and they are in /etc/guix/acl reconfiguring my system will change it right?

<vagrantc>think so

<vagrantc>at least, i had that experience in the past

<vagrantc>recently...

<untrusem`>cool, actually is what I want I have declared substitutes in the config itself

<kestrelwx>How come `guix` needs 2 versions of SQLite?

<trev>is guix.moe trustworthy?

<trev>ah nevermind i get it now

<kestrelwx>One from 2022.

<kestrelwx>Oh, so `guix` has 3.39.3 and `guile-sqlite3` has 3.51.0 in dependencies.

<andreas-e>Guest18: For anki, it is not rust that poses problems, but npm.

<mwette>I'm looking into update for guile-libyaml. There are only two files from nyacc used for this at runtime: "arch-info.scm" and "cdata.scm". Better to use nyacc as (runtime) input or copy the files as is done now?

<Guest18>andreas-e: thanks for the update

<vagrantc>ok, at least some of the kernel substitutes got baked finally :)

<theesm>vagrantc: sounds good, there's been another round of updates today btw (prepared a PR already, still have to confirm deblob scripts as soon as they're available)

<vagrantc>we might want to consider updates on occasion :)

<vagrantc>er, skipping updates on occasion :)

<vagrantc>theesm: have you tested 6.18.12 on x86_64-linux?

<theesm>I haven't, am on aarch64 most of the time (but my work laptop is on guix system as well and that's a x86_64 machine, will test it there soon-ish)

<vagrantc>heh

<vagrantc>looks like we should just deprecate the x86_64-linux kernels :)

<vagrantc>i'll test at least 6.18.12 soonish on a virtual machine ... and maybe i can dig out some actual hardware today :)

<theesm>actual x86_64 hardware? so you're going to a museum? /j

<bjc>i don't get it

<vagrantc>you might be thinking of ia64

<bjc>that makes more sense =)

<bjc>though i thought intel was still making that stuff, just in very limited quantities

<theesm>in other news, the 6.19 PR will probably be ready within the next hour-ish, finally got around to create the configs for it

<vagrantc>oh, i was wrong about the substitute being available ... eesh. this is confusing.

<vagrantc>most of the 6.18.12 -> 6.18.13 updates seem to be related to f2fs ... wild guess not many affected guix users? :)

<vagrantc>so ci is ... inconsistantly showing a substitute for linux-libre 6.18.12 ... sometimes it's there, sometimes it's not.

<theesm>iirc that was the update series last week where just one commit was reverted, right?

<vagrantc>theesm: more than one, but yeah, pretty small

<vagrantc>master currently has 6.18.10 ... 6.18.11 has quickly released small changes in under 24 hours ... 6.18.12 managed to last a whole 3 days.

<vagrantc>looks like 6.18.13 has the same deblob scripts ... so ... maybe we should just jump straight to 6.18.13 ... ugh.

<untrusem>all systems updated

<vagrantc>theesm: we also should've updated news for the 6.17 removal (and probably should have waited a little longer with it, but ... here we are)

<vagrantc>theesm: and we should remove 5.4 :)

<vagrantc>theesm: i'm guessing you haven't started on that 6.19.x branch yet? :)

<theesm>i have, i'll create a 6.19 PR within the next few minutes

<vagrantc>oh, yay!

<vagrantc>theesm: opinions on squashing the old versions that were never in master?

<theesm>haven't made up my mind yet on that/on skipping kernel minor-versions

<theesm>i mean it would result in less crunching to be done for CI, but we'd also have to check if series should be skipped or not which would be more work ont he maintenance side

<nemin>Hey guys, if a PR I'd like to see merged has been open for two months and hasn't seen any activity for a month, what's the usual way to step in? Ask in the PR's comments? Open a PR of my own?

<theesm>regarding squashing old versions that were never in master: we could probably do that, don't know if that would have any side-effects worth considering

<untrusem>nemin: ping a committer 😛😅

<vagrantc>theesm: we went through the trouble to vet the old versions (at least somewhat) ... but on the other hard it makes using guix time-machine a little more unrealistic

<nemin>untrusem: Fair nuff, just wanted to make sure. (By the way, I'm still hoping to hear your thoughts on my post :)

<moksh>ahh I know, I just felt as the post is now not on the front page, it won't help that many people but either way I will write to you tommorow

<moksh>nemin: do you know about grafts? I don't think nix have those

<nemin>I reckon Lobste.rs is the kind of site where people occasionally read back threads of up to several years old, so I think there's still merit in commenting. Either way, thanks, looking forward to it.

<theesm>vagrantc: pushed my 6.19 branch -> https://codeberg.org/guix/guix/pulls/6591

<moksh>which team maintains the xdisorg.scm ?

<nemin>moksh: re: grafts, if I understand correctly how they work, the closest Nix equivalent would be overlays. Though I think with those you need to rebuild packages fully.

<theesm>and made an err, forgot to update deblob hashes and kernel hash (didn't think of double checking until now)

<moksh>nemin: don't you miss flakes in guix?

<moksh>like you don't have to do `time-machine` shenanigan for that just run `nix run <something-something>`

<nemin>A little, in general manifests and time-machine feel a lot less intuitive

<moksh>yep

<moksh>you manually have to make a channel file and then specify it

<moksh>it is not a good ux

<Rutherther>nemin: no, that is not the closest equivalent by far. It is very off. The equivalent in Nixpkgs is "replaceDependencies"

<nemin>In general Guix is a lot less intuitive with many things compared to Nix, but I figure that's because of the massive difference in manpower and funding.

<nemin>But if there's one thing that exasperates me, it's Guile errors. They're inscrutable.

<moksh>guix repl -r <file.scm> is my goto at the least then `build'

<nemin>Is there a guide for that somewhere? Right now I'm pretty much just doing an edit -> guix build loop -> fail/succeed loop and it's not super convenient.

<look>Does anyone know why this match-lambda does not work? https://codeberg.org/look/saayix/src/branch/zen-service/modules/saayix/services/home/zen.scm#L102

<theesm>vagrantc: hashes of 6.19 should be fixed now, will now build-test kernels (build-times on rk3588 are quite good luckily) and get a cup of coffee

<moksh>I mean you can use `-K` to keep the build directory in /tmp and debug there as well but it depends on the type of error

<nemin>Oh yes, I've used that too.

<Rutherther>look: because that use-modules does not end up at beginning of a guile file, it's in a nested block. So the interepreter doesn't know to 'sneak in' the ice-9 match macros.

<moksh>\offtopic look, your rust doc overhaul is very nice

<Rutherther>look: look at the actual builder file for the derivation that's failing and you will probably see it

<untrusem`>nemin: I don't think there is an guide for debugging

<look>will take a look, thanks

<untrusem`>*look* will take a look

<kat>i was about to say, that's hilarious

<nemin>👀

<untrusem`>5 people are here, time to put eyes on my 4 months old pr

<untrusem`> https://codeberg.org/guix/guix/pulls/3390

<untrusem`>though I already pinged @wongandj

<untrusem`>so take a look at this instead https://codeberg.org/guix/guix/pulls/6103

<untrusem`>ACTION being greedy

<kat>poor look

<look>thanks untrusem` :) I've been wanting to get back at it and implement some of the feedback, but been busy with more fun stuff e.g learning macros and working on package parametrization

<untrusem`>all the best look :)

<untrusem`>can I change the target branch of a pr?

<Rutherther>yes

<theesm>untrusem`: wl-kbptr looks cool and useful (custom qmk firmware on my keyboard solves the same thing for me though)

<untrusem`>I wanna change a existing pr from master to rust-team

<untrusem`>ACTION wants to see a demo theesm

<untrusem`>I will try to use jujutsu vcs to contribute to guix maybe then I won't have to recompile for every branch change

<untrusem`>I don't want to use worktrees no more

<theesm>there's docs regarding qmks mouse keys feature here -> https://docs.qmk.fm/features/mouse_keys if you're interested in reading about it

<ieure>theesm, I also have mousekeys on my mech board, it's nice.

<nemin>untrusem`: You'll be happy to hear which PR I'm trying to hasten then :D JJ is stuck at v0.32, despite v0.38 being out.

<untrusem`>theesm: I just wanted to see a screencast of how it looks in usage

<untrusem`>ohh nice nemin

<untrusem`>you use jj for contributing

<untrusem`>?

<nemin>No, but I use it for all my other stuff. It's just so much more convenient than git.

<nemin>But, now that you mention, it's not a bad idea to try it for guix. Hm.

<untrusem`>I mean yeah, I want to find out if it would eliminate the need to recompile guix everytime

<untrusem`>I just use magit, thats why I git

<untrusem`>:P

<nemin>Yeah, magit is cool. I was actually hoping to try majutsu, which is magit for jj. But it doesn't seem to be working with v0.32, hence the initiative to update it. Sadly 0.38 will require rust-1.9-something.

<untrusem`>nemin: you are in luck

<nemin>I've seen that it was just merged to the rust-team branch, but that'll still take a little while until it's on master, right?

<untrusem`>I have contributed rust-1.91,92,93

<untrusem`>yep

<nemin>Noice, thank you for your work

<untrusem`>you will need to use inferiors to get substitute for those

<untrusem`>Rutherther: lol to change targe branch for master to rust-team, I will need to rebase the whole rust-crates.scm I am too lazy for it :P

<untrusem`>I will just wait till rust-team branch is merged in master

<nemin>Off, but today I encountered some really weird issues after the mega-graft. Plasma would no longer show up using Wayland and the X11 session was completely borked. I had to roll back a version, then do another pull+reconfigure.

<untrusem`>nemin: you can see which branch will be merged into master through https://qa.guix.gnu.org/

<untrusem`>\offtopic

<untrusem`>ohh damn

<nemin>I guess on one hand, yay for declarative, on the other, it was a little unsettling to see an update nearly completely bork my environment.

<untrusem`>that's why I first test with a vm, its overkill but yeah

<untrusem`>`guix system vm` :P

<nemin>Maybe I should start using that, if only for --news-worthy upgrades.

<untrusem`>hmm good idean

<untrusem`>idea*

<untrusem`>otherwise as ieure told me today `guix system build` is enought to check things

<nemin>Also, if there's one thing I kinda miss in guix, it's seeing an itemized list of upgrades before it commences. (Think pacman or apt's output before you confirm you wanna upgrade.)

<untrusem`>you could do a `--dry-run`

<untrusem`>but yeah its not equivalent

<untrusem`>I switched to kanata from kmonad, its basically qmk but for any keyboard, so with that I removed haskell dependency for my system user :)

<untrusem`>I ought to upgrade it now :P

<untrusem`>why does it try to build the torbrowser, when I see that there are substitutes for it via `guix weather torbrowser`

<nemin>By the way, this is a little embarrassing, but I genuinely am not sure: You really do need to do guix pull with both your normal user and root if you want to do a full upgrade (home + system), right? Doing just one or the other means the channels are only updated for that user, while the other remains on the old version.

<ieure>nemin, No, user only.

<Rutherther>nemin: as long as you do sudo guix system reconfigure, you're using the guix of your user

<ieure>nemin, There are very, very few circumstances where you should ever pull as root.

<nemin>Oh.

<nemin>Well, I guess I'm glad I asked then. Thank you all.

<untrusem`>I mean you don't need to embarrassed, you don't know how many questions I asked when I got into guix and I still too cause I am dumb

<untrusem`>Rutherther: helped me unbreak my system many times

<nemin>Yeah, updating is just such a basic thing, but it's also completely different to what I'm used to. But this will certainly speed things up, calculating guix takes quite a bit.

<untrusem`>yeah in nix you download a 46 mb tar.gz everytime

<nemin>Haha, I don't think they ever really worry about bandwidth and storage space. The size of nixpkgs alone is frightening.

<vagrantc>"guix build --source PACKAGE" and "guix build PACKAGE" are ... building different sources ... in this case it's for linux-libre packages ... is this because they are ... computed derivations or whatever they're called?

<ieure>Computed origins.

<Rutherther>vagrantc: are you sure it's the case? how did you find that out exactly?

<vagrantc>was trying to use "guix build --max-jobs=3 --source linux-libre@6.18 linux-libre@6.12 linux-libre@..." and then a separate "guix build --max-jobs=1 linux-libre@6.18 linux-libre@6.12 linux-libre@..." to build all the sources concurrently (since it is mostly single-threaded) while still have kernel builds proceeding with as many cores as possible, but one at a time

<vagrantc>Rutherther: by running the commands from the same directory on the same machine in parallel

<vagrantc>i swear that has worked before

<ieure>vagrantc, make-linux-libre-source is the computed origin, it takes the upstream origin, deblobs it, and gives a new origin back with the changes.

<vagrantc>the same exact commands running concurrently were buildinng ... different sources

<vagrantc>well, one command with --source, and one command without

<vagrantc>but otherwise identical

<ieure>vagrantc, `guix build -S linux-libre' should do all that and print the path to the deblobbed source, which is the thing `guix build linux-libre' builds from. So there are two source trees involved, and the flow is vanilla source -> deblobbed source -> package

<vagrantc>what's -S do? :P

<ieure>It's the abbreviated version of --source

<vagrantc>the obfuscated version :P

<Rutherther>for me guix build --derivations --source linux-libre and guix build --dry-run --no-substitutes linux-libre produce the same derivations for the source build. This is on like month old guix

<ieure>vagrantc, Can you paste some output of what you're seeing?

<vagrantc>also, --derivations ... does not print the derivations, it just goes ahead and starts building

<vagrantc>or rather, it prints the derivations and starts building

<Rutherther>probably because of grafts

<Rutherther>it will print the derivations once it knows them

<vagrantc> https://paste.debian.net/hidden/9d643c88

<Rutherther>try both of the commands with --no-grafts

<ieure>It's always grafts.

<vagrantc>with --no-grafts https://paste.debian.net/hidden/58860ca2

<vagrantc>wait till you see my dns grafts

<vagrantc>still getting different derivations

<vagrantc>oh, wait ... that's not showing the source at all, now that we're doing the derivations :)

<ieure>Yeah.

<ieure>ACTION wonders if there's a .drv file pretty-printer lurking in Guix somewhere

<Rutherther> https://codeberg.org/guix/guix/pulls/6199 :)

<vagrantc>it was the grafts

<vagrantc>let's see if i can do the trick i wanted to do now ...

<vagrantc>yup, using --no-grafts allows me the behavior i wanted

<theesm>Rutherther: almost forgot about the mail regarding the drv/store interactions commands i wanted to send to guix devel as there's been several codeberg issues discussing the same thing (mentioned in 6199 that i wanted to write one, maybe now's a good time to do so)

<vagrantc>been using guix long enough, and still get stumped by some really perplexing bits often

<Rutherther>theesm: yeah, this is a recurring topic for sure

<theesm>think i'll write the mail now^^ (especially as i'm looking for a reason to finally retire my hacky awful aterm .drv files diff thing (https://codeberg.org/theesm/diff-drv) if stuff regarding store commands land in guix proper one day)

<theesm>(sidenote: aterm .drv files could've been s-exp, always wondered why we kept that format)

<civodul>theesm: diff-drv, i’ve always wanted that!

<civodul>(we use that ATerm format “for historical reasons”… and now it’s set in stone)

<civodul>ah but i think it’s not quite what i want: i’d want a recursive diff, that finds the “deepest” differing input

<Rutherther>civodul: I am waiting for that cuirass evaluation to complete and see no builds on my guix pull :)

<theesm>civodul: recursive diff would be awesome and even more useful (and sounds like just the right weekend rabbithole to jump into and figure out how difficult it'll be to implement)

<Rutherther>hmm, but the profile drv does not match. I am wondering if it's due to the grafts

<ieure>theesm, Suspect the Nix .drv format was retained because it allowed reusing the Nix daemon instead of writing a replacement. Maybe when it gets rewritten in Scheme.

<ieure>Or building in support for sexp derivations.

<theesm>additional support would be nice, but i don't know enough about the internals to assess how possible it is, replacing would probably be a major breaking change though and would never happen(?)

<ieure>theesm, I think replacing it would have to not be a breaking change. I know there's at least some thought/desire to do this work, I'm not sure if anyone has started on it.

<ieure>I swear this channel has the single highest concentration of single-character and common short word nicks in IRC history. Certainly never seen anything like it in 30+ years on IRC across several networks.

<ieure>This mild gripe brought to you by seeing the "m" in "I'm" highlighted as a nick.

<phm>lol

<ieure>Genuinely don't get it, I'd have changed my nick in a day, tops, if I got pinged all the dang time from people writing normal words.

<phm>They like being popular, I suppose

<Rutherther>ieure: or disable the notifications

<theesm>ACTION is looking at what guix graph is doing in hopes to find inspiration for a recursive diff thing

IRC channel logs

2026-02-20.log