bug#30312: documentation: misleading EFI partitioning instructions

Marius Bakke skribis: > l...@gnu.org (Ludovic Courtès) writes: [...] >>> I'm not sure how to best resolve the first issue. I suppose we can >>> mention that if unsure which GRUB to use, the user can test whether >>> "/sys/firmware/efi" exists on the live image. >>> >>> We could also make it c

bug#31983: guix lint command error.

$ guix lint guix ;;; Failed to autoload make-session in (gnutls): ;;; missing interface for module (gnutls) Backtrace: 5 (primitive-load "/home/fis/.config/guix/current/bin/guix") In guix/ui.scm: 1557:12 4 (run-guix-command _ . _) In srfi/srfi-1.scm: 640:9 3 (for-each # …) In

bug#31982: shaderc fails its test suite on all hydra-supported systems

Hi Rutger, In commit 7f540654873a2761746bdc43be4727cad99b92c0, you updated 'sharerc' to upstream commit be8e087 and enabled tests. It turns out that it fails its test suite on all systems supported by Hydra, but the failure is effectively being ignored, because of . I

bug#31982: shaderc fails its test suite on all hydra-supported systems

shaderc fails its test suite on all systems supported by Hydra, but the builds succeed because the #f returned by meson-build-system's check phase is ignored, due to . https://hydra.gnu.org/build/2811833 (x86_64-linux) https://hydra.gnu.org/build/2811921 (i686-lin

bug#30312: documentation: misleading EFI partitioning instructions

l...@gnu.org (Ludovic Courtès) writes: > Hi Marius! > > Marius Bakke skribis: > >>> Ricardo Wurmus skribis: >>> Finally, it is not clear where the efi partition should be mounted. Should it be /mnt/boot/efi? If so, should the configuration file specify “/mnt/boot/efi” as the targ

bug#31907: New users get wrong/old profile path to guix after reconfiguring

Well, I wondered myself , and I was palning to test when I arrive home today. But here is my take: 1. Premise: The system configuration is declarative. The declarative state should be obeyed all times by the system 2. Implication: running a guix pull (or any other form of update) as any user sh

bug#31977: clone tests fail on CentOS 7

Hi Guix, Running 'make check' in the guix source tree on a CentOS 7 system results in 15 FAILS: tests/containers.log: 9 FAILS tests/syscalls.log: 3 FAILS tests/guix-environment-container.log: 1 FAIL tests/guix-pack.log: 1 FAIL tests/pack.log: 1 FAIL Referring to bug#24108, the cause may be that

bug#30312: documentation: misleading EFI partitioning instructions

Hi Marius! Marius Bakke skribis: >> Ricardo Wurmus skribis: >> >>> Finally, it is not clear where the efi partition should be mounted. >>> Should it be /mnt/boot/efi? If so, should the configuration file >>> specify “/mnt/boot/efi” as the target? Or should it be “/boot/efi”? [...] > I've tr

bug#31970: epiphany: Strange "XXXXXXXXXXXXX..." entries in library RPATHs

Hi Mark, Mark H Weaver skribis: > which also changed the build-system from 'glib-or-gtk-build-system' to > 'meson-build-system', warnings started appearing in the build logs for > epiphany complaining about "XX" > appearing in the RPATH of the built libraries.

bug#31892: guix pull ignores --substitute-urls in some cases

Hello Vagrant, Vagrant Cascadian skribis: > I've seen this a few times, and it seems like guix pull remembers old > substitutes. I tried disabling one of the substitutes that guix-daemon > is configured to use since it wasn't online at the time, but it tries to > use it anyways: > > guix pull --

bug#31757: 'guix system disk-image --format=iso9660' includes more than the OS closure

l...@gnu.org (Ludovic Courtès) skribis: > Turns out ‘guix system disk-image --format=iso9660’ includes not sure > the closure of the given OS, but everything that’s in the build > environment’s store. So typically, we end up with QEMU and all in > addition to the store’s closure. Fixed in 718d44

bug#31907: New users get wrong/old profile path to guix after reconfiguring

On 2018-06-20 23:35, l...@gnu.org wrote: > Hello swedebugia, ..snip > ~/.config/guix/current is created by the new ‘guix pull’. So when > coming from 0.14, you actually need to run it twice: the first run will > give you the new ‘guix pull’, and the second run will actually run the > new code

bug#30312: documentation: misleading EFI partitioning instructions

l...@gnu.org (Ludovic Courtès) writes: > Hello gentlefolks! > > Ricardo Wurmus skribis: > >> First, this sounds like it’s up to the user to pick either EFI-based >> GRUB or BIOS-based GRUB. It is not clear that this is determined by >> whether the machine has a {BIOS, EFI in legacy mode} or EFI.

bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc

Mark H Weaver writes: > Hi Marius, > > Marius Bakke writes: > >> Mark H Weaver writes: >> >>> 'meson-build-system' includes 'patchelf' as an implicit input for all >>> packages that use it, and uses it from its 'fix-runpath' phase, >>> sometimes directly and sometimes via (guix build rpath). >>

bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc

Hi Marius, Marius Bakke writes: > Mark H Weaver writes: > >> 'meson-build-system' includes 'patchelf' as an implicit input for all >> packages that use it, and uses it from its 'fix-runpath' phase, >> sometimes directly and sometimes via (guix build rpath). >> >> 'patchelf' is a nasty hack whic

bug#30312: documentation: misleading EFI partitioning instructions

Hello gentlefolks! Ricardo Wurmus skribis: > First, this sounds like it’s up to the user to pick either EFI-based > GRUB or BIOS-based GRUB. It is not clear that this is determined by > whether the machine has a {BIOS, EFI in legacy mode} or EFI. It’s > really not much of a choice. > > Second,