Bug#894158: libogg: new upstream release 1.3.3
On Tue, Mar 27, 2018 at 11:09:51AM +0100, Simon McVittie wrote:
> On Tue, 27 Mar 2018 at 18:25:59 +1030, Ron wrote:
> > On Mon, Mar 26, 2018 at 10:55:04PM +0100, Simon McVittie wrote:
> > > lose the -dbg package,
> >
> > This would mean people wanting a backport to oldstable would lose easy
> > access to debug symbols, so right now I'd still consider that to be a
> > regression.
>
> I've mostly considered a consistent interface to debug symbols across
> packages within the same suite to be more important than backports to
> oldstable-backports-sloppy, although I do see your point.
>
> (stable is the source of official backports to oldstable-backports;
> oldstable-backports-sloppy contains backports from testing, which can
> break the upgrade path from oldstable to stable.)
>
> Do you really backport the latest versions to oldstable or older? I tend
> to think that if someone is sufficiently change-averse to be staying
> with oldstable and not upgrading to stable, then installing backports
> is the last thing they should be doing.
Not necessarily through Debian's bpo infrastructure, but yes, I maintain
backports repos for both personal and company use for all of the still
supported distro releases (so for another month or so, all the way back
to oldoldstable). Not everything gets pushed into those, but since you
never can predict when something important might need to be, I usually
try pretty hard to ensure everything I'm responsible for can trivially
still be built out of the box on all of them.
And realistically, that's usually not very hard - all you have to do is
not gratuitously break things for older releases.
I'm certainly not the only one doing that, there's been plenty of
thank you's from people grateful it was trivial to do an unofficial
backport of things they've needed somewhere too.
> > > fix Lintian warnings,
> >
> > There are none which are flagging an actual problem in this package.
>
> Debhelper compat levels > 5 fix bugs (or design flaws if you prefer) in
> historical debhelper behaviour; the older compat levels are deprecated
> for a reason.
Sure, but none of those changes actually fixes a bug in this package,
so *at best*, changing the compat level will fix nothing, and hopefully
also break nothing, if I'm careful enough and have time enough to check
that none of the changes in behaviour actually do cause an unexpected
regression (which is quite common in packages where people do just
blindly bump the compat every time lintian or someone suggests they
should).
And really the main reason the currently deprecated set are deprecated
is just because Niels doesn't yet have an ideal way to keep adding new
compatibility levels indefinitely in a clean and easily maintainable
way. It's not because they are somehow fundamentally broken - at least
not if you don't need any of the things the newer compat levels add.
> Compat level 9, which is currently the oldest non-deprecated compat
> level, was available in what's now oldoldstable.
Yes, compat 9 is now my current baseline, for exactly that reason - but
that's not a change which warrants an upload to do only that. Not when
at best all it would do is not introduce a new bug. It will probably
happen with the next upload though - unless I need to do it in a hurry
and don't have time to properly regression test for a change like that.
> The absence of ${misc:Depends} might not be an issue now, but it could
> become an actual problem, since it's where debhelper tools put new
> dependencies as they become necessary.
If it ever does, I actually *would* want this to break loudly and
obviously. So that we can assess whether the new dependency it
added was justifiable, or whether we should change something to
avoid it. For some packages more than others, I don't want to have
debhelper gratuitously adding new dependencies silently.
> If the RFCs are false-positives and they are actually Free Software,
> please add Lintian overrides to document this for future contributors. If
> they're non-free, then that's considered a release-critical bug (I can't
> say I'm entirely convinced that applying the DFSG equally to documentation
> is proportionate, but there have been GRs that say it's project consensus
> that we do).
It's documented here:
http://metadata.ftp-master.debian.org/changelogs/main/libo/libogg/libogg_1.3.2-1_copyright
I thought I'd actually reported a lintian bug about those being false
positives (many years ago now), but don't seem to see one still open
for that in the BTS ...
Maybe it was Simon Josefsson's check script, which at some point we
were using to test for these, which that happened for. Unless it was
fixed in lintian and then later regressed.
But either way, as a real false positive, it is lintian which should be
fixed here. Even that lintian tag itself says that is the correct action
for a false positive with this warning.
> > > rebuilding with newer gcc defaults might well produce better-hardened
> > >
Bug#894158: libogg: new upstream release 1.3.3
On Tue, 27 Mar 2018 at 18:25:59 +1030, Ron wrote:
> On Mon, Mar 26, 2018 at 10:55:04PM +0100, Simon McVittie wrote:
> > lose the -dbg package,
>
> This would mean people wanting a backport to oldstable would lose easy
> access to debug symbols, so right now I'd still consider that to be a
> regression.
I've mostly considered a consistent interface to debug symbols across
packages within the same suite to be more important than backports to
oldstable-backports-sloppy, although I do see your point.
(stable is the source of official backports to oldstable-backports;
oldstable-backports-sloppy contains backports from testing, which can
break the upgrade path from oldstable to stable.)
Do you really backport the latest versions to oldstable or older? I tend
to think that if someone is sufficiently change-averse to be staying
with oldstable and not upgrading to stable, then installing backports
is the last thing they should be doing.
> > fix Lintian warnings,
>
> There are none which are flagging an actual problem in this package.
Debhelper compat levels > 5 fix bugs (or design flaws if you prefer) in
historical debhelper behaviour; the older compat levels are deprecated
for a reason. Tracking the latest isn't required, but I would recommend
catching up at least once per Debian stable cycle: that doesn't involve
a whole lot of uploads (about 1 per 2 years). Compat level 9, which
is currently the oldest non-deprecated compat level, was available in
what's now oldoldstable.
The absence of ${misc:Depends} might not be an issue now, but it could
become an actual problem, since it's where debhelper tools put new
dependencies as they become necessary.
If the RFCs are false-positives and they are actually Free Software,
please add Lintian overrides to document this for future contributors. If
they're non-free, then that's considered a release-critical bug (I can't
say I'm entirely convinced that applying the DFSG equally to documentation
is proportionate, but there have been GRs that say it's project consensus
that we do).
> > rebuilding with newer gcc defaults might well produce better-hardened
> > binaries.
>
> Do you have something specific in mind which might apply here beyond
> the current set of explicit hardening options this is built with?
I don't have anything specific in mind, but comparing what individual
packages do with the recommendations that dpkg-buildflags provides is
not something that can really scale to a project the size of Debian.
I notice that libogg has its own hard-coded knowledge of which hardening
flags work(ed in 2014) on which architectures. It seems like it would
be better to have this information exist centrally, in dpkg.
smcv
Bug#894158: libogg: new upstream release 1.3.3
On Mon, Mar 26, 2018 at 10:55:04PM +0100, Simon McVittie wrote: > On Tue, 27 Mar 2018 at 07:45:27 +1030, Ron wrote: > > There's actually some more interesting fixes after the 1.3.3 tag, so I > > should probably nudge upstream toward a 1.3.4 tag sometime soon and pull > > in the corner case patch with those. > > Sure, I'm in no rush to see 1.3.3. Cool, this is the reference implementation of a stable standard, so it is generally more surprising when there is some significant change to it than that it's been years since the last one. > Updating to a new upstream release would probably also be a good > opportunity to catch up on 3½ years of packaging best-practice ( Just on the specifics of this: > lose the -dbg package, This would mean people wanting a backport to oldstable would lose easy access to debug symbols, so right now I'd still consider that to be a regression. We're almost at the point where Wheezy is EOL for LTS support now, but Jessie still has more than 2 years to run, so we're still at least a whole cycle away from this being a Good Thing to do in the "next upload". > fix Lintian warnings, There are none which are flagging an actual problem in this package. I care about the ones which do, the rest it's much less interesting to play whack-a-mole with. > rebuilding with newer gcc defaults might well produce better-hardened > binaries. Do you have something specific in mind which might apply here beyond the current set of explicit hardening options this is built with? If there are I'm interested to know more about that - but if "rebuild with newer toolchain" uploads is going to be a thing, then waiting for gcc-8 to become the default in this cycle might be the right point for that to happen? Best, Ron
Bug#894158: libogg: new upstream release 1.3.3
On Tue, 27 Mar 2018 at 07:45:27 +1030, Ron wrote: > There's actually some more interesting fixes after the 1.3.3 tag, so I > should probably nudge upstream toward a 1.3.4 tag sometime soon and pull > in the corner case patch with those. Sure, I'm in no rush to see 1.3.3. Updating to a new upstream release would probably also be a good opportunity to catch up on 3½ years of packaging best-practice (lose the -dbg package, move Vcs-* off Alioth, fix Lintian warnings, that sort of thing), and rebuilding with newer gcc defaults might well produce better-hardened binaries. smcv
Bug#894158: libogg: new upstream release 1.3.3
Hi Simon, On Mon, Mar 26, 2018 at 09:03:09PM +0100, Simon McVittie wrote: > Source: libogg > Version: 1.3.2-1 > Severity: wishlist > > While updating ioquake3 I noticed that the upstream developer now bundles > libogg-1.3.3, which is newer than the version in Debian. FSVO "newer" ... I was pretty sure there was actually nothing at all in that one for us - but reviewing all the commits again, I see there is a one-character typo fix in the docs (accurred -> occurred), and a one line patch for a corner case that I'm not sure anything actually trips over in practice. The 1.3.3 release was mostly all futzing about in the build system for Visual Studio, MacOS, and CI testing so it had been on my Meh Not For Us list. There's actually some more interesting fixes after the 1.3.3 tag, so I should probably nudge upstream toward a 1.3.4 tag sometime soon and pull in the corner case patch with those. > Please consider also adding a debian/watch file for uscan, which would > have caused Debian's QA infrastructure to pick this up automatically. Automatically, yes - but usefully perhaps not so much. Especially since I'll generally get a poke directly from *upstream* if there is something important in these which we are missing - and what is in git is usually more interesting than what is in a tarball on the download site. But thanks for the poke to review this again and note the current status where people who aren't following git might see it. Cheers, Ron
Bug#894158: libogg: new upstream release 1.3.3
Source: libogg Version: 1.3.2-1 Severity: wishlist While updating ioquake3 I noticed that the upstream developer now bundles libogg-1.3.3, which is newer than the version in Debian. Please consider also adding a debian/watch file for uscan, which would have caused Debian's QA infrastructure to pick this up automatically. smcv
