Wednesday, 26 January 2022

Re: Revisiting default initramfs compression

On Wed, Jan 26, 2022 at 4:18 PM Robie Basak <> wrote:
> It was noted in ubuntu-devel-discuss@ that changing the compression
> method impacts Xen's use of pygrub. I thought that was worth mentioning
> in this thread as something worth considering when making any decision.



Which for people who love bugs more than mailing list entries is [1].


> --
> ubuntu-devel mailing list
> Modify settings or unsubscribe at:

Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

ubuntu-devel mailing list
Modify settings or unsubscribe at:

Re: Revisiting default initramfs compression

It was noted in ubuntu-devel-discuss@ that changing the compression
method impacts Xen's use of pygrub. I thought that was worth mentioning
in this thread as something worth considering when making any decision.

Tuesday, 25 January 2022

+1 maintenance report


I usually don't do those, but thought I'd try. I had 2 days of +1
maintenance (Monday and Tuesday), and even though I wasn't able to
give it my 100% due to other responsibilities, here's what I did
more-or-less. These are from my slightly chaotic notes:

* Looking into capnproto
- Stuck in -proposed because of FTBFS on all arches
- Fixed the FTBFS by fixing the failing tests - possibly due to the
new openssl
- Sadly, it seems it fails on ppc64el now only, didn't have time to
pursue that yet

* fakechroot depwait:
- Blocked by jemalloc FTBFS - see below, but now migrated

* jemalloc FTBFS checking:
- Failed due to glibc 2.34 dropping malloc_hooks, pushed fix
- Migrated

* Removal of uvp-monitor per request as it was unmaintained

Then I moved on to doing some NBS cleanup:

* glewlwyd no-change rebuild to clear associated NBS

* biboumi and the libidn11 NBS
- Looked at botan that's blocking that, but ppc64el test failure
makes no sense
- Hacked a bit on it but didn't make much progress

* emacs - libotf0 NBS
- emacs was FTBFS after a no-change rebuild
- Cherry-picked fix to make emacs build again

* libquvi-0.9-0.9.3
- Its dependency, quvi, had a no-change rebuild FTBFS
- Since the package was unmaintained, I filled a removal bug and
proceeded with the removal (LP: #1958967)
- Please shout if you want it back, but remember that it first
needs a build fix!

* libslurm36 NBS
- Caused by the mpich no-change rebuild FTBFS
- Looked into the failure, trying to identify obvious solution
- Tried building the new version from Debian - passed
- Prepped and uploaded a merge for mpich

...and I think that's it. The rest was outside of +1 maintenance scope, I think.


Łukasz 'sil2100' Zemczak
Foundations Team

ubuntu-devel mailing list
Modify settings or unsubscribe at:

Re: [Launchpad-users] Proposed decommissioning of 32-bit powerpc builders in Launchpad

On Fri, Dec 03, 2021 at 12:59:34PM +0000, Colin Watson wrote:
> The old 32-bit powerpc architecture was removed from Ubuntu in Ubuntu
> 17.04 [1]. This means that all releases that still supported it are now
> in ESM, and ESM doesn't include powerpc support. We're therefore
> considering decommissioning Launchpad's powerpc builders. Note that the
> 64-bit ppc64el architecture would be *unaffected* by this change.

We've now disabled the powerpc architecture in xenial (which should
cause no further builds to be created) and deactivated the powerpc
builders. I plan to leave things in this state for a little while to
confirm that no further powerpc builds are being created and that
nothing else comes up, but after that we'll start tearing down the
builders permanently.

Colin Watson (he/him) []

ubuntu-devel mailing list
Modify settings or unsubscribe at:

Monday, 24 January 2022

OpenSSL 3.0 status report

Hi all,

This is a quick status report regarding the OpenSSL 3.0 transition that
started back in November in the archive[0]

Thanks a lot of people, we have OpenSSL 3.0.1-0ubuntu1 in the release
pocket for jammy, and the vast majority of its reverse-dependencies are
built against it, although some of them still haven't reached the
release pocket for various reasons, e.g. other entangled transitions.

However, the work isn't finished. There remains quite a few packages in
the release pocket that still link against libssl1.1, as can be seen on
the NBS report[1]. This number should get down to 0 at release time, and
those packages should thus be a good target for people on +1 rotation,
or anyone that looks to give a hand for the upcoming release. Notably,
if you open bugs for tracking these issues (which I encourage
wholeheartedly), please use the tag `transition-openssl3-jj` to help
tracking the effort[2].

I'm available via mail or IRC (schopin, mostly during European daytime)
to help anyone having questions.



Simon Chopin
Foundations Team Ubuntu MOTU

ubuntu-devel mailing list
Modify settings or unsubscribe at:

+1 maintenance report


Amidst the mid-cycle sprints and being partly sick,
I was on +1 last week and did the following things:

## node-pbkdf2 (LP: #191828)

The tests have been failing on s390x because of it
being big-endian but I've been in touch with people
on the Debian side (we're all part of the JS team)
and we're trying to fix this. The upstream is dead
but we've proposed a first patch, which whilst doesn't
fully resolve the issue, it brings us a lot closer
to fix the issue at hand. I'll keep working with
them and keep updating the bug as and when we have
an update.

## bagel

One of the tests, ASD_DMRG, seemed to be failing on
s390x but when asked upstream, that test is "meant
to fail". Only by chance, it's failing on s390x for
us, so as intended upstream, I've patched bagel to
skip this test and everything seems to be working
(and passing) in bagel/1.2.2-3ubuntu1.

## mat2 (debbug #1002418)

src:mat2 was regressing with the new
libimage-exiftool-perl upload, resulting in an
AssertionError. This was already addressed
upstream but not in Debian or Ubuntu. Since there
was an RC bug (#1002418) open in Debian, I uploaded
an NMU there and things are now fixed via the
mat2/0.12.2-1.1 upload.

## ugrep

src:ugrep was stuck in proposed migration as it
was regressing src:forensics-extra on armhf.
Simply re-triggering the package on armhf made
it pass and src:ugrep has now migrated.

## esys-particles

Both, Gianfranco and myself, took a look at this
and the more we look at it, the crazier it gets. :)

This seems to be working in Debian perfectly
but somehow not on Ubuntu and the log says that
it can't find the said modules and this is very
much reproducible in an LXD container but we
couldn't find what was up with that. We suspect
that as the Python transition moves forward,
this will settle on its own, with a simple
re-trigger. So until then, we've left this as-is
and will revisit later, towards the end of the

## ruby-fast-gettext (debbug #1002103)

There seemed to be FTBFS due to two reasons -
one, because of ruby3.0, related to tainting of
code, and two, because of API change in rails 6.
I was able to reproduce and fix them both via
2.0.3-1ubuntu2. Also, fixed the same in Debian
via 2.0.3-2 and furthermore, sent the patch
upstream via PR #136.

## python-sop

src:python-sop was stuck in proposed migration
as it was failing autopkgtest on armhf. Simply
re-triggering the package on armhf made it pass
and src:python-sop has now migrated.

## cmark-gfm (LP: #1958235)

This will probably be the highlight of my +1, heh.
cmark-gfm/0.29.0.gfm.2-1, which got auto-sync'd
from Debian was a soname bump and it started a
transition. It also slipped the maintainer's eye
and it resulted in breaking a handful of packages,
namely, pandoc, pandoc-citeproc, blogliterately,
gitit, and patat, at least. Christian noticed this
immediately and opened the bug and asked me to TAL.
I reverted the upstream version back to what it was
to temporarily stop the (bad) transition and uploaded
a fix via 0.29.0.gfm.2-1+really.0.29.0.gfm.0ubuntu1.
Quite a version, I know. :)

Meanwhile, this is being handled on the Debian side
and I'll make this a sync again later next week.

## phpmyadmin (LP: #1955284)

Two of the tests had been failing for so long
on s390x in Debian and Ubuntu, both. Whilst
Debian's failure doesn't prevent the migration,
Ubuntu's does. These tests have a problem on
32-bit problem and I wrote a patch for upstream
and it got accepted a few weeks back. However,
now it looks like these tests don't really
help with anything and are somewhat useless,
we (I and upstream) have decided to drop this.
As a result, I've dropped this in Ubuntu and
uploaded a fix via 4:5.1.1+dfsg1-5ubuntu1.

## php-symfony-polyfill

src:php-symfony-polyfill FTBFS'd with PHP 8.1.
I added a patch as a delta since Debian hasn't
yet reached that point of transition and
uploaded a fix via 1.24.0-1ubuntu1. It now works
well w/ PHP 8.1 and gets us closer to completing
the transition.

## php-league-commonmark

src:php-league-commonmark has a "risky" test that
was failing on s390x which stopped the migration
of php-symfony-polyfill upload. A couple of re-tries
made it pass and so did php-symfony-polyfill.

## libmarc-xml-perl

src:libxml-libxml-perl was stuck in proposed
migration as it regressed src:libmarc-xml-perl.
However, during the LHF, I investigated a bit
more and Gregor uploaded a fix and I re-triggered
the package with the right triggers and both,
src:libxml-libxml-perl and src:libmarc-xml-perl
have migrated.

## sdlgfx

src:sdlgfx was stuck in proposed migration as
it was regressing src:libalien-sdl-perl and
src:libsdl-perl on armhf. Since I am also a
part of the Perl team and I knew this was
a false-positive, simply re-triggering made
it pass and src:sdlgfx migrated to Jammy.

## libtap-parser-sourcehandler-pgtap-perl

src:libtap-parser-sourcehandler-pgtap-perl was
stuck in proposed migration as it was failing
autopkgtest on armhf. Simply re-triggering the
package on armhf made it pass and it has now

## python-flask-marshmallow (debbug #989269)

The old version of python-flask-marshmallow was
rather useless and had no real documentation
available to the users. This version has been
there since Focal and I did the new upstream
release of the same in Debian via 0.14.0-1
and got it sync'd in for Jammy, the new LTS.

## doctrine/php-doctrine-*/php-defaults

This is a case of us running into a circular
dependency hellhole. To fix doctrine, we need
to fix php-doctrine-persistence, which needs
a fixed php-doctrine-common and a fixed
php-doctrine-persistence, which then depends
on doctrine, indirectly. This loop makes the
whole situation very chaotic and none of the
said packages build because of the "dependency
problem" now. As the first step, I opened
LP: #1958646 to drop the newer version of the two
source packages from jammy-proposed. Thanks,
Lukasz, for assisting that. After I worked this
whole thing out, it seems we will need an AA
to drop a few of these packages from Jammy
temporarily or introduce newer binary packages
in the archive. Either way, I'll follow with
some AA. (CC: Bryce).

## ruby-redis-rack, ruby-voight-kampff, thin

The above three packages were failing on arm64
and amd64 and simply re-trying the autopkgtest
made them pass, which in turn opened up the
gateway for a few more Ruby packages.

## ruby-rack

src:ruby-rack FTBFS'd and had a failing autopkgtest
because webrick is no more embedded in ruby3.0,
rather it is available as a separate package.
I uploaded a fix to Debian via 2.2.3-4 and to Ubuntu
via 2.1.4-5ubuntu1 - to prevent the new minor
version of rack auto-syncing, esp. until ruby3.0
has completely transitioned.

- u

ubuntu-devel mailing list
Modify settings or unsubscribe at:

Re: Proposal: revert recent debianutils changes for Jammy

On 2022-01-24 15:27, Dimitri John Ledkov wrote:
> Longer term it would be easier if we do a merge from debian now to
> preserve just the `export NO_PKG_MANGLE=1` delta (if that is still
> required),

Setting that variable was my idea. The reason is that without it, the
translation files are stripped at build time and imported to Launchpad.
But we have no use for those particular translations; they are for man
pages only, and the language packs don't deal with man pages.
(Previously we have tricked the translators to spend time with those
strings unnecessarily.)

If that's the only remaining Debian/Ubuntu delta, I think we should try
to have Debian set that variable. It makes no difference to Debian, but
is useful for us. Then we can sync again.

Gunnar Hjalmarsson

ubuntu-devel mailing list
Modify settings or unsubscribe at: