puppetdb fails to build from source on noble

[Pushkar Kulkarni]

[ Impact ]
* Package puppetdb fails to build from source on noble. The `default-jdk/jre` packages from java-common have been migrated to openjdk-21. And the puppetdb level on noble (7.12.1-3) fails to build with openjdk-21. See ppa build [1].

* The current binaries of puppetdb were built prior to the default-jdk migration to openjdk-21. Running them with openjdk-21 (which puppetdb does not support) can have unforeseen consequences to users.

* Users of puppetdb migrating to noble from jammy might see regressions.

[ Test Plan ]
* Building puppetdb 7.12.1-3 on noble as in [1] causes FTBFS.

[ Where problems could occur ]

* This SRU proposes upgrading puppetdb to 8.4.1-1 (which is currently uploaded to oracular). This version is compatible with openjdk-21.

* However, puppetdb 8.4.1-1 also needs libclj-http-clojure (>= 3.12.3) which is not satisfiable on noble [2]. I plan to create a parallel SRU request, which should precede the current one, for package clj-http-clojure too.

[ Other Info ]
* I haven't attempted running the 7.12.1-3 binaries with the default-jdk/openjdk-21 because FTBFS in itself is an indicator of incompatibility and needs to be addressed.
* I also created an SRU bug for clj-http-clojure [3].
* A successful PPA build of puppetdb 8.4.1-1 on Noble, with libclj-http-clojure updated to 3.12.3-1 is seen here [4].

[1] https://launchpad.net/~pushkarnk/+archive/ubuntu/puppetdb-sru1/+build/28577254
[2] https://launchpad.net/~pushkarnk/+archive/ubuntu/puppetdb-sru2/+build/28577255
[3] https://bugs.launchpad.net/ubuntu/+source/clj-http-clojure/+bug/2069390
[4] https://launchpad.net/~pushkarnk/+archive/ubuntu/puppetdb-sru3/+build/28577425

[Nick Rosbrook (enr0n)]

Have you tried to determine if there is a minimal set of patches that could be cherry-picked for an SRU, rather than backporting a new upstream version? Usually, backporting a new upstream version as an SRU requires a micro release exception, but I do not see any for this package on [1].

Otherwise, following the backports process [2] for this package *might* be more appropriate (i.e. land the new version in -backports rather than -updates).

Note that I am not on the SRU team or anything, but I came to look at this as a sponsor, so those are my thoughts.

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
[2] https://wiki.ubuntu.com/UbuntuBackports

[Pushkar Kulkarni (pushkarnk)]

Thanks, Nick.

I tried to only backport the patch that fixes FTBFS with openjdk-21. I see a build-time test fail [1]. There is another patch in 8.4.1-1 that skips a test, but I don’t find that relevant to this test failure.

[1] https://launchpad.net/~pushkarnk/+archive/ubuntu/puppetdb-noble/+build/28592673/+files/buildlog_ubuntu-noble-amd64.puppetdb_7.12.1-3ubuntu1ppa1_BUILDING.txt.gz

[Benjamin Drung (bdrung)]

Marking as fixed released for oracular since 8.4.1-1 built there.

I agree with Nick to cherry-pick the needed patches to make puppetdb build on noble. Have you tried bisecting upstream to see which commit fixes the test failure?

I am unsubscribing ~ubuntu-sponsors for now. Please re-subscribe once you have a debdiff to sponsor.

[Pushkar Kulkarni (pushkarnk)]

Thanks for the reviews and sincere apologies for my delayed response.

I was able to cherry-pick a patch (see attached debdiff) and get puppetdb building [1]. However, the autopkgtests failed:

=====

autopkgtest [00:30:07]: @@@@@@@@@@@@@@@@@@@@ summary
standalone FAIL stderr: warn: JDK 21.0.3 is neither tested nor supported. Please use JDK 11
with-puppetserver FAIL non-zero exit status 1

====

Whilst fixing test 'standalone' is straightforward (allow-stderr), the failure of test 'with-puppetserver'[2] might be related to incompatibility with puppetdb (7.*) and puppetserver(8.*) in noble. Howerver, contrary to what I initially assumed, puppetdb 7.* must work with puppetserver 8.*as per [3].

[1] https://launchpad.net/~pushkarnk/+archive/ubuntu/puppetdb-retest/+build/28627960
[2] https://paste.ubuntu.com/p/tsSxDp6ydh/
[3] https://www.puppet.com/docs/puppetdb/7/overview.html

I am investigating the autopkgtest failure.

[Pushkar Kulkarni (pushkarnk)]

I have managed to fix the autopkgtest failures by back-porting one more upstream patch along with some necessary changes to debian/test/*.

The final debdiff is attached here.

Test build: https://launchpad.net/~pushkarnk/+archive/ubuntu/puppetdb-retest/+build/28638064
Local autokpgtest run: https://paste.ubuntu.com/p/2SgC3YcJGY/

[Nick Rosbrook (enr0n)]

Thanks for finding the minimal patches required for this. A few organizational things:

1. 0008-Resolve-ftbfs-with-java-21.patch: It would be good to have an Origin: field in the patch showing where you got this. It's good you have the Author: for credit, but links are easier to follow. I also prefer to have Bug-Ubuntu: fields in the patch headers.

2. 0009-Replace-use-of-to-pson.patch: This patch needs dep3 headers in general.

3. Are both patches, and the d/control change, directly related to the FTBFS? If so, the changelog would be more readable with an entry like:

* Fix FTBFS on noble (LP: XXXXXXX)
  - first patch summary
  - second patch summary
  - d/control change summary
* [...the rest...]

4. Finally, from a quick glance, it seems these same autopkgtest failures exist in oracular. Can you prepare a patch to fix those in oracular too?

[Nick Rosbrook (enr0n)]

LP is eating my indentation in the changelog entry example, but hopefully you get the idea.

[Pushkar Kulkarni (pushkarnk)]

Thanks again, for the review!

> Points 1, 2, 3 above

  I've addressed them in the newly attached diff. Test build in PPA [1].

> Point 4

  Yes, I do have an MP created [2].

[1] https://launchpad.net/~pushkarnk/+archive/ubuntu/puppetdb-retest/+build/28646990
[2] https://code.launchpad.net/~pushkarnk/ubuntu/+source/puppetdb/+git/puppetdb/+merge/468942

[Nick Rosbrook (enr0n)]

Thanks! I have gone ahead and uploaded.

I did make one minor adjustment because I forgot to mention something before. Generally, it is a good idea to follow [1] when selecting a version number for SRUs. In this case, it might not technically matter because oracular already has a new upstream version in -release, but still.

> Yes, I do have an MP created [2].

I left a quick comment there. To make the SRU team's job easier, it would be good to also fill out the SRU template on bug 2072516 (even though it's trivial since it's about making autopkgtest pass).

[1] https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging

[Pushkar Kulkarni (pushkarnk)]

Thanks! I added the SRU template on bug 2072516. And also addressed your comment on the oracular MP.