IRC channel logs
2025-05-12.log
back to list of logs
<meaty>arch has functionality for this, iirc <meaty>perhaps it could be implemented as a flag for guix locate to send queries to build servers... or the other way around, to ask build servers for locate databases <meaty>eventually when p2p nar sharing is implemented it would solve the issue of allocating query work <meaty>what is the status on that front anyway? <meaty>wasn't there some issue with the way nar metadata was kept that made it incompatible with the way IPFS works or something <JodiMcJodson>hello, I am currently trying to install guix with LUKS on my root drive but it doesn't seem to work. After running `guix system init ...` and rebooting, I get to a grub rescue shell with the error "unknown devie" (with the UUID of the luks partition as well as "unknown filesystem". I'm not really sure what to do, I haven't done anything unusual afaik, my setup looks almost exactly like the <JodiMcJodson>/etc/configuration/desktop example as far as file-systems/mapped-devices goes <nomike>With `guix refresh --list-dependent foo` I can get a list of packages which use `foo` as an import or native import. How can I get a list of packages which inherit `foo`? <jakef>nomike: might have to grep your local gnu/packages. remember to check for (package/inherit...) too <untrusem>what keyring do you folks use, I have setup keepassxc as the keyring, but still having problems opening some program like fractal etc. <civodul>how’s the Whippet + Guile adventure going? :-) <wingo>civodul: a question for you :) in the next major/minor guile version (4.0??), would it be acceptable to read-syntax in a read-hash-procedure instead of read ? <wingo>civodul: pretty well! am incrementally moving all BDW API use to whippet. working on weak tables now. is mostly getting there <civodul>re read-hash-procedure, if there’s a way to write code that can work for both, yes <civodul>it would be nicer to have a transition period where both are recognized, but i understand this can take way too long <wingo>but i would like to move some parts of weak tables to modules, so i am trying to figure out what to do with e.g. the source properties weak hash <wingo>i realized that with read-syntax it is mostly not needed to have a global source properties weak map and that e.g. in the boot reader and expander (read.c / expand.c) i don't actually need to much about with source properties. some users will still want them, so i am planning on an (ice-9 source-properties), and deprecation shims for the default env. but the question is to see if i can get psyntax to not have anything to do with source <wingo>properties and instead just use syntax <civodul>does psyntax still use the source property table? i thought not <wingo>anyway i guess for guix you will be ok as read-hash procedures are a tightly managed thing, and there is read-syntax in whatever 3.0.x guix is using <wingo>civodul: yes, as a fallback, also if you pass it a datum instead of syntax, and it also tries to attach source properties on quoted datums as well (which are otherwise stripped) <wingo>but i think it's just transitional, we can move entirely to syntax objects in 4.0 <wingo>anyway. some more work needed to even see if the new non-bdw collectors are a win or not <efraim>hmm, came really close to rust-bootstrap-1.74 building on riscv64. That'll save days if I can get it working <nomike>I'm in a `guix shell --container --development guix --network --nesting --link-profile` but when I run `./pre-inst-env guix refresh --update spme-package` I'm getting `guix refresh: error: mkdir: Read-only file system: "/home/nomike/.config"` and I don´t know why... <identity>try adding --share=/home/nomike/.config to yuor --container invocation <ruther>nomike: recently there was a change that the root fs in container is read only. Use --writable-root to mitigate it. As for what is guix refresh trying to write, I don't know <nomike>Ahhh...Okay. I knew that this worked not so long ago, so I thought I broke something on my end. And I was worrying why it tries to access my home directory in a build container. <nomike>Didn't sound kosher to me. But now that I know that there was a change, I'm less worried. <efraim>IIRC it tries to write some stuff in ~/.config/guix/gpg while it works over the keyring it makes while checking package signatures <civodul>Codeberg is down; are we a source of misfortune to whoever hosts our stuff? :-) <cbaines>one difference is the number of failed to install locale messages, there seem to be more now <ruther>cbaines: and you're sure it could not have been killed by ie. OOM or manually? Because there are no errors <cbaines>ruther, unfortunately it's hard to tell from the limited information the build coordinator has, but if you look at the timeline for the builds in the data service, they all failed after around 24 hours <cbaines>so I'm guessing they got stuck then timed out <ruther>yeah, seems so from that information <ruther>cbaines: how can I substitute the drv file to try to build it locally? <ruther>oh so plain guix build should work, it's just that it's from different substitute. I haven't realized that <cbaines>I forget if it's a guix-daemon or guix build thing, but if it's asked to build a derivation that doesn't exist, it'll attempt to substitute it first <ruther>great, it's substituting now indeed <futurile>efraim: would you chime in on the GCD conversation, you had an idea about the release branches, and I didn't want to characterise it (see email from ian and my reply) <efraim>futurile: sure, I'll have a chance in about an hour <civodul>futurile: hi! i’m planning to move guix-consensus-documents.git in the next hour or so <civodul>just so you don’t push before it’s done :-) <ruther>cbaines: note that with --cores=1 the build succeeded on my end <ruther>with --cores=16 (default for me) it was taking too long on one part so I killed it <andreas-e>Concerning the codeberg migration, is all it will take for us to edit .git/config and to change the url field of [remote "origin"]? <tusharhero>you can change it using Magit too if you use that. <aldum>`git remote` has a `set-url` function these days (ofc it doesn't do much more than the manual editing of the config) <civodul>futurile: done! you can update .git/config <civodul>futurile: i also your account as “owner” of the Guix org, in accordance with GCD 002 <cbaines>ruther, maybe you could send your findings regarding xz-mesboot to #75518 <futurile>civodul: got, it - yes, that's the correct account <civodul>Codeberg is struggling fetching maintenance.git, i suspect it’s getting 502s :-) <andreas-e>When I click on the repository, it says it is in the process of migrating. So we are in limbo now. <cbaines>I migrated repositories over just by pushing from my laptop <cbaines>given there was only one branch to migrate, that was an easy approach <civodul>ah well yes, i could do that as well <efraim>ruther, cbaines: re xz-mesboot, this sounds familiar <efraim>I disabled parallel-builds for all mesboot-packages for riscv64 <efraim>I think some of the inputs are just fragile <old>good lord offlineimap is again broken <ruther>I don't think it was ever fixed properly <old>I've used a patch on the ML <old>but now it's broken again <ruther>are you sure you're using the patched version? <old>ruther: Yes I have the patch in my home configuration <ruther>old: that's not what I meant. Sure, it's there, the question is if the version of offlineimap you're using is using the patch. :) <old>ruther: yes. It's not the same error I usualy get without the patch <lechner>civodul / are you sure the redirect in #76296 will work? isn't it inconsistent with the HTTPS security model? i think codeberg may have to serve your certificate <ruther>old: it has started somehow, but I don't think the reason you can't pull is that. I think it's the usual savannah being down <sham1>Savannah is clearly out on the pasture <ruther>lechner: why would it be inconsistent? The client will see 302 on one page, so it will go to that one, making completely new https request, the https requests are unrelated <lechner>and for regular Git, I think it is git.git.savannah.gnu.org/ <old>woops I was pulling Guile not Guxi sorry <ruther>guix is going to stay on savannah for one more year as a mirror <civodul>lechner: the patch adds an entry in our nginx instance, which does an HTTP redirect <old>ruther: How will that work with guix-pull? <old>During the initial phase transition. I suppose both codeberg and savanah will be on and the default channel will change <old>allowing for smooth updating, but breaking reproductible script in the future <old>maybe it's possible to keep the savanah link indifinitely and redirect to codeberg? <old>ruther: it was my oauth token that is expired for one of my mail. Offlineimap is not broken (well it is without the patch) <ruther>old: it will work normally with guix pull, the user won't notice <old>but it will break guix time machine? <old>guix time-machine -C my-channels.scm <old>my-channels.scm will have savanah in it <ruther>you mean after it doesn't exist anymore? Yeah, the url will have to be adapted in the channels file <ruther>Or if people are using %default-channels, they won't have to do anything <old>right. So for scientific paper with publication, one need to put %default-channels instead <lechner>ACTION wishes someone like old would rewrite offlineimap <makx>Oh this [migration to codeberg] is cool <makx>Wonder whether that'll get me off my lazy bum and contribute patches <yelninei>janneke the last bison issue is now also solved: it uses weak symbols from libpthread but does not link to it. On linux the symbols are in libc so it is not a problem there <yelninei>i think I have all of the regressions and everything broken now is also broken currently on master <yelninei>hmm, how would I make it that bison-boot0 does not inherit the flag <janneke>yeah, in many cases it's pretty unfortunate for commencement packages to inherit everything from their "normal" variants <ruther>how does local-file decide the directory it resolves from? When I am in root of my repository and run `guix build -L modules package`, I get an error that canonicalize-path cannot find the path from local-file. Then I cd to modules and do `guix build -L . package`, and it works. In second case it is resolved relative from the module it's in, in the first it isn't. The path is boards/kr260/pm_cfg_obj.c, and it's under zynqmp/packages <ruther>folder in modules. So in neither case relative path from cwd matches it. <yelninei>i guess I can strip #:configure-flags from the arguments before they are spliced in which also works if the kwarg does not exist. <ieure>ruther, Are you sure you get an error in the first case? <yelninei>but juggling around arguments to not cause a change in commencement can be very annoying <ieure>ruther, I have ~/projects/dotfiles/home.scm with my home config, files in ~/projects/dotfiles/files, and (local-file "files/gitignore") in the services. When I reconfigure, I get "warning: resolving 'files/gitignore' relative to current directory", but it works. But it only works if the argument to local-file resolves relative to $PWD. <ieure>ex. I can't be in $HOME and run `guix home reconfigure ~/projects/dotfiles/home.scm' <ieure>It *is* tremendously annoying, and I wish it resolved relative to the file containing the `local-file' form. <ruther>ieure: the thing is, local-file is supposed to resolve files relative to the source file, and it does so for me in the second case, but not in the first one <ruther>this is rom news file from year 2016: * ‘local-file’ resolves file names relative to the current source file <ruther>I guess I could just use something like search-path on %load-path <ruther>ieure: btw -L $PWD/modules works fine <ruther>Yeah, but at least I know something to mitigate the issue <ruther>ieure: another bizarre issue is that when I put the modules folder to GUILE_LOAD_PATH env var, the modules are loadable with use-modules, but specifications do not match the packages. Specifications do match only when -L is used <yelninei>janneke: I will need some time to cleanup my local patches (especially the 3 additional libc patches) . civodul also wants to merge the two glibcs again which will be another rebuild for the linux side <ruther>maybe it' intentional, I don't know. There is %package-module-path that is appended with load-path if -L is used, but it wont' be with GUILE_LOAD_PATH <ruther>oh I guess this really is intentional. There is GUIX_PACKAGE_PATH env var and when I set it to GUILE_LOAD_PATH I get a ton of warnings <jakef>Is there a way to force guix build etc to source from software heritage? <identity>jakef: not sure about that, but `guix lint -c archival` should check that there is an archive on software heritage <Kabouik>I'm having trouble enabling full Thunderbolt support in Guix, I assume my port defaults to a secure mode (https://wiki.archlinux.org/title/Thunderbolt#User_device_authorization mine seems to be set to `user` mode) but boltctl (bolt package) sends a GDBus error ("Failed to list devices: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.bolt was not provided by any .service files") <Kabouik>I need TB4 to work automatically since I plug an eGPU to it and it needs to be detected at boot time. <ieure>Kabouik, I see an `org.freedesktop.bolt.service' file in the bolt package. <ieure>Kabouik, Not really sure how Guix manages D-Bus services, but it seems like it's in the right place. Maybe since it's a system service, the bolt package needs to be in your operating-system config's packages field. <ruther>rather it should extend the dbus root service <Kabouik>I am grateful that this IRC channel is here in such cases but I am always having trouble finding how to use those specific packages that require a few lines in the config.scm when there's no corresponding entries in the manual or package description. <ieure>Kabouik, Completely understandable, I agree this is not great. <Kabouik>I have no dbus root service in my config.scm, I'll need to look how it should be set up. I was hoping to use bolt just from guix shell to debug things but I guess that's a no. :P <ruther>you most definitely do have it, in desktop-services presumably <ruther>if you didn't, the error would look completely differently <ruther>it wouldn't be that service can't be found, it would be that you can't connect to dbus <ruther>just extend it with a list that will contain the bolt package <Kabouik>I was saying that because grep dbus returns nothing, but maybe it's called otherwise. <ruther>it's called dbus-root-service-typw <ruther>yes, it is included in desktop services <ruther>Definitely, dbus extensions require a reboot (or rather restart of the service, but the restart is impossible without reboot, or maybe not impossible, but not simple at least) <ruther>a simple herd stop dbus is going to leave your system in an unusable state <ruther>Kabouik: what if you execute libexec/boltd under bolt package (as root)? <Kabouik>You mean from its install directory? I'll check. <ruther>ah, so it needs more setup than just extending a dbus service, a proper service that will make this directory should be made probably. But for now you can just create it manually... <Kabouik>Indeed that helps, thanks. I'll need to extend the service later if I keep bolt, but for now it does not find my TB4 dock (despite being properly powered by it) <Kabouik>Ok found it. No I'll see if bolt can help me make it detected at boot time. <Kabouik>As this is required to use the egpu. <gabber>does anyone here have ideas why QA may use a wrong base-commit compared to the one in a submitted patch? happens i.e. with #78352 <Kabouik>Apologies for bothering you again ruther but I feel this may be a Guix specificity again, not boltctl being bugged. I should be able to authorize and remember a TB device with `boltctl enroll uuid` (https://commandmasters.com/commands/boltctl-linux/) but I get GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action org.freedesktop.bolt.enroll is not registered <Kabouik>Those errors are all but informative to me. <ruther>Kabouik: ah, the bolt package has also polkit rules. So the same way you extended the root dbus service, extend polkit-service-type <Kabouik>Is that the exact same syntax (polkit-root-service-type)? <ruther>it's polkit-service-type as I typed in my message. Other than that it is the same, it also accepts list of packages. <Kabouik>Yeah that worked ruther! I could heard the eGPU fan spinning as soon as I ran `boltctl enroll uuid` and `inxi -G` confirms it's detected. It's even surprising that it seems to work from within my user session while everything I found mentioned this would work only if booted with the eGPU plugged. I suppose that's true when TB4 is set to authorized by default, but boltctl may make it a lot more flexible. <potatoespotatoes>heyo! I've got an image I'm building for some hardware (a mnt reform) and I'd like to define a tmpl file for potential users (and really just to clean up some of this code). I think this is a thing? Searching `tmpl site:https://guix.gnu.org/manual/devel/en/` turns up nothing and the only use of these tmpl files (at least gnu/system/examples/raspberry-pi-64.tmpl) is in Makefile.am. <potatoespotatoes>I'm happy to just define this as a lisp definition, but I was wondering what the point of these tmpl files are and if there is any documentation exists for them? <ieure>potatoespotatoes, ".tmpl" is just a file naming convention, the same as naming it "raspberry-pi-64.example", there's no actual facility for this. <ieure>potatoespotatoes, If you want, you can write a procedure which returns an operating-system variant with all the MNT stuff configured. I use stuff like this for any reusable chunk of operating-system or home-environment configuration. <ieure>Lots of other examples in that file. <PotentialUser-39>Hello. I ran `guix pull` and came across 1056 new commits! Wow! That was impressive! :O <gabber>PotentialUser-39: this mostly depends on when you last pulled <cbaines>gabber, regarding the base commit QA uses, it's always the latest processed revision of the relevant branch <gabber>what's the "relevant branch" of a patch with a base-commit? master/main? or one generated by the QA itself for the patch in question? <cbaines>gabber, if no branch is specified, then the patches are applied to the latest processed revision of the master branch <gabber>is this intentional design or does it just feel like a bug? in my understanding QA were supposed to parse the base-commit string of a patch and use that, no? <cbaines>this is intentional, I'm not sure why it would try and use the base commit <cbaines>maybe that might be useful to know when you're looking at the patch, or when attempting to apply it if it doesn't apply to the current master <cbaines>but it's more important for QA to apply and test against a recent revision of master for which there's data available <cbaines>since this reduces the chance that the information QA provides is out of date <identity>PotentialUser-39: i think it is the R package updates, actually <gabber>ok, it kind of makes sense from the QA perspective. from the patch-review perspective it just seems like odd behaviour <gabber>so, rebasing a patch and posting a v2 should resolve QA issues (at least in that case) <PotentialUser-39>identity I believe you. I notice nothing relevant to packages I have installed. <identity>PotentialUser-39: you should be able to inspect checkouts in ~/.cache/guix/checkouts/ with the usual git commands, if you are interested <PotentialUser-39>`guix pull` does a `git pull`to fetch the new version of the guix code. It also seems to update some core binaries (guix). What else does it do? <gabber>guix pull updates the guix of the profile you are executing the command from <gabber>since guix distributes software from a single repository (the main guix repository also being its main channel), package definitions may be updated, which would result in different builds of the packages in question <gabber>you can invoke a `git pull` like update (without updating the current profile) by invoking `guix time-machine' <PotentialUser-39>gabber Can you think of an intentional benefit in having different guix binaries in different profiles? <ieure>PotentialUser-39, It means each user can have their own state, instead of requiring all users to share a system-wide state. <gabber>PotentialUser-39: yes. this allows to test future releases without tainting e.g. your system with upgraded software/checkouts. <gabber>it is very different to how "classical" distributions handle things, but it's a selling point that (incidentally?) also solves whole classes of problems the other distros might never even address <PotentialUser-39>ieure That is a good one, yes. Thank you. I was thinking of different profiles for a single user but failed to mention that. <potatoespotatoes>ieure: I stepped out for a minute but this looks very helpful, thank you! <PotentialUser-39>gabber Very different indeed. It brings advantages but also disadvantages. <PotentialUser-39>It is annoying that adapting software to run on Guix is such a demanding task. Every now and then I find a bug that I assume is due to assumptions by the programmer or an issue with the packaging. <gabber>PotentialUser-39: what disadvantages are you thinking of? <gabber>what issues with packaging are you talking about? <PotentialUser-39>I do not want to be nagging. I know Guix is a volunteer-made project. It is great, but it is not perfect (like all software). And like all software, it is not the best choice for all, it has its strengths and weaknesses (the learning curve for non-schemers is a bit high). So, that was kind of a disclaimer. I am still making an effort to do some <PotentialUser-39>The community helps, is friendly, but it is not paid support. Some times we are on our own, and either make (at a large cost) it or we give up. <gabber>not sure which aspects you are talking about, exactly <PotentialUser-39>Anyway, I tried to bring some software to Guix. Some automatic tests would not pass due to missing files (FHS is not followed), the build container has the wrong date and time, etc.. I felt bad disabling tests to make it run, but I was not knowledgeable enough to figure what was happening in every situation. That was one of my experiences. <gabber>for me it was kind of a rabbit-hole. it took a while to learn all the features and understand them, but now i'm hooked and everything else feels rather clumsy <gabber>the FHS thing is, well... IMHO a well needed overhaul of a historically grown issue. and relying on timestamps in general is an anti-pattern IMO <gabber>but yes, people here tend to shame the devs who sometimes don't package their software in the real, standardized way <gabber>this may sound like coping, but other distros just opt for non-free software, uninspectable or unreproducible solutions, readily made binaries that may-or-may-not work, etc <gabber>once something is packaged for guix it will for ever be reproducible - at least for that specific guix checkout it was built with. so, with our time-machine we will always be able to make it run <ieure>You can use faketime in your package if there are time-dependent tests. The nss package has some examples. <sham1>fwiw, more and more linux distros are trying to make things reproducible, and plenty require things to be buildable from source <ieure>Agreed that packaging stuff for Guix takes a bit of getting used to. Having done a bunch of Debian packaging work, run .deb repos, etc, Guix is *way* easier in a lot of ways. `guix build blah' and it builds blah, and that's it. No dicking around with pbuilder, pdebuild, chroots, manually installing build-deps that hang around long after they're needed, etc.