<the_tubular>I really want to learn more about scheme and just found this out <str1ngs>hello, raghavgururajan what tests were failing for you? <acrow>I wonder if the presence of the glibc-utf8-locales package could cause the warnings from other packages regarding missing GTK-translation. <acrow>Probably better to leave it out of the profile though unless it's needed. <str1ngs>acrow: glibc-utf8-loales never worked for me I've always had to use the full glibc-locales <str1ngs>though not sure if that will help you. <lfam>glibc-utf8-locales is basically just for test suites. It only contains a handful of capriciously chosen locales <lfam>glibc-locales is the full package <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 <acrow>Maybe my expectations are out of line. <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>Or maybe we already have this thing <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. <lfam>XFCE is based on GTK, so that's a plus <lfam>You know, regarding bugs in our GTK packaging <acrow>Maybe gramps reaches out for a gnome feature it ought not. <lfam>I'm thinking of something like that acrow. Or maybe our XFCE needs work <lfam>If it were my bug, I'd check what that Ubuntu language pack package is based on <lfam>Then you can check if we package that thing <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>all my systems were always in english *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 <podiki[m]>went all hacker with strace, just to find out --verbose output actually told me what I wanted <podiki[m]>still, I blame the program for just listing the load directory variable, but not any "fail to load portal" or similar message <lfam>Strace vs error messages... you have to do what works for you :) <podiki[m]>somehow more noise helped? sometimes we just gotta see the same thing a few different ways ***bsturmfels is now known as sturm
***sturm is now known as bsturmfels
<bricewge>I've updated git to 2.33, “guix refresh“ informs me 229 would need to be rebuild because of it, this seems really low <bricewge>Could this still by pushed to master? Or should it go into staging or the like? <str1ngs>bricewge git is a command not a library so that actually surprisingly high. <str1ngs>unless git is used for git sources. but I thought guile-git was used via libgit2 <bricewge>Indeed, I forgot Guix is using libgit2 internally <str1ngs>though that does not help answer your question sorry. maybe someone else knows if this needs to be staged first. <bricewge>No I think it answer it, I was worrying about “guix refresh“ missing some internal parts of Guix depending on git <danialbehzadi[m]>Should I make a new patch from current master or a patch on top of my older patch? <danialbehzadi[m]>* I submitted a patch to update a package, which is not merged into Guix yet. <danialbehzadi[m]>Should I make a new patch from current master or a patch on top of my older patch? <str1ngs>DigitalKiwi ah I stopped using archlinux years ago. mainly debian based and guix now a days. <KittyOwO[m]>Anyone here use Gajim for XMPP? I notice there is a gajim-omemo package but it doesn't seem to do anything when I install it? <bricewge>efraim: Hum, "guix refresh" doesn't lookup inheriting packages? <bricewge>Anyway, I trashed my Guix install again, so if someone want to update "git" instead of me, they are welcome <bricewge>danialbehzadi: You can write a new version of the patch to update the package to it's last release <bricewge>Kitty OwO: I'm of using it. But did you install gajim in the same profile its plugin? <KittyOwO[m]>bricewge: I had it built/installed as root on the config.scm file <bricewge>Can you find the plugin file from the aforementioned environment variable? <KittyOwO[m]>my brain is kinda mush from a lot of troubleshooting and configuring things today, how can I check this? this feels quite obvious but brain mush lol <bricewge>Something like “tree "$(echo $GAJIM_PLUGIN_PATH)"” <atka>install ncurses for "clear" to work <alyssaphack>so just do `guix install ncurses` for my user profile? <alyssaphack>why is ncurses not included by default with a desktop install template? <atka>I can't speak as to why, but I prefer it that way <atka>are you using right ctrl vs left ctrl? <alyssaphack>is it mentioned anywhere in the manual that users will run into this issue? <leoprikler>what terminal are you using, it works in gnome-terminal at least? <atka>both ctrl+l work for me in tty on a minimal system <alyssaphack>leoprikler: but how come ctrl+l also fails for me in a tty without an X session running? <efraim>I added this to my .inputrc: Control-l: clear-screen <alyssaphack>So, I guess it was an issue of the feature not being set in my inputrc <the_tubular>alyssaphack, ncurses is install by default, but it won't be on your profile by default <alyssaphack>do you happen to know where in the codebase I can read about that? <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 <alyssaphack>does upstream guix prefer st users to install ncurses to be able to do Ctrl+L or should that be patched to just work out of the box? <the_tubular>Sorry alyssaphack, didn't see your mesage, but as mbakke said, guix by default only gives you the profile you explicaly says you want <the_tubular>The reason is that you can specify a newer or older version of X program but still have the same program serve as a dependency for another program, or just another user <the_tubular>I'd suggest you check out a guix talk, it is way better explained that I will <bost>Hi. I installed `mycli` and when I try to run it I get `pkg_resources.DistributionNotFound: The 'sqlparse<0.4.0,>=0.3.0' distribution was not found and is required by mycli` <bost>I guess that's a missing dependency, right? <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 bug-guix@gnu.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. <mbakke>bost: right! you can try adding '--with-latest=python-importlib-resources' to upgrade that too :-) <mbakke>bost: installing a package won't start any services, to use MySQL or MariaDB on Guix you need to add '(service mysql-service-type)' to the services section of your operating-system config. <bost>efraim mbakke: "hail mary" what a name LOL :) <bost>'--with-latest=python-importlib-resources' actually downgraded 'mycli 1.24.1 → 1.22.2'. <bost>sorry for lame questions I'm a guix newbie <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 <efraim>* unless you ran 'guix gc' in between <mbakke>bost: you need 'guix install mycli --with-latest=mycli --with-latest=python-importlib-resources' to get the latest versions of both <slyfox>efraim: core-updates (i'd like to bump a libffi there :) <efraim>the idea is to freeze what's there and hammer it into a workable state while still allowing patches to core-updates <mbakke>slyfox: indeed, we only build the "full" package set on branches that are to be merged soon, in order to save build farm power. <efraim>libffi should be fine, I thought it was a bit of a landmine but I see on core-updates it's only the 2 patches added <bost>I'm running guix in a VM using qemu, on an older machine. That's why it's slow, I'd say. <bost>`guix install mycli --with-latest=mycli --with-latest=python-importlib-resources` leads to 'The 'importlib_resources>=5.0.0' distribution was not found and is required by mycli'. <slyfox>aha, that makes sense. i guess i'm just very unlucky that a package I'd like to test in 'core-updates' pulls in rust. <mbakke>slyfox: why does libffi pull in rust? <mbakke>slyfox: you can test the update on 'core-updates-frozen' to benefit from rust substitutes :) <slyfox>In my case 'meld' pulls in rust (via some glib/gnome depends) <slyfox>I hoped for cuirass repo, but looks like it's not there <mbakke>slyfox: it is set through the web UI <bost>mbakke: FYI `guix system reconfigure ...` took me ~14 minutes. Including the mistake "oh run it with sudo". That's definitely not fast. Hmm. ***sneek_ is now known as sneek
***hugotty` is now known as hugotty
<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 gtk+@3.24.24, 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 the issue you have with gramps is the dialog about locales? <acrow>I'm surprised that gtk+@3.24.24 is regenerated so often with different hash outcomes. I would expect it to be the same. <str1ngs> VISUAL=emacsclient EDITOR=emacsclient guix edit gramps sh: nano: command not found <acrow>Yes, that warning has sent me down this path. Though I can really find no fault with the package aside from the message. <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 gtk+@3.24.24. <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>Ahh -- I hadn't thought of that. <mfg>i'm also not sure about it, but it's at least plausible :D <acrow>That and the change rate of all the package's dependencies. gtk+ depends on 24 packages. I think a few of them seem to get pretty frequently updated. <str1ngs>acrow LANG=C gramps . should fix this yes? <acrow>No, I still get the same warning message. <str1ngs>though that's just hiding the problem <str1ngs>acrow: gramps -v has en_US for LANG? <str1ngs>acrow: it should be one line `LANG=en_US gramps` from shell <acrow>No, the output from gramps -v is 'LANG : en_US.UTF-8 <acrow>Ok, so what is see (and I think it's odd) is that I get the same reported value for LANG from 'gramps -v' as well as 'LANG=en gramps -v'. <acrow>My shell environment has LANG=en_US.utf8. Which is subtly different. Hmm. <str1ngs>I get LANG : en_US.UTF-8 despite exporting LANG=C even . though I don't get the dialog with LANG=C gramps <acrow>The package appears to be ignoring the local environment. <str1ngs>gramps -v though could be doing something wrong. I defiantly export LANG=C and it still shows en_US <acrow>Isn't LANGUAGE supposed to be the en_US.utf8 while LANG is supposed to be simply en? They may be hardcoded to incorrect generic values. Does that seem right? <str1ngs>I think en_US is some fallback with gramps <acrow>No -- I still get the warning and gramps -v still reports en_US.UTF-8. Very weird. <str1ngs>acrow you have glibc-locales in your profile? <acrow>I had glibc-locales-utf8 until yesterday when I removed it. It made no difference. <acrow>I'm beginning to think this is more peculiar to gramps than it is to guix. <mfg>acrow: are you on a foreign distro? <mfg>hmm k. on foreign distros i frequently run into locale problems... but not on guix system <acrow>I do have another machine where I can check it on a foreign distro though. Give me a minute or two. <str1ngs>what's strange is if I remove glibc-locales from my profile the dialog popup goes away. but then I get C locales warnings logs <str1ngs>I'm using foreign distro right now BTW <str1ngs>on guix system is glibc-locales used by default or do you need to explicitly add it to the system declaration? <mfg>it's part of %base-packages i think :D <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? <mfg>here is the check that produces the error message <acrow>However, running gramps on the foreign disto always generates an additional error that I don't see on guixSD, 'failed to load canberra-gtk-module'. More fun. <mfg>canberra is a theme, isn't it? <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 gtk+@3.24.24 on my system, so which one should be getting scrutinized? <slyfox>does 'guix size gramps' show the relevant info? <acrow>slyfox: beautifully! Thanks. <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. <iskarian>I've got module mode working for go-build-system (though it removes the ability to reuse build artifacts) <iskarian>and I've got a go-1.17 package coming down soon as well <str1ngs>acrow: I don't think it build en_US since it's probably the default. i.e on ubuntu 20.04 there is no en_US files in /usr/share/locale/ installed by gramps <jackhill>thoughts on where to start with guix deploy: error: program `/gnu/store/3lig4b2i1qaisg9yx8nbl0xp8hgh40a7-guix-1.0.1-15.0984481/bin/guix' failed with exit code 1 ? <podiki[m]>iskarian: nice! you had the new godbus package too? (I'll be using that for a go package I need to submit, darkman, which helps run things to switch to darkmode) <iskarian>I actually noticed it needed fixing after looking at darkman with you ;) <podiki[m]>ah right, couldn't remember who I was discussing with <podiki[m]>that ended up being why darkman wasn't compiling <podiki[m]>I haven't figured out why geoclue isn't giving me a location, but that's a separate matter, and one that's not a big deal since it is on a desktop <podiki[m]>I should check and submit darkman with a note it needs the godbus-dbus update <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 <bricewge>lfam: Did my last push produced all those failed build? <lfam>bricewge: I'm on a train (unreliable internet) <lfam>I want to help but just warning you I might disappear <bricewge>I pushed a git update, and the impact should have be <300 packages <lfam>Apparently 555 builds failed, which is for multiple architectures <lfam>So, it could be up to ~300 * $number-of-arches <lfam>Did you try building any of these new failures locally? <lfam>The build logs indicate some weird problem with the CI. I don't have a hypothesis of how it could be affected by Git <lfam>And Git updates are fine for master <lfam>I definitely can't try building anything right now because I just GCed and my bandwidth on the train is slow <bricewge>Yes the only error message I could find is "cannot build missing derivation [...]" <lfam>I would try to get in touch with mathieu othacehe to ask if they made any changes on ci.guix.gnu.org <lfam>Or, just email <guix-sysadmin@gnu.org> in addition to guix-devel <lfam>Digging in, on other arches, the failure was caused by dependencies of Git failing <lfam>And those failures were caused by connection failures within the build farm, according to the handful of logs I'm looking at <lfam>So, I don't think it's related to your commit. It would still be helpful if you started a discussion about this <bricewge>I've send an email and I'm still building the synapse package <Fare>can a substitute server be a static http server? Then I could put the packages on gitlab or something. <bricewge>gitolite and synapse build correctly on my machine <bricewge>So I guess the failing build are not related to my recent commits <bricewge>Nevermid, you aren't trying to extend it here, but to modify it <bricewge>But the service take a file-like not a list <ruffni>i pretty much copy/pasted what i found in the docs <bricewge>The service being pam-limits-service-type, not pam-limits-service which is a wrapper around it <ruffni>so i wrap the (pam-limits-service ) s-exp into a g-exp creating a file? <bricewge>AFAIU this service type take a file-like containing a plain limits.conf contents <iskarian>Has anyone else noticed that --keep-going doesn't always work? <iskarian>I haven't yet pinned down the conditions... <ruffni>bricewge: this looks promising! but isn't this pretty much exactly what pam-limits-service does (the next block in the file)? <ruffni>(pam-limits-service) is a shortcut for the whole service creation. <ruffni>i think i got it! thank you, bricewge <ruffni>but how do i get this s-exp together with the modify-services block? is there an analogon to package modify-phases replace? or do i just cons the service to %desktop-services? <ruffni>nvm, i got it! though the docs are a bit confusing imho <iskarian>bricewge, I just sent a reply regarding the failed builds (it looks like something might be triggering #48574) <iskarian>(that something being a lot of rebuilds being triggered at once by the git update) <iskarian>if I have a package X, which disables tests ("#:tests? #f"), can I restore the usual behavior of #:tests? in a package inheriting from x?