Debian Traffic #22 For 10 Feb 2001

Editor: Zack Brown

By Peter EckersleyPrashanth MundkurSteve Robbins  and  Zack Brown

Debian Home Page (http://www.debian.org) | Weekly News (http://www.debian.org/News/weekly/) | Social Contract (http://www.debian.org/social_contract) | Constitution (http://www.debian.org/devel/constitution) | Policy Manual (http://www.debian.org/doc/debian-policy/) | Developer's Reference (http://www.debian.org/doc/packaging-manuals/developers-reference/) | Documentation Project (http://www.debian.org/doc/ddp) | debian-devel Archives (http://lists.debian.org/#debian-devel)

Table Of Contents

Introduction

Want to help write KC Debian? See the KC Authorship page (../author.html) the KC Debian homepage (index.html) , and the Thread Summary FAQ (../summaryfaq.html) . Send any questions to the KCDevel mailing list. (mailto:kcdevel@zork.net)

Mailing List Stats For This Week

We looked at 583 posts in 2168K.

There were 195 different contributors. 99 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Wishful Thinking About Package Management

19 Jan 2001 - 2 Feb 2001 (62 posts) Archive Link: "Secure apt-get"

Summary By Peter Eckersley

People: Kalus ReimerGoswin BrederlowJohn GoerzenBernd EckenfelsMatt ZimmermanBrian MayJason GunthorpeWichert AkkermanBen Collins

Klaus Reimer asked "Is there already any feature to run apt-get in a secure way? I mean that it installs only TRUSTED packages." .

Peter Cech suggested the features added by Connectiva in their port of apt to RPM (see this editorial on Freshmeat (http://freshmeat.net/articles/view/192/) ). Goswin Brederlow mentioned "apt-get's cvs has a ssh method of retrieving files. Of cause you would need ssh access to a save mirror."

John Goerzen replied helpfully:

I have been working with Ben Collins on this project already. You may find some documentation -- albeit somewhat out-of-date -- on this at the URLs below. The software is already written and will be showing up in Debian this weekend.

My draft spec:

gopher://gopher.quux.org:70/9/devel/debian/debsigs.ps (PostScript)
gopher://gopher.quux.org:70/0/devel/debian/debsigs.txt (Plain Text)

This spec allows for multiple signatures per .deb with an eye towards flexibility and open policymaking.

Discussions involving cryptographic security seem to create substantial confusion on Debian mailing lists, and this was no exception. A number of posters thought that signed packages would be of little benefit unless a human made the signatures. But, as Bernd Eckenfels said, "It will [provide] additional security since corruption on the way from master to the user (i.e. mirror or cd) will be detected."

Wichert Akkerman did, however, hint at a problem with giving dinstall a key, and Matt Zimmerman explained:

[Compromising dinstall] only affects packages currently on Debian mirrors, and once the compromise is fixed, things return to normal. If a trusted key were stolen, it could be used to sign packages and distribute them anywhere, and it is much harder to revoke a key from every Debian system than to repair a single system intrusion.

Also, once the key is revoked, older packages (e.g., from previous releases) signed by that key can no longer be verified.

Brian May proposed a work around - "Would it help if you could download the signatures separately from the package? That way [post compromise] an existing CD could still be used, just down load the new signatures (which would be much smaller then the packages themselves) from your local debian mirror." . Matt Zimmerman conceded "Yes, I believe that would help.... Then we are back to the usual, insoluble key management problem."

Jason Gunthorpe's comments provided a clearer idea of the current state of affairs:

Alfredo is porting his Connectiva code into APT4, the FTP masters and Release masters have agreed on a file format/etc and we will likely see signed *releases* for woody (I hope).

This means you can tell that you are using Debian 2.2rX from Debian itself with certainty no matter where you get it from, as long as you can get a trust path back to the signing keys (ie w/ HTTPs and Verisign).

2. Translation of Install Messages

22 Jan 2001 - 30 Jan 2001 (18 posts) Archive Link: "translated templates files"

Summary By Steve Robbins

People: Michael BramerColin WatsonOlaf MeeuwissenGustavo Noronha Silva

Michael Bramer got busy coordinating the translation of messages you see when installing a package:

Debconf allow multi language templates files. But very few packages with templates files use this feature. (only debconf, base-config and roxen support several languages (=>5) )

I start to translate this week same templates and write bugreport. I set a web page to manage this translations.

see: http://auric.debian.org/~grisu/debian_translation/

If you like to help, to translate same (very little) texts, write this page. Translate one or two files in your language or check same translations and write bug reports.

Others joined the translation effort, but most of the thread was spent discussing the 2-letter codes for languages and countries. Some folks apparently confuse the two; for, according to Colin Watson, " I see roxen and roxen2 both use "se" for Swedish translations in the above list, while the generally accepted Swedish locale in most of the rest of Debian seems to be "sv" " .

Olaf Meeuwissen agreed with Colin,

Go ahead, file that bug report! The language tag `se' is used for Northern Sami. Swedish is sv.

See http://www.indigo.ie/egt/standards/iso639/iso639-1-en.html for details.

A few messages later, Olaf elaborated, quoting from some relevant standards documents:

On language codes the HTML 4.01 spec says:

6.8 Language codes

The value of attributes whose type is a language code ( %LanguageCode in the DTD) refers to a language code as specified by [RFC1766], section 2. [...]

Language codes are case-insensitive.

Then RFC1766 says:

The following registrations are predefined:
In the primary language tag:
- All 2-letter tags are interpreted according to ISO standard 639, "Code for the representation of names of languages" [ISO 639].

And ISO 639 then says:

Technical contents of ISO 639:1988 (E/F) Code for the representation of names of languages

Two-letter lower-case symbols are used

Gustavo Noronha Silva also pointed out that languages may have variatiants, " BTW, portuguese has two major "versions", pt_BR (brazillian), and pt (or pt_PT, I don't know exactly) (portuguese), the page has only pt, I'd like to know how is this diference handled, and how is it supported in debconf... I translated base-config's debconf's template, I set it's translated description field as pt_BR (see bug #83206). " Michael Bramer changed his script that generates the web page to support xx_XX style language codes.

3. Vouching for a New Maintainer

27 Jan 2001 - 1 Feb 2001 (60 posts) Archive Link: "[Fwd: [RFC] Making NM 'by recommendation']"

Summary By Steve Robbins

People: Martin MichlmayrGlenn McGrathIan JacksonJulian GilbeySam HartmanCraig Small

Martin Michlmayr, one of the hardest-working of Debian's Application Managers, made a proposal to slightly change the New Maintainer procedure. Though he made his proposal to the debian-newmaint-admin list, Glenn McGrath forwarded it to debian-devel, sparking a fairly large flame war. In his proposal, Martin said:

I have recently seen an increase in applicants who are unprepared or don't even respond to my initial or follow-up messages. I have the strong suspicion that this is related to the fact that it's really easy to sign up for NM -- simply enter your name and e-mail address, and there you go! You no longer have to think how serious you are about it and what you want to do for Debian.

My proposal is this: You can no longer apply to become a Debian developer yourself, but instead you need an existing Debian developer to recommend you. Nothing in the NM system changes except of the application itself. The developer who recommends another person as a NM is not responsible for him or has to go through the NM process with him (the latter will still be done by an AM) -- so this recommendation is no report to the DAM, but simply the entry ticket to the NM process.

How do you find someone to recommend you? Easy, if you meet a developer for key signing you can ask him to recommend you, or if you are active on the Debian mailing lists or help out with boot-floppies or a Debian port, I'm sure someone is willing to recommond you. Or, of course, a sponsor can do it.

This change would guarantee or at least increase the chance that applicants

- have a signed GPG key

- have a sponsor

- have had contact with Debian before

- have seriously thought about joining Debian

What do you think of this? I would like to implement this sooner than later, so please share your comments.

Finally, here are some statistics; these are the number of people who apply for NM each month. Of course I don't know how much increase is due to the dropping waiting time for NM and the easy-to-use web interface, but...

Glenn prefixed the above with his own take on Martin's proposal:

There is a faction of debian developers who are elitists and want to close the system to new developers (numerous attempts have bee nmade by diffferent methods)

These sorts of arguments are devisive and counterproductive to debians goals, but i think this topic needs to satisfactorly be discussed and _concluded_. I think elitism is the only threat to debians viability. If the elitists gain power their will no doubt be a manpower shortage as there will be a lack of "worthy" new maintainers to do the work that the elitists want to hand to other people.

As expected, a few people on debian-devel had comments. There is a faction of unabashed "elitists" who favour raising the bar of technical competence. Ian Jackson, for one, is of the opinion that " anyone who thinks that it's a problem that these procedures are elitist should not be a Debian developer, but should go off and do something else. Elitism - ie a high standard of techical excellence - is *exactly* what we're here for, and continue failure to recognise that will lead and is leading to problems. "

The consensus view, however, was that Glenn had misinterpreted Martin's proposal. As Julian Gilbey put it:

I think this is not, in any way, what Michael was suggesting. I don't know whether you have been following what has been happening in the New Maintainer arena for the last two years, but the rate at which people are currently being accepted into Debian is far higher than it has ever been before.

However, this is due to the stirling work of a large number of volunteers who are devoting part of their time to acting as Application Managers, gathering the required information from prospective developers and ensuring that they have the technical competence to do what they wish to do for Debian.

What many of the AMs are noticing, however, is that over the last couple of months, the people who are in the NM queue are more and more often either not interested in becoming developers, or they don't respond to emails, or they have no idea what they are doing, or they don't know what they want to do in Debian. I effectively ended up sponsoring one of my applicants until he was technically up to the level I felt was required of a developer (and if the developer concerned is reading this, I don't mean this personally).

What is the result of this? Applications are handled in general on a first-come, first-served basis, and the rate of applications being received is now significantly greater than that of them being processed. So the queue is going to grow again, despite our best efforts, but critically, those people who are actively already working for Debian and need to become registered developers to effectively do their work are being lost among those who have no idea. There is a system for putting applicants "on hold" if they are not ready, or don't respond, but it wastes the small amount of time that the AMs have to devote to this work, and thereby holds up those people who really ought to be in the queue.

The proposal is a simple one. Already, someone is only accepted as a new maintainer if they pass the requirements (all of which are documented explicitly on the website, see under http://www.debian.org/devel/join/newmaint). The suggestion is that they have to convince an existing maintainer to recommend them to the NM team before they will join the queue. Now, anyone who is seriously interested in becoming a new maintainer should already be actively involved in some aspect of Debian, either active on a list or working on a package through the sponsorship system. If they are so unknown that they cannot even find even one developer who is willing to put their name forward to the NM team, why are they applying in the first place?

If this proposal means that the number of applicants who just drop out of the process after wasting people's time is significantly reduced, then it is worth it. And if it means that applicants enter the NM system actually ready to become maintainers (with all the docs and experience etc required), then it will help many more people to join Debian far more quickly. And I do not envisage that a single applicant who would have got through will be prevented from doing so by this proposal.

So I see this proposal as a way of helping Debian to open its doors rather than the opposite.

Most of the posters to this thread saw it this way, and Glenn eventually conceded, " it was wrong of me to brand Martin an elitist " . Sam Hartman wondered, " What about trying something simpler like having a checklist of steps that the maintainer should follow (already done) and requiring them to check off that they have completed enough of them when they first apply. I suspect that people would tend to tell the truth and to self-select. " Unfortunately, says Martin Michlmayr, " There is a checklist and a big link from the application page; it didn't work. "

Craig Small got busy and implemented a checkbox system on the application form. This change passed from proposal to implemented in four days or less. That's gotta be some kind of record!

4. Mailing List Confusion

29 Jan 2001 (24 posts) Archive Link: "HOWTO announce ITP"

Summary By Zack Brown

People: Julian GilbeyJosip RodinBrian MayMark BrownMartin MichlmayrSam Hartman

Julian Gilbey instructed:

To announce an ITP, please send a mail to submit@bugs.debian.org (mailto:submit@bugs.debian.org) against the wnpp package with Severity: wishlist and subject line "ITP: packagename".

Don't send it to -devel directly; the BTS will forward it there *after* the ITP has been given a bug number.

Mark Brown could not confirm that the BTS was properly forwarding the ITPs, and Sam Hartman suggested updating the Developer's Reference (http://www.debian.org/doc/packaging-manuals/developers-reference/) to reflect the current procedure. Elsewhere, there was some confusion over whether the new system even behaved as it had been described. Mark Brown could not confirm that the BTS properly forwarded each ITP, and Josip Rodin said, "the BTS will not forward it automatically to -devel, but to wnpp@d.o list. Unless someone has implemented it while I wasn't looking... You need to put `X-Debbugs-Cc: debian-devel@lists.debian.org' header (real header, not pseudo like Package) in order for the BTS to CC: the mail (with the bug number in the subject line) to -devel list." Julian groaned and asked, "could we modify the wnpp@debian.org alias in master:/etc/alias to forward also to -devel? If this is agreed, I'll forward this message to debian-admin." Martin Michlmayr did not like that idea, since the wnpp mailing list got a lot of traffic that didn't belong on -devel. At one point, Josip added, "There will be a new list created, debian-wnpp@lists.d.o, and it will replace wnpp@d.o address. That way everyone who wishes to see ITPs and all can subscribe to that list." Julian offered the suggestion that most people, although not avidly fascinated by ITPs, still might be interested in the occassional one, but would rather not "subscribe to Yet Another List for something of only marginal interest." Brian May agreed, and added, "If these messages aren't posted to debian-devel, you run the increased risk of the problem not getting noticed until somebody asks "how come you changed the name of your package?"" Close by in the thread, Josip argued, "the reason ITPs were posted to -devel thus far is that there was no other more appropriate list, but the information had to be posted somewhere where everybody could see it. With the automated WNPP that can be browsed using the BTS and which has nicely sorted web pages, and considering there's simply way too many ITPs etc these days, another list looks like a logical step forward." And Julian replied, "I guess you're right."

5. Debian in CVS?

29 Jan 2001 - 3 Feb 2001 (65 posts) Archive Link: "RFC: Central version control for Debian"

Summary By Prashanth Mundkur

People: Matt ZimmermanJoey HessJunichi Uekawa

Matt Zimmerman wanted to take a leaf out of OpenBSD's book and have a central CVS repository for Debian code. As in OpenBSD, it would help auditing efforts of the entire source tree, as well as make it easier for the Security Team to " create branches from older versions to backport fixes, and easily extract individual changes (e.g. changes to a particular source file between two upstream releases) and merge them in" , increase peer review, sharing and collaboration between maintainers, and make it easier for maintainers adopting orphaned packages to deduce packaging decisions from its history.

Joey Hess provided a little background on a similar discussions in past two Atlanta Linux Showcases, especially on a cvs for Debian.

The idea we eventually decided would be a good one is to set up a system and import all of the sources in debian into it. After that, the system sits there and tracks packages as they are installed into the archive each day, and grabs the new version, checking it into cvs.

The resulting cvs archive would be generally read-only, at least in the beginning. Some developers may eventually opt to use it as the canoical archive for their package (typcially people who have been maintaining their own cvs repositories, and groups like the boot-floppies, I guess -- no need for two cvs repositiories in these cases).

But the good thing about doing it this way is it doesn't really change how things are done now. Developers can opt to not use cvs if they don't want to, and their uploads will still be automatically checked in.

There are some hurdles though:

Presuming we could find someone to donate the disk space, I think it would be worth it. Matt listed some of the nice benefits it would yeild.

Predictably, one of the first questions raised was about the infrastructural requirements for this enterprise. Matt clarified that he had in mind only the code for standard and higher-priority packages. Joey Hess provided some real data on the size requirements of selected packages:

Package Current tree size Repository size Revs Growth
debconf 726 kb 4.2 mb 294 5.8
boot floppies 9.7 mb 48 mb 74 4.9
bsdgames 7.3 mb 9.2 mb 28 1.26
sphinx2 24.5 mb 25 mb 3 1.02
xjewel 261 kb 291 kb 7 1.11
aalib 1.2 mb 1.5 mb 23 1.25

Revs is the number of revisions since it entered cvs (roughly: it doesn't count cvs commits w/o a debian revision, or branches so is low for boot floppies).

Growth is repository size divided by current tree size.

Most of these packages have been in cvs for years and years. I picked them randomly from what was at hand. While it does demonstrate that packages that undergo a _lot_ of revisions (debconf) or that are developed for a long time in cvs (boot floppies), can see large growths in the repository, it also indicates that more typical packages that are not debian-native, and receive only modest numbers of revs tend to see growths of only 1/4 again their size in the repository over a period of 3 to 4 years. In fact, my entire repository (56 packages) is just 1.8 times the size of the current source trees.

The ed-diff-like format used by rcs is quite efficient.

Matt provided some data on his efforts:

Today, I imported the rest of standard into my CVS repository. Here are some statistics:

142 source packages 173Mb
121 source packages made it into CVS 138Mb
Repository size 598Mb
Average source package size 0.82Mb
Average repository size per package 4.94Mb
Checked-out CVS tree 593Mb

Junichi Uekawa commented in the subthread on the overloading of CVS servers that "There are many projects which seem to be working with a distributed CVS system. cvsup seems to be used quite widely, and making mirrors of CVS sites seems to be done quite efficiently. [...] And I have checked out the repository for OpenBSD to see how they have done it. They have cvs (anonymous read-only) mirrors all over the world, just like we have loads of ftp mirrors around the world. It has been done before, and does not sound like a completely unreasonable argument."

Matt's last update to the list was:

I've been updating the repository about once per day. I just recently finished automating the process, and the repository now contains 156 (package,version) pairs for 142 packages.

I have put the repository up for viewing with viewcvs here

http://alcor.ddts.net/cgi-bin/viewcvs.cgi/debian/?cvsroot=Debian-test

Not surprisingly, the most oft-changed package is debconf, with 5 uploads in the past 8 days. Other packages with several revisions include rblcheck, cpio, and console-data (all with 3 revisions). Look to those packages if you want to see anything interesting.

Other discussion (predictably, for Debian!) ranged over the use of the repository to satisfy clauses of the GPL license on source code availability.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.