Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Raphael Geissert]

Hello Jörg,

Jörg Sommer wrote:
> Hello Raphael,
> 
> Raphael Geissert <[EMAIL PROTECTED]> wrote:
>> Jörg Sommer <[EMAIL PROTECTED]>
>>jed (U)
> 
> This is a SVN snapshot. There's no release of it. I fail to see how to
> point to a changelog file in a SVN repository. How should I handle this
> situation?

By making me ignore those watch file which are in experimental?
:)

> 
> Bye, Jörg.

Cheers,
Raphael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: On the subject of watchfiles (was Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version)

[Gunnar Wolf]

Andreas Tille dijo [Tue, Feb 26, 2008 at 08:21:47PM +0100]:
> >Heh, start a bit earlier (think Ruby)... Educate maintainers to
> >release proper .tar.gz, not braindead .gem packages containing the
> >equivalent to an orig.tar.gz (but created due to a nice
> >don't-ask-me-why-that's-not-properly-implemented bug in December 31,
> >1969)... And then complaining if you are distributing in stable
> >anything older than their nightly checkouts.
> >
> >Yes, Perl and the CPAN rock my world, although my programming is
> >nowadays mostly Ruby-based. The Ruby general mindset is WAY inferior.
> 
> What?
> I admit I would have been able to parse the contents of your mail
> with the same success if you would have written in Spanish. :)
> Prehaps it is me who had to get up 4:20 this morning (so I started
> *really* early ;-) ) - but I do not even understand whether this is pro or 
> contra proper watch files.

Sorry, I'm a bit incoherent as well  - due to all kind of unrelated
events :) 

I'm completely pro-watch. It is fundamental to the way pkg-perl
works. As said IIRC by Tincho, there is no way to keep track of over
670 packages without automated tools.

What really brings me down is that this is impossible in communities
such as the Ruby one, which uses a incoherent and brain-dead packaging
format, and insists on shoving it on distributions' throats. Bah.

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: On the subject of watchfiles (was Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version)

[Andreas Tille]

On Tue, 26 Feb 2008, Gunnar Wolf wrote:


Heh, start a bit earlier (think Ruby)... Educate maintainers to
release proper .tar.gz, not braindead .gem packages containing the
equivalent to an orig.tar.gz (but created due to a nice
don't-ask-me-why-that's-not-properly-implemented bug in December 31,
1969)... And then complaining if you are distributing in stable
anything older than their nightly checkouts.

Yes, Perl and the CPAN rock my world, although my programming is
nowadays mostly Ruby-based. The Ruby general mindset is WAY inferior.


What?
I admit I would have been able to parse the contents of your mail
with the same success if you would have written in Spanish. :)
Prehaps it is me who had to get up 4:20 this morning (so I started
*really* early ;-) ) - but I do not even understand whether this is pro 
or contra proper watch files.


Kind regards

  Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: On the subject of watchfiles (was Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version)

[Gunnar Wolf]

Andreas Tille dijo [Tue, Feb 26, 2008 at 03:02:31PM +0100]:
> Well, in fact it is helpful if you teach upstream to organise releases
> that way that watchfiles would work.  This is not only in the interest
> of Debian but for the whole FLOSS community so other interested users
> will be able to transparantly download software as well and upstream
> will start using a consistent version management.  This will not work
> for upstream dead software - but here are watch files void anyway.

Heh, start a bit earlier (think Ruby)... Educate maintainers to
release proper .tar.gz, not braindead .gem packages containing the
equivalent to an orig.tar.gz (but created due to a nice
don't-ask-me-why-that's-not-properly-implemented bug in December 31,
1969)... And then complaining if you are distributing in stable
anything older than their nightly checkouts.

Yes, Perl and the CPAN rock my world, although my programming is
nowadays mostly Ruby-based. The Ruby general mindset is WAY inferior. 

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: On the subject of watchfiles (was Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version)

[Andreas Tille]

On Tue, 26 Feb 2008, Martín Ferrari wrote:


Of course, we have luck, because CPAN (99% of our packages come from
there, and we have only 4 unsolvable watch problems) is pretty
well-behaving and consistent, compared to other upstreams. But chances
are that watchfiles can be useful for the majority of people.


Well, in fact it is helpful if you teach upstream to organise releases
that way that watchfiles would work.  This is not only in the interest
of Debian but for the whole FLOSS community so other interested users
will be able to transparantly download software as well and upstream
will start using a consistent version management.  This will not work
for upstream dead software - but here are watch files void anyway.

Kind regards

Andreas, who had also doubt about watch files until about
 onw year ago ...

--
http://fam-tille.de

Re: On the subject of watchfiles (was Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version)

[Martín Ferrari]

Hi Jon,

On Tue, Feb 26, 2008 at 11:20 AM, Jon Dowland
<[EMAIL PROTECTED]> wrote:
>
>  Is it worth investing much effort into debugging watch file
>  issues?

In my experience, yes. I can cite the example of the perl group: 679
packages group maintained. You'll guess that there's no way in earth a
small group of people can track such amount of packages manually. We
heavily rely on the watchfiles for detecting new upstream releases,
and the tool we use
(http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi) automates
that for us. We go to great lengths to make every package have the
correct watch information.

Of course, we have luck, because CPAN (99% of our packages come from
there, and we have only 4 unsolvable watch problems) is pretty
well-behaving and consistent, compared to other upstreams. But chances
are that watchfiles can be useful for the majority of people.


-- 
Martín Ferrari

On the subject of watchfiles (was Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version)

[Jon Dowland]

Is it worth investing much effort into debugging watch file
issues?

In my experience, watchfiles are seldom useful. There was
the whole problem with getting at HTTPS URLs; the
sourceforge workarounds (that broke); etc. One of the
packages I maintain (deutex) does not have the latest
upstream version linked to from a website (it's referenced
in a mailing list post somewhere). I've read several other
examples of situations (unpredictable version number schemes
etc.) where it falls short.

Also, if a package is being looked after by an active
maintenance team, you'd hope that they would be aware that a
new upstream version was available: in many cases you'd hope
they were aware one was *due*, often with pre-releases in
experimental to catch issues for the larger suites.

If a package is not being looked after by an active
maintenance team, there's a bug in the package maintenance
(or the package should be on it's way out); which won't be
solved by tweaking the watch file.


-- 
Jon Dowland


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Jörg Sommer]

Hello Raphael,

Raphael Geissert <[EMAIL PROTECTED]> wrote:
> Jörg Sommer <[EMAIL PROTECTED]>
>jed (U)

This is a SVN snapshot. There's no release of it. I fail to see how to
point to a changelog file in a SVN repository. How should I handle this
situation?

Bye, Jörg.
-- 
Prof. in der Mathematikvorlesung zu einem vergessenen φ in der
Gleichung: „Klein‐φ macht auch Mist.“


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Michal Čihař]

Hi

On Mon, 18 Feb 2008 19:20:18 -0600
Raphael Geissert <[EMAIL PROTECTED]> wrote:

> Seems like I forgot to make sure to list only those affecting packages in
> unstable. But it would anyway be nice to keep both watch files working :)

I know, but I tend to forgot to this when I upload package to
experimental ;-).

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Raphael Geissert]

Hello,

Michal Čihař wrote:
> Hi
> 
> On Sun, 17 Feb 2008 14:41:34 -0600
> Raphael Geissert <[EMAIL PROTECTED]> wrote:
> 
>> Michal Čihař <[EMAIL PROTECTED]>
>>gammu
> 
> The problem with this is that there are stable versions, for which I
> use watch file and are uploaded to unstable. Testing versions I put
> (usually) to experimental and I don't change watch file there. Is it
> really that big problem that packages in experimental don't have
> absolutely correct watch file?
> 

Seems like I forgot to make sure to list only those affecting packages in
unstable. But it would anyway be nice to keep both watch files working :)

Cheers,
Raphael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Raphael Geissert]

Raphael Hertzog wrote:

> On Sun, 17 Feb 2008, Raphael Geissert wrote:
>> Ack, what about only reporting (thus in a non automated way) on those
>> which are not affected by any repackaging/similar version part?
> 
> It's might be acceptable but I'm not sure either. Some packages have
> development version packaged and those development versions are released
> differently than the stable releases... thus in theory it would need an
> update of the watch file to point to the development release during the
> time when the devel version is packaged (AFAIK, that's the case for
> glib2.0 that you gave as example).
> 
> But as a maintainer I wouldn't update the watch file because what I care
> is to not miss a new stable release... missing a development release is
> not a big deal.
> 
> Maybe there's room for improvement to uscan here. It would check at
> several places and know the status (stable, development) of each release
> based on where it was found.

You can specify several urls on a same watch file, e.g.:

8<>8
version=3
http://domain.tld/downloads/foo-(.*)\.tar\.gz

opts=uversionmangle=s/beta/~beta/ \
http://domain.tld/downloads/pre/foo-(.*)\.tar\.gz
8<>8

> 
> At the end, I think there are far better things to do than overoptimize
> watch files. If watch files is something that you find important, you
> could work on creating watch files for all the packages that don't have
> any and submit them (and also use them for DEHS check even while they are
> not integrated in the source package).

DEHS already does its best to guess watch files by using the urls provided
in the copyright files of the packages. Those are the so called 'watch
wizard-generated watch files' and their result does appear on DEHS and on
the DDPO. For the last part you mention it sounds more like one of the
features that is already mentioned in[1].

> 
>> > And when we have +svn we are indeed newer than the upstream
>> > released tarball and the information is correct! So stripping that part
>> > would be a mistake.
>> 
>> IMHO it would be better to strip that part with a dversionmangle.
>> However, DEHS currently compares with $upstream le $debian so those
>> packages are marked as up to date.
> 
> I don't know what makes you say better, some aesthetic consideration? In
> any case, watch files are not supposed to be a burden to maintain. So I'm
> against such modifications.

So both versions match. But at least any Debian-related repackaging should
at least be removed from the Debian version with a dversionmangle since
both (with dfsg, without dfsg) are the same version.

> 
> Cheers,

[1]http://wiki.debian.org/DEHS

Cheers,
Raphael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Raphael Geissert]

Russ Allbery wrote:

> Raphael Geissert <[EMAIL PROTECTED]> writes:
> 
> Your guess is as good as mine.  I've asked and didn't get any answer.  As
> near as I can tell, they all really like hacking on GNU Backgammon, but
> none of them like doing release management.  (Some of them use Windows and
> do periodic builds from CVS snapshots, which may have something to do with
> it.)

I've seen several of those Windows users working on FOSS projects mainly
targeted to Linux (and UNIX's) lately.

> 
>> By the way, I've been working on uscan and my changes can be expected to
>> be available within some days. One of the features I've been working on
>> is #395439 which might be helpful in your situation.
> 
> I don't see how it would help with this in particular, although I can
> think of some other things it would be helpful for.
> 

Let's say upstream uses the auto* stuff and stores the version of the
program in a .in, with it you could point uscan to the .in file and write a
nice regex that matches the version number. It would be tricky, if not
impossible, to make it then link to the right snapshot, but you would at
least be aware of new releases.

Cheers,
Raphael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Michal Čihař]

Hi

On Sun, 17 Feb 2008 14:41:34 -0600
Raphael Geissert <[EMAIL PROTECTED]> wrote:

> Michal Čihař <[EMAIL PROTECTED]>
>gammu

The problem with this is that there are stable versions, for which I
use watch file and are uploaded to unstable. Testing versions I put
(usually) to experimental and I don't change watch file there. Is it
really that big problem that packages in experimental don't have
absolutely correct watch file?

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Raphael Hertzog]

On Sun, 17 Feb 2008, Raphael Geissert wrote:
> Ack, what about only reporting (thus in a non automated way) on those which
> are not affected by any repackaging/similar version part?

It's might be acceptable but I'm not sure either. Some packages have
development version packaged and those development versions are released
differently than the stable releases... thus in theory it would need an
update of the watch file to point to the development release during the
time when the devel version is packaged (AFAIK, that's the case for
glib2.0 that you gave as example).

But as a maintainer I wouldn't update the watch file because what I care
is to not miss a new stable release... missing a development release is
not a big deal.

Maybe there's room for improvement to uscan here. It would check at
several places and know the status (stable, development) of each release
based on where it was found.

At the end, I think there are far better things to do than overoptimize
watch files. If watch files is something that you find important, you could
work on creating watch files for all the packages that don't have any and
submit them (and also use them for DEHS check even while they are not
integrated in the source package).

> > And when we have +svn we are indeed newer than the upstream released
> > tarball and the information is correct! So stripping that part would be a
> > mistake.
> 
> IMHO it would be better to strip that part with a dversionmangle. However,  
> DEHS currently compares with $upstream le $debian so those packages are
> marked as up to date.

I don't know what makes you say better, some aesthetic consideration? In
any case, watch files are not supposed to be a burden to maintain. So I'm
against such modifications.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Russ Allbery]

Raphael Geissert <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:

>> Upstream stopped doing real releases a while back although hopefully
>> will again do some someday.  Currently, all that's available is nightly
>> snapshots.  I can:
>>
>> * Keep pointing the watch file at the actual official release location in
>>   the hope that upstream will eventually release a newer official version.
>> 
>> * Point the watch file at the daily snapshots and have it always be out of
>>   date because I'm not going to release new versions of gnubg daily.
>> 
>> * Delete the watch file.
>> 
>> Which would you rather I do?  I personally think the first option is
>> the best, which is why I'm doing it, but I don't care that much.
>
> I would probably have kept the version number at 0.14.3 and append
> +snapshotMMDD.

That would imply that this is a snapshot of 0.14.3, or at worst the next
version.  It's not; upstream considers it to be a snapshot of 0.16.
That's the version number the program displays in all of its dialog boxes
and so forth.  There was a 0.15 after 0.14.3 as well; it was just never
released as anything other than a CVS snapshot.

I don't version the stuff, I just try to package it.  :)  But I do think
that the version of the Debian package should reflect upstream's version
unless upstream's version is completely impossible.

> However if I only were able to choose between those three I would choose
> the first one.

Yeah, that's pretty much where I'm at.

> But I do wonder why upstream hasn't released any version, and guessing
> this:, but updated the changelog or a similar file you use to know that
> the latest version is 0.16

Your guess is as good as mine.  I've asked and didn't get any answer.  As
near as I can tell, they all really like hacking on GNU Backgammon, but
none of them like doing release management.  (Some of them use Windows and
do periodic builds from CVS snapshots, which may have something to do with
it.)

> By the way, I've been working on uscan and my changes can be expected to
> be available within some days. One of the features I've been working on
> is #395439 which might be helpful in your situation.

I don't see how it would help with this in particular, although I can
think of some other things it would be helpful for.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Raphael Geissert]

Russ Allbery wrote:

> Raphael Geissert <[EMAIL PROTECTED]> writes:
> 
>> Russ Allbery <[EMAIL PROTECTED]>
>>gnubg
> 
> Upstream stopped doing real releases a while back although hopefully will
> again do some someday.  Currently, all that's available is nightly
> snapshots.  I can:
> 
> * Keep pointing the watch file at the actual official release location in
>   the hope that upstream will eventually release a newer official version.
> 
> * Point the watch file at the daily snapshots and have it always be out of
>   date because I'm not going to release new versions of gnubg daily.
> 
> * Delete the watch file.
> 
> Which would you rather I do?  I personally think the first option is the
> best, which is why I'm doing it, but I don't care that much.
> 

I would probably have kept the version number at 0.14.3 and append
+snapshotMMDD. However if I only were able to choose between those
three I would choose the first one.

But I do wonder why upstream hasn't released any version, and guessing
this:, but updated the changelog or a similar file you use to know that the
latest version is 0.16

By the way, I've been working on uscan and my changes can be expected to be
available within some days. One of the features I've been working on is
#395439 which might be helpful in your situation.

Cheers,
Raphael Geissert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Scott Kitterman]

On Sun, 17 Feb 2008 18:55:26 -0600 Raphael Geissert 
<[EMAIL PROTECTED]> wrote:
>Scott Kitterman wrote:
>> On Sunday 17 February 2008 17:22, Raphael Geissert wrote:
>>>
>>> If Debian's 0.11+1-1 is upstream's 0.11 why not just strip the '+1' 
using
>>> dversionmangle?
>>> That's in my POV the bug.
>>>
>> I think rewriting watch files for one time events is a mistake.  If this
>> were
>> a permanent feature of the version numbering I would agree. 
>
>The thing is, when you make such kind of uploads all you have to make sure
>is that uscan still says your package is up to date. 
>
>> I suppose the 
>> easiest solution for me to not be bothered about this would be to remove
>> the watch file on the next upload.
>
>You won't be bothered if you also maintain the watch file.
>And as I said in my response to Raphael Hertzog I could skip those where 
the
>Debian version has something like +svn, +cvs, -pre, and also probably skip
>those such as yours: +n.

Fair enough.

>But those I really don't want to exclude are the ones
>having 'dsfg', 'ds', 'debian', or ones whose watch file really reports an
>older version (e.g. in Debian: 2.3.1, upstream: 2.0.1).
>

There are also packages where an upstream release is missing entirely.

This sounds more reasonable to me, but I think you should publish a revised 
list and give maintainers a chance to respond.

Scott K


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Russ Allbery]

Raphael Geissert <[EMAIL PROTECTED]> writes:

> In order to bring some more QA on the watch files subject I'd like to
> start a permanent MBF on packages whose Debian upstream version (the
> version string from Version: without the epoch and the Debian revision)
> is higher than the latest upstream version found thanks to their watch
> file.

> Russ Allbery <[EMAIL PROTECTED]>
>gnubg

Upstream stopped doing real releases a while back although hopefully will
again do some someday.  Currently, all that's available is nightly
snapshots.  I can:

* Keep pointing the watch file at the actual official release location in
  the hope that upstream will eventually release a newer official version.

* Point the watch file at the daily snapshots and have it always be out of
  date because I'm not going to release new versions of gnubg daily.

* Delete the watch file.

Which would you rather I do?  I personally think the first option is the
best, which is why I'm doing it, but I don't care that much.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Raphael Geissert]

Scott Kitterman wrote:
> On Sunday 17 February 2008 17:22, Raphael Geissert wrote:
>>
>> If Debian's 0.11+1-1 is upstream's 0.11 why not just strip the '+1' using
>> dversionmangle?
>> That's in my POV the bug.
>>
> I think rewriting watch files for one time events is a mistake.  If this
> were
> a permanent feature of the version numbering I would agree. 

The thing is, when you make such kind of uploads all you have to make sure
is that uscan still says your package is up to date. 

> I suppose the 
> easiest solution for me to not be bothered about this would be to remove
> the watch file on the next upload.

You won't be bothered if you also maintain the watch file.
And as I said in my response to Raphael Hertzog I could skip those where the
Debian version has something like +svn, +cvs, -pre, and also probably skip
those such as yours: +n.
But those I really don't want to exclude are the ones
having 'dsfg', 'ds', 'debian', or ones whose watch file really reports an
older version (e.g. in Debian: 2.3.1, upstream: 2.0.1).

> 
> Scott K

Cheers,
Raphael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Scott Kitterman]

On Sunday 17 February 2008 17:22, Raphael Geissert wrote:
> Scott Kitterman wrote:
> > On Sunday 17 February 2008 15:41, Raphael Geissert wrote:
> >> Please note that this situation often occurs when the maintainer didn't
> >> make the watch file strip some +VCSrevN that was added to the Debian
> >> Version.
> >>
> >> If nobody objects I'll start filling (in an automated way since there
> >> are no false positives) reports on the 307 source packages which report
> >> a Debian upstream version higher than Upstream version by the watch
> >> file.
> >
> > I disagree.  You list my package:
> >
> > Scott Kitterman <[EMAIL PROTECTED]>
> > pysubnettree
> >
> > The reason this package is in the state it's in is that upstream uploaded
> > a new version of the package without changing the released version number
> > so a
> > fake version number was needed.  While suboptimal, there is no bug in the
> > watch file.
>
> If Debian's 0.11+1-1 is upstream's 0.11 why not just strip the '+1' using
> dversionmangle?
> That's in my POV the bug.
>
I think rewriting watch files for one time events is a mistake.  If this were 
a permanent feature of the version numbering I would agree.  I suppose the 
easiest solution for me to not be bothered about this would be to remove the 
watch file on the next upload.

Scott K


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Raphael Geissert]

Scott Kitterman wrote:

> On Sunday 17 February 2008 15:41, Raphael Geissert wrote:
>>
>> Please note that this situation often occurs when the maintainer didn't
>> make the watch file strip some +VCSrevN that was added to the Debian
>> Version.
>>
>> If nobody objects I'll start filling (in an automated way since there are
>> no false positives) reports on the 307 source packages which report a
>> Debian upstream version higher than Upstream version by the watch file.
> 
> I disagree.  You list my package:
> 
> Scott Kitterman <[EMAIL PROTECTED]>
> pysubnettree
> 
> The reason this package is in the state it's in is that upstream uploaded
> a new version of the package without changing the released version number
> so a
> fake version number was needed.  While suboptimal, there is no bug in the
> watch file.

If Debian's 0.11+1-1 is upstream's 0.11 why not just strip the '+1' using
dversionmangle?
That's in my POV the bug.

> 
> While this is no doubt a rare condition, I believe that your assertion
> that there are no false positives is incorrect.
> 
> Scott K

Cheers,
Raphael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Raphael Geissert]

Wesley J. Landaker wrote:

> On Sunday 17 February 2008 13:41:34 Raphael Geissert wrote:
>> If nobody objects I'll start filling (in an automated way since there are
>> no false positives) reports on the 307 source packages which report a
>> Debian upstream version higher than Upstream version by the watch file.
> 
> I don't know what you mean by "there are no false positives". My ghdl
> package you mention is a false positive, for one.
> 

Please refer to my note:
> Please note that this situation often occurs when the maintainer didn't
make 
> the watch file strip some +VCSrevN that was added to the Debian
Version. 

package|Debian Version |upstream version|Debian upstream version
ghdl|0.26+gcc4.1.2~dfsg-2|0.26|0.26+gcc4.1.2

Comparing the upstream version and the Debian upstream version will,
correctly, say that the latter is higher (in other words: it isn't a false
positive, the Debian upstream version _IS_ higher than upstream).
Please also note that as explained on[1] DEHS is additionally
stripping 'dfsg', 'debian', and 'ds' from the Debian Version, which is
something IMHO must be done (and I'm of the opinion that DEHS should not do
that but let uscan and the watch file do it, hence my RFC of a version=4
watch file format I'll soon be sending to -devel).


[1]http://wiki.debian.org/DEHS (section 'Debian repackaging (a.k.a. trust
what uscan says)')


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Raphael Geissert]

Hello,

Raphael Hertzog wrote:
> Hello,
> 
> On Sun, 17 Feb 2008, Raphael Geissert wrote:
>> Rationale: the watch files are meant to keep track of upstream and if
>> there's a newer version not being reported by the watch file it means
>> that it needs to be fixed.
>> 
>> Please note that this situation often occurs when the maintainer didn't
>> make the watch file strip some +VCSrevN that was added to the Debian
>> Version.
>> 
>> If nobody objects I'll start filling (in an automated way since there are
>> no false positives) reports on the 307 source packages which report a
>> Debian upstream version higher than Upstream version by the watch file.
> 
> I do object. I don't think it's really important to complicate watch files
> to strip .dfsg or +svn that are addded by Debian maintainers. The most
> important thing with watch files is that a new upstream version is
> detected... but it's not important if the report says that Debian is newer
> than upstream when in fact we're at the same version.

Ack, what about only reporting (thus in a non automated way) on those which
are not affected by any repackaging/similar version part?

Some examples:
package|Debian Version|Reported upstream version|Debian upstream version
xrn|9.02-7.1|1|9.02
swfdec-gnome|2.21.90-2|0.5.5|2.21.90
conduit|0.3.6-2|0.3.4|0.3.6
diction|uupdate|1.11|uupdate
eject|2.1.5-6|2.1.0|2.1.5
epiphany|0.7.0-1|0.6.1|0.7.0
at-spi|1.21.5-1|1.20.1|1.21.5
glib2.0|2.15.5-1|2.14.6|2.15.5
...and so on

> 
> And when we have +svn we are indeed newer than the upstream released
> tarball and the information is correct! So stripping that part would be a
> mistake.

IMHO it would be better to strip that part with a dversionmangle. However,  
DEHS currently compares with $upstream le $debian so those packages are
marked as up to date.

> 
> Cheers,

Cheers,
Raphael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Wesley J. Landaker]

On Sunday 17 February 2008 13:41:34 Raphael Geissert wrote:
> If nobody objects I'll start filling (in an automated way since there are
> no false positives) reports on the 307 source packages which report a
> Debian upstream version higher than Upstream version by the watch file.

I don't know what you mean by "there are no false positives". My ghdl 
package you mention is a false positive, for one.

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


signature.asc
Description: This is a digitally signed message part.

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Scott Kitterman]

On Sunday 17 February 2008 15:41, Raphael Geissert wrote:
> Hello all,
>
> [Please respect the Reply-To header]
>
> In order to bring some more QA on the watch files subject I'd like to start
> a permanent MBF on packages whose Debian upstream version (the version
> string from Version: without the epoch and the Debian revision) is higher
> than the latest upstream version found thanks to their watch file.
>
> Rationale: the watch files are meant to keep track of upstream and if
> there's a newer version not being reported by the watch file it means that
> it needs to be fixed.
>
> Please note that this situation often occurs when the maintainer didn't
> make the watch file strip some +VCSrevN that was added to the Debian
> Version.
>
> If nobody objects I'll start filling (in an automated way since there are
> no false positives) reports on the 307 source packages which report a
> Debian upstream version higher than Upstream version by the watch file.

I disagree.  You list my package:

Scott Kitterman <[EMAIL PROTECTED]>
   pysubnettree

The reason this package is in the state it's in is that upstream uploaded a 
new version of the package without changing the released version number so a 
fake version number was needed.  While suboptimal, there is no bug in the 
watch file.

While this is no doubt a rare condition, I believe that your assertion that 
there are no false positives is incorrect.

Scott K

Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Raphael Hertzog]

Hello,

On Sun, 17 Feb 2008, Raphael Geissert wrote:
> Rationale: the watch files are meant to keep track of upstream and if there's 
> a newer version not being reported by the watch file it means that it needs 
> to be fixed. 
> 
> Please note that this situation often occurs when the maintainer didn't make 
> the watch file strip some +VCSrevN that was added to the Debian Version. 
> 
> If nobody objects I'll start filling (in an automated way since there are no 
> false positives) reports on the 307 source packages which report a Debian 
> upstream version higher than Upstream version by the watch file.

I do object. I don't think it's really important to complicate watch files
to strip .dfsg or +svn that are addded by Debian maintainers. The most
important thing with watch files is that a new upstream version is
detected... but it's not important if the report says that Debian is newer
than upstream when in fact we're at the same version. 

And when we have +svn we are indeed newer than the upstream released
tarball and the information is correct! So stripping that part would be a
mistake.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Proposed MBF: Debian upstream version higher than watch file-reported upstream version

[Raphael Geissert]

Hello all,

[Please respect the Reply-To header]

In order to bring some more QA on the watch files subject I'd like to start a 
permanent MBF on packages whose Debian upstream version (the version string 
from Version: without the epoch and the Debian revision) is higher than the 
latest upstream version found thanks to their watch file.

Rationale: the watch files are meant to keep track of upstream and if there's 
a newer version not being reported by the watch file it means that it needs 
to be fixed. 

Please note that this situation often occurs when the maintainer didn't make 
the watch file strip some +VCSrevN that was added to the Debian Version. 

If nobody objects I'll start filling (in an automated way since there are no 
false positives) reports on the 307 source packages which report a Debian 
upstream version higher than Upstream version by the watch file.

I'm attaching a list of these packages so I give some time for maintainers to 
fix the watch files before this MBF is accepted (!objected) and the automated 
MBF script is written.

All the reports will be available at[1].

Any kind of feedback is, as usually, welcomed.

[1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=atomo64%40gmail.com;tag=dehs-dver-higher-thanup

Kind regards,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
Hideki Yamane (Debian-JP) <[EMAIL PROTECTED]>
   ttf-kiloji (U)

Marc Dequènes (Duck) <[EMAIL PROTECTED]>
   arkrpg
   genetic

Adam Cécile (Le_Vert) <[EMAIL PROTECTED]>
   aircrack-ng
   museek+
   ripole

Masayuki Hatta (mhatta) <[EMAIL PROTECTED]>
   a2ps
   mendexk
   ptex-bin

Siegfried-Angel Gevatter Pujals (RainCT) <[EMAIL PROTECTED]>
   glest (U)
   lightyears

J.H.M. Dassen (Ray) <[EMAIL PROTECTED]>
   libgnetwork (U)

Jari Aalto <[EMAIL PROTECTED]>
   agrep
   micro-httpd

Clint Adams <[EMAIL PROTECTED]>
   arch-perl
   archway
   axp

Moray Allan <[EMAIL PROTECTED]>
   gpe-todo
   libgpevtype
   libmatchbox
   matchbox-window-manager
   xrestop

Russ Allbery <[EMAIL PROTECTED]>
   gnubg

maximilian attems <[EMAIL PROTECTED]>
   klibc

Richard Atterer <[EMAIL PROTECTED]>
   btyacc

Khalid Aziz <[EMAIL PROTECTED]>
   prctl

Sebastien Bacher <[EMAIL PROTECTED]>
   libgnetwork (U)
   mlview
   pango1.0

Alan Baghumian <[EMAIL PROTECTED]>
   gparted (U)

Jeff Bailey <[EMAIL PROTECTED]>
   gnumach (U)
   klibc (U)
   mig (U)

Michael Banck <[EMAIL PROTECTED]>
   apbs
   pymol (U)

Carlos Barros <[EMAIL PROTECTED]>
   tac-plus

Dima Barsky <[EMAIL PROTECTED]>
   esniper

Daniel Baumann <[EMAIL PROTECTED]>
   9base
   acct
   cdrdao
   gnushogi
   pfqueue

Romain Beauxis <[EMAIL PROTECTED]>
   php-xml-htmlsax3

Dave Beckett <[EMAIL PROTECTED]>
   cairo

Alexander L. Belikoff <[EMAIL PROTECTED]>
   xboard

Christoph Berg <[EMAIL PROTECTED]>
   hobbit
   libyada
   mutt (U)

Marcus Better <[EMAIL PROTECTED]>
   commons-daemon (U)
   kernel-patch-exec-shield

Michael Biebl <[EMAIL PROTECTED]>
   knetworkmanager

Luca Bigliardi <[EMAIL PROTECTED]>
   freej (U)

Laurent Bigonville <[EMAIL PROTECTED]>
   tapioca-glib (U)

Kęstutis Biliūnas <[EMAIL PROTECTED]>
   liblingoteach
   lingoteach-lesson
   xgridfit (U)

Darren Blaber <[EMAIL PROTECTED]>
   atheme-services (U)

Phil Blundell <[EMAIL PROTECTED]>
   gpe-todo (U)

Jérémy Bobbio <[EMAIL PROTECTED]>
   zope-quotafolder (U)

Jay Bonci <[EMAIL PROTECTED]>
   libxml-rss-perl (U)

Dmitry Borodaenko <[EMAIL PROTECTED]>
   redcloth
   samizdat

Giuseppe Borzi <[EMAIL PROTECTED]>
   glest (U)

Bjoern Boschman <[EMAIL PROTECTED]>
   phpsysinfo

Fathi Boudra <[EMAIL PROTECTED]>
   kphotoalbum (U)
   taskjuggler (U)

Fathi Boudra <[EMAIL PROTECTED]>
   icecc (U)
   kwlan (U)

Cyril Bouthors <[EMAIL PROTECTED]>
   drbd8

Marcus Brinkmann <[EMAIL PROTECTED]>
   gnumach (U)
   mig (U)

Marc 'HE' Brockschmidt <[EMAIL PROTECTED]>
   at-spi (U)
   libbonobo (U)
   libbonoboui (U)
   libgnetwork (U)
   zoidberg

Frank B. Brokken <[EMAIL PROTECTED]>
   icmake (U)

Philip Brown <[EMAIL PROTECTED]>
   filter

Cyril Brulebois <[EMAIL PROTECTED]>
   octaviz (U)

Luca Bruno <[EMAIL PROTECTED]>
   nemiver

Thomas Bushnell, BSG <[EMAIL PROTECTED]>
   lilypond

Ansgar Burchardt <[EMAIL PROTECTED]>
   glest (U)

Clint Burfoot <[EMAIL PROTECTED]>
   liberror-perl

Ben Burton <[EMAIL PROTECTED]>
   libarchive-zip-perl

Ross Burton <[EMAIL PROTECTED]>
   gossip
   libgnetwork (U)

Marco Cabizza <[EMAIL PROTECTED]>
   libgnetwork (U)

Jose Calhariz <[EMAIL PROTECTED]>
   xorp

Giacomo Catenazzi <[EMAIL PROTECTED]>
   g15mpd
   libg15render

Hubert Chan <[EMAIL PROTECTED]>
   ffcall

Hubert Chathi <[EMAIL PROTECTED]>
   addresses-for-gnustep (U)
   asymptote

Christopher L Cheney <[EMAIL PROTECTED]>
   libsynce

Adam Conrad <[EMAIL PROTECTED]>
   mysql-dfsg-5.0 (U)
   samba (U)

Jeremie Corbier <[EMAIL PROTECTED]>
   mmpython

Andrea Corradi <[EMAIL PROTECTED]>
   nemiver (U)

Jereme C