Re: Bug#612032: tesseract: rewrite arbitrary user file
On Sun, 2011-03-06 at 22:57 +0100, Jeffrey Ratcliffe wrote:
> Hi Adam,
>
> On 6 March 2011 00:18, Adam D. Barratt <adam@adam-barratt.org.uk> wrote:
> > - Testing and unstable have tesseract 2.04-2.1, so the package for
> > stable would need to have a lower version than that. I'd suggest 2.04-2
> > +squeeze1, which is conventional.
>
> Sure. This will be my first contribution directly to stable or
> oldstable, as I am sure you can tell. I've updated the oldstable
> package to also conform.
Thanks.
> There was no mention of the convention in the Developers'
> Reference[1]. Is this worth a bug report?
I'm planning on working on the wording in the DevRef relating to stable
uploads soon anyway, to ensure it matches current practice; I'll bear it
mind. The reasoning behind using + is to ensure that the newly uploaded
version is higher than any binNMUs which may exist in stable (i.e.
2.04-2squeeze1 < 2.0.4-2+b1). It also saves us having to check whether
there was ever a 2.03-3 in the archive previously.
> > - It would be nice if the reasoning for the quilt build-dep bump was
> > mentioned. My suspicion is that this is due to the use of "dh
> > --with-quilt" triggering a lintian warning but this isn't really
> > necessary for stable as the relevant quilt version is already included
> > there (and the warning has thus been dropped by the version of lintian
> > in experimental).
>
> I've dropped it, assuming you are correct, and asked Jakub Wilk, who
> prepared the original NMU, to confirm.
Okay, thanks.
For the record, I'd be happy with the squeeze upload either as is or
with the quilt bump + more expansive changelog entry; the main issue
with the original was the lack of explanation.
> >> Would you like separate bugs to be opened for each distribution? At
> >> the moment, the same sid/wheezy bug is quoted/closed.
> >
> > That's fine (and the right way to do it).
>
> Sorry, but your answer is ambigious. Would you like the extra two bugs
> opened (and closed)?
Sorry, "that" referred to the current situation. There's no need to
open more than one bug to track a particular issue in a given package;
the BTS is more than capable of tracking which versions of a package
(and by extension which suites) the bug applies to assuming it has
supplied with the correct version information in terms of fixed / found
versions. #612032 was already corrected tagged for the stable version
(albeit as a side-effect of it being the unstable version at the time
the bug was reported); I've just sent the relevant control@ command to
mark the oldstable version as affected.
> I would also suggest that the Developers' Reference could be improved
> to confirm this, one way or the other.
I don't think this is an issue specific to stable; it's a general
feature of BTS version tracking so if further documentation is needed it
should be outside of any stable update discussion.
Regards,
Adam
Reply to: