<civodul>i’ve tried to restart ‘goggles’ (the service that does that) but somehow it seems to wreck havoc
<civodul>cbaines: we should reboot bayfront one of these days because it’s still running shepherd 0.9.2
<Guest78>when writing a package, how can one pull more data into their package from the internet after an initial git clone has occured. I am having issue with pulling in more data from the internet and using guix modules in any of the build stages. Must one implement a custom fetcher?
<simendsjo> I have a very poorly specced VPS that's unable to do a system reconfigure. Can I somehow build this locally and transfer the result to the VPS without setting up offloading? Is it save to do guix system build, guix archive --export and guix archive --import?
<civodul>cbaines: alright, so feel free to reboot when you want
<janneke>hmm, there is no /etc/ssh/authorized_keys.d/offloading in my childhurd...
<civodul>zamfofex: hi! just read about your wasm cross-compilation target, that sounds fun!
<civodul>if we could “guix build --target=whatever-wasm hello”, that’d be nice
<civodul>will i manage to get ci.guix upgraded today? suspense!
<civodul>so far it’s been a lot of waiting for things to build (and eventually fail)
<RavenJoad>Could someone share their Guix config where they have their laptop's lid close event cause both all elogind sessions to lock and suspend the system? I already have the suspending part, but not the locking part.
<anthk_>hello, mit-scheme doesn't compile under i686, upstream stated it's not supported
<apteryx>nckhexen: we ran out of space on p9, so i'm running a GC, and it's taking hours to "deleting `/gnu/store/trash'"
<apteryx>so if you were wondering about why it's not building things, that's the reason
<apteryx>anthk_: we could remove it from the 'supported-systems' field
<apteryx>(from everyone attempting to build it for such platform, actually)
<vivien>Is Maxim Cournoyer here? I’m working on my gnome-team eudev update, and I don’t understand the paragraph starting with "Maybe add a ;singled valued comment", what should I add as a comment? Also, it would be desirable to have UDEV_HWDB_BIN set at build time.
<tylerm>does anyone have a better way to package caddy than repackaging all of its dependencies with the go build system
<vivien>lilyp, I like the idea to change udev-service-type to also install hwdb stuff. For a profile, I could just take all the profile inputs that provided a hwdb.d directory and use these files. For the udev-service-type, though, I’m not sure. The extension mechanism is locked to me because it can only be extended with udev rules, not hwdb files. How should the udev-service-type know which package it should take hwdb files from?
<vivien>I know eudev and upower install hwdb files.
<ieure>apteryx, Thank you for the kind words. I'm in physical therapy for a while yet, it's coming along, but not 100% yet.
<vivien>Obviously the upower-service-type should extend the udev-service-type with its own hwdb file(s)
<vivien>Maybe I should define a new record type <udev-service-extension> that accepts an optional list of rules and an optional list of hwdb files
<vivien>Stupid me, I don’t need it, since we extend udev-service-type with package-like file-likes
<vivien>So I can just take the /lib/udev/rules.d sub-directory of all extensions for rules, and the /lib/udev/hwdb.d sub-directory of all extensions for hwdb files
<lilyp>avalon don't know about blueman, but os packages = system wide
<apteryx>lilyp vivien: interesting idea to use system configuration for the hwdb files; would this complement a profile hook or be used instead of it?
<apteryx>to Emacs Debbugs users: when wide replying (with W S) on a patch message, does it preserve *that* message subject, or does it pick the PATCH 0/N subject one (that of the cover letter)? For me it picks the subject of the thread's first mail, which looses context
<vivien>apteryx, I’ll do the udev-service-type modification and drop the profile hook
<vivien>I mean, every system user has access to (a subset of) the same hardware, so the use for a profile hook is certainly limited
<lilyp>yeah, I don't think that this is a variable that a profile hook should mess with – you can still do so on your own for debugging and what not, but I'd rather not shadow crucial stuff by accident is all
<apteryx>vivien: great. will that make the patches submitted to eudev unnecessary?
<apteryx>I guess they could still be useful for debugging, if the variables honored are documented
<vivien>apteryx, we still need support for udevadm hwdb -o and UDEV_HWDB_PATH, because I think hwdb.bin should be computed when building the system, not when activating it
<vivien>Also if I do a home service variant, it will use UDEV_HWDB_BIN
<vivien>But I’m not sure about how to implement the home service variant, because if the system is configured with hwdb file X and the home system is configured with hwdb file Y, then the home hwdb.bin file should be compiled with both X and Y
<vivien>So the home environment should know about the system environment
<vivien>And if the system is reconfigured with Z instead of X, then the home hwdb.bin file still indexes X and Y, not Z and Y
<vivien>It would be better if eudev could read from multiple hwdb.bin files, but I guess it defeats the purpose of the index in the first place.
<vivien>Is there a reason for udev-rule not being (file->udev-rule file-name (plain-file "udev-rule" contents))?
<vivien>(or even file-name instead of "udev-rule")
<vivien>I can’t imagine the answer is "to avoid leaking contents to the store", since it ends up there anyway.
<lechner>vivien / are you aware that udev rules processing is defective?
<janneke>my childhurds have 4GiB of memory and i've also been using 2GiB of swap which may or may not have any effect
<janneke>but i certainly remember gcc builds getting stuck now and then
<lechner>vivien / it's been a while since I looked at udev. i don't think it's quite like it because the udev rules are simply expected to be in a common folder (while the hwdb is indeed a binary-type product). with the rules, the issue is that udevadm only looks in the rules shipped with the upstream package, and not in the rules collected by guix system. btw, the hwdb treatment seems to have changed dramatically in the most recent version
<lechner>3.2.12, which has prevented its packaging in Guix, but maybe the new hardcoding to the upstream hwdb does not matter if you indeed use UDEV_HWDB_PATH consistently, although I think that is an imposition on unsuspecting users
<lechner>i believe the path should be in a well-known place under /etc so that the variable is not needed for casual users
<cbaines>janneke, hmm, I think I'm giving them 2GiB at the moment, and don't have swap. How are you setting your childhurds up with swap?
<vivien>Even with the eudev update, upower still crashes in the VM. I added some printfs here and there, and I found out that upowerd (src/linux/up-backend.c:778) fails to get a handle of the org.freedesktop.login1.Manager interface of the /org/freedesktop/login1 object on the org.freedesktop.login1 bus
<lilyp>currently, it's not needed, I will rebase the branch on master once I get to tackling the things I wanted to do for emacs-build-system
<cbaines>civodul, if QA is correct, then those builds should correspond to derivations that are on the master branch
<lilyp>vivien is that from gio or the removed dbus-glib? :)
<vivien>since it builds and passes the unit tests without dbus-glib, I guess it’s from gio!
<cbaines>civodul, for the bordeaux build farm, there's some admin stuff around branch builds, because QA will cancel them when the branch is merged, but that's important as the bffe will then submit builds for those same derivations again, but with higher priorities
<cbaines>I guess CI currently has a bunch of builds that are effectively for the master branch, but associated with the emacs-team specification