Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Debian Traffic #15 For 22 Dec 2000

Editor: Zack Brown

By Prashanth Mundkur  and  Zack Brown

Debian Home Page | Weekly News | Social Contract | Constitution | Policy Manual
Developer's Reference | Documentation Project | debian-devel Archives

Table Of Contents


Want to help write KC Debian? See the KC Authorship page the KC Debian homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.

Mailing List Stats For This Week

We looked at 583 posts in 2050K.

There were 254 different contributors. 123 posted more than once. 0 posted last week too.

The top posters of the week were:

1. New handling of setuid packages

29 Nov 2000 - 7 Dec 2000 (49 posts) Archive Link: "dpkg-statoverride vs. suidmanager"

Summary By Prashanth Mundkur

People: Domenico AndreoliWichert AkkermanMarcus BrinkmannJoey HessAnthony TownsOlaf MeeuwissenMatt Zimmerman

Matt Zimmerman asked about the use of dpkg-statoverride for packages containing setuid binaries that were previously handled using suidmanager.

A long thread was spawned that discussed the various issues in transitioning from suidmanager to dpkg-statoverride: preserving user setuid customizations, and security. Wichert Akkerman, Joey Hess, Petr Cech and Domenico Andreoli discussed dpkg 1.8 handling the conversion of the suidmanager database into the one used by dpkg-statoverride, and the different interactions with packages using suidmanager that transitioned to dpkg-statoverride before or after an upgrade to dpkg-1.8. Complications were caused since files had to be arranged differently in the .deb archive depending on which mechanism of setuid management was used. Joey and Wichert agreed that such transitioning packages should pre-depend on the correct version of dpkg. When Domenico Andreoli requested a clarification, " do you mean that if a setuid binary as to be managed with suidmanager it must go in .deb without the setuid (becouse that little window upon deflating the .deb in which it is setuid even if it shouldn't)? if it would be managed by dpkg-statoverride it can be whatever mod you want?" Wichert replied, "Exactly." Marcus Brinkmann pointed out that "This seems to mean we get a pre-dependency on the new dpkg in every package moving to statoverride."

Joey later cleared the fog again, explaining the difference between the two mechanisms:

Doesn't really work because suidregister requires that binaries be shipped non-suid, and it may add the suid bit, while statoverrides allow the binary to be suid in the .deb itself (this is a good thing, it makes it easy to tell if some package has a suid file before installing it).

If new packages ship suid binaries and the old suidregister is being used, there is a window where binaries will be suid even if the admin has turned off those permissions, and we should not allow that.

Anthony Towns eventually come up with more suggestions, one of which was essentially agreed on. He said, " have dpkg 1.7.x conflict with suidmanager <= 0.45, suidmanager 0.46 depend on dpkg >= 1.7.x, so that suidmanager is upgraded along with dpkg. the new suidmanager could, perhaps, register all its settings with dpkg-statoverride," except that Wichert added "We'll have to make it dpkg >=1.8 since that will fix some stupid bugs in dpkg-statoverride, and we'll have to be careful to coordinate uploading the packages at the same day."

Elsewhere, there was some discussion about the number of packages affected. Joey Hess found 120 such packages on his system. Olaf Meeuwissen posted the results of his search:

Just checked on a fairly minimalistic server here and my laptop that I use for development work. Both run potato (with security updates).

server 21 suid programs / 121 packages installed
laptop 22 suid programs / 339 packages installed

I haven't changed any of the default permissions (AFAICR).

2. Time To Become A Debian Maintainer

1 Dec 2000 - 11 Dec 2000 (14 posts) Subject: "Debian New Maintainer Status on"

Summary By Zack Brown

People: Goswin BrederlowBen ArmstrongDaniel Burrows

Michael Piefel, keeping close track of the Debian New Maintainer Status page (as he'd been waiting to become a maintainer for 45 days at that time), noticed that between November 16 and December 1, the page recorded a lowering of the maximum number of days anyone had to wait to become a maintainer. This didn't make sense to him, and he posted to the list. Daniel Burrows replied that the numbers probably represented the current state of the system, and that some of the people waiting the longest had been passed through finally, thus lowering the maximum wait statistic. At one point, Goswin Brederlow objected:

If one applicant has waitet 185 Days for his approval, how should that number ever get erased from the list? The 185 Days can't become shorter therefore the number should never drop.

If people who are approved are deleted from the calculation, then that should be called "oldest waiting" or something better. Also the average should be over all appications within a reasonable time (one year?) just to make the figure meaningfull.

But Ben Armstrong gave his interpretation:

I assume these numbers help two groups of people:

First, the NM team wants to know "how are we doing?" Watching that "avg wait" number fall is going to be a good indicator of how the process has improved and applicants are having to wait less time to get through. Historical numbers only give a gloomier picture of progress, answering only "how badly did we do in the past?". Numbers for who is on the queue at the moment tell them how they are doing *now*.

Similarly, the applicant wants to know "how long can I expect to wait?" The "avg wait" number tells the applicant how they're doing relative to other people on the queue. Historical numbers are not relevant because the process is continuously improving (in theory :)

Now, you may feel that the NM team needs to do some sort of pennance, hanging the albatross of their "worst case" numbers around their neck. But I believe they deserve to see what kind of progress they are making with the applicants that they have left on the queue.

Goswin still felt it would be useful to keep an average of past results, going back perhaps 100 applicants; but there was no more discussion.

3. Optimization for subarchitectures

1 Dec 2000 - 12 Dec 2000 (8 posts) Archive Link: "subarchitectures"

Summary By Prashanth Mundkur

People: Camm MaguireBen CollinsRob Latham

Camm Maguire posted his quandary in packaging optimized atlas blas libraries. When built, the optimized binaries would only run on the subarchitecture (like Athlon, PIII, and PII) they were built on, although they would be "much faster!" However, the build process for these libraries posed an interesting problem. He explained, " I still have a problem with *building* the package, however. Currently, atlas both compiles and *executes/times* the resulting code on the compilation machine, to determine the fastest code. To my knowledge, there is currently no cross-compilation capability to atlas. I'm checking into this, but assuming its the case, how can we auto*build* either one package, or many specific architecture dependent packages, where the build process depends on the building cpu?" Later, in a subsequent thread, the discussion continued, with Camm explaining his situation to Ben Collins, saying, " Most importantly, it appears that atlas cannot cross-compile, i.e. the compiled code must *run* on the compilation machine. From what I can see, this makes it impossible to autobuild fully optimized version(s) of this package given the current machines at Debian's disposal. I can set the package up to autobuild a generic x86 lib, like it does currently, which will autobuild successfully. But I could also produce a fully optimized binary package covering p3,p2,k6,k7 given the machines available here. My question: is there anyway to get such a binary package to override the auto-built binary packages in the distribution?"

Ben opined that "That's a downfall in atlas, IMO. There should be a way to compile for a CPU, without actually having that CPU. You will most likely have to hack the atlas build process to get this done."

Rob Latham suggested: "If one is using precompiled binary packages, one has to accept that the packager is aiming for a wide target at the expense of speed enhancements. The users will gladly recompile if it's only a step or two, and that's all it takes to see speedup"

Camm then presented a set of possible options for packaging, and asked for feedback, but there was no response.

4. Uploading Packages Into Debian

8 Dec 2000 - 10 Dec 2000 (10 posts) Subject: "uploading packages"

Summary By Zack Brown

People: Bob HilliardJosip Rodin

William Lee Irwin III wanted to upload some packages for the first time, but didn't know where to upload them to. Charl P. Botha pointed him to the Developer's Reference, and William replied with a chapter-and-verse citation, for Uploading To FTP-Master. But Bob Hilliard put in:

Unfortunately, the "Developer's Reference" is outdated in this respect. The currently correct address for uploads is or (aliases for the same machine). The incoming directory is a mouthful "/org/".

dupload, from the package of the same name, is a script to automate uploading of packages. The default configuration file for the current version includes the correct url and incoming directory for auric.

Josip Rodin corrected him on both points, saying that the current Developer's Reference was not outdated, and that Bob must have been looking at an old one. He added that dupload did not contain the correct URL and incoming directory for auric. Bob replied, "I stand corrected."

5. A task-science Package?

8 Dec 2000 - 13 Dec 2000 (12 posts) Archive Link: "RFC: new task-science package"

Summary By Prashanth Mundkur

People: Dirk EddelbuettelRalf TreinemMichael A. MillerRalf Treinen

Parallel to a long discussion on task packages, Dirk Eddelbuettel asked for feedback on the packages in task-science, which he had recently taken over and was planning to reorganize a little: "I removed some packages which were IMHO too esoteric, or which were libraries only (though I might one day place them back into a new `task-science-dev') and added a few others." When Ralf Treinen objected to the word "Science" being used for a task that described itself only in terms of scientific computing and data analysis, saying a task-science " should include tools like theorem provers (packages mona, coq) and there are certainly simulation tools for physics, neural nets, biology, chemics, etc." Dirk agreed and asked, " One operational issue now is how we are going to get rid off the lingering task-science package if we decide to go with task-numerical-analysis (octave, yorick, ...) and task-data-analysis (r-base, pspp, xlispstat, gretl, ...). Plus maybe task-numerical-programming (fftw2, libgsl, lapack | blas | atlas2, ....) ? " Michael A. Miller provided his experience, " As scientist who primarily uses debian and other unix systems in the lab and on my desk, I've found task-science to be of limited use. Most of the things I use for distinctly "scientific" tasks are not in task-science, " and suggested some options, like having a task-fft that "could include fftw2, NumPy and a complete collection of the other packages that include fft routines." Dirk made his priorities clear, though: "Those are metapackages, and left for another discussion. My focus right now is to get task-science into more useable shape."

Other discussion focussed in the problem of having too many task packages, targetting newbies and suggestions of other packages for inclusion.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.