bug#43986: core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64
How do I debug this? $ guix-core-updates/guix/pre-inst-env guix environment -s armhf-linux --pure grep needs grep (it's in the implicit native inputs), and that grep has a test failure. So I can't actually enter the environment for building grep and running make check . What now? pgpdAubFLKmTG.pgp Description: OpenPGP digital signature
bug#44027: [PATCH] installer: Create bios_grub partition when it is needed.
Hi, Brett Gilio writes: > Ludovic Courtès writes: >> Shouldn’t it create a “legacy” partition table rather than GPT since >> we’re on an old, non-UEFI platform? > > That is my thinking as well, it should create a legacy MBR table. IMHO the old format should be avoided completely when possible. Why should we enforce it? I think this problem involves having a previous ESP partition on the disk (at least identified as such by parted), because auto-partition! currently checks that before checking if the booted system has EFI support. When that's the case, it doesn't create the needed bios_grub partition that might have been removed previously. The attached patch solves that. What do you think? Happy hacking, Miguel From a2f13b21a631398689cc5471c1910af294454e80 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?= Date: Sat, 17 Oct 2020 14:20:41 +0200 Subject: [PATCH] installer: Create bios_grub partition when it is needed. * gnu/installer/parted.scm (auto-partition!): Only check for ESP on EFI installations. --- gnu/installer/parted.scm | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/gnu/installer/parted.scm b/gnu/installer/parted.scm index b0c73b837e..fffd5abf3b 100644 --- a/gnu/installer/parted.scm +++ b/gnu/installer/parted.scm @@ -911,13 +911,13 @@ exists." (let* ((start-partition (and (not has-extended?) - (not esp-partition) (if (efi-installation?) - (user-partition - (fs-type 'fat32) - (esp? #t) - (size new-esp-size) - (mount-point (default-esp-mount-point))) + (and (not esp-partition) + (user-partition + (fs-type 'fat32) + (esp? #t) + (size new-esp-size) + (mount-point (default-esp-mount-point (user-partition (fs-type 'ext4) (bootable? #t) -- 2.28.0 signature.asc Description: PGP signature
bug#44000: Guile-Git cross-compiled to i586-pc-gnu gets bytestructures wrong
Taylan Kammer writes: > On 15.10.2020 09:42, Ludovic Courtès wrote: >> Ludovic Courtès skribis: >> >>> The problem is that the ‘cond-expand’ used to define ‘arch32bit?’ is a >>> expansion-time thing when (cross-)building Bytestructures itself, so >>> it’s incorrect from cross-building from 64-bit to 32-bit. >>> >>> I believe that changing it to: >>> >>> (define arch32bit? (memq data-model '(ilp32 lp32))) >>> >>> would fix it because then the test would happen at run time. >> >> I confirm that the attached patch for Bytestructures solves the problem >> (running ‘guix pull’ in my childhurd :-)). >> >> Let’s see whether it needs to be adapted for inclusion upstream. > > Hi Ludo, > > Thanks for finding finding this bug and for the patch. > > I'll try to include a portable version of the fix ASAP. I should have > time for it tomorrow. Hi again, Could you please test whether bytestructures 1.0.8 fixes the issue? Thank you! - Taylan
bug#43986: core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64
Hi Danny, On +2020-10-17 12:20:11 +0200, Danny Milosavljevic wrote: > How do I debug this? > > $ guix-core-updates/guix/pre-inst-env guix environment -s armhf-linux --pure > grep > > needs grep (it's in the implicit native inputs), and that grep has a test > failure. What if the test failure tested a grep feature that you don't actually need from the implicit native input grep? Is there no way to use a fully valid subset of a tool's functionality (that excludes irrelevant test failures of unused broken functionality) if there's a test failure in testing everything? If one could express a dependency on a limited subset by passing also a required-features list, à la ACL?, maybe dependencies could trigger less builds, and the feature lists might reveal opportunities for optimizing out some dependencies, e.g. where a bash shell's one or two grep invocations might depend on grep only for a regex match that might easily be rewritten with bash's own built-in '=~' One could imagine builds producing ELFs with bitvectors flagging features built and tested, for efficient dynamic safe-capability determination re usage by dependents, but I better stop rambling. So, monolith dependencies vs factoring, how to balance? > > So I can't actually enter the environment for building grep and running > >make check > > . > > What now? HTWNEU -- Hope This Was Not Entirely Useless :) -- Regards, Bengt Richter
bug#44025: haunt incompatible with package guix
Hi,
On Fri, 16 Oct 2020 at 16:30, Ludovic Courtès wrote:
>> (inputs
>> `(("guile" ,@(assoc-ref (package-native-inputs guix) "guile"
>>
>>
>> Or create a haunt variant named ’haunt-guix’ keeping the compatibility?
>
> Can we do that, but keep that variant in the web site’s ‘.guix.scm’
> file?
My proposal to fix the annoyance is #44051. The variant is created in
the manifest file. Since I am not using ’.guix.scm’, I have not looked
into. Next round, after v1.2. :-)
Cheers,
simon
bug#44027: [PATCH] installer: Create bios_grub partition when it is needed.
On 17/10/20 11:09 pm, Miguel Ángel Arruga Vivas wrote: Hi, Brett Gilio writes: Ludovic Courtès writes: Shouldn’t it create a “legacy” partition table rather than GPT since we’re on an old, non-UEFI platform? That is my thinking as well, it should create a legacy MBR table. IMHO the old format should be avoided completely when possible. Why should we enforce it? I think this problem involves having a previous ESP partition on the disk (at least identified as such by parted), because auto-partition! currently checks that before checking if the booted system has EFI support. When that's the case, it doesn't create the needed bios_grub partition that might have been removed previously. The attached patch solves that. What do you think? Happy hacking, Miguel I'm about to give it a test run. Unrelated to the patch, but, I'm building the installer (gnu/system/install.scm) on latest master and I get the following warnings/errors, although it doesn't stop the build from completing. is it a bug? https://paste.debian.net/plain/1167398
bug#44053: Poor profile generation performance on spinning disks
Hello! I've noticed on multiple occasions that using Guix on traditional spinning drives can be quite slow. On my home machine, will is still relying on 2 x 1 TB spinning drives in RAID1, rebuilding my user profile, which contains 182 entries, takes on average about 20 minutes, even when there are no packages to be built: --8<---cut here---start->8--- $ time guix package -i perl --max-jobs=1 The following package will be upgraded: perl (dependencies or package changed) The following derivation will be built: /gnu/store/lhywla1z2zcz16df4hbvvvngr9zmswr7-profile.drv building CA certificate bundle... building fonts directory... generating GLib schema cache... creating GTK+ icon theme cache... building cache files for GTK+ input methods... building directory of Info manuals... building database for manual pages... building XDG desktop file cache... building XDG MIME database... building profile with 182 packages... real19m0.126s user0m5.648s sys 0m0.333s --8<---cut here---end--->8--- Most of the time remains spent after the message 'building profile with 182 package...'. That part seems IO-bound, with the spinning disks grinding heavily and the CPU mostly idling. The rest of the time (3 minutes), was used by the profile hooks. The same operation on a second, more modern machine equipped with M2 SSDs does much better and takes about 1 minute to accomplish the same, so it seems the bad performance can be mostly attributed to the much slower disk seek times of the spinning disks. On the older machine, two profile hooks are also sticking out w.r.t. the time they take (they take more than one minute opposed to a few seconds): --8<---cut here---start->8--- The following profile hook will be built: /gnu/store/08fanpydi7z4i3qnlqbr8iz23zdgsamw-manual-database.drv building database for manual pages... Creating manual page database... [2139/2139] building list of man-db entries... 175322 entries processed in 95.1 s successfully built /gnu/store/08fanpydi7z4i3qnlqbr8iz23zdgsamw-manual-database.drv successfully built /gnu/store/08fanpydi7z4i3qnlqbr8iz23zdgsamw-manual-database.drv /gnu/store/wzp4mk2r7r4ysciw74gqbfkyai0zmrcc-manual-database real1m36.378s user0m1.674s sys 0m0.108s The following profile hook will be built: /gnu/store/cir84qj587i6is4akgqand7ahg9bj938-xdg-mime-database.drv building XDG MIME database... successfully built /gnu/store/cir84qj587i6is4akgqand7ahg9bj938-xdg-mime-database.drv successfully built /gnu/store/cir84qj587i6is4akgqand7ahg9bj938-xdg-mime-database.drv /gnu/store/j0bznlj2ibnhirijhnwpkkxzz4qfk8wb-xdg-mime-database real1m7.344s user0m1.331s sys 0m0.053s --8<---cut here---end--->8--- So we should profile what's going on while generating the profile (no pun intended) and try to improve this at first since this is where most of the time is spent on spinning drives (17 minutes out of the 20 in the above example). After that we could look into the two above profile hooks. Thanks, Maxim
bug#42900: Bug report
Hi Charlie, charlie writes: > Text as follows: > > ./guix/store.scm:1367:15: Throw to key `srfi-34' with args > `(# the outputs of derivation > `/gnu/store/4vqa9zmhhyzqca476236wbxqbv7s4b1v-guile-ssh-0.13.0-1.688d7f3.drv' > failed (usually happens due to networking issues); try `--fallback' to > build derivation from source " status: 1] 7fcdf05a0ba0>)'. > guix pull: error: You found a bug: the program > '/gnu/store/0v9rirhz4a1gg92n3cclldfh3p8xq9zd-compute-guix-derivation' > failed to compute the derivation for Guix (version: > "accdd9dd97b02a408bab1d40657173aa9c58401a"; system: "x86_64-linux"; > host version: "1.1.0"; pull-version: 1). > Please report it by email to . > > Regards > > Charlie As others have mentioned, this appears to have been a network-related transient error; I cannot reproduce it using: $ guix time-machine v1.1.0 -- guix pull -p /tmp/dummy I am closing this issue, but feel free to open a new one if you still encounter problems. Thank you for the report! Maxim
bug#44054: [1.2 installer]: Kernel panic when attempting to reboot after install.
I generated an installer for myself from 5d4ad8e1be6d60c38577e2f3d92cc5642b12eff0 + Miguel's patch (I think unrelated to this bug) here https://paste.debian.net/plain/1167398 After the install completed I pulled out the USB as per instruction on the screen, and pressed the Reboot button. The system then Kernel panic with the following messages: https://brendan.scot/p/IMG_20201018_140343.png Sorry I don't have it in textual form.
bug#44027: [PATCH] installer: Create bios_grub partition when it is needed.
On 17/10/20 11:09 pm, Miguel Ángel Arruga Vivas wrote: [...] The attached patch solves that. What do you think? Happy hacking, Miguel I have tested the patch and the Installer mostly worked. One thing I noticed is that the partition scheme I was given automatically looks like this: 1 537MB fat32 boot,esp /boot/efi EFI System Partition 2 3146Kb ext4 bios_grub 3 2001MB linux-swap 4 37.5GB ext4 / It is creating the bios_grub partition, but the EFI is still being made also. Is that necessary? --- After completing the install, I was able to make it to the next bug!: https://issues.guix.gnu.org/44054
