laurel
by Oden Eriksson
Hello boys, girls and what nots,
I'm an old fart that used to maintain 1/3 of the Mandriva Linux
distribution back in the day, and other stuff. That was pretty wild!
I've been lurking around here in the background for some years trying to
find something useful to do and to contribute with. I tried with
maxscale in 2016 but that failed due to a license change. I thought it
would be great to break out libinjection from mod_security but then I
realized it's pretty much dead.
So, now I found laurel that is not packaged yet (besides debian?). My
first ever rust package :-)
My status as an active fedora maintainer surely must have expired by now
but maybe I can get a sponsor to help me activate this again and get me
going?.
Anyways, the laurel stuff is here: https://repo.nux.se/laurel/
It builds on FC40 and RHEL 9, probably for RHEL 8 as well but I haven't
tried that yet. I have probably made a lot of mistakes in the spec file,
but consider it as a first take.
I really hope laurel is not needed and it's just a matter of cooking up
some some voodoo magic sauce to make it work in your SIEM platform.
Please enlighten me if that's the case.
Happy midsummer eve!
--
Regards // The penguin whisperer
2 days, 4 hours
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
6 days, 5 hours
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
2 weeks, 1 day
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
2 weeks, 2 days
