Bug#277437: ITP: fbmuck6 -- Fuzzball MUCK (version 6)
Package: wnpp Version: N/A; reported 2004-10-19 Severity: wishlist * Package name: fbmuck6 Version: 6.01 Upstream Author: Fuzzball MUCK Developer Team URL: http://sourceforge.net/projects/fbmuck * License: GPL Description: Fuzzball MUCK (version 6) Fuzzball MUCK is currently the most popular flavor of TinyMUCK server, providing a rich and complex virtual world server environment, along with all of the following features: . * Support for both encrypted (SSL) and unencrypted client connections * Support for MCP (the MUD Client Protocol) version 2.1 * more as I figure out what's worth pointing out Note that there will also probably be a data package of MUF program code from the same source, but a different binary package. -- Joel Baker [EMAIL PROTECTED],''`. : :' : `. `' `- signature.asc Description: Digital signature
Bug#276096: Oops, failed to Cc the ITA bug correctly
[ Failed to Cc the ITA bug correctly the first time around ] Just saw the notice that Eclipse had been orphaned, on the Debian Weekly News; I also see that Joerg Wendland has suggested a pkg-eclipse setup and co-maint. I'm willing to help co-maint it, as well; I use Eclipse 3 pretty much daily at work (albeit, an evil Windows version, because I work for a company large enough to qualify as $Lesser_Evil), and I'd like to see it stay in Debian, since I sometimes use it at home for personal things. -- Joel Baker [EMAIL PROTECTED],''`. : :' : `. `' `- signature.asc Description: Digital signature
Bug#266777: Oops
I appear to be an idiot; I forgot to fill out some of the fields in the ITP. The missing fields for this ITP should read as follows: Upstream Author: Ivo van der Wijk, Amaze Internet Services URL: http://www.zope.org/Members/ivo/QuotaFolder/ License: BSD -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- pgpSHLmsp9tRw.pgp Description: PGP signature
Bug#220212: Follow-up
Just wanting to follow up on this ITP; since I need ZStyleSheet for some work I am doing, and I am packaging other Zope products at the same time, I would like to know if it is still in progress, what it's status is, when you think you might have it ready, etc. Mostly, if that's immediately, I won't bother building my own; if it's not for a while yet, I'll just build a package and replace it later, and if it's I've lost interest, I'll take over the ITP and package it. Not trying to duplicate work needlessly; I just have some paying customers who need this as a Debian package, so I need to make it happen in one of the three above ways, in fairly short order. -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- pgp1KypmSTRA1.pgp Description: PGP signature
Bug#266777: ITP: zope-quotafolder -- Folder-based quota system for Zope
Package: wnpp Version: N/A; reported 2004-08-18 Severity: wishlist * Package name: zope-quotafolder Version: 0.1.1 Upstream Author: * URL: * License: Description: folder-based quota system for Zope Provides a folder-ish Zope object which can enforce restrictions on objects stored within it, including objects stored in sub-folders. . Restrictions can control the total number of objects, the maximum size of any single object, and the total size of all objects together. -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- pgp6L2WXJzWU2.pgp Description: PGP signature
Bug#265974: ITP: tf5 -- TinyFugue 5
Package: wnpp Version: N/A; reported 2004-08-15 Severity: wishlist * Package name: tf5 Version: 5.0 beta 6 Upstream Author: Ken Keys [EMAIL PROTECTED] * URL: http://tf.tcp.com/ * License: GPL-2 (primary), PCRE w/ GPL override (PCRE lib) Description: text-based MU* client TinyFugue is a text-based, line-based client designed for connecting to MU* servers of most flavors (TinyMUSH, TinyMUX, LP, Diku, etc.), and includes support for MCCP versions 1 and 2, SSL encryption, and a host of other features. . This package is the current development version of TinyFugue (major version 5); for the current stable version (major version 4), please see the 'tf' package instead. Note for reviewers: this has been discussed with both of the prior maintainers of tf, and has their blessing; tf4 and tf5 are different enough that they warrant multiple major versions in the archive (among other things, the user interface and scripting language have changed completely between version 4 and version 5; old scripts almost certainly have to be rewritten, and users have to relearn many of the primary interactions). -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- pgpa40J8mJcNa.pgp Description: PGP signature
Bug#204969: ITP: package-pool-helper -- Simple scripts to manage a local package pool
On Wed, Aug 20, 2003 at 09:52:08AM +0200, Marc Haber wrote:
On Wed, Aug 13, 2003 at 01:37:00PM +0100, James Troup wrote:
Martin Michlmayr [EMAIL PROTECTED] writes:
* Marc Haber [EMAIL PROTECTED] [2003-08-13 07:58]:
I'm glad that we have so much manpower that we can use it on endlessly
reinventing this wheel.
Please point me to the other instances of this wheel.
Package: mini-dinstall
And debpool (#200654)
This is not yet in the archive, and not even published. A bad case of
duplicated effort indeed, but the main work related to
package-pool-helper is already done.
Though I'd call debpool 90% done. I got distracted from finishing it by
NetBSD license stuff suddenly becoming active again; what remains is
touch-ups rather than crucial pieces.
Joel, may I ask to see a preliminary version of your package to see if
your package can do what package-pool-helper can do and whether my
functionality can be added to your package?
Certainly. I just ran dpkg-source over the existing setup; you can grab it
at:
http://users.lightbearer.com/lucifer/debian/debpool_0.1.0.{dsc,tar.gz}
Note that this is in the exact state of my working space at the moment, so
it isn't guaranteed to actually be a clean package (all the code should be
clean, but I don't remember if I finished debian/rules, and the TODO file
lists things remaining).
The two big things that I can think might matter (apart from, of course,
handling pools) are the ability to generate Release files, and to use GnuPG
to verify signed changes/dsc files, or sign Release files. (Verification
of actual in-package signatures by debsig-verify doesn't work yet; it's an
eventual goal, but not for the first release).
and debarchiver
Doesn't seem to handle package pools.
It doesn't, nor is it easy to patch, or I'd never have started debpool. :)
and nihkatienumber345, etc. ad nauseam.
How very helpful of you.
Fact is that whenever I mention my package pool scripts in a lecture
or in a developer's meeting, I keep getting requests for the scripts
since there is nothing like that in Debian yet. Either the existing
packages are hard to find, or they are missing some features (maybe
non-dependency on python, or simplicity) that my scripts have.
Experience says that the fact that the file controlling package foo
goes into distribution bar is in the very same directory with the foo
package files makes pool management extremely easy.
H. Debpool manages version information by using tied hashes, and puts
the changes files into an 'installed' directory; perhaps this should
be reconsidered. In any case, look at the code; it sounds like the two
packages might actually (unlike debarchiver or mini-dinstall) be close
enough to overlap significantly, and possibly be merged.
Followup should probably should drop all the other Cc's on it, unless any
of them are crucially interest int he details for some reason. :)
--
Joel Baker [EMAIL PROTECTED],''`.
Debian GNU NetBSD/i386 porter: :' :
`. `'
`-
pgpnRAGaSsgm3.pgp
Description: PGP signature
Bug#200654: ITP: debpool -- pool-based DEB package archiver
On Fri, Jul 11, 2003 at 12:22:46PM -0400, Colin Walters wrote: On Thu, 2003-07-10 at 15:53, Joel Baker wrote: The problem is that it's written in python, which build-depends on emacs, which build-depends on Surely you can just remove the emacs Build-Depends temporarily in order to get a working python? Frankly, I have no idea if that would work or not - I tend to believe a packager when they declare a build-dependancy. In any case, if I desperately needed python, I'd be more inclined to copy over the native version from the other side of the box in question, right now (emacs is far from the only missing build-depend, just the most obviously complex one). The point being that, after well over six months of porting, the NetBSD port is not yet at a point where we could, in any meaningful sense, try to build enough to support mini-dinstall's basic requirements. I'm not trying to claim this would resolve all the worlds problems, but it's fairly clear to me that *some* tool which can run on a system with the barest of bones is useful to at least a few people (given the number who have replied, but not CC'ed the bug, saying Please let me have it! - not a cast of thousands, but more than one or two). Conversely, I had a natively compiled and packaged dpkg, bash, perl, and coreutils within the first few weeks (modulo some ugly hacks to make ncurses compile, given the quirks of NetBSD's wide character support). A side benefit (at least to me) is that it is probably relatively easy to run it on a non-Debian system, since (so far) the only Debian-specific tool is dpkg. -- Joel Baker [EMAIL PROTECTED] pgpbgMBhW8bm1.pgp Description: PGP signature
Bug#200654: ITP: debpool -- pool-based DEB package archiver
In the hopes that it will be illuminating, I have attached a copy of the README.Why file from my working copy of debpool. -- Joel Baker [EMAIL PROTECTED] Why have yet another Debian package repository tool? * Most or all of the other tools require extensive non-core support. While many users may not find this problematic, those working on a new port, and trying to make it self-hosting, will often have a difficult time trying to get some of the more packages with a complex tree of Build-Dependancies (such as Python) to a point where they can be compiled. Conversely, a working shell, an installation of Perl, and a compiler are some of the first things that must be present, simply because so much of the rest of the system depends on these (and they are often available from another port or a non-Debian system). Therefore, I have attempted to keep the requirements for packages not found in the Debian core system (Essential packages, or those with Priority required) to an absolute minimum (ideally, 'none'), or at the very least, only require packages that can easily be compiled on a system with little more than a shell, perl, and a working C compiler. Note that some amount of significant functionality (such as Release files and signature checking) does depend on more complex packages (such as GnuPG or the perl Digest modules), which is why these are in the Recommends field; however, these functions that use these are niceties (if very useful ones), and an archive can operate without them, if necessary. * No other tool handles the new pool-style layout readily. As of this writing, none of the tools in Debian except for katie (part of the softare used to run the primary Debian archives) can handle a pool-style directory layout in any straightforward fashion, while setting up a full instance of katie requires significant support infrastructure (such as an SQL server, among other things). pgpcOnQm9FRPR.pgp Description: PGP signature
Bug#200654: ITP: debpool -- pool-based DEB package archiver
On Thu, Jul 10, 2003 at 03:14:37PM -0400, Colin Walters wrote:
On Wed, 2003-07-09 at 14:55, Joel Baker wrote:
DebPool is a pool-based DEB
s/DEB/Debian/ ?
Hmmm. I'd been hesitant to say it that way, but on reflection, I think
it's actually *more* accurate - since debpool will handle changes, dsc,
{orig.,}tar.gz, diff.gz, and deb.
package archiver designed with a goal of
removing any dependancy on code not shipped as part of the core Debian
system.
By core here do you mean priority = standard?
Yes. Better ways of expression that in short form welcomed. In some
sene, it even goes beyond that; theoretically, right now you can run it
with a subset of the things that are required to build most packages
(coreutils, dpkg, perl, and a shell - no gcc required).
It is capable of all of the following:
* Tracking multiple distributions (however, it does *not* include
unstable - testing promotion scripts).
* Generating Release files (requires libdigest-{md5,sha1}-perl)
* Verifying package signatures (requires gnupg).
* Signing release files (requires Release files and gnupg).
* Running in single-pass or daemon modes.
DebPool is intended to be a lightweight replacement for the full Debian
archival scripts, in the tradition of debarchive and mini-dinstall, but
using a pool layout
How are you implementing this? Do you have some sort of database about
which packages are in which distributions?
Tied hashes, at the moment (because they come with perl's core setup).
and avoiding external dependancies.
This seems like an unfortunate reason to write a whole new program. If
the problem is mini-dinstall's dependency on python-logging, I could
probably suck it into the package. In any case it'll be standard in
Python 2.3 which is why I've been lazy about doing it.
The problem is that it's written in python, which build-depends on emacs,
which build-depends on eventually, you have something like a few dozen
packages to get working, before it will successfully run. I mentioned to
Joey Hess (who also raised this question) that there are more details in
the README.Why file, but this is targeted, in part, at solving the problem
I have as a porter wanting a self-hosting port.
mini-dinstall is capable, but hard to bootstrap to the point it can do it's
job; debarchiver is simple, but hard to patch and doesn't support a lot of
things.
Thus, the focus on making it run not only in a fresh install before any
other packages are put in, but on making it run with only the tools that
one more or less has to copy in from elsewhere to build *any* Debian
package.
Since both of the major questions have come on this set of topics, I'm
going to send a copy of the README.Why file to the bug, so that people can
see what it (currently) says.
--
Joel Baker [EMAIL PROTECTED]
pgppeYKyB3Vua.pgp
Description: PGP signature
Bug#200654: ITP: debpool -- pool-based DEB package archiver
Package: wnpp
Version: unavailable; reported 2003-07-09
Severity: wishlist
* Package name: debpool
* Version: 0.1.0
Upstream Author: Joel Baker [EMAIL PROTECTED]
* URL: N/A
License: BSD
Description: pool-based DEB package archiver
DebPool is a pool-based DEB package archiver designed with a goal of
removing any dependancy on code not shipped as part of the core Debian
system.
It is capable of all of the following:
* Tracking multiple distributions (however, it does *not* include
unstable - testing promotion scripts).
* Generating Release files (requires libdigest-{md5,sha1}-perl)
* Verifying package signatures (requires gnupg).
* Signing release files (requires Release files and gnupg).
* Running in single-pass or daemon modes.
DebPool is intended to be a lightweight replacement for the full Debian
archival scripts, in the tradition of debarchive and mini-dinstall, but
using a pool layout and avoiding external dependancies.
--
Joel Baker [EMAIL PROTECTED]
pgpDy1AvgkzO8.pgp
Description: PGP signature
Bug#200654: ITP: debpool -- pool-based DEB package archiver
On Wed, Jul 09, 2003 at 03:54:09PM -0400, Joey Hess wrote:
Joel Baker wrote:
DebPool is a pool-based DEB package archiver designed with a goal of
removing any dependancy on code not shipped as part of the core Debian
system.
It is capable of all of the following:
* Tracking multiple distributions (however, it does *not* include
unstable - testing promotion scripts).
* Generating Release files (requires libdigest-{md5,sha1}-perl)
* Verifying package signatures (requires gnupg).
* Signing release files (requires Release files and gnupg).
* Running in single-pass or daemon modes.
DebPool is intended to be a lightweight replacement for the full Debian
archival scripts, in the tradition of debarchive and mini-dinstall, but
using a pool layout and avoiding external dependancies.
If you have so many files in the archive that you need a whole hashed
directory tree to hold them (pool, right?), why do external deps matter?
Surely the extra disk space would be negligible.
In this particular case, which I document better in the README.Why file
I intend to put in the package, it is because I have exactly the
situation. It's not *common*, but no tool currently handles it at all
well.
'The situation' being a new port which is bootstrapping from the ground up
('netbsd-i386', in my case). I currently have hundreds of packages in the
archive, many of them rolling through as I try to track unstable and update
core things every week or two (when stuff is going well), and intend to
have an autobuilder in the relatively near future - but I have not yet been
able to untangle the dependancy tree of mini-dinstall (python Build-Depends
on Emacs, and let me tell you how fun THAT is to try to get working on a
new port...), and debarchiver is, frankly, just not up to the task (though
it's what I've been using, to date).
It isn't about disk space, but about the design view that requiring
heavy-weight, non-trivial packages outside the Debian core is not always
a good thing. Right now, it should, in theory, run with little more than
dpkg, perl, bash, and coreutils installed - less than it takes to build
most packages on a new port.
Sometimes I wish we could have one thing that worked well, instead of 4
that work kinda ok. In this case, I would like to have Release file
generation and package signatures[1], but I also want a flat structure
and would prefer to see these features added to something that already
works.
Agreed. I strongly considered the alternatives before doing this; I
even talked to Ola about debarchiver and pools, but the wishlist bug has
been open for a long while, now, and every time I look at the code to
try to patch in the capability for pools, I start twitching.
That's completely aside from the question of Release files or signatures
(which mini-dinstall does just fine, AFAIK, but as noted above, it's
impossible to build enough infrastructure to run it until a long way
into the porting process). To me, being able to self-host an archive for
a new port is a big deal, especially given the (perfectly rational and
reasonable) attitude of ftpmaster thta they want to see some fairly large
amount of porting done *before* they consider putting in a new area in the
main archive.
NIH?
Perhaps, but I've tried to avoid it. If there is, in fact, something which
requires few non-core packages, and does pools, I'd consider it even if
Release files had to be generated by a secondary script; that isn't that
hard to do.
--
Joel Baker [EMAIL PROTECTED]
pgpAQBmC3YeA7.pgp
Description: PGP signature
Bug#194260: ITP: netbsd-make -- NetBSD make suite
Package: wnpp Version: N/A; reported 2003-05-21 Severity: wishlist * Package name: netbsd-make * Version: 1.6.1 * Upstream Author: The NetBSD Foundation * URL: http://www.netbsd.org/ * License: FIXME * Package: nbmake Description: NetBSD Tools: make suite This package provides the NetBSD make, install, mkdep, and mklocale binaries, which are used when building certain BSD programs (such as those in the NetBSD source tree). All of the programs are distinguished by the prefix 'nb' (for example, 'nbmake'), in order to prevent conflict with GNU userland programs of similar names. -- Joel Baker [EMAIL PROTECTED] pgp9CN1qdktzk.pgp Description: PGP signature
Bug#181779: jftw uploaded
close 181779 stop This bug should have been closed by the upload of jftw, but wasn't due to the Closes: entry being in -1, while the actual accepted version was -2. -- Joel Baker [EMAIL PROTECTED] pgpv9AZQkd2Kf.pgp Description: PGP signature
Bug#182617: ITP: fortunes-debian-hints -- Hints for using Debian
Package: wnpp Version: N/A; reported 2003-02-26 Severity: wishlist * Package: fortunes-debian-hints * Version: 1.0 Upstream Author: Joel Baker [EMAIL PROTECTED] License: GPL-2 Description: Hints for using Debian This package provides a set of hints and tips on using Debian, in a fortune database format. New Debian users (or administrators) may find its advice particularly sage or helpful, and even veteren Debianites might find some new tidbits. -- Joel Baker [EMAIL PROTECTED] pgpZhizxYvN3T.pgp Description: PGP signature
Bug#181779: ITP: jftw -- Joel's File Tree Walk library
Package: wnpp Version: N/A; reported 2003-02-20 Severity: wishlist * Package name: jftw Version: 0.1 Upstream Author: Joel Baker [EMAIL PROTECTED] * URL: http://people.debian.org/~fenton/ * License: BSD Description: Joel's File Tree Walk library Joel's FTW library provides an implementation of the ftw and nftw file tree walking functions (using the fts function suite) for platforms which do not have them as part of the core system. (Produces libftw0 and libftw0-dev; this package is largely so that the BSD ports can get official APT support.) -- Joel Baker [EMAIL PROTECTED] pgplT18KPUIso.pgp Description: PGP signature
Bug#167292: ITP: libc12 -- NetBSD C library
On Sat, Nov 02, 2002 at 10:59:10AM +0900, Junichi Uekawa wrote: At Thu, 31 Oct 2002 23:54:10 -0700, Joel Baker wrote: BTW, what does 12 of libc12 mean? I will be happy to name the binaries netbsd-libc12 when the current libc6 becomes gnu-libc6 or glibc6; certainly the source package name might change, but since there are exactly 0 platforms which will ever have both GNU libc and NetBSD libc (they are exclusive and must be separated by arch, since binaries depend on one or other other), it is simpler to have the binary packages named consistantly. FreeBSD's is libc4, though they are using GNU libc instead; the Hurd has libc0.2 as their package name. ITP should state the name of the source package. Hence, I think your ITP should have said something like, source package netbsd-libc, which builds a binary package libc12. At the time, it was source-titled 'libc12' as well. I concur, however, with the thought of renaming the source to netbsd-libc, and the package as it stands (that is, the one in the Debian-BSD archive, and which will be uploaded to the main archive once netbsd-* arch sections exist) is now source-named netbsd-libc. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/
Bug#167292: ITP: libc12 -- NetBSD C library
On Fri, Nov 01, 2002 at 10:26:06AM +0900, GOTO Masanori wrote: At Thu, 31 Oct 2002 15:54:34 -0700, Joel Baker wrote: * Package name: libc12 * Version: 1.6+debian.1 * Upstream Author: The NetBSD Foundation * URL: http://www.netbsd.org/ * License: Varies per source file; see discussion on debian-legal I recommend netbsd-libc or netbsd-libc12. There is already libc6 (glibc). The name libc12 is similar to libc5 or libc6 which are GNU libc. It leads a bit confusion. I don't intend to prioritize GNU libc, because GNU libc does not use their source package name as libc, but glibc. Besides imagine if FreeBSD's libc or other BSD libc is ITP-ed. Distinguishing their name apparently is a good idea, for example diet-libc. BTW, what does 12 of libc12 mean? I will be happy to name the binaries netbsd-libc12 when the current libc6 becomes gnu-libc6 or glibc6; certainly the source package name might change, but since there are exactly 0 platforms which will ever have both GNU libc and NetBSD libc (they are exclusive and must be separated by arch, since binaries depend on one or other other), it is simpler to have the binary packages named consistantly. FreeBSD's is libc4, though they are using GNU libc instead; the Hurd has libc0.2 as their package name. (Note that I would, in fact, be quite happy if all libc packages were more specific; until then, however, all known examples do in fact call the binary libc*, where * is the major version number, per Policy). -- Joel Baker [EMAIL PROTECTED] pgp9l51AM1F6w.pgp Description: PGP signature
Bug#167292: ITP: libc12 -- NetBSD C library
Package: wnpp Version: N/A; reported 2002-10-31 Severity: wishlist * Package name: libc12 * Version: 1.6+debian.1 * Upstream Author: The NetBSD Foundation * URL: http://www.netbsd.org/ * License: Varies per source file; see discussion on debian-legal * Package: libc12 Description: NetBSD C library: Shared libraries Contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library and the standard math library, as well as many others. * Package: libc12-dev Description: NetBSD C library: Development Libraries and Header Files Contains the symlinks, headers, and object files needed to compile and link programs which use the standard C library. * Package: libc12-dbg Description: NetBSD C library: Development Libraries and Header Files Contains unstripped shared libraries. This package is provided primarily to provide a backtrace with names in a debugger, this makes it somewhat easier to interpret core dumps. The libraries are installed in /usr/lib/debug and can be used by placing that directory in LD_LIBRARY_PATH. Most people will not need this package. * Package: libc12-pic Description: NetBSD C library: PIC archive library Contains an archive library (ar file) composed of individual shared objects. This is used for creating a library which is a smaller subset of the standard libc shared library. The reduced library is used on the Debian boot floppies. If you are not making your own set of Debian boot floppies using the `boot-floppies' package, you probably don't need this package. * Package: libc12-prof Description: NetBSD C library: Shared libraries Static libraries compiled with profiling info (-pg) suitable for use with gprof. pgpn3B2rkzTfa.pgp Description: PGP signature
Bug#148413: ITP: iconv -- GNU Unicode conversion library
Package: wnpp Version: N/A; reported 2002-05-28 Severity: wishlist * Package name: iconv Version : 1.7 Upstream author : GNU Project * URL : http://www.gnu.org/software/libiconv/ * License : LGPL Description : A Unicode conversion library This is an open source Unicode conversion library provided by the GNU Project. It is required to provide this functionality on the NetBSD platform, and is a pre-requisite to successfully building GCC 3.1. It also provides a command-line interface via the 'iconv' program. I am currently in the NM queue, pending DAM approval and account creation, and have a sponsor for the package. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#148413: ITP: iconv -- GNU Unicode conversion library
On Tue, May 28, 2002 at 07:23:55PM -0400, Joe Drew wrote: On Tue, 2002-05-28 at 18:06, Joel Baker wrote: * Package name: iconv It also provides a command-line interface via the 'iconv' program. In what ways is this iconv different from the iconv provided in the libc6 package? I expect there is very little, if any, difference; they're both GNU code, and I would be amazed if it were not simply duplicated. However, since none of the *BSD ports have GNU libc, and not all of them implement iconv() in a native fashion, it is necessary to have the package available. It can be limited to only those architectures which lack an implementation of iconv(), if it would cause problems; this is part of why I CC'ed the ITP to debian-devel. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
