Bug#483475: still complains about missing targets when dh is used

[Joey Hess]

Package: lintian
Version: 1.23.49
Severity: normal

If I have a simple rules file using dh, like

#!/usr/bin/make -f
%:
dh $@

lintian still complains:

E: tasksel source: debian-rules-missing-required-target binary-arch
E: tasksel source: debian-rules-missing-required-target build
E: tasksel source: debian-rules-missing-required-target clean

It should notice that there's an implicit rule.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils2.18.1~cvs20080103-6 The GNU assembler, linker and bina
ii  diffstat1.45-2   produces graph of changes introduc
ii  dpkg-dev1.14.19  package building tools for Debian
ii  file4.24-2   Determines file type using "magic"
ii  gettext 0.17-2   GNU Internationalization utilities
ii  intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf
ii  libparse-debianchan 1.1.1-2  parse Debian changelogs and output
ii  liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin
ii  man-db  2.5.2-1  on-line manual pager
ii  perl [libdigest-sha 5.10.0-10Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#482869: lintian: no-md5sums-control-file false positive on package containing only conffiles

[Russ Allbery]

Joey Hess <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:

>> We do already have code that's supposed to check whether an md5sums
>> control file is needed.  It apparently isn't working right.  (Naively,
>> I would have thought that files in /etc would still have md5sums in the
>> package?  I'm probably just confused.)

> dpkg already includes md5sums for conffiles, so it's redundant to put
> those in the md5sums file (though dh_md5sums can do it if asked via -x).

Oh, okay, that makes perfect sense.  Thanks.

-- 
Russ Allbery ([EMAIL PROTECTED])   



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

Bug#482869: lintian: no-md5sums-control-file false positive on package containing only conffiles

[Joey Hess]

Russ Allbery wrote:
> We do already have code that's supposed to check whether an md5sums
> control file is needed.  It apparently isn't working right.  (Naively, I
> would have thought that files in /etc would still have md5sums in the
> package?  I'm probably just confused.)

dpkg already includes md5sums for conffiles, so it's redundant to put
those in the md5sums file (though dh_md5sums can do it if asked via -x).

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#482869: lintian: no-md5sums-control-file false positive on package containing only conffiles

[Russ Allbery]

Frank Lichtenheld <[EMAIL PROTECTED]> writes:

> Hmm, I wonder if it wouldn't be better for dh_md5sums to generate an
> empty md5sums file in this case to make it clear that it checked but
> found no files that needed to be listed.
>
> Otherwise every other program that tries to use the information later
> will need to check again. OTOH they probably need to check anyway since
> an empty md5sums file also could be an error.

We do already have code that's supposed to check whether an md5sums
control file is needed.  It apparently isn't working right.  (Naively, I
would have thought that files in /etc would still have md5sums in the
package?  I'm probably just confused.)

-- 
Russ Allbery ([EMAIL PROTECTED])   



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

Re: [checks/scripts] script_is_evil_and_wrong() and bashisms update

[Frank Lichtenheld]

On Tue, May 20, 2008 at 06:32:42AM +0100, Adam D. Barratt wrote:
> On Tue, 2008-05-20 at 03:15 +0200, Frank Lichtenheld wrote:
> > On Sat, May 17, 2008 at 10:51:03AM +0100, Adam D. Barratt wrote:
> > > On Fri, May 16, 2008 23:58, Frank Lichtenheld wrote:
> [...]
> > > > Have you generated an account at http://svn.wolffelaar.nl/ ?
> > > 
> > > I've tried, a few times, but it appears that either I'm struggling with
> > > the IQ test or the form's broken (obviously I'd plump for the latter :-)
> > > 
> > > I pinged jvw via e-mail a couple of weeks ago but didn't get a response as
> > > yet.
> > 
> > Ok.
> > 
> > Maybe that code should be moved to Alioth at some point...
> 
> I did notice that there was an Alioth project for lintian (although it
> doesn't seem to have been used; the SVN repo is still at revision 0).

I've now requested the creation of a git repo on Alioth now and plan to fill
it with content in the next days. Feel free to make a "Request to Join"
via the Alioth interface.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Bug#482869: lintian: no-md5sums-control-file false positive on package containing only conffiles

[Frank Lichtenheld]

On Sun, May 25, 2008 at 12:30:54PM -0400, Zack Weinberg wrote:
> I have a package that contains only conffiles and directories.  (It works
> with another package that can, among other things, be used as a network
> server, by providing scripts and a directory hierarchy to make that easy.)
[...]
> Naturally enough, dh_md5sums does not produce a checksums file for this
> package, which makes lintian object:
> 
> $ lintian -I monotone_0.40-3_amd64.changes
> I: monotone-server: no-md5sums-control-file
> 
> Please consider having this check verify that there are regular files in
> the package that are not conffiles.

Hmm, I wonder if it wouldn't be better for dh_md5sums to generate an
empty md5sums file in this case to make it clear that it checked but
found no files that needed to be listed.

Otherwise every other program that tries to use the information later
will need to check again. OTOH they probably need to check anyway since
an empty md5sums file also could be an error.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/



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

Re: Lintian Maints happy with Subversion?

[Frank Lichtenheld]

On Mon, May 19, 2008 at 06:46:52PM -0700, Russ Allbery wrote:
> Frank Lichtenheld <[EMAIL PROTECTED]> writes:
> > Since lintian is one of the few remaining pieces of original code (as
> > opposed to non-native packages) that I co-maintain and that is not yet
> > maintained in a distributed VCS I justed wanted to ask what the other
> > co-maintainers think about switching the VCS?
> >
> > Would you prefer remaining with SVN?
> > If no, which other VCS would you prefer?
> >
> > My choice would be to switch to git, but hg or bzr
> > would also be ok if there is a majority for them.
> 
> *heh*.  I sent my other message before seeing this.  Yeah, I'd be very
> happy to move to Git.

I think everybody had plenty time to object. I will go ahead with this
then.

Does anybody still have the old CVS repo around. IIRC we did not import
that when we created the SVN repo. Jeroen maybe?

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Processed: tagging 482795

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.10.28
> tags 482795 wontfix
Bug#482795: lintian: should not recommend debian/templates.pot to exist in 
source
There were no tags set.
Tags added: wontfix

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Bug#483384: lintian: False positive on native-package-with-dash-version with 3.0 (quilt) source packages

[Raphael Hertzog]

Package: lintian
Version: 1.23.49
Severity: normal

If you generate a "3.0 (quilt)" source package with
$ dpkg-source --format="3.0 (quilt)" -b mypackagedir
and you analyze with lintian the generated source package you'll end up
with something like this:
W: quilt source: native-package-with-dash-version

But the source package is definitely not native:
$ cat ../quilt_0.46-4.1.dsc 
Format: 3.0 (quilt)
Source: quilt
Binary: quilt
Architecture: all
Version: 0.46-4.1
Maintainer: Martin Quinson <[EMAIL PROTECTED]>
Uploaders: Martin Quinson <[EMAIL PROTECTED]>, Simon Horman <[EMAIL PROTECTED]>
Standards-Version: 3.6.1.0
Build-Depends: cdbs (>= 0.4.23-1.1), debhelper (>= 4.1.0)
Build-Depends-Indep: gettext, hevea, lynx, diffstat
Checksums-Sha1: 
 9344c1289f262053beb0196645b41ea5d9cda597 403984 quilt_0.46.orig.tar.gz
 384fa4d069913b20fe50699dc77da9f8f644b741 38224 quilt_0.46-4.1.debian.tar.gz
Checksums-Sha256: 
 47bf030565bb462840db694acc183273455714028c74974c5b3a3bd4ad29ad89 403984 
quilt_0.46.orig.tar.gz
 e52b6fc53a588957e71d7245516fd591e3e5efd610f6589698546467da2d9f63 38224 
quilt_0.46-4.1.debian.tar.gz
Files: 
 4508546d1ed0257ef7c128b6121b7208 403984 quilt_0.46.orig.tar.gz
 713ef9174ad7269af4b88f143f193a9d 38224 quilt_0.46-4.1.debian.tar.gz


You probably check for the presence of a .diff.gz file. This check should be 
restricted
to the 1.0 format.

With newer source package format, you get "3.0 (native)" for a native package
and "3.0 (quilt)" can never be "native". You can check for the presence of the
..debian.tar.* file though.

I'm not sure how you should handle 3.x (git) and 3.x (bzr). I'd tend to handle 
them
as native packages but some people are interested to use them even for 
packaging of
third-party software (which is a bad idea IMO).

Cheers,

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils2.18.1~cvs20080103-6 The GNU assembler, linker and bina
ii  diffstat1.45-2   produces graph of changes introduc
ii  dpkg-dev1.14.20  package building tools for Debian
ii  file4.24-2   Determines file type using "magic"
ii  gettext 0.17-2   GNU Internationalization utilities
ii  intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf
ii  libparse-debianchan 1.1.1-2  parse Debian changelogs and output
ii  liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin
ii  man-db  2.5.2-1  on-line manual pager
ii  perl [libdigest-sha 5.10.0-10Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information



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

Automatická odpověď v nepřítomno sti: [6]: ???????? ??? ? ? ???????? ????!

[Cígler Martin]

Do 3. června 2008 jsem služebně mimo kancelář s omezeným přístupem k emailu. V 
naléhavých případech prosím kontaktujte Ivanu Gregovou na adrese [EMAIL 
PROTECTED] nebo telefonem +420 549 522 571.

I am currently out of the office until June 3rd (business trip), with limited 
access to email. In case of urgency please contact my assistant Ivana Gregova 
on [EMAIL PROTECTED] or +420 549 522 571.

S přáním hezkého dne/Best Regards,

Martin Cígler.


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

MESSAGE NOT DELIVERED: Re: Is that your document?

[incoming]

Your message could not be delivered. The User is out of space. Please try to 
send your message again at a later time.


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

Re: Extended Mail System

[Confirmation from gwyneth hannagan]

The message that you sent to me (gwyneth hannagan) has not yet been delivered:

 From: [EMAIL PROTECTED]
 Subject: Re: Extended Mail System
 Date: Wed, 28 May 2008 11:06:42 +

I am now using Vanquish to avoid spam.  This automated message
is an optional feature of that service, which I have enabled.

Please accept this one-time request to confirm that the above
message actually came from you.  Your confirmation will release
the message and allow all future messages from your address.

Click here to confirm:
http://confirm.vanquish.com/?U=sDMrN1ZNHc4HWW6Pd3dKgg

Vanquish respects my privacy and yours.  Your confirmation
gets your mail delivered to me now and in the future.  It
does not serve any marketing purpose.  Learn how privacy is
assured: www.vanquish.com/privacy

Undeliverable mail.

[Altezza Message Transfer Agent]

Hi there!

Your email address to [EMAIL PROTECTED] is being returned
because I could not find a mailbox! (#5.1.1)
If you feel this is an error please let [EMAIL PROTECTED] know.

Altezza Mail Transfer Agent 3.1.0001 (Built August 19, 2003)


begin 666 Original.eml
M>"US96YD97(Z(&QI;G1I86XM;6%I;G1 9&5B:6%N+F]R9PT*>"UR96-E:79E
M<[EMAIL PROTECTED]>4!H;W1E;'1R86EN:6YG+F]R9PT*4F5C96EV960Z(&9R;VT@
M,C(Q+C(R,"XQ.3 N,30T("A;,C(Q+C(R,"XQ.3 N,[EMAIL PROTECTED]@;F5W;6%I
M;"YS=6-C97-S9G5L+F-A('=I=&@@36EC'-E/@T*1G)O;3H@(FQI;G5S(&YA;F-Y(B \;&EN=&EA;BUM86EN=$!D
M96)I86XN;W)G/@T*5&\Z(#QF86-U;'1Y0&AO=&5L=')A:6YI;F2 R,# X(#$Q
M.C V.C(S("LP,# P#0I-24U%+59E7!E
M.B!M=6QT:7!A'1087)T7S P,%\P,# W7S Q0SA#,$,Q+C S.#=#.35#(@T*6"U03H@,PT*6"U-4TUA:6PM4')I;W)I='DZ($YO2 R,# X(#$S.C4X.C(Q
M+C [EMAIL PROTECTED]@1DE,151)344]6T4S-D0P030P.C Q0SA#,$-!70T*#0I4
M:&ES(&ES(&$@;75L=&DM<&%R="!M97-S86=E(&EN($U)[EMAIL PROTECTED];[EMAIL PROTECTED]
M#0HM+2TM+2T]7TYE>'1087)T7S P,%\P,# W7S Q0SA#,$,Q+C S.#=#.35#
M#0I#;VYT96YT+51Y<&4Z('1E>'0O<&QA:6X[#0H)8VAA6QI'0O:'1M;#L@/0T*8VAA6QE/3-$(F9O;G0M9F%M:6QY.FEM<&%C
[EMAIL PROTECTED]"US:7IE.C,R<'@[("(^/$$@/0T*:')E9CTS1")H='1P.B\O=W=W
M+F)BF4Z,S9P>[EMAIL PROTECTED]"UF86UI
M;'DZ26UP86-T.R ]#0IC;VQO6QE/3-$(F)A8VMG

Re: Hermes

[feedback]

You have sent email to a mailbox that is not accessible within the 
nextgenmg.com domain. Please check the destination address. 

Due to recent spam attacks we have temporarily shut down [EMAIL PROTECTED] We 
have left the old URL(s)  on the website to deflect those mail sources with 
invalid source address. So they will never see this message ;->. 

If you have read this far, you are probably interested in us. Please contact us 
at: [EMAIL PROTECTED]


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

Bug#471263: Generated changes and patch systems

[Neil Williams]

Oops, sent to the wrong bug report.

On Wed, 2008-05-28 at 11:45 +0100, Neil Williams wrote:
> On Tue, 2008-05-27 at 18:06 -0700, Russ Allbery wrote:
> > Neil Williams <[EMAIL PROTECTED]> writes:
> > > On Sun, 2008-05-25 at 08:40 -0700, Russ Allbery wrote:
> > 
> > >> Lots of other packages do this -- one of mine off the top of my head is
> > >> xml-security-c.
> > 
> > > Nope. No mention of aclocal.m4 in debian/rules for that package,
> > > just /usr/share/misc/config.guess and config.sub.
> > 
> > Uh, it's the same problem.  Surely the generalization is obvious?
> 
> It's not quite the same problem because aclocal.m4 is regenerated in the
> clean rule itself because changing it causes ./configure --recheck to
> recreate the (modified) file. So instead of copying it around, it has to
> be deleted - merely because a patch system is in use. Seems crazy to me.
> 
> > > I need to patch configure and configure.ac in this package, that means
> > > that aclocal.m4 is constantly being changed and reverted. It shouldn't
> > > matter - it really should not.
> > 
> > Right, so delete it in the clean rule.
> 
> OK. It's a bit like collateral damage - need a patch to configure,
> patching causes configure --recheck which modifies aclocal.m4 so delete
> aclocal.m4. Hmmm. I don't like it but I'll do it anyway.
> 
> > > I see no purpose in lintian (or dpkg come to that) testing for changes
> > > in aclocal.m4 - IMHO it should simply be exempt from this check.
> > 
> > Absolutely not -- you're introducing unexpected changes to the packaging
> > diff file, 
> 
> Well my point is that the change is entirely expected (because the
> patch modifies a file that is involved in generating the changes) - the
> changes are merely a consequence of the patch. It feels wrong to have to
> add a clean rule for aclocal.m4 as a direct result of patching
> configure.ac when aclocal.m4 was not a problem before the patch. 
> 
> Anyway, the "problem" of the tmpl/* files is far more resistant.
> 
> > >>> I really don't want to do all that for the tmpl/* files as well - I
> > >>> don't see the need, copying dozens of files into foo.safe or
> > >>> foo.upstream and then moving them back?
> > 
> > >> Just delete them then.
> > 
> > > ??? That simply does not work. The problem is that running gtk-doc not
> > > only requires tmpl/*.sgml files to exist but it *then modifies them*!
> > 
> > This is extremely unusual.  Are you *sure* that it does an inplace edit of
> > the files during the build process? 
> 
> $ ls libgpewidget-0.115.orig/doc/tmpl/ -1
> colordialog.sgml
> color-slider.sgml
> dirbrowser.sgml
> errorbox.sgml
> gpeclockface.sgml
> gpehelp.sgml
> gpeiconlistitem.sgml
> gpe-iconlist.sgml
> gpeiconlistview.sgml
> gpetimesel.sgml
> gpewindowlist.sgml
> gtkdatecombo.sgml
> gtksimplemenu.sgml
> infoprint.sgml
> init.sgml
> libgpewidget-unused.sgml
> picturebutton.sgml
> pixmaps.sgml
> popup_menu.sgml
> popup.sgml
> question.sgml
> smallbox.sgml
> spacing.sgml
> stylus.sgml
> translabel.sgml
> tray.sgml
> windows.sgml
> 
> From the build log:
>  gtkdoc-mkdb --module=libgpewidget --source-dir=.. --output-format=xml
> --sgml-mode --output-format=xml --tmpl-dir=tmpl
> 
> Now running lintian...
> W: libgpewidget source: patch-system-but-direct-changes-in-diff 
> doc/tmpl/color-slider.sgml
> W: libgpewidget source: patch-system-but-direct-changes-in-diff 
> doc/tmpl/colordialog.sgml
> W: libgpewidget source: patch-system-but-direct-changes-in-diff 
> doc/tmpl/colorrenderer.sgml
> W: libgpewidget source: patch-system-but-direct-changes-in-diff 
> doc/tmpl/gpeclockface.sgml
> W: libgpewidget source: patch-system-but-direct-changes-in-diff 
> doc/tmpl/gpedialog.sgml
> W: libgpewidget source: patch-system-but-direct-changes-in-diff 
> doc/tmpl/gpehelp.sgml
> W: libgpewidget source: patch-system-but-direct-changes-in-diff 
> doc/tmpl/gtkdatecombo.sgml
> W: libgpewidget source: patch-system-but-direct-changes-in-diff 
> doc/tmpl/gtksimplemenu.sgml
> W: libgpewidget source: patch-system-but-direct-changes-in-diff 
> doc/tmpl/libgpewidget-unused.sgml
> W: libgpewidget source: patch-system-but-direct-changes-in-diff 
> doc/tmpl/link-warning.sgml
> W: libgpewidget source: patch-system-but-direct-changes-in-diff 
> doc/tmpl/pixmaps.sgml
> W: libgpewidget source: patch-system-but-direct-changes-in-diff 
> doc/tmpl/smallbox.sgml
> W: libgpewidget source: patch-system-but-direct-changes-in-diff 
> doc/tmpl/spacing.sgml
> Finished running lintian.
> 
> 13 out of 27 files modified by gtk-doc.
> 
> Copy those files back into doc/tmpl/ from the upstream source and they
> are still modified at the next build.
> 
> Add a rm -f doc/tmpl/*.sgml to clean:: and the build fails: No rule to
> make doc/tmp/*.sgml
> 
> So, yes, --enable-gtkdoc is modifying files included upstream and which
> are essential to the build process.
> 
> If I drop --enable-gtkdoc I get different contents in the
> libgpewidget-doc package.
> 
> >  This is almost never what build
> > systems do; ins