bug#63443: download retry bug; mkdir: File exists
Hi, Attila Lendvai skribis: > maybe this commit has a bug? > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8bd4126917f59f4af9a4323c3d5699201862dca2 > > i get a "mkdir: File exists" error: > > 1,198.1 MB will be downloaded > substitute: updating substitutes from 'https://substitutes.nonguix.org'... > 100.0% > substitute: updating substitutes from 'https://substitutes.nonguix.org'... > 100.0% > locale-2.33 1.9MiB 567KiB/s 00:04 ▕██▏ 100.0% > dtc-1.6.1 96KiB 106KiB/s 00:01 ▕██▏ 100.0% > linux-firmware-20230404 267.8MiB 119KiB/s 04:57 ▕██▎ ▏ 12.8%retrying download > of '/gnu/store/i5cjfma5k2fz0h278ypqbdzhl4pjdzjf-linux-firmware-20230404' with > other substitute URLs... > linux-firmware-20230404 267.8MiB 226KiB/s 00:01 ▕ ▏ 0.0%guix substitute: > error: mkdir: File exists: > "/gnu/store/i5cjfma5k2fz0h278ypqbdzhl4pjdzjf-linux-firmware-20230404" > substitution of > /gnu/store/i5cjfma5k2fz0h278ypqbdzhl4pjdzjf-linux-firmware-20230404 failed > guix system: error: corrupt input while restoring archive from # 7f382a0a6a80> Fixed in 885d524f79aa4bbfac5dfebf285e1e248184ee70. Thanks! Ludo’.
bug#49132: guix substitute: backtrace when the network is disabled during substitution
Ah indeed, this is poorly handled. I’m not really sure how to address it. I/O ports are a nice abstraction as it allows you to transparently read “streams” from any medium, but as always, that also comes with opacity where the call site is not supposed to know what kind of exceptions might be thrown deep down. Thoughts? About 'as always, [...]’: [citation needed]. AFAICT, nowhere does Guile documentation state they they aren't supposed to know. Also, that seems a bad supposition to me if it prevents fixing the bug. I would just ignore that 'not supposed to’. I think this supposition needs some adjustment in order to be practical: guix/scripts/substitute.scm has opened the network connection (via http-client), so guix/scripts/substitute.scm is responsible for the connection (unless it delegates of course), so guix/scripts/substitute.scm is supposed to know what to do about exceptions involving that connection (unless it delegates). That there are some intermediate modules before things are actually read from the port is irrelevant -- substitute.scm opened the port, is responsible for the port and knows best how to handle exceptional situations involving that port. Nothing lower-level has the right context/information to make a good decision on how to handle the exception, so no delegation possible. As such, guix/scripts/substitute.scm should do it. It's not 100% clear from the backtrace, but it appears that the exception (from guix/scripts/substitute.scm perspective) happens at: ;; Procedure: process-substitution ;; Unpack the Nar at INPUT into DESTINATION. (define cpu-usage (with-cpu-usage-monitoring (restore-file hashed destination #:dump-file (if (and destination-in-store? deduplicate?) dump-file/deduplicate* dump-file This should then be wrapped in an error handler catching 'bad-response', maybe reporting it, and switching over the next URL. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#53580: shepherd's architecture
> Sorry to be direct: is there a concrete bug you’re reporting here? i didn't pay careful enough attention to report something specific, but one thing that pops to mind: when i'm working on my service code, which is `guix pull`ed in from my channel, then after a reconfigure i seem to have to reboot for my new code to get activated. a simple `herd restart` on the service didn't seem to be enough. i.e. the guile modules that my service code is using did not get reloaded into the PID 1 guile. keep in mind that this is a non-trivial service that e.g. spawns a long-lived fiber to talk to the daemon through its stdio while the daemon is running. IOW, its start GEXP is not just a simple forkexec, but something more complex that uses functions from guile modules that should be reloaded into PID 1 when the new version of the service is to be started. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The unexamined life is not worth living for a human being.” — Socrates (c. 470–399 BC, tried and executed), 'Apology' (399 BC)
bug#63794: Bad error reporting in case of 404 during downloading
I think I saw it again after upgrading but I might have misremembered. > I think this report is about two issues: > > 1. the substitute error, > 2. the way the error is reported. > > About #1, clearing the cache seems fixing. IMO this manual action of having to clear the cache (in a new Guix) to work-around remainders of a bug in old guix should be unnecessary. I consider having to do this a bug. Also, I keep not receiving e-mails in my e-mail client. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#63775: git describe on current master says: v1.3.0-38775-g6192acf8b7
Hi, thank you Janneke for this report, I thought I had some problem with my working dir magit tells me I'm on "Tag: v1.3.0 (39040)" Simon Tournier writes: [...] > Oh, that’s weird! > > --8<---cut here---start->8--- > $ git describe --debug > describe HEAD > No exact match on refs or tags, searching to describe > annotated 38817 v1.3.0 > annotated 38831 v1.3.0rc2 > annotated 38870 v1.3.0rc1 > annotated 55660 base-for-issue-62196 > annotated 55806 v1.2.0 > annotated 55814 v1.2.0rc2 > annotated 55837 v1.2.0rc1 > annotated 55985 v1.4.0 > annotated 55998 v1.4.0rc2 > annotated 56031 v1.4.0rc1 > traversed 56356 commits > more than 10 tags found; listed 10 most recent > gave up search at d62c9b2671be55ae0305bebfda17b595f33797f2 > v1.3.0-38817-g76b7bc5392 > > $ git rev-list --count v1.3.0..HEAD > 38817 > --8<---cut here---end--->8--- I have the very same (updated) results: [...] --8<---cut here---start->8--- 0 LC_ALL=C git describe --debug describe HEAD No exact match on refs or tags, searching to describe annotated 39040 v1.3.0 annotated 39054 v1.3.0rc2 annotated 39093 v1.3.0rc1 annotated 55883 base-for-issue-62196 annotated 56029 v1.2.0 annotated 56037 v1.2.0rc2 annotated 56060 v1.2.0rc1 annotated 56208 v1.4.0 annotated 56221 v1.4.0rc2 annotated 56254 v1.4.0rc1 traversed 56579 commits more than 10 tags found; listed 10 most recent gave up search at d62c9b2671be55ae0305bebfda17b595f33797f2 v1.3.0-39040-g76b7c50645 --8<---cut here---end--->8--- (output from magit-process) [...] I'm not so expert in git, still trying to understand how to debug this strange behaviuor Happy hacking! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
bug#53580: shepherd's architecture
Ludovic Courtès writes: > Hi Attila, > > Attila Lendvai skribis: > >> [forked from: bug#53580: /var/run/shepherd/socket is missing on an otherwise >> functional system] >> >>> So I think we’re mostly okay now. The one thing we could do is load >>> the whole config file in a separate fiber, and maybe it’s fine to keep >>> going even when there’s an error during config file evaluation? >>> >>> WDYT? >> >> >> i think there's a fundamental issue to be resolved here, and >> addressing that would implicitly resolve the entire class of issues >> that this one belongs to. >> >> guile (shepherd) is run as the init process, and because of that it >> may not exit or be respawn. but at the same time when we reconfigure >> a guix system, then shepherd's config should not only be reloaded, >> but its internal state merged with the new config, and potentially >> even with an evolved shepherd codebase. > > Sorry to be direct: is there a concrete bug you’re reporting here? > >> i still lack a proper mental model of all this to succesfully >> predict what will happen when i `guix system reconfigure` after i >> `guix pull`-ed my service code, and/or changed the config of my >> services. > > What happens is that ‘guix system reconfigure’ loads new services into > the running shepherd. New services simply get started; services for > which a same-named service is already running instead get registered as > a “replacement”, meaning that the new version of the service only gets > started when the user explicitly runs ‘herd restart SERVICE’. > > Non-stop upgrades is ideal, but shepherd alone cannot do that. For > instance, nginx supports that, and no init system could implement that > on its behalf. > > Ludo’. Do services get a reference to their previously running version? The Minix project was experimenting with supporting something like supervisor trees for high uptime, and one way they were trying to achieve that was by giving services the memory of their previous version, so they could read their state and migrate it to their own memory.
bug#63947: Bug when building ocaml-dune-build-info for ocaml5.0
After digging a bit more, I could fix this issue by modifying the definition of ocaml-dune-build-info with this patch. The problem might have come from the non standard definition of dune package using properties only. diff --git a/gnu/packages/ocaml.scm b/gnu/packages/ocaml.scm index f0b8f9e912..40a820b90e 100644 --- a/gnu/packages/ocaml.scm +++ b/gnu/packages/ocaml.scm @@ -9538,7 +9538,7 @@ (define-public ocaml-fix (define-public ocaml-dune-build-info (package -(inherit dune) +(inherit dune-bootstrap) (name "ocaml-dune-build-info") (build-system dune-build-system) (arguments
bug#63902: System containers with --network won't start "In procedure canonicalize-path: No such file or directory"
Hi, e...@beaver-labs.com writes: > ERROR: In procedure canonicalize-path: > In procedure canonicalize-path: No such file or directory This bug should have been fixed by 181951207339508789b28ba7cb914f983319920f, can you `guix pull` to update guix and retry? Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#63904: Can't setuid programs to anybody but root
Hi everyone, You might want to have a look at [1], which should resolve this. I've held off on reviewing it for quite a bit but have talked on IRC recently with bjc about it. With this approach, while cleaner, we'll need to identify which services rely on the setuid binaries being present, as well as ensure they're up before any interaction with the user is possible. [1] https://issues.guix.gnu.org/62726 HTH, -- Josselin Poiret signature.asc Description: PGP signature
