<acrow>I suspect it's only needed if you're building something requiring it to be in your environment. Otherwise I think it is part of base and works quietly without further ado. That's my belief. Others here are better informed.
<lfam>It's the hard-coded set of locales used by certain base services, which run with a locale of en_US.utf8
<lfam>But otherwise, it's not really that useful unless you're lucky enough to want to use one the handful of locales it includes
<lfam>I don't really know anything about GTK translations. I will say that it's 100% normal to see a huge number of warnings when using any GTK program
<lfam>I mean, maybe there is really some problem there! I don't know
<acrow>The dog has never been observed to bite me. It may be that its bite has been exaggerated by a higher level api.
<lfam>In the the upstream bug report about this warning, someone says "the en_GB Gtk language message is quite benign; what will happen is that some error messages from the Gtk library that Gramps uses might appear in US english, rather than GB english."
<lfam>I would check the source code of gramps, looking at what triggers this warning. That will help explain precisely what is missing
<lfam>I guess in our case, all translations are missing, rather than just en_GB
<lfam>It could also help to examine that Ubuntu package, to see what it actually is. It appears to be developed within Ubuntu, so I think that we'd need to pull from the source they base their package on
<lfam>I think that's expected. As the message complains that something is missing, the distribution is the entity responsible for properly distributing that thing
<acrow>I'm wondering if there might be a environment variable that the package could change to point to the information it cannot find. I also bet that the desired information is already provided by guix.
<lfam>I'm curious, are you using Guix System or Guix on another distro?
<lfam>And if you are using Guix System, are you using GNOME?
<acrow>I'm using GuixSD but with the xfce windowing environment.
<acrow>I suppose I could also simply reconfigure to use GNOME and see if the problem goes away, but I'll have to accept that as an exercise for later.
<lfam>I think you're most likely to get answers about languages and locales during the European daytime
<acrow>My machine will take it's time reconfiguring for that.
<lfam>At this time of day, I think there's a lot of USAmericans here, and we don't typically need to worry about those things
<acrow>That makes sense. I'll check in again later. Hopefully with additional insight.
<dstolfa>lfam: as a non-native english speaking slavic person i honestly never cared for native language support or support for cyrillic letters other than when i was helping friends make course materials in cyrillic...
*dstolfa finds it weird to find a non-english system and gets lost in it
<lfam>English is quite popular... and it always works on computers
<str1ngs>yeah, I'm spoiled everything defaults to en_US though I'm en_CA
<str1ngs>raghavgururajan well other then a lot of building gtk worked will at-least in the context of g-golf
<podiki[m]>wow I finally figured out why xdg-desktop-portal wasn't working!
<podiki[m]>tried so many random dbus things, even did some strace which was actually helpful....and realized the error was staring at me from the regular xdg-desktop-portal output
<podiki[m]>XDG_DESKTOP_PORTAL_DIR has to just be one directory, it does not handle mulitple
<podiki[m]>so it is a bug in our packaging that xdg-desktop-port and xdg-desktop-portal-gtk both export the variable (or really a bug in upstream, they should support multiple directories as typical for XDG_ variables)
<podiki[m]>sneek later tell raghavgururajan figured out the xdg-desktop-portal issue, I think it is both a bug with our packages (makes XDG_DESKTOP_PORTAL_DIR multiple directories) and upstream (they should support that); nothing to do with dbus in the end
<mbakke>alyssaphack: your profile only contains the packages that you eplicitly install. While a lot of programs depend on ncurses, they use the absolute /gnu/store/xxx-ncurses file name, and don't require it to be in your profile.
<mbakke>if 'st' needs 'clear' to be on PATH (say), its package definition should be patched to use /gnu/store/xxx-ncurses/bin/clear instead of assuming it is installed
<alyssaphack>by absolute ncurses file name are you referring to an input versus propagated-input?
<alyssaphack>st worked fine after I did what efraim suggested with inputrc
<alyssaphack>but if the experience is one of just installing the terminal and Ctrl+l just working then maybe st needs to be patched to refer to ncurses
<mbakke>alyssaphack: guix generally prefers to patch things to work out of the box, but "it depends"... adding a dependency on ncurses to clear the screen should be fine, adding a dependency on 'icecat' to open hyperlinks (say), maybe not...
<mbakke>bost: it seems the version of sqlparse in guix is too new (0.4.1), but mycli requires <0.4.0 :/
<bost>mbakke: what can we do about it? Where should I report it?
<mbakke>bost: if you can report it to firstname.lastname@example.org that would be great :)
<mbakke>I guess either mycli needs to be updated, or we should add a 'sqlparse-0.3' variant that it can use
<bost>mbakke: just to be sure `sqlparse<0.4.0,>=0.3.0` means less than 0.4.0 and greater than or equal to 0.3.0 right?
<mbakke>bost: as a "hail mary", you can try to 'guix package -i mycli --with-latest=mycli' to see if the latest upstream version fixes it (the bug should still be reported though) :-)
<bost>mbakke: the "hail mary" did 'mycli 1.22.2 → 1.24.1'. But that doesn't help. Now I get `The 'importlib_resources>=5.0.0' distribution was not found and is required by mycli`
<bost>mbakke: BTW what does it exactly mean? The "hail mary"?
<bost>mbakke: Anyway, my original problem was different. I installed MySQL or MariaDB but I can't connect to it. I get `ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/run/mysqld/mysqld.sock' (2)`. Ugh
<efraim>A Hail Mary pass is a very long forward pass in American football, typically made in desperation, with great difficulty of achieving a completion. Due to the small chance of success, it makes reference to the Catholic Hail Mary prayer for divine help.
<bost>I found a similar discussion about the mysql problem in the IRC logs. But that didn't help.
<slyfox>core-updates does not build substitutions for most packages, is in intended? I tried to build 'meld' today and I'm yet to finish when 18 rust binaries are to finish building: https://dpaste.com/DBMND77HA.txt
*bost trying `guix package --rollback` for real, for the first time.
<mbakke>bost: no worries, we've all been there ;) you can not modify services without running reconfigure, but it should not take ages to run! if you recently ran reconfigure, and then reconfigure after adding mysql, only a few derivations will need to be built.
<efraim>slyfox: core-updates or core-updates-frozen? There's normally nothing for core-updates, but we're actively working on core-updates-frozen and there should be a bunch of substitutes
<acrow>Reconfiguring to use the gnome desktop does not impact the incomplete GTK message produced by the gramps application.
<acrow>I think the GTK implementation looks for but does not find the locale translations on guix.
<acrow>Ubuntu users report this being fixed with the installation of language-pack-gnome-en. Looking in that package it creates/updates a /usr/share/locale-langpack directory with output from msgfmt run against the usual *.po locale descriptors. It isn't clear to me how the guix /run/current-system/locale/2.31/ structure maps into this. I don't understand the debian makefile callouts to postinst that mediate this. Nor do I see how
<acrow>/var/lib/update-notifier/user.d/language-pack-en fits in.
<acrow>A lot of machinery that obscures what is probably a very simple file creation. I think we just need to create a *.mo file from a *.po file and put it somewhere. :)
<acrow>It seems wrong that 'ls /gnu/store/*gtk+-3.24.24/share | wc -l' is 1151.
<acrow>Well that can be reduced with 'ls /gnu/store/*gtk+-3.24.24 | wc -l' to 575, but this still seems excessive.
<acrow>Better but still excessive is `ls -d /gnu/store/*gtk+-3.24.24 | wc -l`, which is 96.
<acrow>I suppose that each instance correlates to a package that is in, or was in, anyone's profile on my system but shouldn't these deduplicate on garbage collection? There ought be only one real email@example.com, right?
<acrow>I seem to be the owner of a gross conceptual error regarding guix.
<str1ngs>acrow: if it's there because of a installed packaged. it will only get GC'd if the root is deleted. aka profile generation.
<str1ngs>if you have many generations see e.g guix package --list-generations then using --delete-generations will clean those up. that's assuming you no longer want them for things like --roll-back
<acrow>I have 17 generations going back about a month. Hmmm. That is certainly part of it. Thanks.
<str1ngs>no problems also system and guix profiles will files in the store. but I wouldn't worry too much about those ones.
<str1ngs>since it's pretty useful to roll-back the system or guix
<str1ngs>acrow. it does seem to work okay despite it saying it won't work okay. I think gramps is getting senile
<acrow>Yeah. It's really quite a nice example of open software.
<acrow>Gramps has this problem with other distributions too but the fix on guix is more elusive.
<acrow>It forces me to better understand how guix works.
<acrow>And -- again -- I'm trying to come to grips with why the store gets so many different instances of the single package firstname.lastname@example.org.
<acrow>It seems odd that the same source produces so many different outcomes in the store over less than a month's time. Although maybe it's just that the build systems are evolving just that fast. That's my best guess right now.
<mfg>one thing that might change the package are grafts that get applied?
<acrow>Ok, so running 'gramps -v' always returns LANG=en_US.UTF-8 on my foreign distro, just like guixSD, but forcing LANG=C and running gramps does not produce the warning about incomplete gtk installation. Wow.
<mfg>i fon't know much about gtk or gettext but what is GTK_GETTEXT_DOMAIN?
<acrow>but I suppose that makes sense, guix is running on an LTS Ubuntu instance.
<acrow>How could I find out which store instance of gtk+ is supporting my particular gramps instance. I can work out the store for gramps but how to get which stores gramps then accesses? I've got 96 versions of email@example.com on my system, so which one should be getting scrutinized?
<slyfox>does 'guix size gramps' show the relevant info?
<slyfox>\o/ 'guix graph ...' is probably a more precise way to do it including the whole dependency chain. But i'm not sure which --type= you need to pass to it :)
<acrow>FWIW, gramps will open cleanly after setting LC_ALL="C". The software is looking for en_US translations but translations for en, en_GB, and en_CA are the only ones in the gtk+ share/locale mappings.
<acrow>Nothing to do with guix, per-se. Guix is great.
<Fare>Is there the equivalent of cachix.org for guix?
<iskarian>no problem :) I think I've accidentally become one of the more knowledgeable people on packaging Go in Guix, despite never writing a Go program in my life, haha
<podiki[m]>I started heading that way with Haskell, just trying to get some things to compile (most I've done is copy and paste my xmonad config together)
<iskarian>Fare, if you're talking about building Guix packages on another machine, you can either setup the Guix daemon to offload to another machine, or you can setup that machine as a local substitute server, depending on your needs
<zeroter>Strange thing, no user shell spawned by login is using the keymap specified in system config, it works if I spawn a shell manually e.g. "bash" as a user (in linux tty)
<zeroter>is it a problem with guix, or maybe with I need to do some additional configuration?
<lfam>sneek: later tell efraim: I reverted one of your commits, tracked as <https://bugs.gnu.org/50071>. It was "syncthing: Prepare for cross-compiling". I can try to re-do your change without breaking the outputs splitting if you tell me how to test for what you were trying to achieve in your patch