<mark_weaver>karhunguixi: see the recent post entitled "Buck collection" on the guix-devel ML <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>lfam: (actually, I do have some hybrid boxes, but I haven't upgraded them yet :) <lfam>The archives missed September 30 <mark_weaver>karhunguixi: indeed, the GNU mail servers seem to be having problems now, perhaps another spam attack. the post is available on gmane though. <lfam>While I am testing methods of getting a working locale system, can anyone recommend a way to "refresh" the system w.r.t. the locales. Tired of rebooting... ***lfam_ is now known as lfam
<lfam>When linking /gnu/store/...locale... to a gcroot, and then linking the gcroot to /run/current-system/locale: abort *(&#%*( <lfam>Does that mean that some of my guix packages are still linked against glibc-2.21? <lfam>Perhaps my description of those links reads backwards. <mark_weaver>lfam: you can always enable things working again by doing: export LC_ALL=C <mark_weaver>and then, can you show me the output of "readlink /run/current-system/locale" and "readlink /var/guix/gcroots/locale" ? <lfam>I know. But some of my files rely on UTF-8. For example, an ASCII only music library is not so much fun ;) <mark_weaver>the LC_ALL=C is only temporary, so that you can investigate the symlinks and fix them. <lfam>Okay, I am going to have to redo the symlinks and reboot <mark_weaver>iirc, if a program aborts with the locale assertion failure, that indicates that the program was linked with glibc-2.21 but the locales are for glibc2.22 <mark_weaver>so yeah, you need to upgrade your user profiles so that everything is linked with glibc 2.22 <lfam>Yes, I am updating everything now <lfam>What's weird is that `guix package` aborted but I could have sworn that I had already `guix pull`ed. That's why I asked about the difference between `pull` and `package -u guix` earlier <mark_weaver>lfam: those symlinks look good to me. I think the only remaining piece is to upgrade your profiles. <mark_weaver>lfam: I think you probably have to do both "guix pull" and "guix package -u guix" to avoid the problem. <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>Oh I see your last message now <lfam>Hm, `guix package -u guix` returns immediately, as if nothing to do. `guix package -u` and `guix pull` abort. <lfam>Even with LC_ALL=C set on the command line, I had to unlink /run/current-system/locale to successfully `guix pull` <mark_weaver>lfam: the 'guix-daemon' that you're currently running is probably linked against glibc-2.21 <mark_weaver>this incompatibility between glibc-2.21 and glibc-2.22 locales is very unfortunate. we are looking into how to avoid this from happening again. <lfam>Yes, I've been following it on the ML. I'm rooting for the glibc patch. But it would be a while before that gets into Debian. <lfam>codemac: Any progress getting go to work in guix? <paroneayea>ACTION catching up on guix / guile things from the boston python usergroup at microsoft ;) <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 <goglosh>--no-substitutes downloads nothing afaik <goglosh>I've used it when I don't have a network, as long as there is a version already available in the store <lfam>Can anyone reach oberhumer.com (the source for lzo which is required to build guix)? I can't get through. <davexunit>ACTION tries to wrestle locales into submission <davexunit>I have things mostly working, but 'guix environment' fails... <davexunit>I'm reading through the mailing list stuff on the subject <civodul>with guix environment, you should use -E /path/to/.guix-profile/bin/bash <davexunit>it's interesting, because the guix-provided bash has a LOCPATH set to /gnu/store/ksmf9sh2gcbry0rz0zm4diqgsiysjzgg-glibc-utf8-locales-2.22/lib/locale <civodul>i hadn't realized how much painful that would be <davexunit>I worry that people will try out Guix, perhaps after paroneayea's talk, and immediately hit this wall. <civodul>yeah, that's why we need to get the fixes pushed early <davexunit>yeah, I saw your patches. whatever works to fix it would be great. <davexunit>I'm going to set my users shell to the bash I'm installing into my profile <civodul>mark_weaver: re locales, your suggestion is nice, but easier said than done :-( <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> <mark_weaver>(I don't think the existence of GUIX_LOCPATH should inhibit the use of LOCPATH) <mark_weaver>or maybe LOCPATH should just take precedence over GUIX_LOCPATH, since GUIX_LOCPATH essentially plays the role of the "system" LOCPATH. <civodul>or at worst we can copy/paste things... <mark_weaver>hmm, I guess we should consider the case where Guix is run on top of NixOS, in which case LOCPATH will be set to the Nix locales and GUIX_LOCPATH will be set to the Guix locales. <mark_weaver>so maybe GUIX_LOCPATH should take precedence after all <mark_weaver>bah, two different scenarios point to two different policies <mark_weaver>actually, we should also consider the case where the user is just running GuixSD, but has a mixture of software from before we make this change, and after. <mark_weaver>so the older software will consult LOCPATH and not add a version suffix <mark_weaver>so if we move the locales into a version subdirectory, the older software (current master) won't find them. <mark_weaver>I think we'll have to envision a transition where the locales need to be in both places <mark_weaver>this will require some careful thought to avoid running into more problems <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>it also might be good to install locales in both places during a transition period <civodul>mark_weaver: looking in both places wouldn't work: you could end up loading the wrong thing <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 <civodul>Nix doesn't rely on LOCPATH; i think they hard-code locales like we did before <civodul>if we have GUIX_LOCPATH support the versioned scheme, then we could have both 2.22 and 2.23 locales in the same profile (let's assume) and each libc would pick the right one <civodul>meanwhile, the Debian binaries would ignore GUIX_LOCPATH <civodul>now, i would ignore LOCPATH when GUIX_LOCPATH is set <civodul>well, actually that's what the previous patch did <mark_weaver>that might be the right thing, but it's not right in all cases. maybe it can't be helped. <mark_weaver>but GUIX_LOCPATH seems to play the role of a system locale directory, and users might expect LOCPATH to override the system locale directory. <civodul>yeah the recipe for 'tre' relies on LOCPATH <mark_weaver>suppose for now that glibc 2.23 has another incompatible change to locales <mark_weaver>I wonder if there's a reasonable way for us to automatically ensure that both 2.22 and 2.23 locales are available during a transition period. <mark_weaver>maybe "automatic" is too much. maybe the thing is to explicitly keep installing older locales for some period of time <civodul>it'd be easy to have them both in /run/current-system/locale <civodul>however, given that there can be only one package with a given name in the profile, that's harder <civodul>we'd have to rename glibc-utf8-locales to glibc-utf8-locales-old or something <mark_weaver>civodul: I can have both gnupg-1.4 and gnupg-2.0 is the same profile, no? <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. <civodul>i would definitely unconditionally install both system-wide <civodul>well, glibc-utf8-locales could contain both lib/locale/{2.21,2.22} <mark_weaver>well, nothing that uses glibc-2.21 will look in the versioned directory <mark_weaver>the glibc-2.21 locales need to go in the main directory, I think. <mark_weaver>and yet now, our current master looks for 2.22 locales in the unversioned directory, unfortunately. <davexunit>to somewhat solve my issues, I've unset LOCPATH and installed bash and the coreutils to my user profile. <davexunit>that seems to prevent most of the breakage I was seeing before. <davexunit>what a terrible situation to be in. how has nix not been bitten by this? <mark_weaver>okay, so, binaries we need to consider: (1) traditional distro binaries, that expect glibc-2.21 (or earlier) locales and will be broken by LOCPATH pointing to newer ones. <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>is there a way to support all of these binaries together? <davexunit>paroneayea: oh hey you're in town already? cool! <mark_weaver>supporting case (1) requires either (a) LOCPATH is unset, or (b) LOCPATH points to a directory with 2.21 locales <mark_weaver>cases (4) and (5) could be supported by setting GUIX_LOCPATH with versioned directories <civodul>mark_weaver: (1) and (2) are the same category <mark_weaver>I don't know to support case (3) together with case (1/2) <civodul>mark_weaver: (3) is the first category i would sacrifice if it's needed <civodul>i mean we already know that (3) and (1/2) are exclusive <paroneayea>ACTION leaves you all to this locale thing and goes to shower :) <jgay> HexChat: 2.10.1 ** OS: Linux 3.16.0-4-686-pae i686 ** Distro: Debian 8.2 ** CPU: 2 x AMD Athlon(tm) II P340 Dual-Core Processor (AuthenticAMD) @ 2.20GHz ** RAM: Physical: 3.7GiB, 22.0% free ** Disk: Total: 450.9GiB, 35.6% free ** VGA: Advanced Micro Devices, Inc. [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250] ** Sound: HDA-Intel - HDA ATI SB1: HDA-Intel - HDA ATI HDMI29: ThinkPad EC <civodul>mark_weaver: i'm trying out a patch where GUIX_LOCPATH is versioned and LOCPATH is not; GUIX_LOCPATH has precedence over LOCPATH but both are taken into account <jgay>- ThinkPad Console Audio Control ** Ethernet: Realtek Semiconductor Co., Ltd. CIe Gigabit Ethernet ** Uptime: 23h 50m 35s ** <davexunit>jgay: accidental copy/paste? fortunately looks like no sensitive information was shared by mistake. <civodul>mark_weaver: then i'll let some time pass so we can think through the consequences :-) <civodul>but ideally we should start building this week-end <mark_weaver>it might be possible to sacrifice case 2 instead of case 3. <mark_weaver>basically by saying that LOCPATH should no longer be set <mark_weaver>and installing glibc-2.22 locales in /run/current-system/locale (without versioned directory) <civodul>so getting back to yesterday's patch? <mark_weaver>no, I still think the new one you're testing now makes sense. <jgay>davexunit, no, it was sent by my client. I am trying out hexchat and didn't understand what selecting Window -> Send System Info would do <civodul>i think the new one has the advantage that one can still use LOCPATH if really needed <mark_weaver>and use it the same way it's traditionally used on other systems. <davexunit>jgay: oh. heh, that's an interesting feature. ;) <civodul>it's a patch we could submit for discussion on libc-alpha <jgay>and I'm not sure why it sent it only to this channel <mark_weaver>but basically we'd no longer set it in dot files, and advise users to remove the LOCPATH setting in favor of GUIX_LOCPATH <mark_weaver>so, cases (1) and (3) would be handled by the lack of LOCPATH setting. they'd each look in hardcoded directories. <mark_weaver>and cases 4 and 5 would be handled by looking in GUIX_LOCPATH with versioned subdirectories <jgay>it seems to grab info from lspci but not lsusb <mark_weaver>so, in the locale directory, "2.22" could be a symlink to "." <mark_weaver>and after some transition period, we could stop supporting case (3) and make "2.22" a real directory <mark_weaver>although I suppose it might be worth considering another alternative approach: abandon case (3), and put glibc-2.21 locales in the top-level locale directory instead. <mark_weaver>that would mean another awkward transition from (3) to (4), but might make things a bit nicer for people installing from the 0.8.3 USB installer and making the (2) -> (4) transition. <mark_weaver>I guess I'm still leaning toward abandoning case (2) to ease the (3) to (4) transition. <civodul>case (1/2) means every other distro out there, so we have to support it <mark_weaver>it's possible to abandon case (2) while supporting case (1), so they're really not the same case after all. <mark_weaver>that's what happens if we install glibc-2.22 locales in /run/current-system/locale and leave LOCPATH unset. <mark_weaver>(and make /run/current-system/locale/2.22 a symlink to ".") <mark_weaver>to abandon case (3) and support case (2), we need to install glibc-2.21 locales in /run/current-system/locale and glibc-2.22 locales in /run/current-system/locale/2.22 <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. <mark_weaver>rekado: yes, if we did that, we'd have to include all locales, unconditionally, which is a lot of data. <mark_weaver>and I guess that would impact things like the initrd <paroneayea>but I might have just bumped into a good direction for pushing guix adoption <karhunguixi>ACTION activates the secret surveillance equipment in paroneayea's home <paroneayea>good to see super smart, moderately well known people convinced :) <davexunit>paroneayea: I told Georgia that I would volunteer a bit during the user freedom summit, but I'll have time to talk <davexunit>paroneayea: gotta run, but it will be cool to see you and mark and whoever else tomorrow! very excited. <karhunguixi>say you want to install the package providing the dig command, but don't know that it's provided by bind-utils; how would you go about finding which package to install? <davexunit>karhunguixi: we do not have a way to determine that. <davexunit>we've discussed it before, but it's not exactly an easy problem <karhunguixi>maybe a package recipe could have a list of commands it provides <goglosh>I'm going to try to make a package, see if it works <goglosh>though, the download is from github, and I don't know where to get the binary tarbal <bavier>if there's a tarball on github, that's preferable <goglosh>'once a package definition is in place..." <goglosh>what I have is a cmus.scm file describing the package, now I don't know what to do and the manual is kind of ambiguous at this <bavier>goglosh: have you read section 6.5 "Package Modules"? <bavier>so GUIX_PACKAGE_PATH, or put the file in gnu/packages if you're working from a git clone <goglosh>that was probably the only section I didn't read :P