Bug#999497: [Pkg-javascript-devel] Bug#999497: lintian: complain about packages with parts of npm2deb FIX_ME or templates still present
Quoting Paul Wise (2021-11-12 02:08:26) > PS: I wonder if there should be a standard prefix for all template > strings that all packaging tools could use in their templates or > template strings and then lintian could just check for that prefix. I fully agree. I propose to use "FIXME" (i.e. no underscore). I find that to be the more common hint (e.g. is implemented in several tools already (except for Rust crates where "FIX_ME" seems more common - perhaps that site searches for "FIX" and "ME" as separate words?). * https://metacpan.org/search?size=500=FIXME - 169 hits * https://metacpan.org/search?size=500=FIX_ME - 0 hits * https://www.npmjs.com/search?q=FIXME - 79 hits * https://www.npmjs.com/search?q=FIX_ME - 0 hits * https://crates.io/search?q=FIXME - 27 hits * https://crates.io/search?q=FIX_ME - 2533 hits On a related note, I find it troublesome that some tools hide the FIXMEs placed by other tools - e.g. cme stripping licensecheck FIXMEs :-( - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#954331: lintian: coercion for "original_severity" failed: Unknown tag severity minor
Package: lintian
Version: 2.58.0
Severity: grave
Justification: renders package unusable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Upgrading to version 2.58.0 of lintian renders it totally unusable:
$ lintian *_amd64.changes --no-tag-display-limit
coercion for "original_severity" failed: Unknown tag severity minor
Lintian::Tag::Info::__ANON__("minor") called at (eval 123) line 28
eval {...} called at (eval 123) line 27
Lintian::Tag::Info::original_severity(Lintian::Tag::Info=HASH(0x565295307a18),
"minor") called at /usr/share/perl5/Lintian/Tag/Info.pm line 182
Lintian::Tag::Info::load(Lintian::Tag::Info=HASH(0x565295307a18),
"/usr/share/lintian/tags/pkg-perl/nonteam-testsuite-header.desc") called at
/usr/share/perl5/Lintian/Profile.pm line 224
Lintian::Profile::load(Lintian::Profile=HASH(0x565294d47398), undef,
ARRAY(0x5652925edde0), HASH(0x565292972ec0)) called at /usr/bin/lintian line 217
dplint::load_profile(undef) called at
/usr/share/lintian/commands/lintian.pm line 712
eval {...} called at /usr/share/lintian/commands/lintian.pm line 712
main::main() called at /usr/bin/lintian line 46
eval {...} called at /usr/bin/lintian line 46
main::__ANON__("/usr/share/lintian/commands/lintian.pm") called at
/usr/bin/lintian line 115
dplint::run_tool("/usr/bin/lintian", "lintian") called at /usr/bin/lintian
line 294
dplint::main() called at /usr/bin/lintian line 378
jonas@auryn:~/public_debian/pool-sid/OFFICIAL/monero$ lintian *_amd64.changes
--no-tag-display-limit
coercion for "original_severity" failed: Unknown tag severity minor
Lintian::Tag::Info::__ANON__("minor") called at (eval 123) line 28
eval {...} called at (eval 123) line 27
Lintian::Tag::Info::original_severity(Lintian::Tag::Info=HASH(0x55627b1c2e28),
"minor") called at /usr/share/perl5/Lintian/Tag/Info.pm line 182
Lintian::Tag::Info::load(Lintian::Tag::Info=HASH(0x55627b1c2e28),
"/usr/share/lintian/tags/pkg-perl/nonteam-testsuite-header.desc") called at
/usr/share/perl5/Lintian/Profile.pm line 224
Lintian::Profile::load(Lintian::Profile=HASH(0x55627ad428b8), undef,
ARRAY(0x5562785e8de0), HASH(0x55627896e290)) called at /usr/bin/lintian line 217
dplint::load_profile(undef) called at
/usr/share/lintian/commands/lintian.pm line 712
eval {...} called at /usr/share/lintian/commands/lintian.pm line 712
main::main() called at /usr/bin/lintian line 46
eval {...} called at /usr/bin/lintian line 46
main::__ANON__("/usr/share/lintian/commands/lintian.pm") called at
/usr/bin/lintian line 115
dplint::run_tool("/usr/bin/lintian", "lintian") called at /usr/bin/lintian
line 294
dplint::main() called at /usr/bin/lintian line 378
NB! Below was computed after I downgraded to 2.57.0.
- Jonas
- -- System Information:
Debian Release: bullseye/sid
APT prefers buildd-unstable
APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1,
'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.5.0-rc5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_DIE, TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8),
LANGUAGE=da_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lintian depends on:
ii binutils 2.34-5
ii bzip21.0.8-2
ii diffstat 1.63-1
ii dpkg 1.19.7
ii dpkg-dev 1.19.7
ii file 1:5.38-4
ii gettext 0.19.8.1-10
ii gpg 2.2.19-3
ii intltool-debian 0.35.0+20060710.5
ii libapt-pkg-perl 0.1.36+b3
ii libarchive-zip-perl 1.68-1
ii libcapture-tiny-perl 0.48-1
ii libcgi-pm-perl 4.46-1
ii libclass-xsaccessor-perl 1.19-3+b3
ii libclone-perl0.43-2
ii libdevel-size-perl 0.83-1+b1
ii libdpkg-perl 1.19.7
ii libemail-valid-perl 1.202-1
ii libfile-basedir-perl 0.08-1
ii libfile-find-rule-perl 0.34-1
ii libfont-ttf-perl 1.06-1
ii libio-async-loop-epoll-perl 0.20-1
ii libio-async-perl 0.75-1
ii libipc-run-perl 20180523.0-2
ii libjson-maybexs-perl 1.004000-1
ii liblist-compare-perl 0.53-1
ii liblist-moreutils-perl 0.416-1+b5
ii libmoo-perl 2.003006-1
ii libmoox-aliases-perl 0.001006-1
ii libnamespace-clean-perl 0.27-1
ii libpath-tiny-perl0.108-1
ii libsereal-decoder-perl 4.011+ds-1
ii libsereal-encoder-perl 4.011+ds-1
ii libtext-levenshtein-perl 0.13-1
ii libtimedate-perl 2.3200-1
ii libtry-tiny-perl 0.30-1
ii libtype-tiny-perl1.008001-2
ii liburi-perl 1.76-2
ii libxml-libxml-perl
Bug#943525: Namespaces for Lintian Tags
Quoting Felix Lechner (2019-11-20 18:55:04) > I am about to introduce private namespaces for tags. Many tags already > point to the check that issued them. (For those who don't know, a > 'check' in Lintian is a module that issues a tag.) Namespaces would > formalize the relationship. > > For example, the tag > 'debian-copyright-file-uses-obsolete-national-encoding' might become > 'national-encoding@debian/copyright'. [...] > Please provide your thoughts, perspectives and suggestions by amending > the bug report at #943525. Thank you! Great! I very much welcome that change! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#942632: lintian: false positive: package-needs-versioned-debhelper-build-depends 10 but satisfied even in oldstable
Package: lintian Version: 2.28.0 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 When using debhelper compatibility level 10, declaring an unversioned build-dependency on debhelper is enough, because that release is available even in oldstable. Please stop treating that as a lintian error/warning. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl2qyp0ACgkQLHwxRsGg ASEVnBAArRX1k4TrZ3D2HFrphLW1piLSQb4NXoqRO3iMM2TjVXhjxJ4iioUljE8W f4YsWadQ+zI+75+Px93jAo5j9Y7JkTWBPrLpIdTxoVvQO4nDdw2jGdSt4cOOXMyM WyUzW7g+Jf2Gm8mvE5akh4CMwCgVvTdSctyPTlHqri4pTklTfr6ybaQfAkfirGK4 5taXNH642/DmaPnC3/zHOdzBCMijxrcoIIrliOKSF/bDbSUsImE6BPJ0dub65dIn KoIQN1fYkKhV27ZfMqUJlmbeYVXCbLWoXm8SSL/6r8ZNO7ApUPCMJtJ7mNwFVaIj 4MIAnmGQdNvQ3yLsJVhkderOR3OiuKO30pUsDIKRqvfKrv8bOJ1p4+CX3lsc8OFl WIdXTtaFfUWKt0XCKf/71zBEa/6EIVuSniVD9Yrc95B3ZRcE4b0IOxh+nvsEyn29 7xl6+6MG4LX5uoNe+MgQT/otGY+Wn2BxCY9+btmbjHZ900kNoZfrdEbpzsg73UPb WtL4z7IyBHO4w6gXKOR7mnJu3F2uCtUIWauREFl0sHTNK6ZLGEoZNON1hmK6y1IC xtgP+ezz7lSwik1QlLUL3tbOGxqHZC4aX6iwLc9LA2iP9C8PkZM+5gxqx40tts2k WUGrgbcqt73z0MSH3/v+GI4i7lFPXMnuhAlimj7jqziTF3TthpE= =93g9 -END PGP SIGNATURE-
Bug#913723: please confirm that dictionaries should move to section localization
Hi Guillem, Quoting Guillem Jover (2018-12-22 18:58:04) > On Sun, 2018-12-02 at 15:48:53 +0100, Jonas Smedegaard wrote: > > Quoting Guillem Jover (2018-12-02 15:17:02) > > > On Sun, 2018-11-18 at 05:44:42 -0500, Chris Lamb wrote: > > > > Could you propose a patch that would fix this to your > > > > satisfaction? > > > > I'm having a little difficulty sorting this out in my head now > > > > after applying, reverting, etc. etc. :) > > > > > > If you ask me personally, I think lintian is fine as it is! I'd > > > probably just update the section descriptions to clarify this, and > > > prepare a mass override request for ftp-masters. But I'd like to > > > hear from the reporters and others who complained about the secion > > > change to know whether they have been convinced by the arguments? > > > :) > > > > Since you ask: No, I am not convinced by your arguments. > > Ok, I'm still curious about why? :) It seems your argument is essentially that a dictionary locale-specific. I firmly believe that the current use of package section "locale" is for "Localization support for big software packages" (as argued earlier) - i.e. the specific use of the word "locale" related tied to "internationalization and localization". I am not convinced that Debian should change to instead have that package section cover a different more loose definition of "locale". Geographical maps and accounting ledger systems and text editors (those optimized not for computer code but for human prose) are all locale-specific, but not specific to the process of localization. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#913723: please confirm that dictionaries should move to section localization
Quoting Guillem Jover (2018-12-02 15:17:02) > On Sun, 2018-11-18 at 05:44:42 -0500, Chris Lamb wrote: > > Could you propose a patch that would fix this to your satisfaction? > > I'm having a little difficulty sorting this out in my head now > > after applying, reverting, etc. etc. :) > > If you ask me personally, I think lintian is fine as it is! I'd > probably just update the section descriptions to clarify this, and > prepare a mass override request for ftp-masters. But I'd like to hear > from the reporters and others who complained about the secion change > to know whether they have been convinced by the arguments? :) Since you ask: No, I am not convinced by your arguments. But your notion (in an earlier post) that this is not for mere mortals but (yet another) ftpmaster matter, defused my enthusiasm completely. :-( - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#904728: lintian: detect dh-make-perl long description: "This description was automagically extracted from the module by dh-make-perl."
Package: lintian Version: 2.5.94 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Apparently dh-make-perl auto-generates a debian/control file containing the following: This description was automagically extracted from the module by dh-make-perl. Seems to me that should be easily detectable y lintian, and that it should trigger some kind of warning that the long description contains boilerplate. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlta3rwACgkQLHwxRsGg ASFCZRAAqoRBtAecHQwLsMxGyWbnWWDwTl/hh9mSo5IxDtVo4MN+i8k2Nv+6tWJX UAAmmmuV5CRbOLVU3d+R/iU3oWuoXOpVLzbHkxpugT4zkW2FWxE6LnBkcS71Zcsy vm2P9/iOzGKAfXMMJR6VDAWS4gNT6qddOigjB2aTkg1lr2i9ARjZs6F6XNhEx6Ms MlffE8EBBxj1wXITvXEw4o0n1SY6EeSnfJ45lUHXq8O6bRfiGFDZD1DMDF+W3CqG +Pb7q8+D1rB+TJ25rDTW26yXqb3BSogp7WkGVvxWIZRsH9xK1xBhJ8l1eIwm+PO6 eepn2Z2CenTZVl5NNNlus1ku81Cd0TlFSebR/xYFCpSf+bxuWW3LH4qU3DTfisP+ LHW+5P7j79Q/+XqyRPUzHfEqq4PGZ9NglNBBmZFSXBtMxmaNWmyFI92+Clt7Q9yX HNIKNquH9DFCSjEcvWssoQyaTOUAxK7hz4btw5KEkOqfW4wLDv0TJp4tlViiQ5lM YrIVuekEbE58MX2+jkBetbjF4jRbLTHiiwdod3KvibdQIlnWX+NoSc9/EzgGv8W/ uZdgJXKnNRP6K4FySqQVCfYbvPwPLXDYKcK1Ht2c5fg+6+WgeGnoyR4xlq2LXhmU DoRqyka4gV7fqaFlEDfD3kUra/T6miyZFvKqN+b0TNZ+dOXT1w0= =rq1O -END PGP SIGNATURE-
Bug#902797: lintian: check latest changelog entry for duplicate contributor information
Quoting Florian Schlichting (2018-07-01 17:23:04) > Hi, > > On Sun, Jul 01, 2018 at 11:37:21AM +0200, Mattia Rizzolo wrote: > > On Sun, Jul 01, 2018 at 12:39:47PM +0800, Paul Wise wrote: > > > I recently saw a changelog entry (quoted below) for a Perl team > > > package where several contributors to that version had their names > > > mentioned multiple times with one or more changes below each > > > instance of their name. This made the changelog harder to read. I > > > think it would be useful for lintian to emit a pedantic or > > > info-level warning for duplicate contributor information in the > > > latest changelog entry. > > > > I personally agree with you here, but apparently not everybody does. > > ISTR to remember in the past suggesting to change the default of dch > > --multimaint-merge but somebody complained that that way it would > > lose the chronological order of the changes or something like that > > (I don't really buy it). > > I'm probably guilty of uploading a fair number of packages with such > changelogs over the last few days, as I'm working through a list of > perl team packages that haven't had an upload in over six years and > thus still point to SVN with their version in the archive. > > Most of those changelog entries stem from (semi-)automatic mass > commits made over the years to our several thousand packages; and some > of them change the very same thing a previous entry modified. In the > example that Paul cited, Ansgar first changed the Vcs-* lines from > svn.d.o to git.d.o in 2011, then Salvatore changed git.d.o to > anonscm.d.o in 2013, git:// to https:// in 2016, and anonscm.d.o to > salsa.d.o in 2018, each time adding a commit with the change and one > that modified d/changelog using dch. If that last commit was made by > Ansgar again, wouldn't --multimaint-merge result in a confusing > changelog that lists final modifications before intermediate ones? > > Having said that, I don't have a strong feeling about how changelogs > should look like, other than that the default behaviour of our tools > should agree with what lintian wants to see. In my use of d/changelog, > both as a packager and occasionally as a user looking at an installed > package, it's a mirror of the packaging repository's git history, very > likely auto-generated, and a bit redundant as a source of > information... Lintian not complaining is not the same as lintian wanting us to tune tools for (in our opinion) improved readability. I find it more readable to list each contributor only once. Also (not exactly same but strongly related): I find it irrelevant¹ to list changes reverted or shadowed later within same release: Please cleanup auto-generated changelog, stripping parts not ending in the final package release. - Jonas ¹ I thought Debian Policy had a passage that changelog should cover user-facing changes, but cannot find it now so maybe I imagined that. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#835517: lintian: please detect javascript files (not symlinks) shipped in /vendor/ dir
Quoting Jonas Smedegaard (2016-08-26 15:01:06) > Apparently it is a trend for Ruby Gems to stuff convenience code > copies of javascript code into /vendor/ dirs. Those should, according > to Policy § 3.14, instead be packaged separately as a libjs-* package > (see bug#798983). Problem is bigger: Rather than /vendor/, a better path identifier is probably /assets/ - see e.g. bug#835519. Perhaps (at lower severity?) check any path but below "/usr/share/javascript"? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#835517: lintian: please detect javascript files (not symlinks) shipped in /vendor/ dir
Package: lintian Version: 2.5.46 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Apparently it is a trend for Ruby Gems to stuff convenience code copies of javascript code into /vendor/ dirs. Those should, according to Policy § 3.14, instead be packaged separately as a libjs-* package (see bug#798983). The detection involves multiple parts: a) Package name is not "libjs-*" b) Path contains "/vendor/" c) File contains ".js" d) File is truly a file (not a symlink) Beware that file may not _end_ in ".js": Some Ruby packages add an ".erb" suffix (see e.g. ruby-leaflet-rails 0.7.7-1). Related detections: ... d) File is a symlink not pointing below /usr/share/javascript ... d) File is a symlink pointing below /usr/share/javascript e) Package does not depend on package providing symlink For some concrete examples of the kind of bugs this would catch, see bug#835508, #835509, #835512 The lintian message should probably mention the file specifically: Bug#835512 is an example where one of two files needs fixing but the other would trigger a false positive sensible to suppress: The former Javascript library has separate upstream whereas the latter does not. - Jonas -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJXwD2PAAoJECx8MUbBoAEhxu0P/3H2L8ThgsitolyzppFvwr2S 47ujDaRarBSJlMDxHmWMYidLRPVgvxkyFrgKnLeibJWN55U6E+7iOIOWwZvo2LKf 9plkIgqH23glnRSaOveoUPY31pCx+6bqbvsTf/IlQE3ASExtmukYUkY9JS00F8ax QBxNLhDKWklHucyb/9C/mLeFovJkYWXpRJFOhfUI0no2iIiAqXLrIKLJRtVNVSZv 0aMDgLbDUFmllDqZuPYzY/R3MhomLNkODyRf8UdP1ekVMg9oHOrVSYeZwSzKOQbX QNo8QR52KH8TwByPdsvvv6clH7NziPDBWEZSBHBGHGQ3VaWpDn1uXF2rExJP+CcU nAxJqP38XWTSqxnp6K/NBjkyB4ajKzQYpX9+T6aYJCQaO8M1n2bfpAOhmXShpVt6 lL7lsGOqTFdPk+GcuvPKlc3LurEzoHDdtTZURivKRD0DjctZp8ncjRN7d4YtXnJG n+1ehLT5quv0pD2uLlW/0SdCkhKH8VXGqOunmElqke+3rPI63v4fHQefclKIN2fG 4aHnSy0EiavxxWQOUjbOKJUWTSbIVqKJnwJ5AInVT72W33P/NvpteO7nNSXCdM/W iHX6JTw0OJCGeB8Tib8UhR8y0IdDQAs6mcl3J4gjQ3xFU/UR2/QuYU6wDHNEpEtQ JXnZ3OwqLWLwqB9y9Z4A =44pr -END PGP SIGNATURE-
Bug#798983: lintian: please check for libjs-* binary package name outside of web section
Package: lintian Version: 2.5.37 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please have lintian check for libjs-* binary package name outside of web section. I am getting tired of filing bugreports against esp. Ruby packagers properly separating javascript into reusable packages but forgetting to change section for that binary package. Obviously similar applies for other patterns, like these: *-doc *-example *-examples outside of doc section fonts-* outside of fonts section !py-* in python section - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJV9wUCAAoJECx8MUbBoAEhU4wP/jZK8t9doJ1T5ep3TCtCpmHr +xyon6TjLuOcs/q6k3lKe8fFfm0X/QC40kfvrL/dh2zB3TLuQtlB+6AhQVMiNTHC lMPW5LZKFyu8slJz9D8jjXomJwywefixrR5AZUufAeJ6+mUke+Ob/6xN2t8ZP5y3 vmK5cnyRNUit3RmJe1Z7PzLUm4kPsFc7xOS6ZkQKHgG6Ty/xxJxPNZD5fTOgqo3u yJieKtOpCtGm8xuAcCS5UonnTpAQ7pSX3X4wxij1mb/A2oEXuDOCip62bFiovCeX EQ5dm8UCkmlPF570SdHMFukeFj7cvUjeHz5qHbBKgHQIqxUIOk8u/4ezccRnOkGI ED7R9p7Y75vGyn34tM4pOQoXMN8H4Q2p7DIiGydTP7+DsqggOibI2+L9SQGFxKFk 9VXNpaaXpEwZHmdIpBf+84OlbYPcAws3YZ07fz0t2hX63aEj1M5c2JzoZ/PMVlv1 7hXvEtAcx3cwmsv14dqpkXGnuKexZ0GWyavqCR0ycGi/dsCDz8dKRLOJ/0HIXsb6 F383OLseab8QuC0G4iKscE3QQF/Rgo9Y8PPkSFzeKYrSslmKpZhYolEBsy67a1TZ mTERBKLqzGlL0LfJ6feojnVPe+MSHGmBhgyYb58fsj8Mpxu1tKdtTMSYQd5uOn// 7uxKp5Hf324H1gFfyDcm =spzN -END PGP SIGNATURE-
Bug#790693: lintian: Aymara language code is ayc (not ay - not yet, at least...)
Hi Jakub, Quoting Jakub Wilk (2015-06-30 17:16:26) * Jonas Smedegaard d...@jones.dk, 2015-06-30, 16:44: Some of th sugar-*-activity packages trigger lintian warnings like this: W: sugar-read-activity: incorrect-locale-code aym - ay Long description of the lintian warning mentions that language codes are those is ISO 639-1 and ISO 639-2, but does not say which wins if listed in both but by different name. The two-letter code wins. We should update the tag description to make it clear. Wikipedia article on Amayran references the individual languages as Southern Aymara with code ayc and Central Aymara with code ayr. Only Amaya-related locale listed in /usr/share/i18n/SUPPORTED is ayc_PE - i.e. Southern Aymara in Peru. As I understand it, renaming locale files to ay renders them unusable on a standard Debian system (needing /usr/local/share/i18n/SUPPORTED hack). Only Amayan language code usable in standard Debian currently is ayc. Not quite. You can set the LANGUAGE variable[0] to ay (or ayc:ay or similar), and the translations will work, even though the locale is not supported. [0] https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html Thanks a lot for the clarification (the difference between LANG and LANGUAGE has puzzled me for long) :-) I am leaving this bug open for that minor issue of improving wording, but consider the main issue solved. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#790693: lintian: Aymara language code is ayc (not ay - not yet, at least...)
Package: lintian Version: 2.5.32 Severity: normal Tags: l10n -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seems to me that language code aym should not be corrected to ay but instead (for the time being to ayc. Here's my reasoning: Some of th sugar-*-activity packages trigger lintian warnings like this: W: sugar-read-activity: incorrect-locale-code aym - ay Long description of the lintian warning mentions that language codes are those is ISO 639-1 and ISO 639-2, but does not say which wins if listed in both but by different name. Aymara is listed in ISO 639-1 as ay but in ISO 639-2 as aym, but are are both listed as scope Macrolanguage - i.e. what some refer to as Aymaran, the _family_ of Aymara languages. Wikipedia article on Amayran references the individual languages as Southern Aymara with code ayc and Central Aymara with code ayr. Only Amaya-related locale listed in /usr/share/i18n/SUPPORTED is ayc_PE - - i.e. Southern Aymara in Peru. As I understand it, renaming locale files to ay renders them unusable on a standard Debian system (needing /usr/local/share/i18n/SUPPORTED hack). Only Amayan language code usable in standard Debian currently is ayc. I am right now in Peru, discussing this issue with Sebastian Silva - a local activist involved in deploying Sugar there. As I (vaguely) understand it, the ayc_PE slot was created few years ago to cover one of the two Aymara dialects, whereas current translation efforts (involving Sugarlabs, Peruvian ministry and OLPC) intends to cover both dialects as a single language. In the short term the only option I see is to abuse the ayc slot for ay/aym. Sebastian will try get confirmed if above is correctly understood, and if so we should probably have the slot ay (or aym - depending on which ISO standard has priority) added and move dual-dialect localizations to that. ...Or instead have slot ayr created, if in fact current translation covers only one of the dialects _and_ there is interest in localizations also for the other. Phew. Hope that all made some sense... - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVkw3HAAoJECx8MUbBoAEhyXAP/1SZD5kjNnUjKSPGefLp1JfM LeSOM44g2/mKDkZYZcN/xE3AcSkAU0rtz0JLdS6fUMM07xVeIoE0MMp4K3IvZMX5 /pErsiXF3Fqq8JZT5vWJub99qE/9w3E6MNpYNQolbhZVTmuaEPQZyZOMXGfsuxOC HDNqlhjWOZSWEqWDLOs+ZTzTuwnHwuHretn+H8ny/qtHaDoeXKcRXakvngRoRUkA coTlOAVMwuSlzXjjbJo53p39bIICcdpCptPuSfn35XZUcGXVHEKZPgGVJb/DT0tP H6EF0sObKvT+xpY8Eecntj0TilrZruH645+Id2MhLtMuaER0JBORHPtgDzJZDAmM xXlRQWH40hWiSWt7qcRwmDqkQ2o7hMUCIjmtJ8SfJjA/JU99WWGtbDJGa7e1eCrg UaBFzbJQuyspQOcVVrT9uSnnzwzbxDbY9CsvrrSI1gNhT8YBM7FRrdZybsCiRt04 aTa+UVSxey1bmAVpDVkjqyneMMfmgsk+o9a48RIu4sfGVo5J0IbtgTaIFQrljYEA xqNMucPZFuDevMKsfu5d7TPRBrISZ14phUc+pgurJNYMXdeDRh9OJs0wiZyvLV0D IcL+yZGU5U221fQ1b0ytzXhDwRAzOwN1BxZGtQItlirR/0X3allZ5gV2ziGZCBRF Ds1eNVXXx0x9I0bNoqaa =HxE6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150630214442.13887.48537.report...@auryn.jones.dk
Bug#786450: lintian: false positives for missing-license-text-in-dep5-copyright and missing-license-paragraph-in-dep5-copyright
Hi Jakub, Quoting Jakub Wilk (2015-05-21 22:32:23) * Jonas Smedegaard d...@jones.dk, 2015-05-21, 21:30: The following triggers missing-license-text-in-dep5-copyright and missing-license-paragraph-in-dep5-copyright: Files: debian/* Copyright: 2014, Jonas Smedegaard d...@jones.dk License: GPL-3+ License-Grant: This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. […] License: GPL-3+ License-Reference: /usr/share/common-licenses/GPL-3 I believe that to be a false positive: File format 1.0 requires a License paragraph to have a License field (which is always satisfied), but does not mandate said License field to be multi-line. The specification says: “If there are no remaining lines [in the License field], then all of the short names or short names followed by license exceptions making up the first line must be described in stand-alone License paragraphs.” I don't believe this requirement is satisfied in your copyright file. Specification (or at least the part you quote) does not mandate that description be contained within the License _field_ of the License paragraph. Or is your point that my License-Reference is not descriptive enough? Also, it says: “This field should include all text needed in order to fulfill both Debian Policy's requirement for including a copy of the software's distribution license (12.5)”, so I don't think you can move the relevant information to the License-Grant or License-Reference fields. I see two possible interpretations of above: a) It is implied to mean This field, when not a single line,[…] and therefore does not apply to my case. This interpretation makes sense to me both for what it dictates and its context in a paragraph generally covering that flavor of the field. b) The sentence applies both to multi-line and single-line license fields and therefore contradicts the paragraph above which permits single-line license field to reference a license paragraph instead of contain all needed info itself. Perhaps you consider a third option: c) It is implied to mean This field, when used in stand-alone License paragraph, […]. I can see how such interpretation might suite your view on my pattern being wrong, but I fail to see what indications in Policy itself points towards such interpretation. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#786450: lintian: false positives for missing-license-text-in-dep5-copyright and missing-license-paragraph-in-dep5-copyright
Package: lintian Version: 2.5.31 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following triggers missing-license-text-in-dep5-copyright and missing-license-paragraph-in-dep5-copyright: Files: debian/* Copyright: 2014, Jonas Smedegaard d...@jones.dk License: GPL-3+ License-Grant: This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. […] License: GPL-3+ License-Reference: /usr/share/common-licenses/GPL-3 I believe that to be a false positive: File format 1.0 requires a License paragraph to have a License field (which is always satisfied), but does not mandate said License field to be multi-line. Please do not trigger for License paragraphs with single-line License field but containing other fields as well. See https://lists.debian.org/debian-devel/2015/05/msg00473.html for related discussion on distinguishing between license and license-grant. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVXjJkAAoJECx8MUbBoAEhdMMP/A0ktvJrO5J8io97OHX/RS1J fB+yWD0qp5DJ5xWLFij5CQD+zAJyyUhH6ArtT2379Midb51wqFnKTRGdkXESQZWE kmw2c0UnhQxYOTgoGvZ6B01QqKGyWP187x9jlLzW3Dgo0jlIJKRFkGDUur8sw7Gl AUGXc/jM51cpXMONruSlH1d6ADu3LfQL8NTU8vJSTuFmQpmO+uQDELWcxWqlDTU/ fHmJmUcxs14xFp9pAW68g0FYD0vFhn02cMApGYshn4K9ESdRHV+ZaLNkwGFeT6z9 WiwcFNpQfVaUkDvNFcKxWEyQAtgm6MddiSR4+6JDoH/DkAk6HwcUcWWTqgvEUb4f o5hmHQWAci6x2T1nYcsxbm9U4RQZHwQCPg+HFebzHJQuJeQ1bJC8NkNDfU+kcHXo r/T82YnWzQcXMoqQ8Iyr966bPFMr7S5fIz8UFhOX7KME4YvinhQUmIr7ecS6JZZy kVrHC4r12lugeQBmPRCUL05G5jf1Bk2nRKy2u7v48bE8esoNt6J7VawL0THMjv3y 77AKbIUvH2lyeEbgMUb5Lg2p/qXpoRRlQmOf0rTsJDQMVNW3lr0e7+EC4OgnoKig meVX4HRuXRkUPp6VC8UWjXAshNctcwBU3eXKZFvu0YKhtBO+CXS/nRFSukWEkBde aSwlFtrSes9pPXsRjFkK =1Auq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150521193047.29496.63327.report...@bastian.jones.dk
Re: RfC: Moving not-pkg-perl-team-specific lintian tests from pkg-perl-tools to lintian proper
Quoting Axel Beckert (2015-05-16 19:30:40) gregor herrmann wrote: - the CDBS ones would probably benefit from a review by Jonas (I tried to pick the correct versions from cdbs' changelog but I might have been wrong somewhere) Ok, will either not included before Jonas reviewed it or mark it as experimental. To properly enable security hardening for Perl modules with CDBS, you will need cdbs 0.4.130 or newer. ...which means you should use Debian stable or newer. Period. I disagree that each package need versioned build-dependency: That brings no real benefit, only a) papers over broken build environments and b) makes it harder to backport packages. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#771191: Bug#771126: Bug#771191: Bug#771126: libav/tests/lena.pnm: also not mentioned in debian/copyright
Quoting Fabian Greffrath (2014-12-03 08:56:41) Am Dienstag, den 02.12.2014, 23:29 +0100 schrieb Bastien ROUCARIES: And offencive (sexist) for 50% of the population the women... Now it's getting really ridiculous. Gosh, it's a picture of a woman! I disagree with you. Honestly, when you mentioned you'd replaced with a photo of your own, I got very curious and checked if you'd made a self-portrait posing similarly - looking over your shoulder and into the camera with an invitation in the eyes. You chose food. Had you done that (in an honest attempt, inspired by but without making fun on the original), your comment now would have more meaning to me. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#771191: Bug#771126: Bug#771191: Bug#771126: libav/tests/lena.pnm: also not mentioned in debian/copyright
Quoting Jonas Smedegaard (2014-12-03 11:33:17) Quoting Fabian Greffrath (2014-12-03 08:56:41) Am Dienstag, den 02.12.2014, 23:29 +0100 schrieb Bastien ROUCARIES: And offencive (sexist) for 50% of the population the women... Now it's getting really ridiculous. Gosh, it's a picture of a woman! I disagree with you. Honestly, when you mentioned you'd replaced with a photo of your own, I got very curious and checked if you'd made a self-portrait posing similarly - looking over your shoulder and into the camera with an invitation in the eyes. You chose food. Had you done that (in an honest attempt, inspired by but without making fun on the original), your comment now would have more meaning to me. Whoops - sorry: I mixed up you and Reinhard. :-( - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#771191: Bug#771126: libav/tests/lena.pnm: also not mentioned in debian/copyright
Quoting Reinhard Tartler (2014-12-02 14:11:19) On 2014-11-27 23:23, Jonas Smedegaard wrote: In prior similar bugreport https://bugs.debian.org/760171#10 - referenced from https://bugs.debian.org/771191#10 - distribution is documented as permitted only for research and education which I interpret as unacceptable for Debian. FTR, this whole business feel incredibly silly. Welcome to the Real World: Some stuff is incredibly stupid, yet Real. lena.pnm has become the *de-facto* standard image for every CS student to do his graphics courses homework on, Proprietary operating systems, word processors and spreadsheet editors have become the *de-facto* standard e.g. for most public servants in the World. Incredibly silly as free (and technically superior) alternatives exist. But this bugreport is about DFSG... The copyright holder is going to have a very hard time enforcing his right if he wanted to prevent distribution of the image, DFSG is is about Debian respecting copyright and licensing (no matter if difficult for copyright holders to defend or enforce their rights). (perhaps you confuse copyright and licensing with trademarks or patents, in some cases considered irrelevant for Debian to care about) Jonas, would you mind taking over from here and upload https://libav.org/releases/libav-11.1.tar.xz to unstable? I don't mind doing the technical work of packaging, but prefer if someone else takes to dialogue with release team about freeze exception, as I don't have the stomach for that (no blame on the release team for that!). I also don't mind doing the additional technical work of cherry-picking only the fix for this bug and apply to 6:11-2 currently targeted Jessie. Which of those to do would probably need input from the person willing to do the negotiation with release team, however. So I await someone volunteering for that (and while waiting will prepare that new upstream release, and if noone have appeared before done release it targeted experimental). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#771191: lintian: test for inclusion of non-lossy lena/lenna image and flag as potentially non-DFSG
Package: lintian Version: 2.5.30+deb8u2 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 A graphics file popular to include e.g. in testsuites is a scanning from November 1972 issue of Playboy, which is not DFSG compliant: https://en.wikipedia.org/wiki/File:Lenna.png#Licensing. See bug#771126 for a concrete example. I have tried our codesearch to discover more, and have found some but failed to find a reliable search pattern using that interface. It is used for color calibration and therefore needed in non-lossy format but can vary in size and serialization, so simple md5 detection is inefficient, I suspect. Filename typically includes lena or lenna in its stem. A simple check could be scan for /\blenn?a\b/ in filename, and then check with file if content is a graphics file. More reliable check might involve serializing hits of above loose check in some deterministic manner, compute md5 from that, and compare against a blacklist. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJUdx/7XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWJckIALKrSGJjSRbt6VFcWP+hhUfa y0Hf3AOgLIeDi9K88FBLnloNzlQIEKA8mqvfyKfnJ9cahEVCbzXqMMtte1mMZiRc YZuvj93zeGTJne9BOZi21sIa+oDsz2DVSAhJ/sXTi+6JpmuuR6/eeKM8GuwEBeSZ LKQ1SUcTYOMdahejXAtM3/cU0hWed30cZR2oxGpYic/Faxp4irrpm+mFQZXDctgW 4Z4nVWLKK5egH23BGeqIBhHQfJ1YKUkLwihSc7vg+y9QyzYT0nxZQsEr1CwgVZcW z/2ufvacdBQEBBT9V2XaVxxhy4uchgABnHml48D4+OJkJNMwokMwM3o4T6IKoc0= =NOzw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141127125839.32080.5256.report...@bastian.jones.dk
Bug#771191: lintian: test for inclusion of non-lossy lena/lenna image and flag as potentially non-DFSG
Quoting Bastien ROUCARIES (2014-11-27 21:42:22) Le 27 nov. 2014 14:00, Jonas Smedegaard [1]d...@jones.dk a écrit : A graphics file popular to include e.g. in testsuites is a scanning from November 1972 issue of Playboy, which is not DFSG compliant: [2]https://en.wikipedia.org/wiki/File:Lenna.png#Licensing. I have opened #760171 also some time agi Ahh - I was wondering if others had looked at this already - then forgot to check. Thanks! See bug#771126 for a concrete example. I have tried our codesearch to discover more, and have found some but failed to find a reliable search pattern using that interface. It is used for color calibration and therefore needed in non-lossy format but can vary in size and serialization, so simple md5 detection is inefficient, I suspect. No md5 do not suffer from false postive so it is an autoreject. Could you send me a patch against data/cruft/non-distributable-files ? Less work for ftpmaster particularly whenbautomatocally done is faster package going to main. Good points. I'd be happy to contribute md5sums - but this is my first bugreport against lintian so I need a bit of hand holding, I guess: Is that path perhaps in some git, or how do I contribute? Filename typically includes lena or lenna in its stem. A simple check could be scan for /\blenn?a\b/ in filename, and then check with file if content is a graphics file. Yes will implement but it will be wild guess no autoreject. Right, I had no higher hopes than that (as you can see above I even outruled md5sums, didn't think both could be done in parallel) More reliable check might involve serializing hits of above loose check in some deterministic manner, compute md5 from that, and compare against a blacklist. No pull too many deps Ok. Wasn't sure if other checks alreadt did similar. Was just throwing ideas :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#723003: lintian: non-standard-apache2-module-package-name should ignore case
Package: lintian Version: 2.5.17 Severity: normal Binary package libapache2-mod-ruwsgi contains Apache2 module Ruwsgi. Seems to me that non-standard-apache2-module-package-name should compare only after lowercasing (and possibly that Apache Policy should be improved to reflect tnis, but arguably that's an implicit contraint, since it is talking about package names). - Jonas -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130915093732.27253.86202.report...@auryn.jones.dk
Bug#522613: lintian: false positive package-lacks-versioned-build-depends-on-debhelper 6 (5.0.44 is new enough)
Package: lintian Version: 2.2.9 Severity: normal Lintian reports problems with debhelper dependency when using 6 in compat and build-depending on debhelper version 5.0.44. Debhelper itself claims support for compat version 6 in its changelog entry for version 5.0.44, which is the reason this version was used in CDBS dependency resolving. Kind regards, - Jonas -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils 2.19.1-1 The GNU assembler, linker and bina ii diffstat 1.46-1produces graph of changes introduc ii dpkg-dev 1.14.25 Debian package development tools ii file 5.00-1Determines file type using magic ii gettext0.17-6GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libdigest-sha-perl 5.47-1Perl extension for SHA-1/224/256/3 ii libipc-run-perl0.82-1Perl module for running processes ii libparse-debianchangel 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl 1.1600-9 Time and date functions for Perl ii liburi-perl1.37+dfsg-1 Manipulates and accesses URI strin ii man-db 2.5.5-1 on-line manual pager ii perl [libdigest-sha-pe 5.10.0-19 Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarchnone (no description available) ii libtext-template-perl 1.45-1 Text::Template perl module ii man-db2.5.5-1on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522623: lintian: false positive incorrect-libdir-in-la-file when using python-central
Package: lintian Version: 2.2.9 Severity: important When using python-central to handle Python packages potentially targeted for multiple Python versions, library files are moved to a central location and replaced with symlinks at install time. Lintian complains with the following: E: python-sugar-toolkit-0.84: incorrect-libdir-in-la-file usr/share/pyshared/sugar/_sugarext.la /usr/lib/python2.5/site-packages/sugar != /usr/share/pyshared/sugar I believe that error is wrong, as python-central adds symlinks at install time which makes the .la file paths work properly at runtime - even if they are missing in the package itself. Setting severity as important, as ftpmasters reject packages based on this lintian judgement (i.e. sugar-toolkit on april 1st). - Jonas -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils 2.19.1-1 The GNU assembler, linker and bina ii diffstat 1.46-1produces graph of changes introduc ii dpkg-dev 1.14.25 Debian package development tools ii file 5.00-1Determines file type using magic ii gettext0.17-6GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libdigest-sha-perl 5.47-1Perl extension for SHA-1/224/256/3 ii libipc-run-perl0.82-1Perl module for running processes ii libparse-debianchangel 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl 1.1600-9 Time and date functions for Perl ii liburi-perl1.37+dfsg-1 Manipulates and accesses URI strin ii man-db 2.5.5-1 on-line manual pager ii perl [libdigest-sha-pe 5.10.0-19 Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarchnone (no description available) ii libtext-template-perl 1.45-1 Text::Template perl module ii man-db2.5.5-1on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522613: lintian: false positive package-lacks-versioned-build-depends-on-debhelper 6 (5.0.44 is new enough)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 reassign 522613 cdbs retitle 522613 dh compat 6 must depend on v6 (not v5.0.44) thanks On Sun, Apr 05, 2009 at 08:38:46PM +0100, Adam D. Barratt wrote: On Sun, 2009-04-05 at 11:58 +0200, Jonas Smedegaard wrote: Lintian reports problems with debhelper dependency when using 6 in compat and build-depending on debhelper version 5.0.44. Debhelper itself claims support for compat version 6 in its changelog entry for version 5.0.44, which is the reason this version was used in CDBS dependency resolving. The changelog for 5.0.44 says introducing beginning of v6 mode which is somewhat weaker than support for compat version 6 imo. v6 mode was not finalised until the release of debhelper 6.0.0, as is the custom with debhelper versioning, so I believe Lintian is correct here. Depending on debhelper 5.0.44 will give you some v6 functionality, but by no means all of it. Thanks - also to Russ. Your explanations make sense to me. I will fix my 70+ packages having too weak dependency, and reassign this bugreport to cdbs (where I will most probably fix it myself - I help maintain that package, am to blame to relaxing that very dependency hint). Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknZHeIACgkQn7DbMsAkQLg7tQCeNz9UMtmlKJFSCaBdbgXG+DPs ANYAnjffxWeJo+074TraSPXufVXMExvR =lDmH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
