***Server sets mode: +Ccntz
<lechner>i see. sorry, i thought we had control <nckx>I dread sending him an e-mail, but we might not have a choice. <nckx>I was hoping for an immediate response from the GNU DNS folks, but no such dice. <lechner>nckx: going forward, you could consider multi-homed DNS---and let clients load balance (or disregard faulty hosts) <nckx>Yes. There is so much we need to do. <nckx>Every time a server burps things just stop. <jackhill>jgart[m]: cool to hear about guix-forge! <jackhill>does public-inbox implement issue tracking? <jackhill>I always wondered how keeping mailing lists in git works? What happens when posts need to be removed. Does it break pull? <nckx>I'd guess it works like a git revert, but GDPR-friendly it ain't. <KarlJoad>Does Guix have a way to test bootloader code? I wrote my own bootloader function, and need to check that it works right. guix system build and guix system vm do not trigger the bootloader functions. <nckx>the_tubular: If you use GCC and want 9% more of it. It won't affect Guix packages themselves: they are all still compiled with GCC 10. *the_tubular guix pulls away! <nckx>KarlJoad: What about ‘guix system image -t efi-raw’, that looks promising (assuming it's an EFI bootloader). <nckx>You can still boot the result in a VM. <nckx>I need to get my 3h of beauty sleep. 'night all. <KarlJoad>nckx: Didn't know about that one. Trying it now. Thanks. <nckx>KarlJoad: Meanwhile I found a script I used once to do just that: it uses -t qcow2. I bet both work. <nckx>KarlJoad: No, because as proof that I really need to sleep: what I read as -t qcow2 wasn't a guix command, there is no such type, use the default (-t efi-raw, but you don't need to specify that) ‘guix system image’ instead and stop listening to sleepy folks. <nckx>s/Italian/French/ above. <bjc>KarlJoad: i use ‘guix system init /mnt’ to test my bootloader code <bjc>mind, my bootloader just dumps a file in /sbin/init, so it's straight-forward. for testing writing to boot blocks you can use the ‘image’ subcommand, as nckx mentioned <bjc>oh shit. sorry, i pinged again <KarlJoad>bjc: I am testing out adding a grub-efi-removable-bootloader option to write the EFI file to /EFI/BOOT?BOOTX64.EFI. I just want to see if that file ends up in the right place. <bjc>yeah, you should be fine with init, then. that's what i did <bjc>to do the test i created a disk image with dd, used sgdisk to partition it into esp and root, then mkfs on the partitions <bjc>mount the partitions into /mnt and /mnt/boot, run ‘guix system init conf.scm /mnt’, unmount everything and start a virtual machine <KarlJoad>But there is no way to live-test that the EFI file was generated to the right spot? <bjc>once you do the system init, just look inside /mnt/boot <bjc>you'll want to verify the grub modules and junk are in there, at least <bjc>this is assuming your grub target is /mnt/boot, which it probably should be <KarlJoad>The grub-efi-bootloader target is /boot/efi right now. <bjc>hrm. i can't remember if that's correct or not <bjc>gimme a sec to spin up my vm and see what i'm doing <KarlJoad>Because guix system vm does not build boot files, and guix system build does not do that either. <bjc>i would think that vm would build them, because they're needed to boot, but maybe it's doing something funky. build doesn't do it, because the boot files are only needed at install time, so that's when that stuff gets triggered <bjc>init definitely does install them, as will reconfigure -- although you shouldn't be using reconfigure for this <KarlJoad>Inside the VM there is no /boot directory at all. <bjc>looks like i'm using /mnt/boot/esp as my target <bjc>it might be wrong -- i haven't played with this in a bit and can't remember how i left my stuff set up, but this is the safer option between /mnt/boot/esp and /boot/esp, so try it first <KarlJoad>bjc: So, make a disk file, mount, partition, format, then use as a guix system init target? <bjc>disk file → partition → format → mount → system init, but yes <bjc>i ended up putting everything in a script that i could run inside a ‘guix shell’, but of course, i can't find that right now <nckx>bjc: It's OK. I wasn't an idiot this time and turned off the sound for IRC. <nckx>Why am I here then? Because the ssh && beep loop finally beeped! Huzzah! bordeaux is back up, and I can cancel the DNS trickery. My sleep is ruined but I am happy. Adios. <bjc>has it been three hours already? time sure flies <nckx>guix builds? qemu? I don't know! Nothing was ever OOM-killed, just ran its unholy natural course… <nckx>(The ‘break-in’ attempts in dmesg are my ssh loop, please disregard.) <nckx>bjc: Yes, my rest is fucked. It is what it is. Going to make the best of it now. Bye! (Really, now.) <KarlJoad>bjc: How did you format the partitions? I partitioned, but don't see an obvious way to format them. <bjc>you can give mkfs.fat an offset, which you should know from the sgdisk step <bjc>you might be able to do that with ext4? i was doing zfs stuff, so i dunno <bjc>another option is to use ‘losetup -Pf img’ to get /dev/loop devices that you can format and mount <bjc>you're gonna need to losetup them at some point anyway <bjc>you can ignore the grub config creation step. that was just for testing <bjc>but otherwise that script sets up the partition table and formats the esp <apteryx>nckx: thanks again; let's put earlyoom on that box for our future sakes <KarlJoad>bjc: Ok. Used losetup to get a device to work with, formatted, and mounted. But the system init fails with the (gcrypt hash) module having no code. <bjc>i'm guessing, but you probably need to use-module it <KarlJoad>Inside the config file? That makes no sense. <bjc>inside a gexp somewhere <bjc>it'll probably also need a (with-imported-modules) around it too <bjc>oh wait. you may need the guile-gcrypt module installed <bjc>this is one of the reasons i use ‘guix shell -D guix’: it pulls in everything you're gonna need <KarlJoad>I am using `guix shell -D guix` on a pretty empty config file, with pre-inst-env <bjc>there's no guile-gcrypt in there, though <KarlJoad>All I'm using is `guix shell -D guix`, and sudo-ing the ./pre-inst-env guix system init /tmp/config.scm /mnt. The disk image/loopback device is mounted to /mnt and the boot partition to /mnt/boot/efi. <bjc>...oh, i have that in my home config. i wonder why? <bjc>that /should/ be enough <KarlJoad>And I get no code for module (gcrypt hash). <bjc>who's using that module? <KarlJoad>In the backtrace, it looks like (guix utils) (guix config) ... are the ones causing this. Then there is a bunch more resolution. <bjc>i'm still on the “you'll need to (with-imported-modules (gcrypt hash))” train, since it's not built-in to guile <KarlJoad>In unknown file primitive-load-path "guix/store" is the last thing that has any good info. <bjc>you'll need to trace up to where it gets called from your system configuration. since you're building your own init, you should have a builder gexp somewhere that is starting this off <bjc>yeah, you're definitely on the builder side. which is good, because it makes sense that you're getting this error, but is also bad, because backtraces are so, so bad <KarlJoad>But, I am not even calling _my_ code yet. This problem is from grub-efi-bootloader. <bjc>you can start dumping (format #t "i got here!") in places to try and norrow it down? <bjc>i thought you were extending grub-efi-bootloader? <KarlJoad>I am. I want to first make sure I have commands that work. So I don't have to debug commands to run and code to write simultaneously. <bjc>ohh. so there's literally none of your code in play at the moment? <bjc>then i'm not sure anymore. it sounds to me like you need to slurp (gcrypt hash) over to the builder side, but that should be done automatically by the normal code <bjc>stash everything and start from fresh? <KarlJoad>bjc: Clean checkout of master, same nearly-empty config, same loopback disk partition setup, same issue. <bjc>i can't test it myself right now, but maybe a bug got introduced recently? <apteryx>KarlJoad: you want sudo -E ./pre-inst-env ... <apteryx>otherwise the variables set by ./pre-inst-env such as GUILE_COMPILED_PATH are stripped by sudo's default policy <apteryx>(at least that's my understanding of it :-)) <bjc>that makes sense. i use doas with keepenv, so i never would have run into that <apteryx>are backtraces visible somewhere in a failed Shepherd service? <KarlJoad>apteryx: That seemed to work. I'll check back in when things are done. Thanks! <apteryx>no worries -- beware of --sysconfdir which should be /etc <KarlJoad>Oh. I need --sysconfdir=/etc when doing system init? Should it be /mnt/etc? <bjc>no, that's for running configure <bjc>you shouldn't need any flags for running system init <KarlJoad>Just the usual localstatedir flag. Cool. <bjc>awesome. i look forward to having --relocatable be an option <bjc>s/relocatable/removable/ <bjc>i should probably go to bed <KarlJoad>Getting removable working seems to have been easier than I thought it would be. I see there are tests that involve grub in the tests directory. But is there somewhere in particular for grub tests? <KarlJoad>Also, is there any reason to make computer definitions a channel? Perhaps automatic building? <KarlJoad>sneek: later tell bjc Removable support for Grub is now up for sharing! Enjoy! <Ox151>hello how am i supposed to create a new group to add a user to? <Ox151>seems it has to be created before it can be added to suplementry-groups <Ox151>or does it have to be defined in the config.scm <KarlJoad>Ox151: I would recommend you define it in config.scm. <KarlJoad>Although you can go behind Guix's back and do a groupadd. I don't recommend it though. <Ox151>KarlJoad: I cannot find the correct documentation to define in config.scm <KarlJoad>It is in the Guix manual under User Accounts. (guix) User Accounts <Ox151>i love how guix documention leaves much to be desired for flushed out examples. as someone new to lisp there is no guidenence on where (user-group) is supposed to be placed. <KarlJoad>That one isn't great, I agree. I am pretty sure it should be placed inside the operating-system record. <KarlJoad>Might be under the groups field too. I forget which. <Ox151>ive tried like 6 different places in (operating-system) and still nothing. <Ox151>"This type is for, well, user groups. There are just a few fields:" Thanks documentation! <KarlJoad>I think it is a bit sparse because it behaves the same way as the users field does. So you have to cons* or append your newly-define group to the %base-groups list. <Ox151>KarlJoad: that seems to be compiling. thank you <Ox151>where is the reference to groups in any of that documentation? ><' <KarlJoad>That contains documentation for every field the operating-system record accepts. <Ox151>of course it does. is the process for helping improve documentation for new users difficult? i have ran into many examples of where things are not friendly to new users where I would not mind adding edits for clarification and easier guidence. <KarlJoad>Depends. Some of the documentation is automatically generated, and others is manually written. I think everything manually written is under the doc directory in the guix repository. <Ox151>thank you for all the help. ill check it out and see if i can help with making things clearer for new users as i stumble across things. ***dongcarl1 is now known as dongcarl
<abrenon>I failed to notice exactly at what point but my microphone seems to no longer work with the web browser <abrenon>it appears as if I hadn't granted it permissions <abrenon>the trouble occurs with various conference tools like jitsi <abrenon>I run them from a fresh session so I'm pretty sure there's no application grabbing the rec device and failing to give it back <abrenon>I've looked at pavucontrol and alsamixer <abrenon>(meanwhile, webcam works flawlessly) <abrenon>hmm, granted, I haven't tested with another web browser than chromium, ok, I'll test that <scisssssssors12>hi! does anyone know why guix.gnu.org and ci.guix.gnu.org are not accessible from russian ip? i might know the reason but i'd like to know for sure. bordeaux does work but it's very slow today. thanks <scisssssssors12>got it, thanks for the link. glad this block comes not from guix side. i have to find http proxy then it seems <cbaines>bordeaux.guix.gnu.org had some troubles in the last few hours, but it should be back now <scisssssssors12>i'm not really sure that slow download speed was the issue to be honest. i was running guix pull for ~2 hours with "updating substitutes" lines slowly appearing <cbaines>there were DNS and other server issues for a period within the last 24 hours, but I think things should be back to normal now <abrenon>ok works again apparently it fixed itself by tweaking long enough <angelos[m]>beginner question: how do you get `/bin/sh` in your guix profile? search engines fail me atm <abrenon>angelos[m]: what do you mean ? it's there by default isn't it ? <angelos[m]>oh, sorry, I meant when using guix on a foreign distro 😇 <jpoiret>angelos[m]: you'd want bash-minimal or bash, depending on whether you want it for scripts or for interactive use <angelos[m]>jpoiret: oh interesting. How does guix decide which shell gets to create the `/bin/sh` symlink (I'd tried dash first but that only gives `/bin/dash`, i.e. doesn't create `/bin/sh`) <jpoiret>i think /bin/sh is only provided by bash <jpoiret>there are no "alternatives managers" like on some distros <jpoiret>ie we don't have the python -> python3 symlink <angelos[m]>jpoiret: thanks for the info! (is there a document this could go in?) <jpoiret>i don't think there's a specific place it could go in <jpoiret>maybe Guix deserves something like "A gentle introduction to Guix concepts and workflows" <jpoiret>the thing is, we can't really take into account every expectation that other distros put in their users' mind imho <angelos[m]>I was thinking more along the line of "Guix for debian users" 😉 <jpoiret>i'm not aware of anything like that, maybe that would deserve a personal blog post or something like that <angelos[m]>added it to my guix.org file, if I collect enough tidbits I'll see if I can dump it somewhere <angelos[m]>similar question: is there a way to find which packages provide a path? <efraim>it depends, but we don't have anything like 'apt-cache search <file>'. Depending on if I know the depth I might use 'ls -d /gnu/store/*/bin/foo' or 'find /gnu -name foo' and then cancel the search when I have an answer I like <angelos[m]>right. that covers one use case, though the use case I had in mind was more like "I don't know the name of the package that provides the executable/header that I'm missing" <efraim>I've definately used find to find libfoo.h before <efraim>other times I actually ssh into a debian vps I have and use apt-file search there <angelos[m]>right, but that only works when you already have the package installed somewhere <efraim>true, I always forget about that part <attila_lendvai>is there a way to define gsettings values from config.scm? i'd like to disable auto suspend in GDM, and for that some dconf values must be set for root... <jpoiret>i don't think we have a mechanism for that yet, but it's definitely doable, since there's are dconf distro override files attila_lendvai <attila_lendvai>jpoiret, it means that i should just add an extra-file in my config.scm? *attila_lendvai is searching for the proper name of that concept <attila_lendvai>jpoiret, thanks! what i need now is the guix concept to use to generate a file into /etc/xyz from config.scm *attila_lendvai has found special-files-service-type <jpoiret>you'd need to extend etc-service-type <jpoiret>bluetooth-service-type extends etc-service-type if you need an example <attila_lendvai>ddclient-activation imports (ice-9 rdelim) from the host. i guess that's a mistake, as there are no comments there describing why that is so. <sammm>hey - first time guix user! I have done something very silly and reconfigured my base system without any of the coreutils / guix / sudo, so I am not able to reconfigure it back to normal. Any ideas? <jpoiret>no coreutils? how did you end up without them? <jpoiret>that means no su program, at least not suid, right? <jpoiret>you could just log-in as root and reconfigure from there <sammm>I guess root is the answer - thought it might be a good learning experience to get it back <jpoiret>i mean, if you don't have su or sudo, i don't see any other way :p <sammm>hahah - I _think_ I mangled the packages list and am not including %base-packages <jpoiret>right, that seems like the most likely culprit <sammm>welp, i'll go root lol, I thought I'd be able to load back to an older system in grub, but didn't work <sammm>i went and picked the only entry in the "load older config" option, but same story, no coreutils <nckx>You could try manually invoking /var/guix/profiles/system-$number-link/profile/bin/foo? <jpoiret>regarding where your mistake might be, did you also mangle setuid-programs <nckx>I mean, I assume sammm's root profile doesn't have coreutils explicitly installed either? I dunno. <nckx>/run/setuid-programs *should* be separate, not affected, and available, if you're lucky. <nckx>…but jpoiret already hinted at that. <sammm>i'll assess the damage and let ya know <lechner>Hi, should guix weather be computed on the substitute servers? <cbaines>there's some caching of substitutes when guix weather runs, but that's local caching, and won't speed up running it on other machines <roelj>hi guix, I have an almost-trivial and low-impact-on-guix update patch for virtuoso at #55538 but I realize the backlog is rather large already. I've been away for a while, but I wonder if I can simply lessen the review burden and push the patch. WDYT? <lechner>Hi, on startup I see timeouts from udev-daemon (3 x 25 secs) for being unable to start certain freedesktop.org services. Is there a way to get rid of them? <lechner>i also see elingin is already running (2 x) <bjc>shouldn't booting to an older system config generation from grub have fixed sammm's problem? why would that have gone wrong? <sneek>bjc, KarlJoad says: Removable support for Grub is now up for sharing! Enjoy! <civodul>jpoiret, mothacehe: yay for the (guix platforms) change! <civodul>"make cuirass-jobs" is still failing though, apparently due to a cross-compilation job <civodul>#<&inferior-exception arguments: (%exception #<inferior-object #<&gexp-input-error input: #<unspecified>>> <bjc>how does cuirass work? does it iterate over every package? <jpoiret>does `make cuirass-jobs` work in a fresh checkout, or do i need to set up cuirass? <jpoiret>i'd love to help debugging cuirass but it looks like it requires a lot of setting up and that most issues crop up when under heavy load <nckx>Low priority, but I can't pull on berlin: guix offload: error: failed to load machine file '/etc/guix/machines.scm': (record-abi-mismatch-error abi-check "~a: record ABI mismatch; recompilation needed" (#<record-type <service-type>>) ()) <nckx>--no-offload seems to work so far. <jpoiret>is it possible that /etc/guix/machines.scm has been compiled somewhere? <jpoiret>although it shouldn't reference anything related to service-type, right? seems pretty weird <civodul>jpoiret: works in a fresh checkout, you don't need cuirass <civodul>it does the same thing as the "cuirass evaluate" command, which Cuirass uses internally <nckx>jpoiret: I'm not really sure what's going on. I removed ~nckx/.cache & ~root/.cache and it's currently refetching stuff. <nckx>.cache/gui* that is, to be less wrong. <jpoiret>i think i ran into the same issue as you, although the process hasn't died either after printing the exception civodul <jpoiret>(i've also gotten warnings about forking with threads, so it seems i've just ran into the usual lone waiting thread bug) <mothacehe> jpoiret: civodul: I also experiment the gexp-input-error. I don't remember how I used to debug problems in this file <nckx>Removing the caches worked. <mothacehe>I'll try calling cross-jobs from a guix repl <mothacehe>ok so looks like the issue comes from target->openssl-target <mothacehe>I ran: ,use (gnu ci) (guix store) (guix packages) <mothacehe>(map (lambda (system) (cross-jobs (open-connection) system)) %cuirass-supported-systems) <mothacehe>and it gave the same error but with a much more explicit backtrace <jpoiret>ah, right, cause you're not using an inferior for it, right? <jpoiret>build-aux/cuirass/evaluate.scm calls one iiuc <mothacehe>it would be nice if inferiors could show the same backtrace but i don't know if it's possible <jpoiret>what's different about openssl that makes it use CONFIGURE_TARGET_ARCH (which I cannot find any doc for)? <mothacehe>maybe we should merge back those to (guix platforms) as well <jpoiret>mothacehe: right, i hope there aren't a thousand other configure systems like this <jpoiret>is there a mapping target-triplet <-> openssl target? <mothacehe>In procedure put-char: Error while printing exception. <mothacehe>jpoiret: you mean something like target->openssl-target ? <jpoiret>no, rather, is there a 1-to-1 correspondance between both <jpoiret>maybe we could implement something that would enforce complete pattern matching <jpoiret>that would let us leave these next to the packages they're concerned about, and we could still benefit from having well-defined platforms <jackhill>oh no, I need a texlive package that's not yet packaged. Will this cause me to break up with TeX? News at 11! <jpoiret>otherwise i see these getting a lot of new fields (for example, openssl1 doesn't recognize linux-riscv5, so we'd *ideally* need another field for it) <mothacehe>yeah, extending <platform> for each package defining its own triplet won't be viable in the long term <civodul>feel free to review/apply other people's almost-trivial patches as well :-) <civodul>mothacehe: now that you've narrowed it down, it's prolly enough to run: ./pre-inst-env guix build openssl --target=s390x-linux-gnu ? <jpoiret>weird though, since line 798 of gnu/packages/linux.scm does seem to make the proper conversion <jpoiret>mothacehe: do you know which arch this was for? <cbaines>on the subject of s390x-linux, is there a reason why it's listed by guix build --list-systems ? <cbaines>I think for all the other listed systems, there's some notion of "support", but for s390x-linux guix tells me there are isn't a tar bootstrap binary <mothacehe>cbaines: you're right maybe we could remove the s390 platform altogether <jpoiret>the bug is coming from platforms that don't have a linux-architecture, eg hurd or i686-mingw <cbaines>mothacehe, that seems reasonable, it can always be added back if it has a purpose <mothacehe>oh we shouldn't try to build linux for those in the first time, the error should also be more explicit <jpoiret>you can reproduce it with `./pie guix build linux-libre --target=i686-w64-mingw32` <mothacehe>what about erroring out of make-linux-libre-headers if lookup-platform-by-target-or-system returns #f? <civodul>why are we attempting to cross-build linux-libre-headers for MinGW in the first place? <civodul>maybe we could filter it out in (gnu ci)? <jpoiret>supported-systems won't work here cause the current target is used to create the (package ) record <mothacehe>linux-headers must be a depency of %core-packages that we are trying to build for all triplets <jpoiret>linux-headers doesn't exhibit this behavior <jpoiret>hmmm, make cuirass-jobs ends up asking for (all-packages), which just folds all packages <jpoiret>you could also remove the two lines in the manual mentioning them as available targets <mothacehe>jpoiret: yes all packages are built for %cuirass-supported-systems, and cross-packages are built only for %core-packages for all targets <mothacehe>re manual update: yes it's part of the patch i shared <jpoiret>my bad, missed that part. looks good <jpoiret>grep'd and didn't see anything else either <mothacehe>should make the openssl patch useless, for now! <apteryx>civodul: new experiments with fixing the jami service; I thought perhaps fork+exec-command now using guile fibers was causing issues. This proc is used by the dbus-send machinery in (gnu build jami-service). So I've copied the version from Shepherd v0.8.1, autoloading the other bits needed. Now (dbus-available-service) works locally, but in the VM, it prints an odd backtrace: <apteryx>if you have ideas of what this could be attributable to, I'm all hears :-) <jpoiret>seems like with-blocked-signals is not there at compile time <jpoiret>you will need to change the #:select argument of source-module-closure inside the definition of the jami service <jpoiret>the default one only selects guix modules, so it won't import the shepherd modules <jpoiret>that's why you end up without with-blocked-signals (both the geiser warnings and the error are symptoms of this) <apteryx>that'd explain it :-) I'll adjust and report <jpoiret>since the file is loaded by shepherd afterwards, it'll manage to see the rest of the shepherd modules at runtime, which is why that error wasn't noticed earlier <jpoiret>civodul: ci doesn't build for i586-gnu, right? <jpoiret>currently, evaluate.scm tries to build all packages for systems in %cuirass-supported-systems, which contains i586-gnu, but that's not possible since the fold-packages will just error for linux-libre <jpoiret>i'm thinking we could remove it for now <apteryx>ah, now I get ;;; Failed to autoload %precious-signals in (shepherd service):\n;;; no code for module (fibers) <apteryx>I guess I'll try to come up with a minimal, non-Shepherd equivalent to fork+exec-command <apteryx>if I try to pull guile-fibers in a with-extensions form wrapping the source-module-closure, I still get: In procedure load-foreign-library: file: "/gnu/store/c92i95rnwlwrs1a6283jjgp7skha4mjy-guile-fibers-1.1.0/lib/guile/3.0/extensions/epoll", message: "file not found" <civodul>sneek: later tell mothacehe i'm fine with removing s390x-linux <civodul>apteryx: no idea, but i'd hope we don't need to get this far <civodul>it'd be interesting to see how we can simplify the Jami services so we need less support on our side <civodul>do they have a .service file for systemd? <civodul>jpoiret: right, ci.guix doesn't build for i586-gnu currently (i wanted to revive it a month ago, but there were other things going on there) <apteryx>there's a D-Bus service that could take care of the jami-dbus-session, but we don't have support for that in Shepherd. <civodul>no, but we delegate D-Bus service startup to dbus-daemon <tribals>I may be wrong, but I remember I've seen a package definition with multiple `(origin ...)` s. Could it be? <civodul>tribals: yup, you can add origins in 'inputs' for instance <apteryx>civodul: I think the problem with autostarted things is that we loose control regarding when things are stopped and started <apteryx>civodul: in any case, the jami-dbus-session is not where it's failing right now; that parts works OK. Most of the complexity comes from implementing actions and provisioning capabilities, which require talking to the service over D-Bus <apteryx>and since we do not have a D-Bus library in Guile (that is finished and works), we have this wrapper above dbus-send in (gnu build jami-service), which uses fork+exec-command to run it as a specific user/group and capture its output <apteryx>as far as I know, there's no such thing in a systemd equivalent outside of Guix; it'd requires their users to script it their own. <civodul>we have services of all flavors: dbus, old-style daemons, inetd, etc. <civodul>and none of them requires this much machinery on our side <apteryx>do we have d-bus services with which we are talking D-Bus? <civodul>i'm not sure what you mean; it looks like Jami uses its own bus instead of using the system/session buses, right? <apteryx> yes, it requires a session bus, not a system bus <apteryx>such bus is typcally started at login, not as a system service <apteryx>I think for us it's handled by elogind <civodul>sorta like pulseaudio, colord, and all that <civodul>am i right that the difficulty is largely because we're trying to start a user service as a system-wide service, and without much help from dbus? <apteryx>that's one of the odd thing that required the jami-dbus-session service, yes. But that's not where the bulk of the complexity lies. <apteryx>the complexity is being able to talk over that bus using the Jami D-Bus API <apteryx>so that we can ban/unban users, add users, do this kind of thing as shepherd service actions <apteryx>the most important being deploying an account archive when the service boots <apteryx>the current actions supported are: (list-accounts list-account-details list-contacts list-moderators add-moderator ban-contact list-banned-contacts enable-account disable-account), which rely on the D-Bus API of jamid (the daemon). <jpoiret>how would you talk to the service on system boot before the session bus is started? <apteryx>the jami service spawns its own, private session bus <apteryx>was there a way to get connect a REPL from shepherd? <civodul>apteryx: i suppose the Jami UI lets you do those things as well though? <jpoiret>make cuirass-jobs is stuck for me now, with nothing much happening (after removing i586-gnu from %cuirass-supported-systems) <civodul>how important is it to have those actions available from "herd"? <civodul>jpoiret: actually that's good; i have a local change to call 'open-inferior' upfront <jpoiret>yeah it seems really horrible, esp. having to debug with strace <jpoiret>i'm not familiar at all with cuirass, what would recommend looking at first? <jpoiret>btw, i see you said that the finalization thread was left alone after forking, but i'm not sure i follow, it shouldn't be the one forking right? <apteryx>civodul: without D-Bus support there's no provisionning capability; i.e. makes little sense in Guix System. <apteryx>civodul: yes, you can do all this from the Jami Qt client. The use case of jami-service-type is to have a way to run the daemon on a server in a reliable and declarative way, that doesn't require you to login a graphical session, start the Qt client and configure things there, and leave it all open as your user. <apteryx>(e.g., running a rendezvous point on a headless server) <lilyp>for the record, guile still has a bug that makes it so we can't call session bus methods from it <cbaines>civodul, on the topic of the inferiors+threads, what's the benefit of open-bidirectional-pipe providing a file port compared to open-pipe*'s custom binary port? <civodul>cbaines: the port can be passed to 'select', as written in the docstring <civodul>it's relied on by the procedure called 'proxy', IIRC <lilyp>apteryx: the issue is with guile sockets IIRC <civodul>jpoiret: re finalization thread: i don't know, but fork(2) is unspecified in the presence of multiple threads <civodul>the child process has a single thread anyway <lechner>Hi, did someone figure out why so many packages are being rebuilt? It wasn't the new gcc-toolchain, I don't think <civodul>apteryx: there's also guile-ac-d-bus, which is pure Scheme <jpoiret>looking at fork(2), it says that the child has only the calling thread reproduced <apteryx>why is writing posix_spawn bindinds unpleasant? Wouldn't that be the definitive solution here? Perhaps I haven't followed well, but it seems to me the current solution pursued is attempting to restrain our use of threads so that undefined behavior is made defined (in a very fragile way) <nckx>Coming from fork/exec, calling spawn unpleasant is daring. <civodul>the main issue is timing: CI is out, and we'd write a bunch of code under pressure, for an interface that's quite complex <nckx>But I come not to mock unix, I come to ask: does anybody use D on Guix? There's a dub-build-system; it's unused. Dub and rdmd are broken. So I guess: not…? <civodul>that said, posix_spawn bindings would be nice to have longer-term, sure <cbaines>I haven't spotted yet why select is essential to use with the inferior socket in the proxy procedure <bjc>isn't the traditional way to handle fork+threads to spawn a process before threads are spawned, then use ipc to tell that process to fork on your behalf? <civodul>cbaines: in commit bd86bbd300474204878e927f6cd3f0defa1662a5, select is passed an extra argument <civodul>bjc: that doesn't work if you need to share some initial environment with the child processes, such as file descriptors <bjc>you can pass file descriptors around over unix domain sockets <cbaines>civodul, yeah, I'm comparing the before and after. I get that there's something about the proxy stopping when the response port can be read from <maximed>time guix build --list-targets -> half a second, with a pause between ‘The available targets are:’ and the first listed target <cbaines>so before, the proxy stopped when the store connection was closed from the inferior <maximed>Going by "strace", it is loading various (gnu packages ...) <maximed>Looks like #:use-module (gnu packages linux) has been removed, so should be faster on next "guix pull"? <cbaines>in terms of quick fixes, maybe the store connection caching in the inferior could be made optional, which would enable using the safer open-pipe* approach in Cuirass, which as far as I can tell, doesn't benefit from the store connection caching <cbaines>this connection caching is something I've come up against in the data service as well <apteryx>sounds reasonable to me; slow wins over broken <apteryx>but if I recally there was a bug associated to not caching inferiors <cbaines>I'm seeing the "warning: call to primitive-fork while multiple threads are running" as well, although I haven't noticed any problems because of it (but I'm not using lots of cores) <apteryx>quoting civodul: "the inferior change did fix an actual bug that one could see with "make cuirass-jobs"" <cbaines>which inferior change? if I'm remembering correctly, this store connection caching was a performance improvement that related to manifests I think <apteryx>fixed in c71910a095f7e1ef0ab4c1fbea85348373e5a264 <attila_lendvai>what's the deal with perl and cpan? perl-http-daemon has a 6.14 tag in github, but it's not found in the given mirror://cpan/authors/id... url. the latest there is 6.02 <nckx>Are you still using the old GAAS URL? <nckx>If so, that is the deal: those change frequently. <jts>what would be the equivalent on Guix to systemd's system.conf and user.conf? Specifically I'm interested in the DefaultLimitNOFILE option <efraim>IIRC the perl updater also updates the source URI <nckx>attila_lendvai: Actually, recent ‘guix refresh’ should do that for you. <nckx>efraim: Thanks for your reply. I found out about btdu as well, but it requires a working Dub build system which we seem to lack. <nckx>Hence haven't been able to play with it yet. <efraim>I thought we had a dub-build-system <attila_lendvai>guix refresh worked fine, but now i'm at "If you're seeing this warning, your toolchain is really, really old" (and need to go) <nckx>Interestingly, nothing uses it… <efraim>I'm thinking of limiting zig to 64-bit architectures, there's an open bug about it needing ~10GB of ram to link one of their bootstrap stages <nckx>attila_lendvai: Ignore that, look at the actual error. You're just missing a new dependency. <maximed>jts: There is pam-limits-service-type <maximed>And attila_lendvai has a patch to allow setting the limits for shepherd services <KarlJoad>On a recent checkout of Guix, I am getting a match-error with package polkit@0.120 not being found. Is anyone else getting that too? <nckx>KarlJoad: When running what? <nckx>My checkout is fresh 's can be but I haven't seen that so far. <nckx>It is extremely mandatory. <unmatched-paren>lechner: you'll need to check out the git repo, switch to the commit, and run `guix hash -rx .` <nckx>The easiest way, frankly, is to use a bogus (but valid) hash like 1l17qq2wc1y93zzb6pi9cxpkdnyaby9bms4ah5hzcdcpfk98wajc, and then wait for Guix to throw an error with the correct one. <nckx>Another ‘correcter’ way is to use ‘guix hash -rx .’ in a very pristine checkout. <KarlJoad>nckx: I am trying to build my running system using the removable-grub patch I made. When I use a special channels file to pass to guix time-machine (I have extra channels defined for my user) to travel to, then system-build. <lechner>okay, as a noobie i'll go the official route <KarlJoad>The channels file is valid, the time-machine works. <nckx>Copying hashes from other packages is a bad habit yes. <nckx>You should change them a little. <nckx>However: this probably just means the package you were working on was buggy and didn't use file-name. <unmatched-paren>feel free to convert that to your own shell and/or scripting language (guile, perhaps? :P) <nckx>lechner: OK. In truth, the vast majority of people use the copy/paste/adjust route by the way 😉 <nckx>But the ‘official route’ is sliiiiiightly safer in exchange for the extra trouble. <nckx>KarlJoad: Could a channel be lagging behind? <unmatched-paren>`hashrepo GITREPO [REF]` is how it's used. i find it easier than either method :) <unmatched-paren>it's rather hacky given that it's a tiny shell script, but it should Work *unmatched-paren decides to convert it to guile right now <nckx>I can't see anything wrong with it. <KarlJoad>I mean, in theory. But the only channel that could be lagging is one that definitely builds, because that is what my system is running. I copied the channels.scm from /run/current-system <nckx>That weird shell you're using. <lechner>unmatched-paren: guile would be nice, but i want fish, too! <nckx>unmatched-paren: I swore I wrote fish. My muscular memory be swole 💪 <unmatched-paren>lechner: the guix profile? you'll need to set up fish in Guix Home i think <unmatched-paren>there's probably a way to do it without Guix Home but it's not documented afaicr <lechner>i used bash for twenty years and love fish. it stores my entire workflow! <lechner>there are just so many things to learn <unmatched-paren>I actually think the TTY in general is pretty outdated and wish I didn't have to use _any_ shell, but somehow all the desktops are worse (desktop metaphor and/or reliance on mouse) <unmatched-paren>I would like to see a vi-like-keybinding based _desktop_ (not just WM) <nckx>The shell is the worst interface, except for all the others. <nckx>KarlJoad: Could you share your channels.scm, and the exact command that fails? If willing. <KarlJoad>I shouldn't share the channels.scm file, because it references a non-libre channel. But the command I can. <lechner>unmatched-paren nckx: for servers, you prefer X termnals? *unmatched-paren has never operated a server :P <nckx>lechner: I don't follow, I fear. <KarlJoad>`sudo -E ./pre-inst-env guix time-machine -C /tmp/channels.scm --disable-authentication -- system --substitute-urls= <nckx>I said I prefer the (text) shell. <KarlJoad>`sudo -E ./pre-inst-env guix time-machine -C /tmp/channels.scm <nckx>It sucks and yet nothing comes close. <unmatched-paren>Unfortunately, sway et al are just interfaces to arrange your shells (and web browsers, which are even WORSE than shells) and don't try to actually fix the issue with TUIs <nckx>Sure. They don't (cl)aim to, though. *nckx uses Sway, full disclosure. <unmatched-paren>Right now i have four foot windows open in sway. The top-left running senpai, the bottom two running neovim, and the top right running fish. <unmatched-paren>I guess the ability to wield such an interface gives you l33tp01nt5? <nckx>Well, they are, with V O I C E. <lechner>unmatched-paren: do you have completion with 'pass' ? <maximed>On hashing git repos: I believe there was some patch that adds git support to "guix download", though I couldn't find it again <nckx>I thought that was the long-term plan yes. I too remember a patch… <KarlJoad>nckx: But the channel references my personal channel, which does not reference polkit, and my guix branch on Github, along with a third, not-nice channel. The not-Guix channel checkouts _do_ work, because my system is currently running them. So only Guix should have changed. <maximed>unmatched-paren: Conversion from cargo-build-system to antioxidant-build-system is mostly automatic, but there's some non-automatic fiddly stuff too that needs some manual corrections. <lechner>unmatched-paren: what's missing, please? inherit is not enough? <maximed>Pick a package you'd like to build with antioxidant-build-system <maximed>Build it with antioxidant: do "guix build -L . -f antioxidant-packages.scm" <lechner>and then guix package --install-from-file= ? <unmatched-paren>requires a few rust-windows packages that were annoying so we could remove those with antioxidant <maximed>If it doesn't, fix bugs (missing deps, version conflicts, features not being set) <maximed>one method of fixing the bugs sometimes is to update the crate <maximed>but I haven't checked the source code for malware or such <maximed>so strictly speaking actually running the results is currently unsafe <maximed>unmatched-paren: lemme find the mail <maximed>if you add that channel you can do "guix build antioxidated-hexyl" and such <yewscion>Hello all, quick question for those familiar with the ungoogled-chromium package in Guix: On a foreign distro (FWIW), where does ungoogled-chromium look for managed/recommended policy files? I am trying to switch to ungoogled chromium at work, and need to enable Kerberos authentication (I use Icecat for most things, but need a chromium-based <yewscion>I have tried `/etc/chromium` but it doesn't seem to be picking that directory up... <maximed>lechner: You can't install a definition, you can only install the package itself. <maximed>Add the symbol guile-xcb-jep90 to the end of the file <jts>lechner maximed: thanks y'all! <yewscion>Nevermind all, had a window running in the background, so it had never restarted. Picked up the policy now. Sorry for the noise! <lechner>Hi, does the 'native' distinction exist on inputs to aid with cross-compilation? <jts>lechner: would I cons that pam-limits-service onto base-pam-services in the pam-services slot of the operating-system reference? <lechner>so native only if the build process depends on the architecture-dependent parts of that input? <maximed>lechner: the other way around I think? <lechner>jts: i just added it to my modified services, but i am new here <unmatched-paren>lechner: ah, just remembered something: (package/inherit foo ...) is preferred to (package (inherit foo) ...) for apparently graft-related reasons? <lechner>unmatched-paren: i need to add autoconf, for autoreconf b/c ./configure and ./m4 were dropped <lechner>maximed: Hi, how do u read this, please? It's the opposite of Debian/Ubuntu, isn't it? ":native" is appended to a build-dep to signify that it should be installed for the build (i.e 'native') architecture rather than the host architecture. https://wiki.ubuntu.com/MultiarchCross <lechner>that being said, i prefer the Guix nomenclature <maximed>lechner: build & host is somewhat ambigious <maximed>native-inputs = build it for the architecture machine on which the package is build <maximed>inputs = build it for the architecture the package will eventually be run for <lechner>i think both are unclear. perhaps host and target woule be best <maximed>I haven't seen any stones being thrown. <maximed>lechner: But what about cross-compiling a cross-compiler? <maximed>Then you have both host, build and target, and they can all be different. <unmatched-paren>native-inputs should be used when the input is _never_ used at runtime <unmatched-paren>e.g. a C library wouldn't be native, as it needs to be present at runtime for the dynamic linker <maximed>With some exceptions, e.g. if the build script of a library as a test links the library against another library to build a test program (though the test program would only be build, not run, because cross-compiling) <unmatched-paren>but pkg-config only exists to query stuff in e.g. the makefile, so it'd be a waste of time to cross-compile it. <maximed>it's not only a waste to cross-compile it, it's also useless when it's cross-compiled, because then it cannot be run from the makefile <maximed>(with some exceptions, e.g. rust-pkg-config) <bjc>it's not a question of a waste of time; if a package is needed to do the build in the first place, it has to be a native input, because the target/host input won't run due to being the wrong architecture <lechner>in my view, the Debian multi-arch spec named amny things backwards, so please forget you saw that link <maximed>lechner: also, build vs runtime can be somewhat incorrect depending on how you interpret it: what about static libraries? <maximed>They are embedded in the binaries, so they don't end up in the references (guix gc --references), so in a sense, they aren't 'runtime' <maximed>though they could also be considered 'runtime' in other senses of the word <lechner>not sure, but i'm glad guix picked an approach that's different <maximed>The rust application 'dutree' now builds <lechner>how do i add autoconf to the existing native-inputs of an inherited package definition, please? <unmatched-paren>lechner: i believe `(native-inputs (cons autoconf (package-native-inputs OLD)))` but i might be wrong <bjc>‘modify-inputs’ sounds right <bjc>at least for new-style packages. i don't know if that works for old ones <maximed>(new style is converted to old style under the hood) <unmatched-paren>lechner: (native-inputs (modify-inputs (package-native-inputs old-package) (prepend autoconf)))` <lechner>where is this please? error: package-native-input: unbound variable <vagrantc>yeah, guile gives pretty quirky errors when there's a stray or missing paren somewhere <KarlJoad>How unreasonable would it be to have all of an operating-system configuration be built for a VM? The current system-vm command does not produce bootloader code. Perhaps a full-vm command to generate a near identical VM, with bootloader code and all? <maximed>KarlJoad: "guix system image" + run the image <maximed>Maybe try "guix system vm --full-boot" <maximed>dunno if that does what you want though <FlaminWalrus>Anyone know the xkeyboard-config options for unbinding left hyper from Mod4, if any? The StumpWM manual advises the use of xmodmap, but I'd prefer to put it in my system config's keyboard-layout. <KarlJoad>maximed: From the manual, that was exactly what I wanted. Thanks for pointing it out. <KarlJoad>guix shell: error: gcc-12-strmov-store-file-names.patch: patch not found, when building a shell from a manifest listing gcc-toolchain. <lechner>unmatched-paren bjc maximed: Yay, I built my first custom package. Thanks so much, everyone! <lechner>Hi, what's the project standard for Guile formatting, please? <bjc>if you're using emacs, there's a .dir-locals.el file in the top-level of the guix directory with formatting rules <maximed>lechner: Also, "guix style", though it's not perfect <lechner>ah thanks, i tried indent-region with mixed results <bjc>i think every time i've invoked ‘guix style’ i've had to go back and clean up <KarlJoad>Is there a better way to refer to the make package? I have (use-package-modules base), but make is still an unbound variable. <nckx>KarlJoad: The variable is gnu-make, not make (that's the package ‘name’ — confusing!). <maximed>rust-jemalloc-sys now builds with antioxidant <nckx>KarlJoad: You'll get used to it. Much like input labels, the distinction may well disappear someday. *nckx glances at the sizeable backlog — oh dear, did somebody accidentally say ‘run time’ again. <KarlJoad>It likely will. I just wish guix-search output the package name, not just its common name. <bjc>you're right. we should have read/compile/eval/run time <bjc>(eval-when ia-cthulu-fhtaghn-ia) <nckx>Don't forget ‘write time’ (‘development dependencies’ handled by some package managers too). <nckx>modify-inputs has a ‘replace’ clause. <unmatched-paren>nckx: not sure how you'd eliminate the distinction between names and variables <unmatched-paren>how would you handle that case? it's possible that the -11 is just part of the name, so you can't automate splitting it <nckx>(define guile-srfi-145@0.0.1 …) is one possible way. This is Scheme, after all, yolo etc. <nckx>Don't worry, I'm not saying every corner case would be pretty! There will always be isc-binds to worry about :) <maximed>Even that problem: could be eliminated: (define-public 📦bind (package (name "bind" ...))) <bjc>does guile default to utf-8 these days? <nckx>maximed: I… I am not sure I should admit that I thought of that too? <bjc>i thought i remembered reading it's 8859-1 <nckx>But it was more like a (📦 …) disambiguation procedure for bind et al. <maximed>For some things, it uses the encoding of the current locale <bjc>reading a file with no previous encoding specified and no byte-order marks available <maximed>bjc: dunno, I guess UTF-8, US-ASCII or ISO-88519-1 <maximed>nckx: (define-public 📦bind (📦 (name "bind" ...))) <bjc>emoji might cause problems then. to whom do we complain so that we can have emoji identifiers in the next guile? this is very important <maximed>(define-public 📦make (📦 (name "make" ...))) <nckx>unmatched-paren: Anyway, I wasn't really advocating the move and certainly not a particular implementation, I was just referring to the fact that suggestions of a (define-package NAME …) form that does away with an explicit <name> keep popping up, and eventually someone will do something with one. <nckx>OK, so now I can't not share a TIL I had earlier today <nckx>that \o/ , poo, fu, and llap (live long and prosper yes) are all valid XCompose sequences? <bjc>i did not. and i've even gone through the xcompose mappings a while back to get some of my onwn stuff in <nckx>I obviously need to add <Multi_key> <P> <K> <G> to my list now. <jpoiret>nckx: do they work on sway by default for you? just tested, none of these do <jpoiret>wait till you all hear about proof assistant langs using all of the possible UTF-8 codepoints <nckx>jpoiret: Weird. They work out of the box for me (I should have made it clear that ‘valid’ meant ‘upstream’). <nckx>This is in foot on Sway on Guix System, no custom file. <jpoiret>i've got my own .Xcompose extensions though, that may be why <nckx>Also, GTK is a little 💩 and doesn't support all combinations for whatever reason. I can type →, I can't type <- (composed), explain that… <nckx>So if you're using GTK test something else. <jpoiret>in firefox currently, also tried in kitty <maximed>alt-gr + shift + v -> ←, on my keyboard <nckx>I'd be curious if foot ‘work’ for you, if you have the time. <jpoiret>alt-gr is mostly present on latin keyboard <jpoiret>i have an azerty keyboard but with dvorak + alt-gr as compose key for french and other things <bjc>i can type → and ←, but not llap =/ <nckx>I have both: compose:102 and misc:typo for the alt+gr stuff. It's besides the point though. I'm aware of both, but was discussing one. <bjc>this sway + emacs (which is gtk) <nckx>OK, this has quickly become a clusterfest. <bjc>imma guess that xcompose is not as standard as one might thing ;) <nckx>GTK emacs: no poo. foot: poo. <nckx>bjc: Not really, it's just GTK being GTK. <bjc>gtk emacs: no poo, alacritty: poo <bjc>so, yeah, ok, it's gtk <nckx>Apparently it has something to do with GTK using XIM. <nckx>So export GTK_IM_MODULE=xim might fix that? <nckx>I'm not going to ruin my emacs uptime just for that, though. <bjc>your emacs stays up for more than a couple days? <bjc>i've got just the fix. it's called "edit all your files via tramp" <bjc>i'm not complaining. i love tramp. i do this to myself. but it is not conducive to long running sessions <nckx>Haha. Of course M-x emacs-uptime exists. Because of course it does. <nckx>12 days, 20 hours, 41 minutes, 17 seconds. <maximed>ripgrep now builds with antioxidant-build-system <maximed>(needed a fix for an edge case with linking to non-Rust libraries) <nckx>This work is impressive. <bjc>how close is abs to doing everything? <bitspook[m]>nckx: I thought I was the weird one with `8 days, 9 hours, 57 minutes, 45 seconds` <bitspook[m]>(Sorry for dropping in off-topic in your conversation. Please continue) <FlaminWalrus>Can confirm compose llap doesn't work for me with no custom extensions just setxkbmap -option menu:compose <nckx>Dammit. I'll never share anything cool again because fragmentation. <maximed>bjc: if abs=antioxidant-build-system: it doesn't support building non-Rust shared/static libraries yet (e.g. librsvg) <maximed>Lately I haven't had much need to actually modify the antioxidant code itself <maximed>Though there are some incompatibilities with Cargo, e.g. with Cargo, it's possible to link multiple versions of the same thing into the same binary and such <bjc>have you tried things that use cargo workspaces? <bjc>cuz even in cargo, that stuff is a clusterfuck <maximed>I know it exists but I haven't ever actually needed to implement that <nckx>FlaminWalrus: I can only say it's in my /home/nckx/.guix-profile/share/X11/locale/en_US.UTF-8/Compose and I didn't make it up 🤷 But there's more relevant conversation now, so this is it for me. <maximed>For an example for things that need to be done: backports (forward ports?). There are crates depending on rust-nom@3 and other crates depending on rust-nom@7 <jackhill>is there a gexp for outputs other than out? <maximed>whereas the macro system has been removed in rust-nom@7 <bjc>i use workspaces as a way to try and work around being able to test nostd stuff and build firmware images for various devices. it doesn't work very well, but nothing does <jackhill>nckx: thanks. I'm sure that's already documented. Reading is difficult… <nckx>FlaminWalrus: It's LLAP by the way, the shift actually matters (oddly). <maximed>bjc: I suppose antioxidant-build-system could support the nostd and firmware use cases? <bjc>my life has improved dramatically <nckx>jackhill: It's in (guix)G-Expressions under '#$OBJ:OUTPUT' but that's what this channel is for. <bjc>it's a general issue for embedded work. you want to be able to run unit tests, but you have to flag crates as building for a specific arch, so you need a way to segregate them <bjc>but cargo doesn't handle it at all well, either, so there's no pressing need <maximed>cross-compilation is completely untested for antioxidant-build-system <bjc>you should just be able to pass a target triple into rustc. i'm pretty sure that's all cargo does <bjc>it's just that cargo's not very configurable in how it gets that triple <maximed>bjc: Dunno if that's sufficient though, there are a few ‘built-in’ rust crates <bjc>true. for std, at least, you'll need the requisite tarballs from upstream for that arch <bjc>urf. obviously you'll need them for core, too. i dunno what i was just thinking <maximed>Another missing feature in antioxidant-build-system: no tests <FlaminWalrus>nckx: got it now. Also noticed the entire APL symbol catalogue is in there. <maximed>likewise for benchmarks and examples <nckx>FlaminWalrus: ikr? And yet no λ. Nuts. <KarlJoad>How are you guys making QT & GTK apps go dark-themed? ***Rampoina is now known as IHateSpecing
<lilyp>Speaking about GTK, do we have the things ready to push GNOME apps to 42? <lilyp>is there some base stuff like GTK itself that we need to bump?