5 thoughts on - Would This Be Considered A Packaging Bug?
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?
It could be that the packagers did not want the patches distributed with the RHEL source packages as well (maybe something licensing related? Or not distributable as part of RHEL?). I agree that its annoying because you can’t take the RHEL srpm and rebuild on Fedora.
—
Jonathan Billings
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.
5 thoughts on - Would This Be Considered A Packaging Bug?
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?
It could be that the packagers did not want the patches distributed with the RHEL source packages as well (maybe something licensing related? Or not distributable as part of RHEL?). I agree that its annoying because you can’t take the RHEL srpm and rebuild on Fedora.
—
Jonathan Billings
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.