all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Marius Bakke <mbakke@fastmail.com>
Cc: Brett Gilio <brettg@gnu.org>, 38803@debbugs.gnu.org
Subject: [bug#38803] [PATCH] gnu: elfutils: Update to 0.178
Date: Fri, 31 Jan 2020 13:43:21 +0100	[thread overview]
Message-ID: <20200131124321.GM3319@wildebeest.org> (raw)
In-Reply-To: <87a76rvvpz.fsf@devup.no>

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

Hi Marius,

Sorry for the long delay in replying. At Guix Days now, so maybe
someone can help me with some of this :)

On Mon, Jan 13, 2020 at 11:26:48PM +0100, Marius Bakke wrote:
> >> 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'?

I think it already was. But reattached. If it gets mangled by one of
the mail systems you can also find it here:
https://code.wildebeest.org/git/user/mjw/guix/
on the elfutils-0.178 branch.

> 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 ...'.

OK. Done. See attached patch.

> >> 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?

Yes. There is are a new network client and server integrated with
elfutils in 0.178. A new client library debuginfod-client.so which
depends on libcurl, which pulls in most of the other stuff. elfutils
libdw.so has a dependency on this, but it is dlopened when
available. So it isn't a hard dependency. In other distros
debuginfod-client is its own elfutils subpackage which is recommended,
but not required. It allows libdw.so to pull in separate debuginfo
files from the network when not locally installed (and an server URL
is configured). Then there is also a little server based on
libmicrohttpd and sqlite which is responsible for the other part of
the new inputs. Other distros put this also in a separate elfutils
subpackage.

> I.e. could we move libelf.so to its own output to
> lose some of the runtime dependencies?

Sure. That is what most distros do. Have a elfutils-libelf package
that provides just the libelf.so.

> 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.

I would get rid of the other libelf. It has been dead upstream for
years. And last year the home page and upstream completely
disappeared. Replacing libelf with elfutils-libelf for guix globally
would make a lot of sense to me. I believe that is what most distros
do these days.

> >> 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.

I can do that. But it wouldn't change the inputs. The runtime
dependencies of libelf on its own would be reduced to just zlib and
gcclibs. The other libraries (without debuginfod-client) would just
add a couple more compression libraries as runtime dependencies
(although you realy want debuginfod-client also around so that it can
be dlopened). Same for the binaries minus debuginfod-find and
debuginfod. The debuginfod subpackage would be the only thing with
runtime dependencies on everything (including libmicrohttpd and
sqlite).

> > 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.

yeah. I don't actually like optional runtime dependencies. It is had
to explain to users why some installs do work out of the box and
others don't. So I would actually recommend debuginfod-client be a
hard runtime dependency whenever possible. It was mainly done for
other distros which did worry about bootstrapping.

I'll go ask around here how to create a minimal package to see if that
helps. Although it feels a bit odd. Upstream doesn't really support
building just a subset of the package (there are some dependencies
between the libraries and binaries which require things to be build
together).

Cheers,

Mark


[-- Attachment #2: 0001-gnu-elfutils-Update-synopsis-and-description.patch --]
[-- Type: text/x-diff, Size: 3010 bytes --]

From a686a10451f600889a20b9ca8b08c25253b349f4 Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mark@klomp.org>
Date: Sun, 12 Jan 2020 23:54:18 +0100
Subject: [PATCH] gnu: elfutils: Update synopsis and description

* gnu/packages/elf.scm (elfutils): Update summaries.
  [synopsis]: Updated.
  [description]: Updated.
---
 gnu/packages/elf.scm | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/elf.scm b/gnu/packages/elf.scm
index 75caa54296..01bf0fcf89 100644
--- a/gnu/packages/elf.scm
+++ b/gnu/packages/elf.scm
@@ -6,6 +6,7 @@
 ;;; Copyright © 2017 Leo Famulari <leo@famulari.name>
 ;;; Copyright © 2018 Tobias Geerinckx-Rice <me@tobias.gr>
 ;;; Copyright © 2018 Marius Bakke <mbakke@fastmail.com>
+;;; Copyright © 2020 Mark Wielaard <mark@klomp.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -54,9 +55,10 @@
     (build-system gnu-build-system)
 
     ;; Separate programs because that's usually not what elfutils users want,
-    ;; and because they duplicate what Binutils provides.
+    ;; and because they duplicate what Binutils proAvides (but are named
+    ;; differently, using the eu- prefix and can be installed in parallel).
     (outputs '("out"                           ; libelf.so, elfutils/*.h, etc.
-               "bin"))                         ; ld, nm, objdump, etc.
+               "bin"))                         ; eu-nm, eu-objdump, etc.
 
     (arguments
      ;; Programs don't have libelf.so in their RUNPATH and libraries don't
@@ -84,11 +86,21 @@
     (native-inputs `(("m4" ,m4)))
     (inputs `(("zlib" ,zlib)))
     (home-page "https://sourceware.org/elfutils/")
-    (synopsis "Linker and ELF manipulation tools")
+    (synopsis "Collection of utilities and libraries to handle ELF files and
+DWARF data")
     (description
-     "This package provides command-line tools to manipulate binaries in the
-Executable and Linkable Format (@dfn{ELF}).  This includes @command{ld},
-@command{ar}, @command{objdump}, @command{addr2line}, and more.")
+     "A collection of utilities and libraries to read, create and modify
+Executable and Linkable Format (@dfn{ELF}) binary files, find and handle
+Debugging With Arbitrary Record Formats (@dfn{DWARF}) debug data, symbols,
+thread state and stacktraces for processes and core files on GNU/Linux.
+Includes @file{libelf} for manipulating ELF files, @file{libdw} for inspecting
+DWARF data and process state and utilities like @command{eu-stack} (to show
+backtraces), @command{eu-nm} (for listing symbols from object files),
+@command{eu-size} (for listing the section sizes of an object or archive
+file), @command{eu-strip} (for discarding symbols), @command{eu-readelf} (to
+see the raw ELF file structures), @command{eu-elflint} (to check for
+well-formed ELF files), @command{eu-elfcompress} (to compress or decompress
+ELF sections), and more.")
 
     ;; Libraries are dual-licensed LGPLv3.0+ | GPLv2, and programs are GPLv3+.
     (license lgpl3+)))
-- 
2.20.1


  reply	other threads:[~2020-01-31 12:44 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
2020-01-31 12:43         ` Mark Wielaard [this message]
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

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

  git send-email \
    --in-reply-to=20200131124321.GM3319@wildebeest.org \
    --to=mark@klomp.org \
    --cc=38803@debbugs.gnu.org \
    --cc=brettg@gnu.org \
    --cc=mbakke@fastmail.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.