Disclaimer: I'm no AM.
Once in a while, when I read debian-mailinglists I notice some relativ easy todo stuff which would improve Debian - if it only would be done. But it doesn't get done, because the people aware of it, have no time to do it, which is a pity, because it'd be very nice to have. Usually these jobs don't need special priviledges to do them, just some time, some knowledge and some skills.
So I had the idea to set up this wiki page and collect such tasks here, so that AMs can assign them to their NMs. I envision four benefits at least: 1. Debian is improved. 2. The NM has a useful task to do and nothing "theoretic". 3. The AM can see how the NM works. 4. Anybody with some spare time can look if there is something interesting and useful to do.
P.S.: Please leave the layout as it is, thank you very much.
deal with RC bugs in stable
Many RC bugs where filled against packages that have or had the same version in etch (stable) and sid, but the bug is only relevant for sid and lenny. These bugs need to be identified and tagged for testing (lenny currently) and sid, so that they don't show up as appearing in stable.
A automatic checker for loops in essential
> So e2fsprogs which is "Essential: yes" depends on libuuid1, so > libuuid1 is effectively "Essential: yes", right? So if I add a > dependency on passwd, it will effectively make passwd "Essential: > yes", as well, and according to policy I should bring it up for > comment on debian-policy. So, I am doing so now. My mail headers disagree. :) Is this really meant to be on debian-policy rather than debian-devel? > Any objections if I add a dependency on passwd for libuuid1? The > aternative would be to roll-my-own useradd/adduser functionality, but that > would be a real PITA.... I think rolling your own would be wrong no matter what. If there are specific reasons why libuuid1 can't depend on passwd, we should address those instead. But let's have a look: Package: passwd Version: 1:188.8.131.52-1 Depends: libc6 (>= 2.6.1-1), libpam0g (>= 0.99.7.1), libselinux1 (>= 2.0.15), login (>= 970502-1), libpam-modules (>= 0.72-5), debianutils (>= 2.15.2) $ grep-dctrl -n -FEssential yes -sPre-Depends /var/lib/apt/lists/*sid*Packages \ | tr ',' '\n' |sed -e's/^ //' | sort -u coreutils (>= 5.93-1) e2fslibs (= 1.40.3-1) initscripts libacl1 (>= 2.2.11-1) libblkid1 (>= 1.34-1) libc6 (>= 2.3.6-6) libc6 (>= 2.5) libc6 (>= 2.6-1) libc6 (>= 2.6.1-1) libc6 (>= 2.7-1) libcomerr2 (>= 1.34-1) libncurses5 (>= 5.4-5) libncurses5 (>= 5.6+20071006-3) libpam0g (>= 0.99.7.1) libpam-runtime (>= 0.76-14) libselinux1 (>= 2.0.15) libslang2 (>= 2.0.7-1) libss2 (>= 1.34-1) libuuid1 libuuid1 (>= 1.34-1) sysvinit-utils sysv-rc (>= 2.86.ds1-1.2) | file-rc (>> 0.7.0) zlib1g (>= 1:184.108.40.206.dfsg-1) $ So libc6, libpam0g, and libselinux1 are already Pre-Depends of some essential package or other, and don't pose a problem here. login is also Essential: yes, so is only in the list because it's a versioned dep; but it's a versioned dep on a version older than oldstable, so we can probably prune that dep from passwd to make the essential set just a little less tangled. Anyway, nothing in essential currently depends on passwd so we know there's no problematic loop here. debianutils is likewise essential, and the versioned dep is likewise satisfied by the version in stable (though not in oldstable). Again the dep could probably be pruned. That leaves libpam-modules being pulled in, which is not currently essential or a pre-dep of any other essential packages. This is not a spurious dependency on the part of passwd; actually, I'm left wondering why login has it as a Depends instead of as a Pre-Depends, since the stock login PAM config isn't going to work very well without those modules, so login seems to be failing the requirement to be minimally functional while unpacked but not configured. But anyway, let's have a look at what promoting libpam-modules entails. Package: libpam-modules Version: 0.99.7.1-5 Depends: libc6 (>= 2.6.1-1), libdb4.6, libpam0g (>= 0.99.7.1), libselinux1 (>= 2.0.15) Three familiar libraries again, along with libdb4.6. libdb4.6 itself has no dependencies other than libc6. So promoting passwd to a Pre-Depends of an Essential package doesn't introduce any pre-dependency loops, and the only new packages pulled into the transitively-Essential set are ones that arguably are supposed to be there already. As long as none of the maintainers of other Essential packages have plans to introduce a dependency on libuuid1 that would turn this into a loop, this looks ok to me. (BTW, does anyone want to write an essential-checker to check for those loops automatically? :)
General warnings for packages which had no review or don't have security support
> There is debsecan, which looks up information from here: > > http://security-tracker.debian.net/ > > It doesn't seem to offer integration with dpkg or apt yet. > > It produces a daily mail about which vulnerabilities exist on your > system, which have been fixed and which packages have new > vulnerabilities. Yes, but it only tracks known vulnerabilities. But what we really need (and what Jack seems to have suggested) is a general warning to indicate, that this package is a fringe package and might contain serious bugs since noone except the author has read the source code or that it in unsupported security-wise (we'll need to revoke security support for firebird 1.5 inside Etch, e.g.). Actually, it's been planned to add debtags for that. Enrico Zini has also made a prototype implementation , but we haven't been able to push it further, unfortunately (since regular security triage sucks away all the available time recently). If someone wants to drive this further, so that it's available in Lenny, please get in contact with me and I'll outline what's necessary. After all it's a QA aspect as well.  See the thread "New 'maint' facet for Debtags" in debian-devel
Checker for machine-readable copyright files
There is a copyright format proposal to make the copyright files machine-parsable. To make real use of this, there should be a program to check these files. This program should at least be able to:
- Provide the license of a given file in the tree.
- Check that every file in the tree has a license. This should somehow ignore generated files. The easiest way to do this might be to require the clean target in rules to remove all of them. There is some discussion about this, though.
Contact: Bas Wijnen, email@example.com
Add targets to rebuild everything from source
In debian/rules, most packages build most things from source. But not all. Especially packages which use autotools are often not rebuilding Makefile.in and configure (by running autoreconf), and in case there is generated artwork, this is also not always generated during package build.
I think it would be nice if all packages would be required to do this, but others disagree. There is agreement that it would be a good idea to be able to do this, if not during package build, then at least when requested explicitly, by adding a target to debian/rules for it.
The easiest way to do this would perhaps be to add a realclean target, which removes all generated files. The normal build process should then depend on the generated files (for example Makefile.in), and there should also be a new target to regenerate them. Programs only needed to build the package after debian/rules realclean should not be in Build-Depends.
Contact: Bas Wijnen, firstname.lastname@example.org