IRC channel logs
2024-11-20.log
back to list of logs
<futurile>icepic-: in step 4 - setting yourself as a reviewer - it shows you how to usertag <bavier>vagrantc, I just pulled successfully to 1e6d1c3. <bavier>hey guix, if a python package fails the "sanity-check" phase because an ssl context doesn't validate, would installing certs into the build container fix things? Is that even possible? <bdju>may have a clue to my [still-unfixed] locale issue from the other day. if I look in /run/current-system/locale/* I only have 10 different locales to choose from, and en_SE and en_DK aren't among them. did the number of default locales on guix system change semi-recently? <bdju>I know you can make an explicit list of them but the manual says that's to save space by disabling the ones you don't list. I never did that, so I would've thought I'd have "all" of them. and I surely had more in the past. <mange>Looks like if you don't specify anything it uses %default-locale-definitions, which includes ar_DZ, en_GB, en_US, es_AR, es_ES, fr_FR, pt_BR, pt_PT, ru_RU, zh_CN as utf-8 locales. <mange>That was changed in 6228a2b8ba which was in April 2024. Even before that it didn't include en_SE or en_DK, though. <bdju>so if I want ones not included in the default I also need to specify them then I guess <mange>Yeah, but you don't have to remove the old ones to do that. The first example in "(guix) Locales" in the manual uses cons to add to the default list, rather than replace it. <PuercoPop>Is there a way to open an issue in debbugs by issue number? M-x debbugs-gnu quieres for other attributes <bdju>first attempt to copy the manual example didn't work <bdju>what does invalid field specifier mean? <bdju>don't think I'm gonna be able to figure this out. damn. <bavier>bdju, "invalid field specifier" might indicate a typo in one of a package's field names. <adanska>hi guix! im having some strange issues when trying to load a common lisp package from the repl. running `(asdf:load-system "mcclim")` spits out the following error, complaining that it cant compile due to the file system being "read-only". I havent had this issue before, so i'm wondering if im doing something wrong. https://paste.debian.net/1336100/ <mange>Hmm. I just did this and it seemed to work (or at least not crash)? guix shell --pure sbcl sbcl-mcclim -- sbcl --eval '(require :asdf)' --eval '(asdf:load-system "mcclim")' <adanska>im using the source version, `cl-mcclim` <adanska>i wonder if its because its a pure shell <adanska>yes, that seems to be the difference. If i use a nonpure shell, the compilation fails. <adanska>i have some common lisp packages in my profile already... <mange>I always use the sbcl- variants of the packages, because they should already have the fasl files and thus not need to create them. <mange>There's also some way to tell SBCL where to save the fasl files to, but I can't remember the details. <mange>FWIW, I have common lisp packages in my profile and I can run that same command without the --pure and it still works. I didn't try with cl-mcclim. <adanska>would you be able to try compile cl-babel in a non-pure shell with mc-mcclim in your profile? <mange>Something like this? No errors from this: guix shell sbcl cl-mcclim -- sbcl --eval '(require :asdf)' --eval '(asdf:compile-system "babel")' <mange>Similarly, this is fine: guix shell sbcl cl-mcclim -- sbcl --eval '(require :asdf)' --eval '(asdf:compile-system "mcclim")' <bdju>bavier: I'm trying to recreate the list of additional locales from the manual, they use cons to add one new locale to the existing defaults. I copied it pretty much exactly, just put in a different locale. and I've tried with two of them and neither worked so I'm not sure what's wrong. <bdju>I actually would ideally add a few new locales but I thought I'd better get one new one working first and I couldn't even get that far <mange>Can you put your config in a paste so we can see it? <dajole>After installing Guix System with the latest image I get dropped into Grub rescue with 'error: no such cryptodisk found'. I've tried to reinstall with the same result. Any ideas of what might be going on? I haven't tried without full disk encryption, as I'd really like to get that to work. <bavier>bdju, one thing the locale example in the manual doesn't make super clear is that the the cons is the value of the "locale" field of the operating-system declaration. E.g. (locale (cons (locale-definition ...) %default-locale-definitions)). <bdju>thank you, that's probably the issue <bdju>hm I don't think I'm feeling up to messing with this <bdju>I don't know how that fits in then with where I just set my locale currentlyk <bdju>really wish there were more clear examples of common needs <Rutherther>dajole could you send your config and output of lsblk? <Rutherther>Also maybe to make it easier, send /boot/grub/grub.cfg on the disk guix is installed to <dajole>Thank you for your reply, Rutherther. It's getting pretty late here and I need to head out, but I'll try to figure out how to get those files tomorrow (the system isn't booting). I was just following the graphical installer and didn't make any changes to the config. <taeaad>Hi, has anyone tried to make a package for python-polars? <taeaad>I tried to make one via import pypi but the prerequisites aren't clear to me. For example, it seems like I need at least "maturin", but these reqs don't come with the pypi import. <janneke>ACTION fights with libstdc++-boot0 and gcc-cross-boot0, and libtool <amano>Does any bootloader copy kernel images and initrd to /boot? <amano>It's slow for grub to unlock luks. <janneke>haha interpreter /gnu/store/lbgjnpxygyhcfw4ihin5s9w0qiqz56lm-glibc-bootstrap-0/lib/ld-x86-64.so.1CC_FOR_BUILD=gcc, <rekado>dariqq: you're right. There is some overlap between the two teams (hello!), but the sysadmin team should get its own id. <amano>Rutherther: Does grub-efi-copy-bootloader copy all available kernel images along with their initrds to /boot? <amano>I believe guix can have multiple kernel images installed. <Rutherther>amano no, not all available, only the ones that are actually referenced from the system profiles. All available is unnecessarily wasteful. <amano>Send grub-efi-copy-bootloader and grub-efi-copy-signed bootloader to guix. Make sure to delete old files in /boot. <amano>I don't know whether the pending changes to bootloader system will make your bootloader defunct. <Rutherther>As for signing, thats whole another matter and will need a lot more work to do properly <amano>These four issues can make your bootloader defunct. <dariqq>rekado: noticed this because a set of patches i sent earlier wanted to notify sugar team and not sysadmin team (I changed the id before sending and things worked as expected) <futurile>amano, Rutherther that series looks super complicated - seems like a lot of work being done - complicated/big things are hard to get into Guix though <gabber>how do i find the python used in a package built with the pyproject-build-system? python is clearly used (to wrap the binaries) but does not show up in any of the (package-FOO-inputs PKG) <Rutherther>futurile yeah if I submitted my bootloader it would be much shorter, so although its not as powerful, and has some workarounds around the bootloader interface being specifically tailored for grub, it could possibly be accepted faster as a current workaround <unmush>I've noticed that it's possible to reconfigure a system, run 'guix gc', and then be unable to reconfigure the system again without network access. That's a rather difficult situation to be in. This also includes running 'guix system switch-generation'. Maybe a system should optionally carry around references to the tools it needs in order to reconfigure itself? <Rutherther>gabber why do you want it? Anyway, its either the default-python in the build system module, or #:python argument <unmush>(I was recently in a situation like this where I couldn't enable the cups web interface until I got network access) <Rutherther>unmush yes its already optional possibility - add --keep-outputs --keep-derivations to guix-daemon arguments <unmush>I suppose that would solve it, but that's also a global setting that would for example ensure that I keep all 9001 rust versions <gabber>Rutherther: i figured out why i get a weird error when shepherd starts my gunicorn (it's due to non-set GUIX_PYTHONPATH). i have to set that path with the python in use <Rutherther>gabber then for the version of guix you are using gunicorn is packaged improperly <gabber>Rutherther: after your comments yesterday i tried it with a fresh pull <gabber>i suspect some (weird/interesting) bug/behavior when running gunicorn from shepherd <Rutherther>gabber how does your service definition look like? <dariqq>rekado: seems to be fixed already (someelse noticed aswell and sent a patch yesterday) <Rutherther>unmush yeah,I suppose it should be possible to gc root system build dependencies individually upon activation. <unmush>or it would be nice to be able to configure 'guix gc' to be a bit selective about where inputs should be kept (for example, things only reachable through my ~/.guix-profile don't need to keep their inputs probably, but things reachable through /run/current-system probably should) <gabber>Rutherther: the "ModuleNotFoundError: No module named 'pkg_resources'" can be reproduced with a GUIX_PYTHONPATH variable only set to the gunicorn package (without a reference to the python package's site-packages dir) <Rutherther>gabber I know that one. I meant how you have it in your config. But on second thought I think I know where the issue is then, if adding pythons site packages itself. But still, it should work even without any pythonpath set, as the line that has error imports something that does not require pkg resources. <Rutherther>unmush the problem with making guix gc work like that is that Guix gc cannot possibly know that. There is no reference on what was used for build in the package output paths. They refer only to deps that are actually used by it currently <unmush>guix gc knows what derivation produced an output and what its input derivations were and what their outputs are, that's how --keep-outputs and --keep-derivations works <Rutherther>unmush I dont think thats how it works. But I will have to check the source later to know for sure. <gabber>Rutherther: so.. where is the issue, then? <Rutherther>gabber in packaging. I am not at pc now, so I cant inveatigate further. <gabber>Rutherther: thanks nevertheless (: <attila_lendvai>i'd appreciate a pointer to a codeberg repo that has CI set up for building packages of a guix channel. i'd like to set up CI for my guix-crypto channel. <olndrxyz>Hello, does (setq use-package-always-ensure 't) work for you under Guix? <gabber>Rutherther: indeed, omitting the footprint-reducing 'wrap phase of the gunicorn package seems to take care of the issue. should i prepare a path for a full-blown-gunicorn? <rekado>the python-websockets upgrade seems to have broken python-uvicorn. <janneke>oh my -- /gnu/store/...-bootstrap-binaries-0/bin/install: cannot stat '.libs/libcc1.so.0.0.0': No such file or directory <rekado>I'll try upgrading python-uvicorn on master. <efraim>janneke: '.libs' doesn't sound right <efraim>well, I got qtbase to build on i686-linux, but qtdeclarative went OOM during make-dynamic-linker-cache <janneke>efraim: ah; i tried to look at the x86_64-linux build log but i only seem to find an empty one <janneke>efraim: how can i (--keep-faild) best debug this, i.e., what's does command look like that should create libcc1.so.0.0.0? <janneke>ACTION is guessing libtool must be somehow encouraged not to destroy some linking command line <efraim>if that's during a gcc build then I suppose .libs could be the folder that GCC stages the compiled libraries in <janneke>yeah, it's gcc-cross-boot0 on the hurd, in build/libcc1 <efraim>if you know the derivation then you can SSH into the childhurd and manually run 'guix build /gnu/store/...-drv -K' and then inspect it after <efraim>I assume it's still single threaded, so it's unlikely its a race condition <efraim>TIME_T_32_BIT_OK=yes from findutils-boot0 probably isn't a problem, not sure about the disable-posix-spawn flag on gnu-make-boot0 <efraim>janneke: can you upload the build log anywhere? <Kabouik>I am trying to use Yoctopuce.com's Virtualhub executable, but I am getting "VirtualHub: error while loading shared libraries: libusb-1.0.so.0: cannot open shared object file: No such file or directory". It used to work, I don't know what happened besides guix updates (I didn't update Virtualhub). Any ideas? I think libusb, libusb-compat and python-libusb are all installed on my machine. <Kabouik>I can find in my shell history some "LD_LIBRARY_PATH=$(guix build libusb)/lib ./VirtualHub" so I assume I already faced that issue, but this gives me a Segmentation fault now. <janneke>efraim: haha, yeah sorry i meant figure out which make target i should try, ie, make libcc1.lo, or make .libs/libcc.so[*] <janneke>i built its libstdc++ dependency using --disables-shared, otherwise that fails similarly: install: cannot stat '.libs/libstdc++.so.6.0.33': No such file or directory <efraim>janneke: is there a suprise lib64 folder somewhere? <efraim>let me find where libcc1.la is also referenced, it gets installed from the current directory <janneke>no, lib64 does not exist in the tree <efraim>I meant in the install locations <efraim>does it ever actually build libcc1.so.0.0.0? it installs libcc1.so.0 and libcc1.so as symlinks to libcc1.so.0.0.0 <janneke>ah; no it doesn't build libcc1.so.0.0.0 <janneke>i'm guessing `make libcc1.la' should do that <janneke>ACTION is trying the pre-libtool command, and instrumenting libtool, etc <efraim>I would hope so, that's not a build failure I've run into before <rekado>ugh, the fact that the python-team branch has been dormant for so long is really holding us back <rekado>there are so many packages that we can't upgrade because they would depend on packages we don't even have on python-team yet. <rekado>the huge python collection will need regular updates to "core" packages <rekado>otherwise we'll continue to be stuck between micro updates and nasty patches, hoping that it won't all come crashing down. <weary-traveler>i'm on a foreign distro. i would like a more declarative configuration of packages i keep installed in my default profile. is guix home the right thing to look into for this? specifically, i am not looking to change (yet) how i manage my dotfiles <efraim>can you choose only a few packages here or there that need upgrading or is it really touching everything <rekado>I'm happy that the python team has gained a few volunteers, so things are moving in the right direction. <rekado>but we're many years behind in some cases. <futurile>weary-traveler: that will work, or you can start by using a manifest and some shell scripts <rekado>efraim: just now I spent a few hours fiddling with minor upgrades to two packages because anything past the year 2023 required a more recent version of attrs, which causes a rebuild of thousands of packages. <rekado>I ended up scrapping the upgrades, because I'd have to upgrade an ever-increasing number of packages just to get to mid 2022. <rekado>in the end I patched the code of python-moto to remove an import and an exception handler to avoid all this. <rekado>and I only need to do this because of the upgrade to python-websockets, which broke uvicorn, which eventually broke snakemake. <weary-traveler>futurile: yeah, was debating between manifest or guix home. but if guix home won't interfere with dotfiles, then i'd rather use that. sounds like it should be possible to do? <rekado>weary-traveler: dotfile management is optional <futurile>weary-traveler: I use manifests honestly (just because it's how I started), but by default guix-home will ignore dotfiles and it back everything up in any case - so you don't have to use it to manage your dotfiles anyway <rekado>I'm using guix home with only some dotfiles defined in the home configuration. <efraim>I want to suggest ripping off the bandaid and going all in on bumping all the python stuff, but it sounds like you almost did that and it was overwhelming <efraim>I don't know which would be preferable, moving forward incrementally starting from a few years behind or trying to just jump forward <rekado>we did that several times, actually <rekado>but then core-updates got merged first and rebasing the huge python-team branch became impossible <rekado>so now python-team is a subset of what had previously been worked on. <rekado>I don't know what the current status is. <efraim>rust-team can be massive but at least it's mostly self contained <rekado>Python packages also suffer from a lack of tooling and from the overuse of propagated-inputs. <rekado>the updater for Python packages doesn't do a good job at identifying all needed inputs, and the use of propagated inputs means that *everything* somehow needs to be harmonized. <rekado>it would be *so* much easier if we could have package variants to keep old stuff working while the rest of the packages benefits from upgrades. <csantosb>I'm having a little tweak with channels ... <csantosb>channel A includes a package, P, with a dependency, D. D belongs to guix-science. <csantosb>So in channel A, inside the module where P is, I need to add #:use-module (guix-science packages electronics), right ? <csantosb>channel A and guix-science are both included in my .config/guix/channels.scm <csantosb>Impossible to build the .drv for channel A. What I'm missing here ? <rekado>csantosb: your channel needs to declare a dependency on guix-science. <csantosb>rekado: this is what I was thinking, but how ? <rekado>csantosb: in the .guix-channel file add a "dependencies" field <rekado>it's described in the manual in section 6.9 Declaring Channel Dependencies <efraim>janneke: that patch is still active in commencement, you could try adding x86_64-gnu to the systems which use that phase <janneke>i also found: /gnu/store/cjfly6dd41wxbfi5y5l0mx04whlhkxxk-libstdc++-boot0-14.2.0/lib64 <efraim>that normally gets patched in gcc-4.7 IIRC <janneke>";; libcc1.so NEEDs libgcc_s.so, so provide one here" <janneke>my bootstrap-gcc does not provide that one, only libgcc.a <janneke>ACTION goes to figure out why libgcc_s.so is missing from bootstrap-gcc <janneke>hmm, or do i need _more_ --disables-shared in commencement.scm... <csantosb>rekado: still something wrong with my .guix-channel ... <janneke>yeah, we probably don't want --enable-shared in make-bootstrap <janneke>let's convince libtool just not try to install a shared library that doesn't exist <rekado>csantosb: the single quote on line 9 looks wrong <janneke>no, gcc-cross-boot0 for x86_64-linux, (built with --disable-shared!) includes libcc1.so.0.0.0 <fnat>What do you do to be able to use Wireshark? You create a Wireshark group in your system configuration and add your user to it? <ieure>fnat, Haven't run it on Guix, but I generally use `sudo tcpdump' to get a .pcap file, then open it with Wireshark running in my account. <fnat>ieure: Ha, I think that'd work for me too, I'll do that then, thanks! <Rutherther>fnat you would have to do more. I have not tried this, but what could be sufficient is adding wireshark as privileged program, with group wireshark and CAP_NET_ADMIN, CAP_NET_RAW capabilities <Rutherther>(dumpcap coming from wireshark should be the privileged program) <fnat>Thanks Rutherther. I think ieure's tip should be ok, it only involves two steps tcpdump+visualisation with Wireshark. So far it works for me - but thanks for giving extra context. <rekado>csantosb: that's not the format for the .guix-channel file <csantosb>rekado: yep, but for not that lispy people, looks weird <csantosb>I would have never guessed myself, thanks again ! <targetdisk>when I read that y'all built the init system and the initramfs in a functional language, my jaw dropped <targetdisk>I was going to run guix on an Alpine base, but Sheperd and the Scheme initramfs made me reconsider :) <Guest78>Hey everyone! Does anyone know how to properly do rust development on guix? <Guest78>The rust book says to install rust using rustup. <bigbookofbug>Guest78: rustup isn't available in the guix package manager -- what i do is install rust and rust-cargo packages :) <ieure>Guest78, The question is not stupid. Rust is just a language that seems not to care much about how its tooling interacts with distros, so there are a lot of problems and complexity. <bigbookofbug>if you want rustup, one option is the nix-service-type, and using the rustup package from there <Guest78>But Rust version is behind in the guix repo though <bigbookofbug>if you'd like the most up-to-date, nix service type might be the best method <Guest78>bigbookofbug Ok! So native way to do so? <bigbookofbug>if you enable the nix-service-type from here, it'll expose the nix package repository, and you can use rustup via nix. it's a bit more straightforward of an approach than creating an fhs container imo <Guest78>Are nix packages seamlessly integrated or are there some hiccups? <divya>The rust-team branch is just a few weeks before getting merged. <bigbookofbug>your welcome! mostly seamless as long as they don't need driver access <bigbookofbug>the only nix package issues i have are re window managers, but that's because of how nix handles drivers, not a fault on the guix end <bigbookofbug>ieure: rust's tooling is part of what led me to drop it personally and go back to C in all honestly <bigbookofbug>that and the fact that every language interacts with C, but it seems like only rust interacts with rust <Guest78>Could you elaborate what is the problem with rust's tooling? <Guest78>I am coming from python, so yeah, not a good a place! <ieure>Guest78, Rust tooling is built around a model where the only thing you ship is the finished binary, which is fully self-contained. Rust applications tend to have a large number of dependencies which the tooling downloads itself, and everything locks to precise versions. <ieure>This works very poorly with the typical Linux distro model of shipping one version of a library shared between all programs that need it, shipping updates to libraries to patch vulnerabilities, etc. <ieure>I'm sure there are more technical details, but that's the broad picture. <bigbookofbug>my personal issues are that rust seems to assert a very monolithic setup for a project -- like if you're doing rust you're usually only doing rust in my exepreince. there are also the dependencies and the way they work. <bigbookofbug>admittedly i never got too deep into the nitty-gritty of rust because i got frustrated with cargo / compile times / type handling but i do know people who swear by it <bigbookofbug>i tend to avoid the "C killer" sort of types of languages at this point personally. C and the lisp ecosystem fit all my needs for the most part :) <bigbookofbug>Guest78: ive never worked with python -- is the packaging ecosystem not the best ? <ieure>bigbookofbug, I've done a good amount of Python. The packaging stuff has never been *great*, but it's gotten much worse recently. <ieure>They used to have one tool that worked okay, but had some limitations. Then some other tools tried to fill those gaps. Then they made a system with a standardized setup where you can freely mix build front/back end things into one system. Now there are a bajillion poorly differentiated build things and every project you roll into is different than every other one. <ieure>I like Python as a language, I write it near daily, but the build tooling is some of the most unpleasant I have ever had the misfortune to have no option but to deal with. <Guest78>Just fought to hell and more to properly setup pytorch on nix. <Guest78>and I would be glad to have to not go through that again <weary-traveler>ieure: how does rust handle libc? or is that allowed to be shared? <ieure>weary-traveler, I don't know. <Rutherther>weary-traveler: rust produces elf binaries. The only thing "statically linked" are the rust crates it depends on, but with other libraries it's same as compiling c dynamically <ieure>It needs some kind of FFI for that, though, right? <Rutherther>ieure: I am not sure what you mean. For executing functions from so libraries? Yeah, it has an interface for calling functions of external libraries <aemogie>for context on what im trying with the code: im doing an ephemeral root setup, and have a mount that i do inside a home folder, but as the file-system <aemogie>service runs before the user-homes service, the user-homes sees that the <aemogie> home directory already exists and won't properly set up permissions (which is fine for `/root` (which is the example in the logs), but for an unprivileged user, that means i dont have write access in my home folder. <aemogie>and the `file-system-/root/.cache/guix` service requires both `file-system-/persist` and `user-homes` according to `herd status`, yet according to `herd log` one of those requirements run before it while the other runs after it <aemogie>is that possibly to do with how `user-homes` is a one-shot while the `file-system-*` services arent? <Rutherther>Most python packages get the default-python, being python-toolchain, not python itself. Can I somehow reference the underlying python in build phases, not the toolchain? I can get the toolchain by assoc-ref on native-inputs/inputs. The toolchain has python as propagated input, named python, so it seems to me like it's shadowed by the toolchain. <anemofilia>aemogie: Hi, I am using a ephemeral root setup. Why the dependency of /persist/path on user-homes? <Rutherther>gabber: the issue with gunicorn is that the custom wrap phase is referencing the python-toolchain's lib/python3.10 folder, but that folder doesn't exist. The correct folder to reference is python's lib/python3.10 folder. Since python is propagated through the toolchain, when search paths are utilized, the packages get correct pythonpath, but since here assoc-ref for "python" is used, the toolchain is obtained, not python itself <anemofilia>aemogie: Oh, I've read your messages again, and got the problem. I haven't seen that in my setup because I decided to make a @root subvolume for /root <anemofilia>I guess the shepherd-requirements thing should work too, though <philofosser>Hey, has anyone ever seen a guix build phase get premission denied when trying to install to out? I wrote a package for something that doesn't have a `make install', so I added to the build phase (replace 'install (lambda* (#:key outputs (configure-flags '()) #:allow-other-keys) ... (install-file "srcbin" "outbin"))) <philofosser>But guile is throwing premission denied at me. Not sure what's going on. I tried throughing a mkdir-p for the /bin folder in out, but same results. <anemofilia>philofosser: did you overwrite the PREFIX/DESTDIR make flag? <Rutherther>philofosser: can you send full build log output? <philofosser>10 (primitive-load "/gnu/store/7scj3623aim1yak2ns691vaxnb5…") <philofosser> 966:2 9 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #) <philofosser> 1752:10 8 (with-exception-handler _ _ #:unwind? _ # _) <philofosser> 634:9 7 (for-each #<procedure 7ffff5f61f60 at guix/build/gnu-b…> …) <philofosser> 1752:10 6 (with-exception-handler _ _ #:unwind? _ # _) <philofosser> 159:9 4 (_ #(#(#(#(#(#<directory (guile-user) 7fff…>) …) …) …) …)) <philofosser> 223:20 3 (proc #(#(#(#(#(#<directory (guile-user) 7…>) …) …) …) …)) <philofosser> 2 (%resolve-variable (7 . binname) #<directory (guile-use…>) <ieure>philofosser, Please use a paste service. See topic. <philofosser>Sorry for the sudden spam. I was tinkering and messed up the original fail state <philofosser>anemofilia: Sorry about going dark. I fixed problem. It was *drumroll* a typo. I was trying to package ACL2. <philofosser>I was getting a permissions error though which is what distracted me. There's a file coincidentally with the same name as the typo that's generated during the build phase. <janneke>ACTION is now up to gcc-final -- finger crossed <janneke>meanwhile, doing a world rebuild (RWWOPS :) <rekado>builds on ci.guix.gnu.org are in Submitted state for what seems like an unusually long amount of time. <civodul>that can happen when a build has dependencies, and those dependencies are being built before it’s officially “started” <civodul>the other case where this can happen is if the .drv is no longer available on berlin <civodul>in that case the work retries a few times to download it and eventually gives up