Remove apache-ivy support for Pack200 compression, to fix FTBFS#15980
Remove apache-ivy support for Pack200 compression, to fix FTBFS#15980ddstreet wants to merge 4 commits intomicrosoft:tomls/base/mainfrom
Conversation
ddstreet
requested review from
christopherco,
ddstreetmicrosoft and
reubeno
as code owners
|
@reubeno please let me know if there's a better way I could do this with the tooling...it seems like a bit of a special case package that comes to us already doing stuff the wrong way (i.e. patch handling) |
| [[components.apache-ivy.overlays]] | ||
| description = "Add upstream patch file tag to make Pack200 support optional." | ||
| type = "spec-insert-tag" | ||
| tag = "Source4" |
There was a problem hiding this comment.
I see that the upstream spec already does some patching via SourceXXX files instead of PatchXXX files... but it also does use %autosetup.
Did you look into whether the new patches you're introducing could be applied as normal PatchXXX files? Or is the issue that they need to be applied after the others that are already being applied oddly?
(We do have a patch-add overlay, but I'm assuming you didn't go for it because the oddities you mention in the preexisting spec.)
There was a problem hiding this comment.
I tried patch-add first, but the problem is it'll then get applied by %autosetup, and the patch that git format-patch creates from the upstream source doesn't apply because of the source tarball's CRLF line endings; it fails with errors like:
checking file asciidoc/release-notes.adoc
Hunk #1 FAILED at 55 (different line endings).
1 out of 1 hunk FAILED
checking file ivy.xml
Hunk #1 FAILED at 32 (different line endings).
Hunk #2 FAILED at 46 (different line endings).
Hunk #3 FAILED at 55 (different line endings).
Hunk #4 FAILED at 67 (different line endings).
I did some brief tests to see if I could unix2dos the patch file but that didn't help, and this is such a rare situation (I've never seen this problem before) I didn't want to spend too much time trying to finesse the patch file into just the right line endings in the right places to apply. I assume the upstream packager came to the same conclusion.
Agreed -- it looks like the upstream spec was already complicated. About the only thing that comes to mind is that it might be easier to read/understand the One note -- I think the only other considerations I'd take from here (but not change this PR for) are:
|
|
rebase on main, i'll address comments next |
…onal Package FTBFS with newer java because it no longer provides Pack200. Patch context changes required in asciidoc/release-notes.adoc section. This is intentionally added as a Source: instead of Patch: because this package's source tarball contains files in Windows (CRLF) format, which git patches won't cleanly apply to. Backported-from: apache/ant-ivy@d772841
The previous patch reworked the code to make Pack200 optional, and assumed the Pack200 support would come from apache-commons-compress. However, our build of apache-commons-compress specifically removes all support for Pack200. So we need to remove the java file that attempts to use it.
The upstream tarball unfortunately has its source files in Windows (CRLF) format, which breaks patching. The spec file already does dos2unix conversion on one source file it was patching, this expands that to patch all the source files we will patch with the previously added patch.
Since this package doesn't work with standard-defined Patch: that are applied with %autosetup, we need to add lines to manually apply the patch files we previously added.
ack, updated
ack, changed over to use
yeah i think this would be a useful addition. |
3 participants
This package FTBFS because java dropped Pack200 support. This backports a patch to make Pack200 support optional, as well as disabling that optional Pack200 support, so the package builds.
Note this package's upstream source tarball contains files in Windows (CRLF) format, which prevents git patches from cleanly applying; so this PR does more work than should be required simply to add two patch files.