IRC channel logs
2023-04-20.log
back to list of logs
<podiki[m]>regression somewhere pulling in librsvg not librsvg-for-system (or whatever it was called)? <zacchae[m]>Any idea why 'herd status' prints "guile: warning: failed to install locale"? I have glibc-locales in my home config. <civodul>podiki[m]: turns out it was due to gtk+ -> ... -> libsoup-minimal -> samba -> rust <jonsger>ACTION tests his patch for cryptsetup@2.6.1, as it seems we don't support LUKS version 2 yet :( <civodul>jonsger: i've seen that too and ISTR discussions about LUKS2 support some time ago <jonsger>I tried at least `sudo cryptsetup convert /dev/whatever --type luks2` on my machine, but afterwards it refused to boot (stuck in Grub). Said cryptopartition not found or so... <jonsger>restoring the luksHeader back to version 1 enabled the system to boot again :) <podiki[m]>civodul: ah, on core updates then, where the samba i686 fix isn't pushed yet <podiki[m]>I can rewrite as the one pushed on master later if someone doesn't beat me to it <civodul>podiki[m]: i've pushed something that removes the libsoup->samba dependency on i686 <civodul>i didn't know there was a "samba i686 fix" somewhere <andreas-e>podiki[m]: The idea was to merge master to core-updates. If you have time now, that would be perfect. Otherwise I will do it tomorrow. <andreas-e>civodul: That should be consistent; when i686 becomes a supported system for samba, it should reappear automatically as an input to libsoup, no? <SUPERB[m]>I know this is not under topic but I was wondering if there is any AI language model under GPL? <podiki[m]>Sure, I can make the change tonight, I'll use the same form as apteryx did in the revision (don't have the issue # handy here) <monaho>how do i join a team? should i commit myself, or submit a patch? <apteryx>podiki[m]: OK, I'm almost ready to push the merge <podiki[m]>apteryx: ah, and does this have the samba fix too? <podiki[m]>python-cryptography and configure flag should be conditional on supported-systems <apteryx>and reverted the commit doing a similar fix to libsoup <podiki[m]>I think libsoup can stay since it should pick up that samba is i686 okay now (though the comment is misleading) <apteryx>it wouldn't hurt but it's confusing since now unnecessary :-) <apteryx>and the merge will have it rebuild anyway <podiki[m]>the structure was confusing before, with samba, samba/pinned, and then the grafted samba/fixed or whatever it was before you made it clearer <apteryx>yes, we had 3 variants for some reason <podiki[m]>right, standard samba and then graft when needed <apteryx>yes. I've kept the samba/pinned and samba, although the later is currently useless <podiki[m]>i didn't look enough to see why it was that way or what relies on it like that, if anything <podiki[m]>going forward with features branches I think we'll do standard grafting for quick security fix and then ungraft on a branch probably? <podiki[m]>anyway, future samba-branch can clarify when needed <apteryx>the pinned versions appear when things don't get updated fast enough <podiki[m]>being timely on graft and then ungraft hopefully saves us some headaches, doing it piecemeal as needed <podiki[m]>we just keep piling up grafts, updates, big fixes right now, so it becomes a mess <podiki[m]>I hope it will help spur bigger changes too, since it'll be more manageable to do and test <apteryx>I've now merged the Python-related changes I had accumulated on core-updates <apteryx>there seems to be some tests failing (make check)... we'll have to look into these <bjc>i regret deciding to get alacritty built <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? <civodul>happens in the middle of a large data transfer <cbaines>going to do some database maintenance on qa.guix.gnu.org, which should hopefully improve the performance <civodul>efraim: you do have SSH access to berlin though? <civodul>i set up an SSH tunnel to access the web UI directly <efraim>civodul: I don't. I used the client certificate in the past <civodul>oh ok; should we reinstate your access? <efraim>I'd love another certificate, but I could make do with ssh access :P <cbaines>civodul, regarding #62712 maybe those patches could be pushed to core-updates? <cbaines>that would save on doing a bunch of rebuilds after the branch has merged <civodul>cbaines: it's tempting, for sure; i just don't want to annoy folks who've been working hard on that branch with yet another rebuild <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. <efraim>probably not any, with the difference in glibc <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. <andreas-e>Well, 2 scheduled builds left, not a big deal. <civodul>"make assert-binaries-available" is looking much better on core-updates, now that we have GTK+ on i686 :-) <andreas-e>82% of the release manifest on CI, 17% on bordeaux. Maybe it would be time to start building core-updates there, cbaines? <rekado>FYI we still have a broken tensorflow on core-updates <rekado>problem is with grpc, which I haven’t been able to fix yet <some-one>I have found the answer to my question. In order to change a go package in go-build-system I could just pass it as arguments like (arguments `(#:go ,go-1.20)) <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 <civodul>apteryx: interesting; i never encountered it before (neither on my machines nor on berlin) <civodul>it looks like a recent regression, no? <apteryx>I had it sporadically for a long time, but it became acute as of recently. <apteryx>also, are all the machines involved updated to master? <apteryx>I thought perhaps one of the fix you did helped? <civodul>apteryx: i don't use ServerAliveInterval, no <civodul>the machines are not yet updated to 'master' <efraim>I started trying to update alacritty to 0.12 on rust-teams. IT WAS A MISTAKE <apteryx>updating any rust-* something immediatly fills me with regrets <apteryx>ACTION is exagerating, but the experience is not great, especially the lack of tooling (guix refresh -l/guix graph --path, etc). <bjc>i've been trying to get alacritty upgraded for many hours now <bjc>do you think npm was invented to make operating system distributions give up? <efraim>ok, I need a new terminal. I'm trying out sway and it seems terminology is making my computer freeze. <apteryx>the rest of the world probably vendors 4 GiB of rust crates for a terminal emulator and thinks it's normal <bjc>efraim: if you're not on core-updates, and using something like tmux, alacritty is pretty good <efraim>i'm currently on master and i've been using alacritty for a day or 2 now <efraim>I need to figure out the config for it for splitting windows and using tabs <efraim>and I need to figure out how to not pass the TERM to old boxes which don't know about alacritty <bjc>i don't think alacritty does tabs or window splits <efraim>I made it do tabs by accident. I couldn't undo it so I closed all the tabs and started again <efraim>or I'm messing up the terminology between tabs and windows <bjc>that goes in .config/alacritty/alacritty.yml <bjc>huh. i'll have to look into it. i thought alacritty was specifically minimalist and expecting you to use tmux if you wanted fancy panes and tabs and junk <efraim>if only minimal didn't include so many crates <efraim>maybe I'll stash my progress so far and try updating to 0.11 instead of 0.12 <bjc>that's just rust. the whole ecosystem is infected with some kind of brain virus that encourages maximal dependencies as a measure of quality <mirai>civodul: is it feasible to use source-properties to add docstrings for the record returned by define-configuration? <bjc>efraim: are you trying to update alacritty too? because i would like to stop trying to ;) <mirai>so that the record-type itself can also have its own documentation <efraim>bjc: I haven't decided yet. there's a patch for 0.10.1 in the patch tracker, I haven't seen how bad 0.11 will be <tribals>I've just set up aarch64-linux system build facility on x64 (planning lately to offload some hard byte smashing work from actual target device, as it has limited resources) <tribals>Then tried to build most funny thing - maven :^D <bjc>alacritty is broken with the sway in core-updates, so it needs to be brought up to 0.12 <civodul>mirai: hi! i would rather add docstrings to <configuration-field>, but that's already the case no? <mirai>I mean about the type itself <mirai>so that we can add custom descriptions and examples for foo-configuration <efraim>bjc: I'm going to take a brake for a while on alacritty and work on gdb@11 for riscv64 on core-updates. It's also failing <civodul>overall it's best to avoid source properties (side tables in general) and have first-class support for that <bjc>efraim: ok, i'll continue apace, then. it's not hard, just very tedious <civodul>apteryx: do you happen to have Python fixes floating around for core-updates? <civodul>i started looking at python-nptyping and other things leading to onionshare, but it's kinda above my head <mirai>civodul: what makes source-properties “bad”? <civodul>mirai: side tables in general are a hack for when you don't have any other solution; it's a substitute for a proper field in your record type or something like that <civodul>it uses more space, gives more work to the GC, etc. <mirai>how are procedures handling their docstrings? aren't they also using the same mechanism? <apteryx>civodul: I've already merged all I had <civodul>mirai: "procedure properties" is the historical side table for that, but compiled procedures ("programs") use a different thing (docstrings are in an ELF section) <civodul>too much activity on that branch :-) <apteryx>I'm not sure this one is fixed, but it may help <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 <zimoun>On CentOS, systemd kicks guix-daemon, even if I manual enable and start it. <mfg[m]>Is there an easy way to reference the version field of a package inside the package definitino where it is defined? <civodul>zimoun: "kicks" like how? is there an error message or something? <zimoun>I do not know. I do not have acces to the machine. Well, I am helping via email… Let me ask. :-) <mirai>how should I handle a service that wants to write a log file whose path is constructed from a path itself? (i.e. /foo/bar -> /var/log/my-service/instance-???.log) <mirai>a simple 'format' that returns /var/log/instance-/foo-bar.log ? (there are slashes in the name so I doubt that's a good idea even if it worked) <civodul>zimoun: you could try starting guix-daemon by hand to see what happens <civodul>mirai: that, but string-map it to replace slashes by dashes? <mirai>is that the only “sanitization” or are there other pitfalls as well? <mirai>I'd like to construct a path for a log file from a file-system record <rekado>I had been having problems with the python bindings, because we didn’t actually generate the C files from the pyx sources. <rekado>and that required adding grpc in a matching version to the inputs <zimoun>civodul: thanks. Yeah, I already checked that everything works fine when manually launches. :-) <civodul>zimoun: the difference is that the systemd service depends on gnu-store.mount, and that's not yet handled by our SELinux policty <civodul>the intertubes is full of ugly workarounds for that <zimoun>yeah, thanks for pointing our report. <zimoun>My guess was the error because systemd <zimoun>I am waiting the answer about SELinux. :-) <civodul>just read on Mastodon that x86_64-gnu is now a thing, woohoo! <civodul>jpoiret: more Hurd packaging fun ahead! <civodul>rekado: oh, i don't know about Python bindings, all i know is that it builds fine :-) <civodul>i've moved on to Jupyter using the same monkey-typing approach <jonsger>civodul: link to the Mastodon post? I just saw that the diverse Hurd repos are pretty busy regarding SMP etc... <rekado>civodul: okay, I’ll see if I can get the Python bindings working, based on your fix to grpc <civodul>jonsger: i have to admit i don't know how to get the URL of a tool from mastodon.el <daviwil_>ahh, I didn't see the context around "linux", just saw a notification for that message and joined in ;) <mirai>can a file-system 'device' field contain slashes? <mirai>it's either string | uuid | file-system-label <bjc>is there an irc channel that acts as a support group for people packaging rust crates? <civodul>mirai: as many slashes as pleases you <AwesomeAdam54321>bjc: Do you mean packaging rust crates in general, or help packaging rust crates in guix? <bjc>i mean just a place where i can scream and shout about how awful this is <dcunit3d>bjc what's making you pull in npm inside of a rust build? <bjc>i'm not. but cargo is just a recapitulation of all of npm's failures, but for rust <dcunit3d>oh, i still haven't looked into rust. how are you getting windows builds to work though? <bjc>i'm not. but the windows and macos crates are necessary to satisfy the build, so they have to be packaged <bjc>i've spent the last two hours on a branch of a branch of a branch of a dependency tree to get *objective-c* bindings built <bjc>yeah, i'm doing this locally <zimoun>However, there is no var_guix=/var/guix/profiles/per-user/root/current-guix <apteryx>I can't compress zip files with password in nautilus <zimoun>${var_guix}/share/selinux/guix-daemon.cil <mirai>can I override the 'status' action from a shepherd service? <mirai>is there any problems if I do so? <mirai>or is it merely informative for “herd status ...” <jpoiret>sneek, later tell civodul: wdyt of carrying a newer glibc for Hurd? I could make it work <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. <bjc>we disable tests that require networking <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 <apteryx>there's no good way to use gexps when to same-named inputs are used, right? e.g., two versions of docbook-xml <mirai>apteryx: can you share a snippet? <apteryx>I'd like to get rid of labels while preserving the logic selecting the right docbook-xml <apteryx>this shouldn't be needed in the first place but the catalog for 4.2 is broken, I guess? I think you had a patch for that <mirai>so, from what I've collected so far, technically this would be fixed with $what_was_the_number_again docbook-xml fixes <mirai>since it would fix the catalog for all docbook-xml 4.x versions <apteryx>v2 has only 4 patches; does it mean some were already applied? <mirai>the slight problem that always existed if I'm not mistaken is that XML_CATALOG_FILES is simply wrong <mirai>v2 squashed some of the patches <apteryx>what is wrong with XML_CATALOG_FILES? <mirai>if you were to spawn a guix shell with two docbook-xml versions, you'd notice only one of the catalogs is picked up <mirai>which would be the “direct catalog” of docbook-xml that happened to be picked up <czy>is the guix project still on its way to replace the linux kernel with gnu hurd? <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"/>) <mirai>the second paste groups up all docbook xml DTDs but this isn't necessary since we can control how the “jumbo” catalog is generated <mirai>(both pastes were lifted from fedora fyi) <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 <jpoiret>we have an old version of Hurd on master currently, but core-updates should bring a newer version that doesn't boot :) <jpoiret>we'll try to figure it out after the merge <apteryx>mirai: but XML_CATALOG_FILES can take multiple catalogs,no? <apteryx>why the need to generate a master one <mirai>it can, yes, though I don't know what happens if you cram lots of catalogs in it (is there a limit to how big this variable can get?) <apteryx>I doubt so. Linux is very lenient on that <mirai>and technically you have some extra control with a XML master catalog (you can route/rewrite/??? prefixes & public ids, etc.) <mirai>but as a workaround for the wayland package <apteryx>our search path should already list *all* of the catalog.xml files discovered <apteryx>I'm trying your docbook patches with wayland <apteryx>(dropping its patch-docbook-xml phase) <mirai>the catalog for 5 is nowhere to be found, and I suspect if you had another non docbook package that also uses catalogs the same thing would occur <apteryx>ah! this is because they conflict in the profile <apteryx>it wouldn't happen at build time though (cause there's no profile there) <mirai>(sidenote, there's a new version for docbook-xml, 5.1) <mirai>apteryx: so in a build environment the path would contain both catalogs? <apteryx>yes, I'll show you what the build log prints when I get to it <apteryx>(it has to rebuild a bunch of stuff) <mirai>though I wonder how to get it working within a guix shell / profile <apteryx>we'd need to add the version to the path <mirai>this would happen in libxml2 ? <apteryx>the search path of libxml2 would need to be adjusted <apteryx>the installation prefix of docbook-xml-* would need to be versioned <apteryx>perhaps something like xml/dtd/docbook-5.0.1/ instead of xml/dtd/docbook/ <apteryx>I think the current libxml2 search path would still work <mirai>sidenote, I don't know about the chosen prefix used <mirai>but shouldn't it be share/xml ? <apteryx>it could; not sure if there was a reason for the way it is <mirai>there's also the fact that there's no standard way to place these files <apteryx>it's not overly important in my opinion; since we look them via XML_CATALOG_FILES anyway <mirai>some other package can place it under share/foo/xml/mycats/... <apteryx>bah, it'll be like for our other packages e.g. installing udev rules <apteryx>they'll need a custom build phase to move them at the right place, if nobody agrees what the prefix should be <apteryx>hey! wayland built fine with your patches <apteryx>without messing with docbook stuff in the sources <apteryx>I'm going to update docbook-xml 5 and push that to core-updates <Guest19>It seems that my vterm/eshell window is broken with the new progress bar (instead of #). Turns out this is because I use BlexMono which basically is nerd fonts IBM Plex. I wonder why <apteryx>mirai: I've also set docbook-xml 5.1 as the default <mirai>I wonder what's the status of 5.2 <apteryx>weird, arch is still using 4.5 as its default docbook-xml <apteryx>perhaps we should stick to 4.5 if that's the expectation <apteryx>seems it'd break many things (e.g., elogind) <vhallac>Hello. I am slowly learning the mysterious ways of guix. Right now, I am trying to move my dotfiles (at least part of it) to guix home. <mirai>imo I don't think the “default” versioning is that important <mirai>since whatever documentation you wrote <mirai>targets a particular version <vhallac>I like making things fairly custom. So on my artix system, I use sway, which firex lxsession, which starts my services, such as gpg-agent <mirai>it's merely coincidental that it happens to work with a “newer” version <vhallac>The thing I am not quite sure about is: do I even ned a session manager such as lxsession? Or is shepherd replacing it in guix. <mirai>(that's the point of a DTD or in the case of docbook 5, the version attribute) <Guest19>vhallac standard is GDM and you can define in .xsession stuff you want to run upon login <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>He uses gcc12 for building emacs, but I am too new to understand the mechanics of what he is doing there <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 <andreas-e>I also just saw it when wondering about gnome. I restarted it on CI. <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 zig@0.9.1, which, strangely, does build. <andreas-e>podiki[m]: It also built on the farm, ouf! Now on to restarting everything by hand... <ekaitz>andreas-e: ok noted i'll dig on it <podiki[m]>that should really up our coverage then, we should be looking pretty good on x86_64 out to the leafs <andreas-e>Python, excellent! I saw that calibre also builds. Good work, together with apteryx! <podiki[m]>more credit to apteryx I'm sure, I just pick off easy ones here and there :) <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? <ngz>Guest31: "bin" output from glib does. <podiki[m]>htm...python-virtualenv is 2 years old, builds fine, seems works fine for packages except ones i'm seeing not build 🙃 <jpoiret>i'll try to build a sample project using libLLVM-15, don't know where to look for one though <jpoiret>to see if it's just our LLVM-15 that's borked <podiki[m]>did we split llvm into different outputs or change the static/dylib build option recently? maybe something there <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 <apteryx>podiki[m]: yes, llvm-15 is the first one to be built with DYLIB=ON <apteryx>llvm-cling is based from llvm-9, but also uses DYLIB=ON and works with cling <apteryx>there may be something in that package that is important that wasn't included in llvm-15 <jpoiret>it's segfaulting in getenv while loading the library, which works fine on some example i just compiled <jpoiret>i can't even use glibc debug symbols because they're the non-commencement ones 🤡 <acrow>When building a thing that requires 'strip' as in executables; what guix package is appropriate? Do I need to use eu-strip in 'elfutils'? <jpoiret>can't seem to load the libc debug symbols in gdb :( <civodul>jpoiret: did you do "set debug-file-directory /gnu/store/...-glibc-2.35-debug/lib/debug"? <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, jpoiret says: wdyt of carrying a newer glibc for Hurd? I could make it work <jpoiret>even manually doing add-symbol-file tells me No such file or directory. <jpoiret>🤡 not me try to use something inside a container <jpoiret>__environ points to inaccessible memory?? <bjc>love to run across a crate that requires a crate version that doesn't exist, yet somehow builds <bjc>zune-inflate wants libdeflater v0.11.0. libdeflater goes from 0.10.0 straight to 0.12.0 <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"