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.
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.
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
#50000: Nov 1999 #60000: 09 Mar 2000 #70000: 26 Aug 2000 #80000: 19 Dec 2000 #90000: Mar 2001I 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
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.
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.
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.