Bug 1801580

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