<RavenJoad>unmatched-paren: Congrats on the new Dissecting Guix! I had a question about another topic for that series (if there is one). What is a bag? It is referenced in the manual, and I think I understand it. But I think it would be nice to have a Dissecting Guix post about it. From the manual, it looks like that would be a shorter entry.
<podiki[m]>apteryx: thanks! we should be getting closer yet to getting core-updates done
<PurpleSym>apteryx: Maybe updating trio to 0.21 helps? It’s still supported by python-anyio, as it does not contain the (apparently) breaking changes of 0.22.
<PurpleSym>(I assume alot of other applications using trio would fail with 0.22 too.)
<ytc>Hello. How can I connect to a Guix REPL from a remote machine via `geiser-connect' in Emacs?
<ChocolettePalett>Btw, I'm going to install GNU Guix rn, tomorrow I have very important stuff to do though, so I hope nothing goes wrong (-:
<sammm>if I wanted to run an arbitrary binary (i.e not from package) as part of a shepherd service, and run it in boot, would the "best" way be to wrap it in a package using the copy-build-system or something similar before defining a shepherd-service?
<civodul>sammm: hi! yes, having it in a package would greatly simplify things
<civodul>ACTION hits "[GSSH ERROR] Parent session is not connected" in 'guix deploy'
<civodul>apteryx: is it what you were experiencing too?
<cbaines>the last big rebuild was 8 hours ago, so I think the window is now
<mekeor[m]>how long does it take for you to run "C-c . u" in guix-devel-mode? should i build guix locally so that intermediary compilation files speed it up?
<andreas-e>civodul, cbaines: Concerning issue #62712, I do not mind a rebuild on core-updates as long as it is safe; or immediately reverted in case it turns out not to be safe.
<andreas-e>I think for x86 and powerpc we can afford a rebuild. For aarch64, I wonder if we will not be forced to merge blindly anyway.
<rekado>efraim: about the certs: I was waiting for confirmation by nckx, but we could just switch over to the new cert infra I set up.
<andreas-e>It has caught up on master, but there are 2400 builds waiting in the rust-team pipeline. I do not know how the cuirass priority works: I told it to treat core-updates with higher priority than rust-team, but nevertheless there are rust-team packages being built on aarch64, while I do not think that the core-updates queue was ever empty.
<andreas-e>So maybe not after all... I still have a small hope that aarch64 might catch up on core-updates, assuming that not too much disruptive commits appear on other branches.
<cbaines>The bordeaux ARM machines should make good progress, once I get them building core-updates that is
<cbaines>I think they also have a head start, as there's some substitutes available from bordeaux for aarch64 on core-updates already
<some-one>Hello, everyone! Can anyone help me? I am trying to build a golang package. I use go-build-system in my package definition, but it uses go-1.17 default go, but I need to use go-1.20. I've failed to find any information on how can I achieve that.
<some-one>I see a definition of go-build-system, there is `lower` function that has a `go` parameter with the package but I have no clue how to redefine it.
<some-one>Does anyone have any thought where can I dig in further?
<andreas-e>It happened because I cancelled the builds of old evaluations. But I did not know that the consequences were that if the package was unchanged during a later evaluation, it would remain cancelled and not be restarted.
<andreas-e>And then this ripples through all the dependencies.
<andreas-e>The one gmp in yellow you see on the page is a cancelled build that I have restarted by hand.
<andreas-e>Now one needs to restart by hand all failed dependencies, in inverse topological order.
<andreas-e>I have written a script to restart everything, but there is not much point as long as this gmp is not built, for instance.
<andreas-e>I would like to cancel the rust-team builds so that core-updates is treated, but this would create the same problems for the rust-team branch further down the road.
<andreas-e>So the lesson is: As soon as something is treated by cuirass, there is no easy way to stop it without harming builds in the future (well, maybe by editing the database by hand).
<efraim>andreas-e: on the flip side, rust-team shouldn't be that disruptive. other than librsvg, rav1e, gdk-pixbuf and gtk+@2 everything is contained in rust
<andreas-e>I we are lucky, indeed we have the same derivations in rust-team and in core-updates. But I somewhat doubt that there are many that coincide.
<andreas-e>It would be nice to suspend the builds for a few days instead of cancelling them, but other than working with the priority (which did not fully work at least) I do not see what to do.
<andreas-e>I suppose that once the rust-team builds are in status "scheduled" (instead of just "submitted"), they will pass before a new core-updates evaluation that submits new build jobs.
<andreas-e>Or simply, a new evaluation should restart cancelled builds that appear among its derivations.
<andreas-e>cbaines: Indeed if we can have green dots or a good weather forecast for aarch64 on the bordeaux build farm that would be reassuring.
<andreas-e>I already did a "guix shell -D guix" on an aarch64 machine, which worked.
<andreas-e>Actually things are worse: CI is still building packages from the deleted staging branch on aarch64! But I dare not cancel them since many of them may be the same as in core-updates or rust-team.
<attila_lendvai>hrm, this issue is resolved, it's in the release archive. i just need to fix LD_LIBRARY_PATH. but the question often arises, and the best i can do is find /gnu/store
<cbaines>andreas-e, yeah, I'll get things going shortly
<apteryx>civodul: yeah, I had those GSSH errors to the point I couldn't work via offload early this week
<apteryx>but I thought (wish?) it was related to another problem with my SSH which was cutting the connection due to either AutoSSH or a configured 'ServerAliveInterval 15' in my ~/.ssh/config being too aggressive when the connection was heavily used (making it unresponsive)
<apteryx>it seems to have been stable since I figured that
<bjc>one of the most frustrating things about updating these rust crates is how much time i have to spend updating crates for windows and macos that we don't even use, but their lack makes the build break
<Guest31>Hi. Does the build process have a networking connection? I'm packaging python-gtts (google-text-to-speech) and unit tests fail because they get no connection. The compiled program works fine though.
<ryan77627>Hey, I'm still trying to learn Scheme/Guile, I have a question if someone could point me in the correct direction. I am trying to migrate all my applications into a `guix home` config file, but need neovim to be built like so: `guix build neovim --with-c-toolchain=neovim=gcc-toolchain@12`. Where could I look for defining a package with this requirement in a home configuration?
<ryan77627>Right now it seems to be built with gcc-toolchain@10
<rdrg109>[Q] Does anyone know which package has the "file" utility? I need it to get the mime type of some files, but my system shows "-bash: file: command not found", so it seems that it is not in guix by default
<mirai>I think a proper fix for the search path would have to do the following:
<mirai>scan the package for XML catalogs, which don't necessarily have a standard location
<mirai>and generate a “jumbo catalog.xml” that points to the catalogs in the packages
<mirai>perhaps in a similar way how manpages or $GNOME???_stuff is handled
<mirai>another thing worth to note is that docbook-xml 4.x is SGML stuff (notice the line with <delegateSystem systemIdStartString="http://www.oasis-open.org/docbook/" catalog="file:///etc/sgml/docbook/xmlcatalog"/>)
<jpoiret>czy: if by this you mean "trying to keep a working base GNU/Hurd system working" then yes
<jpoiret>ryan77627: you need to look into transform-package-toolchain in (guix transformations)
<mirai>apteryx: an alternative to fixing the problem at the root is to craft a xml catalog within wayland package that points to the (working) catalogs of the docbook-xml packages and set XML_CATALOG_FILES to use it
<mirai>it's ugly but _should_ work until a definite fix is concocted
<vhallac>It is not simply running programs, but having a session manager maintaining stuff for me.
<vhallac>Right now, I am using greetd to start sway using "dbus-launch sway" when I login from tty
<mirai>vhallac: GDM uses elogind for session management
<vhallac>My preference is to use greetd. At some point I want to use the tui login manager, but for now the tty one works well.
<Guest19>Ah okay. Well I have seen people here that use greetd. I am not using it and can't help therefore
<vhallac>I will look into elogind for session management, though. Thanks
<vhallac>Heh, looks like it is already done somewhere. loginctl shows my sessions.
<ryan77627>Is there any way I can tell what version of the C toolchain a package uses? I am trying to redefine neovim to build with gcc@12 but don't know what part of the package to change. I've been looking in the build system definitions but cannot figure out why guix builds it with gcc@10 by default.
<podiki[m]>anyone working on anything core-updates for x86_64/i686 currently? i'm looking at random build failures to see what I can fix
<vhallac>Heh. I just realized that I provided a link to emacs build script to a vim user. Sorry about that. ;)
<podiki[m]>you should look at the build-system for the package, the build inputs will have the compiler and tools used by default, usually you can override with either an argument flag or specifying it manually like (native-inputs (list gcc-12)) or whatever
<vhallac>Ah, yes. There is native-inputs with gcc on line 93
<mirai>I wonder if shepherd actions can take arguments
<mirai>I think they did but I've no idea how it works
<podiki[m]>ACTION continues the satisfying easy python fixes on core-updates...
<Guest19>why is that one package called gtk%2B? Only seen if guix pull or guix install and I wonder why it has such a weird name
<podiki[m]>what package? i've never seen that (maybe a font/terminal display issue?)
<podiki[m]>anyone know why gst-plugins-bad is failing on core-updates? looks like a test timed out, not sure if that is just something that needs to be restarted; causes gtk to fail
<ekaitz>jpoiret: zig in core-updates is the same than in master of I'm very bad at doing diff?
<podiki[m]>andreas-e: rebuilt locally fine, hopefully just a transient test timeout
<andreas-e>ekaitz: Yes, but it does not build any more because of the glibc update.
<ekaitz>andreas-e: oh shit, thanks for the clarification!
<Guest19>podiki[m] I think it is gtk+, not sure since it is a dependency of something. I see it in the linux tty and wondered why it has that weird name. Not sure anymore if it happens in a terminal emulator as well
<podiki[m]>just pushed more small python fixes, maybe 10-50 packages will hopefully build now after a few updates
<podiki[m]>Guest19: I think it is probably a display thing, sounds vaguely like something i've seen too
<andreas-e>ekaitz: There is also firstname.lastname@example.org, which, strangely, does build.
<andreas-e>podiki[m]: It also built on the farm, ouf! Now on to restarting everything by hand...
<jpoiret>Hopefully with zig and ncdu sorted out but if not i can drop them in the meantime
<Guest19>Does someone know if nckx is okay? He was always present and really helpful. Last time I heard from him he was not well and that is already a month+ ago. Kinda worried not seeing him around nowadays
<podiki[m]>i was gone around then so I don't know anything, but share your concern
<jpoiret>ekaitz: so it's libLLVM-15 segfaulting while being loaded
<Guest31>does anyone know which package provides glib-compile-resources ? or is it not packaged yet?
<jgart[m]>What's the status on the service for running the KDE desktop environment? Can someone point me to the relevant thread so that I can go RTFML? ;()
<podiki[m]>ugh, updating virtualenv needs a new hatchling related package (i happen to have locally at least), but wondering if this is asking for trouble right now....on the other hand, yubikey-manager is broken which is pretty key for people that use it
<jpoiret>podiki[m]: the llvm lib loads properly on an example it seems
<bjc>maybe i'll just patch the cargo.toml. it looks like the author yoinked that version for unstated reasons
<ryan77627>I feel I am so, so, so close. I made a new package definition for neovim and can get it to compile with gcc 10, but how can I get this code snippet to actually read the @12 after gcc without erroring? This code currently resolves in "gcc@12: unbound variable"