Re: SRU shift report: 2023-05-24

Hi Robie,

On Thu, May 25, 2023 at 10:13 AM Robie Basak <robie.basak@ubuntu.com> wrote:
> It's been a while since I did one of these. It takes a while to write it
> up that I could be spending on reviewing more SRUs, but I did also get
> feedback that my last post was helpful. So I'll try to continue doing
> these now and again.

Thanks for doing this. I find these helpful and educational too.
By learning more about the thinking/process behind SRU reviews
I can prepare SRUs accordingly in advance, to avoid round trips
where possible, and hopefully help the SRU reviewers handle it.

> Feedback: please make sure your upload is marked Fix Released in the
> development release before uploading, or if that's not possible, then
> there's an explanation in the bug.

A related topic/question.

I recently wondered/asked whether uploading to stable releases
while the development release is marked Fix _Committed_ was OK.

I received clarification that the SRU(s) may be _accepted_,
but not _released_, which is reasonable and does help SRUs
to move to -proposed for verification.

However, that may take review cycles on unapproved queues
or -proposed pocket, before SRUs can actually be released,
or more reviews if further stable upload(s) are needed w/
fixups found while in devel-proposed; thus more info
(e.g., importance/urgency) would be helpful to evaluate.

I had to ask someone, as this particular case doesn't seem
to be documented in [1, 2], so I wondered if it should?
(In case it may help others w/ the same question in the future,
and also document the rationale/considerations to be done.)

Say, something similar to the feedback you wrote (eg devel
is marked Fix Released, or Fix Committed if needed/reasons
described in a comment), plus consider additional uploads.

Thanks!

--
Mauricio Faria de Oliveira

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

+1 maintenance report

Hi,

I was on my first +1 maintenance from May 29 to June 2.

I looked at packages that are FTBFS and stuck in the proposed migration due to
missing build. I spent some unexpectedly long time on the perl packages. I'm
more unfamiliar with this language than I thought..

1. gitlab-ci-multi-runner

The package has a long history of FTBFS both in Ubuntu and Debian.

Request removal https://launchpad.net/bugs/2021461

2. delve

FTBFS since it requires running bpftool, but bpftool is packaged differently
in Ubuntu and Debian. In Ubuntu it needs to match the running kernel. So not
possible to install the right one Ubuntu build environment. May need to
embed the bpftool output in the source package.

https://launchpad.net/bugs/2021481

3. librnd + camv-rnd + pcb-rnd

camv-rnd and pcb-rnd are in dep-wait status, it needs librnd > 4.
It's a small library transition. So I just ask @ginggs to kick off the
transition.

Also ask for revoking the blacklist for sch-rnd since it has stable release
now. https://launchpad.net/bugs/2007172

4. perl related packages

Several perl packages FTBFS (but no reproducible in Debian) with same test
failure:

As reported by Kernel: 'No such file or directory', perhaps the session
name is spelled incorrectly for this handler?

I debug them halfway. I may take a look next week as well.

5. godot

FTBFS in Debian too https://bugs.debian.org/1031132
Imported the bug to launchpad and added an update-excuse bug for reference.
There is a patch on BTS late this week.

6. libs3

FTBFS on ppc64el only. Caused by -Werror=stringop-overread. Looks like the
difference is -O3 vs -O2 build flags between Ubuntu and Debian.

Patch attached at https://launchpad.net/bugs/2021564

7. libtgowt

FTBFS on riscv64, but the previous version didn't. The new version needs
upstream explicit support in its build config. However this library is only
for building telegram-desktop.

Request removal https://launchpad.net/bugs/2021567

8. kickpass

FTBFS on amd64 due to LTO. Caused by a pie patch which is added by the
Debian maintainer (Can be safely dropped).

Patch attached at https://launchpad.net/bugs/2021577 and forwarded to
https://salsa.debian.org/debian/kickpass/-/merge_requests/1

9. pushpin

FTBFS on ppc64el, riscv64, s390x. Same on Debian, and Debian has removed
the packages on these architectures.
Request removal https://launchpad.net/bugs/2021594

10. eln

This package switches from QtWebkit to QtWebengine.
Request removal on ppc64el, riscv64, s390x.
https://launchpad.net/bugs/2022325

12. beaker

FTBFS due to tests relying on running redis server.
I don't think we can run a redis server during the build. The package
already ignores tests relying on mongodb server. So it should expand the
ignore list.

Patch https://launchpad.net/bugs/2022332, forwarded to
https://bugs.debian.org/1037035

13. yade

Killed after no activity. The last build takes 23 hours, so I expect it's
usual.
Retried and succeeded.

--
Shengjing Zhu

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

Re: NBS kernel removals: round two

On Thu, Jun 01, 2023 at 09:34:12PM +0100, Dimitri John Ledkov wrote:

> > Consequently, I will be removing all kernel packages older than linux
> > 3.13.0-170.220 from trusty-{updates,security} next week.

> I believe 3.13.0-165-generic is required to be published, as that's
> the one that is used by
> http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/netboot/mini.iso
> and all the related boot artifacts.

> Also please ensure that 4.4.0-142 remains published too, as that one
> is used by the hwe-mini.iso and related boot artifacts.

> We should realistically continue to support the usage of the last
> installer we built
> https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu318.46

> Apart from those two, all others can be cleaned up. Or set the above
> versions as the ceilings for removals of generic & lts-xenial kernels.

Thanks for pointing this out, I naively assumed that we had rebuilt d-i in
trusty against the last kernels published there before moving to ESM.

I've locally implemented a stay of execution for the above kernel package
versions.

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

Re: NBS kernel removals: round two

On Thu, 1 Jun 2023 at 21:08, Steve Langasek <steve.langasek@ubuntu.com> wrote:
>
> Hi folks,
>
> Well, we found out that removing all NBS kernel packages for stable series
> was not altogether without its problems for users. We have modified the
> removal policy going forward in response to feedback.
>
> Meanwhile, in preparation for the move of bionic from standard support to
> ESM, the Release Team has noticed that NBS cleanup for ESM releases has so
> far been deferred until the releases go fully EOL.
>
> At this point, the *newest* kernel image in trusty-security is missing 3
> years of security updates. I believe it's therefore reasonable to require
> that users doing deployments of trusty today should do so using a kernel
> that is *no more than* 3 years out of date, before immediately enabling
> Ubuntu Pro and upgrading to a recent kernel security release.
>
> Consequently, I will be removing all kernel packages older than linux
> 3.13.0-170.220 from trusty-{updates,security} next week.
>

I believe 3.13.0-165-generic is required to be published, as that's
the one that is used by
http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/netboot/mini.iso
and all the related boot artifacts.

Also please ensure that 4.4.0-142 remains published too, as that one
is used by the hwe-mini.iso and related boot artifacts.

We should realistically continue to support the usage of the last
installer we built
https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu318.46

Apart from those two, all others can be cleaned up. Or set the above
versions as the ceilings for removals of generic & lts-xenial kernels.

--
okurrr,

Dimitri

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

NBS kernel removals: round two

Hi folks,

Well, we found out that removing all NBS kernel packages for stable series
was not altogether without its problems for users. We have modified the
removal policy going forward in response to feedback.

Meanwhile, in preparation for the move of bionic from standard support to
ESM, the Release Team has noticed that NBS cleanup for ESM releases has so
far been deferred until the releases go fully EOL.

At this point, the *newest* kernel image in trusty-security is missing 3
years of security updates. I believe it's therefore reasonable to require
that users doing deployments of trusty today should do so using a kernel
that is *no more than* 3 years out of date, before immediately enabling
Ubuntu Pro and upgrading to a recent kernel security release.

Consequently, I will be removing all kernel packages older than linux
3.13.0-170.220 from trusty-{updates,security} next week.

I will leave xenial as-is for the moment, and send further mail before
making any changes to NBS packages there.

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

Re: SRU bug subscription for sponsors

Hey Robie,

While I understand the rational, that's putting the annoyance on the
sponsors and might decrease their motivation to help with the uploads.
The annoyance being that by helping reviewing/uploading some change we
will now end up being email nagged for every action/user follow up on
the issues until you manual go to launchpad to unsubscribe.

Did the SRU team consider trying to identify the situations where the
sponsors actual need to be subscribed and try to add them back only in
those cases? Or to encourage the sponsoree to reach out to the sponsor
again if needed? Or to have the SRU team subscribe back the sponsor only
in case where an action is actually needed?

Cheers,
Sébastien Bacher

Le 01/06/2023 à 18:59, Robie Basak a écrit :
> Dear Ubuntu Developers,
>
> If you sponsor an SRU, please subscribe to its bugs so that you can
> respond to any enquiries from the SRU team, and step in as necessary.
>
> We're now also subscribing SRU sponsors automatically, but the initial
> implementation is racy, so this might not always occur if SRU unapproved
> processing is too quick (ha!). Hopefully it'll help in most cases, so
> this should be much better than nothing. Incremental improvements!
>
> We find that sometimes the sponsoree doesn't understand the process,
> which is of course to be expected - that's what the sponsorship process
> is for! But it seemed that sometimes sponsors weren't getting the
> message, and the SRU would stall - hence this request, and the
> autosubscription to help.
>
> Robie
>

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

SRU bug subscription for sponsors

Dear Ubuntu Developers,

If you sponsor an SRU, please subscribe to its bugs so that you can
respond to any enquiries from the SRU team, and step in as necessary.

We're now also subscribing SRU sponsors automatically, but the initial
implementation is racy, so this might not always occur if SRU unapproved
processing is too quick (ha!). Hopefully it'll help in most cases, so
this should be much better than nothing. Incremental improvements!

We find that sometimes the sponsoree doesn't understand the process,
which is of course to be expected - that's what the sponsorship process
is for! But it seemed that sometimes sponsors weren't getting the
message, and the SRU would stall - hence this request, and the
autosubscription to help.

Robie