Bug#730870: pu: unifont -- RoM; NMU Version in Stable Undoes Ubuntu Fix
On Sat, 2013-11-30 at 19:13 -0800, Paul Hardy wrote:
> On Sat, Nov 30, 2013 at 3:39 PM, Adam D. Barratt
> <adam@adam-barratt.org.uk> wrote:
> Control: tags -1 + moreinfo
>
> On Sat, 2013-11-30 at 07:59 -0700, unifoundry@unifoundry.com
> wrote:
> > I am requesting that the version of package Unifont in
> Testing, unifont
> > 1:5.1.20080914-4, be included in the upcoming Wheezy point
> release
> > primarily to align with Colin Watson's wishes for Ubuntu.
>
> What are the problems with the package in stable which this
> update would
> resolve? Aligning with Ubuntu's packaging is not a suitable
> reason for
> an update.
>
>
> From a Debian perspective, I would list these changes as most
> relevant:
>
> * debian/copyright reflects revised licensing for the Wen Quan Yi
> glyphs incorporated into Unifont.
So long as the package in stable is distributable, we've generally
treated updates / clarifications to the license information in unstable
as being good enough to cover stable as well.
>
> * debian/control entries had incorrect Section fields because of
> revised policy ("x11" instead of the new "font" section); now they are
> correct.
>
That might be okay as part of an update, it's not enough on its own.
> * debian/control entries needed changes in dependencies to conform to
> new Debian Policy requirements.
See below.
> * I removed vestigial defoma artifacts from the package.
>
Are said artefacts actually causing any problems?
> [...]
> > The Debian NMU of Unifont made its way to Ubuntu and did not
> incorporate
> > Colin's fix, so the upload had the effect of removing his
> fix from
> > Ubuntu.
>
> That's unfortunate, but again in no way justifies an update to
> stable.
>
> Yes, most unfortunate, and I was asking for the change for Ubuntu's
> sake.
I'm confused by this statement. To the best of my knowledge, when Ubuntu
synchronise packages they do so from unstable; the content of the
package in stable has no bearing on what ends up in Ubuntu.
>
> [...]
>
> > * Updated packaging to conform to the policy version
> suitable for Wheezy
> > Stable (3.9.4), notably for the revised font handling
> requirements.
>
> No, the version of Policy applicable to wheezy is 3.9.3.
> Okay. I built the package running the current Stable distribution
> with automatic updates, and that configuration uses Policy 3.9.4.
I'm not sure what you mean by "uses Policy 3.9.4", but:
$ dak ls debian-policy -s stable
debian-policy | 3.9.3.1 | stable | source, all
The release announcement for 3.9.4 explicitly said
"Since this is during freeze, two major caveats. First, none of the
changes in Policy 3.9.4 are release-critical for wheezy (except for
things that were already release-critical before being documented) and
should in general not result in uploads targeting wheezy"
[...]
> However, there are things in the Stable version that do not comply
> with changes made by version 3.9.3 in regards to font handling.
As far as I can tell, 3.9.3 makes exactly 0 changes in regards to font
handling. Please be more explicit.
> > * Added hardening to debian/rules.
>
> That is very much not a suitable change to be making in a
> stable update.
> I added this to remove lintian warnings because it was simple, before
> realizing the problem with the removal of Colin's fix from Ubuntu. At
> the time I started, I was just planning to improve the packaging in
> preparation for the next release of upstream.
>
That's fine for unstable; as I said though, it's not appropriate for an
update to stable.
> I also realize that updating the Policy number is frowned upon for
> changes to Stable, but in this case the Stable version used an
> outdated Policy version that did not reflect mandatory changes in how
> Debian now handles fonts.
Could you point to which changes you're referring to? I may just need
more coffee, but checking through the upgrading checklist and changelog
isn't highlighting anything obvious since policy 3.5.5 (or maybe 3.7.0
at a push).
In any case, whilst the xfonts-utils dependencies are technically
required, it is also in practice unlikely for their absence to be an
issue, due to e.g. xorg and xutils depending on the package.
> Please produce a full source debdiff of the changes you're
> proposing to
> make, based on the current package in stable; we will not ack
> updates
> based on a changelog.
>
> I've attached a debdiff.
>
>
> I think these changes are small. In contrast, the next upload I make
> will be significantly different; I've switched to "dh" and have made
> extensive upstream changes to Makefiles and other structural changes
> to the upstream sources. While I consider the version now in Testing
> to be very robust, there could be problems I didn't anticipate in the
> next version to be uploaded.
>
> Ideally, I would also therefore like to get this last 20080914 version
> into Stable before uploading the new (and significantly different)
> upstream version into Unstable.
I think there may be some misunderstanding of the process here. Uploads
to stable are made as new uploads; the packages do not migrate from
testing to stable. There is nothing stopping you uploading newer
versions of the package to unstable and this discussion should not be
used as a blocker for such uploads.
To be explicit, I'm currently likely to nack this proposed update,
unless answers to the queries above reveal an issue I'm missing.
Regards,
Adam
Reply to: