IRC channel logs
2026-02-12.log
back to list of logs
<Guest22>so /gnu/store/zbpx8jn4spc1p1k54ylzxs6l5chycwd2-guix-module-union/share/guile/site/3.0/gnu/packages/linux.scm is a generated file? <Guest22>so this is on the ungoogled-chromium package maintainer? If they had needed a specific version of pipewire (other than 1.5.85) they should have specified better? <mange>Guix doesn't have package maintainers, so there's not really an individual responsible for the issue. <mange>It does have "teams", but they're a bit different to package maintainers. <redacted>And, when people update packages (like pipewire), they're expected to check whether dependent packages still build anyway. <redacted>Which should mean we don't need to pin dependency versions. <ieure>I've been trying to get CI to build a branch for close to a week, it claims it's polling, but it's not picking up any changes. Anyone have an idea what's wrong? <pomel0>sorry for the very late question, but does anybody know where should I look for terminfo? <pomel0>usually it's in /lib/terminfo but /lib is nowere to be found in guix <Rutherther>pomel0: In Guix profiles you installed the given terminal to, ie. /run/current-system/profile or ~/.guix-profile. Its either under lib od share, I forgot <pomel0>Rutherther: nice, it was in .guix-profile, thanks :] <Rutherther>ieure: has it always been configured to use your fork? I have been having troubles with getting Cuirass to pull a new repo to the cache, to populate it from 0. I always just aborted and resorted to guix pulling as cuirass user first. In case the cache is not populated yet, it could be this issue. <efraim>TIL I have 27 million files in my /gnu/store <futurile>efraim: woah, you don't like using 'gc' much huh - "just in case" you'll need it later for one of the alternative architectures? <efraim>I'm fairly convinced that 'guix gc' clears the newer derivations first. and I'm afraid of needing to rebuild packages on slow architectures <efraim>also my store currently takes about 275GB on disk. btrfs compression works nicely <efraim>but yeah, I need a new plan, it's just too unwieldy <untrusem>efraim: so I should just add this bit and reconfigure? <efraim>untrusem: that should be enough to compress new files <efraim>untrusem: According to the online btrfs documentation setting 'discard' isn't a recommended flag since the default is discard=async <mthl>Hello I was reading (guix elf) module header and notice the following comment <mthl>-;;; This file was taken from the Guile 2.1 branch, where it is known as <mthl>-;;; (system vm elf), and renamed to (guix elf). It will be unneeded when Guix <mthl>-;;; switches to Guile 2.1/2.2. <mthl>Does it mean it should be removed now since Guix requires Guile 3.0 <graywolf>Hi :) How can I build a package *without* some input? Something like --without-input transformation (does not exist). I have tried --with-input=pipewire= , but that is not valid <janneke>graywolf: possibly you could replace the input with something harmless? <janneke>--with-input=evil-library=hello ? -- yuck? <graywolf>Right, will replace it with hello and see how the build goes <graywolf>untrusem: ungoogled-chromium, it does not build on master for couple of days already (we really need some CI...) <janneke>graywolf: although i think there's value in a proper solution for what you need <graywolf>pipewire seems to be the problematic library, and I do not use it, so I thought I would just try to build the package without it and see it it works by any chance <graywolf>So, follow up question, how can I use hidden packages for transformations? --with-input=pipewire='(@ (gnu packages linux) pipewire-minimal-1.4)' does not seems to work... <janneke>graywolf: no idea, but civodul is really missing something this afternoon :) <Rutherther>graywolf: you cant transformations work on specifications. Use guile with package input rewriting or inheriting package directly <Deltafire>if a project build includes the command "npm install" (which pulls down lots of dependencies) then i guess packaging for guix is probably not feasible? <orahcio>Deltafire: There is node-build-system on guix manual. I think you need to change the "npm install" phase to a "guix build" phase of the node.js packages in the inputs list <orahcio>But I am trying to package one project with go dependencies in the middle of build phase, and I am studying about that yet <EmeraldsOfDawn>curious if this methodology makes sense for updating a package in gnu/packages/rust-apps.scm <EmeraldsOfDawn>I have been trying to update tealdeer with just a simple package definition but running into issues with rust dependencies <futurile>EmeraldsOfDawn: if you intend to send a PR, each commit has to apply to one package only. <futurile>EmeraldsOfDawn: and you'll need to check that you didn't break dependent packages <futurile>EmeraldsOfDawn: this is one of joys of Rust in particular <ArneBab>Is there a GCC based alternative to MESA llvmpipe for software rendering? It’s annoying that even a system built completely with GCC still requires LLVM. <EmeraldsOfDawn>I understand, not sure I'm anywhere near PR ready. I'm specifically not doing tealdeer 1.8.1 as it adds a new req and I just want to get it working first <EmeraldsOfDawn>I'm realizing there are build issues as likely a substitute was done for the standard package version 1.7.2 <EmeraldsOfDawn>so building 1.7.3 without a substitute is causing some issues esp with the rust dependencies. <EmeraldsOfDawn>Do I need to list out package specs for every dependency? I have use guix import to generate the dependencies from the correct lock file <EmeraldsOfDawn>(I realize quite a few are unnecessary and I should strip say the rust windows archives) <futurile>EmeraldsOfDawn: there's no need to make the dependency graph more complex than you need to <ieure>EmeraldsOfDawn, `guix build -L' doesn't work in the guix repo, you need to follow the instructions in the manual, `(guix)Building from Git'. <EmeraldsOfDawn>futurile, yes I'll be working on that, I was aiming to look thru and see if I can find what specific dependencies the guix packaged version uses already <futurile>EmeraldsOfDawn: if it's just for you to start with you can do a 'guix import', put it all in a single file and use '-L'. I've done that for some Rust things where I knew I had a load of dependencies. Weird that 1.7.2->1.7.3 means a lot of new dependencies. <EmeraldsOfDawn>futurile, likely isn't a lot of *new* dependencies but since I do an import on the source cargo.lock it picked up everything (not just for the target platform I think) <EmeraldsOfDawn>oh strangely enough, anyone got a clue why all of a sudden I get frequent ssh disconnects? <vagrantc>i have a hunch codeberg is doing the "send notifications for every pull reqquest and issue regardless of what groups i am a member of" thing again <theesm>vagrantc: can confirm, at least it's like that for me as well <vagrantc>i wonder if it is assumptions on the structure of teams.scm, as i have two entries for "Vagrant Cascadian" ... one for reproducible builds and one for other things, but both with the same codeberg username ... and i recently joined a team <vagrantc>theesm: in other news, seems like the kernel-updates job is stalled out on aarch64, but otherwise finished ... and the failures *mostly* seem to be the wrongly built architecture mismatched packages (e.g. linux-libre-arm64-generic being built on i686-linux) <vagrantc>theesm: do you think it is worth pushing the default-to-6.18 and 6.17 removal too? i noticed some 6.17 packages got built in that evaluation <vagrantc>seems a waste of build resources to continue building an EOL kernel... <EmeraldsOfDawn> if I modify %desktop-services I don't need to include it right? My understanding is modify returns the whole thing (with my modifications) so it would be duplicated <vagrantc>theesm: i might have suggested pushing the default-to-6.18 and 6.17-removal in a single pull request, since they are interdependent <vagrantc>theesm: oh, i see you included the 6.18 update in the 6.17 removal... <identity>EmeraldsOfDawn: correct, ‘modify-services’ returns the modified list of services <theesm>vagrantc: i think just merging the combined PR should work, i'll close the other one <theesm>the recent kernel update PR from the 11th is still WIP btw as i'm still waiting for deblob scripts to be available <theesm>if you'd like to you could push the removal/updating-default thing, as you said there's no point in wasting build resources on EoL kernels <acid-bong>evening. about git checkouts as Guix origins and channels: why are they performed in HOME/.cache instead of the store? i mean, i understand the channels, cuz Guix is large and git-cloning it every time, even shallowly, is expensive, but isn't it less secure than, say, the Nixpkgs' fetching directly into the store? <Rutherther>meatg1rl: I would advise against installing toolchains. Anyway to obtain that toolchain use one of the make-arm-none-eabi-toolchain from (gnu packages embedded), ie. a one liner "guix shell -e '((@@ (gnu packages embedded) make-arm-none-eabi-toolchain-12.3.rel1))'" <Rutherther>acid-bong: the checkouts are used for authentication and since they're already available, why not also use them to vendor the given commit to store... that's what's happening <acid-bong>but, auth aside, is there a chance of something on my user's behalf to interrupt the checkout and track some extra files before the repo is consumed by the store? or does Guix take care of that somehow? <Rutherther>acid-bong: not really? I don't really understand why you would do that, just make your own channel and use that one <acid-bong>Rutherther: welp, only if some kinda malware is running in the background, laucnhed from my UID. otherwise, as i just understand, the outside access would be no different than exploiting a nixbld* user and using its builddir <acid-bong>anyway, i know too little about security, so i might get something wrong and it's not so bad after all <Rutherther>acid-bong: If malware was running as your user in the background, it would also probably be able to modify your shell so that you run programs it wants and not the ones you want. And so it could replace the guix you run with custom one that will give you a different channel, no matter if the channel is actually pulled by guix-daemon or your user <Rutherther>acid-bong: really if there is already a malware running on your computer, there isn't much protection for that, it has infinite possibilities of reaching its goals <mra>ieure: howdy! finally managed to semi-fix my bouncer <mra>back to having some free time to continue my quixotic quest to get eyes on #3369 <ieure>Sounds like the next Ubuntu release. <mra>lmao, guixotic quest indeed <mra>isn't there a company called guixotic? <mra>typical of me to need the joke explained <FuncProgLinux>oh lol I named my main config the same way (quixotic) but for other reasons lol <EmeraldsOfDawn>is it possible to pass arguments to the *service* when running herd restart *service*? <EmeraldsOfDawn>I was thinking herd restart (service --ARGS) would work but herd doesn't like it <Rutherther>EmeraldsOfDawn: sure, just herd restart service arg1 arg2... and so on. Note that this passes the args to the start of the service, same as if you did herd stop service && herd start service arg1 arg2... <Rutherther>...so if you meant to pass the arguments to the stop function, for that you will need to do it manually, herd stop service arg1 arg2... then herd start service <EmeraldsOfDawn>Rutherther, yeah I think its then due to sshd and herd both having a -d argument <EmeraldsOfDawn>I have not, wasn't quite sure how to specifically feed the args to the service and not herd <Rutherther>EmeraldsOfDawn: also what sshd service are you actually talking about? The one in Guix does not accept any arguments <ieure>I had no idea you could pass arguments to Shepherd start/stop procedures from the CLI. <Rutherther>yes, you can. I use it in a wayland service that gives out the wayland display to other services. And it takes the wayland display as the argument, so it's something like "guix start wayland-display $WAYLAND_DISPLAY" <mra>bdunahu: i was just taking a look at your PR #4542. it looks good, but it seems like Rutherther was the main reviewer on it? <fhang>Hello all. I am attempting to package a Kotlin application for Guix. It uses Gradle as its build tool. Are there any packages using Gradle in the Guix repository that I can use as reference? Guix does not seem to have a `gradle-build-system`. <bdunahu>thank you mra. yes, I would especially appreciate it if you could look again Rutherther <bdunahu>I also had a question yesterday if the comments left by the guix importer about checking bundled sources were meant to be addressed and removed if possible before PRs like this are accepted <EmeraldsOfDawn>I don't have a custom one, I'd just like to restart sshd with debugging to diagnose something <Rutherther>EmeraldsOfDawn: I see. Well then, no one programmed this behavior in the service. It doesn't pass through arguments to the command it runs. <Rutherther>bdunahu: sorry but I don't really have anything else to comment on that PR. I am not sure about exact solutions about bundled blobs. So I just left it for others. Other than that it's good from my side <Kolev>Hi all. I was wondering how to upgrade my server. I haven't updated it in a year or more. <Kolev>It runs Guix System, of course. <ieure>Kolev, `guix pull && sudo guix system reconfigure /path/to/your/system/config.scm' <ieure>After the pull, if you have a user profile: `guix package -u'; if you use Guix Home, `guix home reconfigure /path/to/home/config.scm' <ieure>system reconfigure will upgrade kernel, services, anything in your system profile. package -u / home reconfigure will update your user profile. Correct command depends on your setup. <futurile>janneke: do you read guix-help? did you see the email from someone who's tried manually following the 'full-source' bootstrap - may be of interst to you ... <Kolev>ieure, I don't know how to save those commands in a Bash script because one command is normal and one command uses sudo. <tux1c```>sudo is just a regular command, so you can write "sudo ..." for whatever you want & it will eventually execute that and prompt for a password and so on <ieure>Yep, sudo in a script just asks you for the password. <ieure>I use Emacs for everything, so I have abbrevs, `gxrc' expands to `cd ~/projects/dotfiles; sudo guix system reconfigure system/$(hostname).scm'. <ieure>You could do the same with a shell script of bash alias. <lilyp>yaaaaaaaaaaaaaaaaay, rust 1.88 broke on gnome-team thanks to disk space (fml)