[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#621006: lintian: Variable substitution in "Maintainer" field in causes warnings and "no-maintainer-field" error



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

severity 621006  wishlist
affects 621006 615132
thanks

On 2011-04-05 20:52, Dmitry Katsubo wrote:
> Package: lintian
> Version: 2.4.3
> 
> When debian/control file reads:
> 
> === cut ===
> Maintainer: ${common:Maintainer}
> === cut ===
> 
> and in my debian/substvars I have:
> 
> === cut ===
> common:Maintainer=Dmitry Katsubo <dma_k@mail.ru>
> === cut ===
> 

Hi

I have the feeling you have not read #615132, which is basically asking
for a check against this particular usage of substvars.


> the lintian produces the following warnings for "osra source" package
> and "no-maintainer-field" error (but reports nothing for other "real"
> packages):
> 
>> Now running lintian...
>> Use of uninitialized value $maintainer in substitution (s///) at /usr/share/lintian/checks/nmu line 139.
>> Use of uninitialized value $maintainer in string ne at /usr/share/lintian/checks/nmu line 97.
>> Use of uninitialized value $maintainer in pattern match (m//) at /usr/share/lintian/checks/nmu line 109.

These are real issues and should have been fixed in a recent commit;
thanks for mentioning those.

>> E: osra source: no-maintainer-field

This most likely happens because dpkg command (exact name eludes me at
the moment, possibly dpkg-source or dpkg-genchanges) building the dsc
does not include the Maintainer field.
  I assume it does this if the Maintainer field is empty, which is very
likely as the debian/substvars file is usually removed by the clean
target (e.g. by dh_clean) and is therefore not present when the source
package is created.
  Note we also have a tag for keeping the debian/substvars file in the
source package because doing so may lead to complications/weird results.

> 
> Expected: the maintainer field is analysed with respect to variable
> substitution.
> 
> 

Obviously we cannot satisfy this and #615132 at the same time.
Personally I am more inclined to satisfy #615132, since these
substitutions can be rather non-trivial and (as you experienced) lead to
some "interesting" issues when done in source fields.

~Niels

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNnevaAAoJEAVLu599gGRC/Q8QAJU4NgDMOJovFoWiyNnWLmVc
tqc2nfPib88763OPjSeyVDmMfNY0bGQH+mpx+jum3liwIjdyI5mON/NGPRrpk5kj
PhbGc6AFu07v7ueqbh5+vAez6G2VOz2Pyma2uFER80JNweNDIXjPSTcoCCKmD5GK
8bjc/9nZR0d2wMEmPPSXF+cYUPARrZ8K49Ho4yzeJj3MXjAYxGXgHPE0fcpbVg0V
uMDh3i45CbYFuieVJX+8dl8Ta9mnS3rApiX2xDtSS1zM2HnrWW09jRc+9xnVz0L6
Xv9hj3lqZDCyUe0NX9JbwKtXmNa/YU4g390CXITkk152jcpcXBV02Sw4wXBdEy5V
p+6zL65tRpjYDyECpcxajmZHCk24pbU1Vrmikiy2Qdv5x3R3lNHBb71COgXJe40j
5K8wyIFlV2AkaglZu0cjnFMeSsMiAIrnibaXjD34vqreQ8E6Syh8p4QUJxE7m0au
RsPfRS+GZ2VzrZsrP6cFDaSmx1yHtxQ9kSOSCNOWtzgfrFGGgCOI15+IE7n3TnUa
sZLlUwnMSsPo97pXOwOQs3fnFz/cLbGykNUavt2SwgVe9agI1HmBpyK7ks1ziz4L
bIAeJXpxAkY/SNPAA7mfbo0y75s9bagxsVHTEOX9GRQX94IxkYJIR0+vnrgB/i2U
JC3ovN7Bsrmtg7NEZNzy
=Deck
-----END PGP SIGNATURE-----



Reply to: