Re: [Rpm-ecosystem] why do elf dependency generators cover libraries in paths outside of the library load paths?

[Dmitry V. Levin]

On Fri, Dec 03, 2021 at 07:53:42PM +, Zbigniew Jędrzejewski-Szmek wrote:
> We had an incident today [1] that opae-devel has auto-generated provides
> like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
> (/usr/lib/python3.10/site-packages/pacsign/hsm_managers/openssl/library/libcrypto.so).
> It was pulled into the buildroot instead of the expected openssl1.1 package.
> Those deps are generated by /usr/lib/rpm/elfdeps, which is configured in
> /usr/lib/rpm/fileattrs/elf.attr to act on anything that matches the
> file magic of '^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*$'.
> 
> My question: shouldn't we limit the elfdeps generator to files which
> are in paths that can be loaded automatically by the linker? (This
> could be implemented as e.g. the paths that are default like
> /usr/lib64, /usr/local/lib64, …, depending on the architecture, and if
> the package installs anything in /etc/ld.so/, also the paths listed there.)

Back in 2006, I implemented the following semantics in ALT Sisyphus:
when Provides and Requires are generated for ELF shared libraries outside
of standard places searched by the dynamic linker, their directory prefix
is added, e.g.

$ rpmquery --provides -p firefox-94.0.2-alt1.x86_64.rpm |grep -F 
libmozsandbox.so
/usr/lib64/firefox/libmozsandbox.so()(64bit) = 
set:hd93tnnyHiEk678Zuue9vzWzvyhOXoj2

Hope this helps.


-- 
ldv
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] debugedit project setup

[Dmitry V. Levin]

Hi Mark,

On Thu, Mar 25, 2021 at 10:13:38PM +0100, Mark Wielaard wrote:
> Hi Panu,
> 
> I added debuge...@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
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] rpm debugedit as a separate project?

[Dmitry V. Levin]

On Sun, Feb 21, 2021 at 09:24:42PM +0300, Dmitry V. Levin wrote:
[...]
> Currently, debugedit.c is GPLv2+, hashtab.[ch] are LGPLv2+, and both
> libelf and libdw used by debugedit are (GPLv2+ or LGPLv3+).

Minor correction: hashtab.c is LGPLv2+, hashtab.h is GPLv2+.

The same stands for more up-to-date versions of these files in binutils
and gcc.


-- 
ldv
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] rpm debugedit as a separate project?

[Dmitry V. Levin]

On Sun, Feb 21, 2021 at 10:49:03AM -0500, Neal Gompa wrote:
[...]
> Splitting out from rpm would make the rpm debuginfo support a bit more
> painful to support for non-Linux systems, but I guess most don't care
> about that. :(

Why should making debugedit either a part of elfutils or a separate
project be any more painful for non-Linux systems?

> I don't think it'd be a good idea for it to become part of elfutils,
> because the elfutils license makes it unshippable for certain
> environments (e.g. automotive and medical, where they get panicky
> about that sort of thing).

Sorry, what do you mean by "elfutils license"?

Currently, debugedit.c is GPLv2+, hashtab.[ch] are LGPLv2+, and both
libelf and libdw used by debugedit are (GPLv2+ or LGPLv3+).

> I'm also not comfortable with the idea of having a part of RPM itself
> broken out and transferred to a project with subpar contribution
> practices. Most of Sourceware still relies on the email workflow for
> contribution of fixes and improvements. While you are the main
> contributor the last few years (and you don't use GitHub), you are not
> the only one, and you are the only one who uses the email workflow. If
> Sourceware projects had something like Pagure overlaid on their Git
> repos where they could also take pull requests properly, then I'd be
> more comfortable with it.

On the contrary, I believe all potential debugedit contributors are
perfectly fine with email workflow used e.g. in elfutils.

> If we really want to split it out, we could just split it out here in
> the rpm-software-management GitHub org. That's where popt lives
> too[1]. Also, popt is definitely used by more than just RPM stuff, so
> I don't know why you noted it as if it's a problem.

I don't think the choice of hosting is important at this stage of
discussion, but you're well aware that github is out of the consideration
for the reason you mentioned above.


-- 
ldv
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] rpm debugedit as a separate project?

[Dmitry V. Levin]

Hi,

On Fri, Feb 19, 2021 at 09:23:58PM +0100, Mark Wielaard wrote:
> Hi all,
> 
> rpm debugedit has grown from a quick hack that simply listed/replaced
> some files/strings to an almost full blown DWARF reader/writer. It is
> now also used outside rpm(build). Debian packages it separately and
> Flatpak builder has an embedded copy it uses to post-process debuginfo.
> 
> It is currently not always easy to update because the people who
> contribute to debugedit are often not regular rpm contributors. And the
> release cycle of rpm doesn't always match up with the release cycle of
> the GNU toolchain. So it sometimes needs a release at a different time
> than rpm gets released.
> 
> There have been some requests to have it moved from rpm to elfutils:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27351
> But I think it would be simpler to have it be its own project, so it
> isn't tied to another projects release schedule and processes.

The advantage of building debugedit along with elfutils is that all
workarounds required to build with older elfutils could be removed, e.g.
this wouldn't be needed:

/* Unfortunately strtab manipulation functions were only officially added
   to elfutils libdw in 0.167.  Before that there were internal unsupported
   ebl variants.  While libebl.h isn't supported we'll try to use it anyway
   if the elfutils we build against is too old.  */

> So my proposal is to:
> 
> - Create a debugedit project on sourceware, so it is close to binutils,
>   from which it sometimes steals code, elfutils on which it relies for
>   libelf/libdw, and dwz which is a similar, but completely different
>   DWARF processor. Most people currently contributing to rpm debugedit
>   should already have an account there.

Yes, sourceware should be fine.

> - Import tools/debugedit.c tools/hashtab.c tools/hashtab.h and
>   tests/debugedit.at from rpm. Add a minimal build using autoconf and
>   autotest around this. Update the hashtab files from libiberty,
>   check debugedit (and sepdebugcrc checkm see below) for updates
>   which came in from binutils. Note, it also has a popt dependency.

The main obstacle is that tools/debugedit.c currently depends on rpm:

$ git grep -h rpm tools/debugedit.c
#include 
#include 
  if (rpmDigestLength(algorithm) == build_id_size)
  ctx = rpmDigestInit(algorithm, 0);
rpmDigestUpdate(ctx, build_id_seed, strlen (build_id_seed));
rpmDigestUpdate(ctx, x.d_buf, x.d_size);
  rpmDigestUpdate(ctx, x.d_buf, x.d_size);
  rpmDigestUpdate(ctx, d->d_buf, d->d_size);
  rpmDigestFinal(ctx, , , 0);


-- 
ldv
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] [Fedora-packaging] Let's standardize the way to disable tests during RPM build?

[Dmitry V. Levin]

On Fri, Jun 05, 2020 at 04:39:08PM +0200, Igor Raits wrote:
> On Fri, 2020-06-05 at 16:10 +0200, Tomas Orsava wrote:
> > Hi,
> > I think it would be useful to have a standard way of disabling the 
> > running of tests during RPM build (in the %check section of a spec
> > file).
> > 
> > I see a lot of packages already having %bcond's or other macro 
> > definitions to archieve this, but each package has their own way, 
> > there's no real standard. Thus you have to first look into the spec, 
> > locate the appropriate %bcond or macro name and only then you can 
> > disable the tests.
> > 
> > I would like to propose two approaches:
> > 
> > (a) Add a *SHOULD* rule to the guidelines that specifies what is the 
> > preferred way to conditionalize the tests.
> > 
> > (b) Or, if that's too strong, mention in the guidelines the common 
> > methods that are being used (e.g. %bcond tests and %bcond check) so
> > that 
> > new packagers have something to use.
> > 
> > What do you think?
> 
> I'd like to have this finally be implemented in
> https://github.com/rpm-software-management/rpm/issues/316. That way it
> would be simply rpmbuild --nocheck or define %_without_check 1 which
> would skip %check section entirely.

That's roughly the same I implemented in ALT rpm-build back in 2009, see
http://git.altlinux.org/gears/r/..git?p=rpm-build.git;a=commitdiff;h=23e6847c


-- 
ldv
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] RFC #417 %optional file attribute

[Dmitry V. Levin]

On Mon, Mar 26, 2018 at 01:08:15PM -0400, Neal Gompa wrote:
> On Mon, Mar 26, 2018 at 6:43 AM, Florian Festi  wrote:
> > Hi!
> >
> > We are currently pondering about #417 [1]. For adding a %optional file
> > attribute that would allow adding file to to %files sections that may
> > not be built under some circumstances (e.g. some architectures).
> >
> > It is already perfectly legal to have files not listed explicitly if
> > they are within a directory that is included in the %file section. But
> > some packages (examples wanted) may have trouble using this due to the
> > way the package files are laid out.
> >
> > Otoh %optional would be another spec language key word that packagers
> > have to deal with and we as RPM upstream developers have a hard time
> > judging whether the benefit of the attribute really out weights the cost
> > of bloating the spec language.
> >
> > Any input - especially with real world packages that would benefit such
> > an addition - is welcome.
> >
> 
> I personally wouldn't use %optional in most cases, just like I avoid
> %missingok (the install-time counterpart to this).

%missingok is *not* an install-time counterpart to %optional.

Imagine you have the following use of %missignok:

%ghost %attr(644,root,root) %config(noreplace,missingok) %verify(not md5 mtime 
size) /etc/postfix/*.db
- this means that some of /etc/postfix/*.db files listed in %files
*might* be created by the package during its lifetime.

In contrast, %optional means that it's explicitly OK for some of files
listed in %files to disappear from the package at build time for any reason.


-- 
ldv


signature.asc
Description: PGP signature
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem