https://bugzilla.redhat.com/show_bug.cgi?id=1507103 Fabio Massimo Di Nitto <fdinitto@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(jpokorny@redhat.c | |om) --- Comment #62 from Fabio Massimo Di Nitto <fdinitto@xxxxxxxxxx> --- (In reply to Jan Pokorný from comment #61) > Created attachment 1402543 [details] > Example simplification > > Slipped the recent comment, but mentioned in [comment 54]: > - either do not refer to particular macros in the changelog > at all, double '%' characters (producing single '%' after > macro processing, preventing macro expansion as such when > it happens during the build process), or put it in some other > understandable way, e.g.: "_isa" macro > > * * * > > >> [re A. and B.[ > > > > The current format still achieve the same technical goal. terse or > > verbose is still a matter of personal preference. The code is not > > obfuscated in either forms. > > We still did not get to why you insist on avoidable (B.) or > inappropriate (A.) complexities without any gain for Fedora > ecosystem. > Because it´s impossible to follow those jumps you do around between comments and we have no idea what you are talking about related to A. What is A? How about adding some context or spec file snippets to make it clear? If B is the configure switches, you need to learn to discern what is required for a review or nice to have. You mentioned different times that it is nice to have and since there are no fedora strict requirements to switch to your format of choice, then I don´t see why we have to change it. > Attached is the patch how it may look. > > > >>>> Also, please: > >>>> > >>>> C. Refrain from initial spaces/indentation in %description-s. > >>> > >>> rationale? > >> > >> Not looking weird in comparison to other packages, e.g. in > >> various output of console programs dealing with packages. > > > > Please provide an example of which commands are you referring to. > > It´s hard to guess what you see without some data. > > "rpm -qi" is the first test of choice. Ok now I can see it. > > > > [%check scriptlet discussion] > > Thanks. > > > >> [re E.] > > > > You haven´t answered either of my questions. > > My answer was: let's just do it. My questions are still unanswered. I asked if it is breaking policies or not. > > > >> [re G.] > > > > It reflects the version of the onwire protocol. There are plenty > > libraries in Fedora that use similar convention. We can document > > it somewhere in the spec file. it´s not going to drop. > > True, and other library cases mainly boil down to "multiple versions > installed simulatenously" scenario as shown. Explicitly designating > on-wire compatible series may also make sense, then please make this > apparent in package summaries, e.g.: > > -Summary: Kronosnet core switching implementation > +Summary: Kronosnet core switching implementation (protocol v1) ok that´s reasonable. > > > >> [re I.] > > > > which version of the package did you test? we fixed that already > > upstream in 1.1. ./configure.ac does check if it is necessary to link > > to libm or not at build time to use ceil(). > > > > Your rpm seems old. > > Used SRPM per [comment 52], using. Just rechecked. > It can be found in "Rpmlint (installed packages)" of review.txt > generated with "fedora-review -rn kronosnet-1.1-3.fc27.src.rpm" > on Rawhide. hmmm does fedora-review -rn rebuilds the package on the local system (aka f29?) or does it build in a chroot for f27 and test the end result.f27 binaries? > > As mentioned, this has no effect on the review itself, just > a feedback about detections (allowing for false positives) observed. Right, that´s clear. I am investigating because it annoys me. libknet uses ceil(). ceil() recently moved from libm to libc. The build system might detect that it needs to link to libm but then when you do rpmlint on a different system that has ceil() in libc, the symbol check would report the warning. So I prefer to understand if the upstream check is bogus on fedora or if the test environment (despite being just a minor warning) is being tricked to think it´s a problem. -- 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 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
