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.

Cheers, h01ger

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.

Contact: zobel@debian.org

A automatic checker for loops in essential

Message-ID: <20080107091659.GA5432@dario.dodds.net>

Note: One of the proposals for this summer of code (SummerOfCode2008/debgraph) will be able to do this -- robertle@semistable.com 

> 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:4.0.18.2-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:1.2.3.3.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? :)

Contact: vorlon@debian.org

General warnings for packages which had no review or don't have security support

Message-ID: <slrnfoqe0l.3p6.jmm@inutil.org> 

> 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 [1], 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.

[1] See the thread "New 'maint' facet for Debtags" in debian-devel

Contact: jmm@debian.org

screenshots.debian.org

Done already. Implemented as screenshots.debian.net -- BerndZeimetz

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:

Contact: Bas Wijnen, wijnen@debian.org

-- I'm working on this. See 478930 -- ?MathieuParent

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, wijnen@debian.org