| Message ID | 20200131165505.GN3319@wildebeest.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [bug#38803] gnu: elfutils: Update to 0.178 | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | fail | View Laminar job |
Mark Wielaard <mark@klomp.org> writes: > OK, OK. Lets see if I can at least get the patch that does only update > the descriptions correct. New version attached. Thanks! I fixed the comment typo and committed. The new description should show up on <https://guix.gnu.org/packages/E/page/3/> shortly. :-) Note that I had to convert the patch from ISO-8859-14 to UTF-8 in order to make git accept it: $ iconv -f ISO-8859-14 -t UTF-8 0001-gnu-elfutils-Update-synopsis-and-description.patch | git am -s Not sure what happened, perhaps it got mangled by your MUA? For the 0.178 update, perhaps we can add the new version as a separate variable until we figure out how to isolate libelf.so? That can be done on the 'master' branch as long as we don't change the current 'elfutils' package.
Hi Marius, On Wed, 2020-02-05 at 21:41 +0100, Marius Bakke wrote: > Mark Wielaard <mark@klomp.org> writes: > > > OK, OK. Lets see if I can at least get the patch that does only update > > the descriptions correct. New version attached. > > Thanks! I fixed the comment typo and committed. The new description > should show up on <https://guix.gnu.org/packages/E/page/3/> shortly. :-) Awesome. Looks good. Thanks. > Note that I had to convert the patch from ISO-8859-14 to UTF-8 in order > to make git accept it: > > $ iconv -f ISO-8859-14 -t UTF-8 0001-gnu-elfutils-Update-synopsis-and-description.patch | git am -s > > Not sure what happened, perhaps it got mangled by your MUA? That is indeed really odd. I definitely didn't want to encode any Celtic languages (I do speak Dutch, but not Gaelic or Breton). > For the 0.178 update, perhaps we can add the new version as a separate > variable until we figure out how to isolate libelf.so? That can be done > on the 'master' branch as long as we don't change the current 'elfutils' > package. I am not sure I completely understand your proposal. When you say 'separate variable', Do you mean we would (define-public elfutils-0.178 ...)? And changing the default libelf implementation should be a separate bug I assume. BTW. Upstream is now debating some of the dependencies for other distros that have bootstrapping requirements too: https://sourceware.org/bugzilla/show_bug.cgi?id=25509 Cheers, Mark
Mark Wielaard <mark@klomp.org> writes: >> For the 0.178 update, perhaps we can add the new version as a separate >> variable until we figure out how to isolate libelf.so? That can be done >> on the 'master' branch as long as we don't change the current 'elfutils' >> package. > > I am not sure I completely understand your proposal. When you say > 'separate variable', Do you mean we would (define-public elfutils-0.178 > ...)? Yes. See e.g 'gdb/next' or 'help2man/latest' for some examples of inheritance. > And changing the default libelf implementation should be a separate bug > I assume. Indeed. I suggest we defer that until we have 0.178+ in properly. > BTW. Upstream is now debating some of the dependencies for other > distros that have bootstrapping requirements too: > https://sourceware.org/bugzilla/show_bug.cgi?id=25509 Good to know we're not alone!
On Thu, 2020-02-06 at 12:04 +0100, Mark Wielaard wrote: > BTW. Upstream is now debating some of the dependencies for other > distros that have bootstrapping requirements too: > https://sourceware.org/bugzilla/show_bug.cgi?id=25509 It would be nice if someone could comment on that bug who better understands the bootstrap requirements for the guix toolchain. Note that this is relevant to other packages too because we are very eager to improve the debugability of the whole toolchain and so have submitted patches to various core packages to support debuginfod-client like binutils, gdb, annocheck, etc. Which means they all eventually depend on everything libcurl depends on: https://sourceware.org/elfutils/Debuginfod.html
Mark Wielaard <mark@klomp.org> writes: > On Thu, 2020-02-06 at 12:04 +0100, Mark Wielaard wrote: >> BTW. Upstream is now debating some of the dependencies for other >> distros that have bootstrapping requirements too: >> https://sourceware.org/bugzilla/show_bug.cgi?id=25509 > > It would be nice if someone could comment on that bug who better > understands the bootstrap requirements for the guix toolchain. Note > that this is relevant to other packages too because we are very eager > to improve the debugability of the whole toolchain and so have > submitted patches to various core packages to support debuginfod-client > like binutils, gdb, annocheck, etc. Which means they all eventually > depend on everything libcurl depends on: > https://sourceware.org/elfutils/Debuginfod.html I think that the Guix toolchain (the one used in package builds) should stay the same (no debuginfod support), and that we should add debuginfod-enabled variants that gets included when users install 'binutils' or 'gcc-toolchain' manually. How does that sound? So our only concern will be how to use Elfutils' libelf.so for GCC, which should be straightforward with an "elfutils-minimal" variant that does not pull in the debuginfo dependencies.
From 6a9f7efd89f6617766640b3e2f7a232977bf98a4 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..22d03fba84 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.") + "Elfutils is 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. Elfutils 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.24.1