Call for testing: 22.04.3 release candidate images ready!

[Paride Legovini]

Hello everyone,

We just finished building our first set of 22.04.3 release candidate
images, which are now available for testing from the ISO tracker:

https://iso.qa.ubuntu.com/qatracker/milestones/447/builds

Please pick your favorite flavor and start testing! And be sure to
report your results on the ISO tracker above. Caveats:

- A couple of risc-v images aren't ready yet (nezha, unmatched).
  They should be appear in the ISO tracker within a few hours.

- The ISO tracker link to the Ubuntu Desktop images does not point
  to the right location. The correct location is:
  https://cdimage.ubuntu.com/jammy/daily-live/20230807.2/

As with every recent release, we have a discourse thread for tracking
progress which we try to keep up to date as much as possible:

https://discourse.ubuntu.com/t/focal-fossa-20-04-5-lts-point-release-status-tracking/29969

--
Paride

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

Re: git-ubuntu build

[Paride Legovini]

Steve Langasek wrote on 13/06/2023:
> On Mon, Jun 12, 2023 at 09:37:56PM +0200, Adrien Nader wrote:
> 
>> I think Steve has an SSH config which defines the "lp" host. What you'> 
> 
> This is the following in my ~/.gitconfig:
> 
> [url "git+ssh://vor...@git.launchpad.net/"]
> insteadof = lp:
> 
> This configuration is described here:
> 
>   https://help.launchpad.net/Code/Git
> 
> We should probably make sure it gets into some Ubuntu documentation and not
> just Launchpad documentation.

The drawback of this config is that with newer versions of Breezy it
gets in the way of Bazaar operations. The relevant change may be [1], in
Ubuntu since Lunar IIRC.

What happens is that Breezy finds the lp: shorthand and resolves it to a
Git URL, then fails if we were actually pointing it to a Bazaar repo.

For example this fails on my Mantic system if I use lp: for Git:

  bzr branch lp:~ubuntu-core-dev/meta-release/ubuntu

I now use lpad: as a shorthand for Launchpad Git repos:

[url "ssh://par...@git.launchpad.net/"]
insteadOf = lpad:

Paride

[1] https://bazaar.launchpad.net/~brz/brz/trunk/revision/7576

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

Re: DEP8 timeouts on install phase

[Paride Legovini]

Paride Legovini wrote on 09/03/2023:
> Hi Andreas,
> 
> Andreas Hasenack wrote on 08/03/2023:
>> Hi,
>>
>> taking this as a sample:
>>
>> https://autopkgtest.ubuntu.com/packages/f/fdroidserver/lunar/ppc64el
>> <https://autopkgtest.ubuntu.com/packages/f/fdroidserver/lunar/ppc64el>
>>
>> It looks like something got slower since a few days ago, and tests
>> started being killed due to a timeout ("kind: install" timeout, which
>> has a default of 3000s in autopkgtest).
>>
>> By the end of February 2023, the passing tests were taking about 20min.
>> Then a little bit more up to 26min in March 2nd, and then they all
>> started to fail.
>>
>> Looking at the logs, we see apt-get install being interrupted by the
>> autopkgtest timeout mid package download:
>>
>> Get:242 http://ftpmaster.internal/ubuntu <http://ftpmaster.internal/ubuntu> 
>> lunar/universe ppc64el apksigner all 31.0.2-1 [438 kB]
>> Get:243 http://ftpmaster.internal/ubuntu <http://ftpmaster.internal/ubuntu> 
>> lunar/main ppc64el openjdk-17-jdk-headless ppc64el 17.0.6+10-1 [217 MB]
>> autopkgtest-virt-ssh [04:23:09]: --- nova console-log 
>> 766e17f7-5365-4cdf-8202-35b6b88a7cdc 
>> (adt-lunar-ppc64el-fdroidserver-20230303-012357-lrg-root5) --
> 
> For some reason a few days ago the connection between te bos01 and bos02
> datacenters to ftpmaster.internal got extremely slow. Download speeds
> are of the order of 100kB/s, sometimes even less, while downloading from
> the Internet (archive.ubuntu.com) works just fine (so it is not storage).
> 
> AIUI the connection from bos0[12] to ftpmaster passes through an haproxy
> and then an IPsec tunnel crossing an ocean. While maybe not ideal, the link
> was ~10 times faster up to a few days ago.
> 
> I filed a ticket about it with the details I could gather. If that's not
> sorted out Soon(tm) we can workaround the issue by switching to
> us.archive.ubuntu.com or by bumping the timeouts.

This is half worked around now: one of the two datacenters which host
the ppc64/s390x/arm64 autopkgtest VMs now has fast connectivity to
ftpmaster.internal, and the other is not as slow as before (perhaps
some link is less loaded now?). So we shouldn't be hitting as many
timeouts as before.

I'm trying to have the other datacenter get the same treatment.

Paride

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

Re: DEP8 timeouts on install phase

[Paride Legovini]

Hi Andreas,

Andreas Hasenack wrote on 08/03/2023:
> Hi,
> 
> taking this as a sample:
> 
> https://autopkgtest.ubuntu.com/packages/f/fdroidserver/lunar/ppc64el
> 
> 
> It looks like something got slower since a few days ago, and tests
> started being killed due to a timeout ("kind: install" timeout, which
> has a default of 3000s in autopkgtest).
> 
> By the end of February 2023, the passing tests were taking about 20min.
> Then a little bit more up to 26min in March 2nd, and then they all
> started to fail.
> 
> Looking at the logs, we see apt-get install being interrupted by the
> autopkgtest timeout mid package download:
> 
> Get:242 http://ftpmaster.internal/ubuntu  
> lunar/universe ppc64el apksigner all 31.0.2-1 [438 kB]
> Get:243 http://ftpmaster.internal/ubuntu  
> lunar/main ppc64el openjdk-17-jdk-headless ppc64el 17.0.6+10-1 [217 MB]
> autopkgtest-virt-ssh [04:23:09]: --- nova console-log 
> 766e17f7-5365-4cdf-8202-35b6b88a7cdc 
> (adt-lunar-ppc64el-fdroidserver-20230303-012357-lrg-root5) --

For some reason a few days ago the connection between te bos01 and bos02
datacenters to ftpmaster.internal got extremely slow. Download speeds
are of the order of 100kB/s, sometimes even less, while downloading from
the Internet (archive.ubuntu.com) works just fine (so it is not storage).

AIUI the connection from bos0[12] to ftpmaster passes through an haproxy
and then an IPsec tunnel crossing an ocean. While maybe not ideal, the link
was ~10 times faster up to a few days ago.

I filed a ticket about it with the details I could gather. If that's not
sorted out Soon(tm) we can workaround the issue by switching to
us.archive.ubuntu.com or by bumping the timeouts.

Paride

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

[Paride Legovini]

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: Setting NotAutomatic for hirsute+1-proposed

[Paride Legovini]

Sebastien Bacher wrote on 22/11/2022:
> Le 22/11/2022 à 20:24, Julian Andres Klode a écrit :
>> We have no idea why the test dependencies are failing to install in a 
>> normal setup,
> 
> Which case are you talking about? The dbus issue is clear, the base 
> image used by the autopkgtest infra is build from kinetic with 
> kinety-security versions of packages but the apt source are lunar ones 
> without proposed. The packages are failing to install because 
> kinetic-security has updates which are in lunar-proposed but didn't 
> migrate to lunar.

A follow-up on this. The curl package also had the same issue, as
the version in kinetic was newer than the version in lunar-release. Now
curl migrated, and we are not aware of other problematic packages (i.e.
packages in the lunar autopkgtest images which are not available in
lunar-release). So for the Lunar cycle this issue is behind us.

Starting from the MM cycle we'll generate the early autopkgtest images
using the *release* images of the previous release, instead of using
dailies. In this way we'll avoid having packages in the autopkgtest
images which are not in the release pocket of the new devel release.

Paride

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

[Paride Legovini]

Hi Jeremy,

Jeremy Bicha wrote on 22/11/2022:
> On Tue, Nov 8, 2022 at 6:05 AM Paride Legovini  wrote:
>> Steve Langasek wrote on 01/11/2022:
>>> I have set the flag now for lunar as it came up in discussion with
>>> Foundations.  The question of whether to change this for stable series is
>>> still open (now with some further series that are stable) but can be
>>> discussed separately.
>>
>> I very much welcome this change, but I think we're now missing an easy
>> way to build (sbuild) packages with -proposed fully enabled. schroots
>> created by mk-sbuild and sbuild-launchpad-chroot may have -proposed in
>> sources.list, but that's not going to be used in >= Lunar. On Launchpad
>> some extra pinning is done to fully enable -proposed [1].
>>
>> One way to re-enable easy builds with full -proposed could be modifying
>> sbuild-launchpad-chroot (/etc/schroot/setup.d/90apt-sources) to do the
>> same pinning that Launchpad does [1]. Once we have a way to sbuild with
>> -proposed enabled I think enabling NotAutomatic for the stable releases
>> would be a good idea: other than helping with SRU verification, the
>> change will keep the -proposed behavior uniform across releases.
>>
>> Paride
>>
>> [1]
>> https://git.launchpad.net/launchpad-buildd/commit/?id=c2ebcb6752af496166a5fffd9df3a4d6df6048ef
> 
> Gianfranco pointed out that there are dbus installability problems in
> the lunar autopkgtests. For instance:
> https://autopkgtest.ubuntu.com/packages/c/cinnamon-control-center/lunar/amd64
> 
> libdbus-1-dev : Depends: libdbus-1-3 (= 1.14.0-2ubuntu2) but
> 1.14.0-2ubuntu3 is to be installed
> 
> dbus 1.14.0-2ubuntu3 is built and I think it was published correctly
> but it hasn't migrated out of lunar-proposed yet.
> 
> Is the breakage fallout from the changes to how proposed is handled for lunar?

Not really: this is due to a version skew in the archive caused by
a dbus SRU upload done to Kinetic before Lunar was open. This caused the
dbus version in kinetic-updates to be newer than the version in
lunar-release.

The dbus package has now need force-migrated from lunar-proposed to
-release (currently pending publication). This should fix the issue.


One (unrelated) autopkgtest aspect that is affected by NotAutomatic: yes
is triggering tests with all-proposed=1. This is currently not working
as expected as we're not setting the pin yet.

Paride

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

[Paride Legovini]

Steve Langasek wrote on 01/11/2022:
> I have set the flag now for lunar as it came up in discussion with
> Foundations.  The question of whether to change this for stable series is
> still open (now with some further series that are stable) but can be
> discussed separately.

I very much welcome this change, but I think we're now missing an easy
way to build (sbuild) packages with -proposed fully enabled. schroots
created by mk-sbuild and sbuild-launchpad-chroot may have -proposed in
sources.list, but that's not going to be used in >= Lunar. On Launchpad
some extra pinning is done to fully enable -proposed [1].

One way to re-enable easy builds with full -proposed could be modifying
sbuild-launchpad-chroot (/etc/schroot/setup.d/90apt-sources) to do the
same pinning that Launchpad does [1]. Once we have a way to sbuild with
-proposed enabled I think enabling NotAutomatic for the stable releases
would be a good idea: other than helping with SRU verification, the
change will keep the -proposed behavior uniform across releases.

Paride

[1]
https://git.launchpad.net/launchpad-buildd/commit/?id=c2ebcb6752af496166a5fffd9df3a4d6df6048ef

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

Testing Ubuntu Release Upgrades (auto-upgrade-testing)

[Paride Legovini]

Hey -devel,

The Ubuntu QA Team brought back to the archive a tool that allows
automated upgrade tests of Ubuntu releases: that's the
auto-upgrade-testing package, available for Kinetic users.

The tool leverages the autopkgtest tooling to setup a VM running a given
Ubuntu release, upgrades it via do-release-upgrade, and tests that the
results match some expected conditions.

I published a Discourse post on how to use the tool:

https://discourse.ubuntu.com/t/testing-ubuntu-release-upgrades/30889

and I'll follow up with a second post on how to write upgrade profiles.
Feedback is welcome on both the tool and the post.

Happy testing!

Paride

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

Re: +1 maintenance day report

[Paride Legovini]

Michael Hudson-Doyle wrote on 19/07/2022:
> On Tue, 19 Jul 2022 at 05:31, Paride Legovini  wrote:
> 
> qiime:
>>  - holding 2 packages
>>  - direct autopkgregression on armhf, with error:
>>AssertionError: dtype('int64') != 
>>  - I wasn't expecting this to ever pass on armhf and did a
>>migration-reference/0 retrigger, but it actually passed!
>>  - I expect the package to now be a candiate.
>>
> 
> This is backwards, I think? The reference test succeeded but the new
> version fails --> this is a regression on armhf. However the Debian
> maintainer has requested removal on 32 bit arches:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014692. I guess we
> should follow.

Right, this is a force-badtest case, thanks. To finish up the job:

https://code.launchpad.net/~paride/britney/+git/hints-ubuntu/+merge/427073

Despite that RM bug the Debian maintainer didn't do an upload dropping
the 32bit archs yet, so a hint looks appropriate to me for now.

Paride

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

+1 maintenance day report

[Paride Legovini]

Note: search the message for "HANDOVER" for what I believe is a bitesize
task that will unblock a migration (I didn't get to it in time).

--

I spent some time trying to figure out why autopkgtests for src:pyside2
take between 2 and 3 hours in Ubuntu and about 25 minutes in Debian, see:

- https://autopkgtest.ubuntu.com/packages/pyside2/kinetic/amd64
- https://ci.debian.net/packages/p/pyside2/unstable/amd64/

but I didn't get to a definitive conclusion. The only thing I can say
is that I don't think there's a single step slowing down the test run,
but it's overall slower. The test has a lot of dpkg operations, and
hence a lot of filesystem sync operations. Perhaps the Debian infra
is making more/better use of eatmydata-like tricks.

Coming to migration excuses, I worked on:

perl:
 - holding 18 other packages
 - causes two regressions:
   - cluster-glue/1.0.12-20ubuntu/ppc64el
 Retriggered and it passed, see:
 https://autopkgtest.ubuntu.com/packages/cluster-glue/kinetic/ppc64el
   - adduser/3.121ubuntu1/i386
 This one requires a hint (thanks bdmurray and vorlon for the pointers):
 https://code.launchpad.net/~paride/britney/+git/hints-ubuntu/+merge/427039
   - hint merged (thanks vorlon)
 - perl should be able to migrate now.

ssreflect: 
 - holding 7 other packages
 - mini transition (src:coquelicot needs to be rebuilt)
 - A new src:coquelicot upload is already in -proposed, but the arm64
   build was unlucky and built against the old version of ssreflect.
 - Did a no-change rebuild upload of src:coquelicot
 - The autopkgtest now pass: 
   https://autopkgtest.ubuntu.com/packages/coquelicot/kinetic/arm64
 - I expect the package to now be a candiate.

webkit2gtk:
 - holding 4 packages
 - Causes test regression on src:surf on armhf.
   It was already retriggered by jbicha. I tried again and it failed.
 - I triggered a surf autopkgtest run without -proposed triggers
   (trigger=surf/2.1+git20220504-1). It failed, so the failure has
   actually nothing to do with webkit2gtk.
 - Passes in Debian:
   https://ci.debian.net/data/autopkgtest/unstable/i386/s/surf/23618675/log.gz
 - I didn't get to the bottom of this.

rakudo:
 - holding 3 packages, 50 days old 
 - mini transition, did no-change rebuild uploads of:
   - perl6-readline
   - raku-tap-harness
 - retriggered builds of (previously FTBFS on all archs):
   - raku-getopt-long (succeeding, s390x not built yet while writing)
 - we'll see if there's anything else blocking with the next britney run.

mathcomp-multinomials:
 - holding 3 packages
 - missing builds on all archs but riscv64
 - reason: missing b-deps (riscv64 got lucky because it slow)
 - retriggered builds; built everywhere but on arm64.
 - reason for missing arm64 build:
   .
   The following packages have unmet dependencies:
libcoq-mathcomp-bigenough : Depends: libcoq-mathcomp-ssreflect-94ef7
   E: Unable to correct problems, you have held broken packages.
   .
 - HANDOVER: I think we just need a no-change rebuild of
   src:mathcomp-bigenough to rebuild against a newer ssreflect.

fonttools:
 - holding 3 packages
 - causes regression in glyphslib/5.3.2+ds1-1
 - the failure also happens in Debian:
   https://ci.debian.net/packages/g/glyphslib/unstable/amd64/
 - Debian (release critical) bug:
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013363
 - filed update-excuse bug linking to the Debian bug:
   https://bugs.launchpad.net/debian/+source/fonttools/+bug/1981989

qiime:
 - holding 2 packages
 - direct autopkgregression on armhf, with error:
   AssertionError: dtype('int64') != 
 - I wasn't expecting this to ever pass on armhf and did a
   migration-reference/0 retrigger, but it actually passed!
 - I expect the package to now be a candiate.
 - cool that we have a tool for microbiome analysis :)

neovim:
 - missing build: s390x
 - retrigged build and it worked
 - I expect the package to now be a candiate.

Cheers,

Paride

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

Re: +1 maintenance _day_ report

[Paride Legovini]

Hi Michael!

Michael Hudson-Doyle wrote on 23/06/2022:
> On Thu, 23 Jun 2022 at 01:33, Paride Legovini  <mailto:par...@ubuntu.com>> wrote:
> 
> - I polished some local changes I had to allow autopkgtest-virt-lxd to
> run tests in LXD VMs, and submitted this upstream [3]. I think
> testing/feedback from Ubuntu developers is needed there. If that gets
> merged we could consider running the armhf tests in LXD VMs, avoiding
> issues like the firejail one I mentioned above.
> 
> 
> Do we publish images that work with lxc launch --vm on armhf? I didn't
> think we did. Getting armhf autopktests into VMs would be great though.

LXD VMs images are there (see: lxc image info ubuntu:jammy/armhf --vm),
but as I learned today LXD doesn't support 32bit archs, and therefore
armhf, so my plan isn't going to work after all :/

Still I think being able to run tests in LXD VMs is a nice addition to
autopkgtest-virt-lxd.

Paride

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

+1 maintenance _day_ report

[Paride Legovini]

Hi -devel,

As part of the newly formed Ubuntu QA team [1] I'm doing a shorter 1-day
+1 maintenance rotation which, other than helping with the usual +1
duties, is a practical way for me to monitor the state of the
autopkgtest infrastructure. Here is the summary for this week.

## Migrations

- plink1.9, stuck in kinetic-proposed for >130 days due to an
autopkgtest regression. Failure identified as an LTO issue. Package
added to lto-disabled-list (LP: #1979247), followed by a no-change
upload. It migrated.

- firejail, stuck in proposed due to autopkgtest regression on armhf.
Issue identified as due to new tests requiring (at least) a privileged
container to success, while the Ubuntu armhf testbed system is an
unprivileged LXD container. I uploaded a workaround (restricting the
failing test to isolation-machine, see LP: #1979358), and also filed
Debian bug on this [2]. After a fruitful discussion with the Debian
maintainer I merged a new package version from Debian, this one
requiring the workaround (tested by triggering autopkgtests from a PPA;
package currently in -proposed). I also suggested a possible way to drop
the only delta the package currently has.

## Tooling

- I polished some local changes I had to allow autopkgtest-virt-lxd to
run tests in LXD VMs, and submitted this upstream [3]. I think
testing/feedback from Ubuntu developers is needed there. If that gets
merged we could consider running the armhf tests in LXD VMs, avoiding
issues like the firejail one I mentioned above.

- I submitted another MR to autopkgtest upstream to update the
documentation to make it explicit that the isolation-container
restriction does not imply that the container is privileged.

## Misc

- I updated the ProposedMigration wiki page [5] to suggest that strange
FTBFS/crashes in newer Ubuntu releases not seen in Debian may be due to
LTO, and that it's worth checking.

Paride

[1] https://discourse.ubuntu.com/t/introducing-the-ubuntu-qa-team/28951
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013326
[3] https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/160
[4] https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/161
[5] https://wiki.ubuntu.com/ProposedMigration

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

Re: Proposal: move byobu (and run-one) to universe

[Paride Legovini]

Dan Streetman wrote on 10/05/2022:
> On Tue, May 10, 2022 at 3:41 PM Brian Murray  wrote:
>>
>> On Tue, May 10, 2022 at 02:55:43PM -0400, Dan Streetman wrote:
>>> On Wed, May 4, 2022 at 11:22 AM Paride Legovini  wrote:
>>>>
>>>> Hi -devel,
>>>>
>>>> The status of src:byobu appears to be less than ideal, and this has been
>>>> the case for several cycles now. I think we should consider moving it
>>>> from main to universe in kinetic. The general feedback from the Server
>>>> Team about this proposal is positive. We are not aware of anything
>>>> specific that could be broken or degraded by the change, however we'd
>>>> like to hear feedback from other developers and users before proceeding.
>>>> This is also tracked in [0].
>>>
>>> just for clarification, besides being installed by default on servers
>>> (due to being seeded in ubuntu-server) the only other effect that
>>> demoting the package from main to universe would have is that the
>>> server team would no longer monitor its LP bugs, right?
>>
>> No, because the package is available in main for a supported release
>> (Ubuntu 22.04) the server team would need to continue to monitor its LP
>> bugs (by being subscribed to the package) until the last supported
>> release that included the package in main is out of standard support.
>> This way they can catch and resolve any serious issues with the package.
> 
> so the only practical effect of the demotion (besides the server team
> ending their package bug monitoring in 5+ years) would be it is not
> installed by default on servers?

Well, yes, but that's a bit reductive with respect to what being in main
means: we also commit to fix those bugs, and same for src:run-one (in
main only as a dependency of byobu, same situation as byobu). As the
status quo is that today the package wouldn't have the MRE requirements,
and that incoming bugs always get low priority, it just feels right to
me to move it to universe.

However from this thread and other discussions it's apparent that people
see value in byobu being installed by default on Server, and this can
only happen if the package is in main. Also byobu "just works": there
are bugs, bug no high impact bugs. My idea is to snooze this proposal
for now, and bring it up again in case a future devel release breaks
byobu in a way that's not easy to fix (e.g. new tmux version with
breaking changes in its interface).

Paride

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

Proposal: move byobu (and run-one) to universe

[Paride Legovini]

Hi -devel,

The status of src:byobu appears to be less than ideal, and this has been
the case for several cycles now. I think we should consider moving it
from main to universe in kinetic. The general feedback from the Server
Team about this proposal is positive. We are not aware of anything
specific that could be broken or degraded by the change, however we'd
like to hear feedback from other developers and users before proceeding.
This is also tracked in [0].

Rationale:

 - Upstream has very little activity [1];
 - Bugs filed against the project are mostly not watched/triaged;
 - Bugs filed against the package do get triaged but are never
   prioritized, and fixes are normally not SRUed;
 - I don't think the package would have the MIR requirements [4] today;
 - Possibly anecdotal: I don't think the package has widespread usage.

Currently we have:

$ reverse-depends -c main byobu
* ubuntu-server
* ubuntu-server-raspi [arm64 armhf]
* ubuntu-wsl [amd64 arm64]

so we'd only need to change the seeds to demote.

Side effects:

The run-one package is seeded as a dependency of byobu, it has no other
reverse dependencies in main. To be evaluated if it makes sense to
explicitly seed it or demote it too.

Paride

[0] https://bugs.launchpad.net/ubuntu/+source/byobu/+bug/1965944
[1] https://code.launchpad.net/~kirkland/byobu/trunk
[2] https://bugs.launchpad.net/byobu/+bugs?orderby=-id&start=0
[3]
https://bugs.launchpad.net/ubuntu/+source/byobu/+bugs?orderby=-id&start=0
[4] https://wiki.ubuntu.com/MainInclusionProcess

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

Status of mailman3 in Jammy

[Paride Legovini]

Hi, about one month ago mailman3 has been removed from Jammy as it was
blocking migrations and because of its bad state in Debian [1].

mailman3 is in universe, however I think it's one of those packages we
want to keep keep an eye on, we even considered a MIR for it a few
cycles ago. Moreover mailman3 users upgrading from Focal to Jammy will
have their mailman3 setup broken by the newer (incompatible)
dependencies, which is not nice.

I checked what the blockers are to get mailman3 in better shape and
found out the following:

1. autopkgtest failures with newer versions of python-click

Debbug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997877

I believe this is fixed upstream version 3.3.5 by:

https://gitlab.com/mailman/mailman/-/commit/5d27492403f80c4b4ea1820b3

---

2. autopkgtest failures in the arc_validate tests

Debbug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996806

Fixed upstream by

https://gitlab.com/mailman/mailman/-/commit/f311b135fe13e3ec07ef2eedad

but this requires newer dependencies, in particular src:mistune (>=
2.0.0). Note that currently we have mistune 2.0.0-1+really0.8.4-1, so
there was an attempt to update it, but it was rolled back due to
reverse-dependencies not ready yet (per d/changelog). This is probably
not trivial to fix (transition).

---

3. autopkgtest fails with sqlalchemy 1.4.23+ds1

Debbug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995779
Upstream bug: https://gitlab.com/mailman/mailman/-/issues/845

This has been worked around upstream by requiring sqlalchemy <1.4, but
in Debian/Ubuntu that requirement can't be satisfied as we're already
ahead of that version. The upstream issue is still open, latest activity
is of 7 months ago. Not a straightforward fix.

---

I was hoping to kick mailman3 into shape with an ahead-of-Debian merge,
but this is not the case: this isn't a drive-by fixup.

Give where we are in the cycle we'll likely have to accept that "no
mailman3 in Jammy" will go into the release notes, and hopefully at some
point we'll be able to add it with a "new functionality SRU".

I wonder if we should do a mailman3 upload to Focal and Impish with
stricter versioned dependencies, so that upgrading to Jammy will require
explicitly removing mailman3, which is my opinion is better than
breaking it silently.

Paride

[1] https://bugs.launchpad.net/ubuntu/+source/mailman3/+bug/1960547

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

Re: Should we change the behaviour of -P for lsblk in util-linux for Jammy?

[Paride Legovini]

Bryce Harrington wrote on 18/02/2022:
> On Thu, Feb 17, 2022 at 01:00:07PM +1300, Matthew Ruffell wrote:
>> Hi all,
>>
>> I'm looking for a bit of advice about landing a new feature in util-linux, as
>> things have gotten a little complicated, and with feature freeze looming, a
>> second opinion would be much appreciated.
>>
>> e.g. lsblk -P now outputs LOG_SEC instead of LOG-SEC.
>>
>> So, what I need advice on is the next steps. Should we:
>>
>> 1) Do nothing, accept 2.32.2 behaviour for -P in Jammy, which is a change 
>> from
>> Focal/Impish, and will abruptly change again with the release of 2.38 likely 
>> to
>> land in KK. MAAS and Curtin are already fixed, no issues there, users must
>> upgrade to latest stable MAAS and curtin on Jammy release. Older Curtin and 
>> MAAS
>> will break.
>>
>> 2) Backport the new 10+ commits into 2.27.2 in Jammy and hope we don't cause 
>> any
>> regressions with the significant amount of code being changed. We keep the 
>> same
>> behaviour that users expect from Focal/Impish, and users can now use
>> -y / --shell if they want. Older MAAS and Curtin continue to work.
>>
>> 3) Revert the single patch which caused all of this,
>> 58b510e580 libsmartcols: sanitize variable names on export output
>> which is a tidier and well tested solution, and drop the patch when 
>> util-linux
>> is rebased to 2.38 in KK. This keeps existing behaviour in Focal/Impish, and
>> enables older MAAS and Curtin to keep working.
>>
>> I'm leaning toward suggesting 3) at this stage, but this is mostly to keep
>> existing users happy on their older versions of MAAS.
> 
> I think your hunch for #3 does sound like the safer approach to me as
> well.  Unless there's a huge number of users asking for the new feature,
> those who do need it can either wait until it's generally available, or
> use a workaround with some awk filters or whatnot.

I'm also +1 on option (3). The issue I can see with (3) is with
downstream software parsing  `lsblk --version` to know how to deal with
the output of -P. However (2) is not a solution for this (we'd still
diverge from the upstream behavior for that version) and option (1) has
the issues you mentioned.

Paride

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

Re: Bumping the baseline on ppc64el in jammy to POWER9

[Paride Legovini]

Christian Ehrhardt wrote on 09/12/2021:

On Thu, Dec 9, 2021 at 2:25 PM Matthias Klose  wrote:


This weekend, we will bump the baseline for the ppc64el architecture to POWER9.


Hi Doko,
to understand this right, the new will be -march=power9 then?

If yes, that implies that any power8 test machine won't be usable for >=jammy.
I just wanted to spell this out so that the implication is clear since
I think while
P8 machines are old they are in common use as test system AFAIK.


Indeed the machine we use to test the ppc64el server ISOs is a POWER8E.

Paride

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

Re: liburing1 -> liburing2 transition

[Paride Legovini]

Paride Legovini wrote on 19/11/2021:

This will be a small transition, only affecting the following packages:
Package: qemu
Package: samba
Package: mpd
Package: plocate


An update on this: while the transition by itself is small, mpd causes 
it to intersect with two other (auto-)transitions which are currently 
happening:


- fluidsynth (SONAME bump: libfluidsynth2 -> libfluidsynth3)
- libopenmpt (new symbols => new binary relationships).

In the hope of simplifying things I filed a bug asking for fluidsynth to 
be temporarily pulled from jammy-proposed:


https://bugs.launchpad.net/ubuntu/+source/fluidsynth/+bug/1952918

OTOH libopenmpt has the following excuse:

* removing libopenmpt-modplug1/0.4.22-1/i386 from testing makes 
vlc-plugin-base/3.0.16-1/i386 uninstallable


Note that this is an i386 thing. AIUI this is happening because 
libopenmpt-modplug1 used to come from src:libopenmpt, but got moved to a 
separate source package (src:libopenmpt-modplug), which was first synced 
in Jammy. This package isn't in the i386 seed germinate output [1]; I 
was confused at first, but I think the reason is that the actual vlc 
Build-Dep is:


  libopenmpt-modplug-dev | libmodplug-dev (>= 1:0.8.9)

which *is* satisfied in the germinate list via libmodplug-dev, however 
vlc-plugin-base still has binary dependencies based on 
libopenmpt-modplug-dev (but FIXME!). This can be sorted out by:


(a) directly seeding libopenmpt-modplug for i386 (and doing [2]); or

(b) dropping libopenmpt-modplug1/i386 from the archive and doing a 
no-change rebuild of vlc. The new i386 vlc-plugin-base will then rely on 
libmodplug. This isn't really nice as the i386 deps will be different 
from the other archs, but at least it won't grow the i386 seed.


Here the ball goes to the Archive Admins.

Paride

[1] 
https://people.canonical.com/~ubuntu-archive/germinate-output/i386.jammy/i386+build-depends

[2] https://wiki.ubuntu.com/ArchiveAdministration#i386_whitelist_updates

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

Re: liburing1 -> liburing2 transition

[Paride Legovini]

Simon Chopin wrote on 19/11/2021:

Hi Paride!

Quoting Paride Legovini (2021-11-19 15:23:57)

Hi -devel,

Next week me and Utkarsh will start the transition from liburing1 to
liburing2.

This will be a small transition, only affecting the following packages:

Package: qemu
Package: samba
Package: mpd
Package: plocate
Package: mariadb-10.6


This one will also be in the upcoming OpenSSL transition :/
I haven't filed a bug yet as it's in universe (I think I'll just script
it) but it FTBFS against libssl3:

https://people.canonical.com/~schopin/rebuilds/openssl-3.0.0-impish.html

There's some very recent activity upstream on that front:

https://jira.mariadb.org/browse/MDEV-25785
https://github.com/MariaDB/server/commit/c80991c79f701dac42c630af4bd39593b0c7efb4

As far as I understand it, this last patch is still being reviewed.


Hi Simon,

Thanks for the heads-up! Speaking of these transitions we probably do 
not need to worry about mariadb-10.6 too much, as the package never left 
jammy-proposed. We're still going to check that it builds against 
liburing2, but it has several other issues to be sorted out before 
migrating:


https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mariadb-10.6

Indeed the package is not listed by reverse-depends:

$ reverse-depends -b src:liburing
Reverse-Build-Depends

* mpd   (for liburing-dev)

* plocate   (for liburing-dev)

* qemu  (for liburing-dev)

* samba (for liburing-dev)


Paride

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

liburing1 -> liburing2 transition

[Paride Legovini]

Hi -devel,

Next week me and Utkarsh will start the transition from liburing1 to 
liburing2.


This will be a small transition, only affecting the following packages:

Package: qemu

Package: samba

Package: mpd

Package: plocate

Package: mariadb-10.6


but let us know if you have any concern about the timing or the 
transition itself. Hopefully we'll also be able to make liburing a sync 
from Debian as a result of this.


Thanks,

Paride

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

Re: +1 Maintenance Report

[Paride Legovini]

Christian Ehrhardt wrote on 01/10/2021:

# Help

Gladly this week Paride was so kind to help me and pick a few more +1 tasks.
That way some more than what I managed to resolve got done. I assume he will
reply to this thread with his own content he worked on this week.
Thanks @paride!


I basically worked on two cases:

# ulfius autopkgtest fail

The ulfius autopkgtest were failing on all the archs. After 
investigating (thanks Christian for the help there) the issue turned out 
to be with IPv6 testing: the autopkgtest testbed set the http_proxy env 
variable but doesn't add ::1 to no_proxy. I filed LP: #1945634 about it, 
hoping for a simple fix on the autopkgtest infra, but it turns out it 
isn't really simple (LP: #1908136).


In any case the bug can serve as a reference bug for packages affected 
by the same issue. I left the update-excuse tag so when bug tasks are 
added it will show up in update_excuses.


I patched the ulfius autopkgtest (debdiff attached to the bug); the 
patch is simple and should easily apply to other cases.


ulfius 2.7.1-3ubuntu1 migrated.

# mpv autopkgtest fail

mpv 0.33.1-1ubuntu1 was regressing the python-mpv autopkgtests on 
ppc64el. I identified this as a race condition in the upstream test 
suite, where an arbitrary sleep() is present. I filed an upstream issue 
and PR [1,2], and applied the patch as an Ubuntu delta for now.


Before uploading the package the fix was tested on the actual 
autopkgtest infra using a "testing against a PPA" trigger [3].


mpv 0.33.1-1ubuntu1 migrated.

# Tooling work

For $reasons I recently converted /var/lib/schroot to ZFS, but the naive 
approach (create dataset && copy stuff over && rename) didn't work as 
ZFS doesn't support overlay mounts (LP: #1718761), so my type=directory 
schroots didn't work anymore.


I wanted to recreate them as type=zfs-snapshot schroots, so I patched 
mk-sbuild to add support for them:


https://code.launchpad.net/~paride/ubuntu-dev-tools/+git/ubuntu-dev-tools/+merge/409346

(currently in Needs Review state). Once I get review/feedback on this 
I'll add something similar to sbuild-launchpad-chroot.


Paride

[1] https://github.com/jaseg/python-mpv/issues/178
[2] https://github.com/jaseg/python-mpv/pull/179
[3] https://wiki.ubuntu.com/ProposedMigration#Testing_against_a_PPA

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