IRC channel logs
2023-10-02.log
back to list of logs
<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? <civodul>adamnr: maybe it’s better now, isn’t it? <cbaines>civodul, I'm up for bayfront rebooting today if you're interested? <cbaines>the bordeaux build farm is pretty idle at the moment <civodul>cbaines: we can do that; actually the only issue is if it doesn’t reboot… <cbaines>you've got the ability to power cycle it right? <civodul>but if someone needs to be physically present, we need to schedule an appointment in the data center <civodul>and i (or Andreas) needs to go there <civodul>which is tedious and means we’ll have some downtime <civodul>but we can be optimistic and cross fingers, right? <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 <lechner->simendsjo / i use 'guix deploy' everywhere. maybe that helps you, too. <civodul>bffe is the only one that failed to start <cbaines>civodul, great, and I've started the bffe now <civodul>cbaines: BTW, guix-build-coordinator took 30s to start, according to ‘herd log’ <cbaines>yeah, from the logs it looks like sqitch (which manages database migrations) took a long time to do nothing <podiki>veriphile: I'm sure some software I use uses it under the hood and I use the script directly too, just calling it directly <civodul>ACTION runs “guix deploy berlin-nodes.scm” <minima>hi, from within a guix checkout i run `guix shell --pure --development guix guix help2man ...' <minima>then i do `guix --version' and i get 1.4.0-... <minima>however, if i do `./pre-inst-env guix --version', then i get 1.3.0... <mekeor>minima: ./pre-inst-env guix --version <minima>yeah, you see my point, that doesn't look ok, does it? <civodul>janneke: “interestingly”, the i586-pc-gnu cross toolchain has no substitutes available on ci.guix <civodul>but these are available on bordeaux.guix <civodul>i wonder if it’s just one of these 40K pending builds <mekeor>minima: what about the git commit hash at the end of 1.3.0....? :D <janneke>civodul: i've just reconfigured, but my "offloading" user fails to login using the /etc/guix/offload/ssh/childhurd private key <janneke>hmm, i've tested this on my other machine...how weird <minima>mekeor: it says 1.3.0.48218-8fc16-dirty <janneke>how do i debug this, where/how should "offloading"'s authorized keys be defined? <janneke>there is no /var/guix/offloading/.ssh directory, and /etc/ssh/authorized_keys.d only has enries for "root" and "janneke" <mekeor>minima: i think 8fc16 is the commit you have checked out <minima>mekeor: hm, i actually seem to `be45f9b4b1251df1a51a30e1d4a53fc2075abfcfe' <minima>ah, interesting - thanks mekeor, that seems to explain it! <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 <civodul>the goal is to get as close as possible to zero pending builds in the coming days <efraim>so I shouldn't push the new rust-team branch yet? ;p <lechner>tylerm / there probably isn't if you hope to contribute your package here <civodul>my hope is that we’ll use the available resources more efficiently <lechner>vivien / where is apteryx's quote from, please? <civodul>without having to restart remote-server once in a while <tylerm>i do plan to contribute it, as i dont want others to be forced to go through it <civodul>rekado: did you have a chance to look into kreuzberg? <tylerm>really the big issue with it is that guix right now is that many go packages are out of date and dont work with caddy <lechner>tylerm / that's the spirit! all for one, and one for all <lechner>tylerm / please join the golang team if you can <tylerm>so i uh currently have a scheme file that is 883 lines long or something like that of repackaging go dependcies <lechner>coming from debian, i can say that that's short! <efraim>don't feel bad, I'm at over 1000 lines of diff on the current rust packaging journey <tylerm>im just stuck rn on some of the depdencies and im wondering if there is a better way <efraim>and thats after more than 100 patches <lechner>tylerm / due to fear of a combinatorial explosion, the Guix concept of package version is less granular the versions available in real life <tylerm>i will have to come back to this later though, go leave for my college lisp class <vivien>lechner, it is, but I wish we had it when we build other dependent packages <apteryx>has git send-message started to send messages into multi-part blobs? Or did I trip some configuration in Gnus that causes these to be shown? It makes applying patches from Gnus annoying. <apteryx>I have 3 parts in a 'git send-email', e.g. [1. text/plain], [2. text/x-patch] and [3. text/plain], and must do Commands -> MIME -> View all before the | RET git am -3s <lechner>apteryx / feel free to send one to me felix.lechner@lease-up.com <apteryx>it's probably my setup, I think they all appear the same, e.g. bug#63985 <apteryx>i probably hit some weird shortcut using my not totally mastered ergodox keyboard yet <vivien>lechner, I received more feedback in the issue (make it a property of the system, not profile), so I guess the discussion is now irrelevant. <avalos>Has anyone here managed to get Bluetooth working with GNOME? <avalos>Also, has anyone managed to replace Pulseaudio with Pipewire? <lilyp>bluetooth works for me, no comment on pipewire <avalos>Did you have to install something extra? <apteryx>another thing which is unhelpful replying from Emacs Debbugs is that the subject on the reply always takes the cover letter subject instead of the specific patch i'm replying to <lilyp>bluez in os packages + bluetooth-service-type is all I have <ieure>apteryx, Welcome to the club, it took me a while to get the hang of mine, but I've been using one for nearly 10 years now. <lechner>vivien / make sense. i hope that works out for you. <avalos>lilyp: did you install bluez system-wide, or in your home profile? <avalos>I installed it in my home profile, and blueman-applet launches with this error: The name org.blueman.Mechanism was not provided by any .service files <apteryx>neat! the series bug#66217 maybe be of use to you! <aldum>I recently helped a friend setting up a Redox, and damnit, now I want one <ieure>Ergodox layout isn't ideal, but I think I prefer it over the Redox. I have the two 1.5u keys on the inside of each half mapped to ctrl/meta, and don't think I could give that up. <ieure>I'm using a SliceMK Ergodox Wireless these days, but had an Infinity Ergodox before that, and a classic Ergodox kit I built before that one (300+ solder joints, it was quite a project). <apteryx>re my gnus issue, somehow I had toggled the "Gnus Inhibit Mime Unbuttonizing", discovered by visiting M-x customize-group RET gnus RET <acrow>avalos: Not that I want to normalize a variance but blueman throws <acrow> that same error for me, on a systemwide install basis; but otherwise <acrow> seems to work fine. So, it isn't just you. It seems to be cosmetic <acrow> and difficult to resolve because of the wide variety of bluetooth <ieure>Yeah, having all the mods on both halves is great. <ieure>I also broke a finger earlier this year and was able to set things up so I could type one-handed for a while. Not much fun, but cool that you can do that. <ieure>I had it set up to use a layer flip modifier that mirrored the left-hand layout onto the right. It was an interesting experiment, never got faster than maybe ~25wpm though. <avalos>lilyp, acrow: turns out, the problem is because the system can't load the proprietary firmware for the Intel Bluetooth adapter. <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? <vivien>I know very little about udev rules <vivien>I have only learnt about udev hwdb <vivien>lechner, nice, I’ll try not to forget to mention it <lechner>vivien / please don't get too frustrated with rules, #63787 <vivien>lechner, do the rules also need to be compiled like the hwdb? <janneke>cbaines: i've got /gnu/store/mbawzv77a1k3d4ykh3j5zznymg8ijqxm-gcc-toolchain-11.3.0.drv built but that probably wasn't by offloading to a childhurd but by building inside a childhurd <janneke>not sure if that matters/mattered, but it might <cbaines>all the bordeaux hurd builds happen without offloading, so that shouldn't matter <cbaines>I'll try building it some more times <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? <janneke>i create the swapfile and copy it in, via a qemu-nbd mount <janneke>there's a patch on the hurd-team branch that runs swapon /swapfile, but for a long-lived childhurd i found that not really necessary <mirai>apteryx: re emacs x gnus x debbugs I've also encountered this <mirai>it takes the subject of the first (?) message <mirai>and I haven't monkeyed with the gnus settings so its all vanilla <mirai>perhaps worth reporting this to bug-gnu-emacs ? <apteryx>i'm afraid my replies will be harder to keep track of because of the lack of precise context (the subject) <mirai>feel free to link the issue as a sample in the bug report <apteryx>I've not seen that behavior outside of Debbugs ephemeral buffers <apteryx>e.g. in my Gnus INBOX I don't think I've ever had that behavior, so perhaps it's caused by Emacs Debbugs? <mirai>re git send-email, I don't recall doing anything crazy there, it was a plain git send-email invocation iirc <mirai>might be gnus also going apeshit with some unexpected input? <vivien>And now is the fun part where I debug the service in a VM, which means, recompile webkitgtk, webkitgtk (libsoup2 edition) and webkitgtk (next). <lilyp>does your package cause the rebuild or is CI just slow? <vivien>I need to recompile many gnome things when I touch eudev <vivien>Fortunately, I won’t touch it during the udev-service-type debugging iterations <lilyp>ahh, yeah, eudev is a real world rebuild <lilyp>maybe we should do webkit 2.42 at some point as well <anthk_>btw, can guix set wayland as default? <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 <vivien>Oh I forgot, if you try to run upowerd on a master-configured system, it crashes the same way <vivien>(if you try to run the gnome-team updated upowerd on a master-branch configured system) <vivien>It’s possible that the dbus interface of elogind changed and everything is incompatible now <vivien>Or maybe elogind is not compatible anymore with upower <RavenJoad>peanuts: You pointed out #66217, and that make me think my #64778 patch for wally-cli should be in flashing-programs.scm too. <lilyp>With elogind 252.9? Unlikely <vivien>I thought it was because upower was using the deprecated d-bus library, but it turns out it has been ported to glib ages ago <vivien>Actually it’s not line 778 because I added a couple of printfs, it’s the line that reads backend->priv->logind_proxy = g_dbus_proxy_new_for_bus_sync (G_BUS_TYPE_SYSTEM, <lilyp>civodul: if it's causing gratuitous builds, you can delete the branch <civodul>lilyp: the question is more whether it’s needed; if it’s not, i’ll cancel them <RavenJoad>apteryx: You pointed out #66217, and that make me think my #64778 patch for wally-cli should be in flashing-programs.scm too. Accidentally sent the previous message to peanuts... <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 <lilyp>but emacs-team ought to have a lower priority than master, no? <cbaines>but the prioritisation probably isn't that important, andreas seemed to have a lot of problems canceling builds though, so I'd maybe caution against that <cbaines>lilyp, it does (6 for emacs-team and 2 for master, and lower number means higher priority in Cuirass) <civodul>cbaines: oh, of course i read your message too late <civodul>i’m not sure we were in that situation (builds associated with emacs-team but in fact needed for master) <civodul>‘gnome-team’ is also taking quite a few build slots <RavenJoad>Has someone used Guix to make their programmable keyboard's firmware reproducible/buildable with Guix? <avalos>RavenJoad: That's oddly specific. <mirai>RavenJoad: apteryx has been adding some qmk/avr stuff lately <graywolf>Is there some built in alist->ini-file procedure? <Zambyte>graywolf: not built in, but there is the guile-ini package which provides scm->ini <Zambyte>I use that package from my guix home config to build some of my application configs.