unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Marius Bakke <mbakke@fastmail.com>
To: Mark Wielaard <mark@klomp.org>
Cc: Brett Gilio <brettg@gnu.org>, 38803@debbugs.gnu.org
Subject: [bug#38803] [PATCH] gnu: elfutils: Update to 0.178
Date: Mon, 13 Jan 2020 23:26:48 +0100	[thread overview]
Message-ID: <87a76rvvpz.fsf@devup.no> (raw)
In-Reply-To: <20200113000345.GA2825@wildebeest.org>

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

Mark Wielaard <mark@klomp.org> writes:

> Hi,
>
> On Sun, Jan 12, 2020 at 09:54:52PM +0100, Marius Bakke wrote:
>> Mark Wielaard <mark@klomp.org> writes:
>> 
>> > This introduces debuginfod support which requires a couple of new inputs.
>> >
>> > * gnu/local.ml (dist_patch_DATA): Remove elfutils-tests-ptrace.patch.
>> >   Add elfutils-0.178-tests-build-id.patch.
>> > * gnu/packages/elf.scm (elfutils): Update to 0.178
>> >   [native-inputs]: Add iproute and pkg-config.
>> >   [inputs]: Add cpio, libarchive, libmicrohttpd, libcurl, rpm and sqlite.
>> >   [synopsis]: Updated.
>> >   [description]: Updated.
>> >   [license]: List all licenses used.
>> > * gnu/packages/patches/elfutils-tests-ptrace.patch: Removed. Fixed upstream.
>> > * gnu/packages/patches/elfutils-0.178-tests-build-id.patch: New. Patches
>> >   backported from upstream git.
>> 
>> Thank you for these improvements.  Could you submit the synopsis and
>> description update separately?
>
> Sure. Split patch as attached.

Thanks!  The first patch did not apply for me, can you rebase on
'master'?

Also, for the description, please use full sentences.  I.e. keep the
'This package provides a collection ...' and 'This includes ...' instead
of 'A collection ...' and 'Includes ...'.

>> I worry about all the new inputs.  This patch effectively makes us
>> unable to update all these inputs outside of the 'staging' or
>> 'core-updates' cycles.
>
> I am not sure I follow. This is my first patch.  It simply adds some
> inputs needed for a new client/server program added upstream in the
> new version.

OK, thanks for clarifying.

>> What is the difference in 'guix size elfutils' with and without this
>> patch?
>
> $ guix size elfutils
> store item                                                       total    self
> /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29              37.4    35.8  47.2%
> /gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib           70.0    32.6  43.0%
> /gnu/store/w0c5bcygj73chk2f6h0g8zhzpm80p1a5-elfutils-0.176          75.8     3.2   4.2%
> /gnu/store/cp72ncw4prnsga65n3pzll07hpsg524f-bash-static-5.0.7        1.6     1.6   2.1%
> /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7      38.4     1.0   1.4%
> /gnu/store/lbip9isk25isymvnb159l115xnacb5j8-xz-5.2.4                72.0     0.9   1.2%
> /gnu/store/l86azr7r3p5631wj3kk329jl1y1mpjgy-bzip2-1.0.6             71.5     0.4   0.5%
> /gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11             70.2     0.2   0.3%
> total: 75.8 MiB
>
> $ ./pre-inst-env guix size elfutils
> store item                                                       total    self
> /gnu/store/1mkkv2caiqbdbbd256c4dirfi4kwsacv-guile-2.2.6            123.9    44.4  22.7%
> /gnu/store/352q0n1rrymfdk49mfr0cym3d8svz824-icu4c-64.2             108.6    37.5  19.2%
> /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29              37.4    35.8  18.3%
> /gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib           70.0    32.6  16.7%
> /gnu/store/k2m4q2av9hw73hw2jx6qrxqdyh855398-openssl-1.1.1c          76.4     6.4   3.3%
> /gnu/store/hfvz18igm68p5yz7z4asn6ph363blp1z-gnutls-3.6.9           130.6     5.1   2.6%
> /gnu/store/slvjkd3brr6n554r2gk9djsjpm7l7xbs-bdb-5.3.28              74.4     4.4   2.2%
> /gnu/store/4rs159kgsa0l1svi5vbvn86in7z28bpl-mit-krb5-1.17           75.3     4.3   2.2%
> /gnu/store/bjxd9jzc560d6i3i35f5yy5mljk0ib6m-openldap-2.4.47        188.5     3.7   1.9%
> /gnu/store/w8qacdh5fqrzn08wz3n43d0czi00c4c6-elfutils-0.178         195.8     3.6   1.9%
> /gnu/store/y7qk8raalgvdnxcglvxa320cfxrjk1x6-gmp-6.1.2               72.6     2.6   1.3%
> /gnu/store/nsikjxykcaqa0zjpfmkqd569bngbv5nl-libunistring-0.9.10     72.4     2.4   1.2%
> /gnu/store/cp72ncw4prnsga65n3pzll07hpsg524f-bash-static-5.0.7        1.6     1.6   0.8%
> /gnu/store/i1cqaixp79vd3qwnyj1ll10pq6skm2wk-pkg-config-0.29.2       71.3     1.3   0.7%
> /gnu/store/3xs3dnc28p9fi8in7hkfcdx20incrdvq-libgc-7.6.12            71.9     1.2   0.6%
> /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7      38.4     1.0   0.5%
> /gnu/store/4m8dlhrzis07787xznx73ang35c3lly1-curl-7.65.3            190.8     1.0   0.5%
> /gnu/store/lbip9isk25isymvnb159l115xnacb5j8-xz-5.2.4                72.0     0.9   0.5%
> /gnu/store/lvnybsygfd6gya6xbdv48g72lb0iqqzx-nettle-3.5.1            73.5     0.9   0.5%
> /gnu/store/f8aljw2qhv3d1br9czn8v5afbgfdrxkg-cyrus-sasl-2.1.27       83.3     0.9   0.4%
> /gnu/store/2792g0vczwsxnvqm9ja5g9hwvbrjlc4w-gdbm-1.18.1             70.7     0.7   0.4%
> /gnu/store/bvpnq3alwbavyk4663j4p9x9hakxwc4d-libatomic-ops-7.6.10     0.7     0.7   0.4%
> /gnu/store/33f8qhxa69dmd43yqdx3wq1b2hqjddgb-curl-7.65.3-doc          0.7     0.7   0.3%
> /gnu/store/7gabmw9siqrz79slpi1f8i90v3w1638x-libidn2-2.2.0           72.8     0.5   0.2%
> /gnu/store/l86azr7r3p5631wj3kk329jl1y1mpjgy-bzip2-1.0.6             71.5     0.4   0.2%
> /gnu/store/zavdh2z5mwkakjf1v98x43w1hzjzxkhl-nghttp2-1.39.1-lib      70.4     0.4   0.2%
> /gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11             70.2     0.2   0.1%
> /gnu/store/lwz8fygpmmsw6h8vrllr56p7ssi5qx33-libtasn1-4.14           70.2     0.2   0.1%
> /gnu/store/zasz52va238yyaq68rjm8ljwl4ikij4p-libltdl-2.4.6           70.2     0.2   0.1%
> /gnu/store/ain96mrdwqd4s9shdd3s7m4syp5icdx5-libffi-3.2.1            70.1     0.1   0.1%
> total: 195.8 MiB

Oof, that is a *huge* difference.  Do you know where the extra
references come from?  I.e. could we move libelf.so to its own output to
lose some of the runtime dependencies?

Previously 'mesa' was using our other 'libelf' package, but I switched
it to elfutils in commit 9b3b4c05a06bb8ef22350706b66043b5e93d8d66
because that's what "everyone else" do.  Perhaps we should go back to
that, thoughts?  Then we don't have to worry as much about the size of
elfutils.

>> Would it make sense to have a separate 'elfutils-minimal' for use in
>> Mesa, and expose the debuginfod-enabled variant as a separate package?
>> We could "hide" the minimal variant so that end users get the expected
>> package.
>
> Sure. Other distros split elfutils into multiple packages. For example fedora has:
>
> %package libs
> %package devel
> %package devel-static
> %package libelf
> %package libelf-devel
> %package libelf-devel-static
> %package default-yama-scope
> %package debuginfod-client
> %package debuginfod-client-devel
> %package debuginfod

Right.  It makes sense to do something similar for Guix if many packages
end up needing elfutils at runtime.

> With the main elfutils package containing all binaries except for
> debuginfod-find (the client) and debuginfod (the server). With
> appropriate requires/recommends (I don't yet know how those work in
> guix).

Guix does not have a notion of 'recommends'.  Each package is built with
an exact set of inputs, and each build output is scanned for references
to the inputs which are then stored as runtime dependencies.

There are talks about "parameterized packages", where you could apply
some vetted transformation to the build procedure, but advertising
optional runtime dependencies is an open question.

>> Also, for the patches, please add links to upstream commits in the patch
>> files, see some of the other patches for examples.  I would also prefer
>> if they were separate files, seeing as the two commits do different
>> things.
>
> OK split in two. The tests patches are together, because they do the
> same thing. I am not sure an upstream git commit id link is better
> than simply the commit id, but added if it is more convenient.

As someone who frequently chases upstream repositories for patches, I
certainly appreciate not having to figure out where their VCS is
hosted.  Sourceware does exceptionally well in that regard, but not
everyone knows it.  So, thanks for adding the links.  :-)

And sorry for all the difficult questions!  It is a great first patch
really, but it also has a heavy impact (see guix refresh -l elfutils).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  reply	other threads:[~2020-01-13 22:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-30  1:41 [bug#38803] [PATCH] gnu: elfutils: Update to 0.178 Mark Wielaard
2019-12-30  1:44 ` Brett Gilio
2019-12-30  2:04   ` Mark Wielaard
2020-01-12 20:39 ` Mark Wielaard
2020-01-12 20:54   ` Marius Bakke
2020-01-13  0:03     ` Mark Wielaard
2020-01-13 22:26       ` Marius Bakke [this message]
2020-01-31 12:43         ` Mark Wielaard
2020-01-31 15:49           ` Marius Bakke
2020-01-31 16:55             ` Mark Wielaard
2020-02-05 20:41               ` Marius Bakke
2020-02-06 11:04                 ` Mark Wielaard
2020-02-06 11:36                   ` Marius Bakke
2020-02-06 13:23                   ` Mark Wielaard
2020-02-06 14:31                     ` Marius Bakke
2023-09-02 18:39 ` Vagrant Cascadian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a76rvvpz.fsf@devup.no \
    --to=mbakke@fastmail.com \
    --cc=38803@debbugs.gnu.org \
    --cc=brettg@gnu.org \
    --cc=mark@klomp.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).