<mark_weaver>lfam: well, I'm not doing this myself, because my own boxes are GuixSD. however, one option would be to make /var/guix/gcroots/locale a symlink to /gnu/store/*-glibc-locales* and then /run/current-system/locale a symlink to /var/guix/gcroots/locale
<civodul>mark_weaver: could you review the glibc/locale patches i just sent while i sleep? :-)
<mark_weaver>"guix pull" updates almost everything that matters, but there's still the main "guix" program that gets run before it jumps into the new updated code.
<mark_weaver>so, even if you run "guix pull", if you haven't yet run "guix package -u" then the old "guix" fails with the locale assertion failure even before it jumps into the updated code from "guix pull".
<lfam>Does `guix package --no-substitutes -u package-name` download all the sources it needs at the beginning? I'm rebuilding guix and I'm on a metered network. I'd like to disconnect if it won't interrupt the build
<lfam>Currently it seems that gcc is building the various dependencies
<mark_weaver>civodul: yeah, I can see that it's more difficult :-/
<mark_weaver>the approach I would take is to have a helper, used by both __newlocale and setlocale, that consults both the LOCPATH and GUIX_LOCPATH variables and creates a combined string <LOCPATH>:<GUIX_LOCPATH_WITH_VERSIONS_ADDED>
<rekado>I need some help from people familiar with Python. I have a package that when built with python-build-system only produces an Egg archive. There are no other files, although the docs say there should be.
<rekado>Is this something specific to our build system?
<mark_weaver>civodul: another option, possibly better, would be to keep the version-adding logic in l10nflist.c, but have it search in both <DIR>/2.22 and <DIR> for each component <DIR> in LOCPATH
<mark_weaver>well, I think we need to consider the general case where we have a mixture of binaries linked with various C libraries. In particular, consider a complex case of both Nix and Guix packages on top of a Debian system, where the Guix packages include a mixture of software linked with glibc-2.21 (without versioned LOCPATH), glibc-2.22 (without versioned LOCPATH), glibc-2.22 (with the patch we'll push soon), glibc-2.23 (with the patch we'll
<mark_weaver>push soon), assuming for now that glibc-2.23 will have another incompatible change.
<mark_weaver>I wonder if we can come up with a reasonable solution that would make such a mixture "just work"
<mark_weaver>enabling the Debian binaries to work means avoiding setting LOCPATH to a glibc-2.22 locale dir
<mark_weaver>hmm, I thought I had both installed at one point, but I guess I'm misremembering.
<mark_weaver>at first thought, it would be great if somehow profile generation would automatically detect which glibc versions are used in the software in the profile, and then ensure that locales are available for all of those versions.
<mark_weaver>but actually, that's not sufficient, because of the split between system profile and user profile, and the fact that on GuixSD the system profile usually contains the locales and yet the system profile almost always uses only a single glibc version.
<mark_weaver>the variation of glibc versions will typically happen in the user profiles, which the system profiles can't see.
<mark_weaver>so, I come back to the idea of simply installing multiple versions of locale data, unconditionally, during some transition period.
<civodul>you mean via the glibc-*-locales packages no?
<mark_weaver>and perhaps we should consider this a transition period right now, and install glibc-2.21 locales unconditionally for some time.
<mark_weaver>(3) Guix binaries linked with glibc-2.22 in current master (no GUIX_LOCPATH support)
<mark_weaver>(4) Guix binaries linked with glibc-2.22 with the new support we're contemplating.
<paroneayea>davexunit: civodul: I ran into someone last night, *not related* to my talk at the boston python hackathon who said "oh Guix? I tried that just last week.. I couldn't get it to work because of some locale thing though"
<mark_weaver>(5) Guix binaries linked with glibc-2.23 with the new support (assuming for the moment that 2.23 is incompatible with 2.22 locales)
<mark_weaver>the advantage to abandoning case (2) is that, after this recent painful transition, people will have probably already purged all of their binaries in case (2).
<mark_weaver>and it would ease the transition from (3) to (4), because they wouldn't have to purge the binaries in case (3).
<mark_weaver>on the other hand, Guix 0.8.3 and our USB installer is still in case (2), and that installer will set things up to set LOCPATH
<mark_weaver>and that will be relevant between the time that we merge (4) into master and the next Guix release.
<mark_weaver>I guess I would lean toward abandoning case (2) and release very soon after the next merge.
<rekado>what's the case against hardcoded locale paths pointing at the locale data belonging to the appropriate glibc item in the store?
<rekado>is it just that we want to avoid having to have *all* locales installed even if the user is satisfied with a subset?
<paroneayea>davexunit: btw, I need to write it down, but I've thought a bit more about a guix services (or services extension we could add) for "mutable data helper" for those users who want help having their databases migrated upon upgrades and backed up before hand, etc
<davexunit>paroneayea: yes, I think the new service API will allow for such a thing
<davexunit>I would definitely want database backups and such to be automated by guix services.