bug#55360: bug#58375: Installer does not show what is being downloaded

Hey Ludo! > I’m not sure it’s a good idea for ‘guix system init’: we’d be logging > mostly progress bars, package names, and the likes to syslog—not super > useful. So I’d suggest not capturing stdout of ‘guix system init’. In the bug report https://issues.guix.gnu.org/57983 capturing the 'gui

bug#58485: [shepherd] Restarting guix-publish fails

Hi, it seems that `herd restart guix-publish` stopped working after the introduction of socket activation into shepherd. This is a problem, because I restart guix-publish automatically after unattended-upgrades. It fails with the following error for me: ---snip--- Backtrace: 7 (primiti

bug#57232: [installer] ENTER in guided partitioner destroys partition table

Hey, > Fixes: . > > * gnu/installer/newt/partition.scm (run-label-confirmation-page): New > procedure. > (run-label-page): Call the above procedure before proceeding. I pushed a slightly edited version of this patch. Thanks, Mathieu

bug#58485: [shepherd] Restarting guix-publish fails

Am Donnerstag, dem 13.10.2022 um 09:51 +0200 schrieb Lars-Dominik Braun: > The obvious explanation would be that stopping does not wait for the > process to actually exit. make-kill-destructor does not waitpid it > seems and 'running is set unconditionally to #f after 'stop has > finished. Shouldn'

bug#53480: i686 ISO image from CI is installing an x86_64 system

Hello, Fixed with: 84b4216e988ec6791b6df8f894d5a01cbf2e5fa5. Thanks, Mathieu

bug#58485: [shepherd] Restarting guix-publish fails

Hi Liliana, > Shouldn't [1] address this very issue? > [1] > http://git.savannah.gnu.org/cgit/guix.git/commit/?id=2a37f174becbafd70591f6eb1d98493c5c1df0e2 no, if the process is running make-systemd-destructor is just an alias for make-kill-destructor. So it does not matter which one we use in this

bug#55360: bug#58375: Installer does not show what is being downloaded

Hi! Mathieu Othacehe skribis: >> I’m not sure it’s a good idea for ‘guix system init’: we’d be logging >> mostly progress bars, package names, and the likes to syslog—not super >> useful. So I’d suggest not capturing stdout of ‘guix system init’. > > In the bug report https://issues.guix.gnu.or

bug#58485: [shepherd] Restarting guix-publish fails

Am Donnerstag, dem 13.10.2022 um 13:35 +0200 schrieb Lars-Dominik Braun: > Hi Liliana, > > > Shouldn't [1] address this very issue? > > [1] > > http://git.savannah.gnu.org/cgit/guix.git/commit/?id=2a37f174becbafd70591f6eb1d98493c5c1df0e2 > no, if the process is running make-systemd-destructor is j

bug#58495: opam import generates wrong check phase

So I'm working on building MirageOS unikernels with Guix, which means using the OPAM importer *a lot*, which unearths some very Fun TM bugs. Here is the first one: guix import opam mirage-clock The correct check phase is this: ``` (replace 'check (lambda* (#:key tests? #:allow-other-ke

bug#58495: opam import generates wrong check phase

Maybe this could be fixed in the dune-build-system? Le 13 octobre 2022 17:03:43 GMT+02:00, Csepp a écrit : >So I'm working on building MirageOS unikernels with Guix, which means >using the OPAM importer *a lot*, which unearths some very Fun TM bugs. >Here is the first one: > >guix import opam mir

bug#58495: opam import generates wrong check phase

Julien Lepiller writes: > Maybe this could be fixed in the dune-build-system? > Actually, good call. I'll look into it, unless you want to take a stab at it.

bug#58497: opam import doesn't work with ocaml_intrinsics among others

The error might not be the same for others, I have a slightly patched opam->guix-package function. guix import opam ocaml_intrinsics Backtrace: In ice-9/boot-9.scm: 1752:10 10 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 9 (apply-smob/0 #) In ice-9/boot-9.scm: 724

bug#58497: opam import doesn't work with ocaml_intrinsics among others

(beautify-description #f _) Seems to be the cause. Yet, there is a description. Maybe parsing ends a bit too soon? Le 13 octobre 2022 18:07:08 GMT+02:00, Csepp a écrit : >The error might not be the same for others, I have a slightly patched >opam->guix-package function. > >guix import opam ocam

bug#58452: openldap fails to cross-compile to aarch64 (strip errors) (was: guix pack cross-compile failed to build docker img of openldap for aarch64)

--- Original Message --- On Wednesday, October 12th, 2022 at 14:32, Maxime Devos wrote: > retitle 58452 openldap fails to cross-compile to aarch64 (strip errors) > thanks > > "guix pack" and Docker seem unrelated here, rather it seems to be > regular cross-compilation bug to me that c

bug#57878: Minimal reproducible setup

Am Donnerstag, dem 13.10.2022 um 12:31 +0300 schrieb Max Brieiev: > > I think this reasoning really falls flat in presence of any non- > > Emacs package manager.  Like, obviously wanting to natively compile > > packages managed by (dpkg, rpm, pacman, emerge, guix), but not > > natively compiling a

bug#58285: secrets crashes when unlocking database

On Mon, Oct 10 2022, 01:21:36 AM -0400 Maxim Cournoyer wrote: > I could reproduce that; I first updated to version 7, but I had an > unrelated problem with otp something. Unfortunately I'm not sure > what's wrong. Would you have the time to open an issue with > upstream? You'll need an account

bug#58485: [shepherd] Restarting guix-publish fails

Hi, > Ahh, so the issue is that shepherd waits neither for the process to be > actually killed nor for the socket to become available, isn't it? I would argue it’s the former, but having either of them would solve the problem, I think. Lars

bug#58290: guile ssh error on guix deploy

On 2022-10-08 14:39, Ludovic Courtès wrote: > Hi! > > Andrew Tropin skribis: > >> From time to time I get the following error, the only thing I change is >> IPv6 config in static-networking service. Sometimes it fails, but after >> a few more attempts with the same config it deploys sucessfully.

bug#58485: [shepherd] Restarting guix-publish fails

Am Freitag, dem 14.10.2022 um 08:18 +0200 schrieb Lars-Dominik Braun: > Hi, > > > Ahh, so the issue is that shepherd waits neither for the process to > > be > > actually killed nor for the socket to become available, isn't it? > I would argue it’s the former, but having either of them would solve