IRC channel logs


back to list of logs

<rekado>sneek: later tell g_bor Mumi now serves /easy where all easy bugs are listed. It’s not yet deployed, but I’ll try to do that tomorrow.
<sneek>Got it.
<refpga>Hi, is the certbot service supposed to show up using "# herd status"? I configured it as per the guix services docs, and reconfigured system to /etc/config.scm without any errors, still herd doesn't show any service named certbot.
<wazamflaw>hello, can anyone recommend the the way to install on Guix System packages that are not yet in the guix archives? as in installing them from a tarball
<wazamflaw>for example, the rust language server package: rls
<wazamflaw>preferably in such a way that the packages could be easily uninstalled should they be added to the archives
<wazamflaw>i believe that `guix environment` could be of use in this situation?
<vagrantc>phase `check' succeeded after 2063.4 seconds ... if you skip the tests the whole package build takes 30-45 seconds
<samplet`>refpga: IIRC, the certbot service is mostly just a cron job with an NGINX configuration extension, so it makes sense that it would’t show up with “herd status”.
<leungbk>I submitted some commits directly and would like to shut down the associated patch threads that I created a couple weeks ago via email. How can I do this?
<BenKey76>The following is from near the end of the Binary Installation document.Source etc/profile to augment PATH and other relevant environment variables:# GUIX_PROFILE="`echo ~root`/.config/guix/current" ; \ source $GUIX_PROFILE/etc/profileThis is unclear. It sets environment variables for that single session and for that single user. The document says
<BenKey76>nothing about setting the necessary environment variables for future sessions.
<BenKey76>The next few sections of the manual speak of building and installing from source. Then at the beginnig of the Application Setup section, the following can be found.Packages installed via Guix will not use the locale data of the host system. Instead, you must first install one of the locale packages available with Guix and then define the
<BenKey76>GUIX_LOCPATH environment variable:$ guix install glibc-locales$ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale1. How is $HOME/.guix-profile created for user B?2. And again this sets a variable for a single session.
<leungbk>sneek test
<apteryx>for big changes which usually would go to core-updates but can't at the moment (due to core-updates being prep'd for merging into master) -- should they go in core-updates-next?
<lfam>apteryx: Yes, that is what core-updates-next is for
<lfam>A place to collect core changes when core-updates is "frozen"
<apteryx>lfam: thanks for confirming
<efraim>sneek: later tell vagrant due to bootstrap issues java is x86_64 only (re: enjarify)
<sneek>Got it.
<efraim>sneek: botsnack
<civodul>Hello Guix!
<civodul>oops, itstool segfaults while building gnumeric:
<rekado_>yup, that looks bad.
<rekado_>blocks diffoscope on core-updates.
*rekado_ is shocked by the many branch pushes and deletions on savannah
<rekado_>looks like a misconfigured git client that automatically pushed *all* local branches to Savannah.
<g_bor>hello guix!
<sneek>g_bor, you have 1 message.
<sneek>g_bor, rekado says: Mumi now serves /easy where all easy bugs are listed. It’s not yet deployed, but I’ll try to do that tomorrow.
<civodul>oh, /easy is nice
<civodul>rekado_: re branches, arggh!
<civodul>lemme remove them while i go through the guix-commits messages
<civodul>hmm i don't see them at
<civodul>have they been removed already?
<civodul>ah yes, i see there are "deleted" messages below in my inbox
<Paprika>Hi all
<Paprika>I'm used to changing the volume with amixer
<Paprika>but that doesn't seem to be available on Guix System, what's the alternative used here?
<civodul>maybe aumix?
<civodul>there's also ponymix for PulseAudio, but i've never tried it
<Paprika>Thanks, I'll try aumix
<Paprika>oh amixer is available
<Paprika>it's in the alsa-lib package
<civodul>ah, good
<jonsger>ah cnf (command-not-found) thing would be nice for guix, to find out which package contains a binary
<civodul>"guix search amixer" didn't help
<civodul>yeah yeah :-)
<nickey>hi! i've installed mcron service on (operating-system ... (services (service mcron-service-type) ...)). But crontab is always says "a cron daemon is not running"
<civodul>hi nickey
<civodul>i get "No crontab for ludo exists", which is correct
<civodul>what does "crontab --version" say?
<nickey>civodul: hi! it says "crontab (GNU Mcron) 1.1.2"
<civodul>ok, weird
<civodul>now, crontab is not the "native" interface to mcron
<civodul>the equivalent of "sudo crontab -l" would be "sudo herd schedule mcron"
<efraim>We don't have a crontab service
<civodul>yes, but mcron provides a "crontab" command
<civodul>nckx: sergei & dmitri appear to be down, could you take a look?
<nickey>"sudo crontab -l" => "No crontab for root exists."
<nickey>Ok. What is the guix-way to schedule non-root user tasks?
<roptat>hi guix!
<civodul>hey roptat!
<g_bor>hey roptat!
<civodul>nickey: it's "mcron --schedule"
<g_bor>I've sent you an invitation to comentor.
<nickey>"mcron --schedule echo" => "
<nickey>mcron: Cannot read files in your ~/.config/cron (or ~/.cron) directory."
<roptat>there's something weird with my email server or client, mails arrive out of order :/
<roptat>my client seem to show the correct date, but shows me old mail (up to 12 hours it seems, but not everything from 12 hours ago) before new ones
<g_bor>roptat: which mail client do you use?
<g_bor>I sometimes had this when I got mail from the future, and the display hid that fact.
<roptat>g_bor, I use K9 on android
<roptat>I don't have that issue with claws-mail for instance (at least it's not as visible)
<civodul>rekado_: re itstool, we're in for a rather big rebuild i'm afraid
<civodul>i'm testing the patch at
<g_bor>roptat: is there an option to sort messages by date? Is it possible that something flipped this setting?
<g_bor>I have seen some reports related to this setting changing.
<g_bor>But they are from 2014.
<roptat>no that can't be it then
<roptat>it started having this behavior a few months ago iirc
<roptat>it's starting to get annoying ^^
<efraim>roptat: on K9 I suddenly got some mails from 2016 at the top of my new mails folder. It was also right after I switched from offlineimap to mbsync
<rekado_>civodul: oof. More rebuilds :-/
<civodul>yeah, well
<civodul>it's not something we can graft
<civodul>and there's no trick we can play
<civodul>like itstool and python-libxml2 both have ~4K dependents
<rekado_>I wonder what we could do to detect these kinds of problems earlier in the future. It doesn’t fail to build; just segfaults when used. Kinda hard to anticipate.
<rekado_>little server update: we’re still waiting for the rack to get power.
<rekado_>meanwhile my colleague went on vacation, so by the time the racks are ready I’ll probably be out. My colleague will install the servers after Oct 4.
<civodul>rekado_: oh thanks for the update
<civodul>do you have findings to share on PXE?
<rekado_>no, not yet. I wanted to get the NFS stuff ready first to better test this, but then I got distracted.
<civodul>ok :-)
<rekado_>the plan is to serve the root file system over NFS, tell the kernel that it should load it from there, and see how that goes.
<civodul>that should be feasible
<civodul>g_bor: here's an idea of an Outreachy project: performance monitoring of the continuous integration service
<civodul>like we discussed at the Guix Days
<civodul>i'm not offering to write the abstract though :-)
<iyzsong>i'd like it (netboot diskless guix system) too :-)
<g_bor>civodul: do you have a mentor in mind?
<civodul>hmmm, not specifically, one of the people who discussed it at the Guix Days?
<civodul>oh, hi demotri, right in time :-)
<g_bor>hi demotri!
***ng0_ is now known as ng0
<g_bor>civodul: I am not completetly aware of all the functionalities of the Guix Data Service. Do you think that it could be useful for monitoring the ci performance?
<civodul>g_bor: it could be useful for monitoring the performance of Guix itself: since it "evaluates" package sets (like Cuirass does), it can keep track of how long it took to perform an evaluation
<civodul>and i think it already does
<civodul>but i don't think it could be useful to monitor CI performance
<civodul>for CI performance we need to measure time of push to time of trigger, time of push to time of build completion, average machine load, etc.
<demotri>civodul: Hi
<sneek>demotri, you have 1 message.
<sneek>demotri, nckx says: I'd say emacs-xyz.
<demotri>civodul: What have I missed?
<g_bor>civodul: we could use the already available zabbix monitoring, and call out to zabbix-sender to collect the metrics, once they are accumulated
<g_bor>Or we could expose a status endpoint for scraping.
<g_bor>The main question is how to create these metrics.
<demotri>civodul: And why is it just the "right time" for me?
<civodul>demotri: i was just kidding, that's because we were talking about Outreachy and the idea of submitting another project
<civodul>on CI performance monitoring
<demotri>Oh, OK. I see. A mentor is missing.
<civodul>yup :-)
*demotri needs to think about a new nickname :-)
<demotri>Chris is in for the general Guix Data Service project as a mentor?
<demotri>Never heard of zabbix, but there is already a Guix package for it.
<demotri>Is there some documentation about the data service? What exactly is on the front-page? I thought the primary idea of the data-service was to pre-evaluate patches?
<roptat>g_bor, done
<g_bor>roptat: if you think that the proposal is ok as is, then please notify me, so that I can approve it. Otherwise feel free to modify it.
*g_bor running make check
***emyles`` is now known as emyles
<roptat>g_bor, I don't think the intern would need a guix system machine, since guix system commands work outside of guix system too
<roptat>we could create virtual machines with guix for test purposes for instance
<g_bor>roptat: you are right, that could be relaxed, but it's a bit tricky to get describe what exactly needed.
<g_bor>What do you think about: a guix system machine or virtual machine. And a short description on how guix can create a guix system virtual machine provided a host with virtualization capabilities.
<g_bor>The main thing is that a guix system machine is lighter on the hardware requirements, but needs dedicated hardware. So we should provide an 'or' option here.
<g_bor>or simply:
<g_bor>a guix system machine,
<g_bor>or a machine with guix installed and capable of executing guix system vm ... commands.
<g_bor>this is of course a mathematican type, completetly precise and useless description
<refpga>Hello, after setting the service for certbot, how do I actually generate the SSL certificates using it? Or is it just for renewal twice a day at random times?
<g_bor>roptat: I believe I managed to come up with something. Please have a look at the modified version.
<roptat>g_bor, "add remarks to quations under the relevant part of text." I don't know what that means :p
<roptat>g_bor, I also changed a bit the IRC community standards description
<civodul>the python-libxml2 patch i found fixes the problem
<civodul>now i'm testing a patch where i create a crash-free itstool for use in gnumeric
<civodul>so we can avoid the 4K rebuilds
<roptat>refpga, you need to configure the certbot service to tell it what certificates you want, then it should automatically get these certificates automatically
<g_bor>roptat: ok, it should be quotations, and it reflects on the practice to write your answers inline. If you can come up with a simpler way to say that, it would be great.
<roptat>let me try
<roptat>g_bor, I think we're good
<nckx>civodul: OK.
<civodul>howdy nckx!
<g_bor>hello guix!
<nckx>civodul: Again, it's only the two ARM machines that are unresponsive… Wonder if it's ssh-daemon again. I'll see them in person tomorrow. The work-around was to disable IPv6, right?
<nckx>Hullo g_bor.
<demotri>I'm finally looking at the FreeCAD patch, but I don't know if the llvm-toolchain-6 package is right:
<demotri>Is that the way one works with LLVM: Making a union-package out of llvm + clang?
<demotri>Is that OK?
<demotri>The rest of the patch LGTM, besides small things I have corrected.
<civodul>gnumeric and diffoscope built! \o/
<civodul>nckx: i'm not sure there was a clear workaround
<civodul>demotri: the "llvm-toolchain" package works, but that's not how we do it usually, AFAICS
<civodul>instead, we simply add, say, llvm-6 and clang-6 as inputs
<civodul>which should be equivalent
<civodul>so i'd suggest doing that as well
<demotri>civodul: Thanks, that was what I thought could work.
<demotri>civodul: Last question: Is llvm-6 an input, or native-input? Thought it is just the compiler (i.e. native), but "guix gc --references /gnu/store/...freecad..." has the llvm-toolchain-6 as reference. Or is that just because of the clang-6 package?
*demotri got right now a broken plastics part on the desktop, so it's really time to push that patch :-)
<apteryx>is there a reason we should keep python-minimal to 3.5, or can it be version bumped to something recent (on core-updates-next)
<refpga>roptat:Sorry for the late reply. I've already configured the service as per the guix docs on certbot. But it mentions that certbot will run at random minute in an hour per day. I don't know when I would get the certificates, I wish there was a way to force it to generate them the first time immediately. Anyway, I have generated certs using the commandline (sudo certbot certonly), but need to renew them using the service still.
<civodul>demotri: i'm not sure, i guess you can make it "inputs"
<civodul>apteryx: core-updates-next shouldn't exist actually :-)
<civodul>as we were discussing here yesterday
<roptat>refpga, I'm not sure, but I thought it would do that immediately, and then at a random time
<refpga>Could be that I'm doing something wrong. I'll check again, thanks.
<apteryx>ah, sorry, I missed it. Should changes just be waiting for core-updates to unfreeze then? How do people know that core-updates is in a freeze?
<apteryx>or perhaps we should branch core-updates off to a new branch to for stabilization, then merge that branch in master (while core-updates remain available for its normal usage)
<demotri>civodul: Thanks, will just give it a try.
*apteryx peeks at the irc logs
<gnu_srs1>Hello again: unpacking bootstrap Guile to '/gnu/store/vi66s7rcx853cwwddbhnccsppppi8x01-guile-bootstrap-2.0'... ./bin/guile: Empty file!!
<gnu_srs1>cat /gnu/store/ echo "unpacking bootstrap Guile to '$out'..."; ... /gnu/store/yaxqsba39qdlyv3wrz04i3705l0l0kyp-xz -dc < $GUILE_TARBALL | /gnu/store/z8zria3rlr8p24kx4gk6wwlmfpyp4lhv-tar xv; extracts stuff but fails here: $out/bin/guile --version since that file is empty??
<apteryx>civodul: OK, I just read that core-updates-next was meant to be core-updates-tmp ;-)
<civodul>yeah, so we should remove it but there's a couple of commits there :-/
<apteryx>anyway, my suggestion to branch off core-updates to stabilize it still makes sense I think; it removes the chance that someone pushes a big changes there by mistake while it's being prepped for a merge to master
<apteryx>and it leaves core-updates open to buziness
<Parra>do you know any VM, docker image or ci/cd with guix installed inside? I'm getting problems just to set it up.. I would like to use it easily
<apteryx>Parra:you can generate such image using Guix itself
<Parra>but that's an endless problem
<Parra>I cannot install guix so I cannot generate guix self contained
<Parra>it's an infinite loop
<apteryx>Parra: Can't you run Guix in a VM?
<Parra>I'm trying to run it inside docker
<Parra>but I cannot get rid of certificates problem
<Parra>that's what I'm using
<Parra>after following this instructions: it keeps failing
<roptat>what kind of certificate issue?
<Parra>I'm trying to implement a package which pulls from github
<Parra>but it fails with that error
<Parra>X.509 error
<roptat>can you show us the command you want to run, and the exact error message?
<roptat>if the issue is inside the guix build environment, there's nothing an environment variable can help you with
<refpga>Parra: Did you set up the environment variables as per ?
<roptat>you could also try to check the date on the system :)
<roptat>if it's too far in the past or the future, X.509 errors can happen
<Parra>should I set them before or after installing nss-certs?
<roptat>after I think
<refpga>I have them set in .bashrc.
<roptat>well, it shouldn't matter
<Parra>that's what I thought
<Parra>I'm going to change them
<gnu_srs1>I've already replaced xz and tar with dynamically built local versions: Seem like the binary file guile is zero, but not the rest?
<gnu_srs1>The tarball file is not zero size: tar ftJv guile-static-stripped-2.0.14-i586-pc-gnu.tar.xz ./bin/guile; -r-xr-xr-x root/root 4160296 1970-01-01 01:00 ./bin/guile
<apteryx>Parra: did you install the nss-certs package in root's profile? I don't see this done in your Dockerfile
<Parra>yes, it's in another repo
<apteryx>the environment variables will not help if the data it's supposed to point to doesn't exist.
<Parra>I'm testing locally
<roptat>you mean another user?
<Parra>I mean in my pc, not in the ci/cd
<roptat>well, it should be set for whatever uses X.509 :)
<roptat>and point to somewhere where you installed nss-certs
<Parra>one second and I will push it
<gnu_srs1>Seem like the cross-built guile-2.0 is also corrupt: ./bin/guile --version: Throw without catch before boot: Aborting. Aborted
<roptat>are you trying to run this on your hurd system?
<Parra>@roptat there is, I think it needs to source the profile
<Parra>I'm going to check that now
<Parra>ah, no, that's already done
<roptat>Parra, I think the issue is that this environment is not defined for the daemon
<Parra>which one, the SSL_.. GIT_SSL.. etc?
<roptat>I mean, it's probably run in an environment where SSL* are not defined, or defined to something different
<gnu_srs1>roptat: Yes, on my Hurd system.
<roptat>gnu_srs1, so we should find why it's broken
<Parra> ok, right, after installing if I do an ls the certs arent there
<gnu_srs1>roptat: How? We already know the the cross-built xz is corrupt, And maybe tar too, And now guile-2.0.
<gnu_srs1>Cross building on a linux amd64 box takes around 2 days...
<roptat>gnu_srs1, ouch :/
<Parra>I can't find them XD
<Parra>where is the usual location of the certificates?
<Parra>I'm root
<roptat>there's no usual location
<roptat>you should install them with guix, then point the variables to their location in your profile
<roptat>when they are installed, they will be in a known location in your profile, namely etc/ssl
<roptat>so for the root user, /root/.guix-profile/etc/ssl
<demotri>Parra: You can also download the QEMU image from the homepage, if that helps.
<roptat>I think they are already installed in the binary tarball, so you only have to make the variables point to the profile (/root/.guix-profile might not exist, so /var/guix/profiles/per-user/root/guix-profile/etc/ssl)
<Parra>I'm going to try that path @roptat
<gnu_srs1>Maybe there is still a mix between guile-2.2 and -2.0: Do I need all dependant packages for guix to be 2.0-versions? For both linux, building the tarballs and hurd, using them?
<Parra>nothing in /var... neither
<Parra>how can I see where nss-certs are installed?
<gnu_srs1>On the linux box I only changed: gnu/packages/make-bootstrap.scm from guile-2.2 to 2.0.
<roptat>Parra, do you mean /var/guix doesn't exist? if it's not there, then it's simply not installed
<roptat>if /var/guix doesn't exist, then guix itself is not installed
<Parra>ok I found them
<Parra>there are thousands
<roptat>ah no, it's not part of the binary tarball
<roptat>so run the daemon, install nss-certs, set the variables and restart the daemon
<Parra>ok, let me try
<Parra>I think I got it now
<Parra>it worked man
<Parra>thanks so much
<roptat>good :)
<rekado_>gnu_srs1: it would be easier to follow if we could see your changes.
<gnu_srs1>rekado_: OK; I'll send an email to guix-devel!
<minall>Hello guix!
<quiliro>hello minall
<jlicht>hi guix
<bgardner>Good morning guix! I installed Guix System on a rack server with a default ssh configuration and it failed to start on the last reboot. No error, nothing in the logs, just a herd status of "enabled, not running, will respawn". Any suggestions on where I should start looking to find more information? herd start ssh-daemon brought it right up, so I'm puzzled.
<jlicht>bgardner: perhaps something to do with your networking? I know I've had some issues with that a long time ago, where I basically had to start ssh-daemon myself afterwards. I only had this problem once though
<nckx>bgardner: Good morning. I just complained about this bug here earlier 🙂 ‘Known’, I'm afraid, but that's about it. <>
<nckx>Disabling IPv6 seems to help but that's of course not an option everywhere.
<nckx>(The bug itself has been around for ages, or at least months.)
<bgardner>jlicht: Static networking config, so while I checked that I assumed it not guilty.
<bgardner>nckx: Reading link
<bgardner>nckx: Thanks very much! And disabling ipv6 is an option for me, I'll investigate that route.
<nckx>Good luck…
<nckx>Here's ‘our’ link to the same bug:
<bgardner>nckx: I know it's a sledgehammer solution to disable IPv6, but once installed into the rack I'd be in a pickle if I lost ssh.
<nckx>Hm, it's marked as ‘Done’, but it doesn't read like it.
<nckx>bgardner: That pickle, I am in it, and I agree.
<sirmacik>rekado_: I saw that in may you've had the problem with emacs error in magit Symbol's function definition is void. How did you solve it? (irclog doesn't show)
<jlicht>roptat: nice work on home-manager!
<roptat>jlicht, thanks
<refpga>Hi, does anybody here have experience with setting up prosody XMPP server? I want to set up SRV records as explained in but there seems no option to do that in guix docs
<refpga>is there anything like the nginx `body` function to specify an arbitrary config option for lua configs?
<refpga>Hi zacts
<zacts>hi refpga
<roptat>refpga, SRV records sounds like a DNS thing to me
<roptat>so it's handled by a DNS server, no?
<refpga>Yes, seems like it. Thanks
*civodul will have to learn how to use byzanz
<roptat>trying to pull with the guix-home-manager channel, I get this error:
<roptat>any idea?
<zacts>how is Haskell support on guix system?
<bgardner>nckx: I'm making no progress on disabling IPv6, are you aware of any documentation that I'm missing?
<nckx>bgardner: All I know of is that bug report. I haven't fixed my own system yet.
<bgardner>nckx: Gotcha. Looks like the static-networking-service code doesn't allow for 'disable', so I might be stuck. I'll bookmark the bug report and try to supply any clues I stumble upon. Thanks again.
<zacts>also, is connected to the actual guix codebase?
<zacts>or is it updated manually?
<nckx>bgardner: Don't be shy about responding to that thread yourself. Or is that not possible?
<civodul>zacts: it's updated daily
<zacts>automatically, or manually?
<bgardner>nckx: Should be possible, I'll give it a shot
<zacts>(I'm assuming the former)
***porto is now known as strawberry
<roptat>I'm still lost...
<roptat>ha I found it!
<jlicht>roptat: what did you learn?
<g_bor[m]>roptat : do you think the netlink proposal is ok now?
<roptat>jlicht, there was an unbounded variable that was named the same as a guix record-type*
<roptat>so at compiled time, the name existed, but resolved to a macro
<roptat>I don't know why guix didn't compile because of that, and why guild would let me do it though
<jlicht>doh! The issue makes sense now. Perhaps it has to do with some interaction with inferiors?
<samplet>How do I enable build output when running “guix system”?
<samplet>(Instead of the spinner with the names of the phases.)
<samplet>Oh I see. It’s the “--verbosity” flag. I think I was confused with the “--debug” flag.
<samplet>That does the trick! I was ignoring “verbosity” because I thought it was one of those build flags that make the daemon print a lot of stuff I’m not interested it. :P
<samplet>s/interested it/interested in/
<zimoun>civodul: nice this Jupyter demo! I am looking forward to have the live sound ;-)
<atw>omg that demo :O
***jonsger1 is now known as jonsger
<pkill9>guix has Festival packaged now, nice
<jlicht>is there an IRC channel for the Guix Workflow Language?
<OriansJ`>jlicht: do we need a seperate place for that?
<jlicht>that is probably the question I should have asked :P; "Is #guix the right place chats about GWL?"
<jlicht>s/place/place for/
<jlicht>I am a bit confused on how to actually *run* workflows at the moment, and I have the feeling I am missing something very essential
<civodul>like documentation? ;-)
<OriansJ`>civodul: that would be a big one indeed
<civodul>but yeah, i think it's the right place for GWL questions
***OriansJ` is now known as OriansJ
<jlicht>well, yes that too, but I actually mean something that gives me "Hello, World!" output
<jlicht>The current website explains (in a super nice way, by the way) how to make files that describe processes and workflows etc, but not how to actually run them. The naive approach of `guix workflow -r <myfile>' does not seem to do the trick
<jlicht>I simply did `guix install gwl', as I had hoped that would be enough to start playing around. Incidentally, it seems that gwl has guix as a propagated input: I had thought this leads to some hard-to-debug issues?
<civodul>jlicht: yeah, well not that terrible, but it's suboptimal
<civodul>but it may be that the "gwl" package is a bit old, no?
<civodul>i think rekado & roelj made quite a few changes lately
<civodul>dunno, you might want to check the repo
<jlicht>it seems to be the latest released version, but looking at the upstream repo it seems you are right :-)
<civodul>and i think this specific problem (guix as a dependency of gwl) is something rekado was looking into at some point
<jlicht>ah, it seems recent changes were made to the way gwl loads workflows, and I have my hello-world using a git checkout of gwl \o/
<jlicht>thanks for the advice civodul
<civodul>cool, yw!
<jlicht>Some time ago I updated biber to 2.12, which works quite well, but it seems our current biblatex packages are compatiable with biber < 2.12. Would it make sense to push a downgrade to biber, or should I rather wait until the next round of texlive updates?
<civodul>rekado_ would know better, but i'd say that if the current biber is unusable in practice, it's probably a good idea to downgrade it
<civodul>according to the principle that something that works is better than something that doesn't :-)
<jlicht>heh, okay
*civodul applies the "guix show" patch:
<civodul>no objections 'round here?
<jlicht>not on my end
<nckx>Cool new ‘logo petition’ bandwagon:
<nckx>(Not that I'm suggesting we add Guix.)
<tune>guix makes you explicitly type out the 2 or 3, which is about as future-proof as it gets
<nckx>(Although ‘support’ is ambiguous as it gets, and we don't intend on ‘supporting’ an EOL package anyway…)
<nckx>tune: I thought that was upstream's recommendation now? So other distro's again map python3 → python?
<nckx>That'll be fun come Python 4.
<tune>I know on arch at least 'python' goes to 'python3'
<civodul>hey roptat, congrats on !
<roptat>civodul, thanks :)