Tmp files created between %install and %check in a python package in rawhide
by Sergio Pascual
Hi,
I was fixing a FTBFS https://bugzilla.redhat.com/show_bug.cgi?id=2291622
in the package python-astroquery
The reason of the failure were two files, installed but unpackaged,
both in python3_sitelib named:
astroquery/ipac/irsa/tests/data/.#.MOST_full_with_tarballs.html.tmp
astroquery/ipac/irsa/tests/data/.#.MOST_regular.html.tmp
These two files are not in the tarball and I have checked that they
appear after %install and before %check
The package has files named MOST_full_with_tarballs.html and
MOST_regular.html in the same folder as well as other files that seem
unaffected.
The same package builds in fedora 40 without problems.
Any idea of what is happening?
Regards, Sergio
0 minutes
- 1
- 0
The VCS RPM tag in Fedora packages
by Miro Hrončok
Hi,
I accidentally realized today (in [1]), that RPM has a VCS tag. 396 Fedora
packages use it, yay \o/
The tag is described (at [2]) as:
"""
(Public) upstream source code VCS location. Format <vcs>:<address> with <vcs>
being the VCS command used (e.g. git, svn, hg, …) and <address> being the
location of the repository as used by the VCS tool to clone/checkout the
repository (e.g. https://github.com/rpm-software-management/rpm.git).
"""
My understanding is the tag should look like this:
VCS: git:https://github.com/fedora-python/marshalparser.git
However, the 396 Fedora packages use it very weirdly.
268 packages omit the <vcs>: prefix (and the .git suffix, but most of the
forges redirect without it, so it's likely moot):
VCS: https://github.com/zenon-prover/zenon
or
VCS: %{forgeurl}
109 packages add an extra scm: prefix (why?):
VCS: scm:git:https://github.com/SIPp/sipp.git
5 packages use git+ssh://:
VCS: git+git@github.com:ryncsn/memstrack.git
4 of them with a hardcoded commit hash:
VCS:
git+https://pagure.io/rpm-git-tag-sort.git#0b8afd628229a41858f24692946e3b905d6e46c6:
2 packages use git://:
VCS: git://git.kernel.org/pub/scm/linux/kernel/git/colyli/bcache-tools.git
Only 11 packages use git:, all of them with %{forgeurl0}:
VCS: git:%{forgeurl0}
or
Vcs: git:%{forgeurl0}
Are the 396-11 packages wrong?
[1]
https://src.fedoraproject.org/rpms/python-BTrees/c/b13e97f40b840a21efddfa...
[2] https://rpm-software-management.github.io/rpm/manual/tags.html
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 week, 2 days
- 4
- 3
rpmlint errors/warnings while reviewing a package
by Mattia Verga
I'm performing a package review [1] for which I get some rpmlint errors and warnings, but I'm unsure how to proceed...
> > - rpmlint errors
> > supernovas-solsys2.x86_64: E: undefined-non-weak-symbol
> > /usr/lib64/libsolsys2.so.1.0.1 jplint_ (/usr/lib64/libsolsys2.so.1.0.1)
> > supernovas-solsys2.x86_64: E: undefined-non-weak-symbol
> > /usr/lib64/libsolsys2.so.1.0.1 jplihp_ (/usr/lib64/libsolsys2.so.1.0.1)
>
> However, the missing `jplint_` and `jplihp_` are an intended feature of the
> `solsys2` plugin. As the description of this sub-package implies this plugin
> requires user-supplied code to work, and these functions are exactly the
> ones that must be defined by the user when using the `libsolsys2` plugin
> library. This whole subpackages is aimed for supporting legacy code only,
> for people who have existing code that define those `jplint_` and `jplihp_`
> symbols, and want to compile their code with supernovas. I can think of 3
> ways to address this:
>
> 1. Let it be as such, if that's OK. (The Debian package has passed the
> initial reviews and is moving to testing with the same setup.)
> 2. I can define weak dummy implementations of the `jplint_` and `jplihp`
> symbols that simply return an error. That would cure the rpmlint errors, but
> it would also hide the fact that the `solsys2` plugin really requires these
> symbols be defined by the user-code. This would probably also mean that I'd
> have to create a new upstream branch/tag (e.g. 1.0.1-3) to distinguish it
> from the one used by the Debian package.
> 3. Drop providing the `solsys2` plugin as a library altogether, and supply
> the source code as documentation (examples) only. This is fine, but it
> requires a bit of extra work for people who want to link their existing
> (old) code with the `solsys2` functionality.
>
> What would be your solution?
I suppose we can ignore those errors, as they are just expected?
> > - rpmlint warning
> > supernovas-cio-data.x86_64: W: only-non-binary-in-usr-lib
> > Is the cio_ra.bin an executable? Or it's just a resource? If the latter,
> > maybe it can be moved under %{_datadir}/%{name}?
>
> It is a resource but it is a platform-dependent one -- so it has an 'arch'
> dependence. %{_datadir} has no arch-dependence, but %{_libdir} does, which
> is why I thought this resource might fit there best. Or do you think it's
> better to put arch-dependent data into {%_datadir}, perhaps under a
> %{name}/%{_isa} directory instead?
I'm not sure here: is it expected that {%_datadir} should not contain arch dependent code? Where it is best to provide such resources?
Thanks
Mattia
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2283055
1 week, 3 days
- 2
- 1
- ← Newer
- 1
- Older →