Spec URL: https://deamn.fedorapeople.org/openjfx-11.spec SRPM URL: https://deamn.fedorapeople.org/openjfx-11-11.0.3-0.fc31.src.rpm Description: JavaFX/OpenJFX is a set of graphics and media APIs that enables Java developers to design, create, test, debug, and deploy rich client applications that operate consistently across diverse platforms. The media and web module have been removed due to missing dependencies. Fedora Account System Username: deamn
Hi! On first glance, the spec looks good. Where the poms come from? I tried to run fedora-review but the build fails. So I run it manually, and got: ERROR: Command failed: # /usr/bin/dnf builddep --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 31 --setopt=deltarpm=False --allowerasing --disableplugin=local --disableplugin=spacewalk --disableplugin=local --disableplugin=spacewalk /var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/openjfx-11-11.0.3-0.fc33.src.rpm No matches found for the following disable plugin patterns: local, spacewalk fedora 14 kB/s | 9.9 kB 00:00 No matching package to install: 'mvn(org.codehaus.mojo:native-maven-plugin)' Thoughts?
Is really both BuildRequires: pkgconfig(gtk+-2.0) BuildRequires: pkgconfig(gtk+-3.0) needed?
> No matching package to install: 'mvn(org.codehaus.mojo:native-maven-plugin)' > valid for f32+ on f31 dependency is satisfied. I can run review against f31, but you will need to fix it (thus likely adopt the native maven plugin)
(In reply to jiri vanek from comment #3) > > No matching package to install: 'mvn(org.codehaus.mojo:native-maven-plugin)' > > > valid for f32+ on f31 dependency is satisfied. I can run review against > f31, but you will need to fix it (thus likely adopt the native maven plugin) in my f31 mockbuild log, the package is maven-native-components-1.0-0.17.alpha.8.fc31.noarch. This package is orphaned in f32?
(In reply to jiri vanek from comment #2) > Is really both > BuildRequires: pkgconfig(gtk+-2.0) > BuildRequires: pkgconfig(gtk+-3.0) > > needed? I think yes, because they are two libs: libglassgtk2.so and libglassgtk3.so
btw, there is openjfx package. Do yo mind to clarify the coexistence of those two? I guess openjfx is, and will rewamin for jdk8, where this openjfx-11 will be for jdk11...and up? In that moment the weuestion arise, how to deal with those. Will you rename the package with jdk14 and/or 17? Also I believe your package *is* working with anything we build under java-latest-openjdk, so you should require java >=11, but in that moment the name is wrong. To have it working flawlessly, we had this in openjdk8 for openjfx(8): https://koji.fedoraproject.org/koji/rpminfo?rpmID=20202175 That is a binding subpackage (coantains only symlinks). Is something like that wortky for 11+? dnf install javafx Last metadata expiration check: 1:09:27 ago on Wed 19 Feb 2020 09:58:11 AM CET. Dependencies resolved. ================================================================================ Package Arch Version Repo Size ================================================================================ Installing: java-1.8.0-openjdk-openjfx x86_64 1:1.8.0.242.b08-0.fc31 updates 34 k Installing dependencies: openjfx x86_64 8.0.202-8.b07.fc31 fedora 8.7 M Transaction Summary ================================================================================ Install 2 Packages Before review itself, we have to clarify the system integration. From this point of view, you step into a self-contianed change :)
(In reply to jiri vanek from comment #1) > Hi! > > On first glance, the spec looks good. Where the poms come from? > I tried to run fedora-review but the build fails. So I run it manually, and > got: > ERROR: Command failed: > # /usr/bin/dnf builddep --installroot > /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 31 > --setopt=deltarpm=False --allowerasing --disableplugin=local > --disableplugin=spacewalk --disableplugin=local --disableplugin=spacewalk > /var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/openjfx-11-11. > 0.3-0.fc33.src.rpm > No matches found for the following disable plugin patterns: local, spacewalk > fedora > 14 kB/s | 9.9 kB 00:00 > No matching package to install: 'mvn(org.codehaus.mojo:native-maven-plugin)' > > > Thoughts? I wrote the poms based on the build.gradle file provided by openjfx
fyi https://bugzilla.redhat.com/show_bug.cgi?id=1438673
> > I wrote the poms based on the build.gradle file provided by openjfx I see. Cool. It would be nice to upstream them, and to get rid of that gradle of theirs (me, just wishes:) ). On contrary, gradle have a bit better support for native building. TY!
You maintain opejfx(8) now right? Is debuginfo/debugsources omitted with reason? (seeying %global debug_package %{nil} on place)
(In reply to jiri vanek from comment #6) > btw, there is openjfx package. Do yo mind to clarify the coexistence of > those two? I guess openjfx is, and will rewamin for jdk8, where this > openjfx-11 will be for jdk11...and up? > In that moment the weuestion arise, how to deal with those. Will you rename > the package with jdk14 and/or 17? > Also I believe your package *is* working with anything we build under > java-latest-openjdk, so you should require java >=11, but in that moment the > name is wrong. > > To have it working flawlessly, we had this in openjdk8 for openjfx(8): > https://koji.fedoraproject.org/koji/rpminfo?rpmID=20202175 > That is a binding subpackage (coantains only symlinks). Is something like > that wortky for 11+? > > dnf install javafx > Last metadata expiration check: 1:09:27 ago on Wed 19 Feb 2020 09:58:11 AM > CET. > Dependencies resolved. > ============================================================================= > === > Package Arch Version Repo > Size > ============================================================================= > === > Installing: > java-1.8.0-openjdk-openjfx x86_64 1:1.8.0.242.b08-0.fc31 updates > 34 k > Installing dependencies: > openjfx x86_64 8.0.202-8.b07.fc31 fedora > 8.7 M > > Transaction Summary > ============================================================================= > === > Install 2 Packages > > > Before review itself, we have to clarify the system integration. From this > point of view, you step into a self-contianed change :) For the coexistence, you are right: openjfx is only for jdk8. openjfx (JavaFX) is included into JDK8 but compiled separately into two projects: openjdk and openjfx. That's why there is a subpackage with only symlinks. Since Java 9 (or 10) openjfx is a separated library. No need to create symlinks. openjdk-8 and openjdk-11 are long term support. That's why I would like to maintain openjfx libraries for those two JDKs. When the next LTS openjdk will released (openjdk-14) I think a new package could be created. For the intermediate openjdk, I could create a openjfx-latest package? openjfx N runs on openjdk N-1 (dixit Johan Vos openjfx co-lead at JFX Days in Zurich last december)
> > For the coexistence, you are right: openjfx is only for jdk8. openjfx > (JavaFX) is included into JDK8 but compiled separately into two projects: > openjdk and openjfx. That's why there is a subpackage with only symlinks. > Since Java 9 (or 10) openjfx is a separated library. No need to create > symlinks. Good. thanx! > > openjdk-8 and openjdk-11 are long term support. That's why I would like to > maintain openjfx libraries for those two JDKs. When the next LTS openjdk > will released (openjdk-14) I think a new package could be created. For the nope, openjdk 17 is next LTS > intermediate openjdk, I could create a openjfx-latest package? openjfx N > runs on openjdk N-1 (dixit Johan Vos openjfx co-lead at JFX Days in Zurich > last december) Is the depndence really so strict? Hard to belive... If not, I would vote for: renaming current openjfx to openjfx8 made this package "openjfx" requiring java >= 11 Where the target jdk will be te highest LTS (11 for now) and latest STS(14 in few weeks). To have it aligned as you are suggesting ojdk 8,11 and latest x openjfx 8,11, lates is kind offer, but may be very very confusing.
(In reply to jiri vanek from comment #3) > > No matching package to install: 'mvn(org.codehaus.mojo:native-maven-plugin)' > > > valid for f32+ on f31 dependency is satisfied. I can run review against > f31, but you will need to fix it (thus likely adopt the native maven plugin) I open a request to adopt maven-native https://pagure.io/releng/issue/9270
thank you, Do you mind to elaborate on: "openjfx N runs on openjdk N-1 " it is very hard to accept:(
(In reply to jiri vanek from comment #14) > thank you, Do you mind to elaborate on: "openjfx N runs on openjdk N-1 " it > is very hard to accept:( My understanding is that the N here refers to the latest LTS and is the minimal version it runs on. This means for example that current OpenJFX runs on 11+, once the next LTS will be released, assuming for example this to be OpenJDK 17, OpenJFX will only run on 17+. Cheers, Mario
(In reply to Mario Torre from comment #15) > (In reply to jiri vanek from comment #14) > > thank you, Do you mind to elaborate on: "openjfx N runs on openjdk N-1 " it > > is very hard to accept:( > > My understanding is that the N here refers to the latest LTS and is the > minimal version it runs on. This means for example that current OpenJFX runs > on 11+, once the next LTS will be released, assuming for example this to be > OpenJDK 17, OpenJFX will only run on 17+. > > Cheers, > Mario Nicolas, what Mario says leads us to rename of openjx to openjfx8 requiring java <= 1.8.0 and this one to openjfx rewuiring java >=11 as is common for compact packages. WDYT?
(In reply to jiri vanek from comment #10) > You maintain opejfx(8) now right? > > Is debuginfo/debugsources omitted with reason? (seeying %global > debug_package %{nil} on place) Yes I'm the maintainer of openjfx(8). It's not clear how to generate debuginfo and debugsources. It's mandatory? Could you help me?
(In reply to jiri vanek from comment #16) > (In reply to Mario Torre from comment #15) > > (In reply to jiri vanek from comment #14) > > > thank you, Do you mind to elaborate on: "openjfx N runs on openjdk N-1 " it > > > is very hard to accept:( > > > > My understanding is that the N here refers to the latest LTS and is the > > minimal version it runs on. This means for example that current OpenJFX runs > > on 11+, once the next LTS will be released, assuming for example this to be > > OpenJDK 17, OpenJFX will only run on 17+. > > > > Cheers, > > Mario > > Nicolas, what Mario says leads us to rename of openjx to openjfx8 requiring > java <= 1.8.0 and this one to openjfx rewuiring java >=11 as is common for > compact packages. WDYT? I agree with that. I must to rename openjfx in openjfx8 but for which versions? F30, F31 and F32? Currently the F32 version is in FTBFS https://bugzilla.redhat.com/show_bug.cgi?id=1799832. I need to use maven instead of gradle. I must make a new package review for this package (renamed from openjfx-11 to openjfx)?
(In reply to Nicolas De Amicis from comment #17) > (In reply to jiri vanek from comment #10) > > You maintain opejfx(8) now right? > > > > Is debuginfo/debugsources omitted with reason? (seeying %global > > debug_package %{nil} on place) > > Yes I'm the maintainer of openjfx(8). > > It's not clear how to generate debuginfo and debugsources. It's mandatory? > Could you help me? Nope, itis not mandatory. Especially with the grade x maven work you did, and with jni involve, itis definitely not mandatory, and I doubt any reviwer (looks like me) will notisnists.
(In reply to Nicolas De Amicis from comment #18) > (In reply to jiri vanek from comment #16) > > (In reply to Mario Torre from comment #15) > > > (In reply to jiri vanek from comment #14) > > > > thank you, Do you mind to elaborate on: "openjfx N runs on openjdk N-1 " it > > > > is very hard to accept:( > > > > > > My understanding is that the N here refers to the latest LTS and is the > > > minimal version it runs on. This means for example that current OpenJFX runs > > > on 11+, once the next LTS will be released, assuming for example this to be > > > OpenJDK 17, OpenJFX will only run on 17+. > > > > > > Cheers, > > > Mario > > > > Nicolas, what Mario says leads us to rename of openjx to openjfx8 requiring > > java <= 1.8.0 and this one to openjfx rewuiring java >=11 as is common for > > compact packages. WDYT? > > I agree with that. > > I must to rename openjfx in openjfx8 but for which versions? F30, F31 and > F32? Currently the F32 version is in FTBFS > https://bugzilla.redhat.com/show_bug.cgi?id=1799832. I need to use maven > instead of gradle. > I must make a new package review for this package (renamed from openjfx-11 > to openjfx)? That is moving us to utterly different workflow... Afaik you can bump your openjfx pkg to sources from this review in rawhide, and I have to adapt java-1.8.0-openjdk-fx packages to require javafx-8 In meantime you can start review of openjfx8, as new, compact package. Which openjdk8-fx will later depend on. If you fail to fix the FTBS, then it is on to yu to drop it. It happens. I will then just remove openjfx binding from openjdk8. This sounds like rawhide only for a while, and backporting should be slow, although to have it in f32 would be useful and nice, I dont think we are meting deadlines, as this is in fact at least self-contained chnage. Still, wdyt? I really would like to have wider audience on this:(
(In reply to jiri vanek from comment #20) > (In reply to Nicolas De Amicis from comment #18) > > (In reply to jiri vanek from comment #16) > > > (In reply to Mario Torre from comment #15) > > > > (In reply to jiri vanek from comment #14) > > > > > thank you, Do you mind to elaborate on: "openjfx N runs on openjdk N-1 " it > > > > > is very hard to accept:( > > > > > > > > My understanding is that the N here refers to the latest LTS and is the > > > > minimal version it runs on. This means for example that current OpenJFX runs > > > > on 11+, once the next LTS will be released, assuming for example this to be > > > > OpenJDK 17, OpenJFX will only run on 17+. > > > > > > > > Cheers, > > > > Mario > > > > > > Nicolas, what Mario says leads us to rename of openjx to openjfx8 requiring > > > java <= 1.8.0 and this one to openjfx rewuiring java >=11 as is common for > > > compact packages. WDYT? > > > > I agree with that. > > > > I must to rename openjfx in openjfx8 but for which versions? F30, F31 and > > F32? Currently the F32 version is in FTBFS > > https://bugzilla.redhat.com/show_bug.cgi?id=1799832. I need to use maven > > instead of gradle. > > I must make a new package review for this package (renamed from openjfx-11 > > to openjfx)? > > That is moving us to utterly different workflow... > Afaik you can bump your openjfx pkg to sources from this review in > rawhide, and I have to adapt java-1.8.0-openjdk-fx packages to require > javafx-8 > In meantime you can start review of openjfx8, as new, compact package. Which > openjdk8-fx will later depend on. If you fail to fix the FTBS, then it is on > to yu to drop it. It happens. I will then just remove openjfx binding from > openjdk8. > This sounds like rawhide only for a while, and backporting should be slow, > although to have it in f32 would be useful and nice, I dont think we are > meting deadlines, as this is in fact at least self-contained chnage. > > Still, wdyt? > I really would like to have wider audience on this:( Sorry, correct me if I misunderstood: I commit into package openjfx the code from this review (openjfx 11) in rawhide. In meantime I fix the FTBFS of the package openjfx (openjfx 8) in F32. Finally, I make a package review for a new openjfx8 package and I merge into the code for openjfx 8 and you drive the modifications needed for java-1.8.0-openjdk-openjfx?
Moreover yes. > I commit into package openjfx the code from this review (openjfx 11) in rawhide. In that moment I have to disable openjdk8 bindings. > In meantime I fix the FTBFS of the package openjfx (openjfx 8) in F32. Yes, unless you wish to have both openjfx-8 and openjfx(-11) in f32 In that case the FTBS failure can be solved during openjfx-8 review. But I doubt that :) We have to start in rawhide, and are unlikely to make it for f32. Probably the most correct way is to go as self-contained change for f33, to get a proper adudience on the topic. > I make a package review for a new openjfx8 package and I merge into the code for openjfx 8 and you drive the modifications needed for java-1.8.0-openjdk-openjfx yes
Small update. We will (try to) move jdk11 to system jdk in f33
(In reply to jiri vanek from comment #23) > Small update. We will (try to) move jdk11 to system jdk in f33 Thanks for the update. maven-native is unretired today, I will commit and publish the new version soon. I'm currently working and resolve the FTBFS on openjfx8. I will also commit the code of openjfx11 into rawhide of the project openjfx like as discussed.
as discussed, openjfx8 for javafx8 and openjfx for javafx11 are in rawhide