<ae_chep>So firstname.lastname@example.org is in main channels, and so is email@example.com. Glib requires firstname.lastname@example.org . Does that mean we're due a glibc update?
<bdju>gentle reminder (to no one in particular) about bug #63239 which I suspect didn't hit the mailing list properly but is viewable in the web ui
<ae_chep>And then zlib also brings up conflicting entries. First entry email@example.com (prop from firstname.lastname@example.org) second entry email@example.com (prop from firstname.lastname@example.org) . I don't know how to fix this (on a foreign distro)
<lilyp>Ehm, why are you pulling in two versions of glib?
<lilyp>Note, glib != glibc – the former is a basic library for GNOME, the latter is the GNU libc.
<mfg[m]>zacchae: if you build the package with guix, then gcc should find libstdc++ and use it correctly. But yeah for binaries you need a workaround, there have been discussions about it on the ML, I think
<jgart[m]>is there a way to disable tests currently from the CLI when running guix build foo?
<GNUtoo>jpoiret: thanks a lot for the help yesterday, I finally managed to make it work with -e '(list (@@ (gnu packages commencement) gcc-final) "lib")' (I needed 2 @ else it would complain about not finding gcc-final)
<rekado>next4th: I don’t think this would help on its own. We need to generate the registry at a time when the only thing Guix knows is the *current* profile.
<next4th>well, profile hook can only build for one profile though..
<rekado>so these would be multiple steps: extend ibus to look for registries on a search path, generate an IM registry in a profile hook, extend ibus to merge multiple registries, then set search path to system and user profile.
<next4th>rekado: if i read the code of ibus right (ibusobservedpath.c), it use file_hash in addition of mtime, so it should works on guix too. only need is to merge IBUS_COMPONENT_PATH from multiple profiles.
<minima>it looks like the search engine on logs.guix.gnu.org is stuck at jan 2023? what i mean is that it doesn't seem to report any result past that time, like if it needed a nudge or something?
<juli>does anyone know why i might be getting an "error: output: unbound variable" when using `#$output' in a g-expression? there are other packages in this file using g-expressions so i know the module is imported; i see other packages in this file which use `#$ouput' in analogous positions
<juli>huh, turns out the issue is... using it inside a `#$(file-append ...)' form???
<juli>i switched it to `(string-append #$ouput ...)' but the documentation explicitly demonstrates `#$(file-append output ...)'
<old>oh my god. thanks for the person that added with-configure-flags transformation
<darosior>Hey all. I'm trying to get my Rust program to build against an older glibc in a Guix container. For now i'm simply trying with glibc-2.29. I've got a toolchain using `make-gcc-toolchain`. I'm trying to get rust to be using this toolchain using `package-with-c-toolchain`, but i keep getting an obscure scheme error when building the derivation. I may
<darosior>be misunderstanding the "label" argument of `package-with-c-toolchain` there..
<mihi>about bootstrapping: When next Guix version is released and I install it on a foreign distro, then install a package written in C without using substitutes, will it bootstrap gcc all the way from M2-Planet or will it use the gcc of my host distro? And if the former, will it download the guile seed or will it use my host guile?
<mihi>nvm, got an answer in #bootstrappable already :)
<vagrantc>mihi: using the debian packaged guix it cannot use the host guile for anything guix builds, because that is not available to guix-daemon's build environment
<vagrantc>mihi: the debian-packaged guix is basically a trust path to get to running guix stuff (e.g. you already trust debian's keys, install the debian guix, run guix pull, now (most of) your guix operations are running guix binaries for everything