Saturday, 24 July 2021

Ubuntu 20.10 (Groovy Gorilla) End of Life reached on July 22 2021

This is a follow-up to the End of Life warning sent earlier this month
to confirm that as of July 22, 2021, Ubuntu 20.10 is no longer
supported. No more package updates will be accepted to 20.10, and it
will be archived to old-releases.ubuntu.com in the coming weeks.

The original End of Life warning follows, with upgrade instructions:

Ubuntu announced its 20.10 (Groovy Gorilla) release almost 9 months
ago, on October 22, 2020, and its support period is now nearing its
end. Ubuntu 20.10 will reach end of life on July 22, 2021.

At that time, Ubuntu Security Notices will no longer include
information or updated packages for Ubuntu 20.10.

The supported upgrade path from Ubuntu 20.10 is via Ubuntu 21.04.
Instructions and caveats for the upgrade may be found at:

https://help.ubuntu.com/community/HirsuteUpgrades

Ubuntu 21.04 continues to be actively supported with security updates
and select high-impact bug fixes. Announcements of security updates
for Ubuntu releases are sent to the ubuntu-security-announce mailing
list, information about which may be found at:

https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce

Since its launch in October 2004 Ubuntu has become one of the most
highly regarded Linux distributions with millions of users in homes,
schools, businesses and governments around the world. Ubuntu is Open
Source software, costs nothing to download, and users are free to
customise or alter their software in order to meet their needs.

On behalf of the Ubuntu Release Team,
--
Brian Murray

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

Friday, 23 July 2021

+1 Maintenance report

Hi,
I was looking at +1 maintenance items this week to make update-excuses
a better place. I've tackled a few cases that were more complex than "hit
retry" despite sprint and other duties trying to steal my time. For that I think
it became quite a list looking back at the end of the week.

All but the last cases here are for documentation for the interested,
but fully resolved and no problem for impish anymore.

The last case in this list still isn't fully complete and waiting for someone
pythonic to further debug module loading - so if that sounds tempting
or you are on +1 maintenance on next week - consider having a look :-)


# Iperf / Openvswitch

I looked into iperf being blocked by openvswitch tests as it rang some bells.
And indeed new bug 1936796 is the return of bug 1919432 which was also coming
up in +1 duty back then.
https://lists.ubuntu.com/archives/ubuntu-devel/2021-March/041419.html
Since nothing has changed since last time I went ahead and fixed mininet
in Impish via https://bugs.launchpad.net/ubuntu/+source/mininet/+bug/1936796

I also pinged upstream mininet about this still being a problem and that the
suggested patch helps at least all our cases.

After I got a review by James Pagewho dealt with mininet before I uploaded
a fix of mininet to impish. Sadly upstream didn#t reply yet, but that solves
our imminent issue.

After the new mininet was built I triggered the tests together and
everything related did migrate.


# xtensor

This is a autopkgtest fail that blocks src:xtensor and src:xtensor-blas.
The test fails on all architectures.
- s390x / arm64 / i386 fail on bad-package.
xtensor-dev became a transitional and is available on all arch.
But the actual dependency libxtensor-dev only exists on a few
libxtensor-dev | 0.22.0-5 | impish-proposed | amd64, armhf, ppc64el, riscv64
That explains the badpkg s390x issue, and I guess we can just reset it
instead of spending too much time fixing the package.
- also amd64 / ppc64 fail one of the tests by a build error.
The last good test was more than two years ago.
https://autopkgtest.ubuntu.com/packages/x/xtensor/impish/amd64
In debici this passes on amd64/arm64/armel/armhf/ppc64 but fails i386/s390x.
https://ci.debian.net/packages/x/xtensor/
And they are not all-skips.
The problem is reproducible locally and an OOM.

I filed https://bugs.launchpad.net/ubuntu/+source/xtensor/+bug/1936820
to track the various MPs to guide the testing into a better state.
It has 3 test-resets, 2 marked as big_package and one Debian MR to reduce
concurrency.

After all the changes were present tests worked as planned (now succeeding
on the architectures they can work on and ignored on the others). Thereby
xtensor and xtensor-blas migrated to impish-release.


# gegl

As usual, first of all file a launchpad update-excuse bug to avoid others
looking into the same case.
https://bugs.launchpad.net/ubuntu/+source/gegl/+bug/1936901
This turned out to be a real reproducible issue, most likely due to
the endianness. I did quite some debugging to ensure a high quality
bug report and then filed that issue upstream.
https://gitlab.gnome.org/GNOME/gegl/-/issues/289
Once we know if it is a regression (then we wait for a fix) or just
a new test exposing an issue we always had (then we might skip the tests)
we can decide on the next step.


# nftables / firewalld

I found nftables being blocked for more than two months due to a test
fail with firewalld.
As usual a LP bug will help to track any insight/effort and update-excuse
will make it show up for everyone:
https://bugs.launchpad.net/ubuntu/+source/nftables/+bug/1936902/+addcomment

After some debugging I found this to be a real regression in nftables which
had an upstream fix in the following version.
I did test builds, filed a Debian bug and some more verifications.
But it really looked all good when the fix was applied

After a kind review by fellow co-+1 Graham I did upload this to impish
and eventually that made nftables migrate.


# ntopng (3.8.1 rebuild) / ndpi (3.0 -> 3.4)

This is stuck since ntopng fails to build on arm*.
This rang a bell and I found some history on ubuntu-devel for this.
After an uncomfortably long trip through try-builds, dfsg crazyness
and updates to Debian bugs I ended up filing a removal request as
it seems the better approach for me after assessing the situation
in detail.
=> https://bugs.launchpad.net/ubuntu/+source/ntopng/+bug/1937016
And until removed the update-excuse tag ensures that no one else needs
to do archeology on this case again.
To resolve it long term I have bumped the Debian bug to clarify that the
new upstream version would fix the FTFBS
=> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977805#17


# pyspread

That was blocked by a autopkgtest-fail that happens in Ubuntu
https://autopkgtest.ubuntu.com/packages/p/pyspread
and Debian
https://ci.debian.net/packages/p/pyspread/
with the new 1.99.6-1 version.
This was already brought up in April in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986488
but not handled since then.

Note: This package is uncommon as it always runs the testsuite code and tests
against the same other packages but NOT against a packaged pyspread.
This happens because pyspread is not installed as dependency, only via the test
that extracts it. Therefore it is not necessarily always testing what you think.
For example you can not run the 1.99.6 test against the 1.99.5 binaries or
vice versa.

I found, debugged and fixed the broken testcase.
I reported it and a fix upstream
https://gitlab.com/pyspread/pyspread/-/issues/92
https://gitlab.com/pyspread/pyspread/-/merge_requests/36
I also bumped the Debian bug as FYI and filed a launchpad bug for other
plus-one people to be aware of.

Thanks to various people in #ubuntu-desktop for my journey through font-land.

I uploaded the fix to Impish to resolve it but did not migrate for another
issue this time on s390x due to big endian
https://bugs.launchpad.net/ubuntu/+source/pyspread/+bug/1937162
I fixed that new test as well - it is not a new regression, only a new
test coverage that was missed before.
I also reported it upstream in case there is a deeper underlying issue
that needs to be fixed.
https://gitlab.com/pyspread/pyspread/-/issues/93

With both applied it migrated.


# breezy / lintian-brush / breezy-debian

I have actually looked at those last plus-one-duty that I was on.
In the meantime
https://bugs.launchpad.net/ubuntu/+source/lintian-brush/+bug/1931369
were fixed through
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989634
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988909
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989633
But that wasn't all it seems, the breezy-debian bug
https://bugs.launchpad.net/ubuntu/+source/breezy-debian/+bug/1933034
now also affects lintian-brush at least in Ubuntu.

It turns out that there are staged issues.
First one would need to resolve the breezy 3.2.1 FTBFS
https://bugs.launchpad.net/ubuntu/+source/breezy/+bug/1937173

Once that FTBFS is solved breezy-debian and lintian-brush can be
rebuilt and will work.
Then finally the tests of silver-platter, breezy-debian, breezy and
lintian-brush all need to be re-triggered with combined triggers to each of
them.
The latter will then resolve bug 1933034.

But as I said first of all the breezy FTBFS in bug 1937173 needs to be solved.
I've done quite some debugging and documented it in the launchpad bug.
My current working theory is that the newer python that is in Impish is
not loading the test modules more than once.
The tests are designed to load modules that have "raise exception..." and
expect that to be processed.
That works once, but not ever again - as if python would keep it in some cache
and decide to "no I no more load that crap".
I've tried to clear loaded python modules sys.modules.items / sys.modules.pop
and also to make the module non-identical (in case they are hashed) but
neither approach has worked.

It is easily reproducible in e.g. a local sbuild but needs another pair
of pythonic eyes that want to dive deeper into the behavior of __import__.

This would be a great spot for next weeks +1 maintenance to continue on.


--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

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

Thursday, 22 July 2021

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

On Wed, Jul 21, 2021 at 6:11 AM Robie Basak <robie.basak@ubuntu.com> wrote:
>
> Thank you for volunteering! As we have at least one qualified person
> committed, I'd be very happy to see the backports pocket continue. As a
> concrete proposal, I suggest we do this by reforming ~ubuntu-backporters
> as follows.
>
> In particular I wanted to enumerate a specific transition plan and the
> reformed team's responsibities below, since my opinion on sunsetting the
> backports pocket is only moot if this actually happens.
>
> Feedback appreciated!
>
> # Team Roles
>
> For clarity, initially there will be two roles in the team: 1) a
> leadership role, driving re-establishment and reform; 2) people doing
> the regular day-to-day work, such as reviews.
>
> I think the first role could only effectively be taken by suitably
> qualified, existing and established Ubuntu developers. We'll see if
> there are any other volunteers, and if there are, see if there is
> consensus that they can also take on the role.
>
> The second role would be open to anyone who meets the requirements of
> the new process, which is yet to be defined.
>
> To get started I suggest continuing the old process, while allowing for
> the new team's leadership to drive process reform.
>
> # Transition Plan
>
> * This entire plan is predicated on there being at least one suitably
> qualified, experienced and established Ubuntu developer committed to
> taking on both roles. So far, that's Dan, but others may join him.
>
> * ~techboard takes ownership of ~ubuntu-backporters.
>
> * Existing but inactive team members are removed.
>
> * Those that we have agreed will take on the first role are added as
> team admins.
>
> * Those still active in the team and are willing to do the second role
> (if any; I think only Iain qualifies if he is willing) are added as
> regular team members.
>
> * A process for future management of team membership would be up to the
> team itself to establish.
>
> # Team responsibilities
>
> Here I've tried to define what we need, rather than specify how the
> backporters team will deliver it. I'd prefer to leave the team to drive
> that. For example, Gunnar asked some good questions in the thread; I've
> deliberately not answered those, leaving that for the backporters team
> to figure out later as part of the process reform.
>
> * Establish and manage an effective process to handle backport
> requests. Any review process must accept or reject every backport
> request on its technical merit, and be neutral to who is requesting
> it[1].
>
> * Maintain the backports pocket based on this process, making sure that
> all requests receive an appropriate answer in a reasonable amount of
> time.
>
> * Maintain quality in the backports pocket, where the definition of
> quality is driven by the team, but defined by consensus within the
> wider Ubuntu developer community.
>
> * Handle your own process reform and membership management, but making
> sure that any responsibility can be carried by any contributor who
> demonstrates the required capacity and competence. Specifically,
> since the DMB has never managed membership of ~ubuntu-backporters,
> there is no requirement for the DMB to be involved. Unless you want
> to delegate that, in which case that's a conversation to have with
> the DMB.
>
> How does this sound? Feedback appreciated.

I'm in agreement with everything.

So as far as next steps based on your proposal, it seems like:

1) Open call for initial volunteers
- I volunteer for the leadership role (at least for the initial
re-establishment), assuming there are no objections
- mapreri volunteers for day-to-day role (thanks Mattia!)
- this email thread seems like a good enough call to the community for
anyone else who wants to volunteer, either in a leadership role or
day-to-day role
2) Administrative changes to ~ubuntu-backporters
- I don't see any public documentation on an existing process for
membership changes to ~ubuntu-backporters, so I assume your proposal
along with the disussion here is enough justification to ask the TB to
make the changes, assuming there is no objection from the TB of
course, or from existing active members (Laney I assume all this
sounds ok to you?)
3) New team has initial public irc meeting (and email/chat
communication as needed) to make any process reforms (membership,
backports process, etc)
4) update public documentation
5) New team starts work on reviewing backports

does that seem correct?

>
> Robie
>
>
> [1] To be clear, I believe that the current process requires
> sponsorship/upload of a suitable backport, and the backporters team only
> reviews once an upload has taken place. I am not suggesting that we
> require the backporters team to do any more than that - for example
> responding to a backport request with no upload with "please find a
> sponsor[2] to upload an appropriate backported package and then we'll
> review it" would be fine. But the process must avoid the current
> situation where only privileged people can get their uploads reviewed,
> and everyone else is blocked.
>
> [2] Availability of sponsors is a separate issue. I'd like to address
> that too, but I don't think it's appropriate to pull that into the scope
> of backports reform.

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

Wednesday, 21 July 2021

Re: Proposal: sunset the backports pockets

On Tue, Jul 20, 2021 at 8:38 AM Gunnar Hjalmarsson <gunnarhj@ubuntu.com> wrote:
>
> On 2021-07-20 13:58, Dan Streetman wrote:
> > Yes, objection here. The backports pocket is still in use.
> >
> > If I understand correctly, as discussed in much greater length in
> > other posts in this thread, the sole problem with the backports
> > process is lack of time for the Ubuntu Backports Team to actually
> > review uploads to the -backports pocket.
> >
> > If that's the case, then the Canonical Sustaining Engineering Group
> > is happy to take that over (since 'sustaining' the stable releases
> > is...our job), please feel free to ping me about ACLs and process
> > tooling for approving -backports uploads and we'll start reviewing
> > the queues.
>
> That sounds promising, Dan.
>
> As regards uploads in the queues, I had a quick look yesterday. I found
> one item in bionic and four ones in focal. But only one (1) item had a
> reference to a bug report with the expected justification, test results etc.
>
> But then we have all the backport requests which are not yet uploaded:
>
> https://bugs.launchpad.net/bionic-backports
>
> https://bugs.launchpad.net/focal-backports
>
> <https://wiki.ubuntu.com/UbuntuBackports> gives the impression that the
> uploads should be carried out by an ~ubuntu-backporters member in
> connection with the review.
>
> So if the Canonical Sustaining Engineering Group steps up — which is
> excellent, of course — there still seems to be room for clarification of
> the process.
>
> * Who can/should upload?
>
> * Should sponsorship be sought for uploads to the -backports queues?

definitely good points to clarify, we should probably move any
clarifications over to rbasak's new thread

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

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

On 2021-07-21 14:06, Robie Basak wrote:
> I haven't checked myself, but there seem to be different opinions on
> how it currently works, exactly, based on the discussion so far.

The last para of <https://wiki.ubuntu.com/UbuntuBackports> is ambiguous,
and may explain the differences in opinion.

> However, I think we're all agreed on the process to reform it, so
> I'll leave the details to the newly formed backporters team to sort
> out :)

Thanks for making it happen, Robie!

--
Cheers,

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

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

Hi Mattia,

Thank you for your support, and for volunteering for the second role!

On Wed, Jul 21, 2021 at 12:56:07PM +0200, Mattia Rizzolo wrote:
> > [1] To be clear, I believe that the current process requires
> > sponsorship/upload of a suitable backport, and the backporters team only
> > reviews once an upload has taken place.
>
> I believe you are wrong on this.
> They way the current process is worded, uploads should be done by people
> in ~ubuntu-backports only, effectively causing a huge load on the team.
> The reform needed here (as you more or less imply), is that upload
> rights should follow the usual rules, with ~ubuntu-backports only
> reviewing the uploads once they end in the "unapproved" queue (i have no
> idea how the staging queue for backports is currently called).

The point I was trying to make in my footnote was merely that I'm not
intending to demand that the backporters team take on all the work
themselves as soon as someone requests a backport without providing any
further work themselves.

I haven't checked myself, but there seem to be different opinions on how
it currently works, exactly, based on the discussion so far. However, I
think we're all agreed on the process to reform it, so I'll leave the
details to the newly formed backporters team to sort out :)

Robie

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

Hi!

Thank you Robie for drafting this!

On Wed, Jul 21, 2021 at 11:11:33AM +0100, Robie Basak wrote:
> # Team Roles
>
> For clarity, initially there will be two roles in the team: 1) a
> leadership role, driving re-establishment and reform; 2) people doing
> the regular day-to-day work, such as reviews.
>
> I think the first role could only effectively be taken by suitably
> qualified, existing and established Ubuntu developers. We'll see if
> there are any other volunteers, and if there are, see if there is
> consensus that they can also take on the role.

I agree on this.

> The second role would be open to anyone who meets the requirements of
> the new process, which is yet to be defined.

I also hereby volunteer me for the day-to-day tasks.
Mostly, I don't have enough cycles available to drive discussions and
anything related on how to reform the process, else I'd volunteer for
more, but if anything I'm positive I can handle reviews and similar.
As such, I'm happy to follow Dan or whoever is going to take lead on the
project, provided that they present a viable reform path.

> # Team responsibilities
>
> * Establish and manage an effective process to handle backport
> requests. Any review process must accept or reject every backport
> request on its technical merit, and be neutral to who is requesting
> it[1].
>
> * Maintain the backports pocket based on this process, making sure that
> all requests receive an appropriate answer in a reasonable amount of
> time.
>
> * Maintain quality in the backports pocket, where the definition of
> quality is driven by the team, but defined by consensus within the
> wider Ubuntu developer community.
>
> * Handle your own process reform and membership management, but making
> sure that any responsibility can be carried by any contributor who
> demonstrates the required capacity and competence. Specifically,
> since the DMB has never managed membership of ~ubuntu-backporters,
> there is no requirement for the DMB to be involved. Unless you want
> to delegate that, in which case that's a conversation to have with
> the DMB.

I don't think there is a need to involve the DMB here. I'd just say
that any members should be part of ~ubuntu-dev already, nothing more
complex than that.

> How does this sound? Feedback appreciated.

Nothing to add, your starter is great already, now we only need a lead
to lead :)

> [1] To be clear, I believe that the current process requires
> sponsorship/upload of a suitable backport, and the backporters team only
> reviews once an upload has taken place.

I believe you are wrong on this.
They way the current process is worded, uploads should be done by people
in ~ubuntu-backports only, effectively causing a huge load on the team.
The reform needed here (as you more or less imply), is that upload
rights should follow the usual rules, with ~ubuntu-backports only
reviewing the uploads once they end in the "unapproved" queue (i have no
idea how the staging queue for backports is currently called).

> [2] Availability of sponsors is a separate issue. I'd like to address
> that too, but I don't think it's appropriate to pull that into the scope
> of backports reform.

Aye, unrelated.


--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-