Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.maint.java > #12823 > unrolled thread
| Started by | Julien Plissonneau Duquène <sre4ever@free.fr> |
|---|---|
| First post | 2024-11-04 14:50 +0100 |
| Last post | 2024-11-27 09:30 +0100 |
| Articles | 20 on this page of 70 — 8 participants |
Back to article view | Back to linux.debian.maint.java
gradle reboot Julien Plissonneau Duquène <sre4ever@free.fr> - 2024-11-04 14:50 +0100
Re: gradle reboot Jérôme Charaoui <jerome@riseup.net> - 2024-11-04 15:10 +0100
Re: gradle reboot Toni Mueller <toni@debian.org> - 2024-11-04 17:00 +0100
Re: gradle reboot sre4ever@free.fr - 2024-11-19 11:10 +0100
Re: gradle reboot -- 2024W47 update sre4ever@free.fr - 2024-11-22 18:30 +0100
Re: gradle reboot -- 2024W48 update sre4ever@free.fr - 2024-12-02 19:50 +0100
Re: gradle reboot -- 2024W49 update sre4ever@free.fr - 2024-12-09 12:10 +0100
Re: gradle reboot -- 2024W49 update Emmanuel Bourg <ebourg@apache.org> - 2024-12-09 14:40 +0100
Re: gradle reboot -- 2024W49 update sre4ever@free.fr - 2024-12-09 19:00 +0100
Re: gradle reboot -- 2024W49 update Hans-Christoph Steiner <hans@at.or.at> - 2024-12-09 19:20 +0100
Re: gradle reboot -- 2024W49 update sre4ever@free.fr - 2024-12-10 10:40 +0100
Re: gradle reboot -- 2024W49 update Matthias Klose <doko@debian.org> - 2024-12-14 10:50 +0100
Re: gradle reboot -- 2024W49 update sre4ever@free.fr - 2024-12-14 11:50 +0100
Re: gradle reboot -- 2024W49 update Matthias Klose <doko@debian.org> - 2024-12-14 13:20 +0100
Re: gradle reboot -- 2024W50 update sre4ever@free.fr - 2024-12-13 19:40 +0100
Re: gradle reboot -- 2024W50 update Emmanuel Bourg <ebourg@apache.org> - 2024-12-14 00:40 +0100
gradle: FI -- reverse dependencies that FTBFS sre4ever@free.fr - 2024-12-17 12:00 +0100
Re: gradle: FI -- reverse dependencies that FTBFS Emmanuel Bourg <ebourg@apache.org> - 2024-12-18 10:00 +0100
Re: gradle reboot -- 2024W51 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2024-12-20 19:20 +0100
Re: gradle reboot -- 2025W02 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-01-10 19:30 +0100
Re: gradle reboot -- 2025W03 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-01-17 19:30 +0100
Re: gradle reboot -- 2025W04 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-01-24 19:20 +0100
Re: gradle reboot -- 2025W04 update Hans-Christoph Steiner <hans@at.or.at> - 2025-01-27 17:10 +0100
Re: gradle reboot -- 2025W04 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-01-27 19:30 +0100
Re: gradle reboot -- 2025W05 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-01-31 19:10 +0100
gradle reboot -- 2025W06 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-02-07 19:50 +0100
gradle reboot -- 2025W07 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-02-14 20:10 +0100
Re: gradle reboot -- 2025W07 update Hans-Christoph Steiner <hans@at.or.at> - 2025-02-19 08:00 +0100
Re: gradle reboot -- 2025W07 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-02-19 09:50 +0100
gradle reboot -- 2025W08 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-02-21 18:20 +0100
gradle reboot -- 2025W09 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-02-28 20:30 +0100
gradle reboot -- 2025W10 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-03-07 18:50 +0100
Re: gradle reboot -- 2025W10 update Emmanuel Bourg <ebourg@apache.org> - 2025-03-10 18:50 +0100
Re: gradle reboot -- 2025W10 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-03-10 19:10 +0100
gradle reboot -- 2025W11 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-03-14 19:50 +0100
gradle reboot -- 2025W12 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-03-21 19:00 +0100
kotlin2 in Debian -- 2025W13 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-03-28 20:00 +0100
Re: kotlin2 in Debian -- 2025W13 update Emmanuel Bourg <ebourg@apache.org> - 2025-03-29 12:40 +0100
Re: kotlin2 in Debian -- 2025W13 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-03-29 13:50 +0100
kotlin2 in Debian -- 2025W14 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-04-04 21:00 +0200
kotlin2 in Debian -- 2025W15 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-04-11 14:20 +0200
kotlin2 in Debian -- 2025W16 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-04-18 19:50 +0200
kotlin2 in Debian -- 2025W17 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-04-25 22:10 +0200
kotlin2 in Debian -- 2025W18 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-05-02 19:50 +0200
Re: kotlin2 in Debian -- 2025W18 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-05-06 18:40 +0200
kotlin2 in Debian -- 2025W19 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-05-09 22:20 +0200
kotlin2 in Debian -- 2025W20 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-05-18 13:50 +0200
kotlin2 in Debian -- 2025W21 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-05-23 20:10 +0200
kotlin2 in Debian -- 2025W22 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-05-30 20:50 +0200
kotlin2 in Debian -- 2025W23 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-06-07 19:20 +0200
kotlin2 in Debian -- 2025W24 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-06-14 19:10 +0200
kotlin2 in Debian -- 2025W25 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-06-20 20:00 +0200
Re: kotlin2 in Debian -- 2025W26 and W27 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-07-01 17:00 +0200
kotlin2 in Debian -- 2025W28 to W30 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-07-27 23:00 +0200
kotlin2 in Debian -- 2025W31 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-08-03 22:00 +0200
kotlin2 in Debian -- 2025W32 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-08-11 00:10 +0200
kotlin2 in Debian -- 2025W33 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-08-16 15:40 +0200
kotlin2 in Debian -- 2025W34 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-08-24 17:50 +0200
kotlin2 in Debian -- 2025W35 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-09-01 21:30 +0200
kotlin2 in Debian -- 2025W36 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-09-07 21:50 +0200
kotlin2 in Debian -- 2025W37 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-09-15 14:30 +0200
kotlin2 in Debian -- 2025W38 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-09-22 15:50 +0200
Re: kotlin2 in Debian -- 2025W39-W41 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-10-12 23:10 +0200
Re: kotlin2 in Debian -- 2025W39-W41 update Hans-Christoph Steiner <hans@at.or.at> - 2025-10-31 12:10 +0100
Re: kotlin2 in Debian -- 2025W39-W41 update Bastien Roucaries <rouca@debian.org> - 2026-02-15 20:00 +0100
Re: kotlin2 in Debian -- 2025W23 update Emmanuel Bourg <ebourg@apache.org> - 2025-06-16 15:50 +0200
Re: kotlin2 in Debian -- 2025W23 update Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-06-20 21:30 +0200
Re: gradle reboot Emmanuel Bourg <ebourg@apache.org> - 2024-11-08 00:30 +0100
Re: gradle reboot Hans-Christoph Steiner <hans@at.or.at> - 2024-11-26 13:40 +0100
Re: gradle reboot sre4ever@free.fr - 2024-11-27 09:30 +0100
Page 1 of 4 [1] 2 3 4 Next page →
| From | Julien Plissonneau Duquène <sre4ever@free.fr> |
|---|---|
| Date | 2024-11-04 14:50 +0100 |
| Subject | gradle reboot |
| Message-ID | <JF5CV-6zL6-3@gated-at.bofh.it> |
Hi, This is to let you know that I am currently working on overhauling and upgrading the gradle package to the upcoming 8.11 release. This is indeed quite challenging and I am not yet to the point where I could share a repo and let others experiment and contribute, but I hope to get there in a few days or maybe next week, I will then post an update with a link. My current plan is to make it at least a 2-stage build as there is no point in trying to make its complicated buildscript work with the currently packaged version 4.4.1. I don't know yet if the versions of Groovy and Kotlin currently in Debian will work with these builds but I will try. I am also factoring in the gradle-debian-helper in the build of Gradle itself to use its logic to resolve artifact versions, even though the plugin can no longer be used as is because it depends on a core 'maven' plugin that disappeared with Gradle 7. About myself, I haven't contributed much to the project yet but I am a long time FLOSS advocate and Debian user, with some background in large scale deployments, SRE and DevOps things. I didn't have much prior experience with Gradle until the past few days, so I am learning while doing it. Regards, -- Julien Plissonneau Duquène
[toc] | [next] | [standalone]
| From | Jérôme Charaoui <jerome@riseup.net> |
|---|---|
| Date | 2024-11-04 15:10 +0100 |
| Message-ID | <JF5Wh-6A6Y-1@gated-at.bofh.it> |
| In reply to | #12823 |
Hi Julien, Le 2024-11-04 à 08 h 43, Julien Plissonneau Duquène a écrit : > This is to let you know that I am currently working on overhauling and > upgrading the gradle package to the upcoming 8.11 release. This is > indeed quite challenging and I am not yet to the point where I could > share a repo and let others experiment and contribute, but I hope to get > there in a few days or maybe next week, I will then post an update with > a link. Thank you for working on this. As you probably know, Gradle has been a major pain point in Debian for a while now. I would simply like to suggest, please don't aim for perfection: an "80%-good" solution would be a great improvement already. And if for whatever reason your efforts don't bear fruit, please document your work and the challenges you faced, so that others may more easily pick up where you left off. Thanks again, -- Jérôme
[toc] | [prev] | [next] | [standalone]
| From | Toni Mueller <toni@debian.org> |
|---|---|
| Date | 2024-11-04 17:00 +0100 |
| Message-ID | <JF7EJ-6AWq-5@gated-at.bofh.it> |
| In reply to | #12823 |
Hi Julien, On Mon, Nov 04, 2024 at 02:43:08PM +0100, Julien Plissonneau Duquène wrote: > This is to let you know that I am currently working on overhauling and > upgrading the gradle package to the upcoming 8.11 release. This is indeed I was also looking into this a few days ago, but I am not a Java programmer at all. However, I would suggest to make a "gradle8" package that could be installed in parallel with the existing Gradle. The benefit is that the new package doesn't need to be feature-complete, and can even (initially) have a higher bug-tolerance while keeping everything running as-is for the time being. These are just my 0.02 cents, and this is where I was trying to go. I also found that downloading the "source" package from the website is probably not a good idea, and went for the Github repository instead, after finding lots of .class files in the "source" repository and getting the impression that some bits might be missing. Questions and comments welcome! Cheers, Toni
[toc] | [prev] | [next] | [standalone]
| From | sre4ever@free.fr |
|---|---|
| Date | 2024-11-19 11:10 +0100 |
| Message-ID | <JKtlf-9Y9a-1@gated-at.bofh.it> |
| In reply to | #12825 |
Good morning,
Le 2024-11-04 16:53, Toni Mueller a écrit :
> getting the impression that some bits might be missing.
Well you were right, there are many missing files [1] in the
distribution ZIPs, mostly documentation and testing though. I reported
that and got no reaction so far. I've updated d/watch in my branches to
use the GitHub releases from now on.
I've sanitized and imported the new releases sources and pushed the
current state of my work, still very rough, to Salsa [2]. There is
currently a regression compared to two weeks ago as I'm currently unable
to get the build to start compiling the project, it hangs in a
configuration stage. Currently investigating why, this is probably
related to some missing dependency.
MRs already opened are:
- that one [3] with configuration changes for repacking the source for
4.4.1 and preparing for imports, and also patches Gradle 4.4.1 so you
can use it to build libnative-platform-java
- these [4] for importing the new releases.
Comments, feedback and help welcome as usual.
Cheers,
[1]:
https://salsa.debian.org/jpd/gradle/-/blob/upgrade-to-8.11-wip/debian/wip/delta-ghtar-gradlezip
[2]:
https://salsa.debian.org/jpd/gradle/-/blob/upgrade-to-8.11-wip/debian/wip/README.md
[3]: https://salsa.debian.org/java-team/gradle/-/merge_requests/7
[4]: https://salsa.debian.org/java-team/gradle/-/merge_requests/8
https://salsa.debian.org/java-team/gradle/-/merge_requests/9
https://salsa.debian.org/java-team/gradle/-/merge_requests/10
--
Julien Plissonneau Duquène
[toc] | [prev] | [next] | [standalone]
| From | sre4ever@free.fr |
|---|---|
| Date | 2024-11-22 18:30 +0100 |
| Subject | Re: gradle reboot -- 2024W47 update |
| Message-ID | <JLFDH-aLaT-1@gated-at.bofh.it> |
| In reply to | #12831 |
Good evening, Some news from this adventure: Le 2024-11-19 11:04, sre4ever@free.fr a écrit : > There is currently a regression compared to two weeks ago as I'm > currently unable to get the build to start compiling the project, it > hangs in a configuration stage. Currently investigating why I found out what triggered the issue, which was a combination of incomplete dependencies fixes/removals that missed the missing sources (still following?) newly imported (mostly testing code) and --write-verification-metadata being prone to deadlocks after errors happened in the configuration stage, which is probably worth a bug report upstream if I manage to craft a less exotic reproducer. Not getting any clue about what was wrong was frustrating to say the least, I had to debug the thing with jdb to figure that out. Now the build starts again, does not complain anymore about libnative-platform-java after an updated package was installed, and fails against another outdated lib, details are on the updated README there [1] I haven't received a lot of feedback (as in: none) from this list about what is in my repos yet, but that's still very welcome and encouraged ;) Next week I will start working on a detailed action plan and PoC for the rebootstrap, in between build runs and fixups. Have a nice week-end, [1]: https://salsa.debian.org/jpd/gradle/-/blob/upgrade-to-8.11.1-wip/debian/wip/README.md -- Julien Plissonneau Duquène
[toc] | [prev] | [next] | [standalone]
| From | sre4ever@free.fr |
|---|---|
| Date | 2024-12-02 19:50 +0100 |
| Subject | Re: gradle reboot -- 2024W48 update |
| Message-ID | <JPjEB-dgGI-5@gated-at.bofh.it> |
| In reply to | #12832 |
Good evening, Le 2024-11-22 18:25, sre4ever@free.fr a écrit : > Next week I will start working on a detailed action plan and PoC for > the rebootstrap, in between build runs and fixups. Updating and then fixing the builds of various packages (not all of them direct dependencies of Gradle) kept me busier than expected, and thus the writing hasn't progressed much, though the reading and the thinking have. I added a bunch of links to the bottom of wip/README [1] if you are interested, and commented on a few GitHub issues for some shameless self-advertising. The build progressed a bit and now fails on the outdated Groovy; my current plan is to attempt to patch Gradle to make it build with the version currently in Debian, and make it work at least enough to be able to rebuild both Gradle itself and newer versions of Groovy with it. I also plan to patch Gradle 4.4.1 to make it work with the newer libkryo-java (that should be rather trivial) and libnative-platform-java and -jni (easy enough at first sight), to make the transition easier. I attempted the reverse (patching libraries to implement retrocompatibility) but that's not possible at least with kryo that changed return types of methods keeping the same names and argument types. I managed to get IDEA to sync the patched project now without errors and even in offline mode, which should help me with further patching deep into the internals of the beast, and you now have a shiny new debian/rules target to help you if you want to try that at home. Dependencies and reverse dependencies are now detailed in their own wip/document.md, that was a fairly tedious job for the dependencies but hopefully worth it, it allowed me to fix a few mistakes and learn a few things about Kotlin. There are actually much fewer direct dependencies than I thought initially, and also more of them that are up-to-date than I thought. I registered on mentors.debian.net and published packages there [2] (though I haven't uploaded all of them yet) if you want to try them without rebuilding, leave a review or, if you dare, upload the new `kryo` that currently breaks all two of its two reverse dependencies to experimental ^ ^. As usual, comments and contributions are welcome. Cheers, [1]: https://salsa.debian.org/jpd/gradle/-/blob/upgrade-to-8.11.1-wip/debian/wip/README.md [2]: https://mentors.debian.net/packages/uploader/sre4ever@free.fr/ -- Julien Plissonneau Duquène
[toc] | [prev] | [next] | [standalone]
| From | sre4ever@free.fr |
|---|---|
| Date | 2024-12-09 12:10 +0100 |
| Subject | Re: gradle reboot -- 2024W49 update |
| Message-ID | <JRJOh-fncQ-3@gated-at.bofh.it> |
| In reply to | #12846 |
Good day,
Some news about the ongoing work on Gradle packaging:
Le 2024-12-02 19:43, sre4ever@free.fr a écrit :
> The build progressed a bit and now fails on the outdated Groovy
Last week the build progressed some more and now (using --continue)
generates 78 of the 83 (86 minus 3 dropped) jars that are expected in
the binary distribution (that's almost 94%). Some Groovy issues were
solved by copypasting some newer Groovy source code right into the
project; that's indeed temporary and only necessary until Groovy gets
updated, and I plan to take care of that right after Gradle.
Now the build fails on Kotlin issues. These are going to be tougher
(getting it to build is one thing, getting it to actually work is
another thing) and my current plan to try to use the version that is
currently in Debian is likely to be a dead end for reasons already
stated on this list. I already had to drop the new declarative DSL as it
is not (yet?) needed for rebuilding Gradle (I didn't check for Kotlin
though) and makes use of many new features that were possibly added to
Kotlin as part of the collaboration between Gradle and JetBrains. What
remain are the regular kotlin-dsl and some parts of core-configuration
written in Kotlin, which are all necessary for core features and
rebuilding both Gradle and Kotlin.
I will see this week how far I can go with this plan. The alternative
would be to upgrade Kotlin at the same time, with similar (but a bit
more complicated) bootstrapping techniques.
Which brings us to the crucial subject of bootstrapping: I now have a
(non-functional) PoC of how I plan to proceed, which is basically to
make it possible to rebuild Gradle with a plain old Makefile [1],
automatically generated from Gradle build scripts, to be updated with
every new release and committed to the repository as part of the
packaging sources. For the rebootstrap this would go as follows
(assuming that all issues that would prevent Gradle from working are
already resolved):
- maintainer uses a binary distribution of Gradle from upstream to build
a first-stage patched Gradle and to generate the Makefile; that build
will not be used and is only necessary to correctly generate the
Makefile
- maintainer rebuilds a first stage patched Gradle using the Makefile
- maintainer builds a second stage patched Gradle using the
Makefile-built Gradle, check that it works (test suites), check that it
generates the same Makefile as the binary distribution, eventually
checks and investigates for differences in binaries against the
first-stage build with binary distribution
- maintainer commits packaging updates
- for the CI (or anybody else after the package is published) to rebuild
the package, debian/rules checks the version of Gradle that is currently
installed on the system; if the version is not known (i.e. successfully
tested) to be compatible (and this is probably going to be a very
restricted set of versions close to the one being built), d/rules will
build a first-stage Gradle using the pre-generated Makefile, then
(re)build the target Gradle using a temporary installation of the
first-stage Gradle.
As usual, comments and contributions are very welcome.
Cheers,
[1]:
https://salsa.debian.org/jpd/gradle/-/blob/upgrade-to-8.11.1-wip/debian/gradle.Makefile
— this Makefile is not useable as is, but you get the idea
--
Julien Plissonneau Duquène
[toc] | [prev] | [next] | [standalone]
| From | Emmanuel Bourg <ebourg@apache.org> |
|---|---|
| Date | 2024-12-09 14:40 +0100 |
| Subject | Re: gradle reboot -- 2024W49 update |
| Message-ID | <JRM9r-fqmE-3@gated-at.bofh.it> |
| In reply to | #12848 |
Le 09/12/2024 à 12:08, sre4ever@free.fr a écrit : > As usual, comments and contributions are very welcome. Sounds good so far. Regarding the bootstrapping, once the initial version is uploaded I don't think we should try too hard to keep the bootstrapping logic in the package, that'll most certainly be tedious to maintain over time. Emmanuel Bourg
[toc] | [prev] | [next] | [standalone]
| From | sre4ever@free.fr |
|---|---|
| Date | 2024-12-09 19:00 +0100 |
| Subject | Re: gradle reboot -- 2024W49 update |
| Message-ID | <JRQd3-fuLl-5@gated-at.bofh.it> |
| In reply to | #12849 |
Le 2024-12-09 14:32, Emmanuel Bourg a écrit :
>
> I don't think we should try too hard to keep the bootstrapping logic in
> the package, that'll most certainly be tedious to maintain over time.
Well that's indeed something to think about, and I am a bit worried
about that as well. With Gradle, the work necessary to maintain the
bootstrapping in working condition will have to be weighted against the
work necessary to patch and downgrade the build scripts to make them
work with a previous release, which may or may not be that easy
depending on feature gaps between Gradle releases.
Gradle authors made it pretty clear that they actively upgrade Gradle
build scripts to use the latest features available (aka "dogfooding").
Even if Debian maintainers managed to ship every Gradle final release,
new majors releases were so far never built with a final release, but
rather pre-releases or snapshots of the new major release [1]. This also
happens for minor releases, though changes in build scripts are less
drastic and some minor releases are probably (untested so far but worth
testing) going to build with some previous releases.
AFAIK the current Debian Policy doesn't say much about bootstrapping
build tools i.e. which exceptions to the usual rules might be admissible
or not in these cases. Fedora provides some guidelines [2] [3] that seem
reasonable. My personal opinion is that making such tools bootstrappable
would be a good practice, but that it's ultimately the job of the
upstream developers to provide the means to bootstrap their products. It
has always been (AFAIK) possible to build GNU Make without GNU Make.
Their authors now make it possible to build GNU Make without any "make"
at all [4]. It is almost possible to build SBT without SBT [5].
Unfortunately the feedback we've got from Gradle leads so far is that
they don't care much about that issue.
But I would leave it to the maintainer of the day to decide whether they
want to maintain the bootstrapping in working condition or not. I
promise not to bark and bite if they don't ^ ^. Though I think that even
if the tool breaks at some point, keeping the parts around in the
toolbox just in case they are needed again later would be wise.
That said, I'm actually marginally outdoing the Gradle folks with my
approach as I assume that any release will be buildable by the same
release, which may not always be true, and I would not be surprised if
Gradle authors stated at some point that it is not among their goals,
but it's much more convenient to assume that and I believe that this is
going to work most of the time with no (or little) changes.
[1]: https://salsa.debian.org/-/snippets/756
[2]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_exceptions
[3]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
[4]: https://git.savannah.gnu.org/cgit/make.git/tree/bootstrap
[5]:
https://github.com/sbt/sbt/blob/1.10.x/DEVELOPING.md#running-sbt-from-source---sbton
— spoiler, as the wishlist season is officially opened: I added
"package SBT" on my to-do list for 2025.
--
Julien Plissonneau Duquène
[toc] | [prev] | [next] | [standalone]
| From | Hans-Christoph Steiner <hans@at.or.at> |
|---|---|
| Date | 2024-12-09 19:20 +0100 |
| Subject | Re: gradle reboot -- 2024W49 update |
| Message-ID | <JRQwp-fv7I-9@gated-at.bofh.it> |
| In reply to | #12850 |
sre4ever@free.fr: > Le 2024-12-09 14:32, Emmanuel Bourg a écrit : >> >> I don't think we should try too hard to keep the bootstrapping logic in the >> package, that'll most certainly be tedious to maintain over time. > > Well that's indeed something to think about, and I am a bit worried about that > as well. With Gradle, the work necessary to maintain the bootstrapping in > working condition will have to be weighted against the work necessary to patch > and downgrade the build scripts to make them work with a previous release, which > may or may not be that easy depending on feature gaps between Gradle releases. > > Gradle authors made it pretty clear that they actively upgrade Gradle build > scripts to use the latest features available (aka "dogfooding"). Even if Debian > maintainers managed to ship every Gradle final release, new majors releases were > so far never built with a final release, but rather pre-releases or snapshots of > the new major release [1]. This also happens for minor releases, though changes > in build scripts are less drastic and some minor releases are probably (untested > so far but worth testing) going to build with some previous releases. > > AFAIK the current Debian Policy doesn't say much about bootstrapping build tools > i.e. which exceptions to the usual rules might be admissible or not in these > cases. Fedora provides some guidelines [2] [3] that seem reasonable. My personal > opinion is that making such tools bootstrappable would be a good practice, but > that it's ultimately the job of the upstream developers to provide the means to > bootstrap their products. It has always been (AFAIK) possible to build GNU Make > without GNU Make. Their authors now make it possible to build GNU Make without > any "make" at all [4]. It is almost possible to build SBT without SBT [5]. > Unfortunately the feedback we've got from Gradle leads so far is that they don't > care much about that issue. > > But I would leave it to the maintainer of the day to decide whether they want to > maintain the bootstrapping in working condition or not. I promise not to bark > and bite if they don't ^ ^. Though I think that even if the tool breaks at some > point, keeping the parts around in the toolbox just in case they are needed > again later would be wise. > > That said, I'm actually marginally outdoing the Gradle folks with my approach as > I assume that any release will be buildable by the same release, which may not > always be true, and I would not be surprised if Gradle authors stated at some > point that it is not among their goals, but it's much more convenient to assume > that and I believe that this is going to work most of the time with no (or > little) changes. > > > [1]: https://salsa.debian.org/-/snippets/756 > [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be- > packaged/#_exceptions > [3]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping > [4]: https://git.savannah.gnu.org/cgit/make.git/tree/bootstrap > [5]: https://github.com/sbt/sbt/blob/1.10.x/DEVELOPING.md#running-sbt-from- > source---sbton > — spoiler, as the wishlist season is officially opened: I added "package > SBT" on my to-do list for 2025. I also think that your bootstrapping plan sounds good. And I second that I don't think it is so important to maintain the bootstrapping Makefile. It'll always be in git for anyone who wants to go back to it. I think it would be fine to keep in place, as long as the workflow is documented, e.g. the bootstrapping is not required to be maintained, but it would be nice to have. .hc
[toc] | [prev] | [next] | [standalone]
| From | sre4ever@free.fr |
|---|---|
| Date | 2024-12-10 10:40 +0100 |
| Subject | Re: gradle reboot -- 2024W49 update |
| Message-ID | <JS4SJ-fMdf-1@gated-at.bofh.it> |
| In reply to | #12851 |
Le 2024-12-09 19:17, Hans-Christoph Steiner a écrit : > I think it would be fine to keep in place, as long as the workflow is > documented, e.g. the bootstrapping is not required to be maintained, > but it would be nice to have. It's probably not as complicated to maintain as it may look right now, let me give some details about how I see future maintainer work wrt/ this. The makefile is automatically generated by a new "makeMakefile" gradle task that is added by the custom plugin. My goal is to make it work as generated with no further postprocessing, especially no manual editing. It is only intended to (re)build the version of Gradle from which is was generated, as a fallback method for a first stage build if the Gradle currently installed on the system is not usable for the build. IOW it's there to prevent some FTBFS cases. When importing a new Gradle release: - either the build succeeds out of the box with the version of Gradle currently installed on the system. In that case the Makefile will be automatically updated as part of a manual build of the package (the task would be skipped by default if the makefile version matches the package version). The maintainer only has to commit it as part of packaging updates. - or the system Gradle fails to build the new release. In that case the maintainer has basically two choices: either downgrade the build scripts to make them work with the system Gradle, and then they are back to the same situation as above, or go through the bootstrap process again, and in that case a new Makefile will be generated and used as part of the bootstrap process. Of course all of this is going to be documented, and I'm also planning to automate the bootstrap process (download the binary dist and dependencies, setup a temporary installation, first stage builds etc). Testing that the Makefile fallback actually works could be done by the maintainer, but I think it would be more convenient to delegate that to some custom CI pipeline on Salsa that is allowed to fail so the maintainer won't be blocked to proceed with an upgrade if that's the only thing that breaks. And if that's the makeMakefile task that breaks, which I think is less likely than future issues with the rest of the custom build logic, they can just comment out the bits in debian/rules if they don't want to fix it. Cheers, -- Julien Plissonneau Duquène
[toc] | [prev] | [next] | [standalone]
| From | Matthias Klose <doko@debian.org> |
|---|---|
| Date | 2024-12-14 10:50 +0100 |
| Subject | Re: gradle reboot -- 2024W49 update |
| Message-ID | <JTwWB-gWHj-5@gated-at.bofh.it> |
| In reply to | #12850 |
On 09.12.24 18:56, sre4ever@free.fr wrote: > Le 2024-12-09 14:32, Emmanuel Bourg a écrit : >> >> I don't think we should try too hard to keep the bootstrapping logic >> in the package, that'll most certainly be tedious to maintain over time. > > Well that's indeed something to think about, and I am a bit worried > about that as well. With Gradle, the work necessary to maintain the > bootstrapping in working condition will have to be weighted against the > work necessary to patch and downgrade the build scripts to make them > work with a previous release, which may or may not be that easy > depending on feature gaps between Gradle releases. what about having two sets of packages? one set encapsulating the bootstrap, which always stays in unstable, and one "production" set, which then migrates to testing? Would that be better to keep the bootstrap knowledge up to date? Matthias
[toc] | [prev] | [next] | [standalone]
| From | sre4ever@free.fr |
|---|---|
| Date | 2024-12-14 11:50 +0100 |
| Subject | Re: gradle reboot -- 2024W49 update |
| Message-ID | <JTxSF-gXfg-3@gated-at.bofh.it> |
| In reply to | #12855 |
Le 2024-12-14 10:48, Matthias Klose a écrit : > > what about having two sets of packages? one set encapsulating the > bootstrap, which always stays in unstable, and one "production" set, > which then migrates to testing? Would that be better to keep the > bootstrap knowledge up to date? That's a possibility, though I would keep them in the same repo and manage them using branches, and maybe keep the bootstrap packages only in experimental. We are going to need branches to maintain the gradleN packages anyway (only support and no opposition so far for renaming to gradleN, so we are going this way). But I think having the makefile as a backup build method even in production is worth considering, as it's very likely that without it some upgrades will require much more work to downgrade their build scripts so they work with the currently packaged version, if that's possible at all. It also sort of breaks the circular dependency, and I think that's good practice. Cheers, -- Julien Plissonneau Duquène
[toc] | [prev] | [next] | [standalone]
| From | Matthias Klose <doko@debian.org> |
|---|---|
| Date | 2024-12-14 13:20 +0100 |
| Subject | Re: gradle reboot -- 2024W49 update |
| Message-ID | <JTzhL-gYdu-5@gated-at.bofh.it> |
| In reply to | #12856 |
On 14.12.24 11:49, sre4ever@free.fr wrote: > Le 2024-12-14 10:48, Matthias Klose a écrit : >> >> what about having two sets of packages? one set encapsulating the >> bootstrap, which always stays in unstable, and one "production" set, >> which then migrates to testing? Would that be better to keep the >> bootstrap knowledge up to date? > > That's a possibility, though I would keep them in the same repo and > manage them using branches, and maybe keep the bootstrap packages only > in experimental. experimental is fine, as long as there are no architecture dependent packages involved. re-bootstrapping then in unstable is a pain.
[toc] | [prev] | [next] | [standalone]
| From | sre4ever@free.fr |
|---|---|
| Date | 2024-12-13 19:40 +0100 |
| Subject | Re: gradle reboot -- 2024W50 update |
| Message-ID | <JTiJX-gGym-1@gated-at.bofh.it> |
| In reply to | #12848 |
Good evening, Here is a quick report about the (little) progress made this week. Le 2024-12-09 12:08, sre4ever@free.fr a écrit : > Now the build fails on Kotlin issues. And now I'm stuck on the (re)build of Kotlin 1.3.31 that currently FTBFS [1]. > I will see this week how far I can go with this plan. Not very far indeed, as was expected: I quickly realized that Gradle now depends on APIs that were introduced with Kotlin 1.3.50, not much later than the current Debian version. After downloading the ~4GiB Kotlin git repo (and running git gc --aggressive to claim back over 2 GiB) I tried to figure out if backporting some code from that version into Kotlin 1.3.31 could work by copypasting the relevant parts of Kotlin sources into the Gradle project, just prefixing the package names as I did with Groovy. At some point I faced a wall: some of these parts are not in the repo, as they are generated during the build of Kotlin (protobuf etc). That got me into rebuilding the Kotlin package, which I haven't achieved so far. I started from what's in the `master` branch with the patches of Vladimir Petko to rebuild with Java 21, repatched to rebuild with Java 11 as the installed Kotlin compiler won't run with Java 21, and then got stuck on errors [2] that don't make sense to me, especially that one: > error: type mismatch: inferred type is > org.jetbrains.org.objectweb.asm.tree.MethodNode but MethodNode! was > expected I also tried to rebuild the last published tag but it fails on the same error. To me, it looks like either a name clash with two different versions of the class (but I can't figure out what/where the other version could be), or a compiler bug. Unless someone here could give me some clue about what's going on, I will probably have to dive into some jdb debugging session, as IDEA won't sync/build/debug/highlight the project due to the outdated Gradle. Anyway, the current plan for next week is still to fix the Kotlin build, or maybe decompile pregenerated classes, and try to figure out whether a backport of the necessary APIs is reasonably achievable. RFS: is any DD from the Java Team willing to act as a sponsor for a few weeks to proceed with the reviews and uploads to experimental and unstable? (if not I would have to file a RFS bug) Also would you allow me into the java group on Salsa so I can start working directly on some repos? Cheers, [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057513 [2]: http://paste.debian.net/1339720/ -- Julien Plissonneau Duquène
[toc] | [prev] | [next] | [standalone]
| From | Emmanuel Bourg <ebourg@apache.org> |
|---|---|
| Date | 2024-12-14 00:40 +0100 |
| Subject | Re: gradle reboot -- 2024W50 update |
| Message-ID | <JTnqh-gMTN-5@gated-at.bofh.it> |
| In reply to | #12853 |
Le 13/12/2024 à 19:31, sre4ever@free.fr a écrit : > That got me into rebuilding the Kotlin package, which I haven't achieved > so far. I started from what's in the `master` branch with the patches of > Vladimir Petko to rebuild with Java 21, repatched to rebuild with Java > 11 as the installed Kotlin compiler won't run with Java 21, and then got > stuck on errors [2] that don't make sense to me, especially that one: > >> error: type mismatch: inferred type is >> org.jetbrains.org.objectweb.asm.tree.MethodNode but MethodNode! was >> expected I tried building kotlin this week and stumbled on the same issue. Tweaking the signature of the abstract method and/or its implementations didn't work. I'm thinking about rebuilding a clean kotlin package in bookworm with the Java 21 patches and then uploading it to unstable to get out of this. > RFS: is any DD from the Java Team willing to act as a sponsor for a few > weeks to proceed with the reviews and uploads to experimental and > unstable? (if not I would have to file a RFS bug) I can review your changes. Don't bother with the RFS, you can open PRs on Salsa and ping us here. Emmanuel Bourg
[toc] | [prev] | [next] | [standalone]
| From | sre4ever@free.fr |
|---|---|
| Date | 2024-12-17 12:00 +0100 |
| Subject | gradle: FI -- reverse dependencies that FTBFS |
| Message-ID | <JUDsZ-cB5-13@gated-at.bofh.it> |
| In reply to | #12853 |
Hi, For information: Yesterday I tried to rebuild (on trixie) the 110 identified source packages that depend on Gradle. That kept my low-end, second-hand laptop busy for about 5 hours. Most packages (102, ~93%) were rebuilt without issues. The 8 packages that failed to build OOTB were: 1. android-framework-23 2. android-platform-external-doclava 3. android-platform-tools-base 4. gradle-kotlin-dsl 5. kotlin 6. kotlinx-atomicfu 7. kotlinx-coroutines 8. zeroc-ice #1 and #2 already had FTBFS bugs unresolved since 2022, are severely outdated and their former uploader is not listed as a DD anymore (he requested to be removed as uploader of several packages in 2022 but is still listed in a few ones, these would require some final cleanup). These packages need a full overhaul and are not worth fixing in their current state so we can ignore them for now. #3 has a FTBFS bug unresolved since Aug 2024, is also severely outdated (2017), and overall same verdict as above. #4 to #7 fail because the current Kotlin compiler won't run with Java 21 (class files version 65). I'm currently working on this as part of the Kotlin 1.3.31 rebuild issue. #8 failed because it depends on an updated PHP that was not yet in testing. It succeeded after manually installing the required dependency. The good news here is that right now nothing (else) needs to be fixed to rebuild with the current Gradle 4.4.1. Cheers, -- Julien Plissonneau Duquène
[toc] | [prev] | [next] | [standalone]
| From | Emmanuel Bourg <ebourg@apache.org> |
|---|---|
| Date | 2024-12-18 10:00 +0100 |
| Subject | Re: gradle: FI -- reverse dependencies that FTBFS |
| Message-ID | <JUY4p-rS6-1@gated-at.bofh.it> |
| In reply to | #12858 |
Le 17/12/2024 à 11:54, sre4ever@free.fr a écrit : > android-platform-tools-base has a FTBFS bug unresolved since Aug 2024, > is also severely outdated(2017), and overall same verdict as above. Kotlin depends on libgradle-android-plugin-java which is built by android-platform-tools-base, we can't remove it. Emmanuel Bourg
[toc] | [prev] | [next] | [standalone]
| From | Julien Plissonneau Duquène <sre4ever@free.fr> |
|---|---|
| Date | 2024-12-20 19:20 +0100 |
| Subject | Re: gradle reboot -- 2024W51 update |
| Message-ID | <JVPLr-19Tm-9@gated-at.bofh.it> |
| In reply to | #12853 |
Good evening, Not much progress was made on Gradle this week: Le 2024-12-13 19:31, sre4ever@free.fr a écrit : > now I'm stuck on the (re)build of Kotlin 1.3.31 that currently FTBFS I'm still there. I managed to use IDEA CE's debugger instead of jdb which helps a lot and narrowed down the issue to some subtle failure in class resolution that could happen either in Kotlin code or in libintellij-core-java or both, but I haven't nailed it yet, though I think I'm getting close. The trip deep inside the compiler internals is interesting but it requires a lot of patience and focus as the internal code is rather scarcely documented and the way things are named and structured not always intuitive. This project will be on a break next week so the next report will be in January, maybe even week 02 depending on my progress. Until then I will try to wrap up some of my work on dependencies to get these out of the way. I'm also going to delay the update to Gradle 8.12 that was released a few hours ago for mainly two reasons: - the new release now depends on a file events library that was split from native-platform and isn't packaged yet (the ITP is already filed); also that split would complicate a bit more the upgrade path that I'm planning for Gradle (and possibly Kotlin as well) - I would like someone else to proceed with that update to make sure the maintainer documentation makes it possible for others to maintain the package, and I haven't yet started to work on that documentation. That said, I wish happy end of year celebrations to those that will celebrate, peace to those that won't, and everybody to take care. Cheers, -- Julien Plissonneau Duquène
[toc] | [prev] | [next] | [standalone]
| From | Julien Plissonneau Duquène <sre4ever@free.fr> |
|---|---|
| Date | 2025-01-10 19:30 +0100 |
| Subject | Re: gradle reboot -- 2025W02 update |
| Message-ID | <K3rVE-7IH0-11@gated-at.bofh.it> |
| In reply to | #12865 |
Good evening, I have some more good news to share this week: Le 2024-12-20 19:15, Julien Plissonneau Duquène a écrit : > narrowed down the issue to some subtle failure in class resolution that > could happen either in Kotlin code or in libintellij-core-java or both It turned out to be some code missing in libmaven-resolver-1.6-java [1] which also breaks the builds of a few other packages. After solving that it was surprisingly easy to get Kotlin 1.3.31 to build with some additional code backported from 1.3.50 (no additional patching required), and even more surprising to see the Gradle 8.11.1 build succeed on the second try only after this enhanced Kotlin was installed and a single-line-change patch added to the Gradle packaging. A milestone is reached. Now building is one thing, getting the result to actually work is another battle. The first attempts could not even run successfully `gradle --help`, and I'm currently trying to get `gradle :help` to work within its own project [2], which means improving and fixing some earlier patching to ultimately get the generated `gradle` to be able to rebuild itself, and right after that make it build new releases of Groovy and Kotlin. Next week I plan to continue to progress on this, and also fork the `kryo` and `native-plaforms` packages to make it possible to install both the old and the new versions on a system, and change Gradle 4.4.1 packaging to make it use the old versions (mostly the same scheme as the current Maven upgrade). Cheers, [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091772 [2]: https://salsa.debian.org/jpd/gradle/-/blob/upgrade-to-8.11.1-wip/debian/wip/README.md -- Julien Plissonneau Duquène
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | linux.debian.maint.java
csiph-web