Re: Point Release process addition

2022-07-27 Thread Sebastien Bacher 

Hey Brian,

First it seems a bit short notice to give that warning a week before the 
milestone, even if the current report indicates there should be no 
practical issue it would be nice to have such changes discussed more in 
advance in the futur


And I've also some questions

1. Are we confident those issues are currently visible to owning teams? 
I think only the uploader get notified today, maybe it would make sense 
to also reports bugs and tag those rls-...-incoming as we do for archive 
rebuilds?


2. Are you going to make stakeholders part of the decision process and 
if so how?


3. If you decide to revert back to the previous version, what does it 
mean for users who already got the upgrade? Do we let them on a version 
we decided was buggy and should be reverted? If that's the case 
shouldn't we try to rather bump the revision to something newer to 
ensure everyone is moved out the buggy version?


Cheers,
Sebastien Bacher

Le 26/07/2022 à 01:05, Brian Murray a écrit :

With the imminent point release of Ubuntu 22.04 LTS, I wanted to let
everyone know of an addition to the point release process[1] followed by
the Ubuntu Release team.

The team will evaluate the packages currently phasing[2] which are also
on any installation media and make a decision as to whether the packages
should be fully phased or if the package should be reverted back to the
prior version.

The point of doing this is to ensure that we are not creating an image
(and subsequently an installed system) with a package version which
contains a regression in that package.

[1] https://wiki.ubuntu.com/PointReleaseProcess
[2] https://people.canonical.com/~ubuntu-archive/phased-updates.html

Thanks,
--
Brian Murray
on behalf of the Ubuntu Release Team



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

2022-07-27 Thread Dan Bungert 
I was on +1 this week.  I focused exclusively on the ffmpeg transition.
Thanks to William Wilson and Brian Murray for retest, rebuild, and sponsored
uploads.

# xpra (LP: #1982418) ##

Upstream had fixes for FFMPEG 5 compatability across a few commits.  Cherry
pick relevant stuff, upload by way of sponsor.  Patch forwarded to Debian.

# xmms2-plugin-avcodec (LP: #1982419) #

Upstream had a straightforward single commit.  Cherry pick, debdiff in sponsor
queue.  Patch forwarded to Debian.

# vtk7 (LP: #1982514) #

vtk7 is sadly quite behind upstream, and attempting to merge individual fixes
is not at all clear that it will be correct.  I did my work the same time Peter
Green was doing so for Debian, and came to the same conclusion.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004793#23

Not entirely sure what to do next.  Simply grabbing the latest version of
ffmpeg-affected source files and dropping it into the codebase does build.

# unpaper (LP: #1982594) #

A newer version of unpaper is in the deferred queue currently and does build
for Kinetic and Sid.  I suggest we sync that, when available.

# shotdetect (LP: #1982598) #

The fixes for FFMPEG 5 look non-trivial and upstream doesn't have this
implemented yet.  No rdeps on shotdetect outside of a suggests on a
metapackage, possibly should remove shotdetect.

# retroarch (LP: #1982606) #

Upstream is quite active and the upstream version has a fix, but the changes
aren't even close to applying to the codebase in the archive.
"Fixed" by disabling FFMPEG usage.  Affected functionality listed
here: https://docs.libretro.com/library/ffmpeg/
Uploaded by way of sponsor.

# qtox #

Builds fine, fails in autopkgtest due to needing another package from proposed.
Moved onward with an extra trigger on chromaprint.

# pqiv (LP: #1982779) #

Just needed rebuild.  Upload by way of sponsor.

# performous (LP: #1982781, LP: #1982860) #

While there is a version in experimental, it isn't required to get this to
build with FFMPEG 5.  Cherry-picked a commit from upstream and extended it just
a little to get this buildinging.

Also needed a ppc64el fix
https://salsa.debian.org/games-team/performous/-/merge_requests/1

Uploaded by way of sponsor, patch for the FFMPEG part forwarded to Debian.

# motion (LP: #1982886) #

Backported commit, in sponsor queue, forwarded to Debian.

# minidlna (LP: #1982890) #

Just needs no change rebuild.  In sponsor queue.

# RISC-V rebuilds #

A few packages built fine, except for some temporary non-availability of the
new FFMPEG packages in proposed for RISC-V.  On rebuild they were fine.
* loudgain
* lynkeos.app
* mediastreamer2
* mgba
* moc
* mpv

# brief looks #

* mplayer - upstream 1.5 version has support for ffmpeg 5
* octave-video (LP: #1982875) Not able to find any work upstream on a
  transition.
* olive-editor (LP: #1982869) Upstream is focused on a new 0.2 version, which
  looks like it would be fine with FFMPEG 5.
* lives - Upstream is aware but a compatible version is not yet ready.
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013421
* qtav (LP: #1982609) Upstream work started upstream on FFMPEG 5.
* openboard (LP: #1982784) Builds with upstream PR, which is not yet merged.
  At quick glance, PR looks similar to what other projects are doing.

-Dan

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