bug#66174: [BUG] poetry buil

Danny Milosavljevic writes: Hi Danny, > This was broken by commits d477018b57d5b4c13b4dd35aa1c4ee1a00ca76e2 > and 21d6985a8b3c6e53aab648275dc27b72c7453437--one of which also has > an incorrect commit message. Obviously those commits can never have > worked since they require poetry in order to

bug#57402: webkitgtk-with-libsoup2 fails to build on powerpc64le, breaking freecad

reopen 57402 quit Hi Marcel, Marcel van der Boom writes: > I think this issue was wrongly retitled. While the > webkitgtk-with-libsoup2 *was* also an issue (now fixed) the configure > phase error as originally reported (reproduced below for clarity) is > still there. > > > CMake Error at >

bug#66207: Cannot boot VMs with grub-efi-bootloader

Mathieu Othacehe writes: > Now it looks to me that what Ricardo is observing is not linked to any > of the changes mentioned above. When using the grub-efi-bootloader, > Grub is never installed in the post-MBR gap. This was already the case > in 1.4.0 and is still true. Those images cannot be

bug#66279: Unexporting

Hi Ludovic, Ludovic Courtès writes: > Hi Maxim, > > Commit 03795e2ba27424fc98957da00f6c71325e7ae425 exports the > record type descriptor (RTD). > > Common practice is to keep RTDs private because by publishing them, we > make it harder to change the ABI (because users might be matching fields

bug#66207: Cannot boot VMs with grub-efi-bootloader

Hey, Some context around that. Before recent commits, when we were producing qcow2 or raw images, those were MBR images with an EFI partition. If the grub-bootloader was used, then Grub was installed both in the post-MBR gap and in the EFI partition. This means that a single image could be

bug#66174: [BUG] poetry buil

Hello, This was broken by commits d477018b57d5b4c13b4dd35aa1c4ee1a00ca76e2and 21d6985a8b3c6e53aab648275dc27b72c7453437--one of which also hasan incorrect commit message. Obviously those commits can never haveworked since they require poetry in order to build themselves. I've reverted commit

bug#66207: Cannot boot VMs with grub-efi-bootloader

Hi, [...] > It’s due to the bootloader. This field from the bare bones template > works: > > (bootloader (bootloader-configuration > (bootloader grub-bootloader) > (targets '("/dev/sdX" > > but this from the desktop template doesn’t: > > (bootloader

bug#66297: guix-daemon not starting after boot

Hi Guix! After the recent pull and system reconfigure I've started experiencing guix-daemon not starting up after the system boot. ~# guix describe Generation 29 Sep 27 2023 21:59:12(current) guix 0500af5 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master

bug#65889: texlive-acronyms is missing dependencies

Hi Josselin, On 2023-09-14 14:13, Josselin Poiret via Bug reports for GNU Guix wrote: > Couldn't we report those missing dependencies upstream then? This can be done, in theory it's nothing too complicated and all it takes is simply add a DEPENDS.txt file to the repository. If you're interested

bug#65979: incorrect “guix hash” for FastQC

Hi, On Sun, 1 Oct 2023 at 17:07, Ludovic Courtès wrote: > >> My take is that it’s OK to keep ‘vcs-file?’ as is: the best we could do > >> would be to add complicated heuristics in the hope corner cases like > >> this one would be better dealt with, but it wouldn’t be bullet-proof > >> anyway. >

bug#66207: Cannot boot VMs with grub-efi-bootloader

Hi, Ricardo Wurmus skribis: > The manual for “guix system” gives a somewhat complicated invocation > that I only found out about later: > > image=$(guix system image --image-type=qcow2 \ > gnu/system/examples/lightweight-desktop.tmpl) > cp $image

bug#63153: transfig build failure

Fixed with [1] in '337dbf6867597b6e3b72b0bdb2152a42a9f41dbc'. [1]: -- Thanks, Bruno.

bug#65979: incorrect “guix hash” for FastQC

Hi, Simon Tournier skribis: [...] >> Clearly #2 is correct (it’s perfectly fine to have a ‘.svn’ directory in >> a Git repo), whereas #1 is an approximation that, in corner cases like >> this one, gives the wrong answer. > > These corner cases matter for some SWH loader implementing Nar hashes

bug#66290: transmission-daemon-service-type not serving web interface

The documentation for transmission-daemon-service-type makes it sound like the web interface should be up and running: Once the service is started, users can interact with the daemon through its Web interface (at ‘http://localhost:9091/’) ... However, the daemon throws 404 when