+1 maintenance report

Thu Aug 4 01:21:04 UTC 2022

On Friday, July 22 2022, Steve Langasek wrote:

> Hi Sergio,

Hello,

Sorry for the delay.  I was travelling and then on medical leave.

> 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).

As I understand it, we are constantly trying to unblock packages from
-proposed while at the same time judging whether it makes sense to add
extra delta that will inevitably be carried forward for some time,
especially when we are dealing with packages in universe.

This specific +1 shift was done mid-cycle, and as it turned out I ended
up working (coincidentally) on issues that also affected the Debian
packages, so I made a judgment call and considered it better to try and
fix problems there first knowing that the fixes will eventually reach
Ubuntu (because none of the packages I worked on had any pre-existing
delta).

On top of what I said above, there is also the fact that +1 maintenance
reports seem to be meant to provide guidance for the person who is going
to be on shift during the following week.  My report is not the only one
to mention a lot of Debian work that will eventually need to be followed
up later.

> Can you elaborate how each of these package fixes are getting into Ubuntu,
> and where the progress is being tracked?

I am not entirely sure I understand the question, but I will try my best
to answer.

Each of these fixes are getting into Ubuntu ideally when the respective
Debian maintainers accept the proposed changes and perform the
corresponding uploads.  If that doesn't happen before the final freeze,
I/we can certainly pick the fixes up and upload them to Ubuntu.

I was unsure whether I should file an Ubuntu-specific bug for each fix,
so I decided not to do so in order not to pollute our bug tracking
system.  So, for now, the progress for each of these issues is being
tracked in the respective links I posted (BTS, salsa, upstream repo,
etc).  I am subscribed to all of them, and get notified whenever there
is an update.

Arguably, I should have probably filed corresponding Ubuntu bugs (tagged
update-excuse) for each of these issues.  This is a workflow improvement
that I am considering for the next shift.

>> 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

This hasn't been accepted by the Debian maintainer yet.  I left a ping.

>> * 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

No response yet.  This will likely demand a bit of work, so I truly
believe it should be done in Debian.

>> * 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

Merged and uploaded.  Fixed.

>> * 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/

Rebuilt.  Fixed.

>> * 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

No response yet.  Left a ping.

>> * 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.

This is finished.

Thank you,

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14