Guillem Jover wrote:
> On Tue, 2011-05-10 at 16:28:56 -0500, Jonathan Nieder wrote:
>> I think a good fix would be to unconditionally batch the errors and
>> require a --verbose or similar flag to get the full list. Would you
>> be interested in working on that?
>
> I've already code for this and
Hi!
On Tue, 2011-05-10 at 16:28:56 -0500, Jonathan Nieder wrote:
> Matteo Cortese wrote:
> > Would you consider a flag to switch this warning off?
> >
> > Like David, I've already missed a number of errors hidden in a sea of
> > "version string does not start with digit" lines.
>
> I think a good
Hi Matteo,
Matteo Cortese wrote:
> Would you consider a flag to switch this warning off?
>
> Like David, I've already missed a number of errors hidden in a sea of
> "version string does not start with digit" lines.
I think a good fix would be to unconditionally batch the errors and
require a --v
Would you consider a flag to switch this warning off?
Like David, I've already missed a number of errors hidden in a sea of "version
string does not start with digit" lines.
Please remember that this affects people who have compiled their kernel
following an official although misleading README.
Or, more generally, if someone can explain how to revert to pre-1.16
behavior, I'd be very grateful, because I have dozens of locally
compiled kernel packages installed on my system, causing every
invocation of dpkg to spew hundreds of lines of useless warnings,
making it nearly unusable (any valid
On Sat, Apr 09, 2011 at 10:32:14AM +0200, Guillem Jover wrote:
> What I've locally now is the following (might get slightly refined
> before the push though):
>
> --compare-versions is lax by default now, will still warn though.
> One of the reasons I ended up with the strict parser for
> --compar
Hi!
On Tue, 2011-04-05 at 08:20:01 +0200, Raphael Hertzog wrote:
> On Tue, 05 Apr 2011, Guillem Jover wrote:
> > On Tue, 2011-04-05 at 07:48:58 +0200, Raphael Hertzog wrote:
> > > On Tue, 05 Apr 2011, Guillem Jover wrote:
> > > > The strict parser should only take effect on anything that's not the
On Tue, 05 Apr 2011, Guillem Jover wrote:
> On Tue, 2011-04-05 at 07:48:58 +0200, Raphael Hertzog wrote:
> > On Tue, 05 Apr 2011, Guillem Jover wrote:
> > > The strict parser should only take effect on anything that's not the
> > > status or the available files and --compare-versions.
> >
> > Not
On Tue, 2011-04-05 at 07:48:58 +0200, Raphael Hertzog wrote:
> On Tue, 05 Apr 2011, Guillem Jover wrote:
> > The strict parser should only take effect on anything that's not the
> > status or the available files and --compare-versions.
>
> Not sure I parse your sentence correctly, but
> --compare-
Hi,
Guillem Jover wrote:
> On Mon, 2011-04-04 at 23:57:39 -0500, Jonathan Nieder wrote:
>> I'd be happy to work on a fix to this that fits nicely with dpkg's
>> design and is agreeable to people. Any hints or pointers?
>
> Sorry, I guess I don't follow, a fix for what? We are talking about
> jus
On Tue, 05 Apr 2011, Guillem Jover wrote:
> The strict parser should only take effect on anything that's not the
> status or the available files and --compare-versions.
Not sure I parse your sentence correctly, but
--compare-versions uses the strict parser:
$ dpkg --compare-versions foo2 eq foo2
Hi!
On Mon, 2011-04-04 at 23:57:39 -0500, Jonathan Nieder wrote:
> Raphael Hertzog wrote:
> > He's using dselect apparently, so it's probably dpkg-query --predep which
> > is spitting out those warnings (it's the only dpkg-query command that
> > parses the available file).
Actually, there's other
Hi,
Raphael Hertzog wrote:
> He's using dselect apparently, so it's probably dpkg-query --predep which
> is spitting out those warnings (it's the only dpkg-query command that
> parses the available file).
Ah, that makes sense.
I'd be happy to work on a fix to this that fits nicely with dpkg's
d
On Mon, 04 Apr 2011, Jonathan Nieder wrote:
> Wait a second. I'm not up to speed on the exact design, but such
> widelands versions really _were_ in the archive once (according to
> snapshot.debian.org). And this is about dpkg-query looking through
> the "available" file, not "dpkg -i". Are you
Jonathan Nieder wrote:
> Gordon Haverland wrote:
Sorry, sloppy of me. The quoted text is by Raphaël, not Gordon, for
those who were wondering what had happened to the world. :).
>> None of those packages are official Debian packages. I suggest you get in
>> touch with the providers of those pack
Gordon Haverland wrote:
> None of those packages are official Debian packages. I suggest you get in
> touch with the providers of those packages so that they update them
> accordingly.
>
> As noted, it's not a bug but a deliberate change.
Wait a second. I'm not up to speed on the exact design, b
On Mon, 04 Apr 2011, Gordon Haverland wrote:
> In terms of the kernels I compiled myself, they were named
> according to the instructions that were present at one time for
> kernel-package. The README.gz in /usr/share/doc/kernel-package
> still shows version strings that are not strictly numeri
Hello.
On April 4, 2011, Hilmar Preusse wrote:
> On 03.04.11 Gordon Haverland (ghave...@materialisations.com)
> wrote:
> > I normally compile my own kernels. dpkg-query is giving
> > errors on these self-compiled kernels. (newmain.1 and
> > newmain.2) are the specific strings causing problems.
>
On 03.04.11 Gordon Haverland (ghave...@materialisations.com) wrote:
Hi,
> I normally compile my own kernels. dpkg-query is giving errors on
> these self-compiled kernels. (newmain.1 and newmain.2) are the
> specific strings causing problems.
>
This could be an intended change:
dpkg (1.16.0) u
Package: dpkg
Version: 1.16.0
Severity: normal
I normally compile my own kernels. dpkg-query is giving errors
on these self-compiled kernels. (newmain.1 and newmain.2) are the
specific strings causing problems.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy
20 matches
Mail list logo
