Hi, As discussed I setup a separate debugedit project: https://sourceware.org/debugedit/ It contains the debugedit and sepdebugcrcfix programs and the find- debuginfo.sh script and the debugedit.at testsuite. I used git-filter- repo to keep the git history of the files from the rpm repo. Then I resynced the libiberty and binutils files and added a minimal automake/autoconf/autotest build system. Replace popt with getopt argument parsing. And use libiberty md5 or sha1 instead of rpmDigest algorithms for build-id updates. There is a test debugedit-0.1 release to see whether this works. But I would like to make sure first that things are setup so that flatpak and rpm can use this as is before people start packaging it. Once we know it can be used as replacement for the built-in rpm/flatpak debugedit we do a proper debugedit 1.0 release. Please join the debugedit mailinglist for discussions: https://sourceware.org/mailman/listinfo/debugedit File bugs or feature requests: https://sourceware.org/bugzilla/enter_bug.cgi?product=debugedit Checkout the git repo: git clone git://sourceware.org/git/debugedit.git I have played a bit with pagure, but haven't set it up properly, sorry. So for now we'll do patches by email. Cheers, Mark
On 3/22/21 7:42 PM, Mark Wielaard wrote: > Hi, > > As discussed I setup a separate debugedit project: > https://sourceware.org/debugedit/ > > It contains the debugedit and sepdebugcrcfix programs and the find- > debuginfo.sh script and the debugedit.at testsuite. I used git-filter- > repo to keep the git history of the files from the rpm repo. Then I > resynced the libiberty and binutils files and added a minimal > automake/autoconf/autotest build system. Replace popt with getopt > argument parsing. And use libiberty md5 or sha1 instead of rpmDigest > algorithms for build-id updates. > > There is a test debugedit-0.1 release to see whether this works. But I > would like to make sure first that things are setup so that flatpak and > rpm can use this as is before people start packaging it. Once we know > it can be used as replacement for the built-in rpm/flatpak debugedit we > do a proper debugedit 1.0 release. Awesome. I'll make it a priority to see that we transition, if at all possible, to the external debugedit in rpm 4.17 already. Stay tuned... > > Please join the debugedit mailinglist for discussions: > https://sourceware.org/mailman/listinfo/debugedit > > File bugs or feature requests: > https://sourceware.org/bugzilla/enter_bug.cgi?product=debugedit > > Checkout the git repo: > git clone git://sourceware.org/git/debugedit.git > > I have played a bit with pagure, but haven't set it up properly, sorry. > So for now we'll do patches by email. I for one far prefer patches by email over Pagure... - Panu - > > Cheers, > > Mark > _______________________________________________ > Rpm-ecosystem mailing list > Rpm-ecosystem@lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-ecosystem >
Hi Panu,
I added debugedit@sourceware.org to the CC.
On Tue, Mar 23, 2021 at 03:52:53PM +0200, Panu Matilainen wrote:
> On 3/23/21 2:29 PM, Panu Matilainen wrote:
> > On 3/22/21 7:42 PM, Mark Wielaard wrote:
> > > There is a test debugedit-0.1 release to see whether this works. But I
> > > would like to make sure first that things are setup so that flatpak and
> > > rpm can use this as is before people start packaging it. Once we know
> > > it can be used as replacement for the built-in rpm/flatpak debugedit we
> > > do a proper debugedit 1.0 release.
> >
> > Awesome. I'll make it a priority to see that we transition, if at all
> > possible, to the external debugedit in rpm 4.17 already. Stay tuned...
>
> FWIW, here's a quick-n-dirty package of debugedit 0.1:
>
> https://laiskiainen.org/rpm/debugedit/
Nice, thanks. Would it make sense to add the debugedit.spec to the
debugedit sources themselves so people can easily create an rpm?
Does it actually make sense to install everything under bindir?
Originally in rpm the tools were installed under /usr/lib/rpm/ because
they were only invoked indirectly through rpm. If we see them as tools
that no user/admin/developer will ever invoke directly maybe they
should be installed under /usr/libexec/ instead?
Cheers,
Mark
On Thu, Mar 25, 2021 at 10:13:38PM +0100, Mark Wielaard wrote:
> On Tue, Mar 23, 2021 at 03:52:53PM +0200, Panu Matilainen wrote:
> > On 3/23/21 2:29 PM, Panu Matilainen wrote:
> > > On 3/22/21 7:42 PM, Mark Wielaard wrote:
> > > > There is a test debugedit-0.1 release to see whether this works. But I
> > > > would like to make sure first that things are setup so that flatpak and
> > > > rpm can use this as is before people start packaging it. Once we know
> > > > it can be used as replacement for the built-in rpm/flatpak debugedit we
> > > > do a proper debugedit 1.0 release.
> > >
> > > Awesome. I'll make it a priority to see that we transition, if at all
> > > possible, to the external debugedit in rpm 4.17 already. Stay tuned...
> >
> > FWIW, here's a quick-n-dirty package of debugedit 0.1:
> >
> > https://laiskiainen.org/rpm/debugedit/
>
> Nice, thanks. Would it make sense to add the debugedit.spec to the
> debugedit sources themselves so people can easily create an rpm?
Found some missing Requires for find-debuginfo.sh:
# For strip_to_debug, eu-strip
Requires: elfutils
# For add_minidebug, readelf, awk, nm, sort, comm, objcopy, xz
Requires: binutils, gawk, coreutils, xz
# For find and xargs
Requires: fileutils
# For do_file, gdb_add_index
Requires: gdb
# For run_job, sed
Requires: sed
# For dwz
Requires: dwz
# For append_uniq, grep
Requires: grep
Cheers,
Mark
On 3/26/21 3:11 AM, Mark Wielaard wrote: > On Thu, Mar 25, 2021 at 10:13:38PM +0100, Mark Wielaard wrote: >> On Tue, Mar 23, 2021 at 03:52:53PM +0200, Panu Matilainen wrote: >>> On 3/23/21 2:29 PM, Panu Matilainen wrote: >>>> On 3/22/21 7:42 PM, Mark Wielaard wrote: >>>>> There is a test debugedit-0.1 release to see whether this works. But I >>>>> would like to make sure first that things are setup so that flatpak and >>>>> rpm can use this as is before people start packaging it. Once we know >>>>> it can be used as replacement for the built-in rpm/flatpak debugedit we >>>>> do a proper debugedit 1.0 release. >>>> >>>> Awesome. I'll make it a priority to see that we transition, if at all >>>> possible, to the external debugedit in rpm 4.17 already. Stay tuned... >>> >>> FWIW, here's a quick-n-dirty package of debugedit 0.1: >>> >>> https://laiskiainen.org/rpm/debugedit/ >> >> Nice, thanks. Would it make sense to add the debugedit.spec to the >> debugedit sources themselves so people can easily create an rpm? Upstream specs can be a bit controversial, but I have no particular opinion on that. If it makes sense to you/others then by all means. > Found some missing Requires for find-debuginfo.sh: > > # For strip_to_debug, eu-strip > Requires: elfutils > # For add_minidebug, readelf, awk, nm, sort, comm, objcopy, xz > Requires: binutils, gawk, coreutils, xz > # For find and xargs > Requires: fileutils > # For do_file, gdb_add_index > Requires: gdb > # For run_job, sed > Requires: sed > # For dwz > Requires: dwz > # For append_uniq, grep > Requires: grep > Doh, of course :D Thanks for pointing these out, spec updated. "fileutils" is "findutils" though. - Panu - > Cheers, > > Mark >
On 3/25/21 11:13 PM, Mark Wielaard wrote:
> Hi Panu,
>
> I added debugedit@sourceware.org to the CC.
>
> On Tue, Mar 23, 2021 at 03:52:53PM +0200, Panu Matilainen wrote:
>> On 3/23/21 2:29 PM, Panu Matilainen wrote:
>>> On 3/22/21 7:42 PM, Mark Wielaard wrote:
>>>> There is a test debugedit-0.1 release to see whether this works. But I
>>>> would like to make sure first that things are setup so that flatpak and
>>>> rpm can use this as is before people start packaging it. Once we know
>>>> it can be used as replacement for the built-in rpm/flatpak debugedit we
>>>> do a proper debugedit 1.0 release.
>>>
>>> Awesome. I'll make it a priority to see that we transition, if at all
>>> possible, to the external debugedit in rpm 4.17 already. Stay tuned...
>>
>> FWIW, here's a quick-n-dirty package of debugedit 0.1:
>>
>> https://laiskiainen.org/rpm/debugedit/
>
> Nice, thanks. Would it make sense to add the debugedit.spec to the
> debugedit sources themselves so people can easily create an rpm?
>
> Does it actually make sense to install everything under bindir?
> Originally in rpm the tools were installed under /usr/lib/rpm/ because
> they were only invoked indirectly through rpm. If we see them as tools
> that no user/admin/developer will ever invoke directly maybe they
> should be installed under /usr/libexec/ instead?
These certainly look like they don't quite belong to /usr/bin, and in
the rpm context they certainly don't. But I don't know what others do
with these tools, so I just left it up to upstream in the package.
/usr/libexec is controversial as it doesn't exist in FHS at all, and
last I looked the Debian family doesn't use it (but this could be
outdated info). The FHS-compatible place would be /usr/lib/debugedit/ I
suppose. Me and rpm, we don't really care one way or the other.
- Panu -
- Panu -
Hi Mark,
On Thu, Mar 25, 2021 at 10:13:38PM +0100, Mark Wielaard wrote:
> Hi Panu,
>
> I added debugedit@sourceware.org to the CC.
>
> On Tue, Mar 23, 2021 at 03:52:53PM +0200, Panu Matilainen wrote:
> > On 3/23/21 2:29 PM, Panu Matilainen wrote:
> > > On 3/22/21 7:42 PM, Mark Wielaard wrote:
> > > > There is a test debugedit-0.1 release to see whether this works. But I
> > > > would like to make sure first that things are setup so that flatpak and
> > > > rpm can use this as is before people start packaging it. Once we know
> > > > it can be used as replacement for the built-in rpm/flatpak debugedit we
> > > > do a proper debugedit 1.0 release.
> > >
> > > Awesome. I'll make it a priority to see that we transition, if at all
> > > possible, to the external debugedit in rpm 4.17 already. Stay tuned...
> >
> > FWIW, here's a quick-n-dirty package of debugedit 0.1:
> >
> > https://laiskiainen.org/rpm/debugedit/
>
> Nice, thanks. Would it make sense to add the debugedit.spec to the
> debugedit sources themselves so people can easily create an rpm?
>
> Does it actually make sense to install everything under bindir?
At least debugedit executable has a documented command line interface,
so I'd say it belongs to bindir.
--
ldv
On 3/23/21 2:29 PM, Panu Matilainen wrote: > On 3/22/21 7:42 PM, Mark Wielaard wrote: >> Hi, >> >> As discussed I setup a separate debugedit project: >> https://sourceware.org/debugedit/ >> >> It contains the debugedit and sepdebugcrcfix programs and the find- >> debuginfo.sh script and the debugedit.at testsuite. I used git-filter- >> repo to keep the git history of the files from the rpm repo. Then I >> resynced the libiberty and binutils files and added a minimal >> automake/autoconf/autotest build system. Replace popt with getopt >> argument parsing. And use libiberty md5 or sha1 instead of rpmDigest >> algorithms for build-id updates. >> >> There is a test debugedit-0.1 release to see whether this works. But I >> would like to make sure first that things are setup so that flatpak and >> rpm can use this as is before people start packaging it. Once we know >> it can be used as replacement for the built-in rpm/flatpak debugedit we >> do a proper debugedit 1.0 release. > > Awesome. I'll make it a priority to see that we transition, if at all > possible, to the external debugedit in rpm 4.17 already. Stay tuned... Here goes: https://github.com/rpm-software-management/rpm/pull/1712 - Panu -