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
Next week I will start working on a detailed action plan and PoC for
the rebootstrap, in between build runs and fixups.
The build progressed a bit and now fails on the outdated Groovy
As usual, comments and contributions are very welcome.
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.
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 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.
Now the build fails on Kotlin issues.
I will see this week how far I can go with this plan.
error: type mismatch: inferred type is org.jetbrains.org.objectweb.asm.tree.MethodNode but MethodNode! was
expected
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
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)
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?
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.
android-platform-tools-base has a FTBFS bug unresolved since Aug 2024,
is also severely outdated(2017), and overall same verdict as above.
now I'm stuck on the (re)build of Kotlin 1.3.31 that currently FTBFS
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
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).
investigate the current Gradle 8.11.1 stage 2 build failure (which
looks like either a Kotlin compiler bug or a dependency on a feature
that is missing in 1.3.31) and try to patch the build script to work
around that.
Good evening,
Some great news for this week, as I got my "stage 0" gradle (the one that is locally built by a pre-built binary distribution of Gradle from upstream) to rebuild itself successfully.
Le 2025-01-17 19:22, Julien Plissonneau Duquène a écrit :
investigate the current Gradle 8.11.1 stage 2 build failure (which looks like
either a Kotlin compiler bug or a dependency on a feature that is missing in >> 1.3.31) and try to patch the build script to work around that.
It turned out that the amount of patching required was very reasonable given the
version gap. I had to patch a few more lines for Groovy as well, and was delighted to achieve a successful build two days ago. It was also a pleasant surprise to notice that the binaries generated by this "stage 1" build are identical to those built by the "stage 0", which will make the rebootstrapping a
bit easier.
I'm currently working on packaging something that will be unfinished but could
be pushed to experimental to make it easier for others to try the new release,
and I have good hopes to achieve that by next week. Then there will still be some significant work to update or package missing but important dependencies,
as currently some key features (configuration cache, HTML problem reports, TOML
version catalogs, ...) are disabled because of this.
Now I have a growing stack of TODO items for sponsors/uploaders willing to participate ;) and published the planned steps for the migrations here [1] (will
update tomorrow).
Have a nice week-end,
[1]: https://salsa.debian.org/jpd/gradle/-/blob/upgrade-to-8.11.1-wip/debian/ wip/action-plan.md
Great news! Congrats on hitting that major milestone!
trying to figure out how to configure the whole thing so the bootstrap
gradle (from upstream, thus unpatched) still finds the Kotlin 2.0.20
that makes it happy, but builds a gradle that uses our Frankenkotlin.
it's a slow and tedious process, though I think I'm progressing, and I
still have some hopes to be able to get the thing to work with the Frankenkotlin.
I'm already done with a few modules and I'm currently on the most
touchy one, kotlin-dsl.
Good evening,
As I'm writing this, my current gradle 8 build is down to 2 (new) compilation errors in kotlin-dsl (from over 60 last week).
Le 2025-02-07 19:40, Julien Plissonneau Duquène a écrit :
I'm already done with a few modules and I'm currently on the most touchy one,
kotlin-dsl.
This kept me busy for a while, as it required a fair amount of git archaeology
to track the tormented history of some Kotlin stdlib features that had then to
be either dropped, renamed, copy-pasted or reimplemented in Gradle source code.
A few more features had to be backported into our Frankenkotlin, and I also had
to rework the build of its backported assign-plugin to get jars that look like
they could be usable.
I will probably be done with that Gradle module soon, and I think most other modules written in Kotlin are already patched so I expect to be able to test if
that gradle will rebuild itself by next week, and then either debug it (probable
outcome) or, if I'm really lucky, resume the packaging work. Watch my repositories on salsa for updates!
Cheers,
Very exciting! Thanks for your status updates on this. Do you want
more visibility for them?
test if that gradle will rebuild itself by next week, and then either
debug it (probable outcome)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 716 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 52:21:53 |
| Calls: | 12,115 |
| Calls today: | 6 |
| Files: | 15,010 |
| Messages: | 6,518,589 |
| Posted today: | 1 |