IRC channel logs

2023-07-06.log

back to list of logs

<agnem>When I source extra profiles created with manifests (as described here https://guix.gnu.org/cookbook/en/html_node/Basic-setup-with-manifests.html) the XDG_DATA_DIRS variable is not updated. Anyone got a nice way to work around that?
<agnem>Or maybe XDG_DATA_DIRS isn't meant to be propagated by a profile
<agnem>Also, can I add packages to a profile by providing a manifest (instead of replacing the whole profile)
<agnem>^ I ended up with (define (packages-from-manifest filename) (let ((port (open-input-file filename))) (eval (cadr (read port)) (interaction-environment))))
<PotentialUser-78>I'm trying and failing to disable guix's build phase "check", when building custom Python packages.
<PotentialUser-78>I've asked in the mailing list.
<PotentialUser-78> https://lists.gnu.org/archive/html/help-guix/2023-07/msg00004.html
<PotentialUser-78>But details are here. Anything that I'm missing?
<PotentialUser-78> https://snippet.host/ifvmmo
<frog>PotentialUser-78: when trying to build the package, you can see near the bottom of the output that it says "view build log at..." If you look at the filename of the build log, you can see the package that's failing is python-pyspnego. Your package never gets built because one of its dependencies fails first. this is a problem with a package in the guix main channel.
<ryan77627>Hey all, simple question (at least I think?) Trying to get EFI to work with libvirt machines. Installed OVMF and got its files in the proper place using (extra-special-file ...), but am still missing the ovmf_vars.fd file. It seems from a glance the ovmf package doesn't provide this. any clues as to where i can source the proper file?
<HiltonChain[m]>ryan77627, OVMF packaged in Guix is too old.
<HiltonChain[m]>As a temporary workaround, I once tried to download its package for another package manager, modify the configuration files and put them to the search path: <https://paste.debian.net/hidden/c9b5d4f1/>
<mirai>what's stopping it from being upgraded?
<HiltonChain[m]>I don't know, I think it's never upgraded since the addition.
<efraim>oh nice, with an upstream patch borrowed from gentoo I make it to the tests section for zig-0.9 on riscv64
<rekado>I’d like to upgrade python-pygments a little
<rekado>lots of packages depend on it
<rekado>should I create a new branch just for that update?
<civodul>rekado: hey! you can send it to guix-patches
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, davidl says: Hi I read your blog post from June 5th reg. dev environments and CI. Thanks for that write-up it was very useful! I had one hickup though when following it: the part saying "The end result looks like this (not repeating things that haven’t changed):" - actually I had to change the vcs-file? procedure and the *file* argument to local-file used by the package source field. Dunno if others find that self-evident,
<civodul>rekado: because the number of dependents is above the threshold, we'll have to manually tell qa.guix to pick it up
<civodul>WDYT, cbaines?
<civodul>davidl: oh right, thanks for the feedback, maybe we should edit it to mention that
<rekado>civodul: okay!
<cbaines>civodul, rekado maybe it's worth checking if python-pygments is changed on tex-team-next, as that's the big change being built at the moment
<cbaines>it if not, then we can manually submit builds, but if it is, it's probably worth just pushing the change to tex-team-next if ngz is fine with that
<civodul>cbaines: ah yes, tacking it on that train is prolly a good idea
<jonsger>how do you folks reboot you Guix System servers?
<jonsger>`sudo reboot` doesn't work very often :(
<civodul>jonsger: hi! "doesn't work"?
<civodul>it works for me and i hope i'm not the only one :-)
<jonsger>on my PC it works. But for my Hetzner VM and a baremetal server at Hetzner it sometimes/often doesn't work
<civodul>how does it not work precisely? :-)
<civodul>it hangs?
<jonsger>yep
<civodul>it'd be great if you could report the shepherd version and /var/log/messages excerpt to bug-guix@gnu.org
<bjc>jonsger: are you using any network-mounted file systems?
<jonsger>bjc: on this maschine not, on the other I'm using CIFS. But the problem exists also when I didn't had network mounted filesystems
<jonsger>I guess this time it was: "shepherd[1]: Service postgres might have failed to stop."
<civodul>not necessarily
<civodul>please report a bug with all the details :-)
<civodul>Friday hack idea 💡 combine guile-mastodon and (guix channels) to write a daemon that toots Guix channel news
<civodul>who's in? :-)
<civodul>granted, it's Thursday
<civodul>but it feels like Friday, doesn't it?
<cbaines>you can also ask the data service for all the news, which might save repeatedly guix pulling, e.g. https://data.guix.gnu.org/revision/2426e51688d479042ea115a634c6be2d8b9f3b99/news
<pjals>i don't see the need for guile-mastodon as a dependency :^)
<cbaines>unfortunately I haven't added JSON support for that endpoint yet :/
<civodul>ah!
<civodul>also, you need to be able to ask "give me all the news since commit X"
<pjals>i've hacked together a shell script that posts an activitypub note, should be relatively easy to port it to guile
<civodul>pjals: such a solution will also be accepted :-)
<civodul>ah yes, in Guile of course
<pjals>(if anyone's interested, https://git.vern.cc/vern/scripts/src/branch/main/tilserv/mkfpost )
<pjals>i think that might actually use mastodon api, still, it's compatible with pretty much every fediverse instance software
<civodul>neat
<efraim>`sudo reboot` works for me on my desktop machine but isn't on my pinebook pro
<civodul>uh
<civodul>and then we'll discover everyone knows about the bug but nobody dared report it :-)
<efraim>After that I'll report the bug about the time appearing twice in the logs :)
<jonsger>civodul: I thought that I reported it already in the pre shepherd 0.10 era, but I need to find the bug
<civodul>jonsger: oh, it'd be great if you could test with the latest release (0.10.1)
<jonsger>I'm on current master so I expect its running shepherd 0.10.1
<civodul>jonsger: yes; you can run "cat /proc/1/cmdline | xargs -0" to be 100% sure
<graywolf>Is it possible to use pre-inst-env together with nonguix channel? I am getting no code for module (nongnu packages linux) when I try to deploy using guix build from git (therefore using the pre-inst-env).
<jonsger>yep its shepherd 0.10.1
<rekado>graywolf: you can extend you core Guix with any modules by using “-L /where/the/other/modules/are” or by using GUIX_PACKAGE_PATH
<rekado>i.e. for whatever channel you want to use you must have a copy of the channel code so that you can add it to the load path.
<Kabouik_>nckx: Price: Yes, it's not priced as a toy. To be fair, I don't use it as one either, it's my primary laptop (and the secondary is just the old one now collecting dust), and it's powerful enough for that use in my situation. Re: Offloading: what does that mean exactly in the context of guix install? Things that available precompiled from substitutes install much faster of course, but it's still a relatively long process
<Kabouik_>compared to other package managers I've tried for pre-compiled software. When I use Guix on the phone, it's significantly longer because software often needs to be built for aarch64, I assume the substitute servers just don't have everything ready for aarch64.
<graywolf>Ooh... right. I am already usint -L ., but this did not occur to me for some reason. Thanks
<rekado>razlix77[m]: you’ll also need to tell nscd about ldap
<rekado>razlix77[m]: IIRC that’s done by adding nslcd to the list of name-services in the nscd-configuration of the nscd-service-type
<Kabouik_>Also, on the phone, Guix often complains that the disk is full and fails to install things, which I guess might be because of the compilation leftovers. I often run a guix gc to free some space, but am reaching the limit anyway. The rest of the system (and apt) work fine because I still have about 2GB of free space on /, but that is not enough for Guix.
<zacchae[m]>There are two packages which I am trying to install that don't have substitutes available. My puny L5 runs out of memory when it tries to build, so it crashes in a very unhelpful way. Is it worth making a bug report if I don't even have a log to reproduce?
<zacchae[m]>^ arm packages that is
<juliana[m]>what's the package? and is it aarch64 or 32-bit arm?
<juliana[m]>what are the packages* rather
<zacchae[m]>aarch64. Evince and jami
<zacchae[m]>I don't see existing bug reports
<podiki>PurpleSym: have a new rocm update patch I'm about to send; did you ever manage to get current version working for your card?
<lispmacs[work]>hi, I know all the guix maintainers are busy people, but was wondering if anybody had time to look at my little package patch:
<lispmacs[work]> https://issues.guix.gnu.org/63964
<pjals>the patch looks incorrectly encoded
<pjals>> +;;; Copyright � 2023 Christopher Howard <christopher@librehacker.com>
<podiki[m]>oh godot 4.1 is out, better update and finish my godot 4 patch
<lispmacs[work]>pjals: weird, I wonder where in the process that happened
<lispmacs[work]>patch file is UTF-8, so must have been some earlier step
<pjals>you sent it through git-send-mail, right?
<cbaines>zacchae[m], feel free to file a bug report, but do include the outputs that you're missing substitutes for
<lispmacs[work]>pjals: I think I just attached it to an e-mail
<pjals>you should always use git-send-mail, it does all the stuff for you
<cbaines>zacchae[m], looks like there's some prioritisation issues on the bordeaux build farm at least
<juliana[m]>zacchae: looking into it, evince is failing to build on the same file each time I try to build it. libdocument/EvinceDocument-3.0.gir
<juliana[m]>that's... way outside my wheelhouse, but if you wanna open a bug report I can add some traceback
<juliana[m]>"ldd return non-zero exit status 1"
<zacchae[m]>cbaines: Thanks, I'l submit that after work (or sooner if I run out of work)
<zacchae[m]>juliana: Neat. I guess I'll ping you when I make the bug report
<juliana[m]>poge
<PurpleSym>podiki: No, my card is not supported any more my rocm. Too old.
<podiki[m]>PurpleSym: which one again? do you know the gfx### of it? (just curious)
<podiki>hooray, godot 4.1 builds and works, just gotta muster the will to clean up and finalize the patch
<pjals>finally! godot for four guix!
<GNUtoo>Hi, is there a way to refer to a package output in a service configuration? I'm interested in having something like that in nginx:
<GNUtoo>(service (nginx-service-type (nginx-configuration [...] (root <reference to package output>))))
<GNUtoo>So far I did (root (string-append (with-store store (package-output store gnutoo.cyberdimension.org)) "/")) but I also use a machine definition and use guix deploy and for some reason the path to the package doesn't exist in the target
<graywolf>Is there a way to specify the path from which guix deploy should read the signing key?
<rekado>GNUtoo: that’s what gexps can do for you
<mirai>^^
<mirai>podiki[m]: Can you run OpenCL apps on AMD GPUs (using rocm) with plain guix?
<mirai>sneek: later ask civodul: Is this procedure still relevant? <https://git.savannah.gnu.org/cgit/guix.git/tree/guix/packages.scm#n876>; The linked discussion indicates that the issue has been fixed.
<sneek>Got it.
<podiki[m]>mirai: I'm not sure, I need firmware for my (newer) gpu anyway, unless i'm just at 1024x768 res or something like that
<mirai>what gfx#### are you using (or family name)
<podiki[m]>I think gfx1100? just upgraded to a 7900xt, before was a 6700xt
<mirai>hmmm… are there multiple rocm package versions in guix? Or is it only the “latest” one
<podiki[m]>currently just the latest one, unfortunately really hard to tell what cards are supported since amd's documentation is terrible on that (last I checked)
<podiki[m]>they tend to note more the workstation class ones, but maybe they've updated it
<podiki[m]>shouldn't be too hard to restore old versions, did see one patch from gentoo(? i think) to restore some older gfx8* that was disabled seemingly mistakingly upstream
<mirai>IIRC FIJI/gfx8## cards were EOL'd since some rocm version
<mirai>it was written somewhere among their documents I think
<podiki[m]>I haven't tried, just saw https://mirrors.dotsrc.org/gentoo-portage/dev-libs/rocm-opencl-runtime/files/rocm-opencl-runtime-5.0.2-enable-gfx800.patch and linked issue
<podiki[m]>pjals (and others): messy wip patch for godot 4.1 https://paste.debian.net/1285146/
<pjals>many people still rely on godot 3.x, maybe you should split into godot-next or something?
<podiki[m]>yeah, it is an lts release now
<podiki[m]>unfortunately I think there are so many changes to the build will just have to copy/paste without a clean inherit structure, oh well
<podiki[m]>so godot-lts will be godot@3 and godot will be godot@4 is my thought
<podiki[m]>(discussion on forthcoming patch submission of course)
<PotentialUser-50>i'm trying to run guix with qemu, but i'm not familiar with qemu. i am not sure how to get online. i get an error saying RTNETLINK answers: Operation not permitted when trying to run dhclient
<razlix77[m]>hello again :) another day another wall to hit trying to set the console font
<razlix77[m]>````(("tty1" . "LatGrkCyr-8x16")
<pjals>do you want us to help you or?
<razlix77[m]>yep trying to get tho code pasted
<pjals>dont do it like that
<pjals>put it on paste.debian.org
<pjals>this is bridged to irc and irc does not like multiline
<razlix77[m]>ah ok
<razlix77[m]> https://paste.debian.net/1285148/
<razlix77[m]>according to the manual https://guix.gnu.org/manual/devel/en/guix.html#Base-Services it should work with a list of tty . font_name
<razlix77[m]>in my case /home/razvan/.config/guix/system.scm:85:4: error: (service console-font-service-type (quasiquote (("tty1" . "LatGrkCyr-8x16")))): invalid field specifier
<razlix77[m]>I did remove the service from the %base-services list
<pjals>there's information that we dont have, post your whole operating system declaration with information you dont want to share redacted
<razlix77[m]> https://paste.debian.net/1285149/
<pjals>(remove) doesnt exactly work that way i think
<mirai>that can't work
<mirai>you need to use modify-services
<razlix77[m]>still trying to grog the scheme part I do admit :)
<razlix77[m]>it seemed to work for gdm
<razlix77[m]>of course it's copy pasted so yeah
<razlix77[m]>ok back to the drawing board I guess thanks!
<PurpleSym>Podiki: It’s an RX460. No idea which gfx<version>.
<RavenJoad>I am having an issue getting a system test to run. https://github.com/KarlJoad/guix/blob/apcupsd/gnu/tests/power.scm I get guix build: error: #<<apcupsd-configuration> package: #<package apcupsd@3.14.14 gnu/packages/power.scm:33 7f3aab2c0a50> auto-start?: #t>: invalid G-expression input.
<RavenJoad> I know the apcupsd package is defined right, because it builds. The service is the only possible issue, but that has no issues building in the REPL. So it is just this system test failing.
<ternary>I've been trying to get all of my various configs moved over to guix home, but I have a problem with vim right now. It doesn't seem to be able to display certain characters now and I can't set my listchars variable to what I want because it has some special characters
<ternary>Does anyone have any idea what my Guix home config could be missing?
<RavenJoad>ternary: Given that it is only certain characters (and I do not know which), could it perhaps _not_ be a vim problem, but a terminal emulator & font problem?
<ternary>I think it definitely could be that, this is an area I don't know much about. The characters I have noticed so far are a forward arrow that i'm using for a tab and the center dot
<ternary>Okay, I just ran /usr/bin/urxvt instead of what's in my guix profile and the problem went away, so it's got to be something wrong with how urxvt is configured with my Guix setup
<RavenJoad>Perhaps check the .XResources that Guix's urxvt tries to read.
<ternary>What do you mean? Is there one that loads before my ~/.Xresources?
<mirai>ugh… so how to handle unversioned URLs for sources
<ternary>Okay, nevermind, I think I've figured it out. Previously I didn't have the correct fonts and whatnot installed, but even after I fixed that, I hadn't restarted my urxvt daemon so it was using all the old stuff. Restarting that daeomon seems to have got everything to work
<mirai>RavenJoad: for starters marionette-eval needs 'marionette'
<nckx>mirai: Is there no source control repository? Or ask upstream to please stahp it and/or mirror a copy elsewhere.
<mirai>nckx: its this aberration <https://data.iana.org/root-anchors/> or <https://www.iana.org/dnssec/files>
<nckx>(Or, I guess, in theory, you could specify an invalid URL to force Guix to fall back to Disarchive…)
<nckx>(…yuck.)
<mirai>and within RFC7958, it says: The URL for retrieving the set of hashes described in Section 2.1 is <https://data.iana.org/root-anchors/root-anchors.xml>.
<nckx>Or piggy-back on another distro like <https://sources.debian.org/src/dns-root-data/2023010101/>.
<mirai>I suppose the trustanchor id attribute could be used for identifying which “version” the package is but the URL is still unversioned
<mirai>nckx: is it “fair-game” to do so? (it feels like we should be solving this from our side rather than piggy backing); another thing: I did look at what debian was doing and its just… strange
<mirai>because many of the updates are “debian updates”, the source didn't change
<nckx>Oh? Why? I didn't look into the latter in detail.
<nckx>Ah.
<nckx>That's normal Debian packaging style.
<nckx>No?
<RavenJoad>mirai: Ahh. Good catch. I missed that one last night. I still get the same error after changing it though. (URL is updated with changes too)
<GNUtoo>rekado: ok, the issue is that I'm not sure if it works in the service list
<mirai>well, personally this question would nag me: “What's the version of the trust anchor I'm using”
<nckx>mirai: There are several Guix packages that use a Debian (re)package as source.
<nckx>Whatever IANA calls it (that ID you mentioned, for example, if it's meaningful). Or use the date given at https://data.iana.org/root-anchors/ .
<mirai>I guess I could use the trustanchor id attr as version and point the source to a debian mirror?
<nckx>We don't have to follow Debian's versioning scheme if it diverges from upstream.
<GNUtoo>rekado: #$<the package public-define> for instance didn't work
<nckx>mirai: For example.
<nckx>As long as the files match :)
<mirai>the ID is opaque but at least it tells you which trust-anchor you had/were using
<mirai>RavenJoad: Your #$apcupsd-command is unlikely to work (ungexping a list)
<mirai>ungexping lists have some finer details
<RavenJoad>Ah. Ok. Time to tinker a bit then. I should have caught that.
<mirai>try going along the lines seen in audio.scm
<mirai>those patterns should work out ok
<hwpplayer1>I learned treemacs-position describe-variable
<lispmacs[work]>pjals: I resent the patch using git-send-email
<lispmacs[work]> https://issues.guix.gnu.org/63964
<hwpplayer1>sorry I realized I send the message to the wrong channel
<mirai>nckx: I wonder if IANA would be so kind as to provide us with actual versioned URLs
<nckx>Oh, my ‘ask upstream to stahp’ above wasn't sarcastic. Yes, that would be grand.
<RavenJoad>mirai: I copied openssh's format, and kept the actions field in the shepherd-service without knowing what it was for. Removing it fixed the problem. Thanks for your help.
<mirai>nckx: time to compose an email I guess
<djeis>It seems like the .dir-locals file on the main guix channel interacts really poorly with my emacs config somehow, throws me into an infinite regression of asking for confirmation to execute stuff and I have to kill emacs.
<frog>GNUtoo: exclude #$ to fix that. just package name.
<takev[m]>Is there a way to do a guix import for a cargo file thaht you pass as an argument? I am attempting to package a rust program for someone.