bug#45675: Zip-based archives store timestamps

Hi, Julien Lepiller writes: > For java packages, we have a strip-jar-timestamps phase in the > ant-build-system. Thanks for the pointer. Do you think could be worth to extract that into (guix build utils) as the attached patch (WIP) does? It rebuilds the world and replaces all of "old usages

bug#45676: Store references inside compressed data

Hi! Tobias Geerinckx-Rice writes: > It's true. It's a known trade-off of an otherwise almost-zero-effort > yet fast reference scanner. I don't think it's a bug per se, but it > is something of which to be aware. > > Let's stop installing compressed executables & data files. We already > avoid

bug#45676: Store references inside compressed data

Hi Ludo and Leo, Ludovic Courtès writes: > Hi, > > Leo Famulari skribis: > >> On Tue, Jan 05, 2021 at 03:36:07PM +0100, Miguel Ángel Arruga Vivas wrote: >>> There are several binary formats that allow compression of the >>> executable image, or some of its

bug#45676: Store references inside compressed data

There are several binary formats that allow compression of the executable image, or some of its data, which is decompress at runtime: - Kernel images. - Compressed libraries: e.g. Smalltalk modules. - Compressed executable or data files: e.g. library.el.gz. These aren't taken into account b

bug#45675: Zip-based archives store timestamps

A procedure like reset-gzip-timestamp should be useful for reproducibility purposes, adapted to zip based archives as Smalltalk's STAR or Java's JAR binary formats, as some or all of their contents are generated usually at build time. On the latest Zip specification[1], which only seem to be encum

bug#45674: Smalltalk 3.2.91 isn't reproducible

The following issues are shown after a diffoscope call: * Generated files and folders included into .star files (zip format) contain a different timestamp each execution: --- start of diffoscope output -- │ │ │ --- b1/share/smalltalk/CParser.star │ │ ├─

bug#42771: smalltalk fails to build

Bonne année, Ludo! Ludovic Courtès writes: >> From c4385abde62bba4c634a7a874c2f431451909ec2 Mon Sep 17 00:00:00 2001 >> From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?= >> >> Date: Mon, 28 Dec 2020 10:36:48 +0100 >> Subject: [PATCH 1/2] gnu: smalltalk: Fix integer multiplication overflow

bug#42771: smalltalk fails to build

Hi, I've been investigating just a bit about this. Ludovic Courtès writes: > (1) investigate why the test is failing (I think it’s a single test > failure here), Currently there are two main problems with 3.2.5: - Integer multiplication overflow handling invokes undefined behavior, whic

bug#25305: bug#37851: bug#25305: bug#37851: Grub installation only checks for encrypted /boot folder

Hi Ludo, First of all, thanks for your review. :-) Ludovic Courtès writes: > Hi Miguel, > > Miguel Ángel Arruga Vivas skribis: >> + (define (crypto-devices) >> +(define (crypto-device->cryptomount dev) >> + (if (uuid? dev) >> +

bug#26247: Gettext introduces timestamps in .mo files

Hi! Ludovic Courtès writes: > Julien Lepiller skribis: > >> So it's not gettext itself, but our build system that generates the >> en@quote and en@boldquote files. Do we really need them? If so, we >> should find a way to generate them reproducibly. > > They’re generated automatically by the ge

bug#25508: bug#25304: bug#25508: Git hook shebangs should not be rewritten

Marius Bakke writes: > Miguel Ángel Arruga Vivas writes: > >> The attached patch fixes this one too, should I push it to master (as >> the last change for git) or to core-updates or staging (as it might seem >> looking at the dependencies)? > > LGTM. Git (+

bug#25304: bug#25508: Git hook shebangs should not be rewritten

Sorry, I've closed this with the libtool one. The attached patch fixes this one too, should I push it to master (as the last change for git) or to core-updates or staging (as it might seem looking at the dependencies)? Happy hacking! Miguel From 9f0e9eea6d7c338fba234c2f8935ba76b1d94b2c Mon Sep 17

bug#25304: Libtool’s ltmain.sh still contains a /gnu/store shebang

Hi! Ludovic Courtès writes: > Hi! > > Miguel Ángel Arruga Vivas skribis: > >> I was looking through the lists because I have a patch that does exactly >> what you describe here. I guess this goes to core updates, so this >> version is on top of it. WDYT? > >

bug#43579: g++ does not provide std::fegetround

Hi! Ludovic Courtès writes: >[...] > It’s the same story as . >[...] > So this is again #include_next not picking the right due to > search path ordering issues and/or duplicate entries. > > Thoughts anyone? > > I think we need a proper fix but the feedback we

bug#25304: Libtool’s ltmain.sh still contains a /gnu/store shebang

Hi, I was looking through the lists because I have a patch that does exactly what you describe here. I guess this goes to core updates, so this version is on top of it. WDYT? Happy hacking! Miguel l...@gnu.org (Ludovic Courtès) writes: > Hi, > > Commit 98341757c8c45fca8d2b53f9972f5c6a32cf2c95,

bug#44455: [ARTWORK] website: Not enough context for translation of None

diff --git a/website/po/es.po b/website/po/es.po index b845aa2..2658eae 100644 --- a/website/po/es.po +++ b/website/po/es.po @@ -7,10 +7,10 @@ # * Feed se traduce como tablón [de anuncios] cuando es posible. msgid "" msgstr "" -"Project-Id-Version: guix-website 20201005\

bug#44455: [ARTWORK] website: Not enough context for translation of None

The string "None" does not have enough context and can lead to wrong translations, as the word or even the gender may differ for each one. This change also will invalidate the current translation. The code fragment where it is used is included as reported in other thread: "pelzflorian (Florian Pe

bug#44196: [PATCH 2/3] system: Add store-directory-prefix to boot-parameters.

Hello, Ludovic Courtès writes: > (Btrfs no0b here.) Does that mean that /gnu is like a bind-mount of > /gnufs in this case? Yes, it's exactly like that for the end user, but that use case isn't implemented yet---it should be useful too for the Hurd and translators---so I have it under my radar.

bug#43879: Problem with graphical installer

Hi Mathieu, Mathieu Othacehe writes: > "All its data will be lost" refers to the hard drive. Maybe we should > say "Their data will be lost", referring to the partitions? Thanks for the review, I overlooked that. > Otherwise, looks nice. Pushed as bc9e66f0feb25c77898222cfe5f3ef484dcee95e with

bug#44196: [PATCH 2/3] system: Add store-directory-prefix to boot-parameters.

I've pushed this last patch as 582cf9257cd1f9c969fbba5eb1c336ac8b975cde with the following additions: - A pointer to this issue in the commit message. - A description of store-directory-prefix on the commit message. - A better version (I hope) of the comment inside . Thank you very much! Miguel

bug#44196: [PATCH v6 3/4] system: Do not depend on locale folder generated by

¡Hola, Ludo! Thanks for your comments. Reviewing them I found some more issues that I address inline: Ludovic Courtès writes: > Miguel Ángel Arruga Vivas skribis: > >> From 5886bdf74bda59649b3d17b691132d9d030e0fb4 Mon Sep 17 00:00:00 2001 >> From: =?UTF-8?q?Miguel=20=

bug#44196: [PATCH 2/3] system: Add store-directory-prefix to boot-parameters.

prefix boot-parameters-store-directory-prefix) ------ WDYT? Happy hacking! Miguel Miguel Ángel Arruga Vivas writes: > Hi Ludo! > > First of all, thanks for the review. > > Ludovic Courtès writes: >> Could you explain why we need ‘store-directory-prefix’ in addition

bug#44196: [PATCH 2/3] system: Add store-directory-prefix to boot-parameters.

Hi Ludo! First of all, thanks for the review. Ludovic Courtès writes: > Could you explain why we need ‘store-directory-prefix’ in addition to > ‘store-mount-point’? At first sight, looking at the fields in there, > these two can seem to be synonymous. The difference is subtle unless you use bt

bug#43879: Problem with graphical installer

Hi, I CC the list, as we are currently on freeze, but this might require a fix or at least a big explanation somewhere, my bad for not answering soon enough. :-( Marinus Savoritias writes: > Hi, > > The steps that I followed were: > > 1. Use guided installation using full disk with graphical ins

bug#44196: [PATCH v6 3/4] system: Do not depend on locale folder generated by

I hope this is the last one, at least for bug fixes. This version uses the right name for the autogenerated file e...@quot.mo when no image is provided. Miguel Ángel Arruga Vivas writes: > Changes w.r.t. previous version: > - Call normalize-file (the parameters were there but I lost th

bug#44196: [PATCH 1/3] system: Fix grub keymap with store in btrfs subvolume.

Hi Danny, Thank you a lot for taking a look into this. :-) Danny Milosavljevic writes: > Is it possible for there to be no entries in all-entries at all? This is the idiom used in the rest of the file, and that would be a bug in the calling code. The entries are the operating system generation

bug#44196: [PATCH 4/3] system: Fix dependency for grub.cfg generation.

Danny Milosavljevic writes: > This patch LGTM! Thanks for your review, pushed as 222a630e9e. Happy hacking! Miguel signature.asc Description: PGP signature

bug#44196: [PATCH v5 3/4] system: Do not depend on locale folder generated by

Changes w.r.t. previous version: - Call normalize-file (the parameters were there but I lost the call). - Only call search when there is no image configured. >From 3eb494947ed863e60d3d49d4ac4a982b1f9237e3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?= Date: Sa

bug#37851: bug#25305: bug#37851: Grub installation only checks for encrypted /boot folder

;;; Copyright © 2017, 2020 Mathieu Othacehe ;;; Copyright © 2019, 2020 Jan (janneke) Nieuwenhuizen -;;; Copyright © 2019 Miguel Ángel Arruga Vivas +;;; Copyright © 2019, 2020 Miguel Ángel Arruga Vivas ;;; Copyright © 2020 Maxim Cournoyer ;;; Copyright © 2020 Stefan ;;; @@ -360,11 +

bug#44196: [PATCH v4 3/4] system: Do not depend on locale folder generated by

Sorry, the last one didn't generate correctly the locale folder for two reasons: wrong name for the .mo name, and incomplete path. >From 37ef6594c6db00595b4e3aec6bcaec3eb9b4e1cf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?= Date: Sat, 24 Oct 2020 20:36:21 +0200

bug#44196: [PATCH 4/3] system: Fix dependency for grub.cfg generation.

One extra bit :-) * The keymap was depending on the exported package grub, not on the one provided by the bootloader configuration, so e.g. systems that use grub-efi also ended up with grub in their dependency graph. This patch solves that issue. >From ae2d83f91d522b5b0edfe1abbe88dec0a797235c Mo

bug#25305: bug#37851: Grub installation only checks for encrypted /boot folder

44 --- a/gnu/bootloader/grub.scm +++ b/gnu/bootloader/grub.scm @@ -4,7 +4,7 @@ ;;; Copyright © 2017 Leo Famulari ;;; Copyright © 2017, 2020 Mathieu Othacehe ;;; Copyright © 2019, 2020 Jan (janneke) Nieuwenhuizen -;;; Copyright © 2019 Miguel Ángel Arruga Vivas +;;; Copyright © 2019, 2020 Miguel

bug#44196: [PATCH 3/3 v3] system: Do not depend on locale folder generated by grub-install.

This version doesn't modify grub package at all, and it only generates the folder when needed, and fixes a bug in Grub 2.04 that I didn't noticed until I started playing with the installer: https://savannah.gnu.org/bugs/?57889 Happy hacking! Miguel >From 770532b931c312edb9f9a075d86dc132b804dc0b Mo

bug#43960:

Hi, I'm hitting this while testing some patches too. [env]$ make check-system TESTS=encrypted-root-and-boot-os [...] successfully built /gnu/store/32qhcfz3amwq9zisqnagdvrlpl3lr82a-guix-system-tests-modules.drv building /gnu/store/dsq1i6hfhqnx25gsa5m00q9a7d1vshql-module-import-compiled.drv... [

bug#44196: [PATCH 3/3 v2] gnu: grub: Add locale output.

This v2 doesn't change the other patches, only this one, because it was the one I wasn't happy with. It changes from v1 as the separate output "locale" is not generated, but instead the mo files are placed into share/locale with the expected names. >From c8aff861461b599095d55b9f694e074d433c72bb M

bug#44196: [PATCH 3/3] gnu: grub: Add output locale

Hi! This solves Grub localization too, even though I'm not very happy with the gexp juggling... Any idea? Happy hacking! Miguel >From 333a12f2eff427986efd0ed660fff7d7bb113839 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?= Date: Sat, 24 Oct 2020 20:36:21 +0200

bug#44196: [PATCH 2/3] system: Add store-directory-prefix to boot-parameters.

>From 527a9271122f7b83f31dc0b910c6704af81bde66 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?= Date: Sat, 24 Oct 2020 18:15:53 +0200 Subject: [PATCH 2/2] system: Add store-directory-prefix to boot-parameters. * gnu/machine/ssh.scm (roll-back-managed-host): Use boo

bug#44196: [PATCH 1/3] system: Fix grub keymap with store in btrfs subvolume.

>From b310cb18021e421be3256b85ab3f2d8f61fe0ab8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?= Date: Sat, 24 Oct 2020 17:48:28 +0200 Subject: [PATCH 1/2] system: Fix grub keymap with store in btrfs subvolume. * gnu/bootloader/grub.scm (grub-configuration-file) [ke

bug#44196: Problems with /gnu/store in a different btrfs subvolume

I've been testing the installation and the use case for separate btrfs subvolumes, so I created two different btrfs subvolumes for the root file system (/rootfs) and the store (/storefs), and installed with guix system init and a basic operating-system configuration. The problems detected were:

bug#41764: `make authenticate` fails to find the keyring branch

Hi Ludo, Thanks for the quick revision. Ludovic Courtès writes: >> # Authenticate the current Git checkout by checking signatures on every >> commit. >> +GUIX_GIT_KEYRING = origin/keyring > > You need “?=” or users won’t be able to override it. The macro definitions provided through the comma

bug#41764: `make authenticate` fails to find the keyring branch

Hi, Ludovic Courtès writes: > Hi, > > Leo Famulari skribis: > >> I just tried pushing for the first time since installing the new >> pre-push hook that runs `make authenticate`. >> >> This failed with the following error: >> >> Git error: cannot locate remote-tracking branch 'keyring' >> >> Howe

bug#44027: [PATCH] installer: Create bios_grub partition when it is needed.

Hi, Mathieu Othacehe writes: > Hello Miguel, > >> Is there any other issue remaining? It doesn't modify this logic at >> all. Should I apply this patch to master then? > > Yes, your patch LGTM. Please make sure that system tests are still > working by running: > > make check-system TESTS="gui-i

bug#43879: Problem with graphical installer

Hi Marinius, Marinus Savoritias writes: > If you follow the guided graphical install guix will fail to > reconfigure afterwards. > > Everytime you will reconfigure it will say no space left on device. On > /boot. The default installation should not create a separate /boot partition, only creates

bug#44027: [PATCH] installer: Create bios_grub partition when it is needed.

Hi Mathieu, Mathieu Othacehe writes: > Hello Brendan, > >> I feel the installer should not care what was on the drive to begin with, it >> should just >> format the drive how it sees fit. Why should the existing contents of the >> drive >> affect the outcome when we are reformatting everything an

bug#44027: [PATCH] installer: Create bios_grub partition when it is needed.

Hi! Brendan Tildesley writes: > 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 &

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.