[Thijs Kinkhorst]
> Yes, but the point raised was whether it would be better to
> centralise that. There are a lot of opportunities to run lintian but
> appearently a lot of packages with errors/warnings are being
> uploaded.
Sometimes lintian tests have bugs / limitations - false positives which
On Mon, 2006-02-27 at 19:18 +0100, Thomas Viehmann wrote:
> Note that individual maintainers can already configure dput to stop the
> upload on lintian/linda errors.
Yes, but the point raised was whether it would be better to centralise
that. There are a lot of opportunities to run lintian but app
Thijs Kinkhorst wrote:
> On Mon, 2006-02-27 at 18:40 +0200, Lars Wirzenius wrote:
>>If we are to start doing checks on packages before accepting uploads, I
>>think it would be best to start with some subset of lintian and linda
>>errors.
Note that individual maintainers can already configure dput
On Mon, 2006-02-27 at 18:40 +0200, Lars Wirzenius wrote:
> If we are to start doing checks on packages before accepting uploads, I
> think it would be best to start with some subset of lintian and linda
> errors.
Since these tools can already differentiate between errors and warnings,
it would ma
ma, 2006-02-27 kello 18:39 +0100, Goswin von Brederlow kirjoitti:
> I think it would be best for the buildd to run this and append the
> result to the buildd log.
I don't, because, as I said, piuparts tests often fail for reasons
completely unrelated to the package itself, and there is no point in
Lars Wirzenius <[EMAIL PROTECTED]> writes:
> pe, 2006-02-24 kello 18:27 -0300, Gustavo Franco kirjoitti:
>> I would be glad to help with a web interface to show the piuparts html
>> results in a organized way
>
> Something like piuparts-report.py?
>
> Anyway, I think it is more productive if packa
pe, 2006-02-24 kello 18:27 -0300, Gustavo Franco kirjoitti:
> What i thought in a first look to the Lars' list. I think that the
> best thing would include piuparts as a infrastructural test (oficially
> as a part of our archive code), or due to restrict admin time to do
> that, opt for something l
[Gustavo Franco]
> I won't waste my time writing a patch without hear Lars' and lintian
> maintainers opinions first.
Fair enough, but your original statement was, IMO, too vague. You said
"some of" the piuparts-detected problems looked as though lintian
should be able to catch them, but you did
On 2/24/06, Russ Allbery <[EMAIL PROTECTED]> wrote:
> Gustavo Franco <[EMAIL PROTECTED]> writes:
> > On 2/20/06, Lars Wirzenius <[EMAIL PROTECTED]> wrote:
>
> >> In the past six months, I've filed about 260 bug reports based on what
> >> piuparts has found. About 40% of those have been fixed so far
Gustavo Franco <[EMAIL PROTECTED]> writes:
> On 2/20/06, Lars Wirzenius <[EMAIL PROTECTED]> wrote:
>> In the past six months, I've filed about 260 bug reports based on what
>> piuparts has found. About 40% of those have been fixed so far. Below is
>> a summary of the common problems, hopefully the
On 2/24/06, Peter Samuelson <[EMAIL PROTECTED]> wrote:
>
> [Gustavo Franco]
> > I think some of these problems can be detected by lintian, adding
> > some more checks there. It could bring more visibility to so common
> > errors. Comments ?
>
> A better way to phrase "Comments?" would be: "Here is
[Gustavo Franco]
> I think some of these problems can be detected by lintian, adding
> some more checks there. It could bring more visibility to so common
> errors. Comments ?
A better way to phrase "Comments?" would be: "Here is a proof-of-
concept patch to lintian to demonstrate which of these
On 2/20/06, Lars Wirzenius <[EMAIL PROTECTED]> wrote:
> In the past six months, I've filed about 260 bug reports based on what
> piuparts has found. About 40% of those have been fixed so far. Below is
> a summary of the common problems, hopefully the list will help everyone
> to find and especially
Don Armstrong <[EMAIL PROTECTED]> writes:
> On Thu, 23 Feb 2006, Frank Küster wrote:
>> Don Armstrong <[EMAIL PROTECTED]> wrote:
>> > On Wed, 22 Feb 2006, Frank Küster wrote:
>> >> Adeodato Simó <[EMAIL PROTECTED]> wrote:
>> >> > Correct, so one would put in foo.postrm:
>> >> >
>> >> > rmdir
On Thu, 23 Feb 2006, Frank Küster wrote:
> Don Armstrong <[EMAIL PROTECTED]> wrote:
> > On Wed, 22 Feb 2006, Frank Küster wrote:
> >> Adeodato Simó <[EMAIL PROTECTED]> wrote:
> >> > Correct, so one would put in foo.postrm:
> >> >
> >> > rmdir --ignore-fail-on-non-empty /usr/local/lib/foo
> >>
Don Armstrong <[EMAIL PROTECTED]> wrote:
> On Wed, 22 Feb 2006, Frank Küster wrote:
>> Adeodato Simó <[EMAIL PROTECTED]> wrote:
>> > Correct, so one would put in foo.postrm:
>> >
>> > rmdir --ignore-fail-on-non-empty /usr/local/lib/foo
>>
>> That's not sufficient, because /usr/local may be
On Wed, 22 Feb 2006, Frank Küster wrote:
> Adeodato Simó <[EMAIL PROTECTED]> wrote:
> > Correct, so one would put in foo.postrm:
> >
> > rmdir --ignore-fail-on-non-empty /usr/local/lib/foo
>
> That's not sufficient, because /usr/local may be mounted ro, and
> therefore the command may fail e
Peter Samuelson <[EMAIL PROTECTED]> wrote:
> [Frank Küster]
>> That's not sufficient, because /usr/local may be mounted ro, and
>> therefore the command may fail even if the directory is empty.
>
> U.
>
> There are lots of things dpkg can do which fail if filesystems are
> mounted read-only.
[Frank Küster]
> That's not sufficient, because /usr/local may be mounted ro, and
> therefore the command may fail even if the directory is empty.
U.
There are lots of things dpkg can do which fail if filesystems are
mounted read-only. I don't think this is something worth worrying
about.
On Wed, Feb 22, 2006 at 17:42:00 +, Olaf van der Spek wrote:
> Shouldn't logic like that be in one central place (dpkg or a library)
> and not spread over dozens of packages?
Something like dh_usrlocal(1)?
Cheers,
Julien
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "uns
"Olaf van der Spek" <[EMAIL PROTECTED]> wrote:
> On 2/22/06, Frank Küster <[EMAIL PROTECTED]> wrote:
>> Adeodato Simó <[EMAIL PROTECTED]> wrote:
>>
>> > Correct, so one would put in foo.postrm:
>> >
>> > rmdir --ignore-fail-on-non-empty /usr/local/lib/foo
>>
>> That's not sufficient, because
On 2/22/06, Frank Küster <[EMAIL PROTECTED]> wrote:
> Adeodato Simó <[EMAIL PROTECTED]> wrote:
>
> > Correct, so one would put in foo.postrm:
> >
> > rmdir --ignore-fail-on-non-empty /usr/local/lib/foo
>
> That's not sufficient, because /usr/local may be mounted ro, and
> therefore the comman
to, 2006-02-23 kello 02:26 +1100, Anand Kumria kirjoitti:
> On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote:
> >
> > * Creating /usr/local/lib/foo in postinst, but not removing it
> > in postrm.
>
> I don't think that is a problem at all; the administrator ought to
Adeodato Simó <[EMAIL PROTECTED]> wrote:
> Correct, so one would put in foo.postrm:
>
> rmdir --ignore-fail-on-non-empty /usr/local/lib/foo
That's not sufficient, because /usr/local may be mounted ro, and
therefore the command may fail even if the directory is empty.
rmdir --ignore-fail-on
* Anand Kumria [Thu, 23 Feb 2006 02:26:43 +1100]:
Hi,
> On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote:
> > * Creating /usr/local/lib/foo in postinst, but not removing it
> > in postrm.
> I don't think that is a problem at all; the administrator ought to feel
> f
Hi Lars,
On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote:
>
> * Creating /usr/local/lib/foo in postinst, but not removing it
> in postrm.
I don't think that is a problem at all; the administrator ought to feel
free to be able to put things in (say) /usr/local/lib/f
On 20 Feb 2006, Lars Wirzenius stated:
> I added a Cc to Manoj since I would like to hear his
> comment. Whoever responds may want to remove the Cc to avoid
> stuffing his inbox unnecessarily.
>
> su, 2006-02-19 kello 23:42 -0800, Steve Langasek kirjoitti:
>> On Mon, Feb 20, 2006 at 08:24:53AM +02
Lars Wirzenius <[EMAIL PROTECTED]> wrote:
> Hm. I don't use ucf on my own packages (yet), so my understanding is a
> bit hazy, but if I have understood correctly, the actual config file is
> removed with rm anyway, and ucf is needed on purge only to remove the
> config file also from ucf's history
I added a Cc to Manoj since I would like to hear his comment. Whoever
responds may want to remove the Cc to avoid stuffing his inbox
unnecessarily.
su, 2006-02-19 kello 23:42 -0800, Steve Langasek kirjoitti:
> On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote:
> > * Use of ucf
On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote:
> * Use of ucf in postrm during a purge, without checking that ucf
> is installed. Since ucf is not an essential package, postrm
> during purge cannot rely on it. As it happens, I think it might
> be goo
30 matches
Mail list logo
