Hi, Daniel Hartwig wrote: > > Source package: > > > > W ancient-standards-version > > 3.8.3 (current is 3.9.2) > > > > -> Should be updated. Check one of > > /usr/share/doc/debian-policy/upgrading-checklist.* > > > > Bump to 3.9.1 is ok IMO. With 3.9.2 there is: > > > 3.3 > > > > The maintainer address must accept mail from Debian role accounts > > and the BTS. At least one human must be listed with their > > personal email address in Uploaders if the maintainer is a shared > > email address. The duties of a maintainer are also clearer. > > Is this an issue given that the current maintainer address is not > responsive for some time?
No. AFAIK this was introduced because there were some packages which just had a mailing list set as maintainers and it wasn't obvious which persons are responsible for the package. But I'd think about setting the maintainer address to [email protected] and moving Daniel Burrows to Uploaders. That way all future bug reports would go to the list automatically. > > E python-script-but-no-python-dep > > usr/share/bug/aptitude > > > > -> If reportbug (which makes use of that script) is installed, python > > will be installed anyway, so I'd override this lintian warning and maybe > > even file a bug against lintian. > > > > Converted this to sh as the interface is well-defined and it is > conceivable that some package other than reportbug may make use > of the script. The original was trivial enough to not justify > use of python anyway. That's fine, too. > > W binary-without-manpage > > usr/bin/aptitude-curses > > > > -> No problem, but I think either a slave alternative to aptitude or a > > lintian override should be added. I'd prefer the slave alternative. > > > > > aptitude-gtk > > > > W binary-without-manpage > > usr/bin/aptitude-gtk > > > > -> See above. > > I did consider a slave alternative though don't think it is > suitable at the moment since there is no dedicated man page > describing the GTK-standard options. Ok. > I think best bet is an override and moving the man page to > hypothetical aptitude-common (along with other arch-indep > files). Sounds ok until someone writes an aptitude-gtk man page. > > W debian-rules-missing-recommended-target > > build-arch > > build-indep > > W package-would-benefit-from-build-arch-targets > > > > -> Hopefully not too complex to add. > > There is a patch with empty targets but I didn't think > that would be very useful. Agreed, especially because of "package-would-benefit-from-build-arch-targets". That's why I didn't write "trivial to fix". ;-) > With a little more effort we can at least move the docs to > build-indep and get some actual benefits. Great! > > I arch-dep-package-has-big-usr-share > > > > 7336kB 66% > > > > -> Maybe not easy. I'd say not top priority, but worth to look at. > > Yes -- certainly enough there to justify "aptitude-common". Yep. JFTR: I applied for group membership, too. Regards, Axel -- ,''`. | Axel Beckert <[email protected]>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
