Monday, 16 May 2022

Re: Question to flavors: touch-base on flavor participation for 22.10!

Apologies for the delay. On behalf of the Lubuntu team we will be participating in 22.10. Thanks for checking in.

Dan

On 5/11/22 05:40, Graham Inggs wrote:
> Hello flavors!
>
> As we do around the start of every new cycle, I am reaching out to all
> the current official Ubuntu flavors to confirm active participation in
> the upcoming Ubuntu release - 22.10.
>
> Working towards a release requires a lot of effort, so we'd like to
> make sure all the flavors are ready, properly staffed and have enough
> time allocated to make 22.10 happen for their users. This is why,
> similarly to last year, I will need a confirmation follow-up message
> about kinetic participation from every flavor, that is:
>
> * Kubuntu
> * Xubuntu
> * Ubuntu Studio
> * Lubuntu
> * Ubuntu Kylin
> * Ubuntu MATE
> * Ubuntu Budgie
>
> If you have any concerns regarding your participation, feel free to
> reach out to me or anyone else from the ubuntu-release team.
>
> Thank you!
>
> Graham

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

Hi Robie

On Fri, 13 May 2022 at 23:04, Robie Basak <robie.basak@ubuntu.com> wrote:
> octave is in dep-wait on riscv64 for libpetsc-real3.16-dev
> Produced by src:petsc which FTBFS on riscv64
> FTBFS is because of missing symbol SCOTCH_ParMETIS_V3_NodeND
> On amd64 this is shipped in libptscotchparmetisv3-7.0.1.so in libptscotch-7.0_7.0.1-2_amd64.deb
> Also available on riscv64
> So why does the configure script not find it specifically on riscv64? Not sure but it's not looking in libptscotchparmetisv3.so at all. Looks like this was fixed in petsc upstream commit 3307d110e72ee4e6d2468971620073eb5ff93529 that hasn't been released yet. Upstream latest tag is v3.17.1. petsc is 3.16.6 in Ubuntu and Debian has 3.17.0+dfsg1-1exp1 in experimental.
> petsc is currently built on all archs except riscv64, but a rebuild of amd64 fails for me locally.
> Looks like this generally needs a deeper investigation. Upstream has a
> very large number of recent commits. It might be easier just to wait for
> them to release rather than patch up our older version.

This looks like version skew to me; the failed petsc build on riscv64
was against libscotch-dev 7.0.1-2, while the successful builds on the
other architectures were against libscotch-dev 6.1.3-1. As you
noticed, petsc FTBFS on amd64 (and everywhere else) right now, I
believe this is due to the hypre/scalapack/scotch/petsc/slepc
transitions being entangled. I have done a bunch of no-change
rebuilds for these, and hopefully petsc will be able to build later
today.

Regards
Graham

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

Sunday, 15 May 2022

Re:Question to flavors: touch-base on flavor participation for 22.10!

Hi,

Ubuntu Kylin will participate in the 22.10 release.

handsome_feng




在2022年05月11 17时40分,"Graham Inggs"<ginggs@ubuntu.com>写道:

Hello flavors!  As we do around the start of every new cycle, I am reaching out to all the current official Ubuntu flavors to confirm active participation in the upcoming Ubuntu release - 22.10.  Working towards a release requires a lot of effort, so we'd like to make sure all the flavors are ready, properly staffed and have enough time allocated to make 22.10 happen for their users. This is why, similarly to last year, I will need a confirmation follow-up message about kinetic participation from every flavor, that is:   * Kubuntu  * Xubuntu  * Ubuntu Studio  * Lubuntu  * Ubuntu Kylin  * Ubuntu MATE  * Ubuntu Budgie  If you have any concerns regarding your participation, feel free to reach out to me or anyone else from the ubuntu-release team.  Thank you!  Graham

Re: autopkgtest missed regression for kinetic

On Sun, May 15, 2022 at 4:26 PM Steve Langasek
<steve.langasek@ubuntu.com> wrote:
> > The test has never passed; it has had neutral results and failing results,
> > but by policy, proposed-migration does not treat neutral->fail as a
> > migration-blocking regression, only pass->fail. Neutral test results are
> > informational only.
>
> Having said this, I am just this moment looking at cases where britney is
> treating neutral->fail as a regression. I still believe the intended policy
> is as I described, but one way or another there appear to be some bugs here
> in the implementation ;)

devhelp's autopkgtest is marked as "superficial". In Debian, a passing
superficial autopkgtest won't speed up migration to Testing. But if
the test fails, it indicates that there is a serious bug and migration
to Testing is blocked. Please see the description of the intent of
"superficial":

https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst

Thank you,
Jeremy Bicha

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

Re: autopkgtest missed regression for kinetic

On Sun, May 15, 2022 at 12:57:34PM -0700, Steve Langasek wrote:
> This is because the test failure is not a regression.

> * autopkgtest for devhelp/41.2-2: amd64: Not a regression, arm64: Not a regression, armhf: Test in progress, ppc64el: Not a regression, s390x: Not a regression

> The test has never passed; it has had neutral results and failing results,
> but by policy, proposed-migration does not treat neutral->fail as a
> migration-blocking regression, only pass->fail. Neutral test results are
> informational only.

Having said this, I am just this moment looking at cases where britney is
treating neutral->fail as a regression. I still believe the intended policy
is as I described, but one way or another there appear to be some bugs here
in the implementation ;)

--
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: autopkgtest missed regression for kinetic

On Sun, May 15, 2022 at 08:06:44AM -0400, Jeremy Bicha wrote:
> On Sat, May 14, 2022 at 10:18 AM Brian Murray <brian@canonical.com> wrote:
> > On Fri, May 13, 2022 at 08:05:20PM +0200, Julian Andres Klode wrote:
> > > On Fri, May 13, 2022 at 12:06:46PM -0400, Jeremy Bicha wrote:
> > > > I am concerned that the excuses page is ignoring that webkit2gtk
> > > > 2.36.1-1 caused an autopkgtest regression for devhelp.

> > > > https://autopkgtest.ubuntu.com/packages/d/devhelp/kinetic/amd64
> > > > https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html

> > > > The regression was correctly caught in Debian:
> > > > https://tracker.debian.org/pkg/webkit2gtk

> > > > I am concerned because I would expect other packages could have
> > > > introduced regressions but been allowed in to Kinetic.

> > > It seems the state of the 2 autopkgtest-web workers is inconsistent,
> > > not all results were copied up on all instances.

> > > I noticed that it retried a migration-reference/0 test after the failure
> > > which indicated it did not allow the failure, but a later run might have
> > > hit the different backend and hence might have a different view.

> > > So it's unclear if that's the reason, but bdmurray is cleaning that up
> > > right now.

> > The cleanup finished overnight and now both instances of the
> > autopkgtest-web servers have the same information.

> My test case is still broken. devhelp is not blocking webkit2gtk on
> the excuses page.

This is because the test failure is not a regression.

* autopkgtest for devhelp/41.2-2: amd64: Not a regression, arm64: Not a regression, armhf: Test in progress, ppc64el: Not a regression, s390x: Not a regression

The test has never passed; it has had neutral results and failing results,
but by policy, proposed-migration does not treat neutral->fail as a
migration-blocking regression, only pass->fail. Neutral test results are
informational only.

If you want failures of this package's tests to be treated as regressions,
then the devhelp source package should be fixed so that its autopkgtests
return the correct error code.

This version of webkit2gtk has yet to migrate, so you could do this now, get
new devhelp to migrate, and then have webkit2gtk be blocked; or you could
just open a block-proposed bug if this is something that should be
considered a one-off.

In any case, hopefully this clarification about the policy is useful. It is
a policy that should be kept on the proposed-migration end because it
provides greater flexibility than a strictly pass/fail system, and also we
shouldn't deviate from Debian's behavior here and categorically have a
stricter gate than Debian which we don't have the capacity to maintain.

--
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: autopkgtest missed regression for kinetic

On Sat, May 14, 2022 at 10:18 AM Brian Murray <brian@canonical.com> wrote:
> On Fri, May 13, 2022 at 08:05:20PM +0200, Julian Andres Klode wrote:
> > On Fri, May 13, 2022 at 12:06:46PM -0400, Jeremy Bicha wrote:
> > > I am concerned that the excuses page is ignoring that webkit2gtk
> > > 2.36.1-1 caused an autopkgtest regression for devhelp.
> > >
> > > https://autopkgtest.ubuntu.com/packages/d/devhelp/kinetic/amd64
> > > https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
> > >
> > > The regression was correctly caught in Debian:
> > > https://tracker.debian.org/pkg/webkit2gtk
> > >
> > > I am concerned because I would expect other packages could have
> > > introduced regressions but been allowed in to Kinetic.
> >
> > It seems the state of the 2 autopkgtest-web workers is inconsistent,
> > not all results were copied up on all instances.
> >
> > I noticed that it retried a migration-reference/0 test after the failure
> > which indicated it did not allow the failure, but a later run might have
> > hit the different backend and hence might have a different view.
> >
> > So it's unclear if that's the reason, but bdmurray is cleaning that up
> > right now.
>
> The cleanup finished overnight and now both instances of the
> autopkgtest-web servers have the same information.

My test case is still broken. devhelp is not blocking webkit2gtk on
the excuses page.

Thank you,
Jeremy Bicha

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