Debian Traffic #28 For 28 Mar 2001

Editor: Zack Brown

By Prashanth Mundkur

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 952 posts in 3012K.

There were 335 different contributors. 167 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Crypto In Debian/main And Uploads To Non-US

5 Mar 2001 - 12 Mar 2001 (8 posts) Archive Link: "US Maintainer Putting Package on non-US"

Summary By Prashanth Mundkur

People: Brian RistucciaNoah L. MeyerhansEvan ProdromouSam Hartman

Freenet maintainer Evan Prodromou wanted to know whether it was ok with Debian policy to upload crypto-containing Freenet to a non-US server as a US citizen, or non-US uploads had to be done by non-US maintainers.

Sam Hartman and Brian Ristuccia replied it was ok, provided " It is, provided you mail a copy of the software or the public address where you will be posting it to crypt@bxa.doc.gov before you upload. "

Noah L. Meyerhans cautioned on the effects on the distribution of future changes in the laws: " Groups like FreeS/WAN and OpenBSD still don't allow crypto development by U.S. citizens. I don't necessarily propose that Debian takes such a stance, but I *really* don't think it's a good idea to allow crypto in main. If the government policy does change after we've integrated crypto with main then we've got a big mess to deal with and it will take a lot of work to get things back to a legal state. "

2. Welcoming Bug #100000

14 Mar 2001 - 21 Mar 2001 (16 posts) Archive Link: "First Post!"

Summary By Prashanth Mundkur

People: zhaowayCarlos LaviolaJoey HessJordi Mallach Chad Miller

Zhaoway wondered inquiringly in a thread, "Who will get Bug#100000? It's coming!" When Carlos Laviola very optimistically hoped "The problem is that it will take at least a year and a half for people to file 10 thousand bugs" , Joey Hess, fresh from his voyages into the Debian Bug Archive, posted his usual statistics post:

#50000:     Nov 1999
#60000:  09 Mar 2000
#70000:  26 Aug 2000
#80000:  19 Dec 2000
#90000:     Mar 2001

I predict that #100000 will be filed on May 15th. Shall we start a pool? :-)

Jordi Mallach requested "File it against one of my packages, as a birthday present :)" Chad Miller contributed "Ya bunch of base-10 bigots!:)"

For recent BTS coverage, see Issue #27, Section #4  (8 Mar 2001: Archiving Historical Bug Reports) .

(ed. [] Thanks to Marko Schulz for sending in this link.)

3. All Your Apt UIs Are Belong To Deity

18 Mar 2001 - 19 Mar 2001 (3 posts) Archive Link: "All your apt UIs are belong to deity"

Summary By Prashanth Mundkur

People: Patrick Cole

Patrick Cole announced

Just a quick note to let everyone know that the new previously and currently in-the-works apt interface suite, deity, is now available for testing in unstable. (testing in unstable? seems like a bit of a contradiction .. :)

In any case, the aim of deity was to take the base of capt and create a new improved modularised system in which we could build multiple user interfaces on top of, such as curses, gtk, and perhaps framebuffer soon. Another aim I guess, to put it into debianplanet's words, would be: "to replace the broken console-apt and gnome-apt frontends".

Some improvements include better filters, multiple screens, real expandable tree representations of packages, customizable colors, threaded package acquisition, amongst other things. Currently the two UIs available are Gtk and Curses.

4. Building From Source

19 Mar 2001 - 20 Mar 2001 (3 posts) Archive Link: "apt-get source"

Summary By Prashanth Mundkur

People: Charles FarleyMatt ZimmermanPaul Slootman

Charles Farley asked a few questions on building packages from source. His goal was to build basic packages specifically for his i686 architecture, and used export CFLAGS='-march=i686 during compilation. But "I noticed that dpkg-architecture prints out i386 for everyhting. Will this over-ride my export settings and compile, for instance, glibc for a lesser arch?[...]How do you compile a package for your specific arch in debian, and still maintain it in dpkg package management? "

Matt Zimmerman replied "The short answer is that dpkg-architecture doesn't figure into it unless you're trying to cross-compile. dpkg-architecture, as its manpage states, is reporting the Debian architecture string, not the compiler's target architecture. You are doing the correct thing by setting CFLAGS."

In a later thread, Charles noticed that apt-get would persist in downloading the packages he had just custom compiled, even though they had the same version number. "Of course I can just place those packages on hold, but I was wondering as to the "why". Why does apt want to grab the official packages even though mine have been built in the exact same manner?" Paul Slootman replied "Because your .debs have a different checksum to the official ones. However, if you had simply installed your debs with dpkg -i instead of relying on apt-get, apt would have only considered the version numbers, and have seen that you already have the latest version."

5. Mixing And Matching Ximian And Debian GNOME

21 Mar 2001 - 24 Mar 2001 (20 posts) Archive Link: "nautilus1.0 in woody..."

Summary By Prashanth Mundkur

People: Aubin PaulPeter Teichman

Numerous people reported problems mixing Ximian/Helix packages and their Debian counterparts. In response to Jan-Hendrik Palic's experiences with an unsuccessful nautilus install on a woody system, Federico Di Gregorio posted: " ximian and debian packages are not only "substantially different" but also incompatible at binary level. some days ago, after upgrading to nautilus 1.0 in sid and while having still 8-10 ximian gnome packages (some libraries, bonobo, etc.) nothing worked (nautilus crashed.) i purged my installation from *any* package with helix or ximian in it version string and replaced with packages from sid (this is difficult because ximian varsion is almost always >> than debian one, <g>) and everything worked again. binary incompatibilities, qed. "

Peter Teichman, a maintainer of the Ximian versions of the Debian packages, replied that " We can no longer claim to support Debian unstable with Ximian GNOME, since unstable is changing a bit too fast underneath us. If there are problems with testing or stable, though, I'd really appreciate it if people would submit bug reports to bugzilla.ximian.com."

Aubin Paul suggested to Peter : "By no means are we not happy with the work you guys have done on the packages, but there are versioning problems. What would be great, would be if Ximian could adopt the /debian stuff from the Debian packages, as they split up the files appropriately, and are lintian clean. By the way, being lintian clean is not just us being anal, it provides a lot of benefits behind the scenes. [...] What would be best though, is if dependencies were reasonable... why is gnome-libs (>=1.3.11ximian) incompatible with gnome-libs (>=1.3.11) It's frustrating that installing a deb of red-carpet will clobber most of your packages. "

Elsewhere, Bradley Bell took up the task of packaging Ximian's Red Carpet application updater.

 

 

 

 

 

 

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.