Re: Would this be considered a packaging bug?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 02/25/2017 07:27 AM, Alice Wonder wrote:
On 02/25/2017 06:33 AM, Alice Wonder wrote:
On 02/25/2017 06:12 AM, Johnny Hughes wrote:
On 02/25/2017 06:52 AM, Alice Wonder wrote:
https://koji.fedoraproject.org/koji/buildinfo?buildID=861692

The source RPM there uses

%if 0%{?rhel}
# not upstreamed
Patch500: 0001-disable-libe-book-support.patch
Patch501: 0001-fix-build-of-bundled-libzmf-with-boost-1.56.patch
Patch502: 0001-allow-to-build-bundled-libzmf-on-aarch64.patch
Patch503: 0001-impl.-missing-function.patch
%endif

(and more than just those) resulting in those patches not being
included
in the src.rpm because the rpm was not built on rhel/centos.

My understanding was that platform specific patches were suppose to
have
the %if macro where the patch is applied, but should not be where the
source for the patch is defined.

Been a long time since I was a fedora packager so I don't know what
current packaging guidelines are, but that just seems wrong.

Is it wrong?

It depends .. in the Red Hat world, this is used so that patches are
applied on RHEL but not on Fedora.  That is the purpose of that patch.
The RHEL team added something to that patch for RHEL that is different
than Fedora.

So, if built on Fedora, those patches are not installed.  Why would that
be a problem?



Ouch, looking through the spec file it appears that it doesn't use the
normal %patch mechanism to apply patches. Looks like a change in RPM
itself that I am not very fond of.

It appears to use a git command to apply patches from some kind of a
patch macro, and apparently with sources too.

It's just my opinion but I am becoming less and less fond of RPM - just
like I became less and less fond of GNOME which I use to really love.

Guess I now know how dad felt when all the AIX servers he managed
started switching to that new-fangled Linux operating system...

_______________________________________________

Applying: installation fix
Applying: never run autogen.sh
error: patch failed: Makefile.in:14
error: Makefile.in: patch does not apply
Patch failed at 0002 never run autogen.sh
The copy of the patch that failed is found in:
   /builddir/build/BUILD/libreoffice-5.3.1.1/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
error: Bad exit status from /var/tmp/rpm-tmp.c4c5hh (%prep)

-=-=-
That's progress, eh? ;)

git is a source management tool. It's not a build tool. Ah well.

_______________________________________________

Ouch some of the patches are failing because I took them from CentOS src, because they were missing from Fedora source.rpm - it appears that in the newer Libre Office src.rpm - the rhel specific patches that are in the spec file but are not in the src.rpm share the same filename but different content than in the CentOS version of the older libreoffice.

I'm guessing it is possible those patches haven't even been ported to the newer LibreOffice - I'll try building without them, but that is what was wrong with the never run autogen patch.

I installed the CentOS src.rpm to get missing files and that also over-wrote some of the more current Fedora sources with the same name.

Guess using GIT means version control in filenames themselves is no longer being used.

Well in my quest to build rawhide libreoffice in CentOS 7 - I only have one more bad patch to deal with, I will try building without it.

I don't like RPM using git to apply patches though. It was much easier when I could just look at the failed hunks to see what went wrong.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux