IRC channel logs
2025-01-10.log
back to list of logs
<ajarara>clone: no worries! I found it had to do with sh/bash differences. Using something like (system* (string-append #$bash "/bin/bash") #$(local-file "my-script")) worked. <fnat>I'm trying to set up a QMK environment in Guix. I've launched a Guix Shell (--container) with a small number of dependencies: qmk, qmk-udev-rules, and simavr. Then I run 'qmk setup' but it complains it can't find arm-none-eabi-gcc. <fnat>I also see there's a 'make-qmk-firmware' Scheme method in firmware.scm. Should I be using that one instead of the QMK CLI? <nathan-web>Okay. I was finally able to fix the issue with `rename-file` preventing reconfigure. Now that it has run successfully, I have a different problem. <nathan-web>sddm won't start. /var/log/messages shows: shepherd[1]: sddm[3355] Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8. and crashes (repeatedly). <nathan-web>I have `(locale "en_US.utf8")` configured, and `locale` shows "LANG=en_US.utf8" shows a list with "ar_DZ.utf8" "C" "en_GB.utf8" "en_US.utf8" .... <Kolev>Do you have Guix garbage collection on a timer? <Kolev>I always worry that I'll run into disk space issues someday. <jakef>Kolev: dired helps to keep an eye on it <gnugnu>hello guix, I popped in to ask you guys a question real fast, as to whether or not we can upgrade the guix system to older generations of guix system software with it's package management <iyzsong>gnugnu: yes, via CLI 'guix system roll-back' or choose an old generation from grub menu when booting <gnugnu>I mean a guix system generation that is not installed locally... <gnugnu>like the guix system packages from... say 2023 <gnugnu>I imagine it might be possible since locally, that's the basic design... everything is transactional, and maintained <iyzsong>yes, via an old version of guix, thourgh 'guix time-machine --commit=SOME-COMMIT-IN-2023 -- system reconfigure ...' <gnugnu>ok thank you I will look into it... <gnugnu>I know arch linux supports it, but I don't know about guix so much <gnugnu>like on arch a single configuration option can let me install packages from any point in time in the past, arbitrarily, like... all packages from february 2022 <gnugnu>I also am researching methods to build a unique system kernel on guix, which in my mind is essential activity for modern linux users everywhere, if anyone has any information on accomplishing that goal that would be very much appreciated <iyzsong>gnugnu: for a custom kernel, you can pass your kernel config as '#:configuration-file' to the 'make-linux-libre*' procedure, and use that package as 'kernel' in the 'operating-system'. <meaty>There are bug reports about it not building from 6 years ago too <gnugnu>yea but the problem is I want to operate on the whole source tree, manually, and basically use guix to install it properly... build an initramfs, register the modules in the filesystem appropriately, all the typical things, so that's the problem, guides online don't explain the situation with the explicit details that actually matter <gnugnu>they sort of end with (...!) good luck <gnugnu>I would even like to manage it outside of guix, which is probably the actual best solution, if I understood how to simply point it's system configuration in the right directions <gnugnu>I dont need a layer of abstraction on top of essential file system operations like cp bzImage <iyzsong>meaty: thank you for the report, i could look into perl-gtk2 later. <gnugnu>cp bzImage and rebuild the initramfs, then im in a new kernel <gnugnu>you need to understand, everybodies computers are wildly different, and people have wildly different experiences <gnugnu>all of the sudden their internet is dead, there's no helpful logs, then their graphical display is broken, and they're reaching for usb's to install a new distro <gnugnu>modern technology, takes place in nanoseconds <gnugnu>the instructions for building the kernel on the guix website end with the disclaimer that they do not actually explain how to accomplish the feat <gnugnu>I think guix is too slow for me... <gnugnu>I have to connect to the internet in order to install the system, upgrading the system requires being connected to the internet for 30 minutes to an hour <gnugnu>anyways thanks for your help... happy gnu <lechner>Hi, how may I find the store patch of a package for the current system, please? <iyzsong>lechner: guix build --dry-run PKG, if 'guix' is the 'current' one. or guix gc --references /run/current-system/profile if the package is in the profile. <lechner>Hi, if I do one 'guix shell' inside another (for example, because master is refusing to build something else) why isn't the profile cumulative? <Rutherther>lechner guix shell cannot know what shell you are in, so it cannot make it cumulative. There is no information about the packages inside <lechner>Rutherther / what about $GUIX_ENVIRONMENT? <Rutherther>lechner: that is just path to built profile. It doesnt have information about the packages that led to it. The information is lost, the exact definitions are not present, like search paths or possible modified profile hooks <Unthahorsten>Hello, I am creating a package and I have to copy the tgz archive from an input to a directory before compiling, how to do that ? I tried to map origin-actual-file-name the origin but it gives only the filename not the full path. <kreijstal>can someone point me out how to build a package in the guix repl? <kreijstal>I want to debug something that happens only on guix <kreijstal>I want to execute each build stage manually and get into a shell to inspect <olndrxyz>Hi, how can I fix the error: "==== AUTHENTICATING FOR org.freedesktop.policykit.exec ==== Authentication is needed to run /gnu/store/.../xf86-video-intel-backlight-helper as the superuser"? <kreijstal>I discovered a bug. `guix shell guile guile-readline guile-colorized -- guix repl` then somehow guix repl crashes and I get stuck in infinite loop `While reading expression: <kreijstal>In procedure fport_read: Eingabe-/Ausgabefehler <kreijstal>basically, if guix repl crashes, then parent guix get stuck in infinite loop (I think) <fnat>decfed: Hey, thanks! Despite the error with 'qmk setup', I see I'm still able to compile the firmware, so that's promising. <divya>Why does my guix only make the truetype fonts available and not the opentype ones? I have font-inconsolata installed in my system profile and doing fc-list does not list it. <jaadu>divya: Have you run "fc-cache -rv"? <divya>Except now I realize I don't like Inconsolata as much as Iosevka. <blu132>Hello, I have gotten one step closer since last time. My goal is to boot guix on some hardware I have. For a successful boot I need to blacklist two kernel modules: amdgpu and radeon. As of now, I am editing the parameter list in grub every time. According to the documentation ("Bootloader-Configuration"), this is possible through configuring my own menu-entry in the bootloader config, in config.scm. <blu132>Last time I got stuck on getting a path to bzImage. I could eventually solve that by adding (gnu packages linux) to my (use-modules ...) at the beginning. Now I have a new problem: With my current menu-entry, guix says upon reconfiguring: "guix system: error: invalid menu-entry: [...] hint: Please chose only one of: 1. direct boot by specifying fields `linux', `linux-arguments' and `linux-modules', 2. <blu132>multiboot by specifying fields `multiboot-kernel', `multiboot-arguments' and `multiboot-modules', [...]" - option one applies, so I truncated the rest. Checking my menu-entry, I am indeed not specifying "linux-modules". However, as soon as I do, with any value at all, I get the following error message: "extraneous field initializers (linux-modules)". Well which one is it now? <blu132>My menu entry looks like this at the moment: (menu-entry (label "GUIX System - no GPU") (device (uuid "some-uuid")) (linux (file-append linux-libre "/bzImage")) (linux-arguments (list "modprobe.blacklist=usbmouse,usbkbd,radeon,amdgpu")) (linux-modules (list ""))) - I am aware that I will likely need some more arguments for an actually functioning boot entry, but I am building up bit by bit so I don't have to <divya>Why don't you provide the modprobe arguments directly to the kernel. You're using linux-libre, right? <divya>blu132: You can just do (kernel-arguments '("modprobe.blacklist=usbmouse,usbkbd,radeon,amdgpu")) inside `operating-system` <blu132>divya: the grub.cfg looks very promising, following this approach, I'll reboot the box and see if it comes back alive <blu132>divya: Thanks a lot, that was exactly what I wanted, and it is working just fine. <divya>blu132: I am glad to be of help. I've been there multiple times with these pesky kernel arguments. <janneke>okay, so rust-team branch merged, i guess that's a good time for tche core-packages-team to rebase and do a world rebuild, ie, drop the "REMOVME -- prevent world rebuild" patches <ferocious_iguana>Hi! I recently started with Guix and really impressed with this beautiful system! So far I'm playing with it in a QEMU/KVM and was wondering if guest additions are available to be able to use host OS mouse cursor and handle window resizes, etc. <ferocious_iguana>Thanks I'm trying it - but how do I import the package? I tried (use-modules (gnu services qemu)) or (use-modules (gnu packages qemu)) but neither work. and without it says qemu-guest-agent-service-type is unbound <lechner>Rutherther / The links in $GUIX_ENVIRONMENT cannot be maintained across a 'guix shell' when that's used without --pure? <Aure84>Hello. I was wondering if it is possible to make use of fetching mechanisms provided by building systems during building phases of packages (for instance the fetch mechanisms from the CMake build system). Thanks! <lechner>Aure84 / i'd be surprised if the build system has network access <ekaitz>hi! how can i call `invoke` in a package that uses `trivial-build-system` i tried with `#:modules` but... no luck <ekaitz>oh i need to use-modules in it... <Aure64>@lechner, thanks for the reply. You are correct, there is no access to network. I was wondering if there's any way to enable this <rekado>Aure64: there is not, but you can fetch these additional files in advance, compute their hashes and then use the result as an input. <Aure64>Thanks rekado. It is not feasible for the project I'm trying to build. A superbiuld over another superbuild :) <Kolev>SUPDUP isn't necessarily nonfree, but the licensing is ambiguous due to historical resaons. <wakyct>hi Guix, newbie question while I'm writing my first package, the software uses its own license, I tried using the license record constructor from (guix licenses) in my package definition but I guess that's not exported, can I create my own license record in the pkg def like that? <wakyct>I'm just writing it as a local file, haven't checked out Guix <rekado>Kolev: does you channel actually have authorizations? You specify an introduction commit. <Kolev>rekado, it's been ages since I've used my channel. I don't remember. <rekado>since this is the error it's worth trying to figure this out. <Kolev>rekado, it has a branch with my public key. <Kolev>rekado, what is an 'authorization'? <rekado>Kolev: see for example .guix-authorizations in the Guix repository. <janneke>ACTION pushes a freshly rebased core-packages-team "untested", the old one is saved as core-packages-team-old for a bit <janneke>i haven't tested the world rebuild locally this time so it's up to the build farm -- finger crossed <Kolev>Using latest commit ID fixed it. <divya>efraim: Looks like the latest rust-team merge has produced some issues? <ekaitz>can I redirect the output of `invoke` to a file? <kreijstal>ekaitz good question, I was wondering if there was a way to overwrite invoke to have a silent mode, aka print what it thinks it should do but not do it. <ekaitz>i think open-pipe* is the way to go but it's a little bit complex <kreijstal>I wonder if there is a way to overwrite invoke in such a way all dependencies use that invoke... without editing guix source code, like reflection idk <yarl>ekaitz: is that what you want? : (with-output-to-file "/tmp/foo.txt" (lambda () (invoke "echo" "bar"))) <yarl>Or am I lacking context? <ekaitz>yarl: i wasn't sure about the output of invoke, if it was tied to the current-input-port and current-output-port <jmes>I am writing a guile program that must receive messages from Shepherd. What's the most convenient way to connect these 2 separate guile programs? <jmes>On that note, the guile program is like a web server (but with no network needs) in that it needs to have a listen loop and handlers for the messages received. Is there any obvious choice of module for this sort of thing? <PotentialUser-93>Hello. I have just ran "guix system reconfigure", and in the output that was scrolling I saw it was downloading autotrace, inkscape, imagemagick, libcdr... Could someone please suggest why? In addition, it downloads so many packages for texlive! Is it building documentation? Finally, it also downloads mutter when I run i3. Is it some sort of <lilyp>texlive has inkscape as a transitive input <PotentialUser-93>Thank you. Is there a simple way to find that information through recursion? So that I could figure out that out by myself next time. <wakyct>what could be the cause of "builder for `/gnu/store/47ri5ix1hw9zafdcb7lsgl1inf95lgiq-my-frobtads-2.0.drv' failed to produce output path `/gnu/store/wsx1cp68pq4xjnmqbnb9ljhzmvzx3b23-my-frobtads-2.0'"? <wakyct>this is at the end of successful build phases <kreijstal>PotentialUser-93 there is a way to get a bag from a package, from there you can get all its dependencies <ngz>wakyct: Maybe the package doesn’t copy anything to $output <wakyct>oh I did delete the 'install phase because I thought it shouldn't be copying binaries and so on to the store -- that this was "guix package install"'s job, is that wrong? <ngz>wakyct: Probably. Either something is copied to the store, or an empty directory is created (e.g. for a meta-package) <wakyct>thanks, is there an example somewhere of what people do when upstream assumes 'make install' is going to happen? Modify the install phase somehow or do something else? <wakyct>or if I'm supposed to let make install run, how then does that interact with guix package install? <ngz>wakyct: If you don’t want to "make install", you can replace the install phase with your own, which will copy to the store only the files you’re interested in. <wakyct>I guess I'm confused why it's an issue since it doesn't seem like it should be assumed that make install will run <wakyct>I'm afraid the trouble is I don't know what files I'm interested in ;). I thought the build process was just to compile and test. Then guix package install puts the files in the store. <ngz>wakyct: Unless told otherwise, the gnu-build-system does the configure ; make ; make install dance. <wakyct>thanks ngz, I'll try to read up on this, I'm missing some fundamentals it seems <ngz>wakyct: guix package install merely creates a symlink in your profile. It is unrelated to building the package <ngz>wakyct: OK. The Guix manual is good. Do not hesitate to ask questions on this chan if something is not clear. <lfam>PotentialUser-93: There are tools to inspect the dependency graph of packages. Mainly, `guix graph` <lfam>You can do basic things like `guix graph texlive | grep inkscape`, which actually doesn't show a dependency connection, but there are different levels of dependencies that can be inspected with `guix graph`, and I only used the most basic level <lfam>There's also a handy tool `guix graph --path`, which can print a dependency chain in human-readable format <lfam>For example, `guix graph --path libreoffice npth` <lfam>Basically, the sky is limit with dependencies in Guix, except for Rust packages, where the limit is about ankle-high <lfam>There's also a variety of tooling for manipulating the dependency graphs of packages. Lok at Package Transformation Options in the Guix manual <lfam>It's funny and sad, isn't it ieure? <wakyct>I think I solved my issue just by keeping the install phase and then installing after the build was successful, thanks again ngz for explaining <PotentialUser-93>lfam That seems to be useful. My wish would be that `guix graph` would provide also a more text-oriented backend. Or some output that would allow us to build more tools to explore the graphs. Though I suppose one who knows how, can build some Guile script to extract that information with ease. <lfam>PotentialUser-93: All the information is there in Guile. It's just a matter of using it <lfam>For simple things, there actually is a hybrid machine and human-readable interface <lfam>`guix package --search=.` will dump the entire list of packages in the "recutils" format <lfam>Save that to a text file as a cache, and then you can use the recutils to inspect it <ieure>wakyct, Don't think so, since it's a third-party thing, not an official Guix thing. <lfam>Something like this: `cat ~/tmp/local-package-dump | recsel -e 'dependencies ~ "ki18n"' -p name,synopsis,location` <lfam>I use this a lot when doing package graph maintenance work, like working to remove packages that are depended on by a lot of things <lfam>It's not super flexible but it is nice and easy <lfam>There's also `guix graph --type=reverse-package`, which is super handy <ferocious_iguana>I'm trying to build a package (kitty terminal) from a local checkout of guix repository. I followed the instructions on contributing and got to executing `./pre-inst-env guix build kitty`, but this did nothing and just printed the location in the store where kitty package is installed. What can I be missing? <Rutherther>ferocious_iguana: so it gave you kitty you asked for, what's the issue? <ferocious_iguana>I probably didn't explain myself well, I want to setup a development environment for contributing to package repositories. I'm not interested in the kitty I installed in the host, I want to build it from the local clone of the package repository <Guest6134>Is there a standard way to use the guix package manager to hold arbitrary config files within its system? I'm trying to configure usbguard, which needs a couple config files to tell it which USB devices to allow or deny (it is like a firewall but for USB devices), and it is packaged in guix. Do I just make the config files for it like normal or is there a special way to do it so it is integrated into the <Rutherther>ferocious_iguana: but that's what it does, of course when you already have the path present it will use it, it won't rebuild <ferocious_iguana>I see. Is there a way to hack on the package without having to uninstall it from the system - because I'm simultaneously using one :) <Rutherther>Guest6134: with the package manager, not possible, but with guix system it is, with services. You can make a service that will make a file <Rutherther>ferocious_iguana: I don't understand what you mean. If your kitty package definition produced other store path, it would get buiilt. But it doesn't, it evaluates to the same derivation you arelady have <ferocious_iguana>ahhhh, unless I actually make a change - it won't rebuild it, because it matched it to the version in the store <evan>I'm pretty sure what "guix build {package}" is build your package, then it will give back where the result was placed in the store. It doesn't actually change the user's profile (a bunch of symlinks to files in the store) such that the user's "kitty" command will run the new kitty binary that you just build. So it doesn't actually *install* kitty, it just simulates what would happen if it did install it. <evan>the new files are still in the store, but running "kitty" won't execute those files. <ferocious_iguana>evan: thanks for clarifying - indeed, I don't want the build to be installed in my user profile. What confused me is that it simulated what would happen. <Rutherther>it doesn't simulate anything, it just makes sure the path produced by the package exists, ie. by building, substituting or just nothing if it's already there <meaty>What if we adapted the "import" functions into something that would generate/cache package definitions on the fly, that way the majority of packages that don't need manual packaging can be ignored <meaty>e.g. elpa, maybe crates is like this <kreijstal>has anyone ever wrote a custom build system to debug guix packages? <lfam>meaty: I think it's a good idea for languages like Go or Rust, where the majority of "programs" are tiny, not worth the effort to package, and are depended upon at extremely specific versions <lilyp>I mean, that would lose some of the declarative nature of Guix, though. You'd be depending on a state that can be changed, an unreliable one at that. <lilyp>It would let things "just work™" at the moment with no guarantees for future dates. <lfam>lilyp: At least for Go, dependencies are specified by each program. So, if you package foo-1.0, every dependency of this program is specified by the Git commit, transitively <lfam>It's basically the same as Guix <lfam>They even implement a memoized build cache within Go <lfam>Of course, we wouldn't use that cache, but I share this info to highlight the similarity to our own values <lfam>Not sure if Rust works the same way, but already we don't do Rust in a Guix-y way <lfam>I know it sounds icky but I think that, when you look closely, it does conform to our values <lilyp>I do wish we put our hands up in the air less than more, but fair enough for Go, I guess <lfam>I don't think we give up very often, but we each have our own measures :) <Rutherther>lfam: what do you mean by 'already we don't do Rust in a Guix-y way'? <lfam>If we were to always package Go software in the same way that we do for e.g. C, we'd end up with hundreds or even thousands of package definitions of certain Go libraries. I don't see the value in that <lfam>Rutherther: In Rust-world, cyclic dependencies are common, and dependency graphs are extremely large. Sometimes we make the effort to break cyclic dependencies in other languages, but for the scale of Rust, it wasn't feasible given our resources. So, there is no package graph for Rust packages in Guix <lfam>We invented a different way to specify dependencies that loses all the advantages of Guix <lfam>To clarify, Guix can't express dependency cycles <lfam>That's why Rust packages use #:cargo-inputs instead of the normal manner of specifying dependencies <Rutherther>I don't see how cyclic dependencies are possible, ever. You just need to have a way to break the cycle, otherwise it's impossible to build it <lfam>You'd have to read the source of the cargo-build-system to see how they did it <lfam>But, you basically just don't write code that follows a graph. Boom, done <lfam>I think that efraim would know how it works <lfam>Once you have Guix brain, it's impossible to understand ;) <lilyp>I think we should bundle up a bunch of Rust sources in one package and declare it done. <lfam>So, all the dependencies of a package rust-foo would be in a big tarbal? <lilyp>Most of the stuff like serde just gets "reused" over and over anyway with no real value added to the world <lilyp>well, not necessarily, but packages that form cycles would just be built as one <lfam>The tricky thing is you have to get the right version. Different packages depend on different versions <lilyp>yeah, we'd have to reduce the over-specificity drastically <lfam>I think that's something we shouldn't do, as a distributor. It basically guarantees that we introduce bugs. <lfam>It's a shame that these languages are so specific, but it's how they are <lfam>Already we have to compete against "use the language's package manager", and we are losing. We don't want to offer a worse solution <homo>in case of rust, isn't cargo happy about removing dependencies' versions from toml file and using whatever is available in the container? <Rutherther>lfam: also what guix advantages does the cargo build system lose? <lfam>Rutherther: You can't inspect the dependency graph, use any package transformation tools, etc. There effectively is no graph <lfam>homo: Dunno, but we shouldn't disregard software authors decisions about what versions to use unless we have a good reason <homo>the good reason is to let distros do their job about versioning dependencies <Rutherther>I don't think that is the case, it's just that the tools that you typically use for that just don't support it. You can still map over it and change cargo-inputs, you can still collect cargo-inputs recursively and build up a graph <homo>authors often have annoying practice of bundling libraries, as they don't trust distros to do their job, and cargo doesn't trust distros either... <lfam>homo: I agree that's something that a distribution could do. But, the problem is that it's more work than Guix contributors seem to be willing to do for Rust <lfam>And not just a little bit more, but a lot more <sarg>hey guix, I wonder why each config serializer has to be written from scratch? There are just so few config formats - json / yaml / ini, etc. Wouldn't it be better to have generic code for such? <lfam>From what I've seen, the Guix project can choose between "don't include Rust software" or "do it in a way that's kind of suboptimal" <lfam>I haven't seen "do it in the ideal Guix way" appear as an option yet <homo>it is very chaotic how every new language ecosystem has its own package manager (cabal, cargo, npm, pip, stack, etc.) that replaces guix, apt, pacman, etc. and cannot manage packages of other languages... <lfam>It makes sense when you "zoom out" and look at the situation more broadly. People use a lot of different operating systems and this way the experience is the same (or similar) on every type of system <lfam>Thankfully the most popular and important languages have tooling that we can orchestrate from within Guix, like pip for Python <homo>don't apple, google and microsoft have their own package managers for their own systems? <lfam>Google has something that's basically the same idea as Nix / Guix. It's called blaze / bazel and it's a memoized cache <lfam>I don't know what the other companies do <lfam>The method of modeling the build of software as a function with a memoized cache seems to have won <janneke>i installed gdm+gnome for another user, when they login after about a minute gnome-session says: "Oh no! Something has gone wrong." <janneke>/var/log/messages has: WARNING: App 'org.gnome.SettingsDaemon.UsbProtection.desktop' respawning too quickly <homo>I heard in case of apple you must pay 100$ per year to distribute your software, not like you can bypass that by introducing your own package manager <janneke>could that be it, any idea on how to resolve it? <lfam>janneke: Not sure. I found that the GNOME world prints a huge number of warnings on the console. I can never tell if they matter or not <janneke>the user's profile is from today, the system is 6weeks old, reconfiguring now "just in case" <janneke>lfam: great -- well this "Oh no! ..." message pops up as a full-screen message box with one button: log out <homo>that 100$ is for cryptographic key without which macos and ios will refuse to run your software <janneke>it seems you can safely ignore it, but yeah <lfam>That's more or less correct homo <lfam>A bit hard to ignore janneke <lfam>Hopefully you can correlate the console messages with the popup by timestamp <homo>on windows there are chocolatey, microsoft store, msys and winget package managers, don't expect any of those to be free though <homo>msys uses pacman for package management <homo>which leaves only kolibrios, inferno and plan9 as systems without package managers <Guest6134>Is there a way to prevent multiple guix commands trying to download something from blocking one another? My internet should be fast enough to handle more than one download at once. For example, I'm doing a reconfigure and a guix install at the same time, but I dont want the reconfigure to pause downloading while the install does its thing. <lfam>Guest6134: Sometimes you can bypass this by increasing the number of concurrent jobs with --max-jobs=N <lfam>But sometimes it's unavoidable <lfam>You can pass this options to many Guix commands and also to the guix-daemon <Guest6134>lfam: Okay, how can I just have that increased on startup for guix system daemon? <podiki>we need an option like that just for downloads (has been discussed) <podiki>as sometimes you don't want multiple build jobs, e.g. memory runs out if one of those jobs is demanding <lfam>It's something I've wanted for a long time <lfam>It got a lot better in recent years. Previously it could take significant time to start up and finish the download job, so that a 10 kilobyte file might take 5 seconds to "download" <lfam>At least now the overhead is very small <janneke>lfam: timing the message was a good idea, it seems to be: so it's .gsd-usb-protect[<pid>]: segfault ... <lfam>Hm, segfault is never good <janneke>interestingly, reconfiguring with gnome after a recent pull makes me build: gmime-3.2.14.drv totem-pl-parser-3.26.6.drv grilo-0.3.16.drv gnome-control-center-44.4.drv gdm-44.1.drv gnome-shell-44.10.drv -- hmm? <lfam>Fingers crossed it solves the problem <civodul>janneke: looks like the aftermath of the rust-team merge? <lfam>Glad to hear it Guest6134! <Guest6134>By the way, do many people use plasma with it? Im trying to get it going just all the dependancies are slow, but just noticed it doesn't have a service like the other desktop environments, is the support alright? <janneke>civodul: fwiw, it all seems to build, indeed <lfam>Looks like (gnu services web) is broken <civodul>janneke: yes, it looks like there was a non-deterministic test failure in gmime <lfam>From the kernel-updates branch, which is based on recent master f15ca836e4686496f675308655c370c95e9f52b7 <lfam>This is with time-machine <lfam>` guix time-machine --branch=kernel-updates --disable-authentication -- system reconfigure --allow-downgrades /etc/scratchpad-system/configuration.scm --cores=12 -v 3` <lfam>I'm trying `guix pull` now <civodul>that sounds like a scary compiler/gc issue <janneke>can someone remind me: on a new machine, guix offload test succeeds, but guix build doesn't (choose to) offload <civodul>some derivations are marked as non-offloadable (typically small things like compiled-modules.drv) <janneke>yeah, it's things like gnome-shell :) <janneke>yeah, i believe i might have seen something like this yeeeeaaars ago -- weird <lfam>`guix pull` from `master` did succeed <lfam>Maybe my error was transient, as you suggested civodul. I re-ran the original time-machine command and it's building the kernel now, so that's good <janneke>seems like reconfiguring isn't such a bad idea <civodul>janneke: isn’t it a ‘guix’ that was built without offloading support? <civodul>remember, there was a bug following the Guile-SSH upgrade that caused that <janneke>yes, i'm reconfiguring but it was a guix from early december <janneke>yeah, kinda funny though and quite a relief; this must be it <janneke>ACTION chose a bad moment to install a new (backup) machine <janneke>maybe someone should write an rfc on most-recent-good-weather-commits to pull from, or something <lfam>Call them a "release" or something <janneke>ACTION also still hopes that the guix daemon in guile rewrite opens up the possibility to have hashes moved to the end of store file names <janneke>/gnu/store/zmdgrgyavnbp18ssv8p1cajifjff6dhr-bash-minimal-5.1.16 => /gnu/store/bash-minimal-5.1.16-zmdgrgyavnbp18ssv8p1cajifjff6dhr <janneke>gsdlb: what is "this" exactly? Running guile 1344782.scm (with guile-3.0.9 says: <janneke>;;; WARNING: compilation of /home/janneke/src/guix/master/bug.scm failed: <janneke>;;; In procedure =: Wrong type argument in position 1: #<unspecified> <gsdlb>Did you run this in Guile 3.10? janneke <janneke>yeah, i have no guile-3.0.10 available afaik <janneke>guile-next is (still) at 3.0.9-3b76a30e3c