[EPEL-devel] Re: EPEL package and Java 11 requirement.
On Tue, Oct 5, 2021 at 10:41 AM Stefan Bluhm wrote: > > When opening a Buzilla, these common issues popped up: > > java-11-openjdk-headless RPM does not provide java-headless capability > - https://bugzilla.redhat.com/show_bug.cgi?id=1797054 > - "Hi. This is intentional. It will be added once jdk8 will stop to be the > system JDK." > > javapackages-tools: wrong generated Requires: `java-headless >= 11` > - https://bugzilla.redhat.com/show_bug.cgi?id=1993879 > - "The culprint *may* be xmvn, as there is (at least) one pkg in rhel8 which > is jdk11 based but is build by Makefile, and do not suffer the issue." > - "A proper long-term fix would mean redesigning how provides and > auto-requires are supposed to work. There are several possibilities." > - "Another possibility is removing auto-requires on java-headless altogether > - they add little value and cause much trouble." > > Is it possible to disable the auto-require generation in xmvn? > Otherwise it seems I have to skip usage of xmvn just for that. > > Best wishes, > > Stefan > > > - Ursprüngliche Mail - > Von: "fedoraproject org" > An: "epel-devel" > Gesendet: Dienstag, 5. Oktober 2021 09:05:13 > Betreff: [EPEL-devel] Re: EPEL package and Java 11 requirement. > > Hello Mike, > > I thought (!) I read somewhere that this difference between java-headless and > java-11-headless was intentional (or at least I understood it that way). > Let me open a Bugzilla against Java 11. > > > > How did others tackle this issue in the past/currently though? I can't be the > first one creating an rpm with an autogenerated java-headless >= 1:9 tag. > > Is there a way to disable/remove this autogeneration or force it to be > something different? > Also I noticed some packages where the headless tag was not generated at all. > So maybe I could just remove the trigger for that. It is possible to filter generated requires. This was described in a comment in one of the bugs you referred to: https://bugzilla.redhat.com/show_bug.cgi?id=1993879#c10 -- Mikolaj Izdebski > > I tried removing maven-compiler-plugin from the pom and adding the > compiler.target=11 line in the build section but that gave the same result. > > Thanks and best wishes, > > Stefan > > - Ursprüngliche Mail - > Von: "Mike Rochefort" > An: "epel-devel" > Gesendet: Montag, 4. Oktober 2021 22:57:09 > Betreff: [EPEL-devel] Re: EPEL package and Java 11 requirement. > > On Mon, Oct 4, 2021 at 3:50 PM Stefan Bluhm > wrote: > > > > it provides "java-11-headless". Not "java-headless". At least not on my > > machine > > Doing my own checks on CentOS Stream 8 and RHEL 8.4, this sounds like a Fedora > change that didn't make its way back to RHEL. Worth opening a Bugzilla > report on? > > For posterity, only java-1.8.0 returns when checking for java-headless > on EL8 (latest > versions on RHEL for 1.8 and 11 as of writing). > > $ rpm -qp --provides > java-1.8.0-openjdk-headless-1.8.0.302.b08-0.el8_4.x86_64.rpm > /usr/bin/jjs > config(java-1.8.0-openjdk-headless) = 1:1.8.0.302.b08-0.el8_4 > java-1.8.0-headless = 1:1.8.0.302.b08-0.el8_4 > java-1.8.0-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 > java-1.8.0-openjdk-headless(x86-64) = 1:1.8.0.302.b08-0.el8_4 > java-headless = 1:1.8.0 > java-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 > jre-1.8.0-headless = 1:1.8.0.302.b08-0.el8_4 > jre-1.8.0-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 > jre-headless = 1:1.8.0 > jre-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 > libjava.so()(64bit) > libjava.so(SUNWprivate_1.1)(64bit) > libjsig.so()(64bit) > libjvm.so()(64bit) > libjvm.so(SUNWprivate_1.1)(64bit) > libverify.so()(64bit) > libverify.so(SUNWprivate_1.1)(64bit) > > $ rpm -qp --provides java-11-openjdk-headless-11.0.12.0.7-0.el8_4.x86_64.rpm > config(java-11-openjdk-headless) = 1:11.0.12.0.7-0.el8_4 > java-11-headless = 1:11.0.12.0.7-0.el8_4 > java-11-openjdk-headless = 1:11.0.12.0.7-0.el8_4 > java-11-openjdk-headless(x86-64) = 1:11.0.12.0.7-0.el8_4 > jre-11-headless = 1:11.0.12.0.7-0.el8_4 > jre-11-openjdk-headless = 1:11.0.12.0.7-0.el8_4 > > -- > Mike > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org >
[EPEL-devel] Re: Koschei enablement for EPEL 8
Based on feedback received I have just added "EPEL 8" and "EPEL 8 playground" collections to Koschei. For now only a single package is tracked in each collection - epel-release package, but are free to add more packages as needed. On Wed, Aug 28, 2019 at 9:15 AM Mikolaj Izdebski wrote: > > Fedora infrastructure has been asked [1] to enable Koschei [2] for > EPEL 8. Would this be useful to anyone? If yes, which of build targets > (epel8-candidate, epel8-playground-candidate) should Koschei submit > scratch builds for? > > [1] https://pagure.io/fedora-infrastructure/issue/8099 > [2] https://fedoraproject.org/wiki/Koschei ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Koschei enablement for EPEL 8
On Wed, Aug 28, 2019 at 2:53 PM Stephen John Smoogen wrote: > > On Wed, 28 Aug 2019 at 03:16, Mikolaj Izdebski wrote: > > > > Fedora infrastructure has been asked [1] to enable Koschei [2] for > > EPEL 8. Would this be useful to anyone? If yes, which of build targets > > (epel8-candidate, epel8-playground-candidate) should Koschei submit > > scratch builds for? > > > > Can koschei be limited to a single architecture or does it need to > build against all targets? I am worried about the number of s390 > builds we may be adding. Yes, Koschei can be limited to certain architectures, possibly just one. The instances that are ran on Fedora infrastructure are limited to x86_64, aarch64, ppc64 and ppc64le in production and just x86_64 in staging. Noarch builds can be ran on other architectures too, including s390x, but this is how Fedora Koji is configured. -- Mikolaj Izdebski ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Koschei enablement for EPEL 8
Fedora infrastructure has been asked [1] to enable Koschei [2] for EPEL 8. Would this be useful to anyone? If yes, which of build targets (epel8-candidate, epel8-playground-candidate) should Koschei submit scratch builds for? [1] https://pagure.io/fedora-infrastructure/issue/8099 [2] https://fedoraproject.org/wiki/Koschei ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?
On Mon, Aug 12, 2019 at 11:21 AM Miro Hrončok wrote:
>
> On 12. 08. 19 11:16, Mikolaj Izdebski wrote:
> > On Mon, Aug 12, 2019 at 11:14 AM Miro Hrončok wrote:
> >>
> >> On 12. 08. 19 11:12, Mikolaj Izdebski wrote:
> >>> On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok wrote:
> >>>>
> >>>> See for example:
> >>>>
> >>>> https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
> >>>> 2019-08-11 07:50:11
> >>>>
> >>>> - nothing provides python(abi) = 3.6 ...
> >>>>
> >>>> This is provided in RHEL 7.7.
> >>>>
> >>>> (Note that we've unretired the python36 package, so later it resolved
> >>>> correctly.)
> >>>
> >>> Koschei uses Koji repos. You can find out the exact repo URL at given
> >>> timestamp in the following way:
> >>>
> >>> In [1]: import koji, datetime
> >>> In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
> >>> In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
> >>> In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
> >>> In [5]: event = ks.getLastEvent(before=ts)
> >>> In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
> >>> event=event['id'])
> >>> In [7]: pi.repo(repo['id'], 'epel7-build')
> >>> Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'
> >>
> >> And for RHEL packages?
> >
> > Selected RHEL packages are available in EPEL buildroots.
>
> Oh. Do you know any pointers about how do I add more?
EPEL 7 build uses repos from 5 RHEL 7 channels.
You can see them with the following command:
$ koji list-external-repos --tag epel7-base
Pri External repo nameMode URL
--- - --
10 rhel7-server koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-7-server-rpms/
11 rhel7-rhel-extras koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-7-server-extras-rpms/
12 rhel7-server-ha koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-ha-for-rhel-7-server-rpms/
15 rhel7-server-optional koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-7-server-optional-rpms/
20 rhel7-server-rhscl-7 koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-server-rhscl-7-rpms/
Koji admins (i.e. Release Engineering) can add more channels upon
request from EPEL developers.
Before adding to Koji, RHEL repos would need to be synced from RHN to
Fedora servers (this can be requested from Fedora Infrastructure).
>
> >>> x86_64 repos are used for dependency resolution. At that time python36
> >>> was not available in epel7-build:
> >>
> >> Are RHEL packages available directly from epel7-build?
> >
> > Yes, they are. Eg python-0:2.7.5-80.el7_6.x86_64 from my example is a
> > RHEL build.
>
> I see. Thanks.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?
On Mon, Aug 12, 2019 at 11:14 AM Miro Hrončok wrote:
>
> On 12. 08. 19 11:12, Mikolaj Izdebski wrote:
> > On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok wrote:
> >>
> >> See for example:
> >>
> >> https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
> >> 2019-08-11 07:50:11
> >>
> >> - nothing provides python(abi) = 3.6 ...
> >>
> >> This is provided in RHEL 7.7.
> >>
> >> (Note that we've unretired the python36 package, so later it resolved
> >> correctly.)
> >
> > Koschei uses Koji repos. You can find out the exact repo URL at given
> > timestamp in the following way:
> >
> > In [1]: import koji, datetime
> > In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
> > In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
> > In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
> > In [5]: event = ks.getLastEvent(before=ts)
> > In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
> > event=event['id'])
> > In [7]: pi.repo(repo['id'], 'epel7-build')
> > Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'
>
> And for RHEL packages?
Selected RHEL packages are available in EPEL buildroots.
>
> > x86_64 repos are used for dependency resolution. At that time python36
> > was not available in epel7-build:
>
> Are RHEL packages available directly from epel7-build?
Yes, they are. Eg python-0:2.7.5-80.el7_6.x86_64 from my example is a
RHEL build.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?
On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok wrote:
>
> See for example:
>
> https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
> 2019-08-11 07:50:11
>
> - nothing provides python(abi) = 3.6 ...
>
> This is provided in RHEL 7.7.
>
> (Note that we've unretired the python36 package, so later it resolved
> correctly.)
Koschei uses Koji repos. You can find out the exact repo URL at given
timestamp in the following way:
In [1]: import koji, datetime
In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
In [5]: event = ks.getLastEvent(before=ts)
In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
event=event['id'])
In [7]: pi.repo(repo['id'], 'epel7-build')
Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'
x86_64 repos are used for dependency resolution. At that time python36
was not available in epel7-build:
$ dnf -q --repofrompath
epel7-build-1234463,https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463/x86_64/
--repo epel7-build-1234463 repoquery --whatprovides 'python(abi)'
python-0:2.7.5-80.el7_6.x86_64
python34-0:3.4.10-2.el7.x86_64
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: [EPEL-devel] build gradle 2.5 for EPEL?
On 09/09/2015 04:32 PM, matt_dom...@dell.com wrote: > Dell - Internal Use - Confidential > Mikolaj, would you please build gradle 2.5 for EPEL 7? My development team > uses gradle for our builds, and I much prefer getting packages from the > RHEL/CentOS and/or EPEL yum repositories whenever possible. Packaging Gradle for EPEL 7 is not a trivial task and currently I don't have resources to do that myself, however I'm willing to help if anyone wants to attempt that. > Gradle 2.2.1-6 (as in F22) has a bug which prevents my projects from building > correctly, which is fixed in 2.5 and above. We can try to backport individual bugfixes to F22 if you file a bug report in bugzilla. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Orphaned jai-imageio-core in 6
I've just orphaned jai-imageio-core in EPEL 6. Feel free to take it. I have no idea how I become the owner of this package in EPEL 6. I definitely don't remember agreeing to take it. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
