IRC channel logs
2026-05-08.log
back to list of logs
<civodul>csantosb: this newfangled emacs-forgejo thing is awesome! <mwette>I just got a hash mismatch for bootst-0001-unordered-fix-copy-assign.patch. <mwette>civodul: thanks; I guess I should check there first. <civodul>looks like the fix hasn’t been pushed yet (?) <kryptec>has anyone else had trouble accessing a guix vm from emacs with tramp because tramp couldn't find ls? <kryptec>I updated the tramp-remote-path variable with the path to the correct /bin on the guix vm, but still no luck <kryptec>Nevermind, I tried a couple days and got it working right after I ask of course. <cdegroot>something similar happened to me today: projectile-find-file comes up empty on a tramp session. Probably something similar. It was work stuff so didn't have time to go debugging before I punched out :) <kryptec>wouldn't be too surprised, running tramp-cleanup-connection ended up solving it for me at least :) <apteryx>I thought I could record screen with the GNOME screenshot tool; looks like I can't today. <apteryx>how do I mark an issue as read in codeberg with fj.el? Just visiting it is enough, like on the web page? <apteryx>looks like this is how it works; the notifications list does not refresh automatically until you hit 'g' <apteryx>hm, closing an issue in fj.el: error in process filter: fedi-http--process-response: Wrong type argument: number-or-marker-p, nil <apteryx>fj sadly feels a bit flimsy compared to the good old debbugs-gnu.el <apteryx>ACTION uses this as a good excuse to switch context <aloys>Hello Guix community, I'm new. Coming from nix, and very happy to use scheme over nix. <kryptec>welcome aboard! Though I'm also new, so probably the last one to be rolling out the welcome mat :P <kryptec>I think the chat is largely european, which affects the hours people are on here <aloys>No worries, good to know. I'm in down in Oz. Anyway, just popping in to say hi. I might have a few questions in the coming days. <theesm_>created an issue to track mitigation of the newest kernel LPE: https://codeberg.org/guix/guix/issues/8430 even though i'm still not entirely sure if we should wait for a fix or try to proactively mitigate (maybe by providing kernels sans those modules built-in) haven't looked at it properly yet <jlicht>theesm_: is this a "what about second breakfast?" thing, separate from CopyFail? <adanska>is there a way to ungexp just a plain record? I keep getting an 'Invalid G-expression input' if i try to ungexp a record in a gexp. It seems to work for more primitive types like lists and strings, so is there some mechanism here that is preventing this? is the gexp compiler trying to lower any records it finds to store items? <dariqq>apteryx: I made an issue for the screencasting bug (looks like a gjs bug) <gabber>how do we compare to other distributions in package count? <m4xxed> Hey, if I want to build a local guix repo where I have a commit that upgrades some troublesome emacs packages that required some commits and then use this guix repo as a source for my `guix home reconfigure`, how would I do that? <m4xxed> If I `guix pull` with the channel argument set to a file that has the guix channel set to my local repo url, then for some reason it does not actually use my new commits, but always goes for the latest `origin/master` commit... do I need to sign the commit or smth similar? <m4xxed>(but `guix home describe` shows that it uses the local url of my repo, so somehow this worked partly...) <gabber>m4xxed: not sure i understand 100% but i think you could patch your local checkout and do something like `guix time-machine --url=path/to/checkout -- home reconfigure config.scm` but i've never tried that <m4xxed>gabber ok, I will try that. Thanks :) <gabber>the better/proper way were to upstream the changes, since you seem to address something others might be interested in, too <m4xxed>Yes, I want to upstream those changes, but I wanted that one fix immediately and didn't want to go two routes (redefining the package in my home config and use that instead + creating a PR and wait for the merge ) <m4xxed>gabber Isn't what I want to do something common? I always assumed that some people stay on other branches like the `rust-team` branch with some local changes permanently... <gabber>the simple answer to your question would be to build the local checkout and then do `./pre-inst-env guix home reconfigure` <gabber>i think the team-branches are more for people to work on larger parts of the package-base, like when updating for example an interpreter or compiler brings *lots* of changes for many dependent packages. not necessarily because people want to reconfigure their profiles with not-yet-mainlined packages <m4xxed>gabber daaamn, I forgot the `pre-inst-env` route... thanks! <m4xxed>gabber the time-machine route worked, thanks! <gordon1>is there a straightforward way to have guix installation with custom patched (gnu packages package-management)? i feel there is no way of actually transforming it from the config, is it? <gabber>gordon1: what `guix installation'? patched how? what exactly are you trying to do? <gordon1>gabber: i mean the machine with guix system, lets say guix vm run with .qcow2 from the website. I am trying to achieve guix installation free of avahi <gordon1>from my limited understanding, i guess i have only way of making a private guix fork and patching it there in the code, there is no way of using some transformations from the config? <ieure>gordon1, If you don't want to run avahi, remove the service from the list of services in your operating-system. <gordon1>it will be build tho, i don't want it to be built <ieure>gordon1, The Guix support to allow it to possibly run will be built, avahi will not. What reason do you have for this anatagonism against avahi? <ieure>You are correct that if you want Guix not to know that an avahi package or service exists, you must fork Guix and delete the code. I genuinely cannot think of a single reason you'd want to do so, though. <gordon1>it's not avahi per se, i want to have a way of vet the software that i do or not have on my system, with other software i have a way of transforming other packages and removing it from inputs, but it seems that guix package manager is special and i cannot do that there <gabber>if you want to be in total control on what gets installed on your system, i'd suggest you abstain from %default-packages and %desktop-services and the like <gordon1>i probably would do that, but it's more about dependencies (i.e. inputs) of other packages more than about what is in the top of hierarchy <gabber>which inputs of what packages are you talking about? <gordon1>e.g. dbus, pulseaudio, at-spi2-atk, eudev <gordon1>many packages depend unconditionally on dbus but many of those can work perfectly fine without it for example <gordon1>i think last time when i tried to make a private fork, there was some difficulty with running guix like that not in the development setup, since it wants all commits to be signed, i wonder if there is a workaround for me to have a branch of main guix repo and just rebase one or two commits every time i want to do equivalent of doing guix pull? <gabber>IIUC these packages are usually built against some libraries (e.g. dbus) so they could interact with dbus but they still work without it. if you build it locally you might still need dbus as input. but you could craft a `foo-sans-dbus` package at ease <ieure>gordon1, Right, if you remove the avahi (or whatever) package, you will also have to patch or remove any other packages which wanted it. <gordon1>sure, i know that, i think i'll do something like (package->manifest (map ...) package-specifications) with package-input-rewriting, i think that worked last time, or something along those line <gabber>packaging rust stuff is quite the PITA—or am I doing it wrogn!? <gordon1>but yeah, i think that's less of a problem than the issue with guix package manager, but it looks like it has conditional for hurd to build itself without avahi so i assume the only change i need is to remove it from inputs and no other code modification is required <gordon1>is there a way to add a local patch to the guix code without commiting it into the repo? <atw>I believe some packages have .patch files alongside them (sorry that's vague, I haven't packaged in a long time) <atw>sorry, I don't think that's what you were asking; ignore my message <gordon1>yeah, i guess that's a chicken-and-egg problem, in order for me to use it, it has to be commited to repo, even if i'll add it to (gnu packages package-management) <meatoid>hi guix, what is the guix equivalent to /etc/skel? <meatoid>i'd like to define the default 'guix home' environment and home dir layout, without having to define users in the system config <gordon1>tbh i am a bit puzzled, there is an official chapter called "Using a Custom Guix Channel", which shows how you can replace guix with your own fork, but then it mentions that there is channel authentication you need to address, however when i read "Channel Authentication" and "Specifying Channel Authorization" chapters they mention introduction, and second one even mention the question "how do i fork <gordon1>existing channel" but do not address how to do that, it only tells how to throw away existing root of trust completely, which makes it impossible to pull commits from upstream after the fork is done without updating .guix-authorizations and re-signing every single commit, am i missing something? <sham1>Let's see how long it takes for my laptop to run `make` on the guix repo. I just hope that after I've done all this stuff, I'll be able to start pushing my contribution to a PR for real <untrusem>it takes around 30-40min on my t480 i7 8th gen <podiki>you can run make -j<n> for big speed up (though i think there is some reproducibility for the actual guix built like that, but unless you are changing guix the package i think it doesn't matter) <sham1>Yeah, thankfully I'm going going to touch "guix-the-package" for now. Like, technically I guess I wouldn't necessarily need to build guix for my change, but I kind of would like to have a test for it <podiki>indeed, was just looking at that. web interface still loads for me, slowly or after a few retries <csantosb>We definitely need something lighter; all is becoming heavy weight. <untrusem>codeberg is down but their ssh service is up so should be fine <untrusem>JohnDawson: maybe some network issue, can you try again <JohnDawson>I have tried several times in the last hour, but I will try again. <untrusem>Does your network connection allow IPv6? <podiki>i reconfigured earlier today without issue, the error you have suggests some network connectivity maybe (or is your system clock very off?) <podiki>shouldn't be an issue unless your computer was off or asleep for a very long period (and then the wrong date/time causes ssl certs to fail sometimes) <JohnDawson>server 51.89.151.183, stratum 2, offset +0.041354, delay 0.07843 <JohnDawson>server 162.159.200.1, stratum 3, offset +0.038382, delay 0.06586 <JohnDawson> 8 May 16:26:18 ntpdate[4729]: adjust time server 51.89.151.183 offset +0.041354 sec <theesm_>untrusem: codeberg ssh seems to be down as well right now, at least it seems like it on my machine <sham1>Is it normal for `tests/syscalls.scm` to take a long time <PotentialUser17>Hi. I'm interested in hearing your opinion: do you create a partition if your new filesystem will encompass the full disk? <sham1>Yes. Makes it more interoperable with other things <ieure>PotentialUser17, Partitions are required for the system to boot, the UEFI has to load the next stage of bootloader payload from the EFI System Partition (ESP). <zyd>When installing a package via Guix (just normal `guix install foo`), are the substitutes it pulls in what's needed to build the package? Haven't used Guix in a while so I'm forgetting a lot of things. <zyd>Also surprised by gnome-backgrounds seemingly being needed when installing TrenchBroom lol <PotentialUser17>I recall reading that BTRF's subvolumes were better than fixed partitions, and they recommended to lay the filesystem on a disk without partitions. I have also used EXT4 on bare (non-bootable?) disks without issues, but I notice I have been inconsistent and I would like to address that going forward. So, the consensus seems to be to employ a partition table. <Rutherther>zyd: only when you would need to build, ie. the package has not been built on the build farms. In case the package itself can be substituted, you get only dependencies it uses during runtime, not dependencies necessary for build <zyd>Rutherther: is there a way to make this explicit in some way? <zyd>Like when one or the other kind of substitute is being pulled in <ieure>PotentialUser17, At minimum, you need a partition table for the disk you boot off. Disks other than your boot disk can have no partitions. However, partition tables add very little overhead and carry helpful metadata about what kind of stuff is in the partition, so it's common to have one even on disks where you have a single partition taking 100% of the space. <ieure>PotentialUser17, Partition tables also give you flexibility, you can shrink the filesystem, then shrink the partition, then create another partition on the disk, if you like. You cannot do that if you put a FS directly on disk. <ieure>PotentialUser17, I don't know about btrfs, but even ZFS, which manages the entire disk for you, creates a partition table for its own use. <identity>you can freely resize btrfs volumes, if that is what you are talking about <aldum>PotentialUser17: yes, create a partition table <aldum>negligible overhead, and a PITA to create later if you start needing it <sham1>Technically if you're not into using UEFI (which is getting more difficult by the day, but hey, it's possible) you could technically make your whole disk into an LVM physical volume, and you'd get most of the advantages of partitioning but yeah, it's not portable <sham1>As for BTRFS subvolumes being preferred to partitions: yeah. However, that's orthogonal with having partitions. You can (and should) have a partition table even if you are partitioning your stuff with BTRFS subvolumes <sham1>Hm. Codeberg really is having some trouble <aldum>I'm currently doing doing ZFS for root with MBR, there's still a partition table and a small boot partition <vagrantc>ci.guix.gnu.org seems to be doing a good job cranking through kernel-updates!