Hi Sergio,
I notice in this report that most of the items you worked on requiring
source changes have Debian bugs or MPs as references, but there is no
mention of what is done to get them resolved in Ubuntu. We want to push
fixes upstream to Debian and minimize unnecessary delta, but the purpose of
+1 maintenance is to resolve items in the devel-proposed queue. As long as
these packages remain in -proposed, there's a cost to the team (both in
terms of contributing to longer britney run times, and in retreading
packages in the queue that have already been looked at).
Can you elaborate how each of these package fixes are getting into Ubuntu,
and where the progress is being tracked?
Related also to Brian's comments about having a handoff section in reports!
But IMO it's ideal to have this all in an update-excuse bug instead so that
people don't have to find the right email in the archive to get information
about the state.
On Wed, Jul 13, 2022 at 05:05:15PM -0400, Sergio Durigan Junior wrote:
> I've been on +1 maintenance shift from Monday to Wednesday. I'm also
> working on my DebConf presentation & debuginfod in parallel.
>
> Retriggers that worked
> ======================
>
> sqlite> SELECT DISTINCT test.package, result.version, result.triggers
> sqlite> FROM result INNER JOIN test ON test.id = result.test_id WHERE
> sqlite> result.requester = 'sergiodj' AND result.exitcode = 0 AND result.run_id
> sqlite> LIKE '2022071%';
>
> starjava-connect|0.1+2020.10.01-1|ant/1.10.12-3
> starjava-array|0.2+2022.03.23-1|ant/1.10.12-3
> starjava-fits|0.1+2022.05.13-1|ant/1.10.12-3
> starjava-table|4.1.1-1|ant/1.10.12-3
> starjava-topcat|4.8.5-1|ant/1.10.12-3
> starjava-util|1.0+2022.06.09-1|ant/1.10.12-3
> starjava-vo|0.2+2022.01.20-2|ant/1.10.12-3
> starjava-votable|2.0+2022.04.04-1|ant/1.10.12-3
> starjava-ttools|3.4.5-1|ant/1.10.12-3
> osicat|0.7.0+git20220117.a45eb3b-1build1|sbcl/2:2.2.3-2 osicat/0.7.0+git20220117.a45eb3b-1build1
>
> Retriggers that didn't work
> ===========================
>
> sqlite> SELECT DISTINCT test.package, result.version, result.triggers
> sqlite> FROM result INNER JOIN test ON test.id = result.test_id WHERE
> sqlite> result.requester = 'sergiodj' AND result.exitcode != 0 AND result.run_id
> sqlite> LIKE '2022071%';
>
> osicat|0.7.0+git20220117.a45eb3b-1|sbcl/2:2.2.3-2
> osicat|0.7.0+git20220117.a45eb3b-1build1|sbcl/2:2.2.3-2
> python-django-celery-results|2.3.1-1|python-django-celery-results/2.3.1-1
> tinyssh|20220311-2|tinyssh/20220311-2
> r-cran-vegan|2.6-2+dfsg-1|r-cran-vegan/2.6-2+dfsg-1
> golang-github-klauspost-compress|1.15.4+ds1-1|golang-github-klauspost-compress/1.15.4+ds1-1
>
> Investigations
> ==============
>
> * barectf
> - s390x dep8 test is failing. According to upstream, the testsuite
> requires a little-endian architecture.
> - https://salsa.debian.org/debian/barectf/-/merge_requests/1
>
> * python-django-celery-results
> - The tests are failing because python-psycopg2cffi is still at
> version 2.8.1, the minimum required version is 2.8.4. There's a new
> upstream version (2.9.0) available.
> - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014827
>
> * r-cran-vegan
> - Tests are failing because the dep8 unit test script assumes that
> every upstream test will have a corresponding ".save" output file
> that can be used to compare the results against, but that's not the
> case.
> - https://salsa.debian.org/r-pkg-team/r-cran-vegan/-/merge_requests/1
>
> * r-cran-tmb & r-cran-glmmtmb
> - The problem is that r-cran-glmmtmb needs to be rebuilt with the
> newest r-cran-tmb, but hasn't. There was an upload to Debian
> unstable with the purpose of rebuilding the package, but I believe
> it was made too soon and the build ended up using the old version of
> r-cran-tmb.
> - https://tracker.debian.org/news/1345185/accepted-r-cran-glmmtmb-113-3-source-into-unstable/
>
> * tpot
> - Build failing due to a testcase issue. I found a PR upstream that
> fixes the problem.
> - https://salsa.debian.org/science-team/tpot/-/merge_requests/1
> - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014618#10
>
> * sbcl
> - As Athos mentioned
> (https://lists.ubuntu.com/archives/ubuntu-devel/2022-July/042200.html),
> we're starting to work on bootstrapping sbcl on ppc64el.
> - Unfortunately we've hit some bumps... The build is mysteriously
> segfaulting on ppc64el in a PPA. So we're investigating things
> before proceeding with the upload.
>
> * liburing
> - Tests were in a broken state (still running after 13+ days). I sent
> a message to #ubuntu-devel and bdmurray kindly looked into the issue.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
