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 #20 For 25 Jan 2000

Editor: Zack Brown

By Prashanth MundkurSteve 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 Authorship page the KC Debian homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.

1. Education Section

13 Jan 2001 - 15 Jan 2001 (12 posts) Archive Link: "Re: menu-policy: education"

Summary By Zack Brown

People: Ben Armstrong

Continuing the discussion covered first in Issue #17, Section #1  (14 Dec 2000: Adding A New Package Category: Education) , Ben Armstrong asked if anyone would take up the challenge and bring the possibility of a new 'Education' section, to the debian-policy mailing list. He himself had too much on his hands to do it, though he supported the idea. Vladimir Tamara asked if he'd be allowed to spearhead the charge, since he did not maintain any actual Debian packages. Ben implied that Vladimir could do it, though he suggested boning up on the policy manual and the menu-policy documents, as well as the policy-process document. He admonished, "The addition of an "education" section in the package archives is a separate issue and should therefore be pursued separately from the education menu section policy." Someone asked where the education menu section policy should be brought up, and Ben explained:

The only mention of subsections in the Debian policy manual is section 2.1.7. It does not dictate what the sections should be. It simply says that they exist and that you should check the current distribution to see what sections are available. However, sections don't actually exist in the archives now that we have package pools, so now it seems subsections should be a policy thing.

So ... that being the case, we need to step back from the education section for a minute and make a proposal that there be a sub-policy for sections much as there is a sub-policy for menu structure. Once there is such a policy, we can talk about adding the education section to that sub-policy.

Anyway, I think it will be easier to argue for a "Section: archives" once the education menu is populated with packages. Until then, we can relax a bit about the lack of a section policy. :)

The person who'd asked about it, thought this was a bit overly bureaucratic, and Ben replied:

It's much simpler than I put it:

  1. old method: approach archive maintainer and they'll add a new section if they think it's appropriate
  2. new method: ??? there is no new method because the archive doesn't have sections anymore

All I'm saying is since there's no new method, someone is gonna have to *devise* a new method. I have been told that it should just be a matter of adding a policy. This isn't just red tape, the policy document would tell a developer "here are the sections you should add your package to, and roughly what belongs in each" much as we now have a menu sub-policy.

You can't just "check the current release to see what sections are in it" as the policy manual says, because if you look at the new package pools arrangement, the sections simply are not there.

2. Debian Forgets Maintainers

13 Jan 2001 - 18 Jan 2001 (6 posts) Archive Link: "the (unknown) maintainer in the BTS"

Summary By Steve Robbins

People: Douglas BatesColin WatsonJosip RodinAnthony TownsJordi Mallach

Douglas Bates noticed that " the list of bugs by package shows most packages as being maintained by (unknown). Does anyone know what's up? " Jordi Mallach reported that he was closing some of these bugs, but the BTS wasn't responding to his emails. This alarmed Colin Watson " Er, since it seems that the BTS has forgotten who maintains most packages, please don't close anything just because it's maintained by (unknown) just yet :) "

Josip Rodin solved the mystery:

Yes, we had a problem with charisma, the script that makes the Maintainers file; when the Maintainers file is broken, the BTS doesn't process its incoming spool directory. The people at owner@bugs weren't watching their mail closely (I for one had my MX record fucked up so some sixty owner@bugs mails were deferred -- there's a Murphy's law :) and the situation extended for several hours. So, there were more than 300 items held up in the spool, and they were processed once Anthony Towns had fixed the Maintainers file.

Note that some of those were old messages that were stuck there for unrelated reasons, and that caused a couple of extra actions (old reassigns repeated, a couple of new bugs reported). Hopefully nothing serious happened because of this, although this may have caused those empty bug logs (which causes the CGI to print that opaque error message).

3. Standard Trouble With GCC 2.95

14 Jan 2001 (5 posts) Archive Link: "g++, namespace std and STL"

Summary By Steve Robbins

People: Chris LeishmanMark BrownMariusz PrzygodzkMariusz Przygodzki

Chris Leishman asks for help with the C++ Standard Template Library:

Hopefully someone can set me straight on this one...

However, you can make g++ do "the right thing" by providing -fhonor-std on the compile line. However then binaries fail to link because the symbols in the libstdc++-* libraries do NOT contain the std:: component, and thus do not resolve. (Eg. std::terminate)

Why is the library compiled in this way?

Mark Brown opined that " A lot of these things come down to the C++ standard being fairly new and GCC 2.95.2 being fairly old. At the time few if any compilers would have had complete support for the standard, G++ being no exception. Current GCC (which is starting to move towards a 3.0 release) is much more standards conformant, particularly WRT the standard library. "

Mariusz Przygodzki suggested the STLport library as an alternative to SGI's STL. It is already in woody, and " includes full implementation of current SGI STL (with new SGI iostreams optionally). And it works with GCC 2.95.2. "

4. Contrib Or Not Contrib?

15 Jan 2001 - 17 Jan 2001 (38 posts) Archive Link: "Snes9x and Quake in main"

Summary By Steve Robbins

People: Eric Gillespie, Jr.Joe DrewHamish MoffattJoey HessJoseph CarterSean 'Shaleh' PerrySteve Robbins

Debian is an organization that takes software licences seriously. Very, very seriously...

Eric Gillespie, Jr. wondered why the Snes9x and Quake packages were in the "contrib" section of the archive, rather than in "main". " According to policy, sections 2.1.2 - 2.1.4, a package goes in non-free if it isn't DFSG free and in contrib if it depends on a non-free package. Both snes9x and Quake are DFSG free, and neither depend on non-free packages. Therefore, both should be in main. The point has been raised that neither of these packages are useful without non-free software. Even if this were true, policy says nothing about this, and i don't think it should. However, it isn't true. There are free data sets for Quake, and free ROMs for snes9x. "

Joey Hess quickly pointed out that Debian policy also relegates a package to "contrib" if it requires packages which are not in our archive at all. While there are currently no Quake datasets nor snes9x ROMs in Debian, Eric pointed to the DFSG free Quake data set OpenQuartz exists, and continued " Packaging this may be a good idea, but the existence (or not) of free data for Quake is irrelevant. It could be useful to install Quake and start developing free data for it. Forcing me to add contrib to my sources.list to develop DFSG-free data for a DFSG-free game is silly. " Silly, or not, the consensus emerged that Quake will remain in "contrib" until a DFSG free data pak is packaged, at which point it may be moved to "main". Both Eric and Joseph Carter offered to package OpenQuartz.

(ed. [Steve Robbins] I see that Joseph eventually did, and OpenQuartz is now in unstable. )

Eric did submit a bug report asking that both Quake and snex9x be moved to "main". In response, Sean 'Shaleh' Perry pointed out that the snes9x license is not, in fact, DFSG free. So snes9x is never going to be in "main", in any case. Eric submitted a second bug report asking that Quake be moved.

Elsewhere, Joe Drew mentioned that lxdoom is in the same boat. " When I first packaged lxdoom, we talked about putting it in main, but it eventually went to contrib because of a lack of free WAD files. Has this situation changed? If so, lxdoom and prboom could both move to main. " No-one stepped forward with a WAD file.

On the other hand, Hamish Moffatt pointed out an example of the opposite problem, a package in "main" that ought to be in "contrib": " x48 requires user-supplied ROMs, as distributing the ROMs is illegal (they are copyright Hewlett-Packard and not public domain or DFSG-compliant). Therefore x48 belongs in contrib. And I just submitted a bug. "

In the course of arguing for the current policy on "contrib" packages, Joey Hess had this to say:

If you want to understand policy, you really need to look at what we were thinking when we wrote it.

Contrib has historically been a dumping ground for software that wasn't good enough for main. That software might have been very buggy[1], or it might require software that was not on your debian media (because the software was in non-free) to be of any use. Or it might require software that is not available at all unless you rip it directly from the ROM of a game (or download it from a shady ftp site). Or it might just require software you have to get up onto the net and go download. Any of these reasons mean that the software in contrib is annoying to deal with and get working, for one reason or another.

So it was useful to seperate that software out, not for reasons of purity of licenses -- that was not such a big issue in the pree-DFSG-days when contrib was introduced -- but so users could choose not to see it. A better definition of the historical use of contrib might be: "software that is not usable without additional work on the part of the user"

If you apply this definition to Ben's example of a new programming language compiler, the new programming language's compiler is clearly useful right out of the box, if you know or are learning the language. It exists to compile code; code for it to compile need not be available if you can write some. (Just as a free unix system is usable out of the box if you know or are learning unix...)

Aaron's attempt at reductio ad absurdum falls on its face because, whether the BIOS of a computer is software or not, whether it matters if it is free or not[2], if you are using Debian you have one and you not have to do any work to go get one.

I think this is a very pragmatic way to to look at contrib. It's probably pretty much what the original meaning of contrib was (I'd appreciate it if an oldertimer could speak up).

[1] This was one valid reason to put stuff in contrib until 1999.
[2] I'm not interested in debating either question right now.

5. Two Concurrent Package Versions

15 Jan 2001 - 16 Jan 2001 (15 posts) Archive Link: "Two versions in the archives"

Summary By Prashanth Mundkur

People: David StarnerAdrian BunkPaul SlootmanJulian Gilbey

Peeved with the wreckage in the latest version of one of his favorite editors (yudit), David Starner asked whether it was possible to retain the earlier non-broken version: "What is the general rule of thumb on having more than one version of a program in Debian?" Adrian Bunk pointed out " We have already examples of two different versions of a program packaged, e.g. xemacs20 and xemacs21 or fvwm1 and fvwm."

In the case of fvwm, Paul Slootman recollected, ""fwvm" was version 1 and "fwvm2" was version 2. Once fvwm version 2 became stable enough, fwvm version 1 became "fvwm1" and fvwm version 2 became "fvwm", resulting in people with "fvwm" installed automatically upgrading." Adrian objected, " But if you manually upgraded fvwm -> fvwm2 there was no automatic upgrade fvwm2 -> fvwm after fvwm version 2 became "fvwm". :-(" Paul clarified, "fvwm has "Replaces: fvwm2 (<< 2.2)", so when fvwm2 disappeared, dselect should have handled this just fine" . Julian Gilbey also pointed out that the fvwm2 in potato has "Depends: fvwm (>> 2.2)" .

6. Debian On IA-64

17 Jan 2001 (1 post) Archive Link: "Debian on IA-64"

Summary By Prashanth Mundkur

People: Bdale GarbeeBrendan O'DeaBen CollinsRandolph Chung

Bdale Garbee announced that Debian was alive and well on the IA-64!

I am pleased to report that the IA-64 system on loan from HP to Agilent that is in my possession is now happily running Debian GNU/Linux natively. This machine arrived in my hands a few weeks ago "for evaluation" without an operating system loaded, and since what I wanted to evaluate was Debian...

This would have been much harder without the help I received from Randolph Chung. He offered encouragement as I struggled to get a working combination of hardware and BIOS version, crafted the chroot environment on top of TurboLinux that we used to do the bootstrapping work, then helped build some of the packages I got frustrated with.

I would also like to recognize Ben Collins and Brendan O'Dea for being on IRC at the right times to help me get past my struggles building glibc and perl packages, respectively. Their patience and enthusiasm helped!

The current status is that I'm booting a 100% Debian root filesystem, and am finishing up getting the right pieces in place to "start over" building packages that are fit for upload. I have requested a binary-ia64 tree be created, and expect that to happen soon. Package uploads should begin within the next week. It seems completely possible that IA-64 could join the set of supported ports for woody, but a lot of work remains between now and then!

 

 

 

 

 

 

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.