This past weekend I finally decided to jump off the cliff and attempt to re-launch the Java SIG. It seems there's some interest in keeping the Java stack maintained, it's just not focused or organized right now.
What we did when starting the Stewardship SIG seems to have worked out pretty well, so I'm trying to follow in those footsteps here:
- new proper FAS / pkgdb group: java-maint-sig ("java-sig" is occupied by an old, unused bot account) - new private mailing list: java-maint-sig (for RHBZ bugs - so, possibly, also CVEs - hence, private) - tracking project on pagure: https://pagure.io/java-maint-sig (for maintenance scripts, tracking tickets, awesome package dashboards, etc.)
There's already a public fedora mailing list for Java (java-devel), and and IRC channel (#fedora-java on freenode.net), which we will continue to use. Sadly, the existing wiki page for the Java SIG is hopelessly outdated, so I'm tempted to just scrap it and point readers to the pagure tracking project once it's set up beyond a basic README file.
Major upcoming projects for the "new" Java Package Maintainers group include:
- managing OpenJDK 11 / Java 11 transition for hundreds of Java packages in fedora 33 - starting to transition well-maintained Java packages from the Stewardship SIG back into Java SIG - possibly porting packages from gradle to maven to fix build issues and broken dependencies - transitioning from old java.net / JavaEE projects to the new ones now under the eclipse-ee4j umbrella
I know that - among others - the PKI team, Neuro SIG, and Eclipse maintainers depend on parts of the java stack for their packages, so I hope that we can work together with them on these things, as well.
So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list.
Let's make this happen. Fabio
On Mon, May 11, 2020 at 09:45:15PM +0200, Fabio Valentini wrote:
This past weekend I finally decided to jump off the cliff and attempt to re-launch the Java SIG. It seems there's some interest in keeping the Java stack maintained, it's just not focused or organized right now.
What we did when starting the Stewardship SIG seems to have worked out pretty well, so I'm trying to follow in those footsteps here:
- new proper FAS / pkgdb group: java-maint-sig ("java-sig" is occupied
by an old, unused bot account)
- new private mailing list: java-maint-sig (for RHBZ bugs - so,
possibly, also CVEs - hence, private)
- tracking project on pagure: https://pagure.io/java-maint-sig (for
maintenance scripts, tracking tickets, awesome package dashboards, etc.)
There's already a public fedora mailing list for Java (java-devel), and and IRC channel (#fedora-java on freenode.net), which we will continue to use. Sadly, the existing wiki page for the Java SIG is hopelessly outdated, so I'm tempted to just scrap it and point readers to the pagure tracking project once it's set up beyond a basic README file.
The wiki is not that bad actually. The links to guidelines and package lists are still useful. Even the packaging wishlist is mostly up to date since we didn't manage to touch most of the items ;) So maybe just nuke the outdated parts (member lists, "state of affairs" content), and keep the rest?
Major upcoming projects for the "new" Java Package Maintainers group include:
- managing OpenJDK 11 / Java 11 transition for hundreds of Java
packages in fedora 33
- starting to transition well-maintained Java packages from the
Stewardship SIG back into Java SIG
- possibly porting packages from gradle to maven to fix build issues
and broken dependencies
What about packaging gradle instead? (In the cases I looked into, porting from gradle to maven would be rewriting the build system from scratch. Assuming that we have tens and will have hundreds of packages with gradle, in the long term it seems better to support gradle, even in some partial form, than to rewrite build systems of hundreds of packages...).
- transitioning from old java.net / JavaEE projects to the new ones
now under the eclipse-ee4j umbrella
I know that - among others - the PKI team, Neuro SIG, and Eclipse maintainers depend on parts of the java stack for their packages, so I hope that we can work together with them on these things, as well.
So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list.
Yep, count me in.
Zbyszek
On Tue, May 12, 2020 at 9:33 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
The wiki is not that bad actually. The links to guidelines and package lists are still useful. Even the packaging wishlist is mostly up to date since we didn't manage to touch most of the items ;) So maybe just nuke the outdated parts (member lists, "state of affairs" content), and keep the rest?
Fair point. I'll make sure we keep the parts that are still up-to-date and/or interesting.
Major upcoming projects for the "new" Java Package Maintainers group include:
- managing OpenJDK 11 / Java 11 transition for hundreds of Java
packages in fedora 33
- starting to transition well-maintained Java packages from the
Stewardship SIG back into Java SIG
- possibly porting packages from gradle to maven to fix build issues
and broken dependencies
What about packaging gradle instead? (In the cases I looked into, porting from gradle to maven would be rewriting the build system from scratch. Assuming that we have tens and will have hundreds of packages with gradle, in the long term it seems better to support gradle, even in some partial form, than to rewrite build systems of hundreds of packages...).
Uh. We tried. Multiple times. It just won't work, like, ever again. I wrote a longer response here: https://discussion.fedoraproject.org/t/re-launching-the-java-sig/19688/3 So, you are welcome to try, but I bet you'll end up in the long line of packagers who failed to make it work.
- transitioning from old java.net / JavaEE projects to the new ones
now under the eclipse-ee4j umbrella
I know that - among others - the PKI team, Neuro SIG, and Eclipse maintainers depend on parts of the java stack for their packages, so I hope that we can work together with them on these things, as well.
So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list.
Yep, count me in.
Thanks. I'll get your memberships set up. :)
Fabio
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Tue, May 12, 2020 09:50:30 +0200, Fabio Valentini wrote:
Yep, count me in.
Thanks. I'll get your memberships set up. :)
Thank you for starting this off, and thank you for taking care of the Java packages in the meantime too. We really appreciate it. Please count me in also. :)
On Tue, May 12, 2020 at 10:15 AM Ankur Sinha sanjay.ankur@gmail.com wrote:
On Tue, May 12, 2020 09:50:30 +0200, Fabio Valentini wrote:
Yep, count me in.
Thanks. I'll get your memberships set up. :)
Thank you for starting this off, and thank you for taking care of the Java packages in the meantime too. We really appreciate it. Please count me in also. :)
Good morning!
I suspected that you would be interested as well :) You'll see your new group memberships shortly (possibly log out and back in with src.fedoraproject.org).
Fabio
-- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 5/12/20 2:50 AM, Fabio Valentini wrote:
What about packaging gradle instead? (In the cases I looked into, porting from gradle to maven would be rewriting the build system from scratch. Assuming that we have tens and will have hundreds of packages with gradle, in the long term it seems better to support gradle, even in some partial form, than to rewrite build systems of hundreds of packages...).
Uh. We tried. Multiple times. It just won't work, like, ever again. I wrote a longer response here: https://discussion.fedoraproject.org/t/re-launching-the-java-sig/19688/3 So, you are welcome to try, but I bet you'll end up in the long line of packagers who failed to make it work.
JUST PACKAGE THE PRE-COMPILED BUILDS!!!
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Am 12.05.20 um 10:35 schrieb Ty Young:
JUST PACKAGE THE PRE-COMPILED BUILDS!!!
Don't take me as rude but this is not possible.
This is documented in Fedora's packaging policies: https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packag...
Felix
On 5/12/20 3:48 AM, Felix Schwarz wrote:
Am 12.05.20 um 10:35 schrieb Ty Young:
JUST PACKAGE THE PRE-COMPILED BUILDS!!!
Don't take me as rude but this is not possible.
This is documented in Fedora's packaging policies: https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packag...
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed at the Fedora project as a whole as this is a Fedora issue.
FWIW, I can compile 6.4 just fine on Arch Linux using the Github source code via:
./gradlew allZip
Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Tue, May 12, 2020 at 12:34 PM Ty Young youngty1997@gmail.com wrote:
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed at the Fedora project as a whole as this is a Fedora issue.
I am aware that Arch is just packaging up the binary release artifacts published by the gradle project. But that's just never going to fly for fedora.
Arch is also the only distro I looked at that does this, everybody else (at least debian, ubuntu, OpenSUSE) is stuck at an ancient version, if gradle is available at all.
FWIW, I can compile 6.4 just fine on Arch Linux using the Github source code via:
./gradlew allZip
Now try doing that offline and without using the pre-built gradle/wrapper/gradle-wrapper.jar :) You'll be surprised how much junk the build process still needs to download.
Fabio
Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 5/12/20 5:39 AM, Fabio Valentini wrote:
On Tue, May 12, 2020 at 12:34 PM Ty Young youngty1997@gmail.com wrote:
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed at the Fedora project as a whole as this is a Fedora issue.
I am aware that Arch is just packaging up the binary release artifacts published by the gradle project. But that's just never going to fly for fedora.
Well, guess I now know why no one wants to package software for Fedora.
Arch is also the only distro I looked at that does this, everybody else (at least debian, ubuntu, OpenSUSE) is stuck at an ancient version, if gradle is available at all.
Honestly? Good. Those LInux distros, including Fedora, need taken down a few pegs. 3rd party software developers cannot nor will they always bend a knee to extreme constraints that are not otherwise required to build on any other platform or run properly on supported platforms. Linux distros need to learn to play nice with other people.
FWIW, I can compile 6.4 just fine on Arch Linux using the Github source code via:
./gradlew allZip
Now try doing that offline and without using the pre-built gradle/wrapper/gradle-wrapper.jar :) You'll be surprised how much junk the build process still needs to download.
Not a shocker. Gradle breaks backwards compatibility all the time, forcing projects to always use the wrapper. If using pre-builts isn't allowed Gradle will never be buildable, at least not consistently.
Fabio
Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Obviously count us in, Fabio :-)
----- Original Message -----
From: "Fabio Valentini" decathorpe@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Tuesday, May 12, 2020 6:39:04 AM Subject: Re: Re-Launching the Java SIG
On Tue, May 12, 2020 at 12:34 PM Ty Young youngty1997@gmail.com wrote:
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed at the Fedora project as a whole as this is a Fedora issue.
I am aware that Arch is just packaging up the binary release artifacts published by the gradle project. But that's just never going to fly for fedora.
Arch is also the only distro I looked at that does this, everybody else (at least debian, ubuntu, OpenSUSE) is stuck at an ancient version, if gradle is available at all.
FWIW, I can compile 6.4 just fine on Arch Linux using the Github source code via:
./gradlew allZip
Now try doing that offline and without using the pre-built gradle/wrapper/gradle-wrapper.jar :) You'll be surprised how much junk the build process still needs to download.
Do we need a two-step bootstrap process? A first (offline) step where we run gradle-wrapper and fetch all the resources, put all online dependencies into a SRPM/lookaside cache and "finish" the bootstrap build in Koji (giving us a bootstrapped version which works) and then replacing _all_ assets with versions built using the bootstrapped gradle and finally rebuilding gradle?
It'd be hell to set up the first time (two .specs?) and hell to make sure we get every package at the right version. But theoretically possible? :-)
But it might allow us to skip incremental bootstrap from a really old gradle version and might even get us a process which works for future bootstraps.
- Alex
Fabio
Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Tue, May 12, 2020 at 3:34 PM Alex Scheel ascheel@redhat.com wrote:
Obviously count us in, Fabio :-)
*Us* means the three guys from the Dogtag PKI team? :)
Do we need a two-step bootstrap process? A first (offline) step where we run gradle-wrapper and fetch all the resources, put all online dependencies into a SRPM/lookaside cache and "finish" the bootstrap build in Koji (giving us a bootstrapped version which works) and then replacing _all_ assets with versions built using the bootstrapped gradle and finally rebuilding gradle?
It'd be hell to set up the first time (two .specs?) and hell to make sure we get every package at the right version. But theoretically possible? :-)
But it might allow us to skip incremental bootstrap from a really old gradle version and might even get us a process which works for future bootstraps.
That's an innocent thought :) I'm afraid it won't work though. Do you think gradle is downloading source code for its dependencies? Nope, it only downloads prebuilt JARs.
So the build script loads a prebuilt gradle-wraper.jar (that's shipped with the gradle sources) that then in turn downloads more prebuilt JARs from the gradle repository to satisfy gradle's build dependencies which are then used to actually build full gradle ...
----- Original Message -----
From: "Fabio Valentini" decathorpe@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Tuesday, May 12, 2020 9:44:33 AM Subject: Re: Re-Launching the Java SIG
On Tue, May 12, 2020 at 3:34 PM Alex Scheel ascheel@redhat.com wrote:
Obviously count us in, Fabio :-)
*Us* means the three guys from the Dogtag PKI team? :)
Yeah, but mostly expect Dinesh and I :)
Do we need a two-step bootstrap process? A first (offline) step where we run gradle-wrapper and fetch all the resources, put all online dependencies into a SRPM/lookaside cache and "finish" the bootstrap build in Koji (giving us a bootstrapped version which works) and then replacing _all_ assets with versions built using the bootstrapped gradle and finally rebuilding gradle?
It'd be hell to set up the first time (two .specs?) and hell to make sure we get every package at the right version. But theoretically possible? :-)
But it might allow us to skip incremental bootstrap from a really old gradle version and might even get us a process which works for future bootstraps.
That's an innocent thought :) I'm afraid it won't work though. Do you think gradle is downloading source code for its dependencies? Nope, it only downloads prebuilt JARs.
Right -- I wasn't suggesting that it'd download source code. Merely that a binary-JAR-bootstrapped Gradle could be used to (re)-build all of the libraries it needed (from source this time!) and then re-build itself (using those source-built libraries and building a new gradle from source).
The internet-downloaded JARs could be put into lookaside and the SRPM could pull them, put them in the right location, and finish the initial Gradle build. Koji would finish the build and the resulting gradle would be available for us to use.
IIRC the restriction on source code builds of packages can be waived for bootstrap-only builds. So for initial build of gradle, we're fine using the binary wrapper as long as we fully replace it with source-only builds.
Someone with a more recent understanding of packaging policy can weigh in here though.
So the build script loads a prebuilt gradle-wraper.jar (that's shipped with the gradle sources) that then in turn downloads more prebuilt JARs from the gradle repository to satisfy gradle's build dependencies which are then used to actually build full gradle ...
Right :) So we'd take all of those new downloads and put them into lookaside and ship a SPRM that finishes the build based off of those internet-downloaded JARs. This satisifies Koji's no-internet policy while giving us a (hopefully) useful Gradle build system as output.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed at the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel.
I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).
I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with.
Felix
On 5/12/20 11:55 AM, Felix Schwarz wrote:
Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed at the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel.
Yes, exactly. It's not a Java thing, it's a free software thing. If we just grab binaries how do we know that they respect the basic freedoms?
I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).
I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with.
Quite. The high road is never the easy road. Thank you.
On Tue, May 12, 2020 at 12:26 PM Andrew Haley aph@redhat.com wrote:
On 5/12/20 11:55 AM, Felix Schwarz wrote:
Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed at the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel.
Yes, exactly. It's not a Java thing, it's a free software thing. If we just grab binaries how do we know that they respect the basic freedoms?
I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).
I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with.
Quite. The high road is never the easy road. Thank you.
It's too bad nobody's built an equivalent to Maven Central that requires at least sources to be uploaded to publish, similar to PyPI for Python...
On 5/12/20 5:55 AM, Felix Schwarz wrote:
Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed at the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel.
I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).
I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with.
As someone who has been burned due to Fedora's goody little two shoes policies, I'd kindly ask that Fedora take a hike and not package the software at all.
Other software developers SHOULD NEVER have to deal with bug reports from Fedora or any other distro because they want to modify software instead of taking what was already made, breaking things as a result. This isn't the first time a Linux distro has done this either, IIRC, there was an issue with Debian and the developer of the Xscreensaver software too.
At worst all you're doing is angering people who want to support Linux and at best hurting yourselves. Stop it.
Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Ty,
On 2020-05-13 06:58, Ty Young wrote:
On 5/12/20 5:55 AM, Felix Schwarz wrote:
Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed at the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel.
I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).
I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with.
As someone who has been burned due to Fedora's goody little two shoes policies, I'd kindly ask that Fedora take a hike and not package the software at all.
That should be "little goody two shoes policies" . .
P.
On Tue, 12 May 2020 15:58:39 -0500, you wrote:
As someone who has been burned due to Fedora's goody little two shoes policies, I'd kindly ask that Fedora take a hike and not package the software at all.
The only way to make sure that the stuff included with Fedora is open source is to build it from source - simply grabbing a binary provided by an upstream means upstream could slip in some closed source portions or have such a complex and undocumented build system that the project may as well be closed source because no one else can build it.
Gerald Henriksen wrote:
The only way to make sure that the stuff included with Fedora is open source is to build it from source - simply grabbing a binary provided by an upstream means upstream could slip in some closed source portions or have such a complex and undocumented build system that the project may as well be closed source because no one else can build it.
And arguably that (after the "or") is exactly what Gradle is. ;-)
Kevin Kofler
On Tue, May 12, 2020 at 10:57:43PM -0400, Gerald Henriksen wrote:
The only way to make sure that the stuff included with Fedora is open source is to build it from source - simply grabbing a binary provided by an upstream means upstream could slip in some closed source portions or have such a complex and undocumented build system that the project may as well be closed source because no one else can build it.
I've personally encountered Java stuff that, when compiled from its sources, immediately crashed, whereas the "official binaries" worked.
Why not use the official binaries? Because they had a showstopper bug in my environment, and I was trying to devise a fix.
(Even absent that bug, the official binaries had extra "features" like proprietary instrumentation/etc libraries that I (and many others) consider unacceptable..)
- Solomon
On 13.05.20 14:55, Solomon Peachy wrote:
On Tue, May 12, 2020 at 10:57:43PM -0400, Gerald Henriksen wrote:
The only way to make sure that the stuff included with Fedora is open source is to build it from source - simply grabbing a binary provided by an upstream means upstream could slip in some closed source portions or have such a complex and undocumented build system that the project may as well be closed source because no one else can build it.
I've personally encountered Java stuff that, when compiled from its sources, immediately crashed, whereas the "official binaries" worked.
That is just incredibly broken.
Things like this are the reason why I think the build-from-source principle is important, regardless of the inconvience it undeniably causes.
Christopher
Ty Young youngty1997@gmail.com writes:
On 5/12/20 5:55 AM, Felix Schwarz wrote:
Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed at the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel.
I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).
I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with.
As someone who has been burned due to Fedora's goody little two shoes policies, I'd kindly ask that Fedora take a hike and not package the software at all.
This is not "being excellent to each other". Let's keep in mind that we are all here for the same reason (caring about Fedora), and that this makes us colleagues - even when we disagree.
Thanks, --Robbie
On 5/13/20 12:04 PM, Robbie Harwood wrote:
Ty Young youngty1997@gmail.com writes:
On 5/12/20 5:55 AM, Felix Schwarz wrote:
Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed at the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel.
I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).
I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with.
As someone who has been burned due to Fedora's goody little two shoes policies, I'd kindly ask that Fedora take a hike and not package the software at all.
This is not "being excellent to each other". Let's keep in mind that we are all here for the same reason (caring about Fedora), and that this makes us colleagues - even when we disagree.
Neither was the threat and intimidation by higher ups at Red Hat or Fedora, which very few people on this seem to care about despite constantly bringing up the CoC. Selective enforcement probably isn't "being excellent to each other" either.
Anyway, I'm just asking that Fedora not repeat what Debian did. While I find it to be a bit paranoid, I understand the concerns regarding someone sneaking in malware into pre-build binaries. I'm just asking Fedora not package the software at all in that case, or any software that depends on that software if possible. People who want to support Linux by writing software shouldn't be bothered with bug reports from issues they never created to begin with.
Thanks, --Robbie
On Wed, May 13, 2020, at 5:04 PM, Ty Young wrote:
On 5/13/20 12:04 PM, Robbie Harwood wrote:
Ty Young youngty1997@gmail.com writes:
On 5/12/20 5:55 AM, Felix Schwarz wrote:
Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed at the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel.
I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).
I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with.
As someone who has been burned due to Fedora's goody little two shoes policies, I'd kindly ask that Fedora take a hike and not package the software at all.
This is not "being excellent to each other". Let's keep in mind that we are all here for the same reason (caring about Fedora), and that this makes us colleagues - even when we disagree.
Neither was the threat and intimidation by higher ups at Red Hat or Fedora, which very few people on this seem to care about despite constantly bringing up the CoC. Selective enforcement probably isn't "being excellent to each other" either.
Anyway, I'm just asking that Fedora not repeat what Debian did. While I find it to be a bit paranoid, I understand the concerns regarding someone sneaking in malware into pre-build binaries. I'm just asking Fedora not package the software at all in that case, or any software that depends on that software if possible. People who want to support Linux by writing software shouldn't be bothered with bug reports from issues they never created to begin with.
Is your position that Fedora should not package any software where the Upstream provides binaries? If so, that would seem to defeat the purpose of a Linux distribution, IMHO.
V/r, James Cassell
On 5/13/20 4:16 PM, James Cassell wrote:
On Wed, May 13, 2020, at 5:04 PM, Ty Young wrote:
On 5/13/20 12:04 PM, Robbie Harwood wrote:
Ty Young youngty1997@gmail.com writes:
On 5/12/20 5:55 AM, Felix Schwarz wrote:
Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed at the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel.
I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).
I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with.
As someone who has been burned due to Fedora's goody little two shoes policies, I'd kindly ask that Fedora take a hike and not package the software at all.
This is not "being excellent to each other". Let's keep in mind that we are all here for the same reason (caring about Fedora), and that this makes us colleagues - even when we disagree.
Neither was the threat and intimidation by higher ups at Red Hat or Fedora, which very few people on this seem to care about despite constantly bringing up the CoC. Selective enforcement probably isn't "being excellent to each other" either.
Anyway, I'm just asking that Fedora not repeat what Debian did. While I find it to be a bit paranoid, I understand the concerns regarding someone sneaking in malware into pre-build binaries. I'm just asking Fedora not package the software at all in that case, or any software that depends on that software if possible. People who want to support Linux by writing software shouldn't be bothered with bug reports from issues they never created to begin with.
Is your position that Fedora should not package any software where the Upstream provides binaries? If so, that would seem to defeat the purpose of a Linux distribution, IMHO.
No. If source code is provided side-by-side with the binaries(as-is the case with Gradle and many other software) then it's fine as the source code provided is *supposed* to give you the binaries once compiled anyway. If it doesn't then something shady may be going on.
Although I highly doubt the security claims that people are making in favor of compiling from source. Does every Fedora packager *actually* pore over every line of code in order to make sure it doesn't do anything shady? I really doubt it, that would be a superhuman task in many cases. If you can't trust binaries coming from the horses mouth then I'm not so sure you can trust the side-by-side source code either...
V/r, James Cassell _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Wed, May 13, 2020 at 04:04:50PM -0500, Ty Young wrote:
Anyway, I'm just asking that Fedora not repeat what Debian did. While I find it to be a bit paranoid, I understand the concerns regarding someone sneaking in malware into pre-build binaries. I'm just asking Fedora not package the software at all in that case, or any software that depends on that software if possible. People who want to support Linux by writing software shouldn't be bothered with bug reports from issues they never created to begin with.
"Fedora" doesn't package software; individuals do. Those individuals are free to package whatever they like, and Fedora will distribute those packages if they meet the well-established packaging criteria.
Those packagers, and Fedora, are "supporting Linux".
Meanwhile, for every distribution-created "bug" there are ten thousand that created by the upstream authors. Most upstreams are mature enough to recognize this, and consider distribution-level packaging (and front-line user support) efforts to be, on the whole, a net gain.
- Solomon
On 5/13/20 4:58 PM, Solomon Peachy wrote:
On Wed, May 13, 2020 at 04:04:50PM -0500, Ty Young wrote:
Anyway, I'm just asking that Fedora not repeat what Debian did. While I find it to be a bit paranoid, I understand the concerns regarding someone sneaking in malware into pre-build binaries. I'm just asking Fedora not package the software at all in that case, or any software that depends on that software if possible. People who want to support Linux by writing software shouldn't be bothered with bug reports from issues they never created to begin with.
"Fedora" doesn't package software; individuals do. Those individuals are free to package whatever they like, and Fedora will distribute those packages if they meet the well-established packaging criteria.
Whichever you choose. Large projects like Gnome and Fedora refer to themselves as one large organization one minute and then as individuals the next. It reminds me of how everyone says "Linux" is less resource hungry then Windows but "Linux" is just a kernel, as those same people will often say in "Linux"'s defense.
and it's those "well-established" packaging criteria are the reason people stopped packaging Java software for Fedora, according to many emails.
Those packagers, and Fedora, are "supporting Linux".
The amount of disdain and disrespect for third-party, and/or independent software developers and/or creators who don't conform to your clubhouse rules is palpable.
Meanwhile, for every distribution-created "bug" there are ten thousand that created by the upstream authors. Most upstreams are mature enough to recognize this, and consider distribution-level packaging (and front-line user support) efforts to be, on the whole, a net gain.
Nonsense spewing with no proof.
The Debian Xscreensaver fiasco is enough proof that contradicts your ridiculous claims and there are plenty more, including:
* Game developers largely refuse to support Linux, and the some of the few that have have or are currently pulling support citing fragmentation(support) issues.
* Hardware support for AMD GPUs is all over the place and even if technically supported, can be too buggy to use. This is largely because kernel/mesa versions are all over the place.
* Some software packaged even in large Linux distros like Ubuntu as part of their enabled-by-default repos don't even launch. Codeblocks in around 16.04, IIRC, didn't even launch once you install it. You had to use their privately hosted repo to install a newer version.
* You often need to install third-party repos to get up-to-date software since packages are way too slow, or the distros just choose to use very old software(Debian).
* Bugs fixed in newer versions of Gnome shell aren't backported to older versions. It looks like they have extended support, but I doubt it's for the same amount of time Ubuntu supports an LTS. Even if it did, only newer Gnome shell versions are supported for that long. 18.04 probably has shell bugs right now that are fixed in newer Gnome versions.
* There have been security bugs found in packaged software like Grub that have existed in years despite being one of the most widely packaged and used software on Linux.
* Linux distros do not resolve dependancy conflicts correctly. Ubuntu last time I checked still requires you manually install 32-bit libs in order to launch Steam instead of doing that for the user.
* Linux distro GUI package managers are generally poorly designed and buggy. That screenshot of Fedora's cinnamon spin's packager manager GUI I posted here showed that plenty. Other distros aren't much better. Manjaro/Arch Linux's "Pamac" GUI had a bug where it sees itself as a running package manager instance and refused to upgrade or install software on a failed AUR software build/install.
* Linux distros "taint" software they package and install by, for example, enabling shell extensions in Gnome by default. This more likely than not results in false bug reports. Fedora even does this!
I could literally go on and on. The "my-shit-don't-stink" attitude is so terrible it's borderline sad.
- Solomon
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Thu, May 14, 2020 at 06:33:47AM -0500, Ty Young wrote:
Whichever you choose. Large projects like Gnome and Fedora refer to themselves as one large organization one minute and then as individuals the next. It reminds me of how everyone says "Linux" is less resource hungry then Windows but "Linux" is just a kernel, as those same people will often say in "Linux"'s defense.
Please don't change the subject.
The fact of the matter is that nearly nobody is actually paid to work on, or otherwise improve, Fedora. As opposed to, say, Windows (either the OS itself or the greater "ecosystem" around it)
If you want to get volunteers to do something, deriding and insulting them is highly counterproductive. Heck, that applies even if they aren't volunteers. If you act like an ass, don't complain if you're treated like one in response.
I'll follow up on the mostly-unrelated remainder of your reply after I'm back from the doctor.
- Solomon
On 5/14/20 6:42 AM, Solomon Peachy wrote:
On Thu, May 14, 2020 at 06:33:47AM -0500, Ty Young wrote:
Whichever you choose. Large projects like Gnome and Fedora refer to themselves as one large organization one minute and then as individuals the next. It reminds me of how everyone says "Linux" is less resource hungry then Windows but "Linux" is just a kernel, as those same people will often say in "Linux"'s defense.
Please don't change the subject.
The fact of the matter is that nearly nobody is actually paid to work on, or otherwise improve, Fedora. As opposed to, say, Windows (either the OS itself or the greater "ecosystem" around it)
I didn't say otherwise. No one is entitled to free work. If you stand on a mountain and shout how much better you are, as the Linux community often does, then well... don't cry when people show up with pitch forks when they realize they've been "sold" snake oil.
What i'm saying is: Distros like Fedora actively hurt the very people who are directly or indirectly helping them. There are single-person run projects, like mine, out there that can't possibly do all the work needed to have a dozen packages for each distro. It's just not possible or, in the case of Java based projects, not even needed to begin with.
That is to say nothing of those distros doing things like Fedora now does like running X as user which break otherwise perfectly running applications. I can't check in every 6 months to make sure y'all didn't break something. I don't have the time nor the download cap(1TB a month, GO USA!) for it.
If you want to get volunteers to do something, deriding and insulting them is highly counterproductive. Heck, that applies even if they aren't volunteers. If you act like an ass, don't complain if you're treated like one in response.
You're response, honestly, is just an echo of the general mentality many distro developers have that I've seen. It's not even unique or different.
I'll follow up on the mostly-unrelated remainder of your reply after I'm back from the doctor.
It was all in response to the insulation that packaging software for each distro is the answer to everything you seemed to have been putting forth.
- Solomon
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Thu, 14 May 2020 06:59:47 -0500, you wrote:
What i'm saying is: Distros like Fedora actively hurt the very people who are directly or indirectly helping them. There are single-person run projects, like mine, out there that can't possibly do all the work needed to have a dozen packages for each distro. It's just not possible or, in the case of Java based projects, not even needed to begin with.
1) nobody is forcing upstream developers to package their projects - that's what the packagers in the various distrobutions do.
2) the fact that people want to package the Java packages, and that other people want to install those packages, indicates that there is a need.
That is to say nothing of those distros doing things like Fedora now does like running X as user which break otherwise perfectly running applications.
Running X as a user would be a change done to decrease the security risk of running applications using X, or X itself.
It is the type of change that anyone should expect a distribution to make, and the type of change even Apple and Microsoft make (anyone who used Windows in the past will recall the applications that insisted on being run as an Administrator for no valid reason, and eventually Microsoft learned the hard way and cracked down - I am sure just like you seem to be a lot of Windows developers made the same false claim that MS was breaking otherwise perfectly running applications.
I can't check in every 6 months to make sure y'all didn't break something.
Then perhaps you need to look for a different hobby/career?
The software development field is full of constant change that developers need to be aware of regardless of OS or environment.
Le jeudi 14 mai 2020 à 06:33 -0500, Ty Young a écrit :
I could literally go on and on. The "my-shit-don't-stink" attitude is so terrible it's borderline sad.
And years of terminally broken build practices Java-side have finally resulted in complete capture of all the Java big data code the ASF wrote and people contributed to by a single ISV, Cloudera. Because it’s the sole remaining ISV able to build the result and provide it as secure and supported binaries.
Do you think the corps that paid a lot of the ASF devs to create the projects that Cloudera sells today did not notice? The next generation of corp-funded enterprise code will use another language.
Sincerely,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
I wanted to avoid replying to this thread, but this message forced me to do so since it is spreading misinformation.
On Thu, 2020-05-14 at 06:33 -0500, Ty Young wrote:
On 5/13/20 4:58 PM, Solomon Peachy wrote:
On Wed, May 13, 2020 at 04:04:50PM -0500, Ty Young wrote:
Anyway, I'm just asking that Fedora not repeat what Debian did. While I find it to be a bit paranoid, I understand the concerns regarding someone sneaking in malware into pre-build binaries. I'm just asking Fedora not package the software at all in that case, or any software that depends on that software if possible. People who want to support Linux by writing software shouldn't be bothered with bug reports from issues they never created to begin with.
"Fedora" doesn't package software; individuals do. Those individuals are free to package whatever they like, and Fedora will distribute those packages if they meet the well-established packaging criteria.
Whichever you choose. Large projects like Gnome and Fedora refer to themselves as one large organization one minute and then as individuals the next. It reminds me of how everyone says "Linux" is less resource hungry then Windows but "Linux" is just a kernel, as those same people will often say in "Linux"'s defense.
and it's those "well-established" packaging criteria are the reason people stopped packaging Java software for Fedora, according to many emails.
People did not stop packaging Java software for Fedora. Some of them did because packaging some of Java projects is hard, because upstream makes it hard to do so. By relying on old versions of dependencies, bundling them, switching buildsystem to gradle (which is basically impossible to package because of same reasons).
Those packagers, and Fedora, are "supporting Linux".
The amount of disdain and disrespect for third-party, and/or independent software developers and/or creators who don't conform to your clubhouse rules is palpable.
Meanwhile, for every distribution-created "bug" there are ten thousand that created by the upstream authors. Most upstreams are mature enough to recognize this, and consider distribution-level packaging (and front-line user support) efforts to be, on the whole, a net gain.
Nonsense spewing with no proof.
Well, you have started this. Can you provide some statistics how many bugs were introduced by distributions versus upstream bugs.
The Debian Xscreensaver fiasco is enough proof that contradicts your ridiculous claims and there are plenty more, including:
Well, this does not apply to Fedora as-is because we are trying to ship latest versions of software as much as possible. That's one of key F's of Fedora - First.
- Game developers largely refuse to support Linux, and the some of
the few that have have or are currently pulling support citing fragmentation(support) issues.
Fragmentation is the issue, yes. But I think this decade we are finally trying to converge. Flatpaks, RPM improvements and such.
- Hardware support for AMD GPUs is all over the place and even if
technically supported, can be too buggy to use. This is largely because kernel/mesa versions are all over the place.
Same here, in Fedora we try to keep kernel and mesa on latest versions as much as we can, so this does not apply to us.
- Some software packaged even in large Linux distros like Ubuntu as
part of their enabled-by-default repos don't even launch. Codeblocks in around 16.04, IIRC, didn't even launch once you install it. You had to use their privately hosted repo to install a newer version.
I agree that this is issue and bugs should be reported against such software. This area is not really explored by distributions much, but here at least we have quite good test suite for default Workstation applications, so contributing tests for other software is very welcome. Probably best place to talk about this would be test@ or ci@.
- You often need to install third-party repos to get up-to-date
software since packages are way too slow, or the distros just choose to use very old software(Debian).
This problem was supposed to be solved by Fedora Modularity, though from my POV it did not succeed (yet?).
- Bugs fixed in newer versions of Gnome shell aren't backported to
older versions. It looks like they have extended support, but I doubt it's for the same amount of time Ubuntu supports an LTS. Even if it did, only newer Gnome shell versions are supported for that long. 18.04 probably has shell bugs right now that are fixed in newer Gnome versions.
We do backport some of the fixes to stable Fedora versions, but it is huge effort and we try to do best. Do not forget that packages are maintained by individuals who do not get paid to work on this (some do, but that is minority and most likely they get paid for RHEL work rather than Fedora).
If you think there is some nice bug fix to be applied - submit Pull Request. Though this conflicts with your statements above that we should stop patching software and just give upstream binaries, because upstream most likely will never fix some bugs in old versions but in Fedora we might.
- There have been security bugs found in packaged software like Grub
that have existed in years despite being one of the most widely packaged and used software on Linux.
Did you see how many patches are applied to grub2 in Fedora? Security issues are everywhere? Were they introduced by distribution-specific patches? Pretty sure they were patched in Fedora much faster than upstream released new version.
- Linux distros do not resolve dependancy conflicts correctly.
Ubuntu last time I checked still requires you manually install 32-bit libs in order to launch Steam instead of doing that for the user.
Well, if there is specific bug in Fedora - please report it. Installing steam from rpmfusion gives me working steam and I did not have any issues with it.
- Linux distro GUI package managers are generally poorly designed
and buggy. That screenshot of Fedora's cinnamon spin's packager manager GUI I posted here showed that plenty. Other distros aren't much better. Manjaro/Arch Linux's "Pamac" GUI had a bug where it sees itself as a running package manager instance and refused to upgrade or install software on a failed AUR software build/install.
I can not argue with this. But if you would get same software from upstream, it won't be better at all because those bugs are not specific to distributions.
You are very welcome to design and create bug-free GUI package manager ;)
- Linux distros "taint" software they package and install by, for
example, enabling shell extensions in Gnome by default. This more likely than not results in false bug reports. Fedora even does this!
I can't speak for all software, but enabling some extensions by default is up to Workstation WG, they evaluate options and decide what is good for majority of Workstation users. For some other software it might be some legal requirements or things like that. Remember that people have best intents when packaging software. Mistakes happen and you should just let people know and they will do their best to address problem.
I could literally go on and on. The "my-shit-don't-stink" attitude is so terrible it's borderline sad.
- Solomon
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Thu, May 14, 2020 at 6:38 AM Igor Raits ignatenkobrain@fedoraproject.org wrote:
On Thu, 2020-05-14 at 06:33 -0500, Ty Young wrote:
Nonsense spewing with no proof.
Well, you have started this. Can you provide some statistics how many bugs were introduced by distributions versus upstream bugs.
My experience has been that when a packager actively maintains a package, the number of bugs fixed due to packager activity far outweighs the number of bugs introduced. We do not just blindly consume upstream. The work of a distribution is integration work, which few upstreams even think about. In the process of doing that integration work, we discover problems with upstream code, upstream build systems, upstream interactions with other components, and feed bug reports and patches back upstream. Many packages are in better shape *for everyone* because they were packaged for Fedora.
Of course, if you've got a packager who isn't paying attention, things can deteriorate. That's why we have mechanisms for finding and orphaning packages that don't appear to be maintained.
On 5/14/20 7:37 AM, Igor Raits wrote:
*big snip*
I feel like the context of that whole email has been lost. It was merely a long list of reasons why "just package software for dozens of distros" isn't an viable answer in response to the other person's claim. Fedora is a bit of an exception to the rule for some of those, I know, however most Linux distros aren't Fedora... and Fedora breaks software in its own unique way.
In regards to the Grub security bug, I was thinking of the backspace bug which allowed recovery console access.
Well, as just I saw "xscreensaver" word here:
Ty Young wrote on 2020/05/14 20:33:
On 5/13/20 4:58 PM, Solomon Peachy wrote:
On Wed, May 13, 2020 at 04:04:50PM -0500, Ty Young wrote:
Anyway, I'm just asking that Fedora not repeat what Debian did. While I find it to be a bit paranoid, I understand the concerns regarding someone sneaking in malware into pre-build binaries. I'm just asking Fedora not package the software at all in that case, or any software that depends on that software if possible. People who want to support Linux by writing software shouldn't be bothered with bug reports from issues they never created to begin with.
"Fedora" doesn't package software; individuals do. Those individuals are free to package whatever they like, and Fedora will distribute those packages if they meet the well-established packaging criteria.
Whichever you choose. Large projects like Gnome and Fedora refer to themselves as one large organization one minute and then as individuals the next. It reminds me of how everyone says "Linux" is less resource hungry then Windows but "Linux" is just a kernel, as those same people will often say in "Linux"'s defense.
and it's those "well-established" packaging criteria are the reason people stopped packaging Java software for Fedora, according to many emails.
Those packagers, and Fedora, are "supporting Linux".
The amount of disdain and disrespect for third-party, and/or independent software developers and/or creators who don't conform to your clubhouse rules is palpable.
Meanwhile, for every distribution-created "bug" there are ten thousand that created by the upstream authors. Most upstreams are mature enough to recognize this, and consider distribution-level packaging (and front-line user support) efforts to be, on the whole, a net gain.
Nonsense spewing with no proof.
The Debian Xscreensaver fiasco is enough proof that contradicts your ridiculous claims and there are plenty more, including:
Perhaps you don't know, but me, Debian maintainer Tormod Volden and the upstream jwz are talking with good relation these days.
Regards, Mamoru
Game developers largely refuse to support Linux, and the some of the few that have have or are currently pulling support citing fragmentation(support) issues.
Hardware support for AMD GPUs is all over the place and even if technically supported, can be too buggy to use. This is largely because kernel/mesa versions are all over the place.
Some software packaged even in large Linux distros like Ubuntu as part of their enabled-by-default repos don't even launch. Codeblocks in around 16.04, IIRC, didn't even launch once you install it. You had to use their privately hosted repo to install a newer version.
You often need to install third-party repos to get up-to-date software since packages are way too slow, or the distros just choose to use very old software(Debian).
Bugs fixed in newer versions of Gnome shell aren't backported to older versions. It looks like they have extended support, but I doubt it's for the same amount of time Ubuntu supports an LTS. Even if it did, only newer Gnome shell versions are supported for that long. 18.04 probably has shell bugs right now that are fixed in newer Gnome versions.
There have been security bugs found in packaged software like Grub that have existed in years despite being one of the most widely packaged and used software on Linux.
Linux distros do not resolve dependancy conflicts correctly. Ubuntu last time I checked still requires you manually install 32-bit libs in order to launch Steam instead of doing that for the user.
Linux distro GUI package managers are generally poorly designed and buggy. That screenshot of Fedora's cinnamon spin's packager manager GUI I posted here showed that plenty. Other distros aren't much better. Manjaro/Arch Linux's "Pamac" GUI had a bug where it sees itself as a running package manager instance and refused to upgrade or install software on a failed AUR software build/install.
Linux distros "taint" software they package and install by, for example, enabling shell extensions in Gnome by default. This more likely than not results in false bug reports. Fedora even does this!
I could literally go on and on. The "my-shit-don't-stink" attitude is so terrible it's borderline sad.
- Solomon
On Thu, 14 May 2020 06:33:47 -0500, you wrote:
- Game developers largely refuse to support Linux, and the some of the
few that have have or are currently pulling support citing fragmentation(support) issues.
Game developers refuse to support Linux because there is no userbase - even Steam, who moved to Linux for strategic rather than financial reasons, consistently reports a neglible installed base of Linux gamers.
The fragmentation may not help, but it isn't the driving force (if Linux gaming was a $10billion a year business they would find a way to deal with the issues).
- Hardware support for AMD GPUs is all over the place and even if
technically supported, can be too buggy to use. This is largely because kernel/mesa versions are all over the place.
Surprise, writing drivers and the associated code for modern GPU's is hard - even for the in house development teams providing binary only drivers, as anyone who follows GPU issues on Windows is aware.
- You often need to install third-party repos to get up-to-date software
since packages are way too slow, or the distros just choose to use very old software(Debian).
Part of choosing a distro is choosing new vs well tested.
Anyone choosing the released versions of Debian is doing so on the basis they want well tested releases and new versions aren't a priority.
If you want new version, you choose a different distro.
- Bugs fixed in newer versions of Gnome shell aren't backported to older
versions. It looks like they have extended support, but I doubt it's for the same amount of time Ubuntu supports an LTS. Even if it did, only newer Gnome shell versions are supported for that long. 18.04 probably has shell bugs right now that are fixed in newer Gnome versions.
Not a Gnome problem (says a person who doesn't even like Gnome anymore).
When Ubuntu/Red Hat/CentOS/etc release whatever their variation of a distro with a long support lifetime is they take on the burden of supporting the software for the duration of that release, not the upstream.
So in your complaint, it is not up to Gnome to continue supporting that version of Gnome, it is up to Ubuntu to backport/create fixes as necessary - that is after all the whole point of offering a LTS release that people pay Ubuntu to provide support on.
On Tue, May 12, 2020 at 10:59 PM Ty Young youngty1997@gmail.com wrote:
As someone who has been burned due to Fedora's goody little two shoes policies, I'd kindly ask that Fedora take a hike and not package the software at all.
I find it kind of ironic that this is exactly what happened, but you seem not to be aware of it - despite the whole sub-thread having started because of this? gradle was no longer maintainable as an RPM package, so it - and most packages that require it - were removed from fedora. end of story. Isn't this what you're arguing for here?
Fabio
Hello,
On Tue, May 12, 2020 at 12:57 PM Felix Schwarz fschwarz@fedoraproject.org wrote:
Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I suppose I should have been more clear there. Sorry for any confusion, it was aimed
at
the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel.
I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).
I agree that building from sources is the right thing to do. However, let me play devil's advocate here :)
What makes Java apps different from other language ecosystems is that Java apps never share dependencies. There is no concept of "system-wide" 3rd-party Java libraries that would be automatically added to classpath when JVM starts. I realize that this is technically possible to achieve, but that is not how people use it. If you want to distribute your Java app, you just bundle it with all its dependencies into a beefy tarball and ship it. And if Java apps never share dependencies, then developers are not really forced to keep up with latest versions of libraries. Nobody can update the non-existent system-wide Java library that would break their application. They are in control.
Since there is no standard place for shared Java libraries on your laptop, how can you use the packaged Java libraries and develop software against them? Sure, you can hack it and make it work on your Fedora 32 machine, but your custom Makefile is not guaranteed to work on Fedora 31 or later on 33. And your colleague that is on CentOS is out of luck of course. And so are all your potential external contributors on their MacBooks and Ubuntus. What I am trying to say in this paragraph is that shipping (in RPMs) and maintaining individual build-only Java libraries is, at least in my opinion, questionable.
Fedora and other linux distributions are trying to do the right thing, but things like Java apps simply don't fit in. What Java app developers are doing may not be the best thing, but it's been like that for ~20 years, and it seems to be "good enough" for the majority of people involved (well, developers at least). Fedora alone is too insignificant to change it I am afraid.
However, with all that being said. I do like "dnf install my-java-app" better than unpacking some tarballs somewhere.
And finally, here comes the "devil's advocate" part of my email.
* building Java libraries and apps from sources? * +1, no doubt about this * building Java libraries and apps from sources in a controlled and reproducible environment? * yes, please * building Java libraries and apps from sources from SRPMs? * do we really need the RPM overhead here? * shipping (in RPMs) and maintaining Java libraries that are not runtime dependencies of Java applications that we want to have in Fedora? * nope, why? build such build-only dependencies from sources, make sure they are OK license-wise, but do not ship them to users (as explained above, they are not very useful for developers anyway)
We can do license reviews, we can build from sources, but we don't necessarily have to do all this in RPMs. We can do all the right things, store (our binary) results in a language-native way, which would be a Maven repository controlled by Fedora in this case, and then simply wrap our good binary JARs into RPMs, without rebuilding them all the time.
Note having such language-native repository full of good and reviewed Java libraries would mean that developers that care about such things could actually start using it instead of the official Maven repository. And they wouldn't be tied to a specific version of Fedora or Linux.
I don't think this would go against the current packaging policy, it just would be *a ton" of work :)
This email turned out to be way longer than I expected it to be, but Java packaging is a complicated topic.
Thanks, Michal
I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with.
Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Thu, May 14, 2020 at 12:55 PM Michal Srb msrb@redhat.com wrote:
Hello,
On Tue, May 12, 2020 at 12:57 PM Felix Schwarz fschwarz@fedoraproject.org wrote:
Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I suppose
I
should have been more clear there. Sorry for any confusion, it was
aimed at
the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel.
I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).
I agree that building from sources is the right thing to do. However, let me play devil's advocate here :)
What makes Java apps different from other language ecosystems is that Java apps never share dependencies. There is no concept of "system-wide" 3rd-party Java libraries that would be automatically added to classpath when JVM starts. I realize that this is technically possible to achieve, but that is not how people use it. If you want to distribute your Java app, you just bundle it with all its dependencies into a beefy tarball and ship it. And if Java apps never share dependencies, then developers are not really forced to keep up with latest versions of libraries. Nobody can update the non-existent system-wide Java library that would break their application. They are in control.
Long story short - IT world liked so much Java way of doing things so containers popped up so the same effect can be achieved for any language :P .
Since there is no standard place for shared Java libraries on your laptop, how can you use the packaged Java libraries and develop software against them? Sure, you can hack it and make it work on your Fedora 32 machine, but your custom Makefile is not guaranteed to work on Fedora 31 or later on 33. And your colleague that is on CentOS is out of luck of course. And so are all your potential external contributors on their MacBooks and Ubuntus. What I am trying to say in this paragraph is that shipping (in RPMs) and maintaining individual build-only Java libraries is, at least in my opinion, questionable.
Fedora and other linux distributions are trying to do the right thing, but things like Java apps simply don't fit in. What Java app developers are doing may not be the best thing, but it's been like that for ~20 years, and it seems to be "good enough" for the majority of people involved (well, developers at least). Fedora alone is too insignificant to change it I am afraid.
However, with all that being said. I do like "dnf install my-java-app" better than unpacking some tarballs somewhere.
And finally, here comes the "devil's advocate" part of my email.
- building Java libraries and apps from sources?
- +1, no doubt about this
- building Java libraries and apps from sources in a controlled and
reproducible environment?
- yes, please
- building Java libraries and apps from sources from SRPMs?
- do we really need the RPM overhead here?
- shipping (in RPMs) and maintaining Java libraries that are not runtime
dependencies of Java applications that we want to have in Fedora?
- nope, why? build such build-only dependencies from sources, make sure
they are OK license-wise, but do not ship them to users (as explained above, they are not very useful for developers anyway)
We can do license reviews, we can build from sources, but we don't necessarily have to do all this in RPMs. We can do all the right things, store (our binary) results in a language-native way, which would be a Maven repository controlled by Fedora in this case, and then simply wrap our good binary JARs into RPMs, without rebuilding them all the time.
Note having such language-native repository full of good and reviewed Java libraries would mean that developers that care about such things could actually start using it instead of the official Maven repository. And they wouldn't be tied to a specific version of Fedora or Linux.
I don't think this would go against the current packaging policy, it just would be *a ton" of work :)
This email turned out to be way longer than I expected it to be, but Java packaging is a complicated topic.
Thanks, Michal
I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with.
Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 5/14/20 4:53 AM, Michal Srb wrote:
Hello,
On Tue, May 12, 2020 at 12:57 PM Felix Schwarz <fschwarz@fedoraproject.org mailto:fschwarz@fedoraproject.org> wrote:
Am 12.05.20 um 12:32 schrieb Ty Young: > Right, I figured it was some Fedora policy and not up to you. I suppose I > should have been more clear there. Sorry for any confusion, it was aimed at > the Fedora project as a whole as this is a Fedora issue. This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel. I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).I agree that building from sources is the right thing to do. However, let me play devil's advocate here :)
What makes Java apps different from other language ecosystems is that Java apps never share dependencies. There is no concept of "system-wide" 3rd-party Java libraries that would be automatically added to classpath when JVM starts. I realize that this is technically possible to achieve, but that is not how people use it. If you want to distribute your Java app, you just bundle it with all its dependencies into a beefy tarball and ship it. And if Java apps never share dependencies, then developers are not really forced to keep up with latest versions of libraries. Nobody can update the non-existent system-wide Java library that would break their application. They are in control.
For the records, Java is going to get a shiny new "Foreign Memory Access" API, part of Project Panama, (hopefully) in a few years. With it there will be Java applications that have both Java requirements and native library requirements.
Anyone who wants to uses it to create Linux software is going to have to deal with Linux distros breaking their stuff, no matter what they do, just as Fedora broke mine.
Le jeudi 14 mai 2020 à 11:53 +0200, Michal Srb a écrit :
Since there is no standard place for shared Java libraries on your laptop,
Of course there is one /usr/share/java, which has been defined and used by Linux distributions since jpackage times (circa ~2000).
Java is not special from a technical POW, its tooling is poor sure but tooling reflects the values of the community creating and using the tools, not the reverse.
Regards,
Dne 14. 05. 20 v 11:53 Michal Srb napsal(a):
Hello,
On Tue, May 12, 2020 at 12:57 PM Felix Schwarz <fschwarz@fedoraproject.org mailto:fschwarz@fedoraproject.org> wrote:
Am 12.05.20 um 12:32 schrieb Ty Young: > Right, I figured it was some Fedora policy and not up to you. I suppose I > should have been more clear there. Sorry for any confusion, it was aimed at > the Fedora project as a whole as this is a Fedora issue. This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel. I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).I agree that building from sources is the right thing to do. However, let me play devil's advocate here :)
What makes Java apps different from other language ecosystems is that Java apps never share dependencies. There is no concept of "system-wide" 3rd-party Java libraries that would be automatically added to classpath when JVM starts.
And now how is this different to different language ecosystems? All languages I have ever worked with has this attitude, more or less. The Linux distributions are fighting against this but with various success. With Java, Fedora is failing ATM.
And if the bundling is not happening on language level, then we are back to bundling in containers and flatpacks and what not.
Vít
I realize that this is technically possible to achieve, but that is not how people use it. If you want to distribute your Java app, you just bundle it with all its dependencies into a beefy tarball and ship it. And if Java apps never share dependencies, then developers are not really forced to keep up with latest versions of libraries. Nobody can update the non-existent system-wide Java library that would break their application. They are in control.
Since there is no standard place for shared Java libraries on your laptop, how can you use the packaged Java libraries and develop software against them? Sure, you can hack it and make it work on your Fedora 32 machine, but your custom Makefile is not guaranteed to work on Fedora 31 or later on 33. And your colleague that is on CentOS is out of luck of course. And so are all your potential external contributors on their MacBooks and Ubuntus. What I am trying to say in this paragraph is that shipping (in RPMs) and maintaining individual build-only Java libraries is, at least in my opinion, questionable.
Fedora and other linux distributions are trying to do the right thing, but things like Java apps simply don't fit in. What Java app developers are doing may not be the best thing, but it's been like that for ~20 years, and it seems to be "good enough" for the majority of people involved (well, developers at least). Fedora alone is too insignificant to change it I am afraid.
However, with all that being said. I do like "dnf install my-java-app" better than unpacking some tarballs somewhere.
And finally, here comes the "devil's advocate" part of my email.
- building Java libraries and apps from sources?
* +1, no doubt about this
- building Java libraries and apps from sources in a controlled and
reproducible environment? * yes, please
- building Java libraries and apps from sources from SRPMs?
* do we really need the RPM overhead here?
- shipping (in RPMs) and maintaining Java libraries that are not
runtime dependencies of Java applications that we want to have in Fedora? * nope, why? build such build-only dependencies from sources, make sure they are OK license-wise, but do not ship them to users (as explained above, they are not very useful for developers anyway)
We can do license reviews, we can build from sources, but we don't necessarily have to do all this in RPMs. We can do all the right things, store (our binary) results in a language-native way, which would be a Maven repository controlled by Fedora in this case, and then simply wrap our good binary JARs into RPMs, without rebuilding them all the time.
Note having such language-native repository full of good and reviewed Java libraries would mean that developers that care about such things could actually start using it instead of the official Maven repository. And they wouldn't be tied to a specific version of Fedora or Linux.
I don't think this would go against the current packaging policy, it just would be *a ton" of work :)
This email turned out to be way longer than I expected it to be, but Java packaging is a complicated topic.
Thanks, Michal
I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with. Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> To unsubscribe send an email to devel-leave@lists.fedoraproject.org <mailto:devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Thu, May 14, 2020 at 2:42 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 14. 05. 20 v 11:53 Michal Srb napsal(a):
Hello,
On Tue, May 12, 2020 at 12:57 PM Felix Schwarz fschwarz@fedoraproject.org wrote:
Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I suppose
I
should have been more clear there. Sorry for any confusion, it was
aimed at
the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel.
I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place).
I agree that building from sources is the right thing to do. However, let me play devil's advocate here :)
What makes Java apps different from other language ecosystems is that Java apps never share dependencies. There is no concept of "system-wide" 3rd-party Java libraries that would be automatically added to classpath when JVM starts.
And now how is this different to different language ecosystems? All languages I have ever worked with has this attitude, more or less. The Linux distributions are fighting against this but with various success. With Java, Fedora is failing ATM.
Since Java apps always ship their dependencies in tarballs, it's like upstream is pinning down dependencies to specific versions. There is no room for any version ranges like for example "as long as you have java-lib>=2.3 on your system, the dependency will be satisfied". Installing (well, "unpacking") other Java application that requires java-lib>=3.0 will never break the first app.
Then Fedora comes in and tries not only to run both Java App #1 and Java App #2 on the same system, ideally with the single version of java-lib(latest), but also to build both the apps on the same system (the build system being the 3rd Java app). I am not saying this is something bad, it's just something completely unnatural for the Java App ecosystem. Java developers ship their tested self-contained tarballs which work on Linux, Mac and Windows. And Linux distributions take those apps and try to run them with a completely different set of dependencies. I kinda understand why upstream projects are not always happy about that...
Although you're right that there are plenty of Python projects out there that straight up tell you to isolate their applications in a virtual environment when you're pip-installing them from PyPI. It's not all though. There are still plenty of projects that tell you that as long as you have python-lib>=2.3 on your machine, you will be fine. This makes Python packaging so much easier, at least in my opinion. Such Python apps are not in full control of their dependency chains, they realize that newer python-lib could introduce some breaking changes and if you open a pull request with a patch, they are not surprised, they know what the problem is and why the pull request should be merged. That's what they signed up for by saying that python-lib>=2.3 is fine.
Thanks, Michal
And if the bundling is not happening on language level, then we are back to bundling in containers and flatpacks and what not.
Vít
I realize that this is technically possible to achieve, but that is not how people use it. If you want to distribute your Java app, you just bundle it with all its dependencies into a beefy tarball and ship it. And if Java apps never share dependencies, then developers are not really forced to keep up with latest versions of libraries. Nobody can update the non-existent system-wide Java library that would break their application. They are in control.
Since there is no standard place for shared Java libraries on your laptop, how can you use the packaged Java libraries and develop software against them? Sure, you can hack it and make it work on your Fedora 32 machine, but your custom Makefile is not guaranteed to work on Fedora 31 or later on 33. And your colleague that is on CentOS is out of luck of course. And so are all your potential external contributors on their MacBooks and Ubuntus. What I am trying to say in this paragraph is that shipping (in RPMs) and maintaining individual build-only Java libraries is, at least in my opinion, questionable.
Fedora and other linux distributions are trying to do the right thing, but things like Java apps simply don't fit in. What Java app developers are doing may not be the best thing, but it's been like that for ~20 years, and it seems to be "good enough" for the majority of people involved (well, developers at least). Fedora alone is too insignificant to change it I am afraid.
However, with all that being said. I do like "dnf install my-java-app" better than unpacking some tarballs somewhere.
And finally, here comes the "devil's advocate" part of my email.
- building Java libraries and apps from sources?
- +1, no doubt about this
- building Java libraries and apps from sources in a controlled and
reproducible environment?
- yes, please
- building Java libraries and apps from sources from SRPMs?
- do we really need the RPM overhead here?
- shipping (in RPMs) and maintaining Java libraries that are not runtime
dependencies of Java applications that we want to have in Fedora?
- nope, why? build such build-only dependencies from sources, make sure
they are OK license-wise, but do not ship them to users (as explained above, they are not very useful for developers anyway)
We can do license reviews, we can build from sources, but we don't necessarily have to do all this in RPMs. We can do all the right things, store (our binary) results in a language-native way, which would be a Maven repository controlled by Fedora in this case, and then simply wrap our good binary JARs into RPMs, without rebuilding them all the time.
Note having such language-native repository full of good and reviewed Java libraries would mean that developers that care about such things could actually start using it instead of the official Maven repository. And they wouldn't be tied to a specific version of Fedora or Linux.
I don't think this would go against the current packaging policy, it just would be *a ton" of work :)
This email turned out to be way longer than I expected it to be, but Java packaging is a complicated topic.
Thanks, Michal
I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with.
Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Fri, 15 May 2020 08:02:34 +0200 Michal Srb msrb@redhat.com wrote:
I realize that this is technically possible to achieve, but that is not how people use it. If you want to distribute your Java app, you just bundle it with all its dependencies into a beefy tarball and ship it. And if Java apps never share dependencies, then developers are not really forced to keep up with latest versions of libraries. Nobody can update the non-existent system-wide Java library that would break their application. They are in control.
An aside, just to clarify for myself. That means that all Java apps are the equivalent of statically linked, right? And are related to things like flatpaks and modules?
Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
On Fri, 15 May 2020 08:02:34 +0200 Michal Srb msrb@redhat.com wrote:
An aside, just to clarify for myself. That means that all Java apps are the equivalent of statically linked, right? And are related to things like flatpaks and modules?
No, that’s similar to venv everywhere. The language has bytecode- sharing objects. Java upstreams just got used not to share those executable objects between projects, not to version them properly, not to manage their ABI breaks, and to change things in the local copy instead of contributing changes to the original project.
That’s non-free software open source to its extreme. The code is available for a dev to copy and resell at his next work, but everything is organised (at the human not technical level) so it’s not possible to reuse the bytecode directly without paying someone to copy and fork the original code that this bytecode was generated from in the next project.
The practical effect is technical stagnation and market capture by deep pocket companies.
On Sat, 16 May 2020 11:23:03 +0200 Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
On Fri, 15 May 2020 08:02:34 +0200 Michal Srb msrb@redhat.com wrote:
An aside, just to clarify for myself. That means that all Java apps are the equivalent of statically linked, right? And are related to things like flatpaks and modules?
No, that’s similar to venv everywhere. The language has bytecode- sharing objects. Java upstreams just got used not to share those executable objects between projects, not to version them properly, not to manage their ABI breaks, and to change things in the local copy instead of contributing changes to the original project.
That’s non-free software open source to its extreme. The code is available for a dev to copy and resell at his next work, but everything is organised (at the human not technical level) so it’s not possible to reuse the bytecode directly without paying someone to copy and fork the original code that this bytecode was generated from in the next project.
The practical effect is technical stagnation and market capture by deep pocket companies.
Thanks for the explanation.
Hello,
On Sat, May 16, 2020 at 11:24 AM Nicolas Mailhot via devel < devel@lists.fedoraproject.org> wrote:
Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
On Fri, 15 May 2020 08:02:34 +0200 Michal Srb msrb@redhat.com wrote:
An aside, just to clarify for myself. That means that all Java apps are the equivalent of statically linked, right? And are related to things like flatpaks and modules?
No, that’s similar to venv everywhere. The language has bytecode- sharing objects. Java upstreams just got used not to share those executable objects between projects, not to version them properly, not to manage their ABI breaks, and to change things in the local copy instead of contributing changes to the original project.
Well... Java upstreams share their JARs by uploading them to a public Maven repository (Maven Central most of the time). And in the vast majority of cases there are also "source-JARs" (containing source code) uploaded alongside the bytecode JARs. I am simplifying things here a bit, but basically when Java open source projects want to ship their apps, they fetch pre-built dependencies from Maven Central, compile their apps, and bundle everything (app bytecode + pre-built deps) in a tarball. And that's what they ship. JARs in Maven Central are always versioned, and people who want to use them pick specific versions, so no version ranges... (although technically possible of course) And JARs in Maven Central are immutable, so if you want to use such pre-built JAR, you pick a specific version for your app and it will never change.
What you're describing sounds like the 2005-ish way of developing Java applications :) The Java open source world has evolved since then.
That’s non-free software open source to its extreme. The code is available for a dev to copy and resell at his next work, but everything is organised (at the human not technical level) so it’s not possible to reuse the bytecode directly without paying someone to copy and fork the original code that this bytecode was generated from in the next project.
I'd like to know more about this if you don't mind. This is definitely not how open source Java apps are developed.
Thanks, Michal
The practical effect is technical stagnation and market capture by deep pocket companies.
-- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Le lundi 18 mai 2020 à 14:12 +0200, Michal Srb a écrit :
Hello,
On Sat, May 16, 2020 at 11:24 AM Nicolas Mailhot via devel < devel@lists.fedoraproject.org> wrote:
Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
On Fri, 15 May 2020 08:02:34 +0200 Michal Srb msrb@redhat.com wrote:
An aside, just to clarify for myself. That means that all Java
apps
are the equivalent of statically linked, right? And are related to things like flatpaks and modules?
No, that’s similar to venv everywhere. The language has bytecode- sharing objects. Java upstreams just got used not to share those executable objects between projects, not to version them properly, not to manage their ABI breaks, and to change things in the local copy instead of contributing changes to the original project.
Well... Java upstreams share their JARs by uploading them to a public Maven repository (Maven Central most of the time). And in the vast majority of cases there are also "source-JARs" (containing source code) uploaded alongside the bytecode JARs. I am simplifying things here a bit, but basically when Java open source projects want to ship their apps, they fetch pre-built dependencies from Maven Central, compile their apps, and bundle everything (app bytecode + pre-built deps) in a tarball. And that's what they ship.
If Java finally left the stone age, there should be no problem building the same artefacts in rpm, installing them in a central place like %{_datadir}/java or %{_libdir}/java, and making it a package other java software can buildrequire. We managed it in Go, and we did not even have a language versionning infra to build upon.
That’s non-free software open source to its extreme. The code is available for a dev to copy and resell at his next work, but everything is organised (at the human not technical level) so it’s not possible to reuse the bytecode directly without paying someone to copy and fork the original code that this bytecode was generated from in the next project.
I'd like to know more about this if you don't mind. This is definitely not how open source Java apps are developed.
Free software is end user not dev oriented. Stallman wanted his printer driver to work. The GPL gives rights to the recipient. As long as the toolchain is broken enouth even huge downstreams like distros are unable to rebuild the source easily, you have something that may be open source, but does not function as effective free software.
And when downstreaming is broken upstreaming is broken too (who will bother contributing to an upstream when things do not flow the other way?).
As spot wrote a long time ago, the only useful form of open source for Fedora (and a lot of other entities) is free software.
On 5/18/20 7:35 AM, Nicolas Mailhot via devel wrote:
Le lundi 18 mai 2020 à 14:12 +0200, Michal Srb a écrit :
Hello,
On Sat, May 16, 2020 at 11:24 AM Nicolas Mailhot via devel < devel@lists.fedoraproject.org> wrote:
Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
On Fri, 15 May 2020 08:02:34 +0200 Michal Srb msrb@redhat.com wrote:
An aside, just to clarify for myself. That means that all Java
apps
are the equivalent of statically linked, right? And are related to things like flatpaks and modules?
No, that’s similar to venv everywhere. The language has bytecode- sharing objects. Java upstreams just got used not to share those executable objects between projects, not to version them properly, not to manage their ABI breaks, and to change things in the local copy instead of contributing changes to the original project.
Well... Java upstreams share their JARs by uploading them to a public Maven repository (Maven Central most of the time). And in the vast majority of cases there are also "source-JARs" (containing source code) uploaded alongside the bytecode JARs. I am simplifying things here a bit, but basically when Java open source projects want to ship their apps, they fetch pre-built dependencies from Maven Central, compile their apps, and bundle everything (app bytecode + pre-built deps) in a tarball. And that's what they ship.
If Java finally left the stone age, there should be no problem building the same artefacts in rpm, installing them in a central place like %{_datadir}/java or %{_libdir}/java, and making it a package other java software can buildrequire. We managed it in Go, and we did not even have a language versionning infra to build upon.
That’s non-free software open source to its extreme. The code is available for a dev to copy and resell at his next work, but everything is organised (at the human not technical level) so it’s not possible to reuse the bytecode directly without paying someone to copy and fork the original code that this bytecode was generated from in the next project.
I'd like to know more about this if you don't mind. This is definitely not how open source Java apps are developed.
Free software is end user not dev oriented. Stallman wanted his printer driver to work. The GPL gives rights to the recipient. As long as the toolchain is broken enouth even huge downstreams like distros are unable to rebuild the source easily, you have something that may be open source, but does not function as effective free software.
The "toolchain" isn't broken, other than Gradle developers not caring about backwards compatibility but... It works for them, just as constantly breaking internal kernel APIs works for the Linux kernel or running X. Org as user does for Fedora. No-one involved with the Linux kernel or the distros has a right to complain, y'all do it to other people all the time.
The only thing I remember Gradle downloading when I built it locally is a previous beta build in order to build the end final release. Maybe there were a few other things I'm forgetting, someone else can correct me.
And when downstreaming is broken upstreaming is broken too (who will bother contributing to an upstream when things do not flow the other way?).
Yeah, no.
My software didn't magically break just for Fedora because of some bug in my software. It broke because Fedora decided they wanted to do something nearly no Linux distro does... something that has been the defacto standard for many years.
Willing to bet money Gnome has received a great many bug reports because of extensions Linux distros ship by default as well.
...and there are plenty of Open Source projects that don't have packages yet people contribute to them. This isn't the early 2000 when barely anyone has internet and sites like Github didn't exist. Sure, a distro package increases visibility still, but it isn't all that matters. Heck, the Windows 10 calculator app is sitting at over 1100 contributors right now on Github.
The point here is not that upstream should be blindly trusted, but rather that downstream's poo **does*** stink and affect other people, even those that don't specifically package for your distro.
As spot wrote a long time ago, the only useful form of open source for Fedora (and a lot of other entities) is free software.
On 5/18/20 8:34 AM, Ty Young wrote:
...and there are plenty of Open Source projects that don't have packages yet people contribute to them. This isn't the early 2000 when barely anyone has internet and sites like Github didn't exist. Sure, a distro package increases visibility still, but it isn't all that matters. Heck, the Windows 10 calculator app is sitting at over 1100 contributors right now on Github.
I meant VSCode, not the calculator app... although that probably has a fair bit of contributors too.
Le lundi 18 mai 2020 à 08:34 -0500, Ty Young a écrit :
The "toolchain" isn't broken, other than Gradle developers not caring about backwards compatibility but... It works for them, just as constantly breaking internal kernel APIs works for the Linux kernel
The difference, is that you can build a new kernel, while running an old kernel. the kernel is not constantly breaking external kernel APIs like gradle breaks the external gradle APIs a new gradle needs to be built (when building gradle with gradle, the new build is a consumer of external gradle APIS)
On Mon, May 18, 2020 at 3:34 PM Ty Young youngty1997@gmail.com wrote:
On 5/18/20 7:35 AM, Nicolas Mailhot via devel wrote: My software didn't magically break just for Fedora because of some bug in my software. It broke because Fedora decided they wanted to do something nearly no Linux distro does... something that has been the defacto standard for many years.
Ty,
You continue telling us that "Fedora" (sic!) broke your software, but without actually telling us
- which broken program it is that you're talking about, and - which packages / changes in fedora caused the breakage,
those comments are just spreading FUD without adding anything worthwhile to the discussion. Please, either provide those details - so we can do better in the future - or stop.
Thanks, Fabio
On 5/18/20 9:14 AM, Fabio Valentini wrote:
On Mon, May 18, 2020 at 3:34 PM Ty Young youngty1997@gmail.com wrote:
On 5/18/20 7:35 AM, Nicolas Mailhot via devel wrote: My software didn't magically break just for Fedora because of some bug in my software. It broke because Fedora decided they wanted to do something nearly no Linux distro does... something that has been the defacto standard for many years.
those comments are just spreading FUD without adding anything worthwhile to the discussion. Please, either provide those details - so we can do better in the future - or stop.
Fair enough.
The application was an Nvidia GPU overclocking utility written in Java. When Fedora decided to disable running X. Org as root, it resulted in the application no longer being able to adjust GPU/Memory clocks, among possible other things. The software worked perfectly fine on the latest versions of Ubuntu and Arch(and still does), but not Fedora simply because of this.
Thanks, Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 5/18/20 7:27 AM, Ty Young wrote:
The application was an Nvidia GPU overclocking utility written in Java. When Fedora decided to disable running X. Org as root, it resulted in the application no longer being able to adjust GPU/Memory clocks, among possible other things. The software worked perfectly fine on the latest versions of Ubuntu and Arch(and still does), but not Fedora simply because of this.
I figured it had to be something to do with NVidia because that's the only thing that would break due to that change. If you insist on using proprietary software (NVidia driver), then you take the risk of having problems like this. If NVidia would do the right thing and open their driver, then this could work.
On 5/18/20 2:51 PM, Samuel Sieb wrote:
On 5/18/20 7:27 AM, Ty Young wrote:
The application was an Nvidia GPU overclocking utility written in Java. When Fedora decided to disable running X. Org as root, it resulted in the application no longer being able to adjust GPU/Memory clocks, among possible other things. The software worked perfectly fine on the latest versions of Ubuntu and Arch(and still does), but not Fedora simply because of this.
I figured it had to be something to do with NVidia because that's the only thing that would break due to that change. If you insist on using proprietary software (NVidia driver), then you take the risk of having problems like this. If NVidia would do the right thing and open their driver, then this could work.
I completely obliterated this nonsensical argument last time this was said in the thread Red Hat censored. Allow me to do so again.
There are a great many outstanding bugs, some of which have existed for years, in the kernel, its Open Source drivers and in mesa as well as in other projects like Gnome. No one has fixed those despite being Open Source, and in some cases they even have pull requests but the maintainers won't, for whatever reason, accept them. Linux distros refuse to ship or backport the latest versions of the kernel or mesa, so even if it was Open Source and in the kernel it'd take years for everyone to get the fix, if ever.
You are arguing on theoretical nonsense that has no real basis in reality, fueled by purely ideological hatred.
If it was Open Source and we were having this discussion, people like yourself would just move the goalpost by saying something like "Why don't you contribute?" like you always do. You don't care about fixing the problem, you just want the drivers to be Open Source and in the kernel. The issue itself be damned, you don't care whether it *ACTUALLY* gets fixed or not.
Things like graphics drivers shouldn't be apart of the kernel, because as Linux distros have proven, they can't be trusted to keep things up-to-date or not to taint them... and the kernel moves waaaay too slow for hardware releases anyway. AMD GPU owners who have the latest and greatest have to wait many months for AMD to add support, and even then there tends to be bugs. Nvidia? Every new GPU release support is impressively rock solid that I've seen.
X. Org as root is **STILL** the standard and Fedora broke it. This is why no one wants to support Linux: you constantly break your own platform and then cry wolf when people who don't care about your ideological nonsense refuse to fix their software that was working perfectly fine before. No one has time to check on every new Linux distro release to see what you broke and clearly, if the number of unmaintained Fedora packages is any indicator, no one has time or interest to package and properly maintain the Open Source software that is available either.
All of this is completely ignoring the fact that an Open Source Nvidia driver would most likely mean OC support exposed by system files like it is with AMD instead of a nice C API. *Screw that*. Most of the AMD GPU overclocking utilities have broken GPU support because of this, IIRC. With Nvidia I have a nice stable APIs(Stable APIs in Linux? Impossible.) I can use and support nearly everything at once.
Unless you're going to personally volunteer to making a new, stable, drop-in replacement C API if they do Open Source their driver or make a new one and integrate it with the kernel?
Willing to bet you or anyone else here won't.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 5/18/20 7:08 PM, Solomon Peachy wrote:
On Mon, May 18, 2020 at 06:03:16PM -0500, Ty Young wrote:
Willing to bet you or anyone else here won't.
FYI, this applies to you as well.
You just proved my point:
If it was Open Source and we were having this discussion, people like
yourself would just move the goalpost by saying something like "Why don't you contribute?" like you always do. You don't care about fixing the problem, you >just want the drivers to be Open Source and in the kernel. The issue itself be damned, you don't care whether it *ACTUALLY* gets fixed or not.
You create these problems by refusing to play nice and then attempt to use it as leverage in order to attack people/organizations that don't bend the knee. In actuality the issue itself is just a stepping stone that isn't really cared about.
A Gnome foundation member did this this exact same thing on Reddit recently, where graphical glitches would appear *only* on GTK windows that use the unified headerbar and were maxamized/de-maximized. The headerbar only part wasn't originally mentioned, and since the user bringing up the bug was using Nvidia, Nvidia was the one to get blamed for it. Once the unified headerbar only part was mentioned did the foundation member back track. It's why I don't believe for a second that issues like the Gnome 3 memory leaks while running Nvidia is Nvidia's fault. People point fingers based on who they like and agree with, not on technical facts.
Crying wolves if there ever was any.
(Yes, I know there are very real situations where Nvidia isn't playing nice themselves, but this isn't the case here)
I'm not advocating for in-kernel drivers. AMD with their drivers has proven proven what a bad idea that is. I, for the most part, like where I'm at and the way Nvidia does things. If I'm against it, I don't see why I would be the one to do it.
Surely it is the responsibility of those who want such a change to make sure that everything that existed before can continue to exist? I realize this requires that such arguments are being made in good faith and consider the perspectives and needs of everyone, which they aren't.
- Solomon
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Mon, May 18, 2020 at 07:54:42PM -0500, Ty Young wrote:
Surely it is the responsibility of those who want such a change to make sure that everything that existed before can continue to exist? I realize this requires that such arguments are being made in good faith and consider the perspectives and needs of everyone, which they aren't.
Yes, exactly, it requires arguments being made in good faith, and considering the needs and perspectives of others.
...You would do well to practice what you preach.
I might add that even when your needs and perspectives are duly considered, it does not follow that the outcome will be something you are necessarily satisfied with. Engineering is all about balancing tradeoffs, after all.
Meanwhile, "everything before" continues to exist and works as well as the day it was released. Nobody here is forcing you to use anything more recent; you're free to adapt that older source code to your needs, or pay someone else to do it for you.
- Solomon
On 5/18/20 5:54 PM, Ty Young wrote:
I'm not advocating for in-kernel drivers. AMD with their drivers has proven proven what a bad idea that is. I, for the most part, like where I'm at and the way Nvidia does things. If I'm against it, I don't see why I would be the one to do it.
This comment doesn't make any sense. NVidia's driver is just as much "in-kernel" as AMD's. It's just supplied separately and has to play catch-up every time some internal kernel interface changes.
On Mon, 18 May 2020 18:03:16 -0500, you wrote:
X. Org as root is **STILL** the standard and Fedora broke it. This is why no one wants to support Linux: you constantly break your own platform and then cry wolf when people who don't care about your ideological nonsense refuse to fix their software that was working perfectly fine before.
X.org running as root likely is a security risk, and as such it is long past the point where somebody should have fixed it.
And with time the other distros will probably also change X.org to run as a user instead of root (ie. once all the bugs are worked out).
So not a very good arguement.
Dude, chill out. We're not going to go back to running X as root. The Nvidia overclocking tool is just not important at all (seriously, who cares?). If you're upset their proprietary software doesn't work anymore, you can ask them nicely to fix it please... or ask for the source code, and see how far that gets you. ;)
The kernel gets rebased continuously throughout the life of a Fedora release. mesa updates are also possible when required, especially at the beginning of a release's lifetime. If there are bugs, you can work with the package maintainers....
On Mon, May 18, 2020 at 8:24 pm, Michael Catanzaro mcatanzaro@gnome.org wrote:
Dude, chill out. We're not going to go back to running X as root.
Ugh, I just noticed the subject of this thread is Java SIG. Amazing how thoroughly this conversation has been derailed....
On 5/18/20 8:24 PM, Michael Catanzaro wrote:
Dude, chill out. We're not going to go back to running X as root. The Nvidia overclocking tool is just not important at all (seriously, who cares?). If you're upset their proprietary software doesn't work anymore, you can ask them nicely to fix it please... or ask for the source code, and see how far that gets you. ;)
I'm well aware Fedora has no interest in correcting its breakage of backwards compatibility. If you'd actually read all the messages you'd realize it was all in the name of explaining why distros can't be trusted to package software and shouldn't do it, including Java applications. It went down this path naturally, as discussions tend to do and have on this very mailing list without my involvement.
(someone tried changing the subject line, but as I pointed out, I was just trying to explain why, as objectively as possible, it wasn't as perfect of a solution as they claim)
Of course, instead of reading everything, you decided to make a snide, unfriendly remark that probably violates the CoC. Given you have a Gnome email address I guess I can't say I'm surprised you take the position that you do. Afterall, Gnome has angered many great, talented, and independent extension developers including, IIRC, the developer of one of those most widely used tray icon extensions at the time who later quit out of frustration because Gnome kept breaking things. Indeed, people in general complain about Gnome not playing nice with others.
I'd love to see CoC enforcement on this, but I feel like I'd die of old age before that ever happens.
Ugh, I just noticed the subject of this thread is Java SIG. Amazing
how thoroughly this conversation has been derailed....
Maybe people shouldn't make claims that amount to "packaging software for each distro is the only way to do things" despite plenty of evidence to the contrary.
The kernel gets rebased continuously throughout the life of a Fedora release. mesa updates are also possible when required, especially at the beginning of a release's lifetime. If there are bugs, you can work with the package maintainers....
The issues being talked about aren't specific to Fedora. Fedora does do a better job than average on these sort of things.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Mon, May 18, 2020 at 10:18 PM Ty Young youngty1997@gmail.com wrote:
On 5/18/20 8:24 PM, Michael Catanzaro wrote:
Dude, chill out. We're not going to go back to running X as root. The Nvidia overclocking tool is just not important at all (seriously, who cares?). If you're upset their proprietary software doesn't work anymore, you can ask them nicely to fix it please... or ask for the source code, and see how far that gets you. ;)
I'm well aware Fedora has no interest in correcting its breakage of backwards compatibility. If you'd actually read all the messages you'd realize it was all in the name of explaining why distros can't be trusted to package software and shouldn't do it, including Java applications. It went down this path naturally, as discussions tend to do and have on this very mailing list without my involvement.
For what it's worth, this is not a change unique to Fedora. Arch, Debian, and other distributions run Xorg in a user session when GDM is the display manager. Some distributions may have elected to change GDM's behavior to the legacy behavior, but none I'm aware of today do so aside from Ubuntu (and that's only when the proprietary drivers are installed). That said, if you are using a display manager that does not support rootless Xorg, you'll get the legacy behavior.
However, the writing is on the wall for both Xorg as root and Xorg as a whole. Fedora in this regard is a trailblazer and other distributions *will* follow. Several distributions have finally shipped GNOME with Wayland by default and removed their "hold-back" patches that reverted GDM and GNOME to legacy behaviors by default. Other desktop display managers are working on supporting running Xorg in the user session as well, and will likely drop support for running Xorg as root once they do. Your app will break everywhere, I can guarantee it.
And to be quite honest, I'm tired of seeing you complain on this list without being even singularly helpful at all. You have provided virtually no constructive feedback and continue to attack the Fedora Project and its members. I do not know why you are even here, given that you seem to hate everything we do.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Monday, May 18, 2020 4:03:16 PM MST Ty Young wrote:
On 5/18/20 2:51 PM, Samuel Sieb wrote:
On 5/18/20 7:27 AM, Ty Young wrote:
The application was an Nvidia GPU overclocking utility written in Java. When Fedora decided to disable running X. Org as root, it resulted in the application no longer being able to adjust GPU/Memory clocks, among possible other things. The software worked perfectly fine on the latest versions of Ubuntu and Arch(and still does), but not Fedora simply because of this.
I figured it had to be something to do with NVidia because that's the only thing that would break due to that change. If you insist on using proprietary software (NVidia driver), then you take the risk of having problems like this. If NVidia would do the right thing and open their driver, then this could work.
I completely obliterated this nonsensical argument last time this was said in the thread Red Hat censored. Allow me to do so again.
There are a great many outstanding bugs, some of which have existed for years, in the kernel, its Open Source drivers and in mesa as well as in other projects like Gnome. No one has fixed those despite being Open Source, and in some cases they even have pull requests but the maintainers won't, for whatever reason, accept them. Linux distros refuse to ship or backport the latest versions of the kernel or mesa, so even if it was Open Source and in the kernel it'd take years for everyone to get the fix, if ever.
You are arguing on theoretical nonsense that has no real basis in reality, fueled by purely ideological hatred.
If it was Open Source and we were having this discussion, people like yourself would just move the goalpost by saying something like "Why don't you contribute?" like you always do. You don't care about fixing the problem, you just want the drivers to be Open Source and in the kernel. The issue itself be damned, you don't care whether it *ACTUALLY* gets fixed or not.
Things like graphics drivers shouldn't be apart of the kernel, because as Linux distros have proven, they can't be trusted to keep things up-to-date or not to taint them... and the kernel moves waaaay too slow for hardware releases anyway. AMD GPU owners who have the latest and greatest have to wait many months for AMD to add support, and even then there tends to be bugs. Nvidia? Every new GPU release support is impressively rock solid that I've seen.
X. Org as root is **STILL** the standard and Fedora broke it. This is why no one wants to support Linux: you constantly break your own platform and then cry wolf when people who don't care about your ideological nonsense refuse to fix their software that was working perfectly fine before. No one has time to check on every new Linux distro release to see what you broke and clearly, if the number of unmaintained Fedora packages is any indicator, no one has time or interest to package and properly maintain the Open Source software that is available either.
All of this is completely ignoring the fact that an Open Source Nvidia driver would most likely mean OC support exposed by system files like it is with AMD instead of a nice C API. *Screw that*. Most of the AMD GPU overclocking utilities have broken GPU support because of this, IIRC. With Nvidia I have a nice stable APIs(Stable APIs in Linux? Impossible.) I can use and support nearly everything at once.
Unless you're going to personally volunteer to making a new, stable, drop-in replacement C API if they do Open Source their driver or make a new one and integrate it with the kernel?
Willing to bet you or anyone else here won't.
What does this rant against Linux and Fedora have to do with the Java SIG? Please take this to another thread, preferably at support@nvidia.com.
On Mon, May 18, 2020 at 9:34 AM Ty Young youngty1997@gmail.com wrote:
The "toolchain" isn't broken, other than Gradle developers not caring about backwards compatibility but... It works for them, just as
A toolchain with broken links scattered through it is not toolchain. Building up the .jar files as a hierarchy from source is not well supported, and has been vulnerable to many fractions. It's inherent to object oriented approaches where paying any notice outside your own momentgary layer of abstraction is considered a violation of your objectives and an anti-pattern. Many "autobuild as needed tools have had this problem, including CPAN, pip, ant, maven, and gradle.
I dealt with a lot of this bundling tools for JPackage years ago, and still deal with it with other tools today, most recently with the rubygems dependencies for R10K. It's a problem.
The only thing I remember Gradle downloading when I built it locally is a previous beta build in order to build the end final release. Maybe there were a few other things I'm forgetting, someone else can correct me.
Build them in "mock", which cuts off network access to the chroot cage building the software. I suspect you'll be unpleasantly surprised: it tends to show build-time downloads for rubygems, pip, and maven based software builds.
Yeah, no.
My software didn't magically break just for Fedora because of some bug in my software. It broke because Fedora decided they wanted to do something nearly no Linux distro does... something that has been the defacto standard for many years.
...and there are plenty of Open Source projects that don't have packages yet people contribute to them. This isn't the early 2000 when barely anyone has internet and sites like Github didn't exist. Sure, a distro package increases visibility still, but it isn't all that matters. Heck, the Windows 10 calculator app is sitting at over 1100 contributors right now on Github.
Inability or unwillingneds to follow deployment standards is one of the signs of software that should be avoided. If the authors follow
The point here is not that upstream should be blindly trusted, but rather that downstream's poo **does*** stink and affect other people, even those that don't specifically package for your distro.
Well, yes.
Gradle was highly applauded by some developers of my acquaintance. I'm curious what you find beneficial about it, because I've found it to be destabilizing.
On Tue, May 12, 2020 03:35:55 -0500, Ty Young wrote:
On 5/12/20 2:50 AM, Fabio Valentini wrote:
What about packaging gradle instead? (In the cases I looked into, porting from gradle to maven would be rewriting the build system from scratch. Assuming that we have tens and will have hundreds of packages with gradle, in the long term it seems better to support gradle, even in some partial form, than to rewrite build systems of hundreds of packages...).
Uh. We tried. Multiple times. It just won't work, like, ever again. I wrote a longer response here: https://discussion.fedoraproject.org/t/re-launching-the-java-sig/19688/3 So, you are welcome to try, but I bet you'll end up in the long line of packagers who failed to make it work.
JUST PACKAGE THE PRE-COMPILED BUILDS!!!
Ty, please stop.
Hi,
A bit of a tangential question:
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl writes:
So maybe just nuke the outdated parts (member lists, "state of affairs" content), and keep the rest?
My wiki-foo sucks. Is there some way to automatically generate a list of members on the wiki from a FAS group?
Thanks, Omair
-- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
On Tue, May 12, 2020 at 10:53:32AM -0400, Omair Majid wrote:
Hi,
A bit of a tangential question:
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl writes:
So maybe just nuke the outdated parts (member lists, "state of affairs" content), and keep the rest?
My wiki-foo sucks. Is there some way to automatically generate a list of members on the wiki from a FAS group?
Maybe just link to some appropriate page (src.fp.o?). I don't think we need to duplicate this information on the wiki.
Zbyszek
Hey Fabio,
thank you very much for your work.
I can't take on more Fedora work but still wanted to express my gratitude :-)
Felix
On Mon, May 11, 2020 at 10:46 PM Fabio Valentini decathorpe@gmail.com wrote:
This past weekend I finally decided to jump off the cliff and attempt to re-launch the Java SIG. It seems there's some interest in keeping the Java stack maintained, it's just not focused or organized right now.
What we did when starting the Stewardship SIG seems to have worked out pretty well, so I'm trying to follow in those footsteps here:
- new proper FAS / pkgdb group: java-maint-sig ("java-sig" is occupied
by an old, unused bot account)
- new private mailing list: java-maint-sig (for RHBZ bugs - so,
possibly, also CVEs - hence, private)
- tracking project on pagure: https://pagure.io/java-maint-sig (for
maintenance scripts, tracking tickets, awesome package dashboards, etc.)
There's already a public fedora mailing list for Java (java-devel), and and IRC channel (#fedora-java on freenode.net), which we will continue to use. Sadly, the existing wiki page for the Java SIG is hopelessly outdated, so I'm tempted to just scrap it and point readers to the pagure tracking project once it's set up beyond a basic README file.
Major upcoming projects for the "new" Java Package Maintainers group include:
- managing OpenJDK 11 / Java 11 transition for hundreds of Java
packages in fedora 33
- starting to transition well-maintained Java packages from the
Stewardship SIG back into Java SIG
- possibly porting packages from gradle to maven to fix build issues
and broken dependencies
- transitioning from old java.net / JavaEE projects to the new ones
now under the eclipse-ee4j umbrella
I know that - among others - the PKI team, Neuro SIG, and Eclipse maintainers depend on parts of the java stack for their packages, so I hope that we can work together with them on these things, as well.
So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list.
Good luck with that! As someone that has been part of the Java SIG since day 0 I wish you make Fedora even better workstation for Java developer than we ever managed.
Let's make this happen. Fabio _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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/java-devel@lists.fedoraproject...
On Tue, May 12, 2020 at 1:02 PM Aleksandar Kurtakov akurtako@redhat.com wrote:
Good luck with that! As someone that has been part of the Java SIG since day 0 I wish you make Fedora even better workstation for Java developer than we ever managed.
Thank you! You're welcome to (re-)join the effort, we'd be lucky to have experienced packagers like you.
Fabio
On Mon, 2020-05-11 at 21:45 +0200, Fabio Valentini wrote:
This past weekend I finally decided to jump off the cliff and attempt to re-launch the Java SIG. It seems there's some interest in keeping the Java stack maintained, it's just not focused or organized right now.
What we did when starting the Stewardship SIG seems to have worked out pretty well, so I'm trying to follow in those footsteps here:
- new proper FAS / pkgdb group: java-maint-sig ("java-sig" is
occupied by an old, unused bot account)
- new private mailing list: java-maint-sig (for RHBZ bugs - so,
possibly, also CVEs - hence, private)
- tracking project on pagure: https://pagure.io/java-maint-sig (for
maintenance scripts, tracking tickets, awesome package dashboards, etc.)
There's already a public fedora mailing list for Java (java-devel), and and IRC channel (#fedora-java on freenode.net), which we will continue to use. Sadly, the existing wiki page for the Java SIG is hopelessly outdated, so I'm tempted to just scrap it and point readers to the pagure tracking project once it's set up beyond a basic README file.
Major upcoming projects for the "new" Java Package Maintainers group include:
- managing OpenJDK 11 / Java 11 transition for hundreds of Java
packages in fedora 33
- starting to transition well-maintained Java packages from the
Stewardship SIG back into Java SIG
- possibly porting packages from gradle to maven to fix build issues
and broken dependencies
- transitioning from old java.net / JavaEE projects to the new ones
now under the eclipse-ee4j umbrella
I know that - among others - the PKI team, Neuro SIG, and Eclipse maintainers depend on parts of the java stack for their packages, so I hope that we can work together with them on these things, as well.
So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list.
Let's make this happen.
Thanks Fabio!
I'll be happy to join and will try to liaise as we continue to look after the OpenJDK packages themselves.
Cheers, Severin
On 5/11/20 10:45 PM, Fabio Valentini wrote:
This past weekend I finally decided to jump off the cliff and attempt to re-launch the Java SIG. It seems there's some interest in keeping the Java stack maintained, it's just not focused or organized right now
Great, really appreciate your work.
So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list.
Count me in! I'm relatively new to fedora and rpm packaging, but got ~20 years of working with Java and my packages depends on the Java ecosystem. FAS account: korkeala.
Markku.
Let's make this happen. Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Tue, May 12, 2020 at 5:43 PM Markku Korkeala markku.korkeala@iki.fi wrote:
Great, really appreciate your work.
Thank you!
Count me in! I'm relatively new to fedora and rpm packaging, but got ~20 years of working with Java and my packages depends on the Java ecosystem. FAS account: korkeala.
Markku.
Great! You should be all set now. Group membership should show up at https://src.fedoraproject.org/group/java-maint-sig after logging out and back in.
Glad to have you on board!
Fabio
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, 2020-05-11 at 21:45 +0200, Fabio Valentini wrote:
This past weekend I finally decided to jump off the cliff and attempt to re-launch the Java SIG. It seems there's some interest in keeping the Java stack maintained, it's just not focused or organized right now.
What we did when starting the Stewardship SIG seems to have worked out pretty well, so I'm trying to follow in those footsteps here:
- new proper FAS / pkgdb group: java-maint-sig ("java-sig" is
occupied by an old, unused bot account)
- new private mailing list: java-maint-sig (for RHBZ bugs - so,
possibly, also CVEs - hence, private)
- tracking project on pagure: https://pagure.io/java-maint-sig (for
maintenance scripts, tracking tickets, awesome package dashboards, etc.)
There's already a public fedora mailing list for Java (java-devel), and and IRC channel (#fedora-java on freenode.net), which we will continue to use. Sadly, the existing wiki page for the Java SIG is hopelessly outdated, so I'm tempted to just scrap it and point readers to the pagure tracking project once it's set up beyond a basic README file.
Major upcoming projects for the "new" Java Package Maintainers group include:
- managing OpenJDK 11 / Java 11 transition for hundreds of Java
packages in fedora 33
- starting to transition well-maintained Java packages from the
Stewardship SIG back into Java SIG
- possibly porting packages from gradle to maven to fix build issues
and broken dependencies
- transitioning from old java.net / JavaEE projects to the new ones
now under the eclipse-ee4j umbrella
I know that - among others - the PKI team, Neuro SIG, and Eclipse maintainers depend on parts of the java stack for their packages, so I hope that we can work together with them on these things, as well.
So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list.
Count me in! I don't think I can help much, but at least can give some suggestions.
Let's make this happen.
Good luck, Fabio!
Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Tue, May 12, 2020 at 6:17 PM Igor Raits ignatenkobrain@fedoraproject.org wrote:
Count me in! I don't think I can help much, but at least can give some suggestions.
Let's make this happen.
Good luck, Fabio!
Thanks! Every bit of help counts. You should now be all set with FAS group / pagure project / mailing list subscription.
Fabio
On Tue, May 12, 2020 18:45:12 +0200, Fabio Valentini wrote:
On Tue, May 12, 2020 at 6:17 PM Igor Raits ignatenkobrain@fedoraproject.org wrote:
Count me in! I don't think I can help much, but at least can give some suggestions.
Let's make this happen.
Good luck, Fabio!
Thanks! Every bit of help counts. You should now be all set with FAS group / pagure project / mailing list subscription.
I've picked a suitable point to fork the thread back to a Java SIG related conversation (added "thread" at the end of the subject to help people differentiate).
Fabio,
Is there a TODO list somewhere so we new members can take up tasks from to help you out? This ticket perhaps? It's filed at the Stewardship SIG's pagure project, so I wasn't sure if the Java SIG folks are aware of it yet:
https://pagure.io/stewardship-sig/issue/89
On Tue, May 19, 2020 at 10:13 AM Ankur Sinha sanjay.ankur@gmail.com wrote:
On Tue, May 12, 2020 18:45:12 +0200, Fabio Valentini wrote:
On Tue, May 12, 2020 at 6:17 PM Igor Raits ignatenkobrain@fedoraproject.org wrote:
Count me in! I don't think I can help much, but at least can give some suggestions.
Let's make this happen.
Good luck, Fabio!
Thanks! Every bit of help counts. You should now be all set with FAS group / pagure project / mailing list subscription.
I've picked a suitable point to fork the thread back to a Java SIG related conversation (added "thread" at the end of the subject to help people differentiate).
Fabio,
Is there a TODO list somewhere so we new members can take up tasks from to help you out? This ticket perhaps? It's filed at the Stewardship SIG's pagure project, so I wasn't sure if the Java SIG folks are aware of it yet:
Good Morning!
We were planning to discuss this from the Stewardship SIG point of view during today's meeting, and I didn't want to announce any plans before that.
However, my suggestion would be to do the following things:
1. determine a core set of packages that's required for a functional java → RPM toolchain
This will include ant, maven, some core maven plugins, javapackages-tools, xmvn, and all the dependencies of those packages.
2. start moving those packages into the @java-maint-sig
I'd like to do some basic sanity checks when doing that, for example checking upstream release history, unnecessary dependencies, possiblitiies to drop unused functionality, etc. Most packages that are required for building RPMs from Java projects (maven, maven plugins, plexus-foo, apache-commons-bar, etc.) should already be in pretty good shape and mostly up-to-date.
3. once that basic set of packages has been moved to the SIG, we can start looking at which things share Java packages as dependencies (e.g. glassfish-jaxb is required by both the DogTag PKI team and the Neuro SIG), and move those to the Java SIG as well, if all parties want to do that.
---
I'll try coming up with a roadmap for which packages to move first. I'd like to do this right, so it won't be fast, but I hope we can improve the Java stack in the process.
Fabio
-- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Tue, May 19, 2020 10:44:05 +0200, Fabio Valentini wrote:
<snip>
Good Morning!
We were planning to discuss this from the Stewardship SIG point of view during today's meeting, and I didn't want to announce any plans before that.
However, my suggestion would be to do the following things:
- determine a core set of packages that's required for a functional
java → RPM toolchain
This will include ant, maven, some core maven plugins, javapackages-tools, xmvn, and all the dependencies of those packages.
- start moving those packages into the @java-maint-sig
I'd like to do some basic sanity checks when doing that, for example checking upstream release history, unnecessary dependencies, possiblitiies to drop unused functionality, etc. Most packages that are required for building RPMs from Java projects (maven, maven plugins, plexus-foo, apache-commons-bar, etc.) should already be in pretty good shape and mostly up-to-date.
- once that basic set of packages has been moved to the SIG, we can
start looking at which things share Java packages as dependencies (e.g. glassfish-jaxb is required by both the DogTag PKI team and the Neuro SIG), and move those to the Java SIG as well, if all parties want to do that.
I'll try coming up with a roadmap for which packages to move first. I'd like to do this right, so it won't be fast, but I hope we can improve the Java stack in the process.
Thanks, that sounds great. I look forward to the plan. You're right: there's no need to hurry. Much better to do it right :)
Unfortunately, I have a work meeting that clashes with the stewardship SIG meeting, so I won't make it there today. If the work meeting finishes early, I will pop by to check if the stewardship meeting is still on.
On Tue, May 19, 2020 at 11:19 AM Ankur Sinha sanjay.ankur@gmail.com wrote:
On Tue, May 19, 2020 10:44:05 +0200, Fabio Valentini wrote:
<snip>
Good Morning!
We were planning to discuss this from the Stewardship SIG point of view during today's meeting, and I didn't want to announce any plans before that.
However, my suggestion would be to do the following things:
- determine a core set of packages that's required for a functional
java → RPM toolchain
This will include ant, maven, some core maven plugins, javapackages-tools, xmvn, and all the dependencies of those packages.
- start moving those packages into the @java-maint-sig
I'd like to do some basic sanity checks when doing that, for example checking upstream release history, unnecessary dependencies, possiblitiies to drop unused functionality, etc. Most packages that are required for building RPMs from Java projects (maven, maven plugins, plexus-foo, apache-commons-bar, etc.) should already be in pretty good shape and mostly up-to-date.
- once that basic set of packages has been moved to the SIG, we can
start looking at which things share Java packages as dependencies (e.g. glassfish-jaxb is required by both the DogTag PKI team and the Neuro SIG), and move those to the Java SIG as well, if all parties want to do that.
I'll try coming up with a roadmap for which packages to move first. I'd like to do this right, so it won't be fast, but I hope we can improve the Java stack in the process.
Thanks, that sounds great. I look forward to the plan. You're right: there's no need to hurry. Much better to do it right :)
Unfortunately, I have a work meeting that clashes with the stewardship SIG meeting, so I won't make it there today. If the work meeting finishes early, I will pop by to check if the stewardship meeting is still on.
That would be great. We'll talk about that topic last, then :)
Fabio
-- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Mon, 2020-05-11 at 21:45 +0200, Fabio Valentini wrote:
This past weekend I finally decided to jump off the cliff and attempt to re-launch the Java SIG. It seems there's some interest in keeping the Java stack maintained, it's just not focused or organized right now.
What we did when starting the Stewardship SIG seems to have worked out pretty well, so I'm trying to follow in those footsteps here:
- new proper FAS / pkgdb group: java-maint-sig ("java-sig" is
occupied by an old, unused bot account)
- new private mailing list: java-maint-sig (for RHBZ bugs - so,
possibly, also CVEs - hence, private)
- tracking project on pagure: https://pagure.io/java-maint-sig (for
maintenance scripts, tracking tickets, awesome package dashboards, etc.)
There's already a public fedora mailing list for Java (java-devel), and and IRC channel (#fedora-java on freenode.net), which we will continue to use. Sadly, the existing wiki page for the Java SIG is hopelessly outdated, so I'm tempted to just scrap it and point readers to the pagure tracking project once it's set up beyond a basic README file.
Major upcoming projects for the "new" Java Package Maintainers group include:
- managing OpenJDK 11 / Java 11 transition for hundreds of Java
packages in fedora 33
- starting to transition well-maintained Java packages from the
Stewardship SIG back into Java SIG
- possibly porting packages from gradle to maven to fix build issues
and broken dependencies
- transitioning from old java.net / JavaEE projects to the new ones
now under the eclipse-ee4j umbrella
I know that - among others - the PKI team, Neuro SIG, and Eclipse maintainers depend on parts of the java stack for their packages, so I hope that we can work together with them on these things, as well.
So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list.
Let's make this happen. Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
I'm basically an developer of jee applications. Not sure how much I can assist, but will do whatever I can to help.
fas account: jwhimpel
Thanks for doing this.
On Mon, May 11, 2020 at 1:46 PM Fabio Valentini decathorpe@gmail.com wrote:
So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list.
Like some others who have responded, I probably won't be much help due to lack of time, but since I maintain a handful of Java packages, sign me up too. Thanks for spearheading this!
On Wed, May 13, 2020 at 10:38 PM Jerry James loganjerry@gmail.com wrote:
On Mon, May 11, 2020 at 1:46 PM Fabio Valentini decathorpe@gmail.com wrote:
So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list.
Like some others who have responded, I probably won't be much help due to lack of time, but since I maintain a handful of Java packages, sign me up too. Thanks for spearheading this!
Thanks for joining us! I pushed all the necessary buttons for your group memberships to get set :)
Fabio
-- Jerry James http://www.jamezone.org/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Hello!
I'm new here, but I would like to be part of this group, I have a little knowledge of Java and I think I can be helpful for the group's goals.
Note: I know this thread is old, but I didn't know how to join this group, because this group has no sponsors.
Am 13.09.2021 um 15:41 schrieb Jhordy M. Caceres Guerra jhordy.caceres@outlook.com:
Hello!
I'm new here, but I would like to be part of this group, I have a little knowledge of Java and I think I can be helpful for the group's goals.
Note: I know this thread is old, but I didn't know how to join this group, because this group has no sponsors.
I very much appreciate your initiative. It inspired me to try to ignite a discussion about Empowering Fedora Java on the Java list. Maybe you could contribute.
Very Thank You!
Of course, You can count on me for anything. I'll try to help where I can.
On 9/13/21 8:41 PM, Jhordy M. Caceres Guerra wrote:
Hello!
Hi!
I'm new here, but I would like to be part of this group, I have a little knowledge of Java and I think I can be helpful for the group's goals.
That would be very helpful considering the states of java (packages) in Fedora!
I'm a java packager and I think I can offer you with some guides to begin with your journey, if you want to be a packager, that is.
Feel free to contact me via email or IRC: didiksupriadi41 :)
Note: I know this thread is old, but I didn't know how to join this group, because this group has no sponsors.
See [1].
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Excellent!
This is what I needed, I was thinking of starting as a Java packager, specially for the apache-rat package. I'd like to know your opinion on the package or some (other) recommendation.
-
Aleksandar Kurtakov -
Alex Scheel -
Andrew Haley -
Ankur Sinha -
Christopher Engelhard -
Didik Supriadi -
Fabio Valentini -
Felix Schwarz -
Gerald Henriksen -
Igor Raits -
James Cassell -
Jerry James -
Jhordy Caceres -
Jhordy M. Caceres Guerra
-
John M. Harris Jr -
John W. Himpel -
Kevin Kofler -
Mamoru TASAKA -
Markku Korkeala -
Michael Catanzaro -
Michal Srb -
Neal Gompa -
Nico Kadel-Garcia -
Nicolas Mailhot -
Omair Majid -
Peter Boy -
Philip Rhoades -
Robbie Harwood -
Samuel Sieb -
Severin Gehwolf -
Solomon Peachy -
stan -
Ty Young -
Vitaly Zaitsev -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek