IRC channel logs
2025-02-14.log
back to list of logs
<df>oh, it downloaded a substitute for the source! <df>but I still deleted it before retrying <Deltafire>i'm using guix home, but running into an issue where ~/.guix-profile/etc/profile seems to be sourced twice, leading to duplicated search paths <old>df: right or texlive lol <old>df: maye there is a way to do it using Guix's Guile modules instead of Guix CLI <df>it seems like it'd be easy enough to say "never build anything locally, fail instead", but harder if you wanted to find and use some kind of metric of how long something's gonna take to build <struggling-guixe>why would a system reconfigure trigger an "indexing objects"? Sholudn't that only happen with a guix pull or guix time machine? <meaty>How do I do tests on a repo that builds its tests to the same binary target as its main executable? 'guix build $package' can only either build the package or run its tests <df>so there is a 'content-addressed mirror', which I assume is considered separate to a substitute server? <df>I mean, that's good, in general <df>just means my experiment probably can't go ahead <podiki>what's the experiment exactly? you can always use a local file:/// for the source <df>podiki: tbh I've got so deep into yak shaving that I forget precisely :D <df>but I think I was planning to upgrade to the latest girara in order to upgrade to the latest zathura <podiki>i don't know what i was trying to do at first, but there is definitely something different i need to do now to get there! <df>I mean, I know I can probably do it locally with package transformations, but the plan was to do it as patch to guix itself <df>well, I guess I'll investigate whether the git source for girara has officially changed to github (where there is a clone) <podiki>i take it you've looked at the manual page on using a local guix checkout to hack on guix? <df>or if the canonical source is just temporarily down <df>yes, with pre-inst-env? <podiki>the girara package i see on guix,the homepage says github is the source repo yes <podiki>(if that's what you are trying to do, build latest tag) <df>in fact now I think about it, even the zathura upgrade was a means to an end (albeit a worthwhile one in terms of learning to contribute), I wanted to build the latest zathura to investigate some weird warnings <df>ah yes, I see the github link <df>well might as well update it in the guix source <df>so if I'm working on a local checkout of guix and using pre-inst-env, should it be configured with --localstatedir=/var ? <df>and if so, when is it actually necessary to change that? I assume there's a reason the manual mentions it there rather than just having a sensible default <df>is it safe to use make -j with the guix source btw? <gorilla>I'm super curious why subversion is included as a base package <eikcaz>anyone else have the issue where slim only works the first time? As in, if I log in again, exwm starts, but slim launches again over top asking for user/pass <eikcaz>It wasn't critical (because I never log out) so I ignored it, but a year later the problem is still there, and my setup is pretty minimal... <podiki>df: i'm not sure if you need localstatedir, defaults to /var <podiki>df: and yes, i do make -j12 (in my case) so it is much faster <eikcaz>gtk fails to build on aarch64, but I don't know which package requires it in my home environment. Is there a way to check? <apteryx>sneek: later tell civodul re the sysadmin team, didn't this existed yet, but being on the guix-sysadmin mailing list, I should be on it <lfam>eikcaz: Not sure the canonical way to find out, but GTK is a dependency of sooo many things <lfam>If you share your home environment (not sure what form that takes, assume some Scheme declaration) I can help figure it out <eikcaz>The only GUIs I have are ungoogled-chromium, mpv, pinentry, alacritty, and qutebrowser <lfam>`guix graph ungoogled-chromium | grep gtk` -> "140488930426128" [label = "gtk+@3.24.41", shape = box, fontname = sans]; <lfam>Kinda crude but it's fast <dstolfa>i hope that the arm64 chip you're building that chromium on can take some punishment <lfam>Another neat tool: `guix graph --path ungoogled-chromium gtk+` <eikcaz>dstolfa: lol, honestly the only reason it's there is because I stubbornly resists having my mobile and desktop environments differ <lfam>Shows (one of) the shortest path[s] between the packages <lfam>In this case, it's a direct dependnecy <eikcaz>Though I do regularly use qutebrowser on mobile, and that should be similarly large <dstolfa>qutebrowser will pull in much of the same, yeah <dstolfa>but it'll pull in qt over gtk i believe <coyotes4ys>does anyone know anything about famitracker? is there a way to install it aside from just the .exe and wine? <eikcaz>at least in my case, the gtk build failure seemed to propagate from python-pytest-xprocess failing tests. Looks like some of the tests are trying to connect to localhost on some port <lfam>It includes " /etc/hosts with an entry that maps localhost to 127.0.0.1; " <eikcaz>hmm. Hope it's not because my builds are happening in a build container <eikcaz>alright, I ran "guix build -f home.scm --without-tests=python-pytest-xprocess", and I get a message "warning: transformation 'without-tests' had no effect on #<<home-environment>", but then it builds python-pytest-xprocess, including the 'checks phase <lfam>I wonder why the transformation doesn't apply <eikcaz>oh, maybe --without-tests just doesn't support home environments, period <eikcaz>is the guix package in a guix installation self-referrential, or does it point to a previous version? <lfam>Do you mean the package you see with `guix show guix`? <lfam>It points to a previous version <lfam>Compare it to the Guix you actually use, with `guix describe` <lfam>I mean, compare the commits that each version of Guix corresponds to, you'll see the packaged Guix is older <eikcaz>I see. Trying to see if the issue is qemu specific, so trying to rebuild my guix profile but for aarch64 so I can guix copy it over and test. <eikcaz>As much of a hassle as this is, the fact that I can rebuild everything for another architecture with just a --system is pretty bad*ss <eikcaz>also, lfam, I resubmitted that patch <lfam>Yes! I tested it earlier today. I just need to read through the documentation again <eikcaz>in case anyone cared, guix pull --system=aarch64 totally works! (would suggest ussing --profile so it doesn't overwrite ~/.config/guix/current though) <coyotes4ys>hmm, i got a 'tar: This does not look like a tar archive' on doing $tar -xvf famitracker-preview2-x64.tar <coyotes4ys>any experience with that or knowledge of whads going on? <eikcaz>what command did you use to generate famitracker-preview2-x64.tar? <coyotes4ys>i downloaded the 64 bit binary. sorry for the time delays eikcaz <gorilla>If there is anybody here in a position to affect this, I'm a bit frustrated that I have gone through two nearly complete installs now only to have them fail at the end for lack of diskspace. <gorilla>I am left to keep guessing how much diskspace the install requires. <gorilla>It would be nice if it would tell me that I lack diskspace before chewing up a ton of bandwidth and time slogging through the whole download process. <gorilla>I recognize that it isn't known what install I will choose at the time of partitioning, so it isn't a simple ask... <gorilla>Actually, most of the install questions are answered before the partitioning questions, so... <eikcaz>gorilla: how much space are you partitioning? <eikcaz>also, it shouldn't re-download things unless you reboot <eikcaz>You should be able to restart the install process, choosing partition sizes, without rebooting the installation ISO <eikcaz>oh wait, I'm wrong. The cow-store service makes everything write to /gnu of the install, which gets wiped if you re-partition. <eikcaz>gorilla: the exact error would help. And maybe a peek at your system config.scm <eikcaz>(using some appropriate pastbin provider, don't past your config here) <lfam>gorilla: It's definitely annoying. How much space are you allocating? In general, Guix will use a lot of space, way more than old school distros like Debian. Personally I would try to allocate 20 GB to the partition that contains the store for a graphical system, 10 GB for a headless system. <lfam>It's a lot but storage is usually really cheap these days. Of course there are situations where storage is still expensive <lfam>You could even argue that it's best to use a single partition for persistent storage on Guix System, instead of separating / and /home, or similar schemes <lfam>I would call that the happy path <gorilla>I was just trying to create a quick VM with 20GB. That was naive. So I doubled it. Third try is 60GB. <lfam>Wow, I can't believe that wasn't enough <lfam>I would even call it a bug <podiki>when i installed just basic running system (no graphical stuff, just like ssh) it was ~9gigs total <podiki>or actually maybe more like 1.5-2GB (that was full disk image with a swap file) <podiki>the result of guix system init on a fresh disk, but this wasn't installer just using a basic config directly <lfam>Those are the kinds of numbers I expect <podiki>i know when i made a vm image it didn't have space for anything extra, had to do a resize manually <podiki>but i think shouldn't be necessary with the --image-size argument <lfam>For a VM, I recommend using --image-type=qcow2, so you can choose a very large image size, but the actual size of the image file grows as necessary <podiki>yeah that's what i used in that case (just looking at my notes) <lfam>eikcaz: I'm reading through the new documentation. The part that says "[...] will connect to unrelated devices (relays, nameservers) [...]", what kind of nameservers are those? Like for DNS? <eikcaz>sneek, later tell lfam, relays are used to relay file transfers between devices that can't directly connect (e.g. to different LANs), name servers simply list device id <-> global IP address associations. I considered that maybe those should be off by default, but the original service left them on so I didn't worry too much about it <sneek>Welcome back lfam, you have 1 message! <sneek>lfam, eikcaz says: relays are used to relay file transfers between devices that can't directly connect (e.g. to different LANs), name servers simply list device id <-> global IP address associations. I considered that maybe those should be off by default, but the original service left them on so I didn't worry too much about it <lfam>By nameserver, do you mean the Syncthing discovery servers? <eikcaz>oh, did I call them the wrong thing? <lfam>I wasn't sure if you were referring to DNS <lfam>Syncthing calls the device lookup servers "discovery servers" <lfam>I'm doing some copy editing <eikcaz>cool. Sorry to make more work for you XD <eikcaz>looks like I called them nameservers early on, then switched to the correct "global discovery servers" in the actual syncthing-config-file documentation <lfam>So I was copy editing the docs, and I found that I didn't understand something about the patch. When I originally read the code, I glossed over syncthing-folder-devices and assumed it was about finding devices that were implicitly defined in folder configurations. But it's like a special case of syncthing-device that adds the introduction info and an encryption-password? Did I get that right? <eikcaz>There is more information about the relationship between a device and a folder than just if that folder should be shared with that device. <lfam>I'm trying to understand why these two record types can't be a single record type <eikcaz>If I combine the record types, then how can easily include the same device in two folders, when only one should be encrypted? <lfam>I think I need to set up such a configuration in my non-Guix-managed Syncthing cluster and see what kind of config it generates to understand fully, but that seems to make sense <eikcaz>I considered allowing a device to be listed as (device [encryption-password [introducer]]), which would eliminate syncthing-device-folder, but I was worried that that would be abusing lists. <eikcaz>I would suggest peeking at one of your existing syncthing configurations <lfam>Yeah, I am :) But I don't have any untrusted servers in my cluster so I don't have anything to illustrate. But I'll set it up <eikcaz>notice that devices are listed twice: once in the body, and once in each folder they are a part of. The one in the body has the main device definition, while the one in the folder which specifies a (probably empty) encryption password and introducer <eikcaz>syncthing-folder-device has just BARELY enough structure that it seems worthy of its own record. I think most peolpe won't use it, which is why I made it optional to use at all (so long as you want the defaults) <lfam>I think it's fine and that I just didn't really understand what I was looking at <eikcaz>reading the section, maybe first sentance should s/device/remote device/. second sentence s/see the files given to it/read the files in this folder, or if those files should be encrypted first/. Third sentence s/from where that device originates/which other remote device introduced this remote device (if any)/ <eikcaz>(since you are already editing, I assumed resubmitting the patch was more work for you) <eikcaz>^reading the syncthing-folder-device section. If it's not clear to you, then maybe it is a bug in the documentation :3 <flypaper-ultimat>sneek: later tell aure84 i ran it using a 'guix system container' which also shares the store with the host machine. but even if you use a 'guix system image' the files should both exist on the virtual machine and in the machine that made the image, you can check for references on the building machine, and those files exist and be the same on the image. (as long as you didnt use the 'cleaning up cruft' functionality of 'guix gc'). <flypaper-ultimat>while 'guix gc --references references are _stored_ in a sqlite database, the results of it are pretty much equivalent to `grep -REao '/gnu/store/(\w|[-.])+'`, so you could use that in a pinch. <flypaper-ultimat>sneek later tell aure84 while 'guix gc --references references are _stored_ in a sqlite database, the results of it are pretty much equivalent to `grep -REao '/gnu/store/(\w|[-.])+'`, so you could use that in a pinch. <aure84>Hello. Is it possible to create a guix container with shepherd running on it? <sneek>aure84, you have 2 messages! <sneek>aure84, flypaper-ultimat says: i ran it using a 'guix system container' which also shares the store with the host machine. but even if you use a 'guix system image' the files should both exist on the virtual machine and in the machine that made the image, you can check for references on the building machine, and those files exist and be the same on the image. (as long as you didnt use the 'cleaning up cruft' functionality of 'guix gc'). <sneek>aure84, flypaper-ultimat says: while 'guix gc --references references are _stored_ in a sqlite database, the results of it are pretty much equivalent to `grep -REao '/gnu/store/(\w|[-.])+'`, so you could use that in a pinch. <flypaper-ultimat>aure84: if you mean a docker container, there's 'guix system image --image-type=docker' <flypaper-ultimat>aure84: but if its just for testing out your shepherd (and you don't need a graphical display like wayland/x11), i like the 'guix system container', because it just gives you a script that you run. <sneek>civodul, you have 1 message! <sneek>civodul, apteryx says: re the sysadmin team, didn't this existed yet, but being on the guix-sysadmin mailing list, I should be on it <ekaitz>sneek: thank you bot, tell me you don't understand me <sneek>me, ekaitz says: you don't understand me <jlicht>greetd-user-session-command defaults to (file-append bash "/bin/bash"); shouldn't this default to the user's login shell rather? <apteryx>lilyp: I'm working on mutter; I have only 2 tests failing at the moment <apteryx>mutter:core+mutter/backends/native / native-unit and mutter:core+mutter/x11 / x11-sync <lilyp>yeah, I saw those too when upgrading the package <lilyp>the rest of the native suite is currently disabled with that multiline sed expression <lilyp>there is some deadlock in it iiuc <aure84>flypaper-ultimat: thanks for the reply! Yeah, the other problem I had is that the vm creaed by `guix system vm` is inmutable and some service activation functions (e.g., those creating directories in the filesystem) will fail. <flypaper-ultimat>aure84: if you give `guix system vm` the --persistent flag it should be writable according to (info "(guix) Invoking guix system") <aure84>flypaper-ultimat: I was jus trying that :). I think is is a more convenient way to try whole systems <aure84>flypaper-ultimat: no, it is still inmutable <aure84>That's weird: "By default, the root file system of the VM is mounted volatile; the --persistent option can be provided to make it persistent instead. In that case, the VM disk-image file will be copied from the store to the TMPDIR directory to make it writable." (from ref manual) <flypaper-ultimat>ive been able to `sudo $(guix system vm --persistent $(guix build -S guix)/gnu/system/examples/bare-bones.tmpl)` and login as root in the vm and touch files. <jlicht>look: oh that seems nice. I'll still have to check if I can get my login shell to start sway using this <aure84>flypaper-ultimat: when I do `guix system image --image-type=qcow2 --image-size=10G -L . config.scm` followed by copy,chmod +w and `sudo qemu-system-x86_64 -hda /tmp/1dg4xkj47xj6m4m3xg9lhsdn2hi2fn8l-image.qcow2 -boot d -m 8096`, the service is up. When I simply `guix system vm....` in any form we have gone through earlier, the service is down. I'm not sure the problem is the read-only system anymore <aure84>as the `/var/dicom-store` dir is created successfully on activation <jlicht>civodul: thanks a bunch for hacking on transient support in shepherd; I've moved all of my ${WAYLAND-,}DISPLAY-related daemons to it, and life has been pretty good so far <civodul>jlicht: nice! you mean ‘herd transient spawn’ specifically? <jlicht>civodul: herd spawn transient ackshually, but yes :-) <decfed>jlicht: could you show an example please? <decfed>do you use it for setting env vars? <jlicht>decfed: sure! Somewhere in the lower regions of my $HOME/.config/sway/config: <jlicht>exec herd spawn transient -N kanshi -E WAYLAND_DISPLAY=$WAYLAND_DISPLAY -- kanshi <jlicht>Noo clue how things are supposed to work if you run multiple concurrent instances of sway, but since I don't do that, this works fine for now :-) <df>podiki: thanks, I was reading an old manual <yelninei>janneke I had to downgrade to libstdc++-5 as I was not able to build libstdc++-14 with the %bootstrap-gcc <yelninei>took several retries because the cross-gcc and final-gcc sometimes were unusable: with things like illegal instruction errors? <yelninei>but now i 2hrs into gcc-final and hope that it will be the last time i have to redo it <civodul>i started investigating but failed to boil it down (and then i switched contexts) <yelninei>civodul: Building for -s i586-gnu so i dont have a gcc-mesboot <janneke>yelninei: ah, that makes sense, of course! <flypaper-ultimat>aure84: two things. in the /var/log/messages i saw the --help message for storescp, because apparently it _requires_ a port argument. when adding the port, it failed again because of permissions, because only root is allowed ports less than 1024. <janneke>yelninei: possibly we need even to distinguish between cross and native compilalation? <flypaper-ultimat>aure84: made some changes that it also uses the correct user, and that thats modifiable <yelninei>i just wish this process to not require that much babysitting: The childhurd becoming unresponsive, transient random failures, etc .... The bootstrpaping does not seem very deterministic and all Ican do is gc and start again from nothing <yelninei>janneke: Probably because when doing cross compilation it is easy to use the earlier automake for the mach headers <yelninei>or maybe better to add a patch with the commit i sent yesterday <aure84>flypaper-ultimat: did you try that in a container? I launch the container and see that the `/var/dicom-store` has been created, but the service is nowhere to be found <ngz>I want to make use of package-transitive-propagated-inputs in a package definition, but Guix won’t let me do this unless I write the expected code in #:imported-modules or #:modules. What should I write there? <aure84>flypaper-ultimat: wait, something came out :)/ <aure84>flypaper-ultimat: it seems it works! thank you! <jakef>hmm, can't have both python-numpy and python-pandas in the same profile right now because python-pandas is propagating numpy v1, and numpy is up to v2 <civodul>jakef: yes, i think that’s the fallout of the recent NumPy 2 addition <civodul>ngz: i’m not sure what you mean: how do propagated inputs related to #:imported-modules <ngz>civodul: I get "Unbound variable: package-transitive-propagated-inputs" when I run a phase in my package definition. So I need somehow to tell Guix where to find this function. <ngz>And I’m not super at ease with that modules/imported-modules stuff. <jakef>civodul: nice, and agree with your comment <Rutherther>ngz: you don't use functions like that in a build phase. Rather, pass only their results to the phases, ie. by ungexping <civodul>ngz: oh wait, perhaps there’s some confusion about the various “code stages” <civodul>packages do not exist on the “build side” <ngz>civodul Ah, yes. So what would be an idiomatic way the get the list of all the propagated inputs of all the inputs of the current package on build side? <civodul>ngz: you could check the #:inputs argument of phases <civodul>though that gives you all the inputs, not just those propagated <civodul>or you could do something like #~(modify-phases whatever … #$(package-transitive-propagated-inputs …) …) <civodul>but, it’s heavyweight and i would not recommend it <ngz>I try to use #$(package-transitive-propagated-inputs …) but I don’t know how to apply it to inputs from #:inputs argument. <civodul>you can’t: these two things live at different times <civodul>packages in general live on the “host side” <civodul>whereas build phases live on the “build side”, i.e., when you actually try to build the package <ngz>I understand that. So I’m looking for a way to do something equivalent on build side, with or without package-transitive-propagated-inputs. Maybe that’s not possible. <ngz>Or it may be something like #$(append-map package-transitive-propagated-inputs (package-transitive-inputs this-package)) <civodul>package-transitive-propagated-inputs takes a package, but package-transitive-inputs returns a list of label/package pairs <ngz>Of course, the type of data is wrong, but I can compose package-transitive-propagated-inputs with, e.g., `second'. It is a draft. <ngz>I probably don’t need package-transitive-inputs either. package-inputs would do, I guess. <ngz>Even #$(package-transitive-inputs this-package) throws an error. :( <yelninei>phase `build' failed after 13042.2 seconds: I think it ran out of disk space <futurile>Q: I have my first commit ready for 'rust-team' but I think I'm having a signature problem. When I do `git log --show-signature -1` it says the signature is good (and it's using the correct signing subkey). But if I run `guix git authenticate` it says the commit is "not signed by an authorized key". What am I doing wrong here? <Rutherther>futurile: did you update your local keyring chain? <futurile>Rutherther: yes - git fetch origin keyring:keyring - and I can see my key is there <Rutherther>alright. Apart from that someone here said that they also had to pull their normal guix. Though that seems strange to me, maybe it's worth a try <dariqq>futurile: is your key authorized on the rust-team branch as well or only on master? <futurile>dariqq: ah, yeah that might be it - I didn't know I had to do that <futurile>dariqq: what's the process step? (I think I might wait for Efraim to be around) <jlicht>rebase and/or merge would do the trick. I'm not quite sure what the rust team usually does to sync with master <futurile>jlicht: so I haven't pushed it yet, I've got my 'single commit' on a local rust-team branch. And I've made sure that the rust-team branch is up to date (rebased against rust-team). But before I push I wanted to make sure that `guix git authenticate` wouldn't indicate any problems. <jlicht>futurile: I think Someone Else needs to make sure the commit that authorizes you is part of the history of the rust-team branch. <ieure>jlicht, Yeah, I was just about to say this. <jlicht>I could be wrong, so don't take my word for it <ieure>I'm pretty sure you're right. <ieure>But we could be wrong together. :) <jlicht>'gezellig' as we say in Dutch ;) <futurile>oh! So I'm unauthorised because rust-team doesn't have the most recent master/key-ring with my key in it <dariqq>futurile: quoting from the manual: "each commit must be signed by a key listed in the .guix-authorizations file of its parent commit(s)" <Rutherther>what's the point of the keyring branch if the key has to be in the branch you're putting commits to as well? <futurile>dariqq: ah yeah, just reading that - my key's not in that file for the rust-team branch - so that's why it's failing then <old>why do I get: No Guile development packages were found. when configuring Guix sources <old>I'm in the following shell: guix shell --pure -D guix guile <old>it usually works fine <ieure>futurile, The keyring isn't the issue, it's that the rust-team branch hasn't pulled in the commit to .guix-authorizations made to master which adds your key ID. <look>Rutherther: afaik only the fingerprint needs to be on that branch (say rust-team), the keyring branch is only used *after* 'guix/git-authenticate' verifies the fingerprint for each individual commit <ieure>futurile, I thiiiiink you can actually rebase rust-team yourself? You'll be rewriting all the commits on rust-team, but they'll get replayed on top of master's HEAD, which should have the commit adding you to .guix-authorizations. <futurile>ieure: OK, thanks for the clarification. <ieure>futurile, The danger here is you rewriting the commit to .guix-authorizations adding your key, which won't work, because your key can't authorize the commit adding it. <futurile>ieure: I think I'll wait for Efraim to be around before I mess up his branch in some horrific way. Ironically I was trying to use a team-branch to derisk it :-) <ieure>futurile, Ha. Makes sense. You can certainly experiment without wrecking things, ex `git checkout whoops-my-bad rust-team && git rebase origin/master', then `guix git authenticate' and see if it complains. <ieure>futurile, Or just rebase rust-team and use the reflog to revert if needed. <ieure>futurile, But I agree that rebasing the whole team's branch needs team coordination. <civodul>it could be that you have a stale ‘config.cache’ (from ‘./configure -C’) <Rutherther>look: so first the current commit is checked by looking at the parent and then whole history using keyring branch? <old>civodul: actually I did a `guix pull' and now it is fine <old>I suppose the guile development version had changed <look>Rutherther: I don't know that much specifics about what you asked, but from my understanding, it first reads from '.guix-authorizations' to see which keys will be loaded from the 'keyring' branch, so if key is on 'keyring' but not on '.guix-authorizations' it won't be used for authenticating <look>I think commits on the keyring branch don't even need to be signed for the authentication to happen, since the only check done is on L233(guix/git-authenticate.scm), and it only compares the public fingerprint <look>So theoretically if you could find a fingerprint collision and poison the keyring branch with your .key (but unsigned), you'd be able to authenticate <look>Not sure about this last part tho, I haven't looked too much into it, just enough to hack it a bit to allow my own guix fork to run without '--disable-authentication' <mra>look: not to jump into the middle of a conversation, but isn't the point that a fingerprint collision should be overwhelmingly unlikely? <mra>like, if you can find a fingerprint collision, iirc you can compromise a lot of pgp-related stuff. my impression was that the standing assumption was that a fingerprint collision was infeasible to find <look>mra: yes you're right, that's why I said 'theoretically', because its really really unlikely <mra>in that case, i imagine that there wouldn't be any sort of concern <mra>of course theoretically anything can happen :P <Altadil>Hello! It looks like the new version of Audacity cannot find ffmpeg anymore. Does anyone else have this bug? <paul_j>Afternoon all! Quick question - I recently updated my laptop which has a greetd-service-type session which starts sway automatically (using greetd-wlgreet-sway-session - configured as shown in the guix handbook). After the update, I now get dropped to a terminal when I log in. If I issue the command 'sway', everything starts as I would expect. I cannot find any error messages suggesting why this happened, and I haven't been able to find <paul_j>any information suggesting this part of my configuration should be updated. If any of you can point me at updated information, I would be most grateful! Thanks in advance. <ieure>Or maybe I'll just push it without, I generally like reviews, but I think it's okay in this case. <civodul>ieure: it should be someone from the browser team or, if nobody steps up, you can feel empowered to push it <civodul>the “Commit Access” section has provisions for that <ieure>civodul, Yeah, I read that section, it's a little vague about when exactly it's okay to do that. <podiki>i wouldn't worry so much about a review for such a simple change to a leaf package for security updates <podiki>there's like 3 excuses right there :) <ieure>podiki, It builds, I always run it myself for a few days before sending the patch. <mra>is there a standard rule for when someone with commit access is actually allowed to push a change? <civodul>ieure: “After this, if no one else is available to review them and if you’re confident about the changes, it’s OK to commit.” is what i was referring to <civodul>if you can think of ways to clarify this, that’s most welcome of course <podiki>i also think with a leaf package and security updates it can get some priority <podiki>we always have to make judgement calls in the end <civodul>also the “Teams” section empowers teams: “[a team] can make decisions within its scope […]” <podiki>i would even say one of the biggest parts of being entrusted with commit rights is that you have good judgement/can handle and learn from mistakes <civodul>and at some point we’ll have (again :-)) working automation to prevent us from making the most obvious mistakes <podiki>let who is without having broken guix pull or caused 5k unexpected rebuilds cast the first stone, or something like that <mra>if someone is looking to accidentally cause every single package to rebuild, have i got the patch for you <podiki>and speaking of teams, i need to make one. do we have a way to scope to specific packages or just modules? <ieure>Ah, this is touching on another thing I was wondering about. A while back, I proposed splitting nss into nss and nss-rapid. I send some patches which do that, and after I got commit rights, I pushed a branch, but QA never did anything with it. <ieure>What's the path forward for that work? <podiki>avoiding your question but: would love to have nss put libs in lib and not lib/nss one day... <ieure>Not sure what that'd entail, but I can take a look, if we're doing a bunch of rebuilds, that'd be a good time for it. <podiki>just a quick look, but for whatever (historical?) reason, we explicitly move things (and set rpath) to lib/nss. so that's the easy part, then a handful of places where we accommodate this change <podiki>besides that...i guess depends if there is some reason lib/nss was used in the first place <ieure>Basically I think there are three paths for the nss stuff: 1. merge to master and hork up everyone's substitues for a bit 2. merge to core-updates and hope that merges before a new LibreWolf needs a newer nss-rapid in master 3. push to a nss-updates branch and have QA build it, then merge to master <ieure>I was pursuing 3, but since QA never built it, maybe core-updates is the next best thing? <podiki>i don't know if we want to load up on core-updates again, but maybe ask whoever is working on that? <podiki>there is also ungrafting needed somewhere in there too <podiki>subs for nss is the thing, but there shouldn't be breakage as i believe they always stress complete backwards compatibility <podiki>i also don't remember your changes <mra>does anyone happen to know where bags are documented? i'm wondering if I could use them to get around some issues that I'm having with derivations <mra>although I'm not sure if bags carry substitutability information... <ieure>podiki, The issue with nss is that upgrading it will trigger a ton of rebuilds. <podiki>yeah i know. could always graft (i assume there are always security updates each version) and join the ungrafting <ieure>I believe most nss releases don't have security fixes. nss is already grafted, it needs an ungraft and upgrade to the latest ESR. <podiki>i think on one of the branch merge threads Ludo was thinking to ungraft on core-updates (or whatever it is called) as the ungrafting branch/job was too much at the time <ieure>Yeah. I think that was ungrafting every current graft, though. Presumably ungrafting just nss is more feasible. <ieure>But again, QA simply did not build any branch I pushed. <ieure>Tried it with nss, tried it with LibreWolf (twice). <futurile>ieure: I believe you have to create an issue in a specific format for QA to pick up the branch <futurile>ieure: I'm sure I read that yesterday in the 'branches' section of the manual <ieure>futurile, Hmmm. It picked up the branch, I could see it in the UI, it just never built anything. <futurile>ieure: ah so you're suffering from the "QA is swamped stuff" <ieure>futurile, I guess? There's zero information presented other than it hasn't built jack. <ieure>futurile, I think the patch format is just to let committers know the patch needs to go on a branch, and QA picks up any branch that gets pushed. <podiki>yeah it has been very behind for a quite a while <ieure>How are we doing stuff that touches big parts of the package graph? Pushing to master? Not doing it at all? <ieure>I guess I'll ask guix-devel when I take lunch. <futurile>I asked Chris about this at Guix Days, it's worth a discussion on guix-devel where there can be some discussion about the nuances <podiki>i believe anything with lots of rebuilds (more than ~300?) goes on a branch, ideally it is built to have subs and then pushed to master <podiki>however, QA is behind so you might have to rely on just a Cuirass job for the branch <podiki>the newish guix build --dependents can also help to see coverage <podiki>e.g. "guix build -P1 <pkg> --no-grafts -n -v1" was a nice one I got from Ludo when working on mesa-updates <ieure>Does cuirass pick up new branches automatically, or does a specification need to be added somewhere? <ieure>Is that in a place I can push to? <podiki>i'm not sure. you need a cert for the web interface, but not sure if that's the preferred way to add a spec <ieure>In my personal setup, I maintain a librewolf-updates branch that I use to hack on before I merge it to my channel's main, same setup would be useful upstream as well. <podiki>perhaps a guix-devel message saying what you'd like to do with nss and requesting a cuirass job <zimoun>Is it possible to authenticate a Git worktree? Well, Git is not happy when I push from a Git worktree. Do I miss something? <podiki>was it because of new keyring additions maybe? i've used worktrees and it authenticates in the worktree at least <ieure>I forget the incantation, but updating nss definitely triggers >300 rebuilds. <podiki>ieure: yeah it is like 15k from my reading of guix refresh nss -l | head --bytes 128 <zimoun>podiki: Thanks. So my failure is probably elsewhere. :-) <podiki>zimoun: though i'm not sure what you mean by push from a worktree, like merge to another branch? i push from a worktree to its branch fine at least <podiki>ieure: so i might make sense to group nss with other ungrafts as it is a good chunk of the package graph. i think there are glibc grafts which means everything <podiki>if it was up to me i would prioritize the ungrafting, it is a lot right now and makes everything take longer <ieure>I agree, the graft situation is really out of hand. <podiki>we should see what the status is of grafts/core branch and try to get that moving in the queue <zimoun>podiki: Well, since “guix git authenticate” relies on ’repository-config’, depending on how it’s implemented, this might fail. But that’s probably not the case and the problem is from elsewhere, so. :-) <zimoun>Ok, the issue was about my configuration of authentication. <zimoun>git … push -v --force origin wip-julia-upgrade\:refs/heads/wip-julia-upgrade <zimoun>Pushing to git.savannah.gnu.org:/srv/git/guix.git <zimoun>guix git: [1m[0msuccessfully authenticated commit [1m5f31ce18b3655264e3d101eada5382bf22ac1cfa[0m <zimoun>remote: error: denying non-fast-forward refs/heads/wip-julia-upgrade (you should pull first) <ieure>zimoun, You can't force-push to savannah, you have to `git push origin :wip-julia-upgrade' and then do a normal push. <ieure>The first push deletes the branch, the second recreates it. <zimoun>I hope that I have broken nothing… Always a bit nervous when pushing on Friday. :-) <zimoun>Now the week-end to rebuild the Julia world. ;-) <df>hi, I'm a bit confused about simple-service and when it's safe to use it rather than modify-services <ieure>df, I could be missing something here, but I think that comment is wrong. The code is adding a new service, I don't see how that changes anything already in %base-services. <df>but in my own config I am using modify-services on %desktop-services to add a substitute server to guix-service-type <df>ieure: the way I read it at least, there is already an mcron-service-type there <df>;; %BASE-SERVICES already includes an instance of 'mcron-service-type', which we extend with additional jobs using 'simple-service'. <ieure>df, I agree that's how the comment reads. Unless I completely fail to understand some subtlety of mcron-service-type, I do not know how the code actually does what the comment claims. <ieure>Maybe mcron's extension mechanism means the new config gets merged into the original one's config? I truly do not know. <ieure>I agree that it's confusing :) <df>although looking at the definition of %base-services, I don't actually see an mcron-services-type there... <lilyp>ieure: the tar vs. tar.lz thing is a sad reality for everything on elpa <lilyp>i think it's still fine to use elpa, because mirrors like swh should kick in if the link goes down <df>if that's the case and simple-service doesn't add any magic to modify existing lists of services, then I'm not sure what it's for at all... <ieure>df, simple-service is for creating simple services. <df>as far as I can see, one could easily create an mcron service with an ordinary service clause, I don't get what simple-service does differently <df>well, I guess I'll try it... <ieure>Yeah, not sure. The service code is still mostly a mystery to me. <lilyp>simple-service is just a syntactic shortcut to instantiate a service that inherits some specific base service <bjc>like if you want a shepherd service in your home config. you can just add it to the list of services without going through the hullabaloo of creating a bunch of objects for this one purpose <ieure>lilyp, Hmm, I've definitely seen patches get kicked back with requests not to use ELPA. And I've also encountered broken packages due to not pointing at the latest version in ELPA. <df>I guess that's my issue, I'm not sure why you would want to inherit rather than just instantiate the serviced <ieure>lilyp, In most cases, you can point to the upstream Git repo, but for this one specifically, the source is embedded in the Emacs source tree. <lilyp>there should be a separate git repo somewhere <ieure>df, Because you can't have more than one instance of the same service at a time. <lilyp>emacs maintains its own fork <lilyp>in that case why not use ELPA? 🤷♀️ <ieure>lilyp, And "ERC is currently distributed with GNU Emacs. We are planning to make ERC releases available on GNU ELPA to enable ERC users to use newer versions of ERC without having to upgrade their entire GNU Emacs installation." <df>ieure: so... if mcron were in %base-services (which is doesn't appear to be afaics), that code would give you two mcrons? <ieure>df, Basically yes. It'd actually give you an error when you reconfigure due to having two mcrons. <ieure>But as lilyp mentions, simple-service gives you a new service that inherits form another one. I do not know if that gives you two mcron processes, or whether the extension mechanism means that the configs get merged. <df>so it is an easier alternative (in some cases) to using modify-services? <bjc>it's used with modify-services, since it returns a service <acrow>nckx: Your posts are always helpful and, yes, please feel free to delete that tarball. I failed to change my status to extended away from keyboard. Mistakes were made.... <acrow>csantosb: Thank you, too, for your help. It's all better now. On to new challenges. <bjc>modify-services also works with a service-list, iirc, and that's likely to be ‘%base-services’ <vagrantc>wow. running guix works so much batter when not running it in a machine with bad RAM <bjc>there are no side effects, so the only thing that matters in the end are the contents of the ‘services’ slot in your ‘operating-system’. it doesn't care what method you used to put things there <bjc>cons, cons*, modify-services, whatever <mra>another day, another 55231 email o7 <mra>back in the patch mines <ieure>Does modify-services have a way to add a service? I know you can change and delete them, but I always end up using (cons* (service ...) (modify-services ...)). <bjc>i think so, but i can't remember <ieure>I wish I could use a single form to add, remove, and modify services, like `modify-phases'. <lfam>That's a good point ieure <bjc>it's been a long time since i looked at modify-services <ieure>Checked the manual, if it has some kind of add facility, it's undocumented. <lfam>I think the adding is more generic, like cons or append <bjc>yeah, i don't see an ‘add’ in the code <bjc>just modify and delete <lfam>I think it's worth adding the capability to "add" in this way <bjc>should be pretty easy <bjc>services.scm:311 has the macro for it <bjc>gnu/services.scm, that is <df>well this is why I was curious above whether simple-service did modify services as suggested in that comment <bjc>simple-service creates a new service. modify-services takes a list of services <df>atm I define an intermediate variable with my modified %desktop-services, then append the rest of my services onto that <acrow>I openly worship emacs which here is only a small grace but in dark moments I am always tempted to explore browsers... and this leads to questions... <acrow>Some ai targeted me with articles saying that the zen-browser was nice and so I wanted to give it a spin in guix. <acrow>I downloaded the zen-browser appimage; cause it should just work and it's way better than flatpak, right? But it doesn't just work... <acrow>I know it would work if it was generated by guix pack -f appimage zen-browser, but that isn't, at the moment, a thing. <ieure>acrow, Is Zen Browser another reskinned Chromium? <acrow>I've done just enough fiddling with the squashfs-image to know I should've asked jlicht for some advice.... :) <jlicht>(tldr: use `guix shell --container --network --emulate-fhs <a bunch of other stuff>') <ieure>> Built on Latest Firefox Version: Zen Browser is based on the most recent version of Firefox, benefiting from Firefox's security updates and patches <acrow>ieure: no, I think it's a reskinned firefox. <ieure>alright, it's not immediately DQ'd. <ieure>I absolutely refuse to run Chromuim-based browsers. <ieure>Any Chromium browser reinforces the Google monoculture killing the Internet (IMO). <mra>yeah, agreed. chrome unilaterally inventing new webs standards and stuff seems very bad for the web to me <mulinolino>For the 6th fucking time. Fix your stupid tutorials/scheme apis to give useful errors. No god damned .guix-channel configuration fits your stupid local channel tutorial >:( <vhns>I'm having some trouble figuring out where I should put a Rust package I'm writing. As in, which rust-xyz.scm file it should go. The package is this: https://github.com/2bc4/twitch-hls-client , it's a commandline client for watching video streams through a video player. <vhns>If anyone has any pointers, I'd much appreciate it. <ieure>vhns, I think (gnu packages rust-apps) is the right place. <vhns>Even tho it's not a graphical application? (I have literal no clue) <mra>mulinolino: if you'd like a change made to documentation, you're more than welcome to submit a patch <acrow>jlicht: Excellent article. Thank you for pointing it out. <ieure>vhns, Sure. There's stuff like DNS servers in there. <lfam>If it's an end-user application, it should go to rust-apps. If it's a "crate" (i.e. a Rust library), then it can go into an appropiate crates module. And if it pertains to Rust itself, then rust.scm <lfam>It sounds like something that a human user would use <jlicht>yw* although I’m not sure everything as written still works without modification <acrow>What I don't immediately see is how to --expose=. It will take a little bit to give this a whirl. brb. <df>can I get the functionality of guix repl in geiser? presumably I could start a repl externally and connect to it, but is there an easier way? <acrow>and .. we are looking for substitutes.... While that's happening I'll say that if this works it would be a wasm supporting browser that I can run in guix without flatpak... of course, there are also probably many other ways. <df>oh... I appear to have it, though I'm not sure how <df>possibly by something I did while messing around with emacs-guix <simendsjo>Is there a home service for setting/extending PATH? I cannot find any, but I want to add to PATH from several home services. <hapst3r>anyone else having trouble to guix pull? <hapst3r>ah nvm, was tripping because I had an "unexpected status code 502" <dariqq>simendsjo: maybe a profile-service-type extension is what you want to add the packages to your normal home profile? <simendsjo>dariqq: I don't have packages, it's to add non-guix paths to profile. I want it for plugin managers which installs programs outside guix. Sure, adding everything to guix would be nice, but it's quite practical. <ieure>simendsjo, (simple-service 'extend-path home-bash-service-type (home-bash-extension (bashrc (list (plain-file "bash-profile-path" "export PATH=$PATH:..."))))) <Rutherther>simendsjo: to change env vars there is home-environment-variables-service-type that is meant for that <ieure>I'm not sure if you can append a value to an environment variable with home-environment-variables-service-type. <simendsjo>ieure: I don't want service definitions to require a certain shell. As an example, I have a dotnet service which want to add ~/.dotnet/tools to the path, and a kubernetes which want to add ~/.krew/bin to the path. <dariqq>simendsjo: maybe home-environment-variables-service-type with PATH=NEW_ENTRY:$PATH works <simendsjo>Rutherther: I cannot set PATH several times. I tried it and completely broke my system :) Got a warning though. <dariqq>simendsjo: Or the ultimate method: Write your own extentable service that concantenates all the pathes and and then sets PATH accordingly only once <simendsjo>Rutherther: Sure it works? Search for "duplicate definition for", and you'll see the warning. <simendsjo>dariqq: That's what I'm leaning towards, I just don't want to do it if it already exists. Should be fairly simple to write though. <ieure>simendsjo, You need a new service: (simple-service 'my-environment-service home-environment-variables-service-type `(("PATH" . "$PATH:..."))) <Rutherther>simendsjo: duplicate definition means two things set PATH in your home-environment-variables-service-type, which of course is a problem <simendsjo>Rutherther: Yes, I want to set it from two different services and the home environment directly. Guess I'll write my own service. <ieure>simendsjo, I am pretty sure the snippet I sent you will do what you want. <acrow>jlicht: Thank you. If you want to test drive the zen-browser appimage in guix then do paste.debian.net/1350022 <simendsjo>ieure: I think that was what I was doing. But looking at environment-variable-shell-definitions, it looks like it should work without an issue (as long as we append) <acrow>jlicht: No optimizations there. <acrow>zen-browser appimage in guix works with hoot. <acrow>If immediate guix gratification isn't available then I prefer my apps come from AppImages than from flatpak because appimages are just harder to get going. I thought I had a better reason but I've forgotten what it was. :) <acrow>The provided incantation doesn't get sound to work out of the box.. apparently a dbus proxy was missed. <acrow>zen-browser sound is a problem for later. Going afk to craft a valentine day card. <gorilla>What is the right word for a pre-defined guile variable for something like base-packages? <jaadu>Is there anything particular I need to do to make graphical programs to work well on a foreign distro? <jaadu>I have read the info page (guix) Application Setup but it seems incomplete. <jaadu>For example xterm seems to miss a window icon. <gorilla>as in a desktop environment icon? or some other icon? <jaadu>gorilla: The icon in the panel isn't showing, its just an anonymous black box. <Rutherther>jaadu: is the share folder under profile you're installing to in XDG_DATA_DIRS environment variable? <gorilla>do you have a .desktop file for the app? If so, what is the path for the icon in the .desktop file? <jaadu>Rutherther: Yes XDG_DATA_DIRS seems to point to ~/.guix-profile/share correctly <jaadu>gorilla: No, I can't find a .desktop for xterm specifically in my guix profile. <gorilla>Doesn't xfce use .desktop files for its panel? <jaadu>Possibly, I run it independently of xfce4. <jaadu>I have a line in my i3 config to run xfce4 panel. It works fine. Mostly. <jaadu>It gets a bit complicated when I don't really understand DBus, PAM, xsession, and whatever else that needs to be connected to have a working desktop. <jaadu>And how it has been setup in regards to guix on a foreign distro. <jaadu>The hope I have is that just loading $GUIX_PROFILE/etc/profile and then just have everything work. But I do run into issues. <simendsjo>StumpWM users: I upgraded to master to avoid the high cpu usage on 24.11, but stumpwm doesn't start when ~/.stumpwm/init.lisp is a symlink. Replacing the symlink with a regular file solves the issue. Is this specific to my system, or a bug in the reworked "better-default-data-dir" or similar? <sobol>hello, i was trying to run that zen browser app image from a paste earlier but i get the following error: "guix shell: error: statfs: : No such file or directory". any suggestions <podiki>probably one of the options refers to a file/directory you don't have <podiki>so guix shell is trying to make it available in the container but doesn't find anything (hence the blank name) <sobol>okay ill double check the args. thansk <sobol>it was the --preserve='^XAUTHORITY$' --expose=$XAUTHORITY