IRC channel logs
2026-04-03.log
back to list of logs
<theesm>vagrantc: i've been thinking about utilizing guix system vm to boot test kernels (still would take 40m-60m per kernel to build those, so that's ~7 hours for one architecture if every currently available kernel gets updated) before submitting my PRs <theesm>maybe we should only boottest the latest kernel and the latest supported LTS kernel? wdyt? (and only x86_64 and arm64 architecture wise?) <vagrantc>theesm: i don't feel comfortable pushing updates i do not at least smoke test <vagrantc>theesm: i would be fine with not pushing every update for all 7 current kernel versions ... <vagrantc>theesm: e.g. only do regular updates on the 6.19.x, 6.18.x (maybe 6.12.x) ... <vagrantc>theesm: and then doing less freuqent updates of the others ... <vagrantc>it is pretty hard to keep up with the kernel updates alone, let alone all the other things in the kernel-team space that reviews get asked for <vagrantc>theesm: also like to test on bare metal when i can, but have not been doing that for every update <theesm>yes, update frequency can be pretty high at times... still have a evergrowing backlog of kernel-team & perl-team things i wanted to look into <theesm>am unsure about the updates vs. testing thing... imho testing latest + whatever lts is and relying on users to report if a lesser used version (or version for a specific ISA) breaks could also work (impact of a broken kernel shouldn't be too high as one could usually just select the previous one in bootloader) <vagrantc>they could also just submit updates for older kernels if we don't bother to update them :) <vagrantc>the longest part of the process is generating the source tarballs ... while i like the process of re-applying the linux-libre tooling to generate the source tarball ... i am very tempted to propose just using the linux-libre tarballs directly rather than regenerating them ourselves <theesm>i mean right now that would be more work for me updating only specific versions, as i started to rewrite the maintenance scripts in guile :D it currently only works on all kernels in guix that are announced in kernel.orgs release.json <vagrantc>it uses a huge amount of time and build resources and the CI infrastructure often times out on generating the tarballs ... <theesm>using linux-libre tarballs directly would be good, that would probably also mean we could just use guix refresh for updates <theesm>think i'd prefer that over maintenance script hackery (or fitting such hackery into guix refresh) <vagrantc>i guess i should start a thread on guix-devel about it <theesm>please do so! would there be a technical reason against using the tarballs directly? imho that seems like the better approach <vagrantc>it has been brought up before and the decision was to keep doing it that way... perhaps largely becuase the people doing kernel updates wanted to keep doing it that way :) <vagrantc>there was a discussion of at least some of the merits of both ways ... quite some years ago now <vagrantc>will have to dig up that old discussion at least for a starting point <YAR_Oracool>So. ..I replaced UUID with hardware adress and grub can't boot any more because it can't find the drives. This is ok since I was warrened theat grub might ignore the normal adress. So my question is... how do I make sure it doesn't ignore the hardwar adress or atleast inherit UUID from the priveious config because I can't really do a drop in replacement with UUID <ieure>YAR_Oracool, No idea. Grub has a completely different conception of "hardware address" than the Linux kernel. I really don't understand why you want to use the topological address, UUIDs and disklabels are there to solve the exact problem you caused yourself. <YAR_Oracool>Because if, I copy a config over the UUIDwill be different while I always use the same adress ofr those parts. <YAR_Oracool>So like add a label to the LUKs drive and tell it to look for that? <ieure>YAR_Oracool, Are you copying one machine's config to another often? Why? <ieure>Yes, a disklabel would solve this. <YAR_Oracool>ieure: You mean the incription label or disc name? Because I don't think I can tell LUKs to refer to itself. <mra>I think I've finally completed my bootstrap far enough that I should be able to run guix without using the packages supplied by nixpkgs! <mra>hopefully this solves my problem. now I just need to figure out how to run the copy of guix that I've installed <librelibrecat>but i want to also turn hyperbola's pacman fork called hyperman into a source based package manager by sinking months of engineering time into it <librelibrecat>usernew: hmm maybe everyone reverting to selfhosted git servers is better <librelibrecat>i genuinely believe that everyone should pay for their own data storage on the internet to not load their data storage costs onto others <ekaitz>any profiling "expert" here that likes to answer a few questions? <yelninei>what team would be most resposible for fontutils? <gabber>team localization's scope includes pacakges/font.scm but i am not sure that is the right answer to your question <quassel-guy>Hello, I can't get distrobox to work properly, can someone help me? <czan>Depends what your problem is. :) Can you be more specific? <yelninei>gabber: A patch to have the linux and hurd version have the same linker settings in graphite2 which causes problems for harfbuzz <gabber>yelninei: i have not the slightest clue. kinda sounds like a hurd team thing ;) <gabber>so you want to introduce that patch, need information on that or want to get rid of if? <gabber>sooo... high quality code, i guess? <gabber>i can review it if you want, though i don't feel particularily competent to do so <bjc>content wise it appears pretty straightforward, and would only affect hurd for us <gabber>but graphite2 has ~4820 dependents, so this should wait for a world-rebuild? <bjc>will it trigger a rebuild on linux with the conditionals like that? <bjc>arguments list should be unchanged <gabber>i think the change in question changes the derivation which tells all the dependents to rebuild, but i am way out of my fields of expertise here <bjc>easy to check i suppose <yelninei>it should not change any linux derivations <gabber>bjc: but—to your statement—adding a #:phases argument absolutely changes the arguments field... <graywolf>efraim: Was there a reason to basically disable apparmor for guix-builder? The confintment is now basically nonexistant. (well, I do not understand apparmor much, so I might be misreading the manpage) <gabber>yelninei: could you check and report that? <bjc>gabber: right, but in the non-hurd case, the list shouldn't be any different between the patches <gabber>i am ok with you pushing these changes if you are sure this will not lead to a massive rebuild of packages (for linux-libre systems) <yelninei>gabber: I checked when i submitted it (and the bot agreed, at least for x86_64-linux) <bjc>yelninei: does that bytestructures upgrade fix the gc issues on hurd? <bjc>ok, i wouldn't have expected it to, but hope springs eternal <postroutine>Hello. With the Guix System ISO installer, is it possible to do the installation from an UART interface ? <gabber>postroutine: WDYM? having a machine boot the ISO image and navigating the menus through a serial / uart interface? <gabber>i think that *should* be possible <postroutine>Yes. I wanted to test it with a computer that have no interface for a screen. (No HDMI, no WGA, nothing) <postroutine>But, I don't know if the installer system is already configured to automatically start a TTY on an UART interface. <gabber>postroutine: just give it a try! <gabber>i'd guess it is, but i could be mistaken <Rutherther>postroutine: what architecture are you installing on? <postroutine>> postroutine: what architecture are you installing on? <postroutine>To be more precise, the computer I want to try is an APU2 from PC Engines. <Rutherther>the installer currently supports uart consoles only on AArch64 and only if the device tree properly specifies the uart interface <PotentialUser-99>Hey everyone, noob here with a probably simple question. I am trying to learn guix and have installed the full distro, but I am trying to create a custom channel to contain the modules for my system config. I have split my system config into a base config which I inherit for each "system". But when I created a channel and ran guix pull, it fails <PotentialUser-99>saying there is no code for a module (automation application home) which is another channel that I have created for some bespoke applications I wrote for home automation. I am importing this into my system config but I am not sure why this is erroring as this channel is already added as a system channel. Happy to elaborate if anyone has any ideas. <PotentialUser-99>Thanks in advance and mcuh appreciated for the great tooling if any of the devs are in here <gabber>postroutine: that is a nice board! <postroutine>I can use `gnu/system/install.scm` and I just need to configure, at least, the kernel ? <Rutherther>I cannot tell you what you need to modify exactly to support the uart completely, but you will at least need to add agetty service that will be started on the serial interface <gabber>PotentialUser-99: this error message indicates that one of your channel references the other channel (the one where guix can not find the code to). can you confirm you are pulling from/using all the channels you want to use? <gabber>PotentialUser-99: i usually craft a special channels.scm file to test these kinds of setups. i'd use it with a `guix time-machine -C -- system vm foo.scm` or similar command <Rutherther>see the agetty-service-type that has tty #f, now only for AArch64. That will start on a primary console specified in /proc/consoles. But chances are that on x86 system this will not be populated at all. So you would need to add "console=" to kernel-arguments with the proper serial interface. Then it should work with tty #f. Or you can just set tty to the exact interface <gabber>Rutherther: are you 100% sure this does not work out of the box? i mean most guix images put *something* on the serial consoles, no? <gabber>postroutine: i'd just give it a try and see what happens (if anything at all) and then follow all of Rutherther's instructions <Rutherther>gabber: I am 100% sure. mingetty is started only on "/dev/tty[1-6]" <Rutherther>regular guix installations also start on default console where it potentially could work, but still unlikely without "console=" argument on x86 <PotentialUser-99>gabber it is definitely added as a system channel in the config and it pulled locally. guix describe shows it as well. That is also a great tip, let me give that a shot! <Rutherther>PotentialUser-99: are you sure the channel has correctly specified dependencies on channels it needs in its .guix-channel? Otherwise the channels won't be available when it's being built. <postroutine>Another solution, is to use `guix system image` to produce an image to write on the SD card of the targeted computer. And to use an `operating-system` defined to enable the UART on Grub and on the Kernel. I think. <postroutine>And also to add an instance of `agetty-service-type` on the `operating-system` definition. As suggested by Rutherther. <gabber>PotentialUser-99: you could try to load the module(s) manually with a `guix repl` (possibly from a `time-machine -C channels.scm`) and see how far you get <gabber>maybe there's a typo somewhere (in the module definition or the load statement) <gabber>Rutherther: thanks for the clarification! <gabber>Rutherther: is there a particular reason we do not preemptively expose that to the (x86_64) installer? <Rutherther>gabber: the sole reason is that this has been added like a week before a release, there shouldn't be changes when not necessary that close to a release. But it will not work on most x86 anyway, if any. <Rutherther>with bios 'enumeration' the uart consoles aren't exposed to /proc/consoles it seems. <gabber>Rutherther: because the devices are named differently on different hardware? <PotentialUser-99>Thanks both gabber and Rutherther for the assistance. Will continue my experimentation and learning now! <n|Phreak>is it possible to use guix search to search for the description of a package ? <bjc>doesn't it do that by default? <nckx>That's its intended purpose. Is it not working? (Although if you're looking for fine-grained search settings you might be disappointed.) <n|Phreak>no your right I'm looking HTML::entities , guix search "HTML::*" <n|Phreak>damn I don't think there is a perl package for that via guix <nckx>There's no perl-html-entities package AFAICT. <n|Phreak>bummer , so I supposed I could just use perl package manager then ? but then how can I load that via home configuration ? <n|Phreak>Trying to get irssi notifications via mako <bjc>using home configuration doesn't preclude doing things the old fashioned way <nckx>Had that not been the case I would have suggested you have a go at ‘guix import cpan …’ to add it to Guix, either your own channel or upstream. <bjc>i've taken to putting (package …) directly in my home config rather than a channel <n|Phreak>yeah same I have all my packages in my home configuraton <bjc>it'd be nice to have a lighter-weight mechanism. i think that's the main appeal of nix flakes <nckx>I mean, I do too, but I don't consider it something to recommend to innocent others 😛 <bjc>why? i honestly think it's simpler to deal with <n|Phreak>Its probably better to create a manifest of all packages then import that <n|Phreak>damn i haven't screwed with perl in years also <n|Phreak>no clue how many meta packages I need for cpan <nckx>bjc: If you have some discipline or version control set up it's probably fine. I don't. <bjc>that's a major reason why i like it: it lets me be sloppy =) <bjc>“doing it right” is an arcane ritual that doesn't have a lot of benefits for most people, i think <n|Phreak>ok ,so I can still cpan via home configuration , but how do you call the specific package to install ? I can do it via guix shell .... <nckx>bjc: In theory I strongly disagree in that it does pay dividends that outweigh the initial outlay but I agree with you in practice by being too lazy to do it. Damn it. <bjc>my recollection is that, from w/i the cpan cli, at least, you can: i /pkgname/ <bjc>nckx: i think, in general, as “professionals”, we tend to overvalue process, because it's important for larger-scale projects <bjc>but most people don't want or need that, and just want to add a package to their system <bjc>the most popular programming language is excel for a reason <nckx>I wish you were wrong but you aren't. <n|Phreak>easier to use python, or bash , or anything else <bjc>if you trust their root cert, doesn't that mean they can man-in-the-middle all your tls traffic? <Rutherther>RavenJoad: how did you figure out that you need to trust it in /etc/ssl? That doesn't make much sense to me. These certificates are usually trusted at wpa_supplicant/NetworkManager level. <RavenJoad>bjc: This is only for connecting to the WiFi, I don't think it's used for any connections. But I don't get a choice here. *yippee* <Rutherther>if you put it to the global system certs, then it will be used for arbitrary connections. That's the issue. <nckx>I find it equally strange, but I think Guix System just merges /etc/ssl like any other profile directory, so creating a Guix package that installs etc/ssl/certs/foo and adding it to your system packages with nss-certs should work. <nckx>It is not something I'd ever do. <Rutherther>yes, but don't do it... this is solved at networkmanager level, you definitely do not need to install it like that <Rutherther>just configure the trusted certificate in networkmanager for that connection <nckx>If the university is telling them to install it system-wide or they can't use the network, they are MITMing and just don't want to use the word. <RavenJoad>Rutherther: wpa_supplicant complains that it cannot load the certificate. localhost wpa_supplicant[597]: OpenSSL: tls_connection_ca_cert - Failed to load root certificates error:80000002:system library::No such <RavenJoad>I already added/copied the relevant config back to NetworkManager from the VM. <nckx>Did you add the certificate using the NetworkManager UI to get that error, or…? <RavenJoad>It's PEAP-TLS, and I set the user certificate, CA certificate, private key, and private key password based on what the university tool generated i the VM. <nckx>And who told you to add the certificate to /etc/ssl? <RavenJoad>nckx: No. I just pointed Plasma's System Settings for NetworkManager skin to the relevant files. <RavenJoad>Adding the certificate to /etc/ssl came out of that NixOS discussion I linked earlier who are dealing with the exact same thing from their universities. <nckx>Oh, only about half of those words mean anything to this nmtui user… <Rutherther>RavenJoad: just don't listen to that thread, it's just false that you would need to do that <RavenJoad>nckx: Looking at nmtui, the settings are the same. The key thing was that I di dnot add a certificate to a keyring or anything. <Rutherther>RavenJoad: so how do the settings look like? especially the CA cert colon ... <RavenJoad>I read that thread as: "We made NM/WPA unprivileged. eduroam with WPA-TLS broke, the fix is to make the certificates & keys readable to wpa_supplicant. <RavenJoad>I know, I saw the stuff not being readable as the issue, privileged or not. <Rutherther>and no such file or directory definitely doesn't sound like permission denied <RavenJoad>Rutherther: I don't have it active right now, otherwise I can't talk here from this machine. But CA cert is file:///home/<me>/.joinnow/... <Rutherther>and you're sure the path is correct? Works for me like that <RavenJoad>And it's similar for the user certificate and private key. <RavenJoad>Path was correct, yes. I used Plasma's file picker GUI, just to be safe. <RavenJoad>There may be an issue because I generated these keys in a Fedora VM because *base64-encoded compressed tarball of Python in a shell script* <nckx>I'd assumed it was because Windows, so… win? :-/ <nckx>In that case it seems unlikely to be an encoding issue. <RavenJoad>Unless OpenSSL is complaining that it cannot find the root certificate the university certificate was generated against, since I ran the tool in a Fedora VM, not on my Guix system. <kestrelwx>Somehow docs failed to build on a new worktree. <nckx>RavenJoad: Possible, but it would be by root certificate name, certificate files don't encode a full directory path or anything. (You may know this but just pointing it out.) <RavenJoad>Right. The VM is just a Fedora 43 live image, not even an install, so it may be out-of-date or something too. <n|Phreak>ok so what guix package actually installs cpan ? <nckx>$(guix build perl)/bin/cpan --help <nckx>(Not meant as actual invocation example; this being Perl it probably much enjoys being installed into a profile.) <n|Phreak>oh duh , I though perl was installed by default <RavenJoad>I guess I'll have to keep investigating before June to see if I can figure this out then. <usernew>Rutherther: do you ever use bcachefs on guix? <nckx>They just break it!!1! (☺) <nckx>usernew: I'm about to leave, but do you have a question about it? <usernew>Ther is my bug report and Im trying to figure out who's involved <nckx>Ah, I hadn't seen that but I boot bcachefs and am interested in the module working, so I'll take a look at it later. <nckx>This is not a great answer but if it is this urgent, I'd use an older kernel (linux-libre) that predates the bcachefs removal to rescue the data. <usernew>nckx: thank you for your quick reply <usernew>nckx: by boot do you mean root fs?! Cause if it the case then we should update the manual (and perhaps the installer) accordingly <usernew>nckx: Would downgrade the kernel if bcache weren't so quickly and heavily developed. Awesome if you could help on that! <n|Phreak>How can I get started using the guix repl to learn more about the services and packages , rather than using the guix package -s or guix search command ? <ieure>n|Phreak, What sorts of things do you want to learn? <ieure>I think for most things, reading the source is likely to be a better way to learn than using the REPL, but it depends. <n|Phreak>I thought I could learn more via the repl, but I do see your point looking through the source also. I just thought it would be a better experience , thats all. <ieure>n|Phreak, Like I said, it depends what you want to learn. If you want to learn the Guile API for dealing with packages and making variants, the REPL is great for that. If you want to learn how to make your own packages, or how a particular package works, the code is better. Without more info than "I want to learn," I can't give you great advice. <identity>i doubt packaging Airshipper is a good idea, but also Veloren was in constant weekly-nightly-build state last time i checked <n|Phreak>ACTION ieure makes sense. I think my trying to dip my toes into too much stuff <kestrelwx>But maybe only nightlies/weeklies make sense, I wouldn't know. <kestrelwx>Given they only recommend Airshipper on their website, the tag might not be too useful/ <yelninei>it is so great running tests and they all actually pass as expected, after they have been a minefield for 2 months <nckx>usernew: Not to be pedantic, but you write both bcachefs and bcache. Both exist. You do mean bcachefs, right? Will look at the kernel module tomorrow. I'm supposed to be on holiday. I'm sure I'll fail. <cdegroot>Might be me but if you need help to recover bcachefs because of a small module issue, then you shouldn't have been using it (the bug report is still valid, of course, but please, stick with ext4 until you know exactly what you're doing. ) <nckx>Tonight will be wasted on sussing out a kernel NULL pointer deref that suddenly showed up. G'night all. <nckx>cdegroot: Agreed, but it's presumably our bug, so… <nckx>Btrfs should be out of beta any year now. <n|Phreak>didn't the bcachfs lead dev succomb to the "Sentient" fallacy ? <usernew>nckx: apologies I always mean bcachefs, ny bad <nckx>I think they literally fell in love with reddit_word_frequencies.txt yes. If they are genuine they are not well. Which saddens me. <nckx>ACTION couldn't help themselves and is making guix to test the module. <nckx>usernew: Thanks for the confirmation. I don't use bcache so wanted to be sure. <n|Phreak>Honestly I really don't think it has anything to do with "mental health" more so because it did something they didn't expect <nckx>I didn't mean it derisively. <nckx>Well, there was obvious derision in my message, but it wasn't aimed at the victim. <n|Phreak>I would sum up the word "god" in that same realm <n|Phreak>humans are pattern seeking , which sucks sometimes <usernew>nckx: Your assistance is very much appreciated <nckx>It's an impressive adaption when it works (hell, we still can't emulate it remotely efficiently) but its failure modes can go poorly, fast, especially when exploited with intent. <dan>Hi- trying to run a guix pull on my linode and running into a few issues: <dan>1. it seems to be bootstrapping, even though I've already had a working guix dist on here <dan>2. I have discover=yes set on the daemon, but it's still building mesboot <dan>3. it hangs on downloads intermittently <dan>have been using guix on this machine for a few weeks with no problems <dan>curious if others have this experience when pulling? <n|Phreak>Yeah I noticed others with newer installs are running into guix pull issues <nckx>usernew: Mind you, make might still take all night to finish, so don't expect an answer tonight. Whichever time zone you're in. <dan>also, how many people self host their own builds? wondering how I can avoid the timeouts <dan>ah ok yeah don't need an answer tonight <n|Phreak>I'm thinking of doing it and caching the full repo <nckx>That was for someone else but I hope you do find your answers, dan. <dan>the thing that happened to me is I was trying to run guix deploy and it complained that the target channel commit was younger than the source <dan>ah lol yea, ig i am not "usernew". <dan>anyways... how do you guys usually go about debugging issues like these? <nckx>Your #2 implies that you purposely didn't authorise any ‘external’ substitute servers? Is that right? <Rutherther>dan: apparently you tried to reconfigure the system with an older commit than the one you reconfigured to previously <nckx>That should not be punishable by mesboot. <nckx>Otherwise it should be harmless. <dan>Rutherther: ig whether there is already a version of the mesboot and all the lower level builds that i'm trying to rebuild available on a substitute server? I think I'm trying to pull from substitutes... how do I check whether I've authorized them? <Rutherther>dan: I think easiest is guix weather, that would tell you if you did not authorize them <nckx>The rounded-down answer is ‘does /etc/guix/acl contain anything at all’, it's a good first heuristic. <nckx>Then, more specifically, does it contain the keys in etc/substitutes/*.pub. <nckx>That's etc/ relative to guix.git. <dan>ah I may have overwritten the acl when I was setting up the deployment, I don't see the substitute server ACLs (only mine in /etc/guix/acl) and the "guix weather bash" tells me the substitutes are available but not authorized <dan>will follow the linked instructions <dan>tyvm nckx and Rutherfer <nckx>localhost ntpd[746]: DEBUG behavior is enabled - a violation of any diagnostic assertion will cause ntpd to abort <nckx>Sounds like another thing that probably shouldn't.