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

Debian Traffic #6 For 12 Oct 2000

Editor: Zack Brown

By Jens MüllerSteve Robbins  and  Zack Brown

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

Table Of Contents

Introduction

Want to help write KC Debian? See the KC Debian homepage.

Mailing List Stats For This Week

We looked at 412 posts in 1561K.

There were 180 different contributors. 78 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Installing Packages In Nonstandard Directories

25 Sep 2000 - 2 Oct 2000 (16 posts) Archive Link: "Can I use dpkg -i to install in /usr/local or /opt?"

Summary By Zack Brown

People: Ethan BensonFriedrich DominicusMike MarkleyDale Scheetz

Someone asked if it were possible to use 'dpkg' to install packages under '/usr/local/index.html' or '/opt/index.html'. Ethan Benson replied that he didn't think this was possible. He added, "it would be cool if .debs could be installed in the confines of a user's $HOME but i think it would severly complicate packaging policy..." Dale Scheetz suggested just using 'ar' or 'mc' to extract files from '.deb' packages directly, but the original poster pointed out that this would lose all the benefit of proper package management. Friedrich Dominicus gave his perspective, saying, "please consider what Debian is working for. The want to be fully conformant to whatever Standard will be there for files and directories. Now one of the points is. No vendors should install anything below /usr/local. The point is if you make it easy to instal whereever you like. This will be done and all the work on standards will go downhill." And Mike Markley added, "This is free software. You have the source. Use it instead of suggesting that maintainers jump through flaming hoops to satisfy a tiny portion of the users by making custom installations marginally easier."

Elsewhere, Ulf Jaenicke-Roessler gave a link to Issue #1, Section #1  (28 Aug 2000: Location Of Files For Personal .deb Packages) for discussion on a similar issue. The original poster replied that he was not suggesting changing Debian's policy regarding standard installation directories, just that it should be possible to override the standard if one wanted. The discussion went back and forth for awhile, and the original poster eventually gave up on the idea.

(ed. [Zack Brown] My own personal opinion is that ideally the tools would allow the standards to be overridden (or at least that the idea should not be totally dismissed). It's possible to be fully conformant to standards, without being limited by them in turn. For example, Linus' approach to POSIX threads is to create a "proper" threading system, and then emulate POSIX threads on top of that. Linux threads will be more powerful than POSIX threads, but anyone will be able to limit themselves to just the standard if they please.)

2. Stability And Resource Limits

27 Sep 2000 - 29 Sep 2000 (10 posts) Archive Link: "unstable, metastable, stable"

Summary By Jens Müller

People: Alexander PerrySeth CohnJoey HessJacob Kuntz

Alexander Perry remarked that it "occurs to me that many of my systems would benefit from splitting unstable into two separate sections, where each package maintainer specifies a flag that determines which section it should be in." He suggested a new distribution he called 'metastable', where all packages should be put that cannot cause any harm to any other user's environment than the one running it.

(ed. [Jens Müller] I don't know really how a program could break any other part of the system than that one it (i.e. the user running it) has access to, that's what the security system is for.)

Petr Cech pointed him to the testing distribution available via the following sources.list lines:

deb http://auric.debian.org/~ajt/ testing main
deb-src http://auric.debian.org/~ajt/ testing main

Joey Hess started a new subthread, pointing out that any program could kill the system by simply eating system resources such as memory. The only way to prevent this would be to introduce hard limits. Jacob Kuntz asked if this should be a goal for Woody, and Joey said he'd love to see such a package, though he felt it would require some difficult config editing through the system

Seth Cohn also asked for hard limits and concluded:

I think it would be a great goal for woody, not only would it make it stand out in the crowd, but it could be another 'package' pool item. Things that don't respect hard resource limits could be 'isolated' in pools so that an even more stable 'stable' could be had.

Let's make memory leaks taking a system down a thing of the past. (or just a thing of Windows)

3. Progress On 'lintian'

29 Sep 2000 - 5 Oct 2000 (10 posts) Archive Link: "lintian lives!"

Summary By Zack Brown

People: Sean PerryWichert AkkermanJosip RodinRoland Bauerschmidt

Sean Perry announced:

I am working on the current code base of lintian. Currently about one third of the currently open bugs have been fixed. Now for testing, testing, testing. So, once a release is prepared, expect a new round of bugs against packages which fail lintian. Also, if you want a feature in lintian and there is no bug asking for this feature, now is your chance to ask.

Goals:

get everyone using lintian again make lintian better, faster, etc. improve lintian's accuracy find a way to not need overrides files as much bring lintian fully up to speed with policy 3.2.x -- a good way there

Current issues:

the whole "your library has no shlibs file" thing. Once a policy has been approved for packages with dynamically loaded modules lintian will be brought up to date.

debconf files are marked as unknown control files. debconf is not in policy yet and neither are the files it uses. Once they are in policy, this message will go away as well.

Roland Bauerschmidt pointed out that http://lintian.debian.org/ only showed Potato packages at the moment, and suggested including Woody reports as well, and Sean replied that once 'lintian' was ready, he hoped it would again do regular runs against the unstable branch, and post its output to that site.

Wichert Akkerman also replied to Sean's current issues, with, "Simple policy: .so files that are not in /lib, /usr/lib, /usr/X11R6/lib/, /lib or /usr/lib/libc5-compat are not libraries but loadable modules." Josip Rodin urged folks to post replies to the bug report covering that issue, bug #66023. Meanwhile, Sean reported that the policy failed for several packages, "notably qt and glibc-debug." Josip replied, "QT has symlinks from /usr/lib to its private directory, so it's compatible (in the FHS meaning); glibc-debug can be an exception." Sean replied that he'd like to see the entire text of the proposal, with the symlink issue stated in the proposal.

End of thread.

4. SONAME Convention

30 Sep 2000 - 5 Oct 2000 (10 posts) Archive Link: "Need help with strange ldd output"

Summary By Steve Robbins

People: Yann DirsonBen CollinsKevin RydeBranden RobinsonJules Bean

Yann Dirson was trying to compile a package that contained the shared library file /usr/lib/liballeg-3.9.33.so, and discovered that the ldd output for the program he was linking against this library confused dpkg-shlibdeps:

When I link something with it I get in ldd's output:

liballeg-3.9.33.so => /usr/lib/liballeg-3.9.33.so (0x40025000)
libc.so.6 => /lib/libc.so.6 (0x400d6000)

This syntax confuses dpkg-shlibdeps (and dh_makeshlibs did not look at the file either). Did anyone already seen such a problem ? Was the lib erroneously built, or is it just a symlink missing (I tried to symlink it to liballeg.so.3.9.33, with no changes.

To this last, Ben Collins responded with:

That is not proper soname convention. It should be liballeg.so.3. If you do what glibc does, then you have

liballeg-3.9.33.so
liballeg.so.3 -> liballeg-3.9.33.so
liballeg.so -> liballeg.so.3 (in the -dev package)

But the SONAME (as shown by the output in 'objdump') should be liballeg.so.3.

Jules Bean thought Ben was saying that the SONAME must end with the major version number, and suggested that for fast-developing libraries, it could make more sense to use both the major and minor versions in the SONAME and link name. But Ben clarified: " That's fine, so long as the soname ends with the ABI version, and not .so. That's mainly the convention I was trying to convey. "

With the hints from Ben, Yann was able to fix up the build process, and announced that he had uploaded the "allegro" package. Kevin Ryde checked it out and said: " It links to libXxf86dga and libXxf86vm which seem to be available only in non-PIC ".a" form, unless that's changed since xlib6g 3.3.6-6 which is all that's on my system at the moment. " Branden Robinson declared: " No, they continue to be available only as static libraries, because there is no official API for them. (libXfont and libXrender should not have shared versions, either, but they do in current phase2 .debs; I'll turn this off when I find the correct config/cf/Imakefile gizmo.)"

5. 'dpkg-scanpackages' And Multiple Package Versions

1 Oct 2000 - 2 Oct 2000 (6 posts) Archive Link: "annoying behavior of dpkg-scanpackages"

Summary By Steve Robbins

People: Massimo Dal ZottoWichert AkkermanDale ScheetzJason Gunthorpe

Massimo Dal Zotto noticed that:

when there are more version of some package in a directory dpkg-scanpackages uses always the wrong version:

# dpkg-scanpackages . /dev/null dists/local/dz/ >Packages
! Package dpkg-www (filename ./dpkg-www_2.4_all.deb) is repeat;
ignored that one and using data from ./dpkg-www_2.3_all.deb !

and wondered " why it doesn't use the highest version so that I can simply keep my old versions in the same directory. This is very annoying. Is there any reason for this behavior? "

Wichert Akkerman replied that it's "already fixed in CVS" which puzzled Dale Scheetz because he understood that " an archives was required to have only one version of every package. When did that change? " Jason Gunthorpe clarified, saying, " this is not strictly true, tools these days are required to handle multiple versions and multiple architectures in the same package file. " This reminded Wichert that he still needed to fix dpkg-scanpackages to handle multiple architectures.

6. 'lintian' 1.11.5 Available; Discussion Of Possible Extensions

2 Oct 2000 - 3 Oct 2000 (7 posts) Archive Link: "lintian 1.11.5 uploaded"

Summary By Zack Brown

People: Sean PerryAndreas SchuldeiColin WatsonDaniel Jacobowitz

Sean Perry announced uploading version 1.11.5 of 'lintian', and added, "Once the new packaging and policy manuals get sorted out, I will go through and ensure all of the references to policy are accurate." He invited folks to suggest features, and Andreas Schuldei replied, "I am thinking about a lexical scanner to detect security sensitiv code wich might for example create opportunities to smash the stack etc." Colin Watson continued:

I was thinking about this too over the last couple of days, in the specific context of format string attacks. I concluded that doing it well probably required too much knowledge of C for just a lexical scanner (there'd be a lot of both false positives and false negatives with the best approaches I can come up with), but that some new warnings in gcc would do a much better job.

gcc already warns when you get the argument types to printf() wrong - other vague possibilities might be extending this to other format-string functions and warning about non-const format arguments.

Daniel Jacobowitz pointed out that this functionality already existed in the 'gcc' CVS tree, and Andreas replied:

Indeed it is already there. And indeed it produces too may false positives. See the discussion on security-audit. People were unsatisfied with it.

But there exist programs like PScan http://www.striker.ottawa.on.ca/~aland/pscan/ one could start out with and one could extend. One should also check if all the relevant signals are caught and if environment variables are cared for. How one does that I do not know now.

This is just C lexical scans now. Perl has some internal, pretty strict checking build in already. For test purposes one could activate that.

The discussion ended there.

7. Exim Versus The Latest 'libc': DB Incompatibility

2 Oct 2000 - 7 Oct 2000 (8 posts) Archive Link: "Still exim problem"

Summary By Steve Robbins

People: Fabio Massimo Di NittoHerbert XuMark BakerBrendan O'Dea

Fabio Massimo Di Nitto noticed a problem with exim after upgrading it to version 3.16-4:

This morning I got this error message:

/etc/cron.daily/exim:
Exim retry database in spool /var/spool/exim
Failed to open database file retry: Invalid argument
run-parts: /etc/cron.daily/exim exited with return code 1

How can I fix it????

According to Herbert Xu, the new version of exim " should delete/update all its database files since it is incompatible with them. " Mark Baker responded:

It isn't intended to be incompatible with them. As soon as anyone tells me where I can find a library that works with libdb 1.85 files, I'll link exim against it. There used to be one distributed with libc that did, but it isn't included in the latest libc; libdb2 doesn't although it does implement the 1.85 API.

If there really isn't any compatible library in debian any more, and this lack isn't just a temporary oversight, then I guess I'll have to make an exim package that deletes those databases when upgrading from an older version (they're only hints anyway, so it's OK to delete them).

Fabio then stopped exim, deleted the lockfiles in the /var/spool/exim/db directory, and restarted exim. He reported partial success:

even if exim find the correct files it's still reporting me each cron.daily execution this message:

/etc/cron.daily/exim:
Exim retry database in spool /var/spool/exim

Brendan noted that this message " appears to be produced unconditionally by exim_tidydb (see exim_tidydb.c, line 162). The program should probably be changed to be less verbose, or to output error messages on stderr so that the crontab entry may redirect stdout to /dev/null. " Meanwhile Mark also replied to Fabio, saying that he would " change the crontab entry so it redirects stdout to /dev/null (and check that any real errors go to stderr) "

8. Living In 'unstable'

3 Oct 2000 - 6 Oct 2000 (13 posts) Archive Link: "When unstable breaks"

Summary By Zack Brown

People: Joost ClaessenJim Lynch

Joost Claessen pointed out that with the recent 'glibc' breakage in Woody, it might be a good idea that "when such a problem is noticed, the server goes in a state of "I don't give (some) package because something is messed up" until the problem is fixed? It would include modifying apt (and dpkg, am not sure) so that when someone tries to upgrade they know they should wait for a while? Not all people are subscribed to the mailing list so the "damage" is reduced to a minimum." Jim Lynch replied:

Such a freeze would represent a layer of protection not unlike the "stable/ unstable" dichotomy existing now. Suppose something breaks in the layer you propose... wanna add a third layer? will each layer represent a group of maintainers developing for people using the layer closer to the dist?

There is the bug tracking system... track that... read source code... read mailing lists... read ITPs and changelogs... read about intent on the part of the maintainer...

The discussion went back and forth for awhile, with some people suggesting various possibilities to avoid the most dangerous aspects of using the unstable version, and others pointing out that the unstable version was called unstable for a reason.

(ed. [Zack Brown] My own personal view is, it would be nice to have some "more safe" way to use the unstable branch, since that's where all the latest packages go; but at the same time that might end up taking folks away from really pounding on the unstable branch, reporting bugs, etc.; this could in turn slow down the release schedule. It seems to me that part of the point of the unstable branch is to benefit from all the eyes, gradually becoming more and more stable as bugs are found and fixed. This seems to be in fundamental opposition to finding a way for the unstable branch to be used as if it were the stable branch.)

 

 

 

 

 

 

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.