+1 Maintenance Report

Plus One Maintenance for Week of Jan 23-27, 2023

Here's notes for what I've worked on. Interspersed are some items that
may need further attention; sorry they're not flagged but hopefully my
notes may be of some use.

### node* cluster ###

nodejs is transitioning from 18.7.0 to 18.13.0.

* Latest version of npm hadn't run tests against nodejs 18.13, so I've
done a broad retrigger against that and node-undici. Succeeded.
* node-help-me needed node-mqtt retriggered, then migrated successfully
* node-rechoir needed node-liftoff and node-webpack retriggered;
both passed successfully, and node-rechoir migrated.

The following were just out of date on ABI, so I did no-change rebuilds:

* node-coveralls rebuilt as 3.1.1-2build1
* node-json5 rebuilt as 2.2.3+dfsg-1build1
* node-readable-stream rebuilt as 3.6.0+~cs3.0.0-4build1
* node-ts-jest rebuilt as 29.0.3+~cs0.2.6-1build1

Those four packages all built successfully, and their basic autopkgtests
succeeded with the old nodejs. I retriggered them all against the
new nodejs, and they all passed successfully as expected.

node-solid-keychain and node-trust-webcrypto are unmaintained upstream
and in fact the latter is flagged by upstream as recommended not to use
due to potential security issues. I filed a removal request for both
packages (LP: #2003831), and vorlon dropped them from the archive.

nodejs is now unblocked and is marked as "Will attempt migration."

### rubocop cluster ###

* ruby-rubocop-ast showed an implicit dependency between
ruby-rubocop-ast rubocop. I retriggered all the tests for rubocop
with ruby-rubocop-ast added as a trigger.
- This appears to have succeeded, and ruby-rubocop-ast is now marked
as "Will attempt migration" \o/

With that fixed, it looks like rubocop itself is also marked as "Will
attempt migration".

A few other *rubocop* packages that were blocked by the above two also
look likely to migrate now.

This entire cluster successfully migrated Thursday.

### ipython cluster ###

* ipywidgets was blocked by migration issue in q2-feature-table.
Retriggering that cleared it, and ipywidgets successfully migrated.
* python-pweave had an armhf migration error, but jbicha successfully
retriggered it to pass for ipython.
* python-qtconsole 5.4.0-1 hadn't been triggered against the new
ipython. I've done the retrigger, with triggers for other depends in
proposed.
* ipython itself I've retriggered against other python components in
proposed.

This entire cluster successfully migrated Thursday.

### python3-defaults cluster ###

python3 has been undergoing transition from 3.10 to 3.11. There's about
four dozen remaining migration issues, I pitched in on a few:

* python-django-tagging needed sync'd; succeeded.
* guake on arm64 needed retrigger with gobject-introspection; succeeded.
* q2cli needed retriggered with python3-defaults on arm64; succeeded.
* siconos on amd64 and arm64 needed retriggers; succeeded.
* python-configshell-fb needed retriggered with python3-defaults; succeeded.
* python-exchangelib needed retriggered with python3-defaults on all
arches; succeeded.
* python-xmlrunner needed retriggered with python3-defaults on all
arches; succeeded.
* fastapi needed retriggered with python3-defaults on all
arches; succeeded.
* conda-package-streaming needed retriggered with python3-defaults on all
arches; succeeded.
* dypi 1.5.0-7ubuntu1 was merged by graham inggs to fix tests, but
needed retriggered with python3-defaults.
* breezy 3.3.2-1ubuntu1 was introduced by Paride to disable flaky test
plugins. This needed retriggered with python3-defaults on all arches,
but also seems to still be flaky at least on amd64, so I also
retriggered the test for that arch a couple more times. Appears to
have finally resolved.

* deepnano/s390x:
- Debian has marked this package for removal. It has been failing in
testing and they no longer include it in CI. It's unmaintained
since 2017, and also depends on unmaintained package theano. See
Debian bugs #1026539, #1027215.
- I didn't file a removal request, but suspect we should...
* pytorch:
- There's a new 1.13.1 release that probably updates it to python
3.11. Debian hasn't merged that yet but there is some discussion to
do so. See LP: #2002685
- It looks like pytorch was removed from the archive instead (see LP:
#2003960). There are a few other pytorch packages that may also
#need attention.
* ceph:
- We're ahead of Debian with 17.2.0
- There are newer releases upstream, 17.2.[1-5]
https://ceph.com/en/news/blog/2022/v17-2-1-quincy-released/
https://ceph.com/en/news/blog/2022/v17-2-2-quincy-released/
https://ceph.com/en/news/blog/2022/v17-2-3-quincy-released/
https://ceph.com/en/news/blog/2022/v17-2-4-quincy-released/
https://ceph.com/en/news/blog/2022/v17-2-5-quincy-released/
- See LP: #1998958 "[SRU] ceph 17.2.5"
- However, the real issue is python3.11 support is missing, even in the
current upstream codebase. See line 20:
https://github.com/ceph/ceph/blob/main/cmake/modules/FindPython/Support.cmake
set(_${_PYTHON_PREFIX}_VERSIONS 3.10 3.9 3.8 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3.0)
- Adding 3.11 to that line seems required, but more might be needed.
See this upstream PR:
https://github.com/ceph/ceph/pull/48947
- I filed an update-excuse bug, LP: #2004038

### graphicsmagick cluster ###

* asymptote on arm64 needed retrigger; succeeded.
* auto-multiple-choice on arm64 needed retrigger; succeeded.
* balsa on arm64 needed retrigger; succeeded.
* node-imagick on arm64 needed retriggered; succeeded.
* raster3d on arm64 needed retriggered; succeeded.
* recoverjpeg on arm64 needed retriggered; succeeded.
* ruby-mini-magickon arm64 needed retriggered; succeeded.
* cimg on all arches needed a broader retriggering against a bunch of
packages, including perl, nodejs, etc.

With all that cleared, graphicsmagick transitioned successfully, and
everything blocked by it has migrated successfully.

### r-base cluster (r-cran*, r-bioc*) ###

Many of the r-cran packages are blocked from migration until r-base is
ready to transition.

* r-cran-sftime FTBFS needed a rebuild; tests now running
* r-cran-epir FTBFS needed a rebuild; waiting on one armhf test, rest good.
* r-cran-flextable waiting on r-cran-epir (above)
* r-cran-stars FTBFS needed a rebuild
- One autopkgtest 'neutral' on s390x, but migration-reference/0 also 'neutral'.
- Retriggered test for s390x, with r-base, et al.

* r-bioc-basilisk's -4 changelog says "Due to conda dependencies this
package seems to work for amd64 only". With -4 its tests now fail on
arm64, armhf, and ppc64el. I'm wondering if we should not be testing
on these other architectures, but am unsure what would need done.
- I filed update-excuse LP: #2003827 about the problem; Graham Inggs
took care of hinting it, and it's successfully migrated.

A couple dozen r-cran* packages all have test failures on just the armhf
architecture. Spot checking, they seem to be web socket failures, or
other issues that might be armhf flaky hardware; it appears the errors
have happened intermittently in the past. Most of these have already
been retriggered by jbicha so I've left them as is, but there may be
more retriggering to do. (Since these armhf errors appear to occur
fairly regularly, it may be worth deeper investigation to see if things
can be made to work more robustly...)

The above work seems to have cleared the logjam for r-base, which
transitioned successfully and allowed a lot of r-bioc-* stuff to
migrate. There's still some r-cran* bits still in process but no
remaining migration issues. So this entire cluster may finish migration
today or tomorrow.

### tdb / squid cluster ###

* pulseaudio on ppc64el needed retriggered
* sssd on ppc64el needed retriggered
* squid on ppc64el needed retriggered

squid was actually blocking a number of items. I retriggered it with
the current -proposed versions of all of them, and it succeeded. squid
successfully migrated from 5.6 to the new 5.7 merge as a result.

sssd is clear of migration blockers, except for samba and
python3-defaults.

tdb is also free from migration blockers other than python3-defaults,
and should now migrate once that transitions.

### talloc / osmo cluster ###

* libosmo-sccp on amd64 needed retriggered
* osmo-pcu needed retriggered (all arches)

The armhf tests took a while to finish running, but everything cleared
Thursday. talloc should now complete migrating once python3-defaults
finishes its transition.

### libmoose-perl cluster ###

* libgeo-calc-perl on amd64 needed retriggered; succeeded
* libaudio-mpd-common-perl on amd64 needed retriggered; succeeded

* libterm-filter-perl is the only remaining failure. This has been
intermittently failing/passing for some time. Debian has a bug report
about the flaky test fail (Deb: #843052) which I've added to Launchpad
as an update-excuse bug (LP: #2003923). I think all we can do is keep
retrying the same triggers until it passes.

libterm-filter-perl finally passed Thursday, and libmoose-perl
successfully migrated.

### numpy cluster ###

* pygac on ppc64el needed retriggered for 1.7.1-2 against numpy,
bottleneck and python3-defaults (and maybe a few others); succeeded.

* einsteinpy on ppc64el failed to retrigger, but was a known issue in
Debian (Deb #1027198). A fixed version 0.4.0-1 sync'd in from Debian,
but failed on s390x. Another fixed version 0.4.0-2 brings a fix for
s390x as well, but tests haven't run for that.

(A bunch of the python packages I've listed elsewhere in this report were
blocked because they also needed retriggered against numpy in addition to
python3-defaults.)

### libcommons-net-java ###

Was blocked by autopkgtest issue for nrepl-clojure on arm64.
Passed successfully after retriggering, enabling it to migrate
successfully.

### maven-artifact-transfer ###

FTBFS needed simple rebuild.
Tests passed ok, and it's migrated successfully.

### golang-github-azure-azure-storage-blob-go ###

Was blocked by golang-gocloud on arm64, and migrated successfully after
that was retriggered.

### gscan2pdf on armhf timeout ###

Passed after a retrigger and migrated successfully.

This mentioned a timeout in its test log, however it looks like it was
something network related, so presumably was armhf hw flakiness. It's
failed intermittently with the same issue in the past, so may be worth
deeper investigation when it occurs in the future.

I did another, broader retriggering with systemd, graphicsmagick,
apache2, libpdf-builder-perl, etc. just in case there were any stray
things dependent on it. That succeeded without issue.

### ycmd on amd64 ###

This hit a timeout, and passed on retriggering, enabling
0+20220824+git2ee4100+ds-2build1 to successfully migrate.

However, there's a new git snapshot, 0+20230103+gitf53e7ac+ds-1, which
has just sync'd in from Debian but awaits python3-defaults to finish
transitioning.

### freedombox ###

Log shows it hit memory exhaustion. Attempted retrigger... succeeded
and migrated successfully.

### pkg-config / pkgconf ###

Autopkgtests fail due to a conflict of these two packages:

"pkg-config/amd64 in main cannot depend on pkgconf in universe."

This pkgconf / pkg-config conflict has been going on for a couple months
whenever these two get triggered together. There is a MIR for pkgconf
to replace pkg-config (LP: #1998095). I've tagged it update-excuse for
+1 maintenance reference.

## jaraco.text Impossible Depends ##

python3-jaraco.text is in main but the new 3.11.0 version depends on
python3-autocommand/2.2.2-2 and python3-inflect/2.1.0-4 which are in
universe. These were just added as build dependencies by Debian in
3.11.0-1.

James Page added a MIR (LP: #2001699), which is in progress.
I added a bugtask for jaraco.text with the update-excuse tag for
tracking.

## colord Impossible Depends ##

colord is bumped in debian from 1.4.6-1 to 1.4.6-2.1. Debian is
re-enabling Argyll support, however argyll is in universe for Ubuntu.

There is an existing MIR for argyll, LP: #821883, however it is old and
last active in 2018. I pinged it, and got attention from Eickmeyer and
Didrocks. Looks like it awaits input from RAOF regarding next actions.
- TODO: Update with his response

I've also opened LP: #2003833 against colord to track the update-excuse
migration problem, for future +1 maintainer reference.

## ceilometer Impossible Depends ##

python3-ceilometer/amd64 in main cannot depend on python3-xmltodict in universe
Impossible Depends: ceilometer -> python3-xmltodict/0.13.0-1/amd64

There is an existing MIR for xmltodict, LP: #2002576. Added bugtask for
ceilometer and tagged update-excuse.

## coreutils ##

coreutils 9.1-1ubuntu2 is merged, but blocked by datefudge on armhf

Debian runs into this issue as well, see Deb #1028587 and LP: #2002803.
Unfortunately per the upstream maintainer the package is no longer
maintained and he recommends moving things dependent on it to other
alternative libraries like libfaketime.

datefudge is required by gcc-12-base, libc6, etc. so doesn't seem like
we can just drop it.

It's a very small codebase (single .c file) so presumably shouldn't be
too time consuming to fix up...

Meanwhile, I've tagged LP: #2002803 as update-excuse.

## Merge plfit ##

Handled the merge for plfit from MoM. Delta just carries forward.
Builds succeeded and tests passed in the PPA, but migration might be
blocked by the python3-defaults transition.

## Stats ##

2023-01-22 1251 update excuse records found
2023-01-23 1232
2023-01-24 1172
2023-01-25 1687 <-- [debian autosync is re-enabled]
2023-01-26 1290
2023-01-27 1172

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Setting NotAutomatic for hirsute+1-proposed

On Sat, Jan 21, 2023 at 08:30:33PM +0100, Gunnar Hjalmarsson wrote:
>On 2023-01-20 21:47, Steve Langasek wrote:
>>On Thu, Jan 19, 2023 at 01:44:12PM +0100, Gunnar Hjalmarsson wrote:
>>>On 2021-01-21 11:20, Robie Basak wrote:
>>>>https://wiki.ubuntu.com/Testing/EnableProposed will need a
>>>>rework though. We link to that from every SRU bug.
>>
>>>That page was last updated on 2020-06-19, and is obsolete. Would be
>>>great i someone could follow up the change and edit the
>>>Testing/EnableProposed page so it makes sense again.
>>
>>Have you run into problems with the instructions on that page? I
>>skimmed it and aside from mentioning "Selective upgrading from
>>-proposed" which is redundant for newer releases, I don't immediately
>>see anything incorrect there. If you can point out where it's wrong,
>>I'll happily edit it to correct it but I don't have time just now to
>>run through the full instructions there to find out what doesn't
>>work.

Maybe the change of behavior here is the confusing bit?

Previously, following the first part of the guide (before the "selective
upgrading" docs) would be enough to install the desired package(s) from
proposed without specifying the pocket in the apt command.

>First I have to admit that I thought the change had been implemented
>already in jammy. I see now that that's not the case, at least not
>yet.
>
>As regards the contents of the wiki page, you are right and I stand
>corrected — there is not much of directly incorrect information.
>
>I think it's mostly about my personal taste: I have long thought that
>the page is overly complicated. I made use of Ask Ubuntu to illustrate
>what a less wordy page might look like:
>
>https://askubuntu.com/questions/1451256
>
>That Ask Ubuntu answer is not exactly targeted people like the ones
>who have participated in this list thread. I have rather the not so
>tech savvy user in mind, like a bug reporter who wants to help verify
>a proposed SRU fix.
>
>I simply fear that the current wiki page contains so much information,
>so a prospective tester may be discouraged to follow through.

Perhaps, in the first section, after

"It is recommended to enable selective upgrading from -proposed as
described in the next section!"

we could metion the NotAutomatic setting and point out that just
creating the file under /etc/apt/sources.list.d/, as shown in the guide,
will no loger make the user's system to prefer newer packages from
proposed, as it would happen in the past. Instead, they should follow
the next section (selective upgrading from -proposed). If they desire
the former behavior they could change the preferences file priority as
well.

>
>--
>Gunnar Hjalmarsson
>https://launchpad.net/~gunnarhj
>
>--
>ubuntu-devel mailing list
>ubuntu-devel@lists.ubuntu.com
>Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--
Athos Ribeiro

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Replacing the telegram-desktop deb by a snap installer in stable series?

Hi!

[moving to ubuntu-devel@ for wider discussion]

I think the appropriate answer here depends on careful policy decisions
that would apply to both the development and to stable releases. I
discussed this briefly with some other SRU team members earlier, and
also with Seb.

Subject to further consultation, I suggest that if we recommend that
users switch to the snap, then that should require explicit user opt-in
(eg. via a debconf prompt) regardless of whether it's in Lunar or in a
stable release. This means that the current implementation in Lunar
should also be changed.

For an SRU, if the current deb is unusable, nobody is stepping up to
maintain it and this is causing users harm, then either we ship a
transitional deb without a binary with the same explicit opt-in
requirement, or we do that but also keep the deb-built binary available
in case the user selects "no". The decision should depend on exactly
what is wrong with the current deb. We shouldn't bother users unless
there's something seriously wrong with it.

In both cases, the notice associated with the choice should be crafted
carefully to make it clear that if the user selects "yes", then they
would be installing telegram-desktop directly as shipped by a third
party and not from Ubuntu, and that further maintanance of the package
would come from upstream, subject to upstream and no longer Ubuntu
process and policies.

Here's my reasoning.

Regardless of whether we do this in the next release or also in existing
stable releases, there are some key user expectations that we should be
thinking about:

1) That users expect Ubuntu releases to be stable in the sense that they
won't change behaviour once released (with some exceptions).

2) That policy, builds, quality control, package publication and similar
processes are under the control of Ubuntu governance. This is required
in order for us to be in a position to deliver on user expectations
generally, including on the previous point.

Moving to snaps published by third parties would break these
expectations, unless we take further action.

In some cases, moving to a snap makes sense. For example, given that the
telegram-desktop deb continues to have no volunteers to fix the
outstanding issues with it, it sounds like users are better served by
the snap right now.

But how does that fit in with user expectations I described above?

Within the Technical Board I've been working on defining policy in this
area. The draft isn't quite ready yet so this is unfortunate timing. But
based on the current state of our deliberations, I think we're at the
following in relation to telegram-desktop:

If users make a deliberate choice to opt-in to a third party software
source, then no further policy applies. Users understand that they are
no longer consuming the software "from Ubuntu", so expectations on
quality from Ubuntu no longer apply.

Otherwise, user expectations such as "no change in behaviour" generally
remain, and we should maintain that. So packages installed by default in
Ubuntu, or through automation such as a transitional deb, should not
change in behaviour even when the package ultimately being delivered is
a snap.

There are exceptions. For example, Firefox already had an exception as a
deb, so it makes sense to carry that through to the snap. It is probably
appropriate to apply our usual Internet protocol change exception to
telegram-desktop, but I'm not sure it's appropriate to give it a blanket
exception for all behavioural changes when protocol changes do not
require them.

There are also other requirements on such snaps in our draft, such as a
dedicated snap track, which aren't currently implemented in the
telegram-desktop transitional deb that's in Lunar right now. Some would
require commitments from upstream.

It seems to me that in the case of Telegram, it makes more sense to
leave upstream free to do what they want in respect of the snap, rather
than for us to ask them for their agreement in implementing our "stable"
policies. This would preclude us from installing telegram-desktop by
default, or pulling it in automatically via a deb, but that doesn't seem
like much of an issue to me given that in the past the only way for a
user to install it was by requiring explicit user action anyway.

Feedback appreciated. Feedback from non Ubuntu developers should go to
ubuntu-devel-discuss@ please[1].

Thanks,

Robie

[1] https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Auto syncs from Debian fixed

On Tue, Jan 24, 2023 at 05:34:20PM +0100, Paride Legovini wrote:
> Just a quick warning on the fact that Launchpad auto-syncs from Debian
> to Lunar are currently not happening.
>
> There's an issue with debmirror is crashing [1], but the underlying
> cause is on the Debian side [2].
>
> The debian-ftp team is aware, hopefully that's going to be sorted out soon.

The Debian ftpmasters have fixed the dak bug that caused this, and
Launchpad's Debian import is running again now; auto-sync should catch
up shortly after that.

--
Colin Watson (he/him) [cjwatson@ubuntu.com]

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Auto syncs from Debian currently not happening

Hi -devel,

Just a quick warning on the fact that Launchpad auto-syncs from Debian
to Lunar are currently not happening.

There's an issue with debmirror is crashing [1], but the underlying
cause is on the Debian side [2].

The debian-ftp team is aware, hopefully that's going to be sorted out soon.

--
Paride

[1] https://answers.launchpad.net/launchpad/+question/704509
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029497

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: How to ask for introducing a new package into main?

On Thu, 19 Jan 2023 at 17:05, <c.buhtz@posteo.jp> wrote:
>
> Hello,
>
> I checked the wiki and docu but couldn't find that process described
> somewhere.
>
> Is there a ticket system where I can open a wishlist-bug or something
> else to ask for introducing a new package into the "main" repository?
>
> "universe", launchpad or privat ppa are not an option because the
> package is still there.

I've read the whole thread, and I just want to reiterate - all default
ubuntu installations enable main, restricted, universe and multiverse
components of an Ubuntu Series, including release, security and
updates pockets (e.g. jammy jammy-security jammy-updates). All of
these are considered to be part of a given Ubuntu distribution
release. A package is available to be installed by default, if it
exists in any of those places. The distinction between the various
locations are in the grand scheme of things fairly minor, and are
policy driven.

There can be specific cases and instances where things are missplaced,
or have been removed and reintroduced. If you have specific packages
and examples of things unavailable, please point them out for further
investigation. Removal and reintroduction often happens when a package
fails to be compatible with a given Ubuntu release, in the specified
timeframe due to timed releases. But these are exceptions rather than
the norm.
--
okurrr,

Dimitri

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Server Package Set Upload Permissions - Lena Voytek

On Fri, Jan 06, 2023 at 12:15:58PM -0700, Lena Voytek wrote:
> I'm announcing my application for server package set upload
> permissions. My application is located at:
>
> https://wiki.ubuntu.com/LenaVoytek/UbuntuServerDeveloperApplication

Today, the DMB voted to approve Lena's ubuntu-server-dev application.

Congratulations, Lena, and thank you for your previous and continued
contributions!

On behalf of the DMB,

Robie