Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1053641: transition: libavif
6 views
Skip to first unread message
Sebastian Ramacher
Oct 7, 2023, 2:40:05 PM10/7/23
to
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: lib...@packages.debian.org ma...@debian.org
> User: release.d...@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
On 2023-10-07 14:06:44 -0400, Boyuan Yang wrote:
> Package: release.debian.org
> Control: affects -1 + src:libavif
> X-Debbugs-Cc: lib...@packages.debian.org ma...@debian.org
> User: release.d...@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
Adrian Bunk
Oct 7, 2023, 5:10:06 PM10/7/23
to
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 +0000
+++ jpeg-xl-0.7.0/debian/rules 2023-10-07 20:36:51.420550561 +0000
@@ -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
>...
> (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 +0000
+++ jpeg-xl-0.7.0/debian/rules 2023-10-07 20:36:51.420550561 +0000
@@ -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
Mathieu Malaterre
Oct 8, 2023, 4:00:05 AM10/8/23
to
Hi,
On Sat, Oct 7, 2023 at 9:36 PM Boyuan Yang <by...@debian.org> wrote:
>
> X-Debbugs-CC: ma...@debian.org
>
> 在 2023-10-07星期六的 20:32 +0200，Sebastian Ramacher写道：
>
> 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 <cmath> 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;
> 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
On Sat, Oct 7, 2023 at 9:36 PM Boyuan Yang <by...@debian.org> 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)).
> > >
> >
> > 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)
> > >
> > > 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.
> > > starting the libavif transition?
> >
> > No, that's not necessary. Please go ahead.
>
>
> 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 <cmath> 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
> (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.
>
> 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
Paul Gevers
Oct 8, 2023, 4:10:06 AM10/8/23
to
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
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.
transitions to be entangled. An upload to experimental is fine of course
to clear the NEW queue.
Paul
0 new messages