https://bugzilla.redhat.com/show_bug.cgi?id=2283055 Mattia Verga <mattia.verga@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Flags| |fedora-review? Assignee|nobody@xxxxxxxxxxxxxxxxx |mattia.verga@xxxxxxxxx --- Comment #36 from Mattia Verga <mattia.verga@xxxxxxxxx> --- (In reply to Attila Kovacs from comment #35) > > (In reply to Mattia Verga from comment #33) > > Hi again Mattia, > > Before I upload a new SPEC (and a new SRPM built from it on Copr), I wanted > to get your opinions on the issues you brought up. > > > A few issues while reviewing the package: > > > > - Sources in the SRPM does not match with those downloaded from the upstream > > URL > > This must have been me referencing the wrong Copr build, since the SRPM is > built on Copr from the source, and so the only way they can diverge is if > the build was an older one, from before the last change on upstream. > > It does bring up a question of versioning though, which I wanted to clarify > before proceeding. The upstream version is a tag on a branch that contains > patches to make packaging easier, as per your earlier suggestion. It has an > upstream version number '1.0.1-2'. As such, would the RPM version be '1.0.1' > (and release '2'), or would it be '1.0.1-2' and the release whatever Fedora > assigns, so the RPM may have a version number such as '1.0.1-2-1'? (I feel > the latter is the more appropriate, but I'd like you to confirm). > '1.0.1-2-1' would not be a valid NVR. You could however do '1.0.1.2-1' (1.0.1.2 version and 1 release) if you think it doesn't worth to release a '1.0.2' bugfix version. You can check the diff in the automatic COPR build in comment#32. > > > - No known owner of /usr/lib64/supernovas > > Perhaps the -cio-data subpackage should just own the entire > > %{_libdir}/%{name} directory? > > Ye, that makes sense. I'll add a '%dir %{libdir}/%{name}' into %files for > it... > > > - Macros in: supernovas (description) > > I think this error is due to the presence of a '%' character in the > > description. It should be escaped (I think using a double '%%') > > I think I removed these macros a while back (I don't see them in the spec > any more). This is another indication that the Copr build I referenced last > was an old one by mistake... I think in the "100% API compatibility" phrase RPM doesn't like that '%'... > > > - rpmlint errors > > supernovas-solsys2.x86_64: E: undefined-non-weak-symbol > > /usr/lib64/libsolsys2.so.1.0.1 novas_trace (/usr/lib64/libsolsys2.so.1.0.1) > > 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 novas_error (/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) > > OK, this is a bit more involved... > > The latest spec (and upstream branch from which the package is built) fixes > 2 of the 4 errors. The `solsys2` library just needed a link flag against the > parent `libsupernovas` to get two of the missing symbols defined. > > 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 think that if that is expected, it should be fine. But I don't know much about C programming/linking, so I'll ask for some advice by more skilled users on how to deal those errors. > > > - 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? > mmm I'll ask for that too, I don't think I've never encountered such a situation... > > I'll await your responses before submitting a new SPEC with the appropriate > changes. > > Thanks in advance, > > -- Attila. I'll let you know ASAP. Also note that, while I can do a full review of the package, you will still need someone to sponsor you as described at https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/ -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2283055 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202283055%23c36 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
