I686 leaf removal and lost payload

Ask Fedora
1

Hello,

I have a new Fedora packaging issue.

I am the packager of the supernovas astrometry library. It has packages (<=1.1.1) for all arches, including i686. Version 1.2.0 added a new subpackage, which has a dependence on the calceph library, which in turn has no i686 support.

To make the build work, I added ExcludeArch %{ix86} to the package, which effectively disabled i686 support going forward.

Given the preference for removing i686 leaf nodes, it should be no big deal to simply discontinue i686 builds for the supernovas lib going forward. But, rpminspect on the bodhi build fails with lostpayload ‘verify’ warnings as a result.

Can I just ignore the rpminspect failure, or is there some other (better) way to resolve the issue of discontinued i686 support of the package?

Thanks in advance,

– A.

2

It would be helpful if you linked the problems you are seeing. I assume it is this update and these tests. I think the lostpayload is expected if you are dropping a package, but I’m not sure that you should be making such a breaking change due to the stable branch’s update policy.

What’s definitely important is the rpmdeps failure. It is absolutely correct in pointing out that the supernovas-devel package is providing shared libraries:

$ rpm -q --provides supernovas-devel
libsolsys-calceph.so.1()(64bit)
libsolsys1.so.1()(64bit)
libsolsys2.so.1()(64bit)
libsupernovas.so.1()(64bit)
supernovas-devel = 1.2.0-5.fc42
supernovas-devel(x86-64) = 1.2.0-5.fc42

This is because almost all of the files are copies:

$ cd /usr/lib64
$ ls -la libsupernovas* libsolsys*
-rwxr-xr-x. 1 root root  14608 Jan 14 19:00 libsolsys-calceph.so
lrwxrwxrwx. 1 root root     20 Jan 15 20:06 libsolsys-calceph.so.1 -> libsolsys-calceph.so
-rwxr-xr-x. 1 root root  22720 Jan 14 19:00 libsolsys1.so
-rwxr-xr-x. 1 root root  22720 Jan 14 19:00 libsolsys1.so.1
-rwxr-xr-x. 1 root root  14528 Jan 14 19:00 libsolsys2.so
-rwxr-xr-x. 1 root root  14528 Jan 14 19:00 libsolsys2.so.1
-rwxr-xr-x. 1 root root 190912 Jan 14 19:00 libsupernovas.so
-rwxr-xr-x. 1 root root 190912 Jan 14 19:00 libsupernovas.so.1

With 1.1.1, these were correctly linked:

lrwxrwxrwx. 1 root root     18 Nov  5 19:00 libsupernovas.so -> libsupernovas.so.1
lrwxrwxrwx. 1 root root     22 Nov  5 19:00 libsupernovas.so.1 -> libsupernovas.so.1.1.1
-rwxr-xr-x. 1 root root 180584 Nov  5 19:00 libsupernovas.so.1.1.1

Please report this upstream as their build system seems broken in 1.2.0.

1 Like
3

Also, looking at the git tree Tree - rpms/supernovas - src.fedoraproject.org, you’ve committed some extra things. You should avoid doing git add . as it has committed unwanted things.

bodhi.template.last is a temporary cache for when you abort a bodhi update in the middle of preparing it.

v1.2.0.tar.gz is the source tarball and should be uploaded to the lookaside cache, not committed to git.

1 Like
4

Thanks. Indeed, I botched the install of the lib symlinks. In the prior version of the package the upstream did not have make install support, and all the files were copied in place by the spec file, including the symlinks to unversioned .so files. v1.2.0 added the install target upstream, but it used the install tool to put the libraries and links into %{_libdir}, but that copied the files that followed the links, instead of just copying the links. So, instead of symlinked .so files, it ended up with an independent copy of the versioned .so.1 files.

Despite all the testing I did, I failed to notice this.

I’ll have this fixed right away…

5

Hi Elliott,

I’ve removed those unwanted files now in new commits. Would it be preferred to rewrite the git history (git reset --hard and force push) to obliterate them from the history altogether, or just let it be?

6

dist-git doesn’t allow history rewriting, so that wouldn’t be possible.

1 Like
7

Thanks for all the help Elliott! Much appreciated.

8

Hi Elliott,

I have the updated packages in Bodhi, see Fedora Updates System

The rpmdeps errors are gone, if you want to take a look to check if it’s allright otherwise also.

9

It seems alright now, though I’m not sure why you would drop %autochangelog.

10

Hi Elliott!

Thanks for checking.

I’m probably missing something, but I had a hard time keeping the Release versions to match the autochangelog entries. Presumably there is a way to set the package release number automatically so they always match, but I do not know how that is done. If you point me in the right direction to get that done, I’ll be more than happy to switch back to %autochangelog.

11

The way to do that is with Release: %autorelease.

Note that if you have a manual changelog, I find it best to change to the automated macros right before committing a new version, because then Release resets 1 and you don’t have to worry about it going backwards or skipping forwards some big number.

You can use rpmautospec convert to automate this conversion.

1 Like
12

Thanks. Will do for the next release in ~3 months…