Differences between revisions 11 and 12
Revision 11 as of 2008-04-16 10:57:14
Size: 7890
Editor: HolgerLevsen
Comment:
Revision 12 as of 2008-04-16 10:58:18
Size: 8580
Editor: HolgerLevsen
Comment:
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:

<b>P.S.: Please dont f*ck with the layout, thanks.</b>
Line 167: Line 169:

== Checker for machine-readable copyright files ==

There is a [http://wiki.debian.org/Proposals/CopyrightFormat 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, wijnen@debian.org

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

<b>P.S.: Please dont f*ck with the layout, thanks.</b>

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>

> 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 with had no review or dont 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

This idea did not came up at a mailing list but at some discussion on "Chemnitzer ?LinuxTage" in March 2008:

It would be nice to have a screenshot (or even a set of screenshots with perhaps different language settings) for each Debian package. This could perhaps be used by applications like goplay (or others that might adopt the idea of goplay) and on general information pages for a package at packages.debian.org. If users might stumble upon a package at this place it sometimes might be very helpful to have a screenshot attached because it is not always straigtforeward to find the homepage of the project and look for a screenshot there.

To implement this idea the following things have to be done:

  • Find a reasonable place to collect these data (for instance register a domain screenshots.debian.org)
  • Set up a database that stores package name, version and a set of screenshots, perhaps some more meta information (I do not want to fight a database flameware, but PostgreSQL has to be prefered because the main infrastructure on Debian servers is running this and the inclusion into this is the final goal)
  • Implement a userinterface to enable users to inject screenshots. I think a Wiki like approach seems to fit here nicely, which means that the hurdle to upload something should be very low but some quality assurance (avoid uploading porn and things like that) should be easily possible as well. (It might be that having a look at the technique which is used in commons.wikimedia.org is a good idea.)

Contact: AndreasTille

There is a [http://wiki.debian.org/Proposals/CopyrightFormat 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, wijnen@debian.org