https://bugzilla.redhat.com/show_bug.cgi?id=1507103
Jan Pokorný <jpoko...@redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(jpokorny@redhat.c |
|om) |
--- Comment #63 from Jan Pokorný <jpoko...@redhat.com> ---
> 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@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
