bug#56030: The guix pull profile is too big

bug#56030: The guix pull profile is too big

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

Hi Guix!

I figured out this morning that my guix pull profile ("current") was more than 1GB. Looking at the closure, I found a few oddities.

There's gcc in there, which is the second most important contributor after guix-*-modules (150 MB). It's referenced by gcc-toolchain, itself only referenced by the guile-wrapper we build in (guix self). Can we get rid of it?

There are three versions of guile (50 MB each). Can we settle for only one?

Then maybe less important because they're small:

There are two libffi, gzip, zlib, libgc, bash-minimal, xz, pkg-config and libunistring.

We have bash-minimal and bash-static. The latter is a bit bigger than the former. Maybe we can keep only bash-minimal?

[-- Attachment #2: Type: text/html, Size: 780 bytes --]

bug#56030: The guix pull profile is too big

[Ludovic Courtès]

Hi,

Julien Lepiller <julien@lepiller.eu> skribis:

> I figured out this morning that my guix pull profile ("current") was more than 1GB. Looking at the closure, I found a few oddities.

Specifically:

--8<---------------cut here---------------start------------->8---
$ guix describe
Generation 219  Jun 20 2022 09:40:20    (current)
  guix 73761d8
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 73761d8049f483e6685c2c736872d0366e03238a
$ guix size $(readlink -f ~/.config/guix/current)
store item                                                       total    self
/gnu/store/rfkyfhdj3zq6lzlw7n0y5m36pdcfd2s7-guix-73761d804-modules   554.6   220.8  27.5%
/gnu/store/249mczqf0jv55a7df9v3a3314mrwjg61-guix-packages-base     123.9   123.9  15.5%
/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8            130.0    53.0   6.6%
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7            129.1    52.0   6.5%
/gnu/store/jv3gkqapz7fxgpjzp7g6rlpfl3fb2pq9-guix-system             51.2    51.2   6.4%
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33              38.3    36.6   4.6%
/gnu/store/cwxfvi0890wwmhigk84iiq1dh64x0ac9-guix-packages-base-source    34.2    34.2   4.3%
/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib          71.7    33.4   4.2%
/gnu/store/3db8s5gn3srsdrzrdz4d0xpxpfhlb3h5-guix-extra              25.7    25.7   3.2%
/gnu/store/bnsf9il448hl5xjavbhq3rcx355svz2v-glib-2.70.2             98.1    15.3   1.9%
/gnu/store/mw3py6smb1pk8yx298hd9ivz9lzbksqi-glibc-utf8-locales-2.33    13.9    13.9   1.7%
/gnu/store/7nlzk7n90ib3llblxlpz725ym3k05gdj-util-linux-2.37.2-lib    80.7     9.0   1.1%
/gnu/store/pyaxxsi4207awhpppqf1br6gl03k47pz-guix-package-cache       6.4     6.4   0.8%
/gnu/store/cyx97f0bx4nki07l52jzw3lng0mzcdcv-guix-cli-core            6.4     6.4   0.8%
/gnu/store/2rdmiv3k11qxz13fjq5bipljwjz0r6ws-guix-manual              6.0     6.0   0.8%
/gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-6.2.20210619    77.6     5.9   0.7%
/gnu/store/zl9wf0zwq2ka9rpmayp53hnp2mn460xf-gnutls-3.7.2           143.4     5.6   0.7%
/gnu/store/xgp23kc3v9w7l10grjwd0n1a74v3fhx3-openssl-1.1.1n          77.2     5.5   0.7%
/gnu/store/il571kvl9fs08xag4hyg6x8hm57akscm-guile-git-0.5.2        100.5     5.2   0.6%
/gnu/store/dyd5gaxzrngl6m9clniq5y1r7yl463h1-guix-system-tests        4.3     4.3   0.5%
/gnu/store/fg76cjzdk413dfkx50fkcwd3wpbyfpi1-pcre2-10.37             84.6     4.0   0.5%
/gnu/store/ffynx7n76vb5rby4b14yjcacqwq1w70h-mit-krb5-1.19.2         82.2     3.9   0.5%
/gnu/store/v06gnr579r0jmr36aha3wkbd1y27ccg7-disarchive-0.4.0       139.1     3.8   0.5%
/gnu/store/x1jd7pqfn9ilb6x97azcfq1fhjr63p0z-p11-kit-0.23.22         76.4     3.4   0.4%
/gnu/store/xmzx5mzv4863yw9kmr2ykndgp37p8if0-sqlite-3.36.0           82.3     3.2   0.4%
/gnu/store/x1x1sw727g7ls93av3i27mkd90s4wgd7-guix-home                3.2     3.2   0.4%
/gnu/store/jkd4zlfq4rph31xazz132cf0skg6km00-guix-cli                 3.1     3.1   0.4%
/gnu/store/v8raqm2shh9azkl71107p53j55hir306-libxcb-1.14             75.3     3.0   0.4%
/gnu/store/ssfq7hv5bhas830cs29fk271brcn3vqi-guile-lib-0.2.7          2.9     2.9   0.4%
/gnu/store/g2ajyl8xk9aarxrgjbng2hkj3qm2v0z2-tar-1.34                75.6     2.9   0.4%
/gnu/store/fa43ijbrb96x08621qigxxiphp503lsi-libx11-1.7.3.1          78.2     2.8   0.4%
/gnu/store/fwbiihd2sbhai63y1pvvdh0f2bakfzrf-gmp-6.2.1               74.4     2.7   0.3%
/gnu/store/yqr33jyy81fdqmr8rd4gvbpisbad2w2l-guix-extra-source        2.5     2.5   0.3%
/gnu/store/4rqq5sl8n85ywfwqdv0f1xjaw9vhgl8k-guix-system-source       2.4     2.4   0.3%
/gnu/store/hkhbq2q1gfs970gsp2nhsmcqb4vmv2xr-libunistring-0.9.10     74.0     2.3   0.3%
/gnu/store/f058zn04xla5jndkhxl0s20pbl61bckq-guile-bytestructures-1.0.10     2.1     2.1   0.3%
/gnu/store/n0sd9hghs18pjsj72023r1spa9wxccc2-libevent-2.1.12         73.8     2.1   0.3%
/gnu/store/m7vwbbsy3pkpi4rpdnvr8m4jc8y36ckn-libgit2-1.3.0           95.4     2.0   0.2%
/gnu/store/xggzgd4xwsy5p02wdfngk67j7zpp91gb-guile-ssh-0.15.1       144.9     1.9   0.2%
/gnu/store/03g49nffc73vrmx5180p4fhr3z4mfk0z-avahi-0.8              111.8     1.7   0.2%
/gnu/store/r08q5kq8hy5621y3yk0c7zrxb9s514z4-guix-locale-guix         1.7     1.7   0.2%
/gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8        1.7     1.7   0.2%
/gnu/store/di5bqb45hi5lvp2q08hlxqjdcl9phjb1-pcre-8.45               73.4     1.7   0.2%
/gnu/store/wcwls45278gzpjvwlvrrs1y7h30g44xh-readline-8.1.1          79.0     1.4   0.2%
/gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8         75.1     1.4   0.2%
/gnu/store/60jl4xry9c93j9l0rr7nkvbw7dihjz4k-guile-gcrypt-0.3.0      76.5     1.4   0.2%
/gnu/store/3x3dl71d4xm6y4hjwq110hmfyfx0xc6j-zstd-1.5.0-lib          72.9     1.2   0.2%
/gnu/store/2b3blhwbag1ial0dhxw7wh4zjxl0cqpk-pkg-config-0.29.2       72.8     1.1   0.1%
/gnu/store/yl859fgb86zgl0zsvbhxdpms945aazip-dbus-1.12.20            79.6     1.1   0.1%
/gnu/store/aggsb6j1svxp70xlll4rqnx5f2pzz794-xz-5.2.5                73.7     1.1   0.1%
/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5                73.7     1.1   0.1%
[…]
/gnu/store/vjf3hvajws01wmm5rwbkgw7z0jvl6v3h-guix-command           788.6     0.0   0.0%
/gnu/store/hsynjf6csram52x9ampnb90ysdbipdk2-emacs-subdirs            0.0     0.0   0.0%
/gnu/store/yyqqi3kp61r9sjqhhay85in0h5s8dzs8-guix-daemon            789.4     0.0   0.0%
total: 802.0 MiB
--8<---------------cut here---------------end--------------->8---

50% goes into Guix modules.  There’s prolly room for improvement because
the ‘guix-COMMIT-modules’, which is #1, is actually the union of all the
other guix-*-modules.

> There's gcc in there, which is the second most important contributor after guix-*-modules (150 MB). It's referenced by gcc-toolchain, itself only referenced by the guile-wrapper we build in (guix self). Can we get rid of it?

I think you fixed that one in 319b8331b2357e12ec9edb9665513c32bef56622.
\o/

> There are three versions of guile (50 MB each). Can we settle for only one?

I think that’s (@ (gnu packages commencement) guile-final), guile-3.0,
and guile-3.0-latest.  However I see only two of them here.

--8<---------------cut here---------------start------------->8---
$ guix graph --path -t references $(readlink -f ~/.config/guix/current) /gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8
/gnu/store/njzk97pz238fcjjpjk2vzdv5rgs6s54v-profile
/gnu/store/vp1m80lj2g6391xi95f056yra7xfb47i-guix-73761d804
/gnu/store/vjf3hvajws01wmm5rwbkgw7z0jvl6v3h-guix-command
/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8
$ guix graph --path -t references $(readlink -f ~/.config/guix/current) /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7
/gnu/store/njzk97pz238fcjjpjk2vzdv5rgs6s54v-profile
/gnu/store/vp1m80lj2g6391xi95f056yra7xfb47i-guix-73761d804
/gnu/store/yyqqi3kp61r9sjqhhay85in0h5s8dzs8-guix-daemon
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7
$ head -3 /gnu/store/yyqqi3kp61r9sjqhhay85in0h5s8dzs8-guix-daemon
#!/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/bin/guile --no-auto-compile
!#
(begin (setenv "GUIX" "/gnu/store/vjf3hvajws01wmm5rwbkgw7z0jvl6v3h-guix-command") (unless (getenv "GUIX_STATE_DIRECTORY") (setenv "GUIX_STATE_DIRECTORY" "/var/guix")) (unless (getenv "GUIX_CONFIGURATION_DIRECTORY") (setenv "GUIX_CONFIGURATION_DIRECTORY" "/etc/guix")) (unless (getenv "NIX_STORE_DIR") (setenv "NIX_STORE_DIR" "/gnu/store")) (apply execl "/gnu/store/jmqzsqpgnxrvzpdyx4dglvz9f40b81xm-guix-daemon-1.3.0-27.598f728/bin/guix-daemon" "guix-daemon" (cdr (command-line))))
--8<---------------cut here---------------end--------------->8---

Fixed this one in commit d418031a8cbdea4e2bc5c52ea1b29ad369579bae.

But then, ‘guile-3.0’ being the default, it’s used in a number of
places, like:

--8<---------------cut here---------------start------------->8---
$ guix graph -t references --path /gnu/store/6f58rzr1xi8h43l6l8gsm4paravqnnjz-guix-20220626.13 /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7
/gnu/store/6f58rzr1xi8h43l6l8gsm4paravqnnjz-guix-20220626.13
/gnu/store/00kkky8qxa73qv8g8y60y5gjz0l4hpmk-guix-command
/gnu/store/m3pdqa0crnvblllvkdjbda42k0rwxn9c-guix-module-union
/gnu/store/v06gnr579r0jmr36aha3wkbd1y27ccg7-disarchive-0.4.0
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7
--8<---------------cut here---------------end--------------->8---

I can’t think of a good solution to this.

> Then maybe less important because they're small:
>
> There are two libffi, gzip, zlib, libgc, bash-minimal, xz, pkg-config and libunistring.
>
> We have bash-minimal and bash-static. The latter is a bit bigger than the former. Maybe we can keep only bash-minimal?

That’s probably due to the fact that there are multiple Guile variants;
annoying.

It’s worth keeping in mind that thanks to deduplication, this costs much
less than it seems in terms of disk space, but it does cost in terms of
bandwidth usage.

Thanks,
Ludo’.

bug#56030: The guix pull profile is too big

[Maxime Devos]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 851 bytes --]


On 17-06-2022 07:48, Julien Lepiller wrote:
> We have bash-minimal and bash-static. The latter is a bit bigger than 
> the former. Maybe we can keep only bash-minimal? 

bash-static is used by glibc (for the 'system' function), it's not 
something that can simply be replaced with bash-minimal (due to the 
cycle bash-minimal -> glibc -> bash-minimal that would result). I do 
have a proposal eliminating the bash-static reference though:

  * replace the 'system' function from glibc by a variant that accepts
    the file name of the shell executable
  * Add a macro '#define system ...' that calls this variant and inserts
    __guix_bin_sh as the shell executable
  * In the build system, look for bin/sh in the inputs.  If it exists,
    add -D__guix_bin_sh=/gnu/store/.../bin/sh to
    CFLAGS or such.

Greetings,
Maxime


[-- Attachment #1.1.1.2: Type: text/html, Size: 1341 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

On Thu Jul 21, 2022 at 3:52 PM BST, Maxime Devos wrote:
>   * Add a macro '#define system ...' that calls this variant and inserts
>     __guix_bin_sh as the shell executable

Would this not violate POSIX? Since, as far as I can see,
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html>
does not give the implementation license to implement system(3) as a
macro. We could do

```
int system(const char *command) {
	return __guix_run_in_shell(command, __guix_bin_sh);
}
```

though.

    -- (

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

And considering the definition of system(3) in glibc:

@ sysdeps/posix/system.c (took me way too long to find this; glibc's
source code is a maze ;))
```
#define SHELL_PATH	"/bin/sh"	/* Path of the shell.  */
#define SHELL_NAME	"sh"		/* Name to give it.  */
```

couldn't we just use `-DSHELL_PATH=/gnu/store/...`?

    -- (

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

On Thu Jul 21, 2022 at 4:03 PM BST, paren--- via Bug reports for GNU Guix wrote:
> Would this not violate POSIX?
Correction: system(3) is ISO C, not POSIX.

But:

@ C11 7.1.4p1
```
... it is permitted to take the address of a library function even if it
is also defined as a macro ^185 ...

185) This means that an implementation shall provide an actual function
for each library function, even if it also provides a macro for that
function.
```

Note the footnote. So this technically would be a violation of ISO C,
but trivially fixed. Apologies for the noise! (Though the SHELL_PATH
solution still applies, of course.)

    -- (

bug#56030: The guix pull profile is too big

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

We're trying to avoid hard-coding bash-static in glibc, instead letting the build-system fill the value in dependents. So that can't be it, right?

Le 21 juillet 2022 17:11:56 GMT+02:00, "(" <paren@disroot.org> a écrit :
>
>And considering the definition of system(3) in glibc:
>
>@ sysdeps/posix/system.c (took me way too long to find this; glibc's
>source code is a maze ;))
>```
>#define SHELL_PATH	"/bin/sh"	/* Path of the shell.  */
>#define SHELL_NAME	"sh"		/* Name to give it.  */
>```
>
>couldn't we just use `-DSHELL_PATH=/gnu/store/...`?
>
>    -- (

[-- Attachment #2: Type: text/html, Size: 850 bytes --]

bug#56030: The guix pull profile is too big

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 1112 bytes --]


On 21-07-2022 17:11, ( wrote:
> couldn't we just use `-DSHELL_PATH=/gnu/store/...`?

Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But 
it's not 'just use -DSHELL_PATH=', we still need to change 'system' 
appropriately.

> Would this not violate POSIX? Since, as far as I can see,
> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html>
> does not give the implementation license to implement system(3) as a
> macro.
Probably. But does that really matter?  The standard exists for a 
reason, but we aren't aiming for POSIX certifications and it isn't the 
law or something ... seems rather inconvenient for development outside a 
build environment though, so perhaps SHELL_PATH could somehow fallback 
to /bin/sh when outside a build environment.
>   We could do
>
> ```
> int system(const char *command) {
> 	return __guix_run_in_shell(command, __guix_bin_sh);
> }

Needs a 'static' to avoid multiple definitions on the same thing, but 
yes, that would avoid the macro problem (though not sufficient for some 
FFI).

Greetings,
Maxime.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

On Thu Jul 21, 2022 at 4:42 PM BST, Julien Lepiller wrote:
> We're trying to avoid hard-coding bash-static in glibc, instead letting the build-system fill the value in dependents. So that can't be it, right?
How would it be any different from -D__guix_bin_sh=...? That argument
would simply be filled in by the build system.

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:
> Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But 
> it's not 'just use -DSHELL_PATH=', we still need to change 'system' 
> appropriately.
Why would we need to change it? The glibc definition already uses that
macro for the shell path, it's just hard-coded to /bin/sh by default.

bug#56030: The guix pull profile is too big

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

I must have misunderstood, I thought you wanted to pass it during the build of glibc.

Le 21 juillet 2022 17:49:36 GMT+02:00, "(" <paren@disroot.org> a écrit :
>On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:
>> Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But 
>> it's not 'just use -DSHELL_PATH=', we still need to change 'system' 
>> appropriately.
>Why would we need to change it? The glibc definition already uses that
>macro for the shell path, it's just hard-coded to /bin/sh by default.

[-- Attachment #2: Type: text/html, Size: 931 bytes --]

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

Oh! I understand now! The __guix_bin_sh macro would actually be included
in the expansion, not defined during the glibc build. Sorry (again) for
the noise!

    -- (

bug#56030: The guix pull profile is too big

[Maxime Devos]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 715 bytes --]


On 21-07-2022 17:49, ( wrote:
> On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:
>> Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But
>> it's not 'just use -DSHELL_PATH=', we still need to change 'system'
>> appropriately.
> Why would we need to change it? The glibc definition already uses that
> macro for the shell path, it's just hard-coded to /bin/sh by default.

If we modify the SHELL_PATH to point to 
/gnu/store/...-bash-minimal-.../bin/sh, then glibc has a reference to 
bash-minimal. But bash-minimal uses glibc, so bash-minimal would have a 
reference to glibc. So you would have to end up with a cycle, which is 
impossible in Guix.

Greetings,
Maxime.


[-- Attachment #1.1.1.2: Type: text/html, Size: 1472 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

Okay, another (hopefully more coherent) proposal: Patch in a

```
extern char *__guix_shell_path;
```

And then, we use a linker script to provide the definition of
__guix_shell_path at linking time. (Unfortunately there's no way to do
this with a flag, afaik...)

    -- (

bug#56030: The guix pull profile is too big

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 645 bytes --]


On 21-07-2022 18:13, ( wrote:
> Okay, another (hopefully more coherent) proposal: Patch in a
>
> ```
> extern char *__guix_shell_path;
> ```
>
> And then, we use a linker script to provide the definition of
> __guix_shell_path at linking time. (Unfortunately there's no way to do
> this with a flag, afaik...)

We could compile a '__guix_shell_path = "/..."' during the compilation 
of the package (as a .o) and wrap gcc to insert it to the CLI arguments, 
no linker scripts required.  Not all linkers support linker scripts, 
e.g. mold doesn't from what I've read because they make the linker slower.

Greetings,
Maxime.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

> We could compile a '__guix_shell_path = "/..."' during the compilation 
> of the package (as a .o) and wrap gcc to insert it to the CLI arguments, 
> no linker scripts required.
Alas, for some reason I couldn't find any documentation on how to define
strings in a linker script. But never mind that, since that's a far
better idea :)

> Not all linkers support linker scripts, e.g. mold doesn't from what I've
> read because they make the linker slower.
Would we really need to support anything other than ld, gold, and lld,
though?

    -- (

bug#56030: The guix pull profile is too big

[Maxime Devos]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 925 bytes --]


On 21-07-2022 18:29, ( wrote:
>> Not all linkers support linker scripts, e.g. mold doesn't from what I've
>> read because they make the linker slower.
> Would we really need to support anything other than ld, gold, and lld,
> though?
>
>      -- (


We can choose to not package mold of course, but I think it would be a 
good idea to support mold, because it appears to be much faster than the 
others. Furthermore, I'd like to eventually switch to mold by default, 
because it's much faster.  From the README:

mold is so fast that it is only 2x /slower/ than |cp| on the same 
machine. Feel free to file a bug <https://github.com/rui314/mold/issues> 
if you find mold is not faster than other linkers.

Program (linker output size) 	GNU gold 	LLVM lld 	mold
Chrome 96 (1.89 GiB) 	53.86s 	11.74s 	2.21s
Clang 13 (3.18 GiB) 	64.12s 	5.82s 	2.90s
Firefox 89 libxul (1.64 GiB) 	32.95s 	6.80s 	1.42s


[-- Attachment #1.1.1.2: Type: text/html, Size: 2030 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

bug#56030: rfc2822 permits that left paren, but why do it? -- was Re: bug#56030: The guix pull profile is too big

[bokr]

Hi "(" aka paren :)

On +2022-07-21 16:03:19 +0100, paren--- via Bug reports for GNU Guix wrote:
[ ... ]
> 
>     -- (
> 
Are you hoping for some effect on a pre-rfc2822 parser??

Just curious :)
--
Regards,
Bengt Richter

bug#56030: The guix pull profile is too big

[zimoun]

Hi,

On Sun, 26 Jun 2022 at 23:20, Ludovic Courtès <ludo@gnu.org> wrote:

>> There are two libffi, gzip, zlib, libgc, bash-minimal, xz, pkg-config and libunistring.

> It’s worth keeping in mind that thanks to deduplication, this costs much
> less than it seems in terms of disk space, but it does cost in terms of
> bandwidth usage.

As shown in [1], note that deduplication is defeated by packages with
multi-outputs impacted by grafted ones.  For example, if one dependency
of bash-minimal is grafted, then two store items of bash-minimal (with
the same content) could live in the store and thus the reduction cost of
disk space is mitigated.

1: <https://yhetil.org/guix/874jy87gcl.fsf@gmail.com>


Cheers,
simon