<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.
<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.
<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
<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?
<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!
<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.
<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
<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"
<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
<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?
<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>>) ())
<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:
<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
<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
<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
<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
<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
<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>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.
<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
<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
<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
<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
<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.
<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