IRC channel logs
2023-07-14.log
back to list of logs
<kiwibytes>By the way, without a window manager it installed correctly! But now grub always restarts... <nckx>Any post-menu output whatsoever? <kiwibytes>nckx: I am just trying once again now, but it was always one driver whitch was already been loaded just before the reboot... <kiwibytes>I don't know, i think i also have to maybe load a non-free firmware driver for the embedded graphics. It is not as easy as i thought it would be. <kiwibytes>I have not that much experience to debug this pile of shit.^ <kiwibytes>Maybe it was "just" a bootloader problem, but GRUB alone has a lot of options and until now i haven't had such problems with it. <kiwibytes>I think it was a hardware error. "TSC 0 ADDR feb00004" "PROCESSOR 2:70f01 TIME 1689295014 SOCKET 0 APIC 0 microcode 7030106" After that there was a message "pthread_getattr_np or pthread_attr_getstack failed for main thread" ... AND then ... "Couldn't read /proc/stat" ... The last message i saw was udevd[1431]: no sender credential received, message ignored <ChocolettePalett>I have an issue with LibreOffice (likely caused by how minimalistic my environment is): firstly it was shutting down due to lack of "GSettings desktop schemas", so I installed both "gsettings-desktop-schemas" and it's "-next" variant after failing to run it run it again. Though now it fails because LibreOffice can't find "org.gtk.Settings.FileChooser" setting schema. <ChocolettePalett>To be honest, I am lost and have no idea about what to do because this problem doesn't seem to be mentioned on guix-help mailing archive. Did anyone have a similar problem or does anyone know how to resolve it? <zamfofex>ChocolettePalett: Perhaps try installing GTK+ too. <mirai>ChocolettePalett: I'd open an issue for this <mirai>it doesn't look right that you can install a non-working LO <mirai>it should pull in whatever it needs to at least work <ChocolettePalett>I guess I can do it tomorrow if nobody does it quicker (I have never contributed to OpenSource—only complained—so it will took me some time to figure out what to do) <rekado>uncharacteristically only the aarch64 nodes are building stuff. <vagrantc>there is only so much stuff that can work simultaneously in the universe <ecraven>is there a way to say "I'm going to install a bunch of stuff, then run some commands, then I want to remove all of that again"? <ChocolettePalett>Yes, you can write a manifest, install packages from it, and them I guess you can --roll-back <ecraven>use case: run some tests. I want to install a bunch of Schemes, then run tests, then uninstall them (but only the ones I hadn't installed before) ;) <ChocolettePalett>Oh, or you might want to use "guix shell" or create another profile, that would be even better I guess <ecraven>how do I show all files that a package installs? for example, s7 ;) <vagrantc>"guix shell" is definitely the way to go if you want to "uninstall" things immediately after running something <vagrantc>that is essentially exactly the use-case ... it creates a one-off environment with the desired packages available and can run an interactive shell or arbitrary commands <vagrantc>although to actually delete them from the filesystem after the fact, you would also need to run guix gc ... <vagrantc>but they are only ephemerally "installed" in the environment inside guix shell <ecraven>that's fine ;) thanks, just checking out which Schemes already exist in guix and which I'll need to create derivations for. also, racket segfaults, but not when run under gdb :D is there a central place to report a bug about this? I'm on arch linux, just did guix install racket, then running racket segfaults. <vagrantc>sounds worth reporting to bug-guix@gnu.org <ecraven>if I do guix install racket, and cups is a dependency for that, cups will *not* be installed in my profile, right? only what I directly installed? <ecraven>I'm trying to write a simple package (running nasm then gcc to link) for Bones (http://www.call-with-current-continuation.org/bones/), and it fails. |builder for `/gnu/store/y0x90n0zr0x2r480q08vmm4452v8zqrb-bones-8.drv' failed with exit code 1 how can I tell guix to show me more details about *how* it fails? <ecraven>(arguments `(#:builder (begin (invoke "nasm" "-f elf64 bones-x86_64-linux.s -o bones.o")))) <ecraven>how do I find a simple example of `trivial-build-system'? <ecraven>is the scheme code of all the derivations somewhere on my system? <geri>replace ,name with "script", didn't notice <ecraven>is there a way to tell invoke to ignore errors? <ngz>ecraven: Use system* instead? <ecraven>how do I print a message from my trivial-build-system builder? just (format #t "doing this now") doesn't show up <lilyp>ecraven: try (format #t "doing this now\n") <lilyp>the newline usually helps flush the pipe :) <pjals>don't you mean (display "doing the thing") (newline)? :^) <pjals>and (force-output) flushes the pipe <ecraven>(format #t "Running nasm\n") (force-output) :D <pjals>(display "a") (newline) is more common in guile, that should be used instead <pjals>since you're not using formatting here <ecraven>this is just for debugging, when everything works, I'll remove it <ecraven>how *do* people create guix packages? just write the file and call guix build repeatedly? <pjals>using (format ...) is really a bad habit <pjals>i use guix shell -KL dir/with/modules -e '(@ (module with package) package)' <pjals>and then i do guix gc -D /gnu/store/package if it built fine but i need to force rebuild it for whatever reason <pjals>-K keeps failed build directories in /tmp/ ;^) <ecraven>hm.. I think I'm in over my head here, nasm runs fine and creates bones.o, but now I need to link that with gcc... on other systems I'd run `gcc -no-pie bones.o -o bones -lrt' but I have no idea how to properly run this on guix to make it find crt1 and stuff... <pjals>cant you just do gnu-build-system? you have a sane makefile, right? <ecraven>of course not :D but I can try to add one... <jlicht>sneek: later tell rekado: Building your node patches locally rn, will reach out once it's done or borked. <rekado>jlicht: thanks. I’ve successfully built js-panmirror on guix-science with these patches. <sneek>Welcome back rekado, you have 1 message! <sneek>rekado, jlicht says: Building your node patches locally rn, will reach out once it's done or borked. <geri>how do i create a macro that takes a list of strings and returns a list of calls to another macro? :D <nckx>ecraven: <only what I directly installed?> Yes, in this case. The way random packages get directly ‘pulled into’ the current profile is through propagation, which undermines certain Guix features. The racket package doesn't propagate anything, so you're safe here. <cbaines>nckx, doesn't appear to be missing to me? <nckx>Ah, the lzip one exists. <nckx>Hmm, last night it was zstd. <cbaines>right, I removed some "cached" zstd nars from bayfront to free up space, but this turned out to cause lots of problems <cbaines>I still need to change the caching concept in the nar-herder to match that of Guix, which is when you serve a narinfo, you make a best effort attempt to continue to serve all the mentioned nars until the narinfo TTL expires <cbaines>nckx, recent versions of Guix should try to fetch the lzip nar if the zstd one can't be fetched, and removing the cached narinfos will work around this <cbaines>in other news, ./pre-inst-env guix weather --system=i586-gnu kills my computer for recent revisions of Guix <nckx>cbaines: Mystery solved, I thought both substitute servers were append-only. Thanks. <cbaines>nckx, bordeaux is currently, at least a bit moreso than ci, but for zstd nars, I want to try and just store them for the most used nars, rather than lots/all of the nars <nckx>My nginx cache suffers from the same problem, I ended up setting a trivial TTL for narinfos (some minutes) to work around it. <cbaines>hmm, I'm still not sure where this hurd problem is :/ <janneke>jpoiret: were you planning to push hurd-team? <jlicht>cbaines: run it under strace? Or does it really freeze/reboot your machine? <cbaines>jlicht, it just takes up all the memory, I'm trying to bisect <jlicht>cbaines: for which particular package? I can try to repro here, after $CURRENT_THING is done <cbaines>jlicht, I'm testing with hello for i586-gnu <cbaines>I think the first broken commit is 999a6ac0cfd9339e138007ed9e4e544a55e92e3e <zamfofex>cbaines: I’ve had a similar thing happen while packaging things. In my cases, it usually came down to a circular dependency between packages. <cbaines>that commit switched mig to git-fetch rather than url-fetch, maybe that introduced a circular dependency <zamfofex>I’d have imagined the extra dependencies on autoconf and automake are the issue. <cbaines>I tried commenting those out, and it still didn't work <cbaines>there is a comment that says git-fetch can't be used, so I'm pretty sure it's that <cbaines>OK, revert of the mig update pushed, and I've also pushed a quick workaround for #64609 <jlicht>cbaines: can confirm what you found <bienjensu>Hi, I'm trying to build TrenchBroom but I need to tell vcpkg using an environment variable to use system binaries instead of trying to build them itself. How would I set an environment variable in a package declaration? <bienjensu>I tried putting it in `configure-flags`, but its not a cmake option obviously. <jpoiret>janneke: you mean rebasing? Yes I did mean to do that at some point <nckx>bienjensu: If an environment variable truly is the way, then #:phases (modify-phases %standard-phases (add-before 'configure 'use-system-binaries (lambda _ (setenv "FOO" "bar"))) …) ; is the way. <bienjensu>nckx: Thanks, vcpkg still can't find curl though, despite it being in `native-inputs`. Not sure what the problem is. <nckx>When can't it find curl? During build? Then you'll have to peek at the build system scripts to see how they are buggy, and likely ignoring/clobbering $PATH. <nckx>So at least that's not buggy. <bienjensu>I'm looking for where that script is called from <elevenkb>Hey y'all's has there been a discussion on improving the interactive development experience? <pjals>microsoft? cmake? sounds about right <janneke>jpoiret: ah, i assumed you already rebased and pushed the bottom; but i can do that too <nckx>bienjensu: I'd add an ‘echo $PATH;’ (in a quick & dirty substitute* phase) to bootstrap.sh just to see what's going on, and if I'm up the right tree. It might even give you something to grep for. <mirai>ecraven: forget that 'trivial-build-system' exists <mirai>use gnu-build-system and delete/replace the phases you don't need instead, it'll save you a lot of headaches <lilyp>actually use copy-build-system if you just need to copy files <jlicht>jpoiret: your update to mig was reverted, as it gave some issues for guix weather on master <lissobone>I am trying to define a package for GNU ACM. <lissobone>./../dis/dis/dis.h:26:10: fatal error: rpc/types.h: No such file or directory <pjals>a library, probably: guix search rpc <pjals>im not sure since you didnt specify if its \<xyz\> or "xyz" <lissobone>I am aware that it's likely something external. <pjals>it might be a package, but the include paths may be wrong <pjals>you can just patch it and put it into the (patches) field in the (origin) <pjals>of course, the program that your trying to package, not the library <pjals>(i know this from experience with trying to package ancient programs related to the nintendo wii) <lissobone>There are lots of rpc implementations for python, rust and go. What if it's just not there? <pjals>doesnt seem to exist, you might need to package it yourself <pjals>look around in the requirements sections <Mari[m]>hello i'm trying to build the latest xwayland from source and i get this error <Mari[m]>../source/meson.build:182:4: ERROR: Neither a subproject directory nor a libxcvt.wrap file was found. <pjals>put libxcvt into the native-inputs <Mari[m]>guix build xorg-server-xwayland --with-source=xorg-server-xwayland=./xwayland-23.1.2 <pjals>doing something as ambitious as updating xwayland would probably require you to create a new package (using inheritance) <Mari[m]>well i guess i'm going back to xorg or downgrading hyprland <Mari[m]>idk how to downgrade packages either lol <nckx>lissobone: It's in libtirpc, but under /include/tirpc/rpc/... <Mari[m]>does guix have some kind of dev channel where i can get the latest version of xwayland? <nckx>Used to be glibc but it was removed quite some time ago. <pjals>why do you need latest xwayland? <nckx>If an update has been submitted it would be as a patch on issues.guix.gnu.org. <pjals>i just use sway and everything works fine <Mari[m]>pjals: hyprland needs the newest xwayland <lissobone>/include/tirpc/rpc? Hmm. I can actually change the source code for it to point there, but that's not really effective. <pjals>idk, doing sed -i 's#<rpc/#<tirpc/rpc#g' on the source directory sounds pretty simple <nckx>lissobone: I did not look at the build system, but setting (string-append "CPPFLAGS=-I" #$(this-package-input "libtirpc") "/include/tirpc") in #:configure-flags or so is usually about the rightest way. <nckx>I.e. modify the search path, non the search string. <pjals>oh wow, why did i not think of that! im so stupid! <pjals>time to go back into editing my dotfiles <nckx>You're not stupid. There are plenty of... something packages and build systems that require patching! I just hope this GNU package doesn't. <nckx>ACTION edits pjals' dotfiles while they're not looking. <pjals>hey! where'd you get access to my computer! <nckx>The Guix backdo—er, sorry, have to go. <geri>ACTION generates everyone's dotfiles with guix <podiki[m]>any updates on branch merging? or in the case of mesa-updates I was thinking to just cherry pick the 2 commits but not sure how/if there is interaction with the tex updates branch <nckx>No, wait, I'm clearly drunk or on mobile, never mind. <podiki[m]>is the tex-team-next branch going to cause builds for everything/lots that use tex for documentation? <ncd>GUIIIIIIIIIIIIIIIIIIIIIIIX <ncd>I'm a fool. I know nothing. However, I feel like I'm missing something. $ guix shell tmux tor weechat; [env] $ tmux; After this, weechat nor tor are found as commands. <lissobone>I've got a problem too, but let's take a look at yours first. <lissobone>I believe this runs an isolated environment. <lissobone>What did you do after executing tmux in the environment? <ncd>Ah, yes, sorry. I merely type "tor" or "weechat" after the tmux bar comes up, and that's when I'm told there is no such command found. <ncd>I can do the same thing with something like "$ guix shell tmux nmap" -> "tmux" -> "nmap" and get the same result. <ncd>That's what I'm wondering, but I'd be surprised that tmux can manage that. <lissobone>What if it affects environment variables somehow? <ncd>I'll be right back; clobbering this to rejoin <Guest28>\guix system: error: cannot close compressed log file (gzip error = -1) what does that mean? <ncd>Also, I have another issue. On occasion, my guix system goes to sleep. I think someone mentioned that my graphical environment is to blame--test <nckx>(Or whatever your guix-daemon's $TMPDIR is.) <ncd>Sorry about the "test"--the system went to sleep, and that meant that weechat, in guix shell, was lost when I came back up, but I used reptyr in a different guix shell to get it back temporarily. <ncd>This is fun, but not what I intended. <Guest28>nckx: Hmm, I did guix gc and now it works. Normally if the disk is full I get a warning that the disk is full. <nckx>If your /tmp is on / (not a separate tmpfs mount), that would explain it. Guix's 'low space' warning is just a guess, it doesn't use AI to estimate how much space you'll really need. <nckx>Building a huge image in one go could easily fool it. <podiki[m]>ngz: you are shepherding the tex-team-next branch? do the changes affect a lot of non-texlive packages (e.g. due to documentation building)? <ngz>podiki[m]: it seems so. There are around 4k rebuilds per architecture, but only around 900 TeX Live packages. <podiki[m]>ok, wondering if it will need a lot of rebuilds on mesa-updates. i guess i could locally rebase and see what I get <ngz>I was hoping to merge the branch yesterday, but I noticed some change on master branch introduced a full rebuild. <ngz>I rebased, and I'm now waiting for QA to catch up. <ngz>So, in short, the branch is not expected to change anymore, so rebasing on top of it could give you accurate numbers of rebuilds. <podiki[m]>i guess for purposes of rebuilds will need to merge tex branch into mesa-updates? i'm not worried about breakage so much as getting our substitute coverage ready <podiki[m]>mesa-updates is just 2 commits directly to mesa, so easy enough to handle <ngz>podiki[m]: I don't think the order matters. But, yes, waiting for a good coverage is the longest part of it. <podiki[m]>i guess i could do the merge into mesa-updates so it can start building, and then maybe cleanest to just cherry pick the mesa updates to master when we are ready? <podiki[m]>i don't see the need for the actual merge commits (seems messy for mesa-updates since it is so little) <mirai>apteryx: I don't think its going to be easy to get fstrim-service-type in %base-services <podiki[m]>:( just tried to push some commits for Pierre but i lost the author when going from my local branch to master <mirai>there's no easy way to “add some-service-type but only if this isn't hurd” <podiki[m]>copyright line was added at least; anything else i can do after the fact? <mfg[m]>does someone know the minimum amount of packages necessary to use lualatex in guix? <cbaines>ngz, do you know what change led to the full rebuild? I guess it's possible that something changed on master to make that happen, but only if the changes on tex-team-next used something that it wasn't using before <podiki[m]>i think I noticed some grafts locally (not on tex branch) for something related to cups? could that be it? <ngz>cbaines: Unfortunately, I don't know what happened. I added a few TeX Live packages just before the merge, but nothing core. So it surprised me. <ngz>mfg[m]: Technically, you only need texlive-bin. <ngz>mfg[m]: But I think once the TeX Live update is done, you can simply install texlive-collection-luatex. <mfg[m]>so i will just have to wait a bit and in the meantime use the full texlive package <cbaines>it might be worth trying to change that comment back locally, and see if you get outputs matching what QA has built <ngz>cbaines: Yes, I reworded a comment. Do you mean this would trigger rebuilds? <Guest9331>hello I'm new to declarative system configuration and wonder (without any troll) what are the pros and cons of guix over nixos (number of packages available put aside) I could not found any resource and the matter. <cbaines>ngz, I think it can, since it seems like the build system files are in the store verbatim, rather than being read/written as an sexp <ngz>That was an innocent comment rewording ;( <Guest9331>hello I'm new to declarative system configuration and wonder (without any troll) what are the pros and cons of guix over nixos (number of packages available put aside). <Guest9331>and nevermind I did a bit of research of found what I was looking for! <geri>Guest7289: guix has better user interfaces for both programmers and users (i.e. language & cli) <ngz>cbaines: Do you know why packages reported by QA are back to step 1, with everything as unknown? I didn't touch anything. <geri>Guest9331: that was to you :D <cbaines>ngz, I think that's because of the change to the comment in texlive-build-system.scm that we discussed above <cbaines>ngz, I've tried changing the comment back and then I see local derivations matching what's already been built <ngz>No, it cannot be. This change happened 32 hours ago, and the build farm had started rebuilding stuff already. More packages were built like 5 hours ago. <cbaines>ngz, maybe CI has built some stuff, but I don't think the bordeaux build farm has yet, and thus QA doesn't know anything about the build status of packages <podiki[m]>i guess "applying" changes in a cherry pick drops author info? <ngz>cbaines: I'm pretty sure numbers were different a sort while ago. I'm feeling really dumb whenever is use this tool =/ <ngz>(see, when I use this tool, I cannot type properly anymore!) <cbaines>which is a full rebuild as you put it <cbaines>which is why QA when from showing quite a few things built, to now pretty much nothing built, as it's looking at 118811f0b6ce20776bdd51ecbc3049c4a50c97a9 <cbaines>maybe the time lag between pushing to a branch and QA updating has caused some confusion here, I'm not quite sure if this is displayed well <ngz>Yet, this change happened 32 hours ago. I understand some delay is necessary for QA to switch HEAD, but this switch happened just now? <cbaines>ngz, I think QA would have updated sometime yesterday afternoon/evening <ngz>I mean: yesterday I saw this "everything unknown" state, then numbers changed, then I see this everything unknown state again. I am puzzled. <ngz>Of course, I changed nothing in the meantime. <cbaines>hmm, what do you mean by "then numbers changed"? I'd expect it to switch to everything unknown yesterday, then remain that way <ngz>Not at all. A few hours ago, more packages were being reported as built, and dispatched throughout the various categories (failure, block, etc). <ngz>IOW, there were less packages in an unknown state. <cbaines>not sure what would cause that, I think what I'm seeing QA show now is representative though <ngz>Fair enough. I give up on this "hiccup". So, now I have two options: either I reinstate the old comment again and wait 24 hours for the build process to catch up, or I don't touch anything anymore, and wait ?? hours for the build process to catch up. :) <cbaines>ngz, from what I can see locally, changing the comment back is definately the way to go <ncd>I've returned with another quandary. Inside of `guix shell tmux`, tmux loads just fine, but outside of that (I've used `guix package -i tmux`), I get an error about the locale/lang var. <jpoiret>just had a look at the reverts, I wonder why generating the package cache ended up running the arguments thunk of rumpkernel <jpoiret>and the mig error is quite mysterious <jpoiret>I don't think we can build anything hurd related with that older mig now though <ngz>cbaines: Well, this is embarrassing: I tried to re-instate the old comment, but I cannot push anymore to Guix repository. "make authenticate" fails with error "In procedure verify: gcrypt: incorrect length". Of course, it never happened on any of the previous iterations. <ncd>Anyone in here ever use ii for irc? <TheSkylarverncc[>hey, i booted the guix system 1.4.0 iso from a dvd and did guix pull, but it seems using the (gnu services xorg) module doesn't provide screen-locker-configuration <pjals>this may be a stupid question but is the configuration in any gexps? <jpoiret>TheSkylarverncc[: screen-locker-configuration has been recently removed <jpoiret>you should follow the latest manual instead of the one automatically started on the installation medium <jpoiret>oh, I completely misread what you were saying <jpoiret>what was removed was screen-locker-service iirc <jpoiret>yeah sorry. How are you using (gnu services xorg) <jpoiret>does `command -v guix` point to the new guix or the system-wide one <jpoiret>then you should probably run `hash guix` <jpoiret>and check that it now points to the guix-pulled guix <jpoiret>hmm, maybe you might need to load its profile manually via a `export GUIX_PROFILE=~/.guix/config/current; . $GUIX_PROFILE/etc/profile` <bjc>is ‘poetry’ building atm? <TheSkylarverncc[>i sourced .config/guix/current/etc/profile but i had to manually use the pulled guix's path <apteryx>mirai: yeah; and I don't think it's necessary anymore <jpoiret>So checking if a package is supported actually leads to all of the transitive dependencies being turned into bags, meaning their arguments thunk is run. Pretty unexpected <jpoiret>cbaines: oh I think I know why there was an issue with mig and native building <jpoiret>we'd need to push some additional changes to make the bootstrap mig use the tarballs <bjc>why do we have (gnu build-system python) *and* (gnu build python-build-system)? <jpoiret>since native building was not working for any of the packages i didn't bother doing this <jpoiret>bjc: the former define the build-system object, and the second is the support code for the builder <jpoiret>one's run from the guix side, the other from the builder side <jpoiret>that's the same for all build systmes <bjc>the naming is unfortunate =) <jpoiret>well, the naming is consistent at least <jpoiret>if you see anything under a build/ subdir, that's code that's supposed to run build-side <jpoiret>it can also run on the host, but it needing to run on the builder means that we have to keep it separate <jpoiret>otherwise it would pull in a bunch of stuff that cannot run on the builder <bjc>yeah, it makes sense, it's just confusing <bjc>i also don't have any better suggestions <ncd>Is herd the first of its kind to offer the "configuration" command? <mirai>ncd: its arbitrary, you can make up whatever command you want <ncd>Are you saying it's merely a convention for the service to allow a command that will return the config file? <ncd>How common was it before guix? <bjc>it's not at all. most systems have little use for it, though, because config files are located in standard places. guix makes tracking them down a lot harder, so the ‘configuration’ action is uniquely helpful <ncd>I'm still working through HTDP, and then after that I'll fully read through the guix manual. I look forward to understanding it. <ncd>Though I think I'll have to get through something more based on guile to really grok the meat. <bjc>i'm very confused at how ‘poetry’ has *ever* built. it's throwing “misc-error #f "no setup.py found" () #f” during the ‘build’ phase <bjc>but afaict, it's never had a ‘setup.py’, and the ‘python-build-system’ it uses hasn't changed in a long time. that particular check is years old <janneke>jpoiret: yeah, i'm puzzled too -- what did we miss? <janneke>possbily we need more patches from hurd-team -- those in commencement... <janneke>...but civodul's "./pre-inst-env guix build --target=i586-pc-gnu guile-static-stripped-tarball" doesn't seem build on hurd-team either <jpoiret>janneke: yes, we need the commencement packages <jpoiret>i'm looking at merging the rest of the native build stuff this week-end <jpoiret>janneke: i think i know why both problems happened. The first workaround is fine, but reverting the mig update is quite annoying <jpoiret>once we have the proper commencement mig it should go away <nckx>Annoying but right or annoying and wrong? <jpoiret>it's right from the data service's POV, but it breaks all cross-compilation for Hurd <jpoiret>ie. you just can't build a system iso now <jpoiret>I guess I can try to commit it again tomorrow along with the required changes to make it work, but it'll require reviewing some more patches <nckx>Oh, I thought it was ‘objectively wrong’, as in causing an infinite loop. <nckx>If it's just a pragmatic thing, I understand your annoyment :) <jpoiret>it is objectively wrong if you're building natively yes, but it was broken in other ways before <jpoiret>ie. you couldn't natively build anything anyways, so I didn't really think of checking whether native build operations would be impacted <bjc>uh oh. using time-machine to build an old poetry has me downloading rust crates <bjc>there goes my cpu for the next day <vagrantc>oooh, guix is up to 87% reproducible ... i will have to update my talk slides! <podiki[m]>python-yubikey-manager is back and working on master yay <janneke>ACTION resets hurd-team, including cherry-picked mig update at the bottom