IRC channel logs


back to list of logs

<the_tubular>Anyone tryed : ?
<the_tubular>I really want to learn more about scheme and just found this out
<acrow>Looks nice.
<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>That would be no. Fail.
<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
<acrow>That makes sense. The odd thing is that changes to the distribution appear to be able to make the problem go away. See:
<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
<sneek>Got it.
<lfam>Nice debugging work!
<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>Hey Guix!
<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
<efraim>There's also git-minimal
<danialbehzadi[m]>I submitted a patch to update a package, which is merged into Guix yet.
<danialbehzadi[m]>Today the original package got an update again.
<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]>Today the original package got an update again.
<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?
<abrenon>hello guix
<KittyOwO[m]>hello uwu
<abrenon>: )
<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?
<bricewge>gajim is using the GAJIM_PLUGIN_PATH environment to locate its plugins
<KittyOwO[m]>bricewge: I had it built/installed as root on the config.scm file
<KittyOwO[m]>I didn't do anything other than that
<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)"”
<alyssaphack>how can I clear my terminal in guix system?
<alyssaphack>ctrl+L and `clear` don't work
<atka>ctrl l should work
<atka>install ncurses for "clear" to work
<alyssaphack>I meant ctrl+l
<alyssaphack>it doesn't work either
<alyssaphack>so just do `guix install ncurses` for my user profile?
<atka>dunno, it should
<alyssaphack>why is ncurses not included by default with a desktop install template?
<leoprikler>why should it?
<atka>I can't speak as to why, but I prefer it that way
<alyssaphack>hmmm clear now works
<alyssaphack>but ctrl+l does not
<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?
<alyssaphack>if they don't install ncurses
<alyssaphack>I'm using st
<atka>both ctrl+l work for me in tty on a minimal system
<leoprikler>well, there you have your answer
<leoprikler>less is more
<alyssaphack>ctrl+l does not work for me in tty either
<alyssaphack>after installing ncurses
<alyssaphack>clear works in tty though
<alyssaphack>so it's probably not an st suckless terminal bug
<leoprikler>it probably is
<alyssaphack>leoprikler: but how come ctrl+l also fails for me in a tty without an X session running?
<alyssaphack>st is not present in that environment
<efraim>I added this to my .inputrc: Control-l: clear-screen
<alyssaphack>efraim: thanks! that fixed it :)
<alyssaphack>So, I guess it was an issue of the feature not being set in my inputrc
<alyssaphack>unless someone has a better explanation
<alyssaphack>TIL clear binary/executable comes from ncurses
<alyssaphack>Guix teaches us new things
*the_tubular doubtfull
<the_tubular>alyssaphack, ncurses is install by default, but it won't be on your profile by default
<alyssaphack>why won't it be available in my profile by default?
<alyssaphack>do you happen to know where in the codebase I can read about that?
<alyssaphack>I'd like to understand why that is so
<alyssaphack>what chapter of ?
<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>that would be easy enough
<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 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: that's 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>here's what I found for hail mary:
<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.
<bost>efraim: Oh Lord :)
<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 :)
<mbakke>heheh :)
<bost>'--with-latest=python-importlib-resources' actually downgraded 'mycli 1.24.1 → 1.22.2'.
<bost>mbakke: ah and that's my next problem. How to modify a service without running `guix system reconfigure`? Since that takes ages to run. I read the 'System Services' paragraph from the and I found there `(define %my-services ...)` snippet, but I don't know how to actually run it?!?
<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:
*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 :)
<slyfox>If I read correctly core-updates-frozen builds all packages, while core-updates builds only core. Is mismatch expected?
<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>and rust depends on libffi
<slyfox>out of my curiosity what does devine those package sets and branctes that runs?
<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
<abrenon>hello again guix
***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>keep files*
<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>that does not seem right haha
<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>strange that works for me
<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
<str1ngs>that's correct
<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>other way round I think
<str1ngs>acrow what about LANG= gramps
<str1ngs>that works for me as well.
<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.
<str1ngs>I'd use glibc-locales
<mfg>acrow: are you on a foreign distro?
<acrow>No, I'm running guixSD.
<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>No idea.
<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?
<str1ngs>slyfox: think that should work.
<abrenon>bye !
<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>hello guix :)
<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>podiki[m], I'm not sure what you mean? I submitted patches for updating godbus at and if that's what you mean
<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
<podiki[m]>(thanks again for that help!)
<Fare>Is there the equivalent of 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
<podiki[m]>Fare: may be helpful for what you mean:
<iskarian>I don't know the details well but and might be good places to start
<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 <>. 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
<sneek>Will do.
<bricewge>lfam: Did my last push produced all those failed build?
<bricewge> Isn't even accecible
<lfam>bricewge: I'm on a train (unreliable internet)
<bricewge>I can't find a usefull log from some failed build
<bricewge>Ok, I'll keep looking around then
<lfam>This is online:
<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
<bricewge>But there is 555 failed build
<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
<bricewge>No, I'll try
<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
<lfam>Or, just email <> in addition to guix-devel
<bricewge>Will do
<lfam>I'm seeing that the new git only built for x86_64:
<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
<bricewge>I managed to gita which was failling on Cuirass too build
<Fare>can a substitute server be a static http server? Then I could put the packages on gitlab or something.
<Fare>or S3 buckets, etc.
<bricewge>gitolite and synapse build correctly on my machine
<bricewge>So I guess the failing build are not related to my recent commits
<JorgeTern[m]11>Hola,pueden ayudarme a empaquetar ?
<ruffni>why is my pam-limits config not showing up in limits.conf?
<bricewge>ruffni: This service isn't extendable
<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
<bricewge>Probably something like this
<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>omg, ok i see it now
<ruffni>(pam-limits-service) is a shortcut for the whole service creation.
<bricewge>Yes it is
<ruffni>i think i got it! thank you, bricewge
<bricewge>You're welcome :)
<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>ah, I meant #50040 rather
<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?