Your message dated Tue, 20 May 2008 20:15:51 +0200 with message-id <20080520181551.GB22689@artemis.madism.org> and subject line Re: Bug#482086: lintian should not parse debian/rules but use debian/rules -nq <target> instead has caused the Debian Bug report #482086, regarding lintian should not parse debian/rules but use debian/rules -nq <target> instead to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 482086: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482086 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: lintian should not parse debian/rules but use debian/rules -nq <target> instead
- From: Pierre Habouzit <madcoder@debian.org>
- Date: Tue, 20 May 2008 19:41:08 +0200
- Message-id: <[🔎] 20080520174108.22359.52219.reportbug@artemis>
Package: lintian Version: 1.23.48 Severity: normal When using implicit rules, like %:, you won't see the target name spelled out explicitly. The proper way to do is to use the -q gnu make feature to know for sure if the target is here. debian/rules -nq <target-name> will return 0 or 1 if the target exists, 2 if not (0 means the target exists and is up 2 date, 1 that the target exists and is _not_ up 2 date, and 2 that the target doesn't exist). Of course, this implies that debian/rules is makefile, but AFAICT it's always the case in Debian.
--- End Message ---
--- Begin Message ---
- To: Russ Allbery <rra@debian.org>
- Cc: 482086-done@bugs.debian.org
- Subject: Re: Bug#482086: lintian should not parse debian/rules but use debian/rules -nq <target> instead
- From: Pierre Habouzit <madcoder@debian.org>
- Date: Tue, 20 May 2008 20:15:51 +0200
- Message-id: <20080520181551.GB22689@artemis.madism.org>
- In-reply-to: <[🔎] 87mymksv9f.fsf@windlord.stanford.edu>
- References: <[🔎] 20080520174108.22359.52219.reportbug@artemis> <[🔎] 87y764sw1x.fsf@windlord.stanford.edu> <[🔎] 20080520180301.GA22689@artemis.madism.org> <[🔎] 87mymksv9f.fsf@windlord.stanford.edu>
On Tue, May 20, 2008 at 06:09:00PM +0000, Russ Allbery wrote: > Pierre Habouzit <madcoder@debian.org> writes: > > On Tue, May 20, 2008 at 05:51:54PM +0000, Russ Allbery wrote: > > >> We tried to do this earlier and it broken horribly because when you use > >> make -n, you can get false negatives, and if you don't use -n, well, > >> obviously bad things happen. > > > Have you any idea of why -n could get errors ? I've built a system at > > work that uses make -nspqr heavily and I've seen almost no issues so > > far, so I'm a bit surprised. > > I think the problem was specifically with invocations of submakes, which > is how some packages end up implementing these rules. There's a bug > somewhere, but I can't find it at the moment. :/ Hmm I see. > > See planet.debian.org today :) > > debhelper v7 is already fixed in Subversion, which I assume is what you > were referring to. Have you run into anything else? I had in the past, but fixed it another way in the end. Well, let's forget about it. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.orgAttachment: pgpWVfXUL6AnT.pgp
Description: PGP signature
--- End Message ---