Created attachment 1753349 [details]
build.log

Created attachment 1753350 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Created attachment 1753351 [details]
state.log

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Dear Maintainer,

your package has an open Fails To Build From Source bug for Fedora 34.
Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. If you have already fixed this issue, please close this Bugzilla report.

Following the policy for such packages [2], your package will be orphaned if
this bug remains in NEW state more than 8 weeks (not sooner than 2021-03-29).

A week before the mass branching of Fedora 35 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 33 will be
retired regardless of the status of this bug.

[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html

Dear Maintainer,

your package has an open Fails To Build From Source bug for Fedora 34.
Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. If you have already fixed this issue, please close this Bugzilla report.

Following the policy for such packages [2], your package will be orphaned if
this bug remains in NEW state more than 8 weeks (not sooner than 2021-03-29).

A week before the mass branching of Fedora 35 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 33 will be
retired regardless of the status of this bug.

[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html

I've been looking into fixing the dom4j FTBFS I've made some progress but now I'm stuck because part of the problem is with msv.

I've managed to reduce the number of build errors in dom4j by dealing with the rename / moving of the org.relaxng.datatype class to com.sun.tools.rngdatatype. For me this required 2 changes:

1. Add a patch fixing all the imports, e.g. :

--- dom4j-2.0.0/src/main/java/org/dom4j/datatype/SchemaParser.java~     2016-04-13 22:15:15.00
+++ dom4j-2.0.0/src/main/java/org/dom4j/datatype/SchemaParser.java      2021-02-22 16:56:08.44
@@ -24,8 +24,8 @@ import org.dom4j.QName;
 import org.dom4j.io.SAXReader;
 import org.dom4j.util.AttributeHelper;

-import org.relaxng.datatype.DatatypeException;
-import org.relaxng.datatype.ValidationContext;
+import com.sun.tools.rngdatatype.DatatypeException;
+import com.sun.tools.rngdatatype.ValidationContext;

 import org.xml.sax.EntityResolver;
 import org.xml.sax.InputSource;

etc.


2. Add a BR + pom dep on the replacement jaxb-relaxng-datatype pkg:

BuildRequires: jaxb-relaxng-datatype

%pom_add_dep com.sun.xml.bind.external:relaxng-datatype::provided


I wanted to see if I could help with fixing msv, but I'm hitting the following issue there:

sudo dnf builddep msv.spec

No matching package to install: 'mvn(net.java:jvnet-parent:pom:)'

I just realized that I forgot to mention why I'm talking about dealing with the rename / moving of the org.relaxng.datatype class to com.sun.tools.rngdatatype.

The reason I mentioned this is because msv is impacted by this too. I still get errors about the org.relaxng.datatype lass being gone when building dom4j, even though this is not mentioned anywhere inside the dom4j sources anymore. These errors now come from these source lines:

import com.sun.msv.datatype.xsd.TypeIncubator;

 TypeIncubator incubator = new TypeIncubator(baseType);

 incubator.addFacet(name, value, fixed, context);

With the last line triggering the following errors:

[ERROR] /home/hans/projects/fedora/dom4j/f34/dom4j-2.0.0/src/main/java/org/dom4j/datatype/SchemaParser.java:[460,26] cannot access org.relaxng.datatype.ValidationContext
[ERROR]   class file for org.relaxng.datatype.ValidationContext not found

So as I said I believe that msv needs similar fixes.

Do you have any idea what to do about the missing BR ?  Should we unorphan it ?

(In reply to Hans de Goede from comment #8)
> I just realized that I forgot to mention why I'm talking about dealing with
> the rename / moving of the org.relaxng.datatype class to
> com.sun.tools.rngdatatype.
> 
> The reason I mentioned this is because msv is impacted by this too. I still
> get errors about the org.relaxng.datatype lass being gone when building
> dom4j, even though this is not mentioned anywhere inside the dom4j sources
> anymore. These errors now come from these source lines:
> 
> import com.sun.msv.datatype.xsd.TypeIncubator;
> 
>  TypeIncubator incubator = new TypeIncubator(baseType);
> 
>  incubator.addFacet(name, value, fixed, context);
> 
> With the last line triggering the following errors:
> 
> [ERROR]
> /home/hans/projects/fedora/dom4j/f34/dom4j-2.0.0/src/main/java/org/dom4j/
> datatype/SchemaParser.java:[460,26] cannot access
> org.relaxng.datatype.ValidationContext
> [ERROR]   class file for org.relaxng.datatype.ValidationContext not found
> 
> So as I said I believe that msv needs similar fixes.
> 
> Do you have any idea what to do about the missing BR ?  Should we unorphan
> it ?


yeah, I think we need to unorphan the missing BR, I adopted msv because I also need this one to other packages of mine.

not sure how to unophan this jvnet-parent package.

> not sure how to unophan this jvnet-parent package.

https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers?rd=PackageMaintainers/OrphanedPackages#Claiming_Ownership_of_a_Retired_Package

"""
1.    See if you can figure out why the package was retired including searching for information about orphaned packages on devel mailing list or emailing the former maintainer. You can also check dead.package in the SCM (url like: https://src.fedoraproject.org/rpms/package_name_here/blob/rawhide/f/dead.package)

2.    Announce on devel which packages you would like to become the owner of.

3.    Retired Fedora packages (rawhide branch retired) require a re-review if they are retired for more than eight weeks or if there is no previous review of the package. Submit a review request (a new bugzilla ticket) and have the package approved by a reviewer as if it were new to Fedora. See the package review process for more information. To unretire a EPEL branch if the package is still in Fedora, no re-review is required.

4.    Request unretirement by filing a releng ticket. Specify all branches that need to be un-retired (inlcuding "rawhide" for Rawhide, unless it is for EPEL only) and include the link to re-review. In this ticket, request that the Release Engineering team unblock the package for the releases that the package should be un-retired for. In this request, clearly specify which branches should be unblocked.

5.    Restore the contents in GIT and prepare a new build and update (if necessary).
"""

I've just done 1. dead.package says "Orphaned for 6+ weeks", so there does not seem to be any specific reason for its retirement, other then that the previous maintainer was no longer interested in maintaining this.

If you can take care of 2. and submit a re-review request for this:
https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review

For 3. and then let me know the bug number of the review-request, then I can take care of doing the package(re-)review.

Ping? I would really like to see this resolved so that I can resolve the dom4j FTBFS error.

I have outlined the procedure for un-orphaning jvnet-parent in comment 10.

As also mentioned there I can take care of the necessary re-review step if you send me a link to the review-request bugzilla.

So I've ended up fixing the dom4j FTBFS issue in a different way. "dnf repoquery --whatrequires msv-<subpkg>" returns nothing
but msv for all msv packages. So it seems that nothing is actually using msv at runtime. As such I've just removed the classes from dom4j which depend on msv as those seem to be unused (*).

Since nothing seems to runtime-depend on msv, perhaps msv can be orphaned and then retired ?



*) The dom4j package supports many XML parsers so it does no Requires all possible deps, instead it leaves it up to the package using it to have a Requires: for the deps of the parser which their package uses (through dom4j).