IRC channel logs


back to list of logs

<reflog>i am having a problem compiling C code with gcc. i installed gcc-toolchain and if i try to compile a helloworld it i get errors like: include/stdio.h:371:54: error: unknown type name ‘__gnuc_va_list’
<reflog>any ideas why this is happening? on my other computer with guix it works fine
<reflog>and this is trying to compile via command line. not through package. packages seem to compile fine
<mange>Are you on a foreign distribution, or could there be something else interfering with your environment? Try inside "guix shell --container gcc-toolchain"?
<reflog>it worked in the container you suggested. and im on the guix system
<reflog>any ideas what might be interfering?
<mange>Can you try in a pure environment, with "guix shell --pure gcc-toolchain"? That's a bit less isolated, so it might cut down the search space for what's interfering. At this point, though, you just need to find out what part of your environment is causing the issue.
<reflog>shell --pure also worked
<mange>Okay, so then it's something in your environment variables. Have a look at the output of env and see if anything looks off?
<reflog>i dont see anything that seems off. i will do a diff from the other computer that works
<jonsger>civodul: I'll try to come to "Au bon vieux temps" tomorrow evening :)
<reflog>i dont know. i did a diff with the working one and it seems reasonable
<permcu>I am trying to download a current guix iso. But returns "Could not find the requested build product." Even if ci.guix shows it has build the iso.
<permcu>Downloading the iso from does not work either. But status is succeeded.
<civodul>jonsger: yay!!
<civodul>i knew i could count on you :-)
<jonsger>let's hope that the train ride goes well and I don't arrive so late in Brussels
<reflog>mange: i figured it out. i had musl installed. i realized when i looked where libc was pointing in my .guix-profile/lib dir
<reflog>thanks for your help!
<apteryx>jpoiret: haven't tested it yet, but given that RHEL 8 had switched to use it, I have expectations it'll just work.
<platoxia>Is guix home ready for prime time yet? It seems like the manual isn't up to date with the tool is why I'm wondering.
<Kolev>platoxia, I'd say it is lacking in services.
<Kolev>Although the proprietary version of Guix has added service definitions to its repos. Hopefully they contribute relevant ones upstream to us.
<mange>I don't think there's anything that I would call a "proprietary version of Guix". There are unofficial channels that package non-free software, but the terms of the GPL still require the channels themselves to be released under the GPL.
<mange>Saying "proprietary version" makes me think of the "open core" business model, which emphatically not applicable to Guix.
<Kolev>mange, there is a non-FSDG derivative of Guix.
<mange>Sure, but I think describing such projects a "version of Guix" is misleading. It would be like calling Ubuntu a "version of Debian".
<rdrg109_>[Question] What's the package with the smallest size in the Guix repositories? I'm asking because I want to run some experiments on installing packages, so I want to install a package in the shortest possible time. I guess it is "curl".
<mange>Why do you guess curl? You can use "guix size" to get guix to report the size of a package. bash-static seems pretty small?
<mange>Do you mean just the package itself, or the package+dependencies?
<Gooberpatrol66>advice for fixing a frozen shepherd?
<iyzsong>Gooberpatrol66: not a fix, but sysrq+reisub could do a more safe reboot than hard poweroff
<mrh57>when packaging, is there a way to set the output package names? not the symbolic name of the package, but the names of the actual outputs.
<sneek>mrh57, you have 1 message!
<sneek>mrh57, podiki says: rest up and hope you feel better soon!
<mrh57>I was trying to package the taglib bindings library for common lisp, but its name is simply "taglib", which conficts with taglib itself naming wise, so that if you try to actually install the CL taglib library you get "error: profile contains conflicting entries for taglib"
<ieure>mrh57, Are you talking about the package name?
<ieure>Outputs can't conflict between packages.
<mrh57>ieure: yes sorry, I mean the package name
<ieure>mrh57, It's Guix convention to prefix Common Lisp package names, so if you have CL bindings for taglib, that'd be cl-taglib.
<mrh57>ieure: right yes, though if I put the name field as "cl-taglib", asdf (as invoked by the guix asdf-build-system/sbcl) gets confused, saying "Component 'cl-taglib' not found"
<ieure>mrh57, Can you paste your package definition?
<mrh57>ieure: sure
<ieure>Wow, that is... some bold styling.
<ieure>mrh57, Hm, don't see anything that looks obviously wrong there. Have you looked at any of the existing CL packages in Guix? Some of them must have had the same issue.
<mrh57>ieure: loll I see, it looks fine with dark reader but wow yes without it its quite... contrasting
<mrh57>ieure: I assume the issue is that the actual .asd in the repo has the internal common lisp package name as "taglib", but the guix asdf-build-system/sbcl is trying to use asdf to build the guix package in the definition, which is "cl-taglib", which doesn't exist in the .asd
<mrh57>ieure: I did look through some package definitions but nothing jumped out, but I'll keep looking
<mrh57>ieure: it might also have something to do with not being able to specify the name of the source link in the package definition (since this repo has no releases/tarballs of any kind)
<ieure>mrh57, All you'd need to do is find a CL package whose name doesn't have the CL prefix, but does have a Guix package. Drakma maybe?
<mrh57>ieure: I think drakma is cl-drakma
<mrh57>ieure: oh I see what you mean lol
<mange>Which asdf build system are you using? Looking at guix/build-system/asdf.scm:285 it looks like it tries to strip the prefix based on the Lisp name. So if you use asdf-build-system/sbcl your package should be named sbcl-taglib.
<mrh57>mange: ahhhh yes!
<mrh57>that would have been a good place to start
<mrh57>I have sadly run into this issue, has anyone else? :
<apteryx>(gnu packages commencement) violates a few circular dependencies rules
<apteryx>c.f. info '(guix) Cyclic Module Dependencies'
<apteryx>in inherit fields for example
<apteryx>(inherit gash) -> gash is from a different module
<apteryx>ah! "To avoid circular dependencies, this module should not be imported directly from anywhere"
<apteryx>in a top comment
<Gooberpatrol66>if the user shepherd process has died, is it possible to restart it from the root shepherd?
<Gooberpatrol66>is there a service attached to it?
<adanska>Hi Guix!
<sham1>Hi adanska
<adanska>I've been following the core-updates thread on guix-devel and I was just wondering: whats the blocker with core-updates being merged atm? are we just waiting for substitutes or something else?
<adanska>Hi sham1!
<rekado>adanska: usually, it’s removing enough unacceptable build failures that unblocks a merge.
<adanska>ahhh, i see
<adanska>i had a cursory look over ci and it looked like things were still building, but now i can see the build faliures
<bdunahu>Does anyone have experience configuring openssl to accept legacy (TLS 1.0) connections for use with wpa_supplicant?
<roran>Do failed builds have their outputs saved anywhere for me to see why they failed without having to try to run build commands myself?
<rekado>roran: only if you use “-K” (--keep-failed)
<roran>Does that preserve build logs, or just the failed outputs
<roran>The failed output files, that is
<roran>And is that -K for build, or can -K be provided to guix package, as well
<rekado>it preserves the build directory
<rekado>it is for “guix build”
<roran>does guix build work like guix package? can i just say "guix build -f <file.scm>"?
<roran>oh ho ho. now i see lots of good output.
<roran>where does that put things after the build? i'll read the manual.
<roran>looks like vkdt has some goofy stuff going on with rawspeed. maybe i can use this chance to see if it'll build with something else
<roran>it looks like building rawspeed takes a LOT of dependencies, whereas i could instead use rawler as the backend. very interesting
<roran>i'll talk with him
<rekado>roran: everything ends up in /gnu/store
<roran>so if i rebuild it, it will nuke that dir?
<rekado>you cannot rebuild something that’s already in /gnu/store
<rekado>you can only do “guix build --check” to confirm that the output is the same
<roran>very interesting. what is happening when i do guix build -f <file> more than once? what about if i do the same thing with guix package -f <file>?
<rekado>once the thing is in /gnu/store you’ll just get the location back
<rekado>it won’t build the thing again when it doesn’t have to
<roran>that's kinda neat, though it's unfortunate. so what happens when i make edits to that <file>? a new hash for the system is generate?
<roran>that's kinda neat, though it's unfortunate. so what happens when i make edits to that <file>? a new hash for the system is generated**
<rekado>when any input changes you get a new hash, so it ends up in a different location in /gnu/store
<roran>aha. do those old dead builds lay there forever?
<rekado>until you run “guix gc”
<roran>[36423 MiB] deleting '/gnu/store/14ijfxdma57iqia8xgcjjcd08jlpgynh-grub-2.06.tar.xz-builder' does this number mean what i think it means?
<roran>guix gc: freed 45,860.12 MiBs HAHAHA
<roran>thanks for reminding me, rekado.
<zilti>I am trying to get Hyprland running on Guix. It compiles fine by now (that was quite a fight, due to Hyprland's weird build), but I can't get it to start... I get log output saying "EGL_EXT_platform_base not supported", "Failed to create EGL context", and "m_sWLRRenderer was NULL!"
<zilti>Is there a special dependency or some configuration I need? Currently I am running swayfx, which runs just fine, and I am pretty sure that one probably also needs EGL?
<jpoiret>isn't EGL unsupported by wlroots?
<zilti>jpoiret: No idea, but wouldn't that be weird? Since Hyprland depends on it. I actually did copy the wlroots package though, to make a wlroots-master, since it needs features that are not yet in the Guix-supplied version
<jpoiret>ah, no, I'm mistaking it with eglstream
<hackyhacker>is that the nvidia eglstreams?
<hackyhacker>I hadn't heard of hyprland before but it looks really cool. Would love to try that on my guix box.
<jpoiret>zilti: you might be missing some mesa stuff? don't know too much about it
<zilti>jpoiret: Hmm. I definitely have everything swayfx has, and I also compared with the hyprland package on nix. I'll keep tinkering a bit more then, thanks so far!
<jpoiret>good luck
<doriru>hello. why isn't it possible to download the latest build?
<rekado>doriru: what URL?
<jpoiret>rekado: the one at
<jpoiret>it hasn't worked for a while
<Kolev>zilti, wait, what's swayfx?
<janneke>anyone tried the new guix home dotfiles?
<janneke>when following the documentation, i'm getting extra toplevel directories
<janneke>dotfiles/guix/.config/guix/channels =>
<janneke>=> ~/guix/.config/guix/channels.scm
<janneke>what gives?
<janneke>*dotfiles service
<zilti>Kolev: A soft fork of sway that adds stuff like window transparency, rounded corners, etc.
<cwebber>Anyone in Brussels already tonight?
<dthompson>cwebber: ludo sent an email to guix-devel yesterday about meeting at Au Bon Vieux Temps around 9:30/10pm
<Zambyte>Could someone take a look at this patch? Just adding an environment variable, should be really easy to verify :)
<apteryx>I'm struggling to understand identifier-syntax, as in the pkg-config example
<apteryx>when is pkg-config-for-target evaluated exactly?
<apteryx>does it do a simple substitution as the doc implies, meaning (pkg-config-for-target (%current-target-system)) would be evaluated at load time?
<apteryx>so it depends on pkg-config-for-target being defined in the scope it expands to?
<apteryx>these questions stem from some changes I've made, and this resulting backtrace:
<ennoausberlin>Hello guix. Are we aware of glibc CVE-2023-6246?
<apteryx>I think jpoiret is :-)
<jpoiret>the POC didn't work when we tried yesterday
<jpoiret>but yeah we do have to fix this in master
<ennoausberlin>jpoiret: I did not see anything in the issue tracker, so I asked. Thank you.
<apteryx>is it fixable by grafts?
<jpoiret>yes, it should be
<apteryx>what didn't work in the POC?
<jpoiret>i didn't get the segfault
<jpoiret>ludo didn't either
<jpoiret>we're quite behind on 2.38 fixes
<jpoiret>since they don't do releases but just maintain a release branch, maybe we should just get the source from there
<jpoiret>instead of carrying a bunch of patches
<apteryx>that's probably less work yes
<apteryx>I'd approve that; backporting patches shouldn't be the work of downstream users
<jpoiret>i'll try building the tip of the branch and see if it works (since that's going from a dist tarball to a git clone, there might be differences)
<jpoiret>2.39 tomorrow 🙏
<apteryx>yeah, resolved my pkg-config problem. it was caused by a cycle in (gnu packages commencement)
<apteryx>these issues are my least favorite to debug, along non-deterministic bugs (network related or such
<jpoiret>huh, I'm extremely airheaded
<jpoiret>of course we're not affected by that CVE
<jpoiret>it affects glibc ≥ 2.36 iirc
<jpoiret>because I was working on c-u with 2.38 I was sure that it affected us on master as well 🙃
<apteryx>good news!
<jpoiret>yes :) that would explain why that POC didn't work
<jpoiret>but it's annoying for c-u. tbh i'm tempted to just try out glibc 2.39 on it instead of carrying a graft right out of the gates
<efraim>There's going to be more CVEs for 2.39 also, not sure it really makes a difference
<jpoiret>there will ofc., but right now we're faced with either 1) change glibc to track the 2.38 release branch → world rebuild 2) graft glibc → bad user experience (and we're not supposed to graft outside of master) 3) switch to 2.39 → world rebuild + possibly more work
<apteryx>we could try 2.39 I guess
<apteryx>if it turns out to be too much work, fallback to grafted 2.38
<ulfvonbelow>when I try to 'guix system image -t iso9660 --system=i686-linux gnu/system/install.scm' it fails to build guix, ending with: GC Warning: Out of Memory! Heap size: 3366 MiB. Returning NULL!
<apteryx>I meant fall back to glibc from its release branch 2.38 + world rebuild
<ulfvonbelow>what are the odds this is caused by some careless local change to the module dependency graph?
<jpoiret>ulfvonbelow: the install image does the equivalent of a guix pull, so it takes lots of ram
<villageidiot>When I use `guix shell` to download a package which provides a texinfo manual, then run emacs from within the shell, I don't see the manual via `info`. Is there a way to get this working as expected?
<villageidiot>To be clear, after a regular `guix install`, I see the manual.
<apteryx>problably need to add info-reader to get a refreshed TEXINFO_PATH env var
<apteryx>villageidiot: the same you would need to add man-db to make man pages available in a profile
<apteryx>search paths aren't currently merged across profiles, that's an old limitation
<ulfvonbelow>also works to add emacs
<villageidiot>Ah, right. The path update stuff always gets me. Let me try that apteryx
<villageidiot>Works like a charm. I'll use your method, ulfvonbelow, because it'll be easier to remember :P
<jpoiret>apteryx: I sent a main regarding core-updates
<podiki>jpoiret: latest on vulkan/zink/mutter issue? i should have some time to look later today
<jpoiret>I haven't really looked into it yet, mb
<jpoiret>I'm also worried it might be due to a merge error
<podiki>there were a few updates on mesa-updates previously, but wasn't much. there was a patch for sdl2 to find vulkan if i recall
<podiki>(i see that on core-updates too)
<efraim>I have to catch up on how the core updates branch is going and if I want a rust team merge before or after
<jfred>Does anyone know of any good instructional videos about defining new Guix services? I've found plenty for package definitions but service definitions I've always had trouble with
<podiki>videos no, but all of gnu/services is at your disposal
<jfred>Yeah, I just find it easier to pick things up when I can see someone walking through an example and explaining their reasoning as they go
<apteryx>neat, switching pkg-config to pkgconf is not a world rebuild endeavour
<apteryx>ACTION merges master into core-updates
<apteryx>nckx: my standalone boot script failed to adjust the initrd line; did we change something in how our grub.cfg is written?
<apteryx>nckx: haha, I think an extra space has slipped between initrd and its value in our generated grub.cfg, which broke my script regexp
<teddd>Hi there, what tools do we have to parse config files in guix / guile ?
<jpoiret>teddd: config files as in the conf file format?
<teddd>yes or a .ini file
<podiki>at some point (months ago?) i lost some icons in my emacs modeline
<podiki>i think some others have mentioned it, anyone here? or seen other issues around emojis/fonts in other programs? (i seem to have lost some font in some desktop programs)
<teddd>podiki: I had the same problem. Some packages switched from all-the-icons to nerd-fonts, which caused some problems. Not sure if all problems I had came from here though. After updating everything things worked out again. Note that I don't use guix for all emacs packages though
<podiki>i do use all-the-icons. you mean some packages in their upstream have changed their dependencies/how they will find icons?
<teddd>Yes that was the case for icons used in mu4e for example
<iK0u>How did guix implement containers? Does it use LXC?
<podiki>teddd: thanks, that gives me something to look for
<teddd>podiki: Glad I could help
<podiki>ah, for doom-modeline:
<teddd>podiki: nice !
<podiki>interestingly, i have nerd-icons somehow (pulled in as dependency?)
<teddd>jpoiret: I know (gnu services configuration) has some things to generate config files but it doesn't seem like one can parse config files.
<jpoiret>teddd: right, that's something we don't really need in guix i would say
<jpoiret>but there might be a guile library out there that does that
<teddd>podiki: Yes I also had it somehow. I tried to switch to it but resorted to stick with all-the-icons for now
<jpoiret>iK0u: no, it just uses the same low-level mechanisms as LXC/Docker, ie. Linux namespaces
<teddd>jpoiret: Yes that's what I thought. But couldn't find one. So I came here. I'll ask on #guile as well
<iK0u>jpoiret: Has security been a focus of it? For example does it have comparable security to LXC?
<jpoiret>it's less audited that's for sure, but the principles are the same. If you want to be watertight though, I would suggest using LXC. Guix containers are not meant for adversarial situations I would say
<jpoiret>the namespaces themselves should work the same way but I'm not excluding some misconfiguration on our part that could cause things to leak somehow
<iK0u>Other than the namespaces has other features of LXC like CGroups and seccomp been included?
<jpoiret>although you should be able to tie cgroups together with them, but it's not available out of the box with eg. `guix shell --container`
<iK0u>Ah, well I find guix containers very convinient to use so far
<teddd>Does one of you know a good ressource to learn about linux namespaces and low-level container linux technologies ?
<podiki>teddd: thanks, mostly fixed. seems a setting i had to work around a mu4e marker icon issue (adding a specific font) was making issues too
<podiki>but still not sure why i'm missing icons/emoji in desktop programs. seems to fallback to some very limited set in black and white
<teddd>podiki: Nice.
<teddd>For the desktop I don't know, I had no particular problems myself because of updates
<teddd>Though I had more or less good experience with some icon sets than others. I had to experiement a bit around before finding the right ones
<podiki>in my case things stopped working/disappeared. refreshed my font cache, but maybe some other setting somewhere has changed
<podiki>font stuff is always annoying to debug
<teddd>I feel you
<teddd>I spent a day or so a few weeks ago just doing this
<teddd>podiki: If that can help I now use yaru-theme, which are the ones used in gnome I think and they just work everywhere.
<podiki>in this case it is icons and emojis from fonts i think....
<podiki>just not sure what changed. is only in some programs, so might be some configuration there (sadly binaries, so perhaps environment issue)
<teddd>podiki: Ah yes binaries are still hard to handle
<apteryx>can the mold linker be used for GNU hurd?
<apteryx>related: could it be a suitable replacement for GNU ld in Guix?
<apteryx>if it is, since it's MIT, it could even be adopted by GCC as its default linker, beating LLVM's lld at efficiency.
<jpoiret>teddd: the manpages are quite good for technical details, otherwise there's a nice redhat guide about them iirc?
<jpoiret>ah, great, using `M-x woman RET namespaces RET` just crashed my emacs
<teddd>jpoiret: haha. Yes redhat looks good
<podiki>teddd: updating the binary program in question seems to have done the trick (regarding emojis). or maybe something else that updated, but think this was it.
<teddd>podiki: ah great !
<ulfvonbelow>how does one unvendor googletest? I have a package that I'm trying to add that insists on using a vendored googletest (by that I mean that running cmake fails with "googletest missing, run git submodule update --init" even when googletest is provided as a native-input).
<apteryx>re can mold replace bfd.ld; its author will have a talk about it at FOSDEM:
<zamfofex>ulfvonbelow: Maybe you need to patch the package.
<dgr>will there be a live stream available of the guix days?
<alextee2>hi! i'm creating a channel for the first time and i have some questions
<alextee2>can someone point me to a super simple example channel repository with 1 package?
<dariqq>alextee2: The cookbook has something on that:
<alextee2>dariqq, thanks
<adamnr>HI Guix
<adamnr>The IRC archive has stopped updating for Guix and Hurd
<alextee2>what does this mean? (exception misc-error (value #f) (value "no code for module ~S") (value ((packages zrythm))) (value #f))
<snape>alextee2: hi, maybe just be aware that a channel is meant to be shared, if you don't share it you can just add the package definition in your manifest.scm or config.scm or home.scm
<alextee2>snape, i already fixed it thanks anw
<alextee2>is there a way to update an existing package to a newer version in a channel?
<alextee2>like i want to package a newer glib, and make packages use that
<alextee2>maybe it's not a good idea though
<snape>alextee2: yes you can just add a package with glib-2.xx as it's done in gnu/packages/base.scm
<snape>in gnu/packages/glib.scm sorry
<snape>was looking at glibc
<alextee2>snape, thanks
<snape>you don't have to rewrite the whole package though, you can just inherit from it
<alextee2>meh it needs newer meson now....
<alextee2>does anyone have a package for meson 1.2?
<alextee2>guix search meson doesn't show 1.2
<alextee2>meson and glib are really outdated.. like more than 5 months
<alextee2>actually nvm i was trying to build latest glib. building a glib version from 3 months ago works with the meson that guix has
<snape>alextee2: there is a "gnome-team" branch
<snape>which could be your channel
<alextee2>snape, is gnome-team an official guix branch? how can i switch to it?
<alextee2>or how can i make my channel depend on it?
<snape>I believe it's meant to be merged with master when it's ready
<alextee2>^ found the answers, trying guix pull now from that branch
<alextee2>does guix provide substitutes for packages in that branch?
<snape>alextee2: it should:
<alextee2>snape, thanks. is there a package list for gnome-team?
<snape>disclaimer: I know nothing about gnome, maybe ask lilyp
<snape>as for the list, I'd just grep the repo
<snape>or use 'guix search'
<f6MB>Hi! I'm unable to search for Extensions:Dictionary (Get more dictionaries online...) on a fresh LibreOffice installation, what I'm missing. Thanks in advance!
<jpoiret>huh, let's try out glibc 2.39 for a bit, although the removal of libcrypt will prove a bit annoying: we'll need to add explicit libxcrypt dependencies everywhere
<apteryx>any tip to debug a package graph cycle? the memory is progressively gobbled up; there's no output
<voroskoi>could somebody take a look at ?
<apteryx>jpoiret: sounds doable; there aren't that many libgcrypt references
<jpoiret>apteryx: nono, not libgcrypt but libcrypt
<apteryx>ah, they'd be hidden so we can't know in advance.
<jpoiret>i'm looking into it (and cleaning up some stuff at the same time)
<jpoiret>it's just a matter of adding a new dep though so shouldn't be too bad
<apteryx>i've hit another cycle (this time package graph, not module graph) while attempting to finish my pkgconf-as-pkg-config thing
<jpoiret>there's just some backports to gcc's bundled libsanitizer that are annoying
<apteryx>it's annoying, I don't understand it
<jpoiret>package graph should be debuggable using guix graph no?
<apteryx>I'm not sure where (which package) to start looking at
<apteryx>also, since pkg-config is syntax, I think I probably have to clear the .go files keeping a ref to it between attempts
<apteryx>that tricked me into thinking it was working twice already
<apteryx>even rebuilt part of the world to find out at the end the original pkg-config was the one used still, uhm
<apteryx>syntax is a bit of a pain to work with
<alextee2>is there a one-liner command to view this log? View build log at '/var/log/guix/drvs/8b/2qw98jjxsi369h9y8m2dmd9x3d15dk-gtk4-git-4.99-1.5483821.drv.gz'
<alextee2>^ gzip -d /var/log/guix/drvs/8b/2qw98jjxsi369h9y8m2dmd9x3d15dk-gtk4-git-4.99-1.5483821.drv.gz --stdout | less
<jpoiret>alextee2: zless
<jpoiret>if you use emacs it'll transparently unzip it as well
<jpoiret>i used to use zless but since i'm now using eat in emacs it's way easier to just open it there as well
<alextee2>jpoiret, thx
<alextee2>does the meson builder not support finding cmake dependencies?
<alextee2>this file exists: /gnu/store/vfwlizy5wpj0mddw2yw7rjcwcshr1y8d-yyjson-0.8.0/lib/cmake/yyjson/yyjson-config.cmake
<alextee2>but when I set yyjson as an input meson can't find it: Run-time dependency yyjson found: NO (tried pkgconfig and cmake)
<alextee2>aha, I had to add cmake to native-inputs
<jpoiret>well, building coreutils rn
<alextee2>made a channel for zrythm-git!
<jpoiret>wow, it supports guile scripting
<alextee2>that's kinda deprecated/experimental... will remove it eventually
<alextee2>guix pull after adding my channel doesn't work
<alextee2>I get |builder for `/gnu/store/3l3842a470882ncaavhjm4ibfnpwb0d6-zrythm-packages.drv' failed to produce output path `/gnu/store/4ac5kipd0ilh99iqriq62v77prqjijr5-zrythm-packages'
<alextee2>the log says: (exception misc-error (value #f) (value "no code for module ~S") (value ((packages zrythm))) (value #f))
<alextee2>but when I tested this channel locally with `guix build -L . zrythm-git` it built fine
<alextee2>any ideas?
<alextee2>-(define-module (zrythm packages zrythm)
<alextee2>+(define-module (packages zrythm)
<alextee2>^ this fixed it!
<apteryx>alextee2: it's sad that guile scripting is scheduled to be removed! was it hard to maintain?
<alextee2>apteryx, it's crashy/problematic in my builds and doesn't work on windows. and it's hard to find info online about integrating it with C
<alextee2>will probably use gobject instead
<alextee2>i have a channel that depends on gnome-team, and when i do `guix pull` it tries to build with glib from guix master branch instead of gnome-team
<alextee2>how can i tell my packages to use the dependencies from gnome-team?
<apteryx>guile 3 still doesn't build/run on windows? I thought someone had worked on that
<alextee2>apteryx, someone has been "working on it" for several years now and libguile still doesn't build/run on windows
<apteryx>alextee2: you can't use gnome-team as a replacement for master; it'll only extend it
<dthompson>yeah guile on windows needs work
<dthompson>sure wish whatever issues there were could get sorted out
<dthompson>there are*
<alextee2>apteryx, i see, so my only choice is to tell users of my channel to switch their main guix channel to the gnome-team branch...
<apteryx>but gnome-team should be merged soonish
<apteryx>if you are already testing it, perhaps mentioning how it works for your will give confidence that it's about ready :-)
<dthompson>someone should see if they can get an nlnet grant or something to fix guile on windows
<alextee2>apteryx, I see, thanks
<apteryx>sad to see windows support is still deemed important in 2024
<apteryx>jpoiret: got some hint about the cycle; it happens when switching pkg-conf to pkgconf
<ieure>alextee2, I have `C-c C-x C-f` bound to find-file-at-point in Emacs, so that plus RET with point on any filename in the shell opens it. Very handy for this kind of stuff.
<alextee2>ACTION uses vim (i know i know)
<ieure>Use whatever works for you. :)
<alextee2>does guix support gtk4 with wayland?
<PotentialUser-97>Hi there! Can I run x-org apps run in "guix system containers"? With some work should I even be able to run the apps headlessly with xvfb?
<apteryx>it has gtk4, I believe gtk4 supports wayland
<apteryx>is it safe to use gexps dynamically? e.g. like on line 157 here:
<adamnr>ping - If someone is able to restart the system that archives the IRC logs for #hurd and #guix
<apteryx>perhaps rekado ^
<jpoiret>janneke: you wouldn't be happy if you had to update hurd and gnumach am i right?
<jpoiret>I'm testing out whether switching to glibc 2.39 on c-u is feasible, but that glibc is too new for our kernel headers
<alextee2>any ideas why this happens? |builder for `/gnu/store/1dyg03nlf22s17hlqvnqxqsis43zcq96-nonguix.drv' failed to produce output path `/gnu/store/56lgifr6dnakx9d87x0hx2ivzpl0byvk-nonguix'
<alextee2>(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (linux-libre-6.7)) (value #f))
<alextee2>i simply added nonguix to my channels
<alextee2>(and ran guix pull)
<jpoiret>please take this to their own channel, this is not due to guix
<f1refly>how much space is recommended for a guix root partition? My current installation has 100GiB for / and I'm constantly running out of space. Wondering if I'm doing something wrong or if this is expected
<jpoiret>depends on what you use Guix for
<f1refly>general desktop computing
<alextee2>jpoiret, i see thanks
<jpoiret>f1refly: as long as you don't build a lot of guix packages yourself, you usually shouldn't use that much space
<f1refly>jpoiret: When running guix gc I can get down to maybe 80GiB if I'm lucky
<f1refly>I trim my generations to about a week
<jpoiret>can you `guix size "$(readlink -f ~/.guix-profile)"`?
<jpoiret>same for /run/current-system/profile
<f1refly>my user profile is 26466.2MiB in size, my system profile 6011.4MiB
<anthk_>run guix gc as a normal user
<f1refly>I do that as well anthk_, also trimming down to a week
<anthk_>would a guix install with bcachefs/btrfs save up space with cow?
<dariqq>hmm do you gc user and system profiles?
<f1refly>dariqq: yes, I use "guix gc --delete-generations=1w" with and without sudo prefixed
<hackyhacker>hello when I run guix pull I get 'the SSL certificate is invalid'. I tried installing nss-certs and setting the environment variables mentioned in the guix manual but to no avail.
<f1refly>is your system clock set to a recent date?
<hackyhacker>oh no my clock is set to something weird. I'll try fixing that and seeing if the problem goes away. Thanks!
<f6MB>Hi! I'm unable to search for Extensions:Dictionary (Menü: Get more dictionaries online...) on a fresh LibreOffice installation, is that expected? oder something I could help with? Or how does that installation menu where to save the dictionaries?
<f1refly>hackyhacker: the certs where probably invalid for the date your clock was set to, it's a common error
<dariqq>f1refly: I dont think this will gc system profiles. I do something like "sudo guix system delete-generations -d 1m" and then "guix gc ... " will delete them from the store.
<f1refly>dariqq: I believe the --delete-generations argument for guix gc means "first delete generations matching the pattern then delete", I think i read it in the manual
<dariqq>how many system profiles do you currently have available ( in /var/guix/profiles ?)
<f1refly>okay, that might be the cause
<f1refly>Just collected ~50GiB. nicee
<f1refly>thanks for the help :)
<sarg>rekado: is goggles-bot working? Logs archives miss today
<rekado>sarg: it’s the usual bug: every new month the file rotation fails. It’s a simple fix but nobody has implemented it.