Bug#1053641: transition: libavif
X-Debbugs-CC: sramac...@debian.org ma...@debian.org On Sun, 8 Oct 2023 09:57:21 +0200 Paul Gevers wrote: > Hi Mathieu, > > On 08-10-2023 09:46, Mathieu Malaterre wrote: > >> (3) Wait till a sane jpeg-xl 0.8 upload (with transition) is ready, and > >> entangle > >> jpeg-xl transition with libavif transition. > > > > #1051131 has been fixed yesterday. I'll go ahead and do the 0.8 upload > > this week. > > Please wait with that until Sebastian approves. We normally don't want > transitions to be entangled. An upload to experimental is fine of course > to clear the NEW queue. Just to let you know that I took the liberty to handle the blocker from src:darktable via NMU, and now the libavif transition should have finished and no longer being a blocker to other transitions. Maybe we should close bug 1053641 and handle other stalled transitions (like jpeg-xl). Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1053641: transition: libavif
Hi Mathieu, On 08-10-2023 09:46, Mathieu Malaterre wrote: (3) Wait till a sane jpeg-xl 0.8 upload (with transition) is ready, and entangle jpeg-xl transition with libavif transition. #1051131 has been fixed yesterday. I'll go ahead and do the 0.8 upload this week. Please wait with that until Sebastian approves. We normally don't want transitions to be entangled. An upload to experimental is fine of course to clear the NEW queue. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1053641: transition: libavif
Hi,
On Sat, Oct 7, 2023 at 9:36 PM Boyuan Yang wrote:
>
> X-Debbugs-CC: ma...@debian.org
>
> 在 2023-10-07星期六的 20:32 +0200，Sebastian Ramacher写道：
> > Control: tags -1 confirmed
> >
> > On 2023-10-07 14:06:44 -0400, Boyuan Yang wrote:
> > > I am looking at starting the transition for package libavif,
> > > which comes with a SONAME bump
> > > (libavif15, v0.11.1-3 (sid) -> libavif16, v1.0.1-1 (exp)).
> > >
> > > * jpeg-xl (Current version FTBFS unconditionally due to a different reason
> > > in Testing/Sid; my NMU fix just accepted in Sid)
> > >
> > > Do we need to wait till my NMU-ed jpeg-xl to migrate to Testing before
> > > starting the libavif transition?
> >
> > No, that's not necessary. Please go ahead.
>
> Alright, here comes the tricky part.
>
> In the test build of reverse build-dependencies, only amd64 builds are
> examined.
> Now, the rebuilt jpeg-xl has some new FTBFS on other architectures; and while
> some
> issues are easy to solve (e.g., missing header for arm64), some
> issues are
> not (like the new test failures for i386 and s390x) [1].
>
> Probably I uploaded the libavif/1.0.1-1 to Sid too soon; and while I tried to
> cancel
> the upload with "dcut rm" and "dcut cancel", these commands never successfully
> intercept the upload ("no such upload found", "no file to delete", etc), and
> we are
> having the new libavif in Sid now to trigger the transition. This is the worst
> condition we could have, though I consciously tried to avoid it :-(
>
> I am now wondering what would be the best way to get this transition done in
> a sane
> way. A few choices in my mind:
>
> (1) Make a sloppy upload to jpeg-xl in Sid to ignore post-build testing
> errors (and
> possibly newly-emerged autopkgtest errors, if any?) so that the libavif
> transition can
> finish, and count on the upcoming jpeg-xl (0.7 -> 0.8) transition to correct
> these
> ignored errors;
>
> (2) Fix current jpeg-xl in Sid properly. That won't be too trivial since the
> new
> testing error is likely triggered by some unclear changes in
> build-dependencies over
> the past several months.
>
> (3) Wait till a sane jpeg-xl 0.8 upload (with transition) is ready, and
> entangle
> jpeg-xl transition with libavif transition.
#1051131 has been fixed yesterday. I'll go ahead and do the 0.8 upload
this week.
Thanks,
> It would be great if you have any suggestion, or even better, some good
> patches
> on it.
>
> Thanks,
> Boyuan Yang
>
>
> [1] https://buildd.debian.org/status/package.php?p=jpeg-xl
Bug#1053641: transition: libavif
Hi, 在 2023-10-07星期六的 23:59 +0300，Adrian Bunk写道： > On Sat, Oct 07, 2023 at 03:33:16PM -0400, Boyuan Yang wrote: > > ... > > (2) Fix current jpeg-xl in Sid properly. That won't be too trivial since > > the new > > testing error is likely triggered by some unclear changes in > > build-dependencies over > > the past several months. > > ... > > Fix below, only tested on i386 but should also fix s390x. > > > Thanks, > > Boyuan Yang > > ... > > cu > Adrian > > --- jpeg-xl-0.7.0/debian/rules.old2023-10-07 20:36:28.728571696 + > +++ jpeg-xl-0.7.0/debian/rules2023-10-07 20:36:51.420550561 + > @@ -23,6 +23,8 @@ > DEB_CXXFLAGS_MAINT_APPEND += -fno-tree-vectorize > endif > > +DEB_CXXFLAGS_MAINT_APPEND += -fexcess-precision=fast > + > ifneq (,$(filter $(DEB_HOST_ARCH), arm64 armel armhf ppc64el)) > # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 > DEB_CXXFLAGS_MAINT_APPEND += -Wno-psabi Thanks. I noticed that gcc-13 changed its default from -fexcess-precision=fast to -fexcess-precision=standard with -std=c++17[2], and this is likely the root cause of recent FTBFS. I have incorporated your patch into jpeg-xl/0.7.0-10.2 upload, and the build seems to go on well. Looks like we can continue and finish the libavif transition. [2] https://gcc.gnu.org/gcc-13/changes.html#cxx Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1053641: transition: libavif
On Sat, Oct 07, 2023 at 03:33:16PM -0400, Boyuan Yang wrote: >... > (2) Fix current jpeg-xl in Sid properly. That won't be too trivial since the > new > testing error is likely triggered by some unclear changes in > build-dependencies over > the past several months. >... Fix below, only tested on i386 but should also fix s390x. > Thanks, > Boyuan Yang >... cu Adrian --- jpeg-xl-0.7.0/debian/rules.old 2023-10-07 20:36:28.728571696 + +++ jpeg-xl-0.7.0/debian/rules 2023-10-07 20:36:51.420550561 + @@ -23,6 +23,8 @@ DEB_CXXFLAGS_MAINT_APPEND += -fno-tree-vectorize endif +DEB_CXXFLAGS_MAINT_APPEND += -fexcess-precision=fast + ifneq (,$(filter $(DEB_HOST_ARCH), arm64 armel armhf ppc64el)) # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 DEB_CXXFLAGS_MAINT_APPEND += -Wno-psabi
Bug#1053641: transition: libavif
X-Debbugs-CC: ma...@debian.org
在 2023-10-07星期六的 20:32 +0200，Sebastian Ramacher写道：
> Control: tags -1 confirmed
>
> On 2023-10-07 14:06:44 -0400, Boyuan Yang wrote:
> > I am looking at starting the transition for package libavif,
> > which comes with a SONAME bump
> > (libavif15, v0.11.1-3 (sid) -> libavif16, v1.0.1-1 (exp)).
> >
> > * jpeg-xl (Current version FTBFS unconditionally due to a different reason
> > in Testing/Sid; my NMU fix just accepted in Sid)
> >
> > Do we need to wait till my NMU-ed jpeg-xl to migrate to Testing before
> > starting the libavif transition?
>
> No, that's not necessary. Please go ahead.
Alright, here comes the tricky part.
In the test build of reverse build-dependencies, only amd64 builds are examined.
Now, the rebuilt jpeg-xl has some new FTBFS on other architectures; and while
some
issues are easy to solve (e.g., missing header for arm64), some issues
are
not (like the new test failures for i386 and s390x) [1].
Probably I uploaded the libavif/1.0.1-1 to Sid too soon; and while I tried to
cancel
the upload with "dcut rm" and "dcut cancel", these commands never successfully
intercept the upload ("no such upload found", "no file to delete", etc), and we
are
having the new libavif in Sid now to trigger the transition. This is the worst
condition we could have, though I consciously tried to avoid it :-(
I am now wondering what would be the best way to get this transition done in a
sane
way. A few choices in my mind:
(1) Make a sloppy upload to jpeg-xl in Sid to ignore post-build testing errors
(and
possibly newly-emerged autopkgtest errors, if any?) so that the libavif
transition can
finish, and count on the upcoming jpeg-xl (0.7 -> 0.8) transition to correct
these
ignored errors;
(2) Fix current jpeg-xl in Sid properly. That won't be too trivial since the new
testing error is likely triggered by some unclear changes in build-dependencies
over
the past several months.
(3) Wait till a sane jpeg-xl 0.8 upload (with transition) is ready, and entangle
jpeg-xl transition with libavif transition.
It would be great if you have any suggestion, or even better, some good patches
on it.
Thanks,
Boyuan Yang
[1] https://buildd.debian.org/status/package.php?p=jpeg-xl
Processed: Re: Bug#1053641: transition: libavif
Processing control commands: > tags -1 confirmed Bug #1053641 [release.debian.org] transition: libavif Added tag(s) confirmed. -- 1053641: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053641 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1053641: transition: libavif
Control: tags -1 confirmed On 2023-10-07 14:06:44 -0400, Boyuan Yang wrote: > Package: release.debian.org > Control: affects -1 + src:libavif > X-Debbugs-Cc: liba...@packages.debian.org ma...@debian.org > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: by...@debian.org > Severity: normal > > I am looking at starting the transition for package libavif, > which comes with a SONAME bump > (libavif15, v0.11.1-3 (sid) -> libavif16, v1.0.1-1 (exp)). > > I tried with the rebuild of all packages on the transition page: > > Level 1: > > * libavif (OK) > > Level 2: > > * jpeg-xl (Current version FTBFS unconditionally due to a different reason > in Testing/Sid; my NMU fix just accepted in Sid) > * libgd2 (OK) > * links2 (OK) > * qt-avif-image-plugin (OK) > > Level 3: > > * darktable (OK) > * kimageformats (OK) > * webkit2gtk (OK) > * wpewebkit (OK) > > > Do we need to wait till my NMU-ed jpeg-xl to migrate to Testing before > starting the libavif transition? No, that's not necessary. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1053641: transition: libavif
Package: release.debian.org Control: affects -1 + src:libavif X-Debbugs-Cc: liba...@packages.debian.org ma...@debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: by...@debian.org Severity: normal I am looking at starting the transition for package libavif, which comes with a SONAME bump (libavif15, v0.11.1-3 (sid) -> libavif16, v1.0.1-1 (exp)). I tried with the rebuild of all packages on the transition page: Level 1: * libavif (OK) Level 2: * jpeg-xl (Current version FTBFS unconditionally due to a different reason in Testing/Sid; my NMU fix just accepted in Sid) * libgd2 (OK) * links2 (OK) * qt-avif-image-plugin (OK) Level 3: * darktable (OK) * kimageformats (OK) * webkit2gtk (OK) * wpewebkit (OK) Do we need to wait till my NMU-ed jpeg-xl to migrate to Testing before starting the libavif transition? (jpeg-xl package maintainer added in the CC list.) Ben file: (The current autogenerated transition page https://release.debian.org/transitions/html/auto-libavif.html can be reused.) title = "libavif"; is_affected = .depends ~ "libavif15" | .depends ~ "libavif16"; is_good = .depends ~ "libavif16"; is_bad = .depends ~ "libavif15"; Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
