reopen 335660 Carl Fink <[EMAIL PROTECTED]>
found 335660 3.0.3-2-1
tags 335660 moreinfo unreproducible
thanks
Okay, so re reopen this bug report with you as the submitter and with
3.0.3-2-1 as a problem release.
On Sat, 29 Jul 2006, Carl Fink wrote:
> > Please note, that 3.0.3-2-1 is in etch and sid, which is _newer_
> > than 3.0.3-6 (yes, the numbering is very ugly, but upstream
> > stepped from 3.0.3 to 3.0.3-2 (upstream version!), so 3.0.3-2-1 is
> > the new Debian version). This numbering is correct in the sense
> > of Debian version numbering:
> I believe you, but that's pointlessly confusing. The difference in
> meaning between hyphens and periods there is just needlessly, well,
> pointless.
Yes, it wasn't a good idea to use 3.0.3-2 as the privoxy upstream
version number and maybe I should have renamed this 3.0.3.2, but now
this version is in the archive and according to policy this version
number is correct (only the rightmost hyphen defines the beginning of
the Debian version). Anyway, there seems to be some movement in the
upstream privoxy version, so we will have a 3.0.4 or 3.1 or something
like this (without hyphens) upstream hopefully soon.
> So, do I file a bug against dpkg or Apt to make this argument to the
> Project Leader?
You have to change the Debian policy which defines the syntax of a
version in section 5.6.12:
5.6.12. `Version'
-----------------
The version number of a package. The format is:
[<epoch>`:']<upstream_version>[`-'<debian_revision>]
The three components here are:
[...]
<debian_revision>
This part of the version number specifies the version of the
Debian package based on the upstream version. It may contain
only alphanumerics and the characters `+' and `.' (plus and full
stop) and is compared in the same way as the <upstream_version>
is.
[...]
As you can see the <debian_revision> isn't allowed to contain a
hyphen, so 3.0.3-2 must be the <upstream_version> :-)
> > I don't have any idea what happens there. I use privoxy every day on
> > several machines (i686 and amd64) and never got the message "cannot
> > resolve domain". I use a local caching DNS on the amd64 machine,
> > while all others use nameservers on other machines.
> > If you can reproduce this problem, maybe it's possible to do some
> > sniffering to find out what happens between your privoxy and the
> > nameserver (maybe you really have a DNS problem?).
> I can't reproduce it on demand, but it happens to me every day.
That makes it even harder to diagnose it :-|
> What diagnostics would help you to solve it?
I hoped, that you could run a sniffer like ethereal to log the
complete network traffic (at least the DNS traffic). So if the
problem occurs, you can look into the DNS trace and find out, whether
privoxy got an answer to its DNS query.
But if the problem happens only once a day, this won't be feasible.
Do you see anything unusual in the privoxy log file when this problem
happens?
Thanks for your help
Roland
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
