Debian Traffic #2 For 14 Sep 2000

Editor: Zack Brown

By Benedikt KöhlerEusebio C Rufian-Zilbermann  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://www.debian.org/Lists-Archives/#debian-devel)

Table Of Contents

Introduction

KC Debian is still looking for authors! I estimate around 20 really cool small to medium-sized threads were left out of this issue. If you'd like to get involved, check out the KC Debian homepage (index.html) .

Thanks go to Michael Stone for pointing out a problem in Issue #1, Section #5  (29 Aug 2000: Sources For Potato Security Fixes) , where incorrect apt sources were given for non-US security updates. I put a note in the text of that summary. Many thanks, Michael!

Mailing List Stats For This Week

We looked at 578 posts in 2066K.

There were 182 different contributors. 94 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Dependencies And Package Groupings

28 Aug 2000 - 10 Sep 2000 (65 posts) Archive Link: "Re: Bug#70269: automatic build fails for potato"

Summary By Zack Brown

People: Anthony TownsHamish MoffattAntti-Juhani KaijanahoRichard BraakmanSteve GreenlandWichert AkkermanManoj SrivastavaJoey HessPaul SlootmanJulian Gilbey

This was a policy discussion that began when someone submitted nearly identical bug reports for 300 different packages, making a number of people rather angry. Julian Gilbey started it off by pointing to Section 10.6 (http://www.debian.org/doc/packaging-manuals/developers-reference/ch-bug-handling.html#s10.6) of the Debian Developer's Reference (http://www.debian.org/doc/packaging-manuals/developers-reference/) , which dealt specifically with the issue of multiple bug reports and which also recommended first discussing the problem on debian-devel. Anthony Towns mentioned that he'd modified the bug-tracking scripts to put all such flooding on hold, but he'd only done it in time to catch the last 20 such reports.

The reports had been about packages missing dependencies in the 'build-depends' field. Anthony suggested:

A useful way to have done these bugs would've been to:

  1. deal with Build-depends-indep (as pointed out by Julian)
  2. attempt to work out what the correct build-dependencies are, and include a sample Build-Depends: line along with an indication of whether this is enough (lib*-dev can be worked out from existing Depends: lines, eg)
  3. including a Version: field from the package being compiled, rather than what was installed on the system
  4. actually looking at the bugs logs (one of the blocked bug reports has a log that ends with "Sorry, gnat wasn't installed can't build"

There're probably other things that should've been done too, which would've been suggested *had this been brought up on -devel in the first place*.

These reports are no better than a lintian check saying "W: no-build-depends-line", which would probably be about as effective, and *much* less intrusive.

Paul Slootman also got spammed by these reports, and asked where to find the list of "build essential packages". There didn't seem to be an explanation of it in section 8.7 (http://www.debian.org/doc/packaging-manuals/packaging.html/ch-relationships.html#s8.7) of the Packaging Manual (http://www.debian.org/doc/packaging-manuals/packaging.html/) , which dealt with dependencies between source and binary packages.

Hamish Moffatt replied that the 'debhelper' package (probably needed by many of the packages listed in the spammed reports) had been made 'unessential' by recent policy decisions. As he put it, "The purists have deemed debhelper to be build-unessential. Using the same logic I feel that a C compiler is a luxury too, but I don't make those decisions." Antti-Juhani Kaijanaho replied, "Yes you do. If you feel that policy is broken, propose an amendment," and added, ""The purists" happen to be the readership of debian-policy from last year." Hamish replied that he just didn't see any logic in excluding 'debhelper'. Antti-Juhani made the case that 'debhelper' wasn't needed in order to build other packages, while something like 'gcc' was; and they (and others) went back and forth on the relative necessity of the two.

Close by, Richard Braakman said, "I don't know how the decision ended up being made, but the argument I presented at the time is that a dependency on debhelper is far more likely to be versioned than the others are. A package that makes use of a new feature of debhelper is going to have to declare its own build-depends anyway." Wichert Akkerman agreed wholeheartedly, but Steve Greenland objected, "It is not unreasonable to assume that the latest-and-greatest version of all the build-essential packages will be installed," so any version dependencies would require building a lot more than just the build-essential packages. Wichert replied, "I wonder what world you are living in. It is in reality a completely unreasonable assumption."

Steve said anyone running a build daemon would almost certainly keep uptodate build-essential packages on their system, but Manoj Srivastava replied, "build essential package is ot merrely for build daemaons. Therefore packages would need to specify the oldest version of the build package they can be built with (in the worst case, exactly the version they were built with), since not every machine they can be built on can be depended to ahve the altest version of the helper packages." [...] "I think that since every package using a helper package seems to need a versioned dependency, addign debhelper to build essential shall not remove the burden from the packages. And auto build daemons can also augment the build environment beyond build essential, as they already do." Wichert replied, "Right. In fact it makes things worse since people will just assume that their helper is already essential and they don't need to bother to to check if they need to specify a versioned dependency for it as well." But Anand Kumria said a bug should be filed about that, since the same thing was true for the 'dpkg-dev' package. Wichert replied, "dpkg-dev is an extremely stable interface, something you can not say for debhelper." But Joey Hess replied simply, "Prove it." He referred to an earlier post of his, where he'd said:

a quick peek at make's NEWS file finds that between the current version and version 3.78, about 7 changes have been made to make that, if used, could result in similar situations. For example:

I really don't see the difference, I really don't see any evidence that debhelper is more guilty of this type of change than make, or the C/C++ compilers, and so I really don't see where you're coming from.

More discussion followed in the various subthreads.

2. Changing The Default Shell

29 Aug 2000 - 6 Sep 2000 (31 posts) Archive Link: "/bin/ksh as a default POSIX shell"

Summary By Zack Brown

People: Sean PerryAnton IvanovHerbert XuManoj Srivastava

Piotr Roszatycki suggested making 'ksh' the default shell for init.d scripts, since it was smaller and faster than 'bash'. Someone suggested that 'ash' was also POSIX compliant, but Sean Perry pointed out that 'ash' was not actually 100% compliant. He added that 'pdksh' had the '-o' option for full POSIX compliance, and went on to say, "As for changing Debian's default, no. What these packages should do is offer to replace /bin/sh with a diversion when the package is installed. I submitted a wishlist bug on ash yesterday to do just this. If pdksh would move its binary into /bin, it could do the same thing." Herbert Xu added that 'ash' was actually more compliant than 'bash', because it could handle functions while 'bash' couldn't. Anton Ivanov pointed out that switching away from 'bash' would break a lot of scripts that used 'bash'isms. Sean and Perry both said they used 'ash' with no problem, and Anton relented, "OK, OK, OK, I surrender. I have to admit my experience was rather old and the quantity of bashisms have sharply decreased. So you can run another POSIX compliant shell happily for sh nowdays." Herbert also pointed out that in Debian, it was policy that all scripts using the '#!/bin/sh' construct, had to be POSIX compliant. Manoj Srivastava quoted the actual policy text (http://www.debian.org/doc/debian-policy/ch4.html#s-scripts) , which had additional conditions on which shell could be used.

3. License Dispute With University Of Washington

29 Aug 2000 - 5 Sep 2000 (34 posts) Archive Link: "Free Pine?"

Summary By Zack Brown

People: David StarnerRaul MillerRichard M. StallmanBranden RobinsonJoseph CarterHenning MakholmSteve GreenlandPeter S GalbraithSantiago VilaJuhapekka Tolvanen

Juhapekka Tolvanen found 'MANA', a fork off the last free version of 'pine', version 3.91; he gave a link to a page (http://home.sol.no/~egilk/mana.html) about it. This seemed to be the answer to the problem of 'pine' being a non-free package. Chris Allegretta posted a link to a mirrorred package (ftp://ftp.kvaleberg.com/pub/mana-4.0beta.tar.gz) as well, and Martin Jenssen gave a link to the official home page (http://www.kvaleberg.com/mana.html) . Santiago Vila thought it looked promising, and included an "intent to package" message, and added that he might orphan the non-free 'pine' if 'MANA' worked out.

David Starner posted the startling, "Whoa! Isn't this the program that RMS said the University of Washington threatened to sue them over?" Raul Miller replied:

I've an outstanding, unanswered question which I've sent to UW in a related context (IMAPD): what specific clause of the copyright is being violated, when modified versions are distributed.

I think that, until we get a decent answer, this should be the question asked by anyone who gets a threat under these conditions: ask what specific terms of the license are being violated.

Of course, if they can come up with a good answer to that question then we'd need to stop distributing modified versions, but until then this looks more like an author-relations issue than a legal issue.

Richard M. Stallman replied, "Their position was that the words "permission to copy, distribute and modify" do not grant permission to distribute a modified version. In other words, they say you can distribute the software, and you can modify the software, but you can't modify it and then distribute the result." He went on:

You may never get an answer from the U of W, because right now the U of W can achieve its goals by saying nothing. If they have the feeling that you will let the issue slide if they let it drop, they are likely to let it drop.

However, you now do have an answer to that question, so I hope you can proceed to take the appropriate action, and remove IMAPD from Main.

The message I forwarded you shows clearly that they treat IMAPD as non-free software, that their position is that people must ASK for permission to release a modified version, and that the license does not give permission. That message does not give all the details. It makes sense to want to know more about the situation, but it makes no sense to let the issue slide unless and until they give you a full explanation. That is not the way to make the DFSG something that the users can rely on.

If Debian decides to reject IMAPD and tells the U of W so, that will put some pressure on them to clarify the license. Otherwise they may prefer to leave it unclear in order to to "have it both ways".

Branden Robinson replied to Richard's description of the U of W's position, saying, "Then it must also be true that one cannot copy and then distribute, or distribute and then copy. Have you attempted to challenge them on this point? Do they have English professors at UWash, or just semioticians?" Richard replied, "I never thought of this argument. It could be a good point to raise in a lawsuit; it might help win the suit."

Raul Miller also replied to Richard, saying he didn't see anything in the language of the license to support the U of W's claim, and Richard replied, "I don't either--but that is not the point. The point is that the U of W has actually threatened to sue the FSF for distributing a modified version of a program that was released under the same words."

Joseph Carter also replied to Richard's initial post, treading with care, "I am comfortable speaking for the group at large when I say we appreciate your advice and input on this matter. I myself appreciate the ends you're trying to accomplish here. Nevertheless, the methods you're using to go about this cause me to question whether or not your means justify your ends." He went on to say, in response to Richard's description of the U of W's position, "If memory serves me, I do indeed recall reading a message forwarded to this effect. The issue I am seeing rests with those words, which Debian and indeed you yourself have accepted those words and at least half a dozen variations of them as free software. Someone at UW decided to tell you that the license didn't say what it said. Based on the language and your interpretations of that language in all contexts not related to software written by UW, I have to conclude that it is your belief that regardless of their stated position, the license itself is free (if perhaps not the clearest of wording...)" But to Richard's advocacy of rejecting IMAPD in order to put pressure on the U of W, Joseph replied:

And here we get into those means I do not feel justify the ends you're after. In order to force UW into the uncomfortable position of admitting that what you wanted to do with pine is acceptable or telling Debian and everyone else that UW imapd is non-free, you want Debian to take a position you do not yourself agree with for purely political reasons. And that's what these are---political reasons. There is no legal problem here. And there was no legal problem with pine 3.91 either, regardless of what they said at the time.

I feel you are attempting to manipulate Debian into fighting a political battle for you that may cost at least some of our users in the end. Call it taking a stand for freedom or whatever you like, but the software IS free according to our best interpretations (and according to the clarification we received from UW..) I don't see an issue that Debian needs to pursue here. There are enough license battles for Debian to fight as it is (I should know!) and we really don't need to look for another one over software that everyone agrees is already free.

Trying to get someone to do something by trying to make it sound like what you want is exactly what they want? That sounds more like ESR's fort? to me what with all of his jedi-robed Tear Down the (Redmond-based) System rhetoric and promises of dollar signs to anyone in a suit who pays homage to a silly little penguin logo. Freedom is only really freedom if you make a conscious choice to be free. Take that away and people quickly relapse into familiar patterns of accepting what they are given.

So while I respect your goals, I have a hard time respecting your position on this issue. If you had written a message in which you came right out and said what you thought, what they've said both then and now, and suggested we decide ourselves whether or not this was a battle we wanted to take up, I probably would have been far more impressed by your directness instead of annoyed with your careful words and I dare say FUD.

Steve Greenland pointed out that while the "clarification from U of W" did allow Debian to distribute modified versions of the software, it explicitly did not allow folks who received that software to distribute their own modified versions in turn. Branden agreed that the U of W's position failed the Debian Free Software Guidelines (DFSG), item 7 (http://www.debian.org/social_contract#guidelines) as found in the Debian Social Contract (http://www.debian.org/social_contract) . But Raul pointed out that Debian was not a legal entity, and so to allow it to distribute modified versions of a piece of software, was implicitly to allow anyone else to do so as well. He added that the Social Contract also drew no distinction between Debian and other people. He went on, "Trying to divide us up, by drawing a line where there isn't one, is very much against what we're about." Peter S Galbraith pointed out that the DFSG referred to a license not being specific to "Debian". How could it refer to Debian, he asked, if there was no Debian? Raul and Henning Makholm pointed out that there was a Debian, but it was a work, not a legal entity.

4. Where's The 'prc-tools' Package?

31 Aug 2000 - 2 Sep 2000 (9 posts) Subject: "Where's the prc-tools package?"

Summary By Benedikt Köhler

People: Brian AlmeidaMichael BeattieWichert AkkermanMichael MeskesStephen ZanderJohn Goerzen

Michael Meskes wanted to know why the prc-tools package hasn't been listed anymore in the Packages file anymore.

Brian Almeida answered that it is currently in frozen, but "dinstall has a bug where if it gets uploaded to frozen it gets removed from unstable... Someone just needs to re-uploaded a recompiled version for woody." . This remark reminded Michael Beattie that he "really* should get around to reviewing that patch I did, and apply it."

Wichert Akkerman replied to the original post and added that someone should NMU the prc-tools package and bring it up to date as the current version of this package is too old and cannot even compile PalmIII applications.

Then John Goerzen told Wichert to close some bugs he gave that package two years ago when he moved to alpha and he still gets bug reports for those bugs. Wichert asked John why he isn't maintaining the package on alpha right now, but John said that the package wouldn't build on alpha at that point of time.

Christopher Chimelis threw in that the package builds on alpha now, as someone had brought it up to date with a recent version of the gcc. And finally Stephen Zander closed the discussion saying that he hasn't had time to build a new version of the prc-tools for woody, but he will do it real soon.

5. KDE Coming To The Official Distribution

4 Sep 2000 (19 posts) Archive Link: "Qt going GPL ..."

Summary By Eusebio C Rufian-Zilbermann

People: Hugues MarilleauRichard BraakmanIvan E. Moore IIWichert Akkerman

This week several threads echoed Trolltech's announcement about the change in the licensing terms for the new Qt library. Developers now have the option of using the open-source version of Qt/Unix 2.2 under either the QPL (Q Public License) or GPL license, depending on their licensing requirements. The full text of the announcement is at http://www.trolltech.com/company/announce/generalpl.html (http://www.trolltech.com/company/announce/generalpl.html)

Hugues Marilleau expressed his concerns that this license is only applicable to the Unix version, "And what about Debian GNU/Hurd and Debian Win32 ? They are not Unix. (Linux is ?) and only Qt/Unix is GPL ? I think this is a good reason to *not* include KDE in Debian." To what Richard Braakman replied, "If there is a free version, the rest is a matter of porting. We have lots of unix-specific packages. I don't see a problem here." And Federico Di Gregorio expressed a similar opinion.

Hugues had mentioned KDE and people started looking for it. There was some initial confusion while the mirroring system propagated the KDE files and because of the location of the files until Ivan E. Moore clarified the details. "KDE2 is doing alot with ssl stuff...konqueror, kmail, etc...kdelibs builds against libssl so it's in non-US."

Jaldhar H. Vyas asked Ivan to produce a version without encryption restrictions and Ivan replied that he would start working on it. Wichert Akkerman offered some suggestions on how to best handle the linkages to the ssl libraries, "kdelibs will pull in the ssl libraries and ldd will report that. Provided that you link konqueror correctly (ie only to kdelibs and not to the ssl libs) that will be fixed once I upload dpkg 1.7.0 which has a dpkg-shlibdeps that uses objdump instead of ldd."

Ivan had to make some changes to KDE and the thread finished with comments from people still looking for the packages and other jovial comments.

6. Moving Ahead With QT

4 Sep 2000 (11 posts) Archive Link: "Qt2.2 released under the GPL"

Summary By Eusebio C Rufian-Zilbermann

People: Marcus BrinkmannJoseph CarterDaniel BurrowsDavid StarnerMichael Beattie

Another thread about the new licensing for Qt started with triumphant tones from happ "WE WON !" and Marcus Brinkmann added, "Everyone won :)"

Joseph Carter called for the next step in a different tone,

No, we didn't win. Neither did KDE. Troll Tech won this license war. It looks like the rest of us will benefit in the long run, but we didn't win. The majority of people involved with KDE still are convinced that they did nothing wrong in terms of law or ethics, people will still accuse them of a whole bunch of things they did and a bit they didn't, and everybody involved seems to hold negative opinions of someone because of how long this has gone on.

There's nothing to celebrate here. Just a company making a move that is, they hope, in their best interests having the side effect of fixing a handful of license quibbles which have caused flamewars the likes of which I couldn't even place on a CDR in compressed format. All of that isn't going away overnight. So what we really have is a single step. A big and important one - but still a step.

So do we prance around gloating over our "victory" or do we take the next step?

Daniel Burrows commented on a coincidence in the timing, "Does anyone else find it ironic that licq-plugin-gtk+ was finally installed into the archive today?" and Michael Beattie agreed that it was. David Starner explained that licq can still be useful regardless of the new Qt licensing "QT is 5 MB in memory, more than GTK + Glib + Gnome libs"

7. Qt Revelry

5 Sep 2000 - 6 Sep 2000 (6 posts) Archive Link: "QT-GPL"

Summary By Eusebio C Rufian-Zilbermann

People:

This short thread about the new licensing for Qt was mostly humoristic, related to the saying "when hell freezes over" (meaning: never, which is when KDE was expected to make it into Debian) with references to the story about the thermodynamic properties of hell. Querying a search engine for 'Therese Banyan endothermic hell' should provide many links to the story. (example) (http://search.excite.com/search.gw?search=+Therese+Banyan+hell+endothermic)

8. KDE Officially Added To Debian

5 Sep 2000 - 6 Sep 2000 (6 posts) Archive Link: "ITP or rather upload... KDE"

Summary By Eusebio C Rufian-Zilbermann

People: Joseph CarterIvan E. Moore IIBernhard R. Link

Following Issue #2, Section #5  (4 Sep 2000: KDE Coming To The Official Distribution) Ivan E. Moore indicated that the unofficial KDE packages that he has been maintaining would now be merged into main. Joseph Carter suggested Ivan to keep both the official and the unofficial packages. "I suggest you DON'T do away with kde.tdyc.com ... You have the infrastructure in place already, use it as a repository for latest KDE and people can just list it after the debian lines in their sources.list if they want more bleeding edge stuff durring freezes and for releases." Ivan agreed " good point...plus the potato packages will still be desired."

Bernhard R. Link warned that some licensing issues might still be lingering "Be carefull, according to http://developer.kde.org/documentation/licensing/licensing.html some parts of kdenetwork are still licenced qpl." Ivan had a quick check and replied "not according to the source code. I see GPL, LGPL, and Artistic. But I plan on doing yet another sweep of all the source, readme's, etc...prior to build and upload."

 

 

 

 

 

 

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.