Re: [proposal] Documenting which revision is installed

[Frans Pop]

Adeodato Simó wrote:
> In other words, I plan on uploading a version to sid, block it from
> migrating to testing, and uploading another version via t-p-u. Stable
> point releases will get updated via s-p-u. That makes it two initial
> uploads, and then twice per stable release (t-p-u; release; t-p-u), plus
> one per stable point release (s-p-u).

The problem with that approach is that it is complex, error-prone and
requires a disproportionate amount of manual work, a lot of which can only
be done by someone with the access needed to set the needed hints.

> As said in my previous mail, I'm willing to take care of that.

For the next 40 years? Can you really guarantee that you will be able to do
this in time and without errors for each and every release and point release?

I agree with Anthony that it is very much preferable to have a solution
that's just able to automatically determine the correct version.

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [proposal] Documenting which revision is installed

[Adeodato Simó]

* Frans Pop [Fri, 28 Dec 2007 08:20:01 +0100]:

> > As said in my previous mail, I'm willing to take care of that.

> For the next 40 years? Can you really guarantee that you will be able to do
> this in time and without errors for each and every release and point release?

Thanks for the vouch of confidence! Anyway, the package would be
maintained by the release team, and there should always be somebody
available to make a oh-so-trivial upload. Or somebody completely
different -- we know how to cover up for other people, ejem.

> I agree with Anthony that it is very much preferable to have a solution
> that's just able to automatically determine the correct version.

Feel free to pursue the idea, then, really, I'm just not interested in
*doing* it myself, whereas I'm interested in doing the package upload
dance. And this is Debian, after all.

And I'm leaving /etc/debian_version untouched, so it could be migrated
to Anthony's scheme if that turns out to besuccessful. But,
/etc/lsb-release ought to be a static file, I think.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Hay quien sueña con la alquimia
que haga del vicio virtud
-- Luis Eduardo Aute, Giraluna


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#458062: ITP: jclassinfo -- extracts information from Java class files

[Vincent Fourmond]

Package: wnpp
Severity: wishlist
Owner: Vincent Fourmond <[EMAIL PROTECTED]>


* Package name: jclassinfo
  Version : 0.19.1
  Upstream Author : Nicos Panayides <[EMAIL PROTECTED]>
* URL : http://jclassinfo.sf.net
* License : GPL
  Programming Lang: C, XML
  Description : extracts information from Java class files

  jclassinfo reads Java class files and extracts useful information
  from them, such as:
  * the classes/methods/constants/fields provided
  * their dependencies
  * the version of the virtual machine necessary to run them
  * a full disassembly of the bytecode
  * other attributes

  This package could come in really useful for the building of a java
dependencies checker.

  Preliminary packaging is essentially finished. I just need to polish it up 
and make sure the manual page is up-to-date.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New field in binary stanza

[Magnus Holmgren]

On måndagen den 24 december 2007, David Paleino wrote:
> Il giorno Mon, 24 Dec 2007 16:25:43 +
> Neil Williams <[EMAIL PROTECTED]> ha scritto:
> > On Mon, 24 Dec 2007 16:51:13 +0100
> > David Paleino <[EMAIL PROTECTED]> wrote:
> > > Hi *,
> > > would it be possible to have a "License" field in the information of a
> > > package?
> >
> > Why? What is the benefit?
> >
> > A machine-interpretable format for debian/copyright is already
> > available. Why clutter the dpkg and apt-cache with licence lines?
>
> debian/copyright is not available via the APT cache, thus cannot be
> available to wrappers like python-apt and others.

Changelogs and copyright files are available at predictable locations under 
http://packages.debian.org/changelogs/pool/ (it would be nice if the Release 
file format were extended to include this information so that other 
repositories than the official ones could make these files available in the 
same manner).

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


signature.asc
Description: This is a digitally signed message part.

Re: DOAP files

[Stefano Zacchiroli]

On Thu, Dec 27, 2007 at 09:52:27PM +, Edd Dumbill wrote:
> I'm not currently subscribed to debian-devel, but am happy to contribute
> in any way I can to this effort, so please feel free to CC me, or bring

Hi Edd, thank for taking part in this discussion!

Debian side, I presume the peculiar thing we need to do is to
standardize how to use upstream DOAP files. The few questions that comes
to my mind right now are:
- would it be enough to have them in a Debian source package or do we
  want to have them also in some Debian binary package (so that they
  will end up being installed on the filesystem)?
- in the latter case, let's standardize a directory where to put them;
  which one?
- similar question for the former case: debian/doap.xml would do?

In answering the above questions we need to think at the use cases,
right now I only have in mind the PTS and packages.d.o. For both cases
probably the source package would be enough, since packages.d.o AFAIK is
already unpacking source packages to extract stuff, for example the
changelogs.

I'm not sure however that preventing a priori filesystem installation
will not hinder future uses ...

Edd, your hints on how to answers the above questions are totally
appreciated!

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Bug#458061: RFH: cfs -- Cryptographic Filesystem

[Gerrit Pape]

Hi, I'm seeking help with the cfs Debian package, if you're interested,
please see
 http://bugs.debian.org/src:cfs

cfs is a nice package, written in 1992, updated 1997, and since without
upstream.  Chris Leishman maintained the package until I took it over in
2002, it's worth reading through the source in any case.  I'm willing to
share maintainership, and possibly hand over the package to another
DD/DM after some time.

Thanks, Gerrit.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Which spell checkers to include by default?

[Luca Capello]

Hi all!

On Tue, 25 Dec 2007 12:17:52 +0100, Petter Reinholdtsen wrote:
> [Manoj Srivastava]
>> Are these packages a drop in replacement for ispell?
>
> None of the spell checkers are drop in replacements for the others.
> Each program need to have support for ispell, aspell, myspell and/or
> hunspell.  This is why I want us to try to get as many packages as
> possible to switch to hunspell, to make it possible to drop ispell
> completely.

It seems that I cannot find a comparison of the differences spell
checkers.  Please, could you enlighten me on why hunspell should be a
better default one?

Thx, bye,
Gismo / Luca


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Which spell checkers to include by default?

[Luca Capello]

Hi all (again)!

On Thu, 27 Dec 2007 02:54:34 +0100, Luca Capello wrote:
> On Tue, 25 Dec 2007 12:17:52 +0100, Petter Reinholdtsen wrote:
>> [Manoj Srivastava]
>>> Are these packages a drop in replacement for ispell?
>>
>> None of the spell checkers are drop in replacements for the others.
>> Each program need to have support for ispell, aspell, myspell and/or
>> hunspell.  This is why I want us to try to get as many packages as
>> possible to switch to hunspell, to make it possible to drop ispell
>> completely.
>
> It seems that I cannot find a comparison of the differences spell
  ^
This should have been "differences BETWEEN spell checkers" or "DIFFERENT
spell checkers", as you prefer ;-)

Thx, bye,
Gismo / Luca


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Which spell checkers to include by default?

[Petter Reinholdtsen]

[Luca Capello]
> It seems that I cannot find a comparison of the differences spell
> checkers.  Please, could you enlighten me on why hunspell should be
> a better default one?

I can only refer to the knowledge I have gotten from those I know that
work on spell checkers.  The features of spell checkers is normally
how well they handle word transformations, concatenations and
proposals.  ispell, aspell and myspell are ok for languages where the
main transformation is adding word endings (like cat -> cats), and not
good with languages with more complex transformations (er -> var), and
completely useless for languages with very complex transformations
(got no example, but I know Nothern Sami have word transformations
based on the words around changes.  When it comes to concatenations, I
am not sure which of these are doing a good job, but I believe aspell,
myspell and hunspell does a better job than ispell.  As for proposals,
aspell include rules on common misspellings and letters that sound the
same as other letters, and uses this to calculate likely proposals for
misspelled words.  ispell do not.  I believe myspell and hunspell does
the same.

So the main differentiating factor is how well the spell checker
handle word transformation, and I am told that hunspell is a huge
improvement for languages with complex transformation rules compared
to ispell, aspell and myspell.

I found
http://www.divvun.no/doc/proof/spelling/X-spell/index.html> on
the pages for the Nothern Sami spell check, which provide some more
information.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[Gabor Gombas]

On Thu, Dec 27, 2007 at 10:18:38AM -0800, Russ Allbery wrote:

> I don't think this is horribly relevant to what we're discussing, namely
> how to go about packaging software for inclusion in Debian.  Generating
> upstream-provided packages that don't meet Debian Policy and therefore
> won't be included in Debian but which are useful for some users is
> certainly of interest to some, but it seems rather off-topic for
> debian-devel.  We're focused on including software in Debian rather than
> creating problems like one sees in the Red Hat world where there are
> random RPMs scattered hither and yon all over the net that may or may not
> work together.

Well, this was in response to "having debian/ in upstream release is
harmful" opinions. You're right that the best thing would be to have
everything packaged officially, but in reality sometimes that just does
not work out, for various reasons:

- Having to work with unreleased development snapshots because the
  official release does not yet have some critical (for me) feature
- Maintainer not uploading new upstream versions for a long time
- Official package lacking some feature due to legal reasons that may be
  important for Debian as an organization but not for me as an
  individual

In these cases upstream help for creating a Debian package is really
nice as it saves me time. Of course it can be expected that the
upstream-provided packaging does not play nice together with official
Debian packages but as long as having to install unofficial packages is
the exception rather the norm I'm willing to pay that price.

> > There is also the method e.g. nut upstream uses that can be viewed as a
> > compromise: they put the upstream-provided packaging info into a
> > subdirectory (packaging/debian), so it does not conflict with the
> > distro-provided packaging.
> 
> This, of course, is ideal from a Debian packaging perspective.  It would
> be nice if more upstreams who feel like they *really* want to provide
> packaging files for Debian would use a strategy like this.

Maybe it should be described somewhere on www.debian.org why is this the
preferred method. I suspect most upstreams providing their own packaging
simply do not even aware that it may cause problems for distro makers.

> My experience, though, with maintainer-provided Debian packaging files
> except for the special case where the Debian and upstream maintainer are
> the same person is very poor.  The Debian packaging often hasn't been
> updated, doesn't reflect the current version of the package, may be
> written for some ancient release of Debian and sometimes won't work with
> unstable, and often has dependencies that reflect whatever the last person
> to touch it had sitting around on their system.  They maintain their
> Debian packaging about as well as they maintain their RPM spec files, but
> Debian puts more effort into integration and transitions and sloppy
> packaging is far more apparent than it is in the messy RPM universe.

In general I agree with you. However in my experience fixing the
upstream-provided packaging to the point when I'm able to build an
installable .deb is just 1-2 minutes, much less than having to create
debian/ from scratch. Yes, it is a hack, it may not be perfect (or it
may even be completely buggy from a packaging POV), but it saves _me_
time and that's what counts.

Maybe the webpage proposed above should also mention that binary
packages built using the upstream-provided packaging scripts should not
be put on the web, so it is less likely that people unaware of the
possible risks download & use them.

(Btw. I'm quite aware of the "RPM hell" problem. We're running
Scientific Linux on our grid nodes, and every gLite upgrade - even just
to update the CA certificates - tends to break the system in new and
exciting ways...)

> In most cases, the Debian packaging files end up just confusing users and
> the upstream maintainer would be better off deleting them and letting the
> Debian packager do their job.

In an ideal world, maybe. But until then they are useful.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [proposal] Documenting which revision is installed

[Petter Reinholdtsen]

[Anthony Towns]
> The main limitation is that it's a nuisance to update -- you can't
> differentiate testing and unstable because of that, eg, and when we're due
> for a release we end up having testing/unstable pretend they're really
> stable already for a while, eg. Updating it more often just makes that
> more of a nuisance.

Why not move the /etc/debian_version file into a separate package, and
for example include the release documentation in that package.  The
package could be called debian-version, and it would make it easier to
keep a separate version in testing and unstable.

The version number and the release notes are in my experience the last
two parts one want to update before a release, and it might make sense
to update those directly into testing, instead of going through sid.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#458095: ITP: phenny -- extensible IRC bot written in Python

[Noah Slater]

Package: wnpp
Severity: wishlist
Owner: Noah Slater <[EMAIL PROTECTED]>


* Package name: phenny
  Version : 2007-12-20
  Upstream Author : Sean B. Palmer <[EMAIL PROTECTED]>
* URL : http://inamidst.com/phenny/
* License : TBD
  Programming Lang: Python
  Description : extensible IRC bot written in Python

Phenny is a lightweight IRC bot with the usual facilities that one expects
such as a Wordnet interface and thesaurus lookups. Modularly extensible with
Python and can reload modules on the fly.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.20.3-bytemark-uml-2
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Noah Slater 

"Creativity can be a social contribution, but only in so far as
society is free to use the results." - R. Stallman


signature.asc
Description: Digital signature

Re: Which spell checkers to include by default?

[Teemu Likonen]

(I just subscribed to this list and tried to construct the References
field manually. I Hope it won't broke threads.)


Petter Reinholdtsen wrote:

[Luca Capello]
> > It seems that I cannot find a comparison of the differences spell
> > checkers.  Please, could you enlighten me on why hunspell should be
> > a better default one?
>
> I can only refer to the knowledge I have gotten from those I know that
> work on spell checkers.  The features of spell checkers is normally
> how well they handle word transformations, concatenations and
> proposals.

You made good points on what spell-checkers are _technically_ better.
I don't know them very well myself but I understand that many of them
are not suitable for synthetic and agglutinative languages like
Finno-Ugric languages. Hunspell seems to be, though, as it was
originally designed for Hungarian.

(For Finnish we even need a completely unique system Voikko which is
used through libvoikko1 and programs depending on it, see 'aptitude
search ~Dlibvoikko1'.)

But I think this is not the main point when deciding the _default_
spell-checker for Debian. A spell-checker may be technically superior to
others but if it's not supported by many languages (i.e. no dictionary
packages) it may not be good default and standard install. I have no
opinion about this myself. Finnish users use Voikko anyway and it is
installed through the Finnish environment task (or desktop task, I don't
remember). I think the question of default spell-checker is more
practical than technical; it has to be considered from supported
languages' point of view.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#458061: RFH: cfs -- Cryptographic Filesystem

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Am Fr den 28. Dez 2007 um 12:04 schrieb Gerrit Pape:
> Hi, I'm seeking help with the cfs Debian package, if you're interested,
> please see
>  http://bugs.debian.org/src:cfs

I will. I'm also at the bughunting party at Zurich so I can see there if
I will fix some bugs there.

I am not a Debian maintainer but have several experiences with packaging
and programming (C and perl).

The days I am not at home. So I will make contact in new year.

Gruß
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBR3Ug4J+OKpjRpO3lAQKY3gf+Jnw4xVkLLBWtLoHqxyJlcJu6gLeRM9Vh
DtTxkM76YGwh+dfz4aaLHscm/8fFszQ2/+5eSplByyHY9kPuk/Kevxn054QNr5tG
sDhla7tKwLmyHQiyysm+kR8VxDADssS77aelArIgeJwmscqhbr9/iChZMCKPqzSV
zCyA0wyqlLPwiVm9En0GxAoC9ptGC8uTFkneCSGIbUU8R4AlagGzqxcnEOiiDmp7
58qRVhGksIqbxzyWoJWnxmLIwBWooeA01DAR9k4/Z7E3/6X1YqNeQKV7VS5Yhz0r
/GiyJNN8ZUqYtS/yHRbj11kD7uF+YbIkAkCzoKMh8QoUj1LnTy9QCA==
=nKA9
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#458097: ITP: libjrosetta-java -- JRosetta - Advanced graphical console engine

[Sylvestre Ledru]

Package: wnpp
Severity: wishlist
Owner: Sylvestre Ledru <[EMAIL PROTECTED]>

* Package name: libjrosetta-java
  Version : 1.0.1
  Upstream Author : Sebastien Jourdain <[EMAIL PROTECTED]>
* URL : http://dev.artenum.com/projects/JRosetta
* License : (QPL but may change in the future)
  Programming Lang: (Java)
  Description : JRosetta - Advanced graphical console engine

 JRosetta provides a common base for graphical component that 
could be used to build a graphical console in Swing with the latest 
requirements, such as command history, completion and so on for instance for 
scripting language or command line.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Editing the sources in "debian/rules clean"

[Bernhard R. Link]

* Adeodato Simó <[EMAIL PROTECTED]> [071226 20:40]:
> I wish everybody did it that way. I'm also happy to see that it's now
> how dh-make will do it, good.

Even better is in my eyes to look if it is possible to get rid of those
files alltogether. I'd guess the vast majority of packages doesn't
really needs to know so much about the actual host, so could easily
work without those. Luckily newer autotools (even vor Debian values
of "newer") do not copy in those files when they are not requested.

So if your package is not using libtool, you might want to check if
it acutally needs those files. If those are in upstreams .tar.gz,
see if they are still there if you remake it with newer automake
and make dist. If they are not in there problem will solve itself
in the near future (check if your command in debian/rules only
copy in those file if they are already there). Otherwise you can look
for unneeded AC_CONONICAL_* in configure.{in,ac} and the included .m4
files. In my experiences someone copied them in without needing them.
(check (autoconf.info.gz)Canonicalizing for what they do, if no
target or target_* variable is used anywhere, it is very likely you
do not need a AC_CANONICAL_TARGET, for example). Upstream might
like that with a minimal change his releases can get siginifantly
smaller and you don't have to think about those config.* files.

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#458102: ITP: worldwind -- NASA Worldwind - 3D Virtual Globe

[Sylvestre Ledru]

Package: wnpp
Severity: wishlist
Owner: Sylvestre Ledru <[EMAIL PROTECTED]>

* Package name: worldwind
  Version : 0.4.1
  Upstream Author : Patrick Murris, Tom Gaskins
* URL : http://worldwind.arc.nasa.gov/java/
* License : (NASA Open Source Agreement V1.3)
  Programming Lang: (Java)
  Description : NASA Worldwind - 3D Virtual Globe

 World Wind allows any user to zoom from satellite altitude into
 any place on Earth, leveraging high resolution LandSat imagery 
 and SRTM elevation data to experience Earth in visually rich 
3D, just as if they were really there.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#458146: ITP: tilecache -- A web map tile caching system

[Christopher Schmidt]

Package: wnpp
Severity: wishlist
Owner: Christopher Schmidt <[EMAIL PROTECTED]>


* Package name: tilecache
  Version : 2.01 
  Upstream Author : Christopher Schmidt <[EMAIL PROTECTED]>
* URL : http://tilecache.org.org/
* License : BSD
  Programming Lang: Python
  Description : A web map tile caching system

 TileCache is an implementation of a WMS-C compliant server made
 available by MetaCarta. TileCache provides a Python-based WMS/TMS
 server, with pluggable caching mechanisms and rendering backends. In the
 simplest use case, TileCache requires only write access to a disk, the
 ability to run Python CGI scripts, and a WMS you want to be cached. With
 these resources, you can create your own local disk-based cache of any
 WMS server, and use the result in any WMS-C supporting client, like
 OpenLayers, or any TMS supporting client, like OpenLayers and worldKit.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#458148: ITP: complearn-gui -- interactive 3d data mining tool and demo for universal machine learning

[Rudi Cilibrasi]

Package: wnpp
Severity: wishlist
Owner: Rudi Cilibrasi <[EMAIL PROTECTED]>


* Package name: complearn-gui
  Version : 1.0.5
  Upstream Author : Rudi Cilibrasi <[EMAIL PROTECTED]>
* URL : http://complearn.org/download.html
* License : BSD
  Programming Lang: C++
  Description : interactive 3d data mining tool and demo for universal 
machine learning

 This is the easiest way to get started with data compression based
 machine learning.  Try the simplest drag and drop interface to AI today.
 This package includes the 3D demo tree search interactive explorer
 clgui.  Get started in minutes with this entertaining and educational
 tool.

-- System Information:
Debian Release: testing/unstable
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]