Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Matthew Miller]

On Fri, Oct 08, 2021 at 11:10:17AM +0200, Mario Torre wrote:
> > RPMs. This is a hybrid packaging model, where some Java RPM packages
> > can be built in the traditional way (where code is compiled during
> > rpmbuild) and some are built elsewhere, and only wrapped in RPMs.
> So the only thing left to do is to convince Mr. Fedora to approve this ;)

Well, there's no magical "Mr. Fedora"... what needs to happen is someone
needs to make a proof of concept.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

> Am 08.10.2021 um 14:11 schrieb Kevin Kofler via devel 
> :
> 
> Mario Torre wrote:
> 
>> On Fri, Oct 8, 2021 at 2:11 AM Kevin Kofler via devel wrote:
>>> And that is actually a problem rather than a solution. Maven artifacts
>>> are basically write once only. Everything depends on a hardcoded version
>>> which, once uploaded, is normally never touched again. This means that
>>> security bugs and other bugs never get fixed (unless the application
>>> bumps the dependency version, which can take months or years or even just
>>> never happen). That is exactly what the RPM system is designed to avoid.
>> 
>> Well, that's why it should be "curated" and not just a mirror of maven
>> central.
> 
> No amount of "curating" can fix this inherent design limitation of Maven.

Maven may have a lot of design limitations, but this scenario is none of them. 
No build system can completely compensate a careless developer or system 
administrator.

And what is the alternative? If we don't find a way to make building Java 
application rpm easier, there will be no Fedora rpm for many applications at 
all. And then, what happens? The sysadmin installs a binary from some source. 
And then happens exactly what you fear: The program runs forever and  
>  that opens all sorts of cans of worms (caching, reproducibility, 
> changed checksums, etc.).


Peter

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Sérgio Basto]

On Wed, 2021-10-06 at 14:37 +0200, Mikolaj Izdebski wrote:
> On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller <
> mat...@fedoraproject.org> wrote:
> > 
> > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> > > I'm not sure what's the best solution, but I guess the number one
> > > reason to have packages within the Fedora distribution is for a
> > > matter
> > > of trust, if this is the case I would argue that a curated list of
> > > maven packages served via a Fedora managed repository would be a
> > > better investment.
> > 
> > I'd love to see someone interested in this pursue this idea! I know
> > we
> > talked about it as long ago as... Flock Prague... and probably
> > before.
> 
> That's a very old idea that has been partially implemented years ago,
> but never approved for use in Fedora. Maven artifacts can be built in
> Koji (there is an existing "koji maven-build" command). Once built
> they appear in a "curated" Maven repository hosted on Koji, that can
> be synced to mirrors, from where users can consume it. Consumers of
> this Maven repository don't need to be running Fedora, not even Linux.

ah Now I understand better this wiki page 
https://fedoraproject.org/wiki/KojiMavenSupport


> Curated Maven repository contains additional metadata, eg. CVEs
> affecting given artifact version, whether upstream is active, whether
> given artifact is available in Fedora and in which releases, etc. For
> each Fedora Linux release there is an auto-generated BOM (bill of
> materials POM) listing artifacts available in the release.
> 
> Binaries from this trusted/curated Maven repository can also be
> wrapped into RPMs (using "koji wrapper-rpm" command) and put into
> distribution repos and composes. Other packages can depend on such
> RPMs. This is a hybrid packaging model, where some Java RPM packages
> can be built in the traditional way (where code is compiled during
> rpmbuild) and some are built elsewhere, and only wrapped in RPMs.
> 
> --
> Mikolaj Izdebski
> 
> > 
> > --
> > Matthew Miller
> > 
> > Fedora Project Leader
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

> Am 08.10.2021 um 14:08 schrieb Kevin Kofler via devel 
> :
> 
> Peter Boy wrote:
>> A valid point, but only in case the app that consumes the maven artefact
>> in unmaintained.
> 
> Many applications are maintained and never (or very rarely, only when they 
> encounter some issue with the version they currently use) bother bumping 
> their dependencies after adding them once. Especially in the corporate 
> world, this is commonplace.

Yes, unfortunately in case of security issues. But those people wouldn’t be 
amused either if you silently exchanged a lib/jar.

As a Fedora rpm, the app will get rebuild about every 6 months. The „curated 
list“ as proposed/implemented by Mikolaj keeps track of upstream maintenance 
and security issues (at least it is constructed to be able to do as he 
described). So we can make a rebuild fail if it uses a security tainted version 
instead of a newer one. 

That would be quite a broad hint. If someone ignores that, the problem is not 
one of jar vs. rpm. 



>>> I think this would be not only a huge
>>> waste of space
>> 
>> given the current size of hard drive space, this really isn't a problem.
>> You won't be able to install a meaningful collection of apps whose
>> cumulative footprint of jars installed in parallel leaves any noticeable
>> trace on a x tb disk.
> 
> Considering that Fedora now also targets devices with as little as 16 or 32 
> GB out-of-the-box storage:
> 
> https://fedoraproject.org/wiki/Architectures/ARM/PinePhone
> https://wiki.pine64.org/index.php/PinePhone#Specifications
> 
> that argument is invalid.

Boxes with these storage limitation have usually other limitations as well and 
are not a device to install a huge bunch of software. But even with 16g GB 
storage, what is a typical size of jars? E.g. the set of log4j jars need about 
2mb. You need a lot of jars installed redundantly to flood 16 gb of storage. 

In theory you are right, but practically this will not be a problem in the vast 
majority of cases.  

And in any case, it is better to have applications as rpm for a large number of 
typical usage scenarios than no rpm version at all for anyone. 

All that under the assumption that said „curated list workflow“  will make it 
easier to build a Java application rpm. 





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Kevin Kofler via devel]

Mario Torre wrote:

> On Fri, Oct 8, 2021 at 2:11 AM Kevin Kofler via devel wrote:
>> And that is actually a problem rather than a solution. Maven artifacts
>> are basically write once only. Everything depends on a hardcoded version
>> which, once uploaded, is normally never touched again. This means that
>> security bugs and other bugs never get fixed (unless the application
>> bumps the dependency version, which can take months or years or even just
>> never happen). That is exactly what the RPM system is designed to avoid.
> 
> Well, that's why it should be "curated" and not just a mirror of maven
> central.

No amount of "curating" can fix this inherent design limitation of Maven. 
You cannot just replace foo-1.2.3 with a different version with security 
fixes, that opens all sorts of cans of worms (caching, reproducibility, 
changed checksums, etc.). So you need to upload something like foo-1.2.3.1 
and then bump the dependency in every single application. How is that any 
easier than just building against the latest foo to begin with?

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Kevin Kofler via devel]

Peter Boy wrote:
> A valid point, but only in case the app that consumes the maven artefact
> in unmaintained.

Many applications are maintained and never (or very rarely, only when they 
encounter some issue with the version they currently use) bother bumping 
their dependencies after adding them once. Especially in the corporate 
world, this is commonplace.

I wrote:
>> So you propose to bundle a whole bunch of JARs, some of which have been
>> built many Fedora releases ago and might not even be buildable in any
>> currently supported Fedora anymore?

and Peter Boy replied: 
> No! See above.

Yet, that is exactly what "Once a JAR is built, the resulting bytecode will
work with current and future JVMs. There is no need to mass-rebuild JARs
every 6 months." (Michal Srb) implies.

>> I think this would be not only a huge
>> waste of space
> 
> given the current size of hard drive space, this really isn't a problem.
> You won't be able to install a meaningful collection of apps whose
> cumulative footprint of jars installed in parallel leaves any noticeable
> trace on a x tb disk.

Considering that Fedora now also targets devices with as little as 16 or 32 
GB out-of-the-box storage:

https://fedoraproject.org/wiki/Architectures/ARM/PinePhone
https://wiki.pine64.org/index.php/PinePhone#Specifications

that argument is invalid.

> But you gain a lot in security if as many of these
> apps as possible are managed as rpm.

Sure, a bunch of JARs in an RPM is marginally better than a bunch of JARs in 
a tarball. But it is no replacement for real packaging with unbundling.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Mario Torre]

On Fri, Oct 8, 2021 at 2:11 AM Kevin Kofler via devel
 wrote:
>
> Michal Srb wrote:
> > Unlike RPM repositories, Maven repositories can easily hold multiple
> > versions of libraries. Once a JAR is built, the resulting bytecode will
> > work with current and future JVMs. There is no need to mass-rebuild JARs
> > every 6 months. And there is certainly no need to try to run every single
> > Java application with a single "system-wide" version of a library.
>
> And that is actually a problem rather than a solution. Maven artifacts are
> basically write once only. Everything depends on a hardcoded version which,
> once uploaded, is normally never touched again. This means that security
> bugs and other bugs never get fixed (unless the application bumps the
> dependency version, which can take months or years or even just never
> happen). That is exactly what the RPM system is designed to avoid.

Well, that's why it should be "curated" and not just a mirror of maven central.

Cheers,
Mario

-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Mario Torre]

On Wed, Oct 6, 2021 at 2:39 PM Mikolaj Izdebski  wrote:
>
> On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller  
> wrote:
> >
> > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> > > I'm not sure what's the best solution, but I guess the number one
> > > reason to have packages within the Fedora distribution is for a matter
> > > of trust, if this is the case I would argue that a curated list of
> > > maven packages served via a Fedora managed repository would be a
> > > better investment.
> >
> > I'd love to see someone interested in this pursue this idea! I know we
> > talked about it as long ago as... Flock Prague... and probably before.
>
> That's a very old idea that has been partially implemented years ago,
> but never approved for use in Fedora. Maven artifacts can be built in
> Koji (there is an existing "koji maven-build" command). Once built
> they appear in a "curated" Maven repository hosted on Koji, that can
> be synced to mirrors, from where users can consume it. Consumers of
> this Maven repository don't need to be running Fedora, not even Linux.
>
> Curated Maven repository contains additional metadata, eg. CVEs
> affecting given artifact version, whether upstream is active, whether
> given artifact is available in Fedora and in which releases, etc. For
> each Fedora Linux release there is an auto-generated BOM (bill of
> materials POM) listing artifacts available in the release.
>
> Binaries from this trusted/curated Maven repository can also be
> wrapped into RPMs (using "koji wrapper-rpm" command) and put into
> distribution repos and composes. Other packages can depend on such
> RPMs. This is a hybrid packaging model, where some Java RPM packages
> can be built in the traditional way (where code is compiled during
> rpmbuild) and some are built elsewhere, and only wrapped in RPMs.

So the only thing left to do is to convince Mr. Fedora to approve this ;)

Cheers,
Mario
-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Mario Torre]

On Tue, Oct 5, 2021 at 10:20 PM Peter Boy  wrote:
>
>
>
> > Am 04.10.2021 um 21:08 schrieb Fabio Valentini :
> >
> >
> > But then you're back to *exactly how Fedora packages for Java projects
> > already work* - only with the added complication that distributing
> > those build artifacts as plain JARs instead of RPMs now makes them
> > impossible to consume as dependencies from other RPM builds.
>
> I think, the key is "via a Fedora managed repository“, something like a 
> fedora.maven.central. That could make the process easier.
>
> Somewhere I had read on "federated repository“ as a specific narrow 
> defined cooperation with distributions or projects with similar principles as 
> Fedora.

Yes, also distributing jars via maven is a lot simpler than having to
package them (even if just wrapped) as RPM, so there's a lot of saving
just by that.

Those jars could be rebuilt from source, including their transitive
deps, or just a mirror of maven central if we trust the upstream (and
in many cases we do, i.e. for things coming from Eclipse.org or
Apache).

The infrastructure, I can't hardly think of this as an additional
burden, we have already hosted and built every single distribution
since the beginning of time, including those same jars in an RPM form.

Cheers,
Mario
-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

> Am 06.10.2021 um 14:37 schrieb Mikolaj Izdebski :
> 
> On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller  
> wrote:
>> 
>> On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>>> I'm not sure what's the best solution, but I guess the number one
>>> reason to have packages within the Fedora distribution is for a matter
>>> of trust, if this is the case I would argue that a curated list of
>>> maven packages served via a Fedora managed repository would be a
>>> better investment.
>> 
>> I'd love to see someone interested in this pursue this idea! I know we
>> talked about it as long ago as... Flock Prague... and probably before.
> 
> That's a very old idea that has been partially implemented years ago,

That (and the following description) sounds great at first. 

> but never approved for use in Fedora.

Was the process not initiated or were there serious concerns? 

What would you recommend to do with it, discard, pursue, evaluate? 


Thanks
Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

> Am 08.10.2021 um 02:06 schrieb Kevin Kofler via devel 
> :
> 
> Michal Srb wrote:
>> Unlike RPM repositories, Maven repositories can easily hold multiple
>> versions of libraries. ...
> 
> And that is actually a problem rather than a solution. Maven artifacts are 
> basically write once only. Everything depends on a hardcoded version which, 
> once uploaded, is normally never touched again. This means that security 
> bugs and other bugs never get fixed ...

A valid point, but only in case the app that consumes the maven artefact in 
unmaintained. 

The goal of the "curated list“ is to make building an "app-rpm" less burdensome 
and provide for more apps as rpm this way. And the updated „app-rpm“ would use 
an updated version of that jar. And that app would be part of the usual rpm 
update procedure.  



>> Fedora could ship just Java applications that would bundle JARs (whatever
>> version they need) from the Fedora Maven repository. I don't see this as a
>> problem, as long as it would be possible to track what JARs are bundled in
>> what application.
> 
> So you propose to bundle a whole bunch of JARs, some of which have been 
> built many Fedora releases ago and might not even be buildable in any 
> currently supported Fedora anymore?

No! See above.


> I think this would be not only a huge 
> waste of space

given the current size of hard drive space, this really isn't a problem. You 
won't be able to install a meaningful collection of apps whose cumulative 
footprint of jars installed in parallel leaves any noticeable trace on a x tb 
disk. But you gain a lot in security if as many of these apps as possible are 
managed as rpm.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Kevin Kofler via devel]

Michal Srb wrote:
> Unlike RPM repositories, Maven repositories can easily hold multiple
> versions of libraries. Once a JAR is built, the resulting bytecode will
> work with current and future JVMs. There is no need to mass-rebuild JARs
> every 6 months. And there is certainly no need to try to run every single
> Java application with a single "system-wide" version of a library.

And that is actually a problem rather than a solution. Maven artifacts are 
basically write once only. Everything depends on a hardcoded version which, 
once uploaded, is normally never touched again. This means that security 
bugs and other bugs never get fixed (unless the application bumps the 
dependency version, which can take months or years or even just never 
happen). That is exactly what the RPM system is designed to avoid.

> Fedora could ship just Java applications that would bundle JARs (whatever
> version they need) from the Fedora Maven repository. I don't see this as a
> problem, as long as it would be possible to track what JARs are bundled in
> what application.

So you propose to bundle a whole bunch of JARs, some of which have been 
built many Fedora releases ago and might not even be buildable in any 
currently supported Fedora anymore? I think this would be not only a huge 
waste of space, but also a gigantic security nightmare.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Matthew Miller]

On Wed, Oct 06, 2021 at 07:08:46AM +0200, Michal Srb wrote:
> @Matthew Miller  Are you still trying to save Fedora
> from packaging the ocean? :)

Oh, you remember. Yes. :)

Let's do what we do really well, really well, and not do things where we're
fighting against 99.% of all actual use both in dev and prod.



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Mikolaj Izdebski]

On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller  wrote:
>
> On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> > I'm not sure what's the best solution, but I guess the number one
> > reason to have packages within the Fedora distribution is for a matter
> > of trust, if this is the case I would argue that a curated list of
> > maven packages served via a Fedora managed repository would be a
> > better investment.
>
> I'd love to see someone interested in this pursue this idea! I know we
> talked about it as long ago as... Flock Prague... and probably before.

That's a very old idea that has been partially implemented years ago,
but never approved for use in Fedora. Maven artifacts can be built in
Koji (there is an existing "koji maven-build" command). Once built
they appear in a "curated" Maven repository hosted on Koji, that can
be synced to mirrors, from where users can consume it. Consumers of
this Maven repository don't need to be running Fedora, not even Linux.

Curated Maven repository contains additional metadata, eg. CVEs
affecting given artifact version, whether upstream is active, whether
given artifact is available in Fedora and in which releases, etc. For
each Fedora Linux release there is an auto-generated BOM (bill of
materials POM) listing artifacts available in the release.

Binaries from this trusted/curated Maven repository can also be
wrapped into RPMs (using "koji wrapper-rpm" command) and put into
distribution repos and composes. Other packages can depend on such
RPMs. This is a hybrid packaging model, where some Java RPM packages
can be built in the traditional way (where code is compiled during
rpmbuild) and some are built elsewhere, and only wrapped in RPMs.

--
Mikolaj Izdebski

>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Mat Booth]

On Wed, 6 Oct 2021 at 11:02, Peter Boy  wrote:
>
>
>
> Am 06.10.2021 um 07:08 schrieb Michal Srb :
>
> Hi folks,
>
> @Matthew Miller Are you still trying to save Fedora from packaging the ocean? 
> :)
>
> On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini  wrote:
> On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller  
> wrote:
>
>
> On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>
> I'm not sure what's the best solution, but I guess the number one
> reason to have packages within the Fedora distribution is for a matter
> of trust, if this is the case I would argue that a curated list of
> maven packages served via a Fedora managed repository would be a
> better investment.
>
>
> I'd love to see someone interested in this pursue this idea! I know we
> talked about it as long ago as... Flock Prague... and probably before.
>
>
> …..
>
> Fedora could ship just Java applications that would bundle JARs (whatever 
> version they need) from the Fedora Maven repository. I don't see this as a 
> problem, as long as it would be possible to track what JARs are bundled in 
> what application.
>
> Fedora maintainers could then focus on maintaining applications, and not 
> maintaining a ton of individual libraries that nobody really cares about that 
> much.
>
>
> I've roughly thought this through with our Java Web CMS project (we don't 
> currently create Fedora rpm). I think with this idea the effort would be 
> noticeably reduced. A number of intermediate steps could be omitted.
>
> My main question: how can we get this going?
>
> Normally we would first need a concise description and then (try to) discuss 
> it on java-devel.
>
> Or is this a case of "do-ocracy“?
>

Yes ;-) I look forward to reading your proposal on java-devel.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

> Am 06.10.2021 um 07:08 schrieb Michal Srb  >:
> 
> Hi folks,
> 
> @Matthew Miller Are you still trying to save Fedora from packaging the ocean? 
> :)
> 
> On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini  wrote:
> On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller  
> wrote:
>> 
>> On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>>> I'm not sure what's the best solution, but I guess the number one
>>> reason to have packages within the Fedora distribution is for a matter
>>> of trust, if this is the case I would argue that a curated list of
>>> maven packages served via a Fedora managed repository would be a
>>> better investment.
>> 
>> I'd love to see someone interested in this pursue this idea! I know we
>> talked about it as long ago as... Flock Prague... and probably before.
> 
> …..
> 
> Fedora could ship just Java applications that would bundle JARs (whatever 
> version they need) from the Fedora Maven repository. I don't see this as a 
> problem, as long as it would be possible to track what JARs are bundled in 
> what application.
> 
> Fedora maintainers could then focus on maintaining applications, and not 
> maintaining a ton of individual libraries that nobody really cares about that 
> much.

I've roughly thought this through with our Java Web CMS project (we don't 
currently create Fedora rpm). I think with this idea the effort would be 
noticeably reduced. A number of intermediate steps could be omitted. 

My main question: how can we get this going? 

Normally we would first need a concise description and then (try to) discuss it 
on java-devel. 

Or is this a case of "do-ocracy“?

And who is able / willing to (co-)work?___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Vít Ondruch]

Dne 06. 10. 21 v 7:08 Michal Srb napsal(a):

Hi folks,

@Matthew Miller  Are you still trying to 
save Fedora from packaging the ocean? :)


On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini  
wrote:


On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller
 wrote:
>
> On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> > I'm not sure what's the best solution, but I guess the number one
> > reason to have packages within the Fedora distribution is for
a matter
> > of trust, if this is the case I would argue that a curated list of
> > maven packages served via a Fedora managed repository would be a
> > better investment.
>
> I'd love to see someone interested in this pursue this idea! I
know we
> talked about it as long ago as... Flock Prague... and probably
before.

This approach will buy you *literally nothing* compared to how things
already work, assuming you don't advocate just redistributing binary
artifacts / JARs from Maven Central.

Given that assumption, JARs would still need to be built 1) from
source, in a 2) trusted environment, 3) against trusted dependencies,
as I don't think any other approach should be acceptable for content
distributed by the Fedora Project.


But then you're back to *exactly how Fedora packages for Java projects
already work* - only with the added complication that distributing
those build artifacts as plain JARs instead of RPMs now makes them
impossible to consume as dependencies from other RPM builds.


I think it would actually make a huge difference.

Unlike RPM repositories, Maven repositories can easily hold multiple 
versions of libraries.



RPM repositories can hold multiple version of libraries as well. This is 
self inflicted limitation of Fedora, because once you have multiple 
versions of libraries, you should also fix (security) bugs in those 
versions. And this is where it starts to be complicated.



Vít


Once a JAR is built, the resulting bytecode will work with current and 
future JVMs. There is no need to mass-rebuild JARs every 6 months. And 
there is certainly no need to try to run every single Java application 
with a single "system-wide" version of a library.


Fedora could ship just Java applications that would bundle JARs 
(whatever version they need) from the Fedora Maven repository. I don't 
see this as a problem, as long as it would be possible to track what 
JARs are bundled in what application.


Fedora maintainers could then focus on maintaining applications, and 
not maintaining a ton of individual libraries that nobody really cares 
about that much.


Thanks,
Michal


Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure


___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report 
it:https://pagure.io/fedora-infrastructure___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Michal Srb]

Hi folks,

@Matthew Miller  Are you still trying to save Fedora
from packaging the ocean? :)

On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini  wrote:

> On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller 
> wrote:
> >
> > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> > > I'm not sure what's the best solution, but I guess the number one
> > > reason to have packages within the Fedora distribution is for a matter
> > > of trust, if this is the case I would argue that a curated list of
> > > maven packages served via a Fedora managed repository would be a
> > > better investment.
> >
> > I'd love to see someone interested in this pursue this idea! I know we
> > talked about it as long ago as... Flock Prague... and probably before.
>
> This approach will buy you *literally nothing* compared to how things
> already work, assuming you don't advocate just redistributing binary
> artifacts / JARs from Maven Central.
>
> Given that assumption, JARs would still need to be built 1) from
> source, in a 2) trusted environment, 3) against trusted dependencies,
> as I don't think any other approach should be acceptable for content
> distributed by the Fedora Project.
>

> But then you're back to *exactly how Fedora packages for Java projects
> already work* - only with the added complication that distributing
> those build artifacts as plain JARs instead of RPMs now makes them
> impossible to consume as dependencies from other RPM builds.
>

I think it would actually make a huge difference.

Unlike RPM repositories, Maven repositories can easily hold multiple
versions of libraries. Once a JAR is built, the resulting bytecode will
work with current and future JVMs. There is no need to mass-rebuild JARs
every 6 months. And there is certainly no need to try to run every single
Java application with a single "system-wide" version of a library.

Fedora could ship just Java applications that would bundle JARs (whatever
version they need) from the Fedora Maven repository. I don't see this as a
problem, as long as it would be possible to track what JARs are bundled in
what application.

Fedora maintainers could then focus on maintaining applications, and not
maintaining a ton of individual libraries that nobody really cares about
that much.

Thanks,
Michal


>
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Colin Walters]

On Mon, Oct 4, 2021, at 3:08 PM, Fabio Valentini wrote:

> But then you're back to *exactly how Fedora packages for Java projects
> already work* - only with the added complication that distributing
> those build artifacts as plain JARs instead of RPMs now makes them
> impossible to consume as dependencies from other RPM builds.

One needs to be a bit careful using the term "impossible" in software.
Some things, such as the halting problem have actually been proven impossible.
But this is not impossible =)  I use non-RPM things as part of building RPMs 
all the time.
So do many other systems.

I think you instead mean e.g.: "would require our use of RPM to not be fully 
self-hosting" or "would require some tooling to e.g. automatically generate 
RPMs from external binaries" etc.
That's more of a policy question, far from impossible.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

> Am 04.10.2021 um 21:08 schrieb Fabio Valentini :
> 
> 
> But then you're back to *exactly how Fedora packages for Java projects
> already work* - only with the added complication that distributing
> those build artifacts as plain JARs instead of RPMs now makes them
> impossible to consume as dependencies from other RPM builds.

I think, the key is "via a Fedora managed repository“, something like a 
fedora.maven.central. That could make the process easier. 

Somewhere I had read on "federated repository“ as a specific narrow defined 
cooperation with distributions or projects with similar principles as Fedora.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Fabio Valentini]

On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller  wrote:
>
> On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> > I'm not sure what's the best solution, but I guess the number one
> > reason to have packages within the Fedora distribution is for a matter
> > of trust, if this is the case I would argue that a curated list of
> > maven packages served via a Fedora managed repository would be a
> > better investment.
>
> I'd love to see someone interested in this pursue this idea! I know we
> talked about it as long ago as... Flock Prague... and probably before.

This approach will buy you *literally nothing* compared to how things
already work, assuming you don't advocate just redistributing binary
artifacts / JARs from Maven Central.

Given that assumption, JARs would still need to be built 1) from
source, in a 2) trusted environment, 3) against trusted dependencies,
as I don't think any other approach should be acceptable for content
distributed by the Fedora Project.

But then you're back to *exactly how Fedora packages for Java projects
already work* - only with the added complication that distributing
those build artifacts as plain JARs instead of RPMs now makes them
impossible to consume as dependencies from other RPM builds.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Matthew Miller]

On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> I'm not sure what's the best solution, but I guess the number one
> reason to have packages within the Fedora distribution is for a matter
> of trust, if this is the case I would argue that a curated list of
> maven packages served via a Fedora managed repository would be a
> better investment.

I'd love to see someone interested in this pursue this idea! I know we
talked about it as long ago as... Flock Prague... and probably before.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Richard W.M. Jones]

On Tue, Sep 28, 2021 at 02:40:18PM -0400, Demi Marie Obenour wrote:
> That said, I am also unsure if anyone is using those bindings.  Why were they
> added originally?

I think probably for oVirt, but oVirt now only uses the virt-* tools
(ie. command line).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Demi Marie Obenour]

On 9/28/21 8:41 AM, Stephen John Smoogen wrote:
> On Tue, 28 Sept 2021 at 08:20, Richard W.M. Jones  wrote:
>>
>> On Tue, Sep 28, 2021 at 02:06:58PM +0200, Kevin Kofler via devel wrote:
>>> Richard W.M. Jones wrote:
 OCaml library code can in principle be dynamically linked, eg:

 $ rpm -ql ocaml-extlib | grep cmxs
 /usr/lib64/ocaml/extlib/extLib.cmxs
 $ file /usr/lib64/ocaml/extlib/extLib.cmxs
 /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64,
 version 1 (SYSV), dynamically linked,
 BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info,
 not stripped

 but upstream doesn't make it possible to ship OCaml binaries this way,
 (they would still require rebuilding on every library update) and so
 we only ship the DLLs not fully dynamically linked OCaml binaries
 (except for the C code).
>>>
>>> Ah?
>>>
>>> So what sits in the main packages of libraries (e.g., in ocaml-facile as
>>> opposed to ocaml-facile-devel) then? Don't only shared libraries belong in
>>> the main package?
>>
>> The original split of ocaml-FOO / ocaml-FOO-devel doesn't make a lot
>> of sense these days.  Ideally we'd put them all in one package.
>>
>>> So I take back my comment that the OCaml stack is properly packaged. ;-)
>>> That sounds like almost as much of a mess as Go and Rust then.
>>
>> I'd hardly say OCaml packging is a mess.  It's much closer to the
>> spirit of C packaging than those others.  If you have *specific,
>> actionable* objections I will listen to them.
>>
>>
> 
> I think Kevin's comment is meant more towards the way the language
> packages itself versus the rpm packaging of the language. Going from
> Kevin's comments on languages over the years, a 'good' language should
> not require such sort of rebuilding.

I believe (though I could be wrong) that *most* natively-compiled languages 
require
cascading rebuilds.  The only exceptions I am aware of are C, C++ (excluding
templates!), and Swift.  Haskell, OCaml, Rust, and Go all require cascading 
rebuilds;
I am not sure about Nim or Zig.

Providing a stable ABI requires major tradeoffs in a language implementation.
It prevents cross-module inlining and other optimizations, and is incompatible
with monomorphized generics (unless one takes the C++ route).  Furthermore,
ABI stability requires committing to the runtime representation of data types
and not changing it, even if these decisions prove to later be suboptimal.
Rust in particular has changed the way it represents structs by default to
improve packing of members.

Furthermore, in at least Rust and Haskell, `1 + 2` is actually a call to a
standard library routine.  If this is not inlined, performance will be abysmal.
Rust generics are basically C++ templates, in that code is generated for them
when they are instantiated, so ABI stability would require a commitment to
never changing the representation of `Vec` or `HashMap`.  That is not a
commitment that the Rust project has made yet.

Overall, I consider automated cascading rebuilds a far more feasible and 
realistic
path forward.  Arch already does cascading rebuilds of its Haskell packages,
for example, which shows that it can be done.

Sincerely,

Demi Marie Obenour (she/her/hers)


OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Kevin Kofler via devel]

Stephen John Smoogen wrote:
> I think Kevin's comment is meant more towards the way the language
> packages itself versus the rpm packaging of the language. Going from
> Kevin's comments on languages over the years, a 'good' language should
> not require such sort of rebuilding.

The OCaml language is to blame for a lot of issues. Still, there are also
issues I see in the RPM packaging (now that I know what those .cm* files
actually are), where it does not conform to best practices and/or to the
general packaging guidelines (which can be overridden by language-specific
ones, sure, but those exceptions are what I have a problem with):

* The main packages of libraries contain files that are only used for static
  linking (.cma files, i.e., "metadata for bytecode static linking" as
  Richard explained). Those main packages should actually contain only
  shared libraries and data files needed at runtime.

* No shared libraries (.so/.cmxs) are shipped for most libraries.

* Executables are not linked against those that are shipped.

That said, I agree that the Go and Rust packaging is worse.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 28, 2021 at 04:33:39PM +0200, Fabio Valentini wrote:
> But as you guessed, there's no such support for gradle, sbt, bazel, or
> whatever new build system Google has been cooking up recently. Nor is
> there support for Groovy (no longer available in Fedora, as it
> depended on gradle), Kotlin (was never packaged), or Scala (no longer
> available) - all of which are now dependencies of gradle. Oh, fun.
> While gradle *used* to be available as an option for Fedora Java
> packages, recent versions of gradle are a barely-open-source mess that
> apparently only upstream itself manages to build from source, and
> everybody else is supposed to "just build with internet access and use
> our binary JAR, it's fine (TM)".
> 
> Another problem is projects that use ant or maven, but do horrendous,
> nonstandard things *within* those build systems, either with custom
> ant targets, or weird maven plugins.

I think this difference in philosophical approach is the crux of
the problem. Elsewhere in the thread people mentioned many smaller and
larger *technical* issues, and we probably would have overcome those
with enough motivation. But packaging of Java is so horrible because
upstreams are completely uninterested in people consuming their
software by compiling it from sources and reusing within other projects.

Hence: crazy build systems that only work on some developer's mac on
alternate weekdays, self-dependent build systems, downloading of
random stuff from the network, constant api breaks and renames of
things, and I'd say generally low quality of output.

> using maven is actually not terrible for making RPM packages,

Yeah, we have maven under control. I remember how maven started being
popular, and was a huge improvement over the older java build systems.
But looking back, it was never so great: for example, it was always
intended only a always-online build system; the local builds we do with Xmvn
are one giant hack. Version dependencies are pinned exactly, there was
never any idea of version ranges or semantic versioning. And doing
anything slightly non-standard with Maven was always extremely painful;
things that would be one or two lines in Make or other build systems
could turn into an extremely fragile 150 lines of XML. And even though
Maven could be the best this ecosystem produced, it already started
moving in the directions that ultimately made the later systems unusable.

Ultimately, I think the Java packages in Fedora are dying because
their ecosystem has philosophies which go in a different direction
than our subset of the software world: building a pipeline directly
from version-controlled code to any build artifacts, reproducible
builds, limited trust, testing and scanning at all levels, automatization,
simplification of build systems and packaging.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Demi Marie Obenour]

On 9/27/21 8:31 AM, Richard W.M. Jones wrote:
> On Mon, Sep 27, 2021 at 12:15:32PM +0100, Mat Booth wrote:
>> On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones  wrote:
>>>
>>> A question about this which is semi-related to your email.
>>>
>>> For some C library packages we have Java bindings, eg:
>>> https://github.com/libguestfs/libguestfs/tree/master/java
>>>
>>> These have been disabled in Fedora for ~2 years, but when they were
>>> around they had these BuildRequires:
>>>
>>>   BuildRequires: java-1.8.0-openjdk
>>>   BuildRequires: java-1.8.0-openjdk-devel
>>>   BuildRequires: jpackage-utils
>>>
>>> I believe the only requirements are javac, javah, javadoc (optional)
>>> and a JVM to run the tests on.
>>>
>>> Is it possible to keep this going, or would that require a lot of
>>> work?  I notice that javah no longer seems to exist.
>>>
>>> (Note I know almost nothing about how the modern JDK works)
>>>
>>> Rich.
>>
>> Hi, the functionality provided by javah has been folded into javac in
>> recent JDKs.
>>
>> These days you can make one call to "javac -h" instead of having to
>> call both "javac" and "javah"
>>
>> I ported quite a few packages this way when Fedora made the switch to
>> Java 11 by default. If you like I can probably take a look libguestfs
>> and send you a PR?
> 
> Sure thing, thanks.
> 
> However before you start you might also want to know that there are
> apparently some serious GC-related problems with how those bindings
> work:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1536762
> 
> so it might be more of a saga than just changing a few commands.
> 
> Rich.

As the person who reported that bug, I don’t think it is likely to be hit
normally.  Most of the problems are either poor performance (not using
direct ByteBuffers) or potential crashes in low memory conditions (which
most users will not run into).   I do not believe that any of these crashes
are exploitable.

That said, I am also unsure if anyone is using those bindings.  Why were they
added originally?

Sincerely,

Demi Marie Obenour (she/her/hers)


OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Stephen John Smoogen]

On Tue, 28 Sept 2021 at 08:20, Richard W.M. Jones  wrote:
>
> On Tue, Sep 28, 2021 at 02:06:58PM +0200, Kevin Kofler via devel wrote:
> > Richard W.M. Jones wrote:
> > > OCaml library code can in principle be dynamically linked, eg:
> > >
> > > $ rpm -ql ocaml-extlib | grep cmxs
> > > /usr/lib64/ocaml/extlib/extLib.cmxs
> > > $ file /usr/lib64/ocaml/extlib/extLib.cmxs
> > > /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64,
> > > version 1 (SYSV), dynamically linked,
> > > BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info,
> > > not stripped
> > >
> > > but upstream doesn't make it possible to ship OCaml binaries this way,
> > > (they would still require rebuilding on every library update) and so
> > > we only ship the DLLs not fully dynamically linked OCaml binaries
> > > (except for the C code).
> >
> > Ah?
> >
> > So what sits in the main packages of libraries (e.g., in ocaml-facile as
> > opposed to ocaml-facile-devel) then? Don't only shared libraries belong in
> > the main package?
>
> The original split of ocaml-FOO / ocaml-FOO-devel doesn't make a lot
> of sense these days.  Ideally we'd put them all in one package.
>
> > So I take back my comment that the OCaml stack is properly packaged. ;-)
> > That sounds like almost as much of a mess as Go and Rust then.
>
> I'd hardly say OCaml packging is a mess.  It's much closer to the
> spirit of C packaging than those others.  If you have *specific,
> actionable* objections I will listen to them.
>
>

I think Kevin's comment is meant more towards the way the language
packages itself versus the rpm packaging of the language. Going from
Kevin's comments on languages over the years, a 'good' language should
not require such sort of rebuilding.


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Richard W.M. Jones]

On Tue, Sep 28, 2021 at 02:00:58PM +0200, Kevin Kofler via devel wrote:
> Florian Weimer wrote:
> > Interesting.  Could you provide an example of such a dynamically linked
> > binary?
> 
> OCaml is interesting in that it does not use standard ELF .so files, but its 
> own dynamic linking mechanism (those .cma files).

.cma files are metadata for bytecode static linking.

.cmxa files are metadata for native code static linking.

.cmxs files are renamed *.so files and can be used for fully dynamic
linking of OCaml native code.

Other issues make it difficult to ship dynamically linked binaries of
pure OCaml code, so in practice *.cmxs are only used for dlopen-style
dynamic loading.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Richard W.M. Jones]

On Tue, Sep 28, 2021 at 02:06:58PM +0200, Kevin Kofler via devel wrote:
> Richard W.M. Jones wrote:
> > OCaml library code can in principle be dynamically linked, eg:
> > 
> > $ rpm -ql ocaml-extlib | grep cmxs
> > /usr/lib64/ocaml/extlib/extLib.cmxs
> > $ file /usr/lib64/ocaml/extlib/extLib.cmxs
> > /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64,
> > version 1 (SYSV), dynamically linked,
> > BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info,
> > not stripped
> > 
> > but upstream doesn't make it possible to ship OCaml binaries this way,
> > (they would still require rebuilding on every library update) and so
> > we only ship the DLLs not fully dynamically linked OCaml binaries
> > (except for the C code).
> 
> Ah?
> 
> So what sits in the main packages of libraries (e.g., in ocaml-facile as 
> opposed to ocaml-facile-devel) then? Don't only shared libraries belong in 
> the main package?

The original split of ocaml-FOO / ocaml-FOO-devel doesn't make a lot
of sense these days.  Ideally we'd put them all in one package.

> So I take back my comment that the OCaml stack is properly packaged. ;-) 
> That sounds like almost as much of a mess as Go and Rust then.

I'd hardly say OCaml packging is a mess.  It's much closer to the
spirit of C packaging than those others.  If you have *specific,
actionable* objections I will listen to them.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Kevin Kofler via devel]

Richard W.M. Jones wrote:
> OCaml library code can in principle be dynamically linked, eg:
> 
> $ rpm -ql ocaml-extlib | grep cmxs
> /usr/lib64/ocaml/extlib/extLib.cmxs
> $ file /usr/lib64/ocaml/extlib/extLib.cmxs
> /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64,
> version 1 (SYSV), dynamically linked,
> BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info,
> not stripped
> 
> but upstream doesn't make it possible to ship OCaml binaries this way,
> (they would still require rebuilding on every library update) and so
> we only ship the DLLs not fully dynamically linked OCaml binaries
> (except for the C code).

Ah?

So what sits in the main packages of libraries (e.g., in ocaml-facile as 
opposed to ocaml-facile-devel) then? Don't only shared libraries belong in 
the main package?

So I take back my comment that the OCaml stack is properly packaged. ;-) 
That sounds like almost as much of a mess as Go and Rust then.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Richard W.M. Jones]

On Tue, Sep 28, 2021 at 01:42:44PM +0200, Florian Weimer wrote:
> * Kevin Kofler via devel:
> 
> > Florian Weimer wrote:
> >
> >> * Kevin Kofler via devel:
> >> 
> >>> (And for the record, I also think that Go and Rust should not work
> >>> that way either! It is possible to build shared libraries of Go code,
> >>> at least one Go toolchain supports it.)
> >> 
> >> There is no stable Go ABI.  Even minor updates change ABI because type
> >> sizes and struct offsets change and are inlined across shared object
> >> boundaries.  You have to rebuild all reverse dependencies to avoid ABI
> >> mismatches.  Go's compatibility guarantees only apply at the source
> >> level and do not preclude the addition of new struct fields, for
> >> example.
> >
> > The same goes for OCaml and yet we still manage to ship almost
> > everything in OCaml dynamically linked.

We rebuild everything on every OCaml release, and ...

> Interesting.  Could you provide an example of such a dynamically linked
> binary?

C libraries of OCaml binaries are dynamically linked, eg:
$ ldd /usr/bin/virt-v2v
  linux-vdso.so.1 (0x7ffce93ab000)
  libvirt.so.0 => /lib64/libvirt.so.0 (0x7f5a759c7000)
  libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x7f5a7593)
  libguestfs.so.0 => /lib64/libguestfs.so.0 (0x7f5a757cc000)
  libxml2.so.2 => /lib64/libxml2.so.2 (0x7f5a75643000)
[etc]

OCaml library code can in principle be dynamically linked, eg:

$ rpm -ql ocaml-extlib | grep cmxs
/usr/lib64/ocaml/extlib/extLib.cmxs
$ file /usr/lib64/ocaml/extlib/extLib.cmxs
/usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64, 
version 1 (SYSV), dynamically linked, 
BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info, not 
stripped

but upstream doesn't make it possible to ship OCaml binaries this way,
(they would still require rebuilding on every library update) and so
we only ship the DLLs not fully dynamically linked OCaml binaries
(except for the C code).

This is kind of OK because OCaml code doesn't suffer the slings and
arrows of outrageous pointers.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Kevin Kofler via devel]

Richard W.M. Jones wrote:
> The bug above is a bit worrying though.  I don't think anyone ever
> tried to address those issues.  I don't know enough to say if they're
> real or nice to haves, but they seem serious.

I have never seen any handwritten JNI code doing any of the things the bug 
wants you to do. Maybe some binding generators do, but handwritten JNI code 
practically never bothers.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Mat Booth]

On Mon, 27 Sept 2021 at 17:31, Richard W.M. Jones  wrote:
>
> On Mon, Sep 27, 2021 at 04:39:03PM +0100, Mat Booth wrote:
> > On Mon, 27 Sept 2021 at 13:31, Richard W.M. Jones  wrote:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1536762
> > >
> > > so it might be more of a saga than just changing a few commands.
> > >
> > > Rich.
> >
> > Hi Rich,
> >
> > TBH it looks like your Java bindings should build fine on Java 11
> > since this change:
> >
> > https://github.com/libguestfs/libguestfs/commit/662dc5d0bf65e72dab11aa58d4bc373b5a3b7e75
>
> You're right - I checked just now using:
>
> java-11-openjdk-headless-11.0.11.0.9-4.fc35.x86_64
> javapackages-filesystem-6.0.0-1.fc35.noarch
> javapackages-tools-6.0.0-1.fc35.noarch
>
> Tests pass too.
>
> The bug above is a bit worrying though.  I don't think anyone ever
> tried to address those issues.  I don't know enough to say if they're
> real or nice to haves, but they seem serious.
>

I think the only super serious one is the local reference leaks --
this can be fatal to an application. The other concerns seem "just"
perf-related.

> BTW another project that would be fun for Java bindings (none exist
> presently) is nbdkit https://gitlab.com/nbdkit/nbdkit
>
> Rich.




-- 
Mat Booth
http://fedoraproject.org/get-fedora
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Richard W.M. Jones]

On Mon, Sep 27, 2021 at 04:39:03PM +0100, Mat Booth wrote:
> On Mon, 27 Sept 2021 at 13:31, Richard W.M. Jones  wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1536762
> >
> > so it might be more of a saga than just changing a few commands.
> >
> > Rich.
> 
> Hi Rich,
> 
> TBH it looks like your Java bindings should build fine on Java 11
> since this change:
> 
> https://github.com/libguestfs/libguestfs/commit/662dc5d0bf65e72dab11aa58d4bc373b5a3b7e75

You're right - I checked just now using:

java-11-openjdk-headless-11.0.11.0.9-4.fc35.x86_64
javapackages-filesystem-6.0.0-1.fc35.noarch
javapackages-tools-6.0.0-1.fc35.noarch

Tests pass too.

The bug above is a bit worrying though.  I don't think anyone ever
tried to address those issues.  I don't know enough to say if they're
real or nice to haves, but they seem serious.

BTW another project that would be fun for Java bindings (none exist
presently) is nbdkit https://gitlab.com/nbdkit/nbdkit

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Florian Weimer]

* Fabio Valentini:

> On Mon, Sep 27, 2021 at 1:07 PM Richard W.M. Jones  wrote:
>>
>> A question about this which is semi-related to your email.
>>
>> For some C library packages we have Java bindings, eg:
>> https://github.com/libguestfs/libguestfs/tree/master/java
>>
>> These have been disabled in Fedora for ~2 years, but when they were
>> around they had these BuildRequires:
>>
>>   BuildRequires: java-1.8.0-openjdk
>>   BuildRequires: java-1.8.0-openjdk-devel
>>   BuildRequires: jpackage-utils
>>
>> I believe the only requirements are javac, javah, javadoc (optional)
>> and a JVM to run the tests on.
>>
>> Is it possible to keep this going, or would that require a lot of
>> work?  I notice that javah no longer seems to exist.
>>
>> (Note I know almost nothing about how the modern JDK works)
>
> I think you'd probably want to do
>
> 1) switch to java-11-openjdk (it's the default on all currently
> supported Fedora branches)

This means that the built JAR files will be unusable with OpenJDK 8,
though.  Maybe there are still some users left?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Mat Booth]

On Mon, 27 Sept 2021 at 13:31, Richard W.M. Jones  wrote:
>
> On Mon, Sep 27, 2021 at 12:15:32PM +0100, Mat Booth wrote:
> > On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones  wrote:
> > >
> > > A question about this which is semi-related to your email.
> > >
> > > For some C library packages we have Java bindings, eg:
> > > https://github.com/libguestfs/libguestfs/tree/master/java
> > >
> > > These have been disabled in Fedora for ~2 years, but when they were
> > > around they had these BuildRequires:
> > >
> > >   BuildRequires: java-1.8.0-openjdk
> > >   BuildRequires: java-1.8.0-openjdk-devel
> > >   BuildRequires: jpackage-utils
> > >
> > > I believe the only requirements are javac, javah, javadoc (optional)
> > > and a JVM to run the tests on.
> > >
> > > Is it possible to keep this going, or would that require a lot of
> > > work?  I notice that javah no longer seems to exist.
> > >
> > > (Note I know almost nothing about how the modern JDK works)
> > >
> > > Rich.
> >
> > Hi, the functionality provided by javah has been folded into javac in
> > recent JDKs.
> >
> > These days you can make one call to "javac -h" instead of having to
> > call both "javac" and "javah"
> >
> > I ported quite a few packages this way when Fedora made the switch to
> > Java 11 by default. If you like I can probably take a look libguestfs
> > and send you a PR?
>
> Sure thing, thanks.
>
> However before you start you might also want to know that there are
> apparently some serious GC-related problems with how those bindings
> work:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1536762
>
> so it might be more of a saga than just changing a few commands.
>
> Rich.

Hi Rich,

TBH it looks like your Java bindings should build fine on Java 11
since this change:

https://github.com/libguestfs/libguestfs/commit/662dc5d0bf65e72dab11aa58d4bc373b5a3b7e75

>
> >
> > >
> > > --
> > > Richard Jones, Virtualization Group, Red Hat 
> > > http://people.redhat.com/~rjones
> > > Read my programming and virtualization blog: http://rwmj.wordpress.com
> > > virt-p2v converts physical machines to virtual machines.  Boot with a
> > > live CD or over the network (PXE) and turn machines into KVM guests.
> > > http://libguestfs.org/virt-v2v
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> > > Do not reply to spam on the list, report it: 
> > > https://pagure.io/fedora-infrastructure
> >
> >
> >
> > --
> > Mat Booth
> > http://fedoraproject.org/get-fedora
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Mat Booth
http://fedoraproject.org/get-fedora
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Richard W.M. Jones]

On Mon, Sep 27, 2021 at 12:15:32PM +0100, Mat Booth wrote:
> On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones  wrote:
> >
> > A question about this which is semi-related to your email.
> >
> > For some C library packages we have Java bindings, eg:
> > https://github.com/libguestfs/libguestfs/tree/master/java
> >
> > These have been disabled in Fedora for ~2 years, but when they were
> > around they had these BuildRequires:
> >
> >   BuildRequires: java-1.8.0-openjdk
> >   BuildRequires: java-1.8.0-openjdk-devel
> >   BuildRequires: jpackage-utils
> >
> > I believe the only requirements are javac, javah, javadoc (optional)
> > and a JVM to run the tests on.
> >
> > Is it possible to keep this going, or would that require a lot of
> > work?  I notice that javah no longer seems to exist.
> >
> > (Note I know almost nothing about how the modern JDK works)
> >
> > Rich.
> 
> Hi, the functionality provided by javah has been folded into javac in
> recent JDKs.
> 
> These days you can make one call to "javac -h" instead of having to
> call both "javac" and "javah"
> 
> I ported quite a few packages this way when Fedora made the switch to
> Java 11 by default. If you like I can probably take a look libguestfs
> and send you a PR?

Sure thing, thanks.

However before you start you might also want to know that there are
apparently some serious GC-related problems with how those bindings
work:

https://bugzilla.redhat.com/show_bug.cgi?id=1536762

so it might be more of a saga than just changing a few commands.

Rich.

> 
> >
> > --
> > Richard Jones, Virtualization Group, Red Hat 
> > http://people.redhat.com/~rjones
> > Read my programming and virtualization blog: http://rwmj.wordpress.com
> > virt-p2v converts physical machines to virtual machines.  Boot with a
> > live CD or over the network (PXE) and turn machines into KVM guests.
> > http://libguestfs.org/virt-v2v
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
> 
> 
> 
> -- 
> Mat Booth
> http://fedoraproject.org/get-fedora
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Artur Frenszek-Iwicki]

> I believe the only requirements are javac, javah, javadoc (optional)
> and a JVM to run the tests on. Is it possible to keep this going,
> or would that require a lot of work?
+1 on this. Having just the minimum, core packages
available in the repo would be good, especially since:
a) It would mean users can still run third-party Java apps.
b) I believe that, similar to Python, many end-users use maven
   (or whatever else) for installing dependencies, instead of the distro's repo,
   so the removal of other packages didn't affect them as much.

>  I notice that javah no longer seems to exist.
javah is now part of javac, invoked using the -h option.
If my research is right, the last edition with a separate javah was Java SE 9. 

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Mat Booth]

On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones  wrote:
>
> A question about this which is semi-related to your email.
>
> For some C library packages we have Java bindings, eg:
> https://github.com/libguestfs/libguestfs/tree/master/java
>
> These have been disabled in Fedora for ~2 years, but when they were
> around they had these BuildRequires:
>
>   BuildRequires: java-1.8.0-openjdk
>   BuildRequires: java-1.8.0-openjdk-devel
>   BuildRequires: jpackage-utils
>
> I believe the only requirements are javac, javah, javadoc (optional)
> and a JVM to run the tests on.
>
> Is it possible to keep this going, or would that require a lot of
> work?  I notice that javah no longer seems to exist.
>
> (Note I know almost nothing about how the modern JDK works)
>
> Rich.

Hi, the functionality provided by javah has been folded into javac in
recent JDKs.

These days you can make one call to "javac -h" instead of having to
call both "javac" and "javah"

I ported quite a few packages this way when Fedora made the switch to
Java 11 by default. If you like I can probably take a look libguestfs
and send you a PR?


>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Mat Booth
http://fedoraproject.org/get-fedora
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Fabio Valentini]

On Mon, Sep 27, 2021 at 1:07 PM Richard W.M. Jones  wrote:
>
> A question about this which is semi-related to your email.
>
> For some C library packages we have Java bindings, eg:
> https://github.com/libguestfs/libguestfs/tree/master/java
>
> These have been disabled in Fedora for ~2 years, but when they were
> around they had these BuildRequires:
>
>   BuildRequires: java-1.8.0-openjdk
>   BuildRequires: java-1.8.0-openjdk-devel
>   BuildRequires: jpackage-utils
>
> I believe the only requirements are javac, javah, javadoc (optional)
> and a JVM to run the tests on.
>
> Is it possible to keep this going, or would that require a lot of
> work?  I notice that javah no longer seems to exist.
>
> (Note I know almost nothing about how the modern JDK works)

I think you'd probably want to do

1) switch to java-11-openjdk (it's the default on all currently
supported Fedora branches)
2) replace jpackage-utils with javapackages-tools (depending on what
exactly you need from that package)
3) replace javah usage (removed with Java 11) with "java -h", or
similar (for an example how I handled this for another package, look
at https://src.fedoraproject.org/rpms/jblas/pull-request/2 )

And since those bindings do not look like they require any third-party
Java libraries, you should be fine.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Richard W.M. Jones]

A question about this which is semi-related to your email.

For some C library packages we have Java bindings, eg:
https://github.com/libguestfs/libguestfs/tree/master/java

These have been disabled in Fedora for ~2 years, but when they were
around they had these BuildRequires:

  BuildRequires: java-1.8.0-openjdk
  BuildRequires: java-1.8.0-openjdk-devel
  BuildRequires: jpackage-utils

I believe the only requirements are javac, javah, javadoc (optional)
and a JVM to run the tests on.

Is it possible to keep this going, or would that require a lot of
work?  I notice that javah no longer seems to exist.

(Note I know almost nothing about how the modern JDK works)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure