<lfam>This will help us understand exactly which code you are running
<nisha>lfam not familiar with debian's pastebin, but I did send it :)
<lfam>I'm not sure I see it yet... where did you send it? :)
<lfam>Okay, and zooming out... I'm not coming up with ideas about what could be wrong, that would cause you to be logged out or to crash SSH or something while installing a Guix package
<lfam>Installing a Guix package involves downloading some files to /gnu/store, maybe doing some compilation in /tmp, updating a database in /var/guix, and then making some symlinks in your user's home directory
<lfam>I'm also not familiar with Vagrant boxes. It's like a virtual machine?
<lfam>Or just a way to specify a system that will be virtualized?
<gnucode>I'm wanting to try to run guix from a console for a while...Essentially I would just start emacs after I login.
<gnucode>But I think I would be tempted to give up this experiment after a few days...Is there someway that I could give a friend my "sudo" password and force myself to only use the console for a while? ie: make it impossible for me on "Guix System" to run X or wayland?
<patched[m]>Is it possible to build using source from a local git repository? guix build doesn't seem to find a git repo when I give url "file:///path/to/my/repo"
<lfam>nckx: Do you know how offloading is configured on berlin? It seems that when I build an aarch64 derivation there, it is always handled by the overdrive, but I'd like to make it use one of the honeycombs
<nckx>In a complete changing of the mind, I'm going to start up building on grunewald, because I can't find anything wrong with it. Maybe it still has heat issues so I'm going to limit the number of parallel builds to 2.
<drakonis>gotta make my gpu last until i can upgrade it
<drakonis>if it does work, it'll simplify maintenance
<lfam>It cropped up after updating my installation
<nckx>(cuirass-remote-worker-configuration (workers 4) …) ; on grunewald. As you might have noticed, there were only ever 3 workers listed at https://ci.guix.gnu.org/workers, not 4. Now I've shut down the remote-worker service on grunewald and 2 of those have vanished, as expected, but one does not.
<nckx>It's dangerous to assume bugs when you have no idea how things work, but I wonder if that could be a bug 😛
<nckx>lfam: I can only say that I'm using gpg-agent without problems on an up-to-date system.
<podiki[m]>thread '<unnamed>' panicked at 'Type RsvgHandle has already been registered', /tmp/guix-build-librsvg-2.50.7.drv-0/librsvg-2.50.7/guix-vendor/rust-glib-0.9.3.tar.gz/src/subclass/types.rs:485:13
<cehteh>sometimes setting laptop_mode to some higher value helps to batch writes better, also the disk schedulers have some knobs to tune, make longer queues, longer timeouts to allow the scheduler to coalesque jobs better
<ns12>"guix install: error: corrupt input while restoring archive from socket"
<cehteh>nckx: dunno how XFS is now .. but when i tried it 15+ years ago it was pretty poor on massive metadata operations
<nckx>Yeah, I don't actually have any experience with it, it just seems like a meme.
<ns12>What should I do to install packages in the meantime? Build everything from source?
<ns12>I'm just asking in general. Whether or not there is a formal mechanism to notify the maintainers, just in case they forgot about updating packages or somehow didn't know about the existence of new versions.
<nckx>And the other half of the perfect storm is that today a branch was merged that makes all of bordeaux historical substitutes ‘obsolete’ for current master. If this had happened yesterday, it would have been comparatively less bad.
<nckx>It was acting weird, but I can really not say if it was weirder than usual.
<nckx>Services failing, that sort of thing. Unfortunately not that unusual.
<cehteh>rekado_: seen my mail i wanted to ask you if perhaps (small chance) the filesytem was not mounted with relatime (and possibly nodiratime) which may or may not be part of the slow delete process
<nckx>I'm just glad rekado_ is OK and Germany is still there.
<nckx>jlicht: Somebody celebrated by stealing our discs, but they put them back.
<rekado_>but the ‘Lifecycle Controller’ is now in recovery mode and it tells me to ‘Repair Lifecycle Controller firmware using the Lifecycle Controller Dell UpdatePackage (DUP) or Lifecycle Controller Repair Package via iDRAC. For moreinformation, see Lifecycle Controller User's Guide.’
<nckx>(No: it's apparently a firmware blob uploader for GNOME. Unlikely future Guix material.)
<jonsger>jop. Dell and Lenovo are doing that for Laptops/PCs quite broad, but not for servers. As they wanna sell bs firmware upgrade software...
<nckx>‘In December 2015, it was revealed that Hughes had been working with a Dell developer to test the system on actual hardware, and that its Dell Edge Gateway product will support firmware servicing via fwupd.’
<jlicht>nckx: it's a service to get the right proprietary bits to your usrs even faster
<jlicht>jonsger: cool! Perhaps the FSDG-projects can have a look some day when there is a reasonable amount of firmware on there for a libre spin of fwupd
<attila_lendvai>rekado_, a hypothesis: maybe the firmware got upgraded, the config got migrated/adjusted to the new version, no reboot, and then something happened that caused the old version to change/overwrite the config... that would be stupid, but i've seen worse.
<cehteh>there are a lot reasons speaking for linux software raid (and few against)
<nckx>I don't understand what the problem is, you'll have to share more than ‘x doesn't work’.
<nckx>Otherwise, it seems like something's wrong with your installation, and what is anybody's guess.
<zimoun`>nckx, the time-machine tries to build many derivations. Then fails. For instance cannot build derivation `/gnu/store/pw35ppk895rdzwykb5zhr20m5kkp0qrq-datefudge_1.23.tar.xz.drv': 1 dependencies couldn't be built
<zimoun`>I am asking why ‘guix pull’ does not work when Berlin is down when we are running Bordeaux.
<rekado_>for the record I changed two things: enabled disk fallback, so that more disks are retried when one cannot be booted from (shouldn’t have any effect because there’s just one virtual disk, RAID0, two SSDs, and one HDD as a spare)
<nckx>So I still don't understand how bordeaux is supposed to make your command work.
***Dio is now known as CarDio
<zimoun`>nckx: that’s my point! We are running 2 build farms. I am not asking that the 2 build farms serve all the substitutes, I am asking why when Berlin is down, ‘guix pull’ becomes broken despite Bordeaux is up.
<nckx>Seven-ALB[m] proposed possibly hosting another mirror.
<nckx>I also noticed that the Chinese one doesn't actually function in the absence of berlin. Or at least not for me. That might've been for whatever other reason (GFW?) but it's something that I'll investigate further, because I was kind of counting on it as a fallback.
<civodul>re the Chinese mirror, does it actually use rsync?
<nckx>work well for Guix because Guix client does not handle HTTP 302 redirection correctly. So we tweaked the program a little bit to offer transparent proxy to Guix client. The program is here: https://github.com/sjtug/mirror-intel‘
<CarDio>Hello, here i can find an answer about packages like haskell's gi-gtk?
<florhizome[m]>I just pulled -- which checkout? i get a few error messages like this and some package names are not found anymore. guix build: Warnung: „(gnu packages my-fonts)“ konnte nicht geladen werden:
<florhizome[m]>In procedure abi-check: #<record-type <origin>>: record ABI mismatch; recompilation needed
<nckx>(gnu packages my-fonts) is not a Guix module 😉
<mbakke>is there a way to force evaluation of inherited package arguments with new variables? i.e. if a package uses the 'version' variable in its builder, it won't change even if the inherited package uses a different version
<EdwardIII>hey, if you want to install guix system on qemu on an ARM guest, what are the options? build it on the host first? interested in playing with it but on mac m1
<EdwardIII>i see you can get guix actual for multiple platforms, but not guix system
<ngz>There is also a strange indentation artifact at line 79
<sailorCat>Hi, I'm looking for a two features. First, there is a package — show all executable files it provides. Actually I can find a dir in the /gnu/storage, then inspect /gnu/storage/hash-package-version/bin, but perhaps there is a more straitforward option. Second, find a package that provides a given command. For instance I expected to find hcitool in the bluez package, but it's not here. What else, except install all
<sailorCat>bluetooth-related packages and check them, I can do to find it?
<civodul>i wrote the first half ~10 days ago and the second half today; maybe that shows...
<ngz>civodul: Actually, the document doesn't answer my earlier question: should we also turn #:make-flags (list (string-append "PREFIX=" %output)) into #:make-flags #~(list (string-append "PREFIX=" #$output)), or is that overdoing it?
<nisha>Hello! just reaching out with my findings about the VM crash: I tried the script and it worked. However, when I run the install steps manually it does crash. I upped my ram and CPU cores on the VM and the manual install steps continued for a little longer and then crashed.
<jpoiret>so, with the new style being significantly terser, should we still try to keep to the one input per line rule, to facilitate merges?
<notmaximed>civodul: Wasn't there a bug report about this-package-input not interacting well with package inheritance?
<notmaximed>Unless that has been fixed since then, it would seem that the blog post is somewhat inaccurate.
<mbakke>civodul: I suppose the manual link should be for the "devel" manual until the next release
<mbakke>eh, derp, the relevant link goes to devel indeed
<civodul>notmaximed: hmm i don't remember seeing such a bug report; do you have a link?
<civodul>this-package-input refers to this-package, so we should be all fine, no?
<apteryx>rekado_: Hi! Thank you for getting berlin up and running again! I'll cherry pick the 3 commits you pushed to core-updates-frozen to master, then delete the core-updates-frozen branch. Is this OK?
<notmaximed>The problem was that 'this-package' is the original package definition, not the new package definition that inherits from the old .
<ngz>mbakke: It makes sense, but ouch nonetheless.
<samplet>It looks like emacs-libgit fails to build on master. Is it just me? It seems it can’t find the “emacs” input. Could be a problem with the simplified inputs.
<tex_milan>Seeing all the troubles, it looks like ability to seed build packages automtically is needed. Do you remember bittorrent? :)
<sozuba>jpoiret thanks for responding again, as much as I am aware, I am not running qemu through virt-manager. But incase I am wrong, could you please let em know how to know if i am using virt manager?.
<samplet>It fails to build in the ‘make-autoloads’ phase, when ‘(assoc-ref inputs "emacs")’ returns ‘#f’.
<sozuba>jpoiret, I tried yesterday as per the docs on manually enabling network, interfaces seems to be up and i try to enable dhcpcd as well. Then gave up. I will try again now
<jpoiret>sozuba: as long as you are running the qemu command line, you are not using virt manager
<jpoiret>what happens when you `dhcpcd` on the interface? does `ip addr` report an IP address afterwards
<sozuba>jpoiret, thank you :). Although I feel this is probably a bug and should be corrected, so as to be helpful to people. after connecting, going through the guided installer cases the same issue. So I am going to go ahead with the manual installation for now, but will submit a bug report.
<jpoiret>sozuba: for sure, I will open a bug on the installer, hopefully we can add this feature for 1.4
<jpoiret>it should just be a matter of checking for and optional set dns servers manually
<ngz>(search-input-file inputs "/bin/emacs") raises the following error: In procedure string-append: Wrong type (expecting string): #f
<apteryx>works here (I built emacs-libgit with the change)
<dissent>jpoiret: i'm sorry, that wasn't correct. the packages that give me trouble are network-manager-applet deluge gtk+ webkitgtk gnome-keyring libnotify poppler libsoup libappindicator zathura telegram-desktop libx11 xorg-server.
<apteryx>civodul: when you have a chance, could you save your work and retry: "35560 normal Ludovic Courtès GNOME Shell 3.28 crashes and suspends to RAM (!) after ejecting removable media". That's a ridiculous one.
<apteryx>the sanity-check.py script got called like: "python" "/gnu/store/nwwr89v2vyg1hs48i49m083vhczsgh3m-sanity-check.py" "/gnu/store/0irzla32qarhqja1zsbyjhan8qbm6h9w-bpytop-1.0.67/lib/python3.9/site-packages" failed with status 2
<NicholasvonKlitz>Is there any quick way to spin up an ad-hoc impure build system, say `cargo-build-system`, where all programs necessary to hack in that environment are there, but instead of dependencies coming from guix, they are pulled in from the language's native package manager, say `cargo` and crates.io?
<NicholasvonKlitz>jpoiret: It might be a cargo-guix specific bug, but when I try to build outside of a cargo-build-system and a crate depends on gcc, I always just get `error: linker `cc` not found` even when gcc-toolchain is install, which leads me to believe environment variables are not set properly
<NicholasvonKlitz>nckx: that solves it. I think it could be a productivity boost if there could be a pure profile that includes rust, cargo, pkg-config, openssl, etc. by default with environment variables properly set
<lfam>zimoun: I know that Debian has kernel building scripts built in to the kernel source code. Like, you can do `make bindeb-pkg`, and install what it creates. Maybe there is something similar for RPM?
<lfam>I sometimes take the Guix kernel config and build Debian kernels with it. I have to adjust MODPROBE_PATH and change the compression algorithm used by switching from MODULE_COMPRESS_GZIP to MODULE_COMPRESS_XZ
<luis-felipe>Hi, anyone else getting this errors when recofiguring the system?
<sneek>Welcome back luis-felipe, you have 1 message!
<sneek>luis-felipe, nckx says: Thank you for making it.
<luis-felipe>guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet.
<luis-felipe>substitution of /gnu/store/13wxi7vjnvyk9xzqav3pls3vignqz2k1-rust-1.54.0 failed
<luis-felipe>guix system: error: corrupt input while restoring archive from #<closed: file 7ff7915452a0>
<lfam>luis-felipe: Hm... does the error happen again if you run the command again?
<lfam>"The distinction between native-inputs and inputs is necessary when considering cross-compilation. When cross-compiling, dependencies listed in inputs are built for the target architecture; conversely, dependencies listed in native-inputs are built for the architecture of the build machine.
<lfam>native-inputs is typically used to list tools needed at build time, but not at run time, such as Autoconf, Automake, pkg-config, Gettext, or Bison."
<lfam>I don't know anything about wayland so I don't know if it's right or wrong
<florhizome[m]>wayland-protos definitely has functionality that is especially used at buildtime like wayland scanner and
<lfam>Note that the distinction only matters for cross-compilation
<unmatched-paren>the .desktop files of the x session and the wayland session look _exactly_ the same
<nckx>I got that when [I deduced that] my guile-gcrypt was older than my guix.
<nckx>Upgrading everything made it work, at least.
<acrow>Well, no luck so far. I've started a new shell under a tmux session and also logged into another terminal session but each returned the same error. I guess I'll need to duck out to allow a complete system restart. Just a few minutes.
<florhizome[m]><jpoiret> "florhizome: what exactly is..." <- sddm is just not starting (i’m left on the ttyand just login from there...) and enlightenment as well. Can send you logs.
<jpoiret>i looked up how to use hardware accel under qemu, but it looked annoying and I could just start sway with a flag anyways
<ison>Does anyone have pipewire working? It seems the latest version is missing the "pipewire-media-session" binary. It existed prior to this update and was working. I thought it was required unless you have an alternative like WirePlumber, but there is no wireplumber for guix yet as far as I know.
<jpoiret>ison: I am literally writing the patch cover letter for such a patchset
<jpoiret>includes pipewire update to 0.3.41 and wireplumber
<phodina[m]>I'm trying to add Rust package to rust-apps.scm. But the package requires gcc-toolchain as an native-input.
<phodina[m]>Adding commencement module to satify the import causes strange guile errors with unbound variables.
<phodina[m]>I've tried to add just the use-module statement and I still get the errors. Is it possible there is some sort of circular dependency created?
<the_tubular>Is this known : /builder for `/gnu/store/dvzk7gwy7syz8y80pb8xf36lb45plf12-guix-package-cache.drv' failed to produce output path `/gnu/store/v5yajfs2y28wl3np4v4y6pr9lwgyadd9-guix-package-cache'
<the_tubular>build of /gnu/store/dvzk7gwy7syz8y80pb8xf36lb45plf12-guix-package-cache.drv failed ?
<jpoiret>the_tubular: are you using other channels?
<nckx>Doesn't that (above) mean that modify-phases itself is undefined?
<Brandong[m]><podiki[m]> "Brandong: yeah, that looks..." <- As in a package in my profile? I only have the official channel enabled. Is there a smart way for me to figure out what package causes the problem?
<jpoiret>the recent emacs-xyz.scm commit seems to have broken it
<jpoiret>i'm running make in a local checkout and it's giving me warnings
<jpoiret>hmmmm, the arguments field of emacs-shroud is borked
<jpoiret>only uses (list ) instead of quoting the whole contents
<nckx>That would explain Brandong[m] error nicely.
<nckx>Since mod-pha isn't defined on the host side.
<jpoiret>looks like `guix style` just trampled all over it
<jpoiret>uhm, 88097dfba765bacb809edae7639fc3ed2dead297 as a whole looks borked
<jpoiret>it transformed all (arguments `(#:things ...)) into (arguments (list ...))