https://bugzilla.redhat.com/show_bug.cgi?id=1507103 Jan Pokorný <jpokorny@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jpokorny@redhat.c | |om) | --- Comment #63 from Jan Pokorný <jpokorny@xxxxxxxxxx> --- > Because it´s impossible to follow those jumps Really? Enumerating separate points was to prevent any confusion. > you do around between comments and we have no idea what you are > talking about related to A. What is A? For whoever is "we", A. was defined in [comment 55]... > How about adding some context or spec file snippets to make > it clear? ...see [attachment 1402543], lines 25,26, 28-30, 458-460 in the original. Hopefully it clarifies it fully. >>>> [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. Let me explain that the review is not a black-or-white mechanical process, which appears to be your current view. It's meant to combine experience and common sense to find near-optimal solutions, individually. In this case, the undisclosed reason behind my suggestion is the common sense one: to eliminate redundancy. To keep Fedora scalable regarding mirrors, minimal installations, etc., it's really good to consider whether the identical files need to be carried over twice per each architecture when not necessary. Common sense hence says, it's enough -- thanks to intra-srpm dependencies -- to carry just a single copy per arch. Packaging guidelines give the green light to this "optimization". I see I should have been more patient to provide this explanation first-hand, sorry about that. Would you be willing to make this change, i.e., to drop license files from libknet1-devel subpackage, now? * * * > 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? It built the package detached from host, using mock (systemd-nspawn containers), which in turn obtained buildroot with > /usr/bin/dnf builddep --installroot \ > /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 28 \ > /var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/kronosnet-1.1-3.fc28.src.rpm with toolchain: > gcc-8.0.1-0.14.fc28.x86_6 > binutils-2.29.1-19.fc28.x86_64 > glibc-2.27-3.fc28.x86_64 Then > 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. in the respective logs, I can see: > checking for library containing ceil... -lm It corresponds to this observation: $ readelf -s /usr/lib64/libc.so.6 | grep ceil || echo none > none So the warning may be false positive, after all. -- 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
