Bug 1015123
Summary: | maven-release: FTBFS in rawhide | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mikolaj Izdebski <mizdebsk> | ||||||||
Component: | maven-release | Assignee: | Mikolaj Izdebski <mizdebsk> | ||||||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | rawhide | CC: | guido.grazioli, java-sig-commits, jcapik, mizdebsk, paulo.cesar.pereira.de.andrade, sochotni | ||||||||
Target Milestone: | --- | Keywords: | Patch | ||||||||
Target Release: | --- | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | 2.2.1-10 | Doc Type: | Bug Fix | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2014-03-06 12:11:02 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Mikolaj Izdebski
2013-10-03 13:26:38 UTC
Created attachment 839672 [details]
maven-release-ftbfs.patch
This is probably completely broken. But may work depending on
how the toString output is done, and how string'able it is.
I am not a java programmer, just some guessing around and
checking stackoverflow related suggestions of how to convert
a string back to a hash map (basically it is said to not do it),
but apparently previously it used some weird type punning to
pass around a HashMap pointer as a String
(or vice versa).
Created attachment 841063 [details]
maven-release-ftbfs.patch
This one should be better, and theoretically should not
change behaviour from when it was building... It basically
should defers type cast error to runtime, but I did not
add exception handling in case there are failures.
Well, I am just trying to "bootstrap" a java stack based on
Fedora packages on another distribution...
(In reply to Paulo Andrade from comment #2) > Created attachment 841063 [details] > maven-release-ftbfs.patch > > This one should be better, and theoretically should not > change behaviour from when it was building... It basically > should defers type cast error to runtime, but I did not > add exception handling in case there are failures. The second patch looks OK. I am not maintainer of maven-release and I have limited time, so it would be very helpful if you could follow rule described in [1] when preparing a patch. > Well, I am just trying to "bootstrap" a java stack based on > Fedora packages on another distribution... Out of curiosity, which distro? Also feel free to join #java-devel on Freenode. Asking questions there usually will be much easier than reporting bugs. We have regular visitors from other distros there too. [1] https://fedoraproject.org/wiki/User:Mizdebsk/HowToSubmitPatches (In reply to Mikolaj Izdebski from comment #3) > (In reply to Paulo Andrade from comment #2) > > Created attachment 841063 [details] > > maven-release-ftbfs.patch > > > > This one should be better, and theoretically should not > > change behaviour from when it was building... It basically > > should defers type cast error to runtime, but I did not > > add exception handling in case there are failures. > > The second patch looks OK. I am not maintainer of maven-release and I have > limited time, so it would be very helpful if you could follow rule described > in [1] when preparing a patch. I will try to make a proper patch, but for now I am just using %if 0%{?fedora} %else <<stuff I need different from fedora spec>>> %endif But I do not care of having credit for the patch, just showing what I am using right now, and attempting to have an idea if it would be usable :-) > > Well, I am just trying to "bootstrap" a java stack based on > > Fedora packages on another distribution... > > Out of curiosity, which distro? OpenMandriva. Right now I am almost at the point of building tomcat from sources. But the java stack is a mess of cyclic dependencies... I did create a javapackages-bootstrap huge package to inject (most) dependencies in the repositories: https://abf.rosalinux.ru/openmandriva/javapackages-bootstrap/blob/master/create-spec.pl and a few other packages were injected using a noarch rpm as source to break other cyclic deps found later... > Also feel free to join #java-devel on Freenode. Asking questions there > usually will be much easier than reporting bugs. We have regular visitors > from other distros there too. Is it really #java-devel on Freenode? I found myself alone there, so I left the room :-) > [1] https://fedoraproject.org/wiki/User:Mizdebsk/HowToSubmitPatches (In reply to Paulo Andrade from comment #4) > > Also feel free to join #java-devel on Freenode. Asking questions there > > usually will be much easier than reporting bugs. We have regular visitors > > from other distros there too. > > Is it really #java-devel on Freenode? I found myself alone there, > so I left the room :-) I believe it's #fedora-java (java-devel is our mailing list[1] :-) ) You can subscribe there as well, if you are going to be using (parts of) our java stack it might be useful to know about major changes in advance. [1] https://admin.fedoraproject.org/mailman/listinfo/java-devel Created attachment 847160 [details] 0001-fix-rhbz-1015123.patch This patch should address the recommendations at https://fedoraproject.org/wiki/User:Mizdebsk/HowToSubmitPatches I am using this patch in my fedora based java packages bootstrap for openmandriva. https://abf.rosalinux.ru/openmandriva/maven-release Note that I am calling fedora packages "upstream", thus the "Update to latest upstream release" logs there. Fixed in maven-release-2.2.1-10 I believe that this bug is fixed in maven-release-2.2.1-10, which is available in Fedora Rawhide, so I am closing this bug now. The build containing the fix can be found at Koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=502286 |