Bug#508985: ITP: libmysqlcppconn-dev -- MySQL C++ Connectivity library

[Rene Engelhard]

Package: wnpp
Severity: wishlist
Owner: Rene Engelhard 

* Package name: libmysqlcppconn-dev
  Version : 1.0.2 snapshot
  Upstream Author : MySQL AB, Sun Microsystems Inc.
* URL : http://forge.mysql.com/wiki/Connector_C++
* License : GPL v2 with "FLOSS exception"
  Programming Lang: C++
  Description : MySQL C++ Connectivity library

 MySQL Connector/C++ is a MySQL database connector for C++.
 .
 It mimics the JDBC 4.0 API.

OpenOffice.org will somewhen include a native driver for
MySQL - which uses mysqlcppconn - they already have experimental stuff
there.

MySQL people: I already did some work on it and have a preliminary package
of 1.0.2~2008121 here (yet without the shared lib as API still changes, we
also could wait till I upload it or just package the static lib - which
I think we should do anyway for now).

But should I "just" maintain it myself or shoudld I (imho better) put this
under pkg-mysql-maint?

Regards,

Rene

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (1001, 'testing'), (1, 'experimental')
Architecture: powerpc (ppc)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable -> testing

[Julien BLACHE]

Josselin Mouette  wrote:

Hi,

> Maybe that’s because I maintain packages with a large audience, but I
> don’t find that effect very important. 

You're right about the large audience, it does make quite a
difference.

> Actually I don’t think we should recommend testing at all to desktop
> users. Except during freeze times, I find unstable to be much more
> usable, and keep testing for (non-production) servers.

Agreed.

> However it is important to keep a large testing userbase, since
> developers don’t (at least, they aren’t supposed to) use it. Some bugs

Ditto.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable -> testing

[Julien BLACHE]

"Daniel Moerner"  wrote:

Hi,

> Obviously, having more users test unstable is good.  However, I agree
> that it's not necessarily a big issue.  A good deal of RC-bugs are
> related to FTBFS, security advisories, package conflicts, and the
> like.  These bugs can pop up independently of how much testing a
> package receives in unstable, so focusing on just increasing the
> number of unstable users would produce diminishing returns.

Your point is moot, mostly: FTBFS and package relationships issues are
probably the easiest RC bugs to fix, they're not the kind of RC bugs
we're seeing right now before a release (at that point any RC bugs of
these kinds that aren't fixed are either tricky or not being taken
care of properly). Also most FTBFS are not reported by users.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#508901: ITP: dicom3tools -- Tools for handling DICOM files, with conversion from proprietary formats.

[Mathieu Malaterre]

On Tue, Dec 16, 2008 at 7:06 PM, Agustin Martin  wrote:
> On Tue, Dec 16, 2008 at 02:14:29PM +0100, Michael Hanke wrote:
>>
>> On Tue, Dec 16, 2008 at 02:06:40PM +0100, Yves-Alexis Perez wrote:
>> > On mar, 2008-12-16 at 13:57 +0100, Mathieu Malaterre wrote:
>> > >   Description : Tools for handling DICOM files, with conversion
>> > > from proprietary formats.
>> > >
>> > >  Unix, Mac and Windows (Cygwin) command line utilities for creating,
>> > >  modifying, dumping and validating files of DICOM attributes, and
>> > >  conversion of proprietary image formats to DICOM. Can handle older
>> > >  ACR/NEMA format data, and some proprietary versions of that such as
>> > > SPI.
>> > What are DICOM, ACR, NEMA, SPI?
>> Medical image data formats. Given that the description should be
>> appropriate for a potential user those names should be ok -- but Mac and
>> Windows are surely not meaningful in this context.
>
> I also find of help having that info in the long description, and even part
> in the short one, so people is aware if they are not potential users.
> Something like
>
> Description: DICOM medical image files manipulation and conversion tools.
>
> Command line utilities for creating, modifying, dumping and validating
> files of DICOM attributes. Support conversion of some proprietary medical
> image formats to DICOM. Can handle older ACR/NEMA format data, and some
> proprietary versions of that such as SPI.
>

Fixed.
$ svn ci -m"as proposed by Agustin Martin" control

Ref:
http://debian-med.alioth.debian.org/

-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Building Debian from Sources

[Mustafa KYR]

Hello,
I am a new engineer and I was just a debian user in my former life. I want
to build debian linux from sources to understand it all. I spent lots of
time during search about it. Do we have a script or sth else in sources
cd. I want to create whole linux which is in installable cd. Please give me
some directions/suggestions or idea. I really need your help ...

Best Regards ...

 Mustafa KIYAR
 Electronic & Telecımmunication Eng.
 Turkey

Gtk1.2/Imlib/gnome-lib packages (Long)

[Barry deFreese]

Hi folks,

Just in case anyone cares/is interested, here is some work I have been 
doing on packages using Gtk1.2, Imlib, gnome-libs, or any combination 
thereof.



Obviously some packages fall within more than one rdepend/rbdepend.
gnome-libs:

 bluefish
   Actually built with gtk2 but still build-deps on gnome-bin?? (pinged 
maintainer). Just a suggests, can probably be removed.


 mrwtoppm
   GTK2 app but still build-depends on libart-dev. NMU'd removing 
build-dep on libart-dev and gdk-pixbuf-dev.


 ogle-gui
   GTK2 app but still build-depends on libart-dev. NMU'd removing 
build-dep on libart-dev.


 swftools
   Build depends on libart-2.0-dev | libart-dev

 digitaldj
   Will need ported or removed.

 gwc
   False positive?

 slmon
   Build-depends on libgnome-dev.  Will need ported or removed.  
Upstream inactive since 2004.


 synce-trayicon
   New in Lenny.  Unneeded build-dep on libgnome-dev? Bug Filed.

 xpuyopuyo
   Needs ported or removed.

 soundtracker
   Supposedly upstream is "working on it"

 gnome-lokkit
   PROP_RM Filed.

 gfslicer
   Started working on a patch but is it worth keeping?

 gbib
   Will need ported or removed.  Upstream has a newer release candidate 
but still not gtk2.


 gnomekiss
   Games team package.  Uploaded new release without libgtkhtml-dev.

 gsnes9x
   Should probaby just be RM'd. snes9express seems a replacement that 
is gtk2.0.


 directory-administrator
   PROP_RM filed by Frank.

 powershell
   E-mailed maintainer about removal.

 gtkgo
   PROP_RM bug filed

 gtkfontsel
   Orphaned but a fairly significant popcon.  I can't find new upstream 
source.  Could probably be ported or RM:d.


 gtkglarea
   Orphaned (now new maintainer) and I can't find any upstream source 
yet but has a few r(b)depends.


gtkglarea5:
 celestia
   New in Lenny

 vertex
   RM: Filed.

 xt
   Needs ported or removed.

 worlded
   Needs ported or removed.  Upstream seems inactive since 2003. 
(Pretty low popcon).


 python-visual
   Needs ported or removed.  There is a new upstream beta 5.0, not sure 
if it requires gtkglarea.


imlib:
 chinput
   Hasn't seen an upload since 2006.  Needs transition to imlib2.  
Can't find upstream source.


 e16menuedit
   e16menuedit2 a gtk2.0 replacement?

 gkrellm
   Bug filed to remove unneeded build-dep on gdk-imlib1-dev

 gkrellmitime
   Bug filed to remove unneeded build-dep on gdk-imlib1-dev.

 gretl
   Unnecessary build-dep?  Maintainer is uploading new version without 
build-dep.


 qtpixmap
   Binary gtk-engines-qtpixmap uses gdk-imlib11

 sylpheed-gtk1
   PROP_RM filed. RM: filed by maintainer.

 gkrellm-snmp
   NMU'd removing unneeded imlib build-dep

 gkrellweather
   NMU removing unneeded imlib build-dep.

 icewm
   Ugh

 kdegraphics
   4.x version in experimental doesn't use imblib11

 libgtkimreg
   Another one for Andreas Tille (Mailed Andreas for thoughts).  
Started on porting.


 mgp
   Not well maintained.  Newer upstream but still not imlib2. (Can be 
built without imlib though).


 paul
   Another one for Andreas Tille (Mailed Andreas for thoughts).  
Started on porting.


 pixelize
   PROP_RM filed

 qiv
   E-mailed Bart Martens for opinion.  Replied, now have e-mailed 
upstream to see if they are doing any porting work.


 qvwm
   PROP_RM filed

 wallp
   RM: Filed.

 xteddy
   E-mail Andreas Tille (taken over upstream). Sent partial patch.  
Still needs some work. Peter De Wacther fixed up patch.


 ygraph
   Gtk1.2 and imlib.  Will need ported or removed.

 netdude
   ITA'd.  There is a new upstream available.  I've pinged the ITAer to 
see if the new upstream is GTK 2.0.


 sqlrelay
   Some of the binaries have decent popcons.  We could probably either 
port sqlrelay-config-gtk or just remove that binary for now.


Thanks,

Barry deFreese


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: First call for votes for the Lenny release GR

[Manoj Srivastava]

On Sun, Dec 14 2008, Pierre Habouzit wrote:

> On Sun, Dec 14, 2008 at 03:02:17AM +, Debian Project Secretary wrote:
>
>> --
>> Choice 2: Allow Lenny to release with proprietary firmware [3:1]
>> == == = = == ===  ===  =
>
> Why on earth does it needs [3:1] whereas it wasn't needed for:
> http://www.debian.org/vote/2006/vote_007

Asked and answered, it has to do with removing the wording about
 requiring the  firmware to be under a dfsg free license.

>> --
>> Choice 3: Allow Lenny to release with DFSG violations [3:1]
>> == == = = == ===   == =
>
> Same question somehow applies here.

You do not think asking to release with known violations of a
 foundation document needs a 3:1? Again, asked and answered.

>> --
>> Choice 4: Empower the release team to decide about allowing DFSG violations 
>> [3:1]
>> == == === === ===  == == =   == 
>> 
>
> Unless I'm mistaken this shouldn't be [3:1] as it's specifically allowed
> by the § about delegates in the constitution. "Delegates shall take
> decision they see fit". What should be [3:1] is to dis-empower them from
> having such rights.

Actuallu, nothing delegated to the delegates allows them to
 change the foundation docs. Or should the packager fo the constitution
 document, or the web team, under their daily tasks, just change the
 constitution as they see fit?

> And FWIW I still believe this vote is an horrible mix-up of really
> different things, is completely confusing, and I've no clue how to vote.
> I would be surprised other people don't think the same.
>
> E.g. How can I decide 2 _and_ 4 ? Does the rule change ? Does any
> resolution that wins overs Further Discussion will be validated ?
> Because unless I'm mistaken, 2 doesn't imply 4, so if 2 wins, 4 is
> invalidated.

No one seems to have seen it desirable to put a 2 & 4 option on
 the ballotl; despite the months we took to discuss this. The web page
 with the options was also up for several weeks, and a draft ballot went
 up earlier.

Seems liek there was plenty of time to change things, and add
 some of the power set options on to the ballot.  If I had added options
 willy-nilly, you would have screamed again of abuse of power.

manoj
-- 
God gives us relatives; thank goodness we can chose our friends.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: First call for votes for the Lenny release GR

[Luk Claes]

Manoj Srivastava wrote:
> On Sun, Dec 14 2008, Pierre Habouzit wrote:
> 
>> On Sun, Dec 14, 2008 at 03:02:17AM +, Debian Project Secretary wrote:

>> And FWIW I still believe this vote is an horrible mix-up of really
>> different things, is completely confusing, and I've no clue how to vote.
>> I would be surprised other people don't think the same.
>>
>> E.g. How can I decide 2 _and_ 4 ? Does the rule change ? Does any
>> resolution that wins overs Further Discussion will be validated ?
>> Because unless I'm mistaken, 2 doesn't imply 4, so if 2 wins, 4 is
>> invalidated.
> 
> No one seems to have seen it desirable to put a 2 & 4 option on
>  the ballotl; despite the months we took to discuss this. The web page
>  with the options was also up for several weeks, and a draft ballot went
>  up earlier.

It's you who decided to put all the proposals on the same ballot. I
don't think it's fair to request from people who disagree with that to
invest time in proposing more options. It's you who decided to make it a
mess, you could as an experienced vote taker have suggested quite some
different things which could have made it cleaner instead IMHO.

> Seems liek there was plenty of time to change things, and add
>  some of the power set options on to the ballot.  If I had added options
>  willy-nilly, you would have screamed again of abuse of power.

Sure, though you could have followed the procedure or hinted people in
an even saner direction IMHO.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable -> testing

[Johannes Wiedersich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Josselin Mouette wrote:
> Actually I don’t think we should recommend testing at all to desktop
> users. 

Why?

>Except during freeze times, I find unstable to be much more
> usable, and keep testing for (non-production) servers.

IMHO, there is one important difference between testing and unstable, as
far as desktop users are concerned: 'testing' at some time will become
'stable'. As a scientist, I basically need stable, reliable software to
carry out my work. Sometimes new hardware or new features in some core
programs I use warrant an upgrade to testing. However, I would not like
to 'indefinitely' cut off a route to 'stable' for my desktop(s).

Of course, your mileage may vary... ;-)

Cheers,

Johannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklIy4cACgkQC1NzPRl9qEUKLACePM1oWPE+qYtVDPdBa4sNnQTa
ITAAnidMpNHFgTBUB84OhL+zD7u/98TE
=l2KZ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#509017: ITP: libclass-c3-adopt-next-perl -- drop-in replacement for NEXT, using Class::C3 to do the hard work

[eloy]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyżaniak (eloy)" 


* Package name: libclass-c3-adopt-next-perl
  Version : 0.04
  Upstream Author : Florian Ragwitz C
* URL : http://search.cpan.org/dist/Class-C3-Adopt-NEXT/
* License : Dual (Perl): GPL/Artistic
  Programming Lang: Perl
  Description : drop-in replacement for NEXT, using Class::C3 to do the 
hard work

 Class::C3::Adopt::NEXT is intended as a drop-in replacement for NEXT,
 supporting the same interface, but using Class::C3 to do the hard work. You
 can then write new code without NEXT, and migrate individual source files to
 use Class::C3 or method modifiers as appropriate, at whatever place you're
 comfortable with.


-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Building Debian from Sources

[Cavit Cahit VURAL]

Hi,

please check http://www.linuxfromscratch.org/

regards

CC Vural

> Hello,
> I am a new engineer and I was just a debian user in my former
> life. I want to build debian linux from sources to understand it all.
> I spent lots of time during search about it. Do we have a script or
> sth else in sources cd. I want to create whole linux which is in
> installable cd. Please give me some directions/suggestions or idea. I
> really need your help ...
>  
> Best Regards ...
>  
>  Mustafa KIYAR
>  Electronic & Telecımmunication Eng.
>  Turkey


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: First call for votes for the Lenny release GR

[Manoj Srivastava]

On Mon, Dec 15 2008, Russ Allbery wrote:

> Thomas Weber  writes:
>> Am Montag, den 15.12.2008, 10:06 + schrieb Steve McIntyre:
>
>>> I've been talking with Manoj already, in private to try and avoid
>>> flaming. I specifically asked him to delay this vote until the numerous
>>> problems with it were fixed, and it was started anyway. I'm *really*
>>> not happy with that, and I'm following through now.
>>
>> Uh, I don't quite get this: you shortened the discussion period, but at
>> the same time asked the secretary to delay the vote?
>
> Where did Steve shorten the discussion period?  He did so for the *other*
> vote, but I haven't seen a thread where he did for this one.  (I may have
> just missed it.)

I mis remembered.  Steve shortened the discussion period for
 this vote, and the discussion and voting period for the _other_ vote,
 but I missed that the vote period for the gr_lenny vote was not
 shortened. I'll send out a new CFV.

Sorry about that.

manoj

-- 
Happiness adds and multiplies as we divide it with others.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#509021: ITP: gdcm -- DICOM library

[Mathieu Malaterre]

Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 


* Package name: gdcm
  Version : 2.0.10
  Upstream Author : Mathieu Malaterre 
* URL : http://gdcm.sourceforge.net
* License : BSD
  Programming Lang: C, C++, C#, Python, Java
  Description : DICOM library

 Grassroots DiCoM is a C++ library for DICOM medical files. It is automatically 
wrapped
 to python/C#/Java (using swig). It supports RAW,JPEG 
(lossy/lossless),J2K,JPEG-LS, RLE
 and deflated. It also comes with DICOM Part 3,6 & 7 of the standard as XML 
files.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable'), (50, 'testing'), (40, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#508992: ITP: pvrg -- JPEG implementation from Standford

[Mathieu Malaterre]

Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 


* Package name: pvrg
  Version : 1.2.1
  Upstream Author : Andy C. Hung 
* URL : ftp://havefun.stanford.edu:pub/jpeg/JPEGv1.2.tar.Z.
* License : PUBLIC DOMAIN LICENSE
  Programming Lang: C
  Description : JPEG implementation from Standford

This public domain image encoder and decoder is based on the JPEG
Committee Draft.  It supports all of the baseline for encoding and
decoding.  The JPEG encoder is flexible in the variety of output
possible.  It also supports lossless coding, though not as speedy as
we would like.  The manual is approximately 50 pages long which
describes its use.  The display program for JFIF-style (YCbCr) files is
described in section IV) below.  The JFIF style is not a requirement
for this codec - it can compress and decompress CMYK, RGB, RGBalpha,
and other formats - this codec may be helpful if you wish to extract
information from non-JFIF encoded JPEG files.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable'), (50, 'testing'), (40, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Why the gr_lenny ballot is the way it is

[Manoj Srivastava]

Hi,

This whole set of discussions and proposals started a couple of
 months ago, when concerns were raised about firmware blobs, dfsg
 violations, and the release. This, after a round of disuccion, led to
 three proposals on how the release should be conducted, in view of
 firmware blobs currently in the linux kernel packages.

The proposals led tyo a great deal of heated responses, and
 whole slew of related proposals were  produced -- related, as in all
 of them dealt with firmware blobs and difsg violations, and dealt with
 the release process, and some of them were for handling just the
 current release, others sought to solve the issue of firmwarfe for this
 and all future release4s, either directly, or  delegating the decisions
 to a group of developers, and away from the general resolution
 mechanism of resolving this for future releases.

All of these related proposals would handle, one way or the
 other, the issue of this release and firmware. Some of them would grant
 dispensation to more than just firmware, and some of them solve this
 problem for future reelases as well, but all would resolve the release
 _now_. Also, some of the proposals are indeed orthogonal, or, at least,
 mutually incompatible; and in some  cases, selecting one option makes
 the others moot.

Yes, some of the options  on this ballot have long term impact,
 but they are also equally capable of solving our "What to do about
 Lenny" problems. Since they all solve the Lenny issue, they are
 relevant, and related, solutions for the issue.  I do not think
 throwing options out because they are not of a narrow and limited scope
 is right. The proposer and sponsors can withdraw them, if they think
 the scope is too broad for the problem at hand. No one else should be
 removing them from consideration as a solution to the Lenny issue.

Now, we have been fairly non-anal about differing options on out
 ballots being formally proposed as amendments (I amend proposal foo,
 and replace all the words in that proposal by these below ), I did
 not see any reason to change being anal retentive for just this vote.

The ballot is a mess. While I think the related proposals should
 be placed on the same ballot overrides ere, the prooposals are not
 truly all orthogoanl. We could, for example, do the allow the
 delegation of DFSG violatio decisions to the release team, _and_ also
 rulke that firmware should be granted special dispensation in the DFSG.

So, while the power set of the options is not feasible, we could
 have a slew of options combining the various proposed options, if
 people wanted to vote on a compatible set of options.

This was discussed a month ago, in early november, giving people
 who wanted to vote on a combination of optiosn plenty of time to
 propose favourite combinations.
Message-ID: <87ej1cd11m@mid.deneb.enyo.de>
Message-ID: <871vxczbww@anzu.internal.golden-gryphon.com>

No one seemed to want such combinations enough to follow up on
 that.

Also,  splitting a vote into multiple ballots, with related
 proposals affecting the same action (lenny release, for instance) , is
 a horrendously bad idea -- since the massive amounts of strategic
 voting possibilities will taint the final result.  Given that these
 proposals are strongly related, they should be  on the ballot
 together.

The permanent solution proposals, if they fail to pass, may be
 discussed, modified, and brought to the table again. 

manoj
-- 
"Those who will be able to conquer software will be able to conquer the
world."-- Tadahiro Sekimoto, president, NEC Corp.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#508990: ITP: dicomscope -- DICOMscope - DICOM Viewer

[Ron Johnson]

On 12/17/08 03:29, Mathieu Malaterre wrote:

Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 


* Package name: dicomscope
  Version : 3.5.1
  Upstream Author : OFFIS DICOM Team 
* URL : http://dicom.offis.de/dscope.php.en
* License : Copyright (C) 1994-2004, OFFIS
  Programming Lang: C, C++
  Description : DICOMscope - DICOM Viewer




DICOMscope is a free DICOM viewer which can display uncompressed,
monochrome DICOM images from all modalities and which supports
monitor calibration according to DICOM part 14 as well as
presentation states. DICOMscope offers a print client (DICOM
Basic Grayscale Print Management) which also implements the
optional Presentation LUT SOP Class.


 BEGIN questionable verbiage

 The development of this
prototype was commissioned by the "Committee for the Advancement
of DICOM" and demonstrated at the European Congress of Radiology
ECR 1999. An enhanced version was developed for the "DICOM
Display Consistency Demonstration" at RSNA InfoRAD 1999. The
current release 3.5.1 has been demonstrated at ECR 2001 and
contains numerous extensions, including a print server, support
for encrypted DICOM communication, digital signatures and
structured reporting.

DICOMscope is not meant as a competition for commercial DICOM
viewers. The application is rather a feasibility study for DICOM
presentation states. The program is not appropriate to be used in
a clinical environment, e.g. for reporting.

 END

Does this really have to be in the long description, or should it be 
in the README.Debian?


--
Ron Johnson, Jr.
Jefferson LA  USA

How does being physically handicapped make me Differently-Abled?
What different abilities do I have?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#508992: ITP: pvrg -- JPEG implementation from Standford

[Mathieu Malaterre]

On Wed, Dec 17, 2008 at 2:16 PM, Ron Johnson  wrote:
> On 12/17/08 03:57, Mathieu Malaterre wrote:
>>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Mathieu Malaterre 
>>
>>
>> * Package name: pvrg
>>  Version : 1.2.1
>>  Upstream Author : Andy C. Hung 
>> * URL : ftp://havefun.stanford.edu:pub/jpeg/JPEGv1.2.tar.Z.
>
> $ mtr havefun.stanford.edu
> Couldn't get fd's flags: Bad file descriptor
> Name or service not known: No such file or directory

The ftp has been down for a while now. I wasn't sure if I had to
indicate the original ftp site, or the copy I uploaded on sf.net:

http://sf.net/projects/jpeg

-> 
https://sourceforge.net/project/showfiles.php?group_id=143299&package_id=157390

-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Building Debian from Sources

[Thiemo Seufer]

Mustafa KYR wrote:
> Hello,
> I am a new engineer and I was just a debian user in my former life. I want
> to build debian linux from sources to understand it all. I spent lots of
> time during search about it.

I'm not sure how much building from source will help your understanding,
but anyway, http://oldpeople.debian.org/~jgoerzen/dfs/ is probably the
thing closest to your request.


Thiemo


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#508992: ITP: pvrg -- JPEG implementation from Standford

[Ron Johnson]

On 12/17/08 03:57, Mathieu Malaterre wrote:

Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 


* Package name: pvrg
  Version : 1.2.1
  Upstream Author : Andy C. Hung 
* URL : ftp://havefun.stanford.edu:pub/jpeg/JPEGv1.2.tar.Z.


$ mtr havefun.stanford.edu
Couldn't get fd's flags: Bad file descriptor
Name or service not known: No such file or directory

--
Ron Johnson, Jr.
Jefferson LA  USA

How does being physically handicapped make me Differently-Abled?
What different abilities do I have?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#508725: ITP:pmwiki -- easy of use wiki-based system

[Chris Bannister]

On Sun, Dec 14, 2008 at 02:16:37PM -0500, Cristian Paul Peñaranda Rojas wrote:
> X-Debbugs-CC: debian-devel@lists.debian.org
> Package: pmwiki
> Severity: wishlist
> Owner: cristian paul peñaranda rojas 
> 
> * Package name  : pmwiki
>   Version   : 2.2.0
>   Upstream Author : Patrick R. Michaud 
> * URL   : http://www.pmwiki.org
>   License   : GPL
>   Programming Lang: PHP
> 
> Description: easy of use wiki-based system

Should be: "easy to use wiki based system."

>  PmWiki is designed to be easy to install and customize as an engine for
> creating professional web sites with one to any number of content authors.
> The software focuses on ease-of-use, so people with little IT or wiki
> experience will be able to put it to use. Also extemely extensible
> and customizable
-- 
Chris.
==
I contend that we are both atheists. I just believe in one fewer god
than you do. When you understand why you dismiss all the other
possible gods, you will understand why I dismiss yours.
   -- Stephen F Roberts


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Gtk1.2/Imlib/gnome-lib packages (Long)

[Andreas Tille]

On Wed, 17 Dec 2008, Barry deFreese wrote:


sqlrelay
  Some of the binaries have decent popcons.  We could probably either port 
sqlrelay-config-gtk or just remove that binary for now.


I'd also strongly vote for only droping this specific binary in case this
would be a Gtk 1.2 removal blocker but keeping sqlrelay in any case.  It
works perfectly without the config-gtk thingy .

Thanks for your investigation and patches

  Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#508990: ITP: dicomscope -- DICOMscope - DICOM Viewer

[Mathieu Malaterre]

On Wed, Dec 17, 2008 at 2:10 PM, Ron Johnson  wrote:
> On 12/17/08 03:29, Mathieu Malaterre wrote:
>>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Mathieu Malaterre 
>>
>>
>> * Package name: dicomscope
>>  Version : 3.5.1
>>  Upstream Author : OFFIS DICOM Team 
>> * URL : http://dicom.offis.de/dscope.php.en
>> * License : Copyright (C) 1994-2004, OFFIS
>>  Programming Lang: C, C++
>>  Description : DICOMscope - DICOM Viewer
>>
>
>> DICOMscope is a free DICOM viewer which can display uncompressed,
>> monochrome DICOM images from all modalities and which supports
>> monitor calibration according to DICOM part 14 as well as
>> presentation states. DICOMscope offers a print client (DICOM
>> Basic Grayscale Print Management) which also implements the
>> optional Presentation LUT SOP Class.
>
>  BEGIN questionable verbiage
>>
>> The development of this
>> prototype was commissioned by the "Committee for the Advancement
>> of DICOM" and demonstrated at the European Congress of Radiology
>> ECR 1999. An enhanced version was developed for the "DICOM
>> Display Consistency Demonstration" at RSNA InfoRAD 1999. The
>> current release 3.5.1 has been demonstrated at ECR 2001 and
>> contains numerous extensions, including a print server, support
>> for encrypted DICOM communication, digital signatures and
>> structured reporting.
>>
>> DICOMscope is not meant as a competition for commercial DICOM
>> viewers. The application is rather a feasibility study for DICOM
>> presentation states. The program is not appropriate to be used in
>> a clinical environment, e.g. for reporting.
>
>  END
>
> Does this really have to be in the long description, or should it be in the
> README.Debian?

Ok will do. Thanks for comments

-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#508990: ITP: dicomscope -- DICOMscope - DICOM Viewer

[Mathieu Malaterre]

Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 


* Package name: dicomscope
  Version : 3.5.1
  Upstream Author : OFFIS DICOM Team 
* URL : http://dicom.offis.de/dscope.php.en
* License : Copyright (C) 1994-2004, OFFIS
  Programming Lang: C, C++
  Description : DICOMscope - DICOM Viewer

 DICOMscope is a free DICOM viewer which can display uncompressed, monochrome 
DICOM images from all modalities and which supports monitor calibration 
according to DICOM part 14 as well as presentation states. DICOMscope offers a 
print client (DICOM Basic Grayscale Print Management) which also implements the 
optional Presentation LUT SOP Class. The development of this prototype was 
commissioned by the "Committee for the Advancement of DICOM" and demonstrated 
at the European Congress of Radiology ECR 1999. An enhanced version was 
developed for the "DICOM Display Consistency Demonstration" at RSNA InfoRAD 
1999. The current release 3.5.1 has been demonstrated at ECR 2001 and contains 
numerous extensions, including a print server, support for encrypted DICOM 
communication, digital signatures and structured reporting.

 DICOMscope is not meant as a competition for commercial DICOM viewers. The 
application is rather a feasibility study for DICOM presentation states. The 
program is not appropriate to be used in a clinical environment, e.g. for 
reporting.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable'), (50, 'testing'), (40, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: First call for votes for the Lenny release GR

[David Weinehall]

On Wed, Dec 17, 2008 at 01:54:40PM -0600, Manoj Srivastava wrote:
> On Mon, Dec 15 2008, Russ Allbery wrote:
> 
> > Thomas Weber  writes:
> >> Am Montag, den 15.12.2008, 10:06 + schrieb Steve McIntyre:
> >
> >>> I've been talking with Manoj already, in private to try and avoid
> >>> flaming. I specifically asked him to delay this vote until the numerous
> >>> problems with it were fixed, and it was started anyway. I'm *really*
> >>> not happy with that, and I'm following through now.
> >>
> >> Uh, I don't quite get this: you shortened the discussion period, but at
> >> the same time asked the secretary to delay the vote?
> >
> > Where did Steve shorten the discussion period?  He did so for the *other*
> > vote, but I haven't seen a thread where he did for this one.  (I may have
> > just missed it.)
> 
> I mis remembered.  Steve shortened the discussion period for
>  this vote, and the discussion and voting period for the _other_ vote,
>  but I missed that the vote period for the gr_lenny vote was not
>  shortened. I'll send out a new CFV.

OK, does this mean that everyone who already cast their vote will need
to do so again, or will the voting period simply be extended another
week?


Regards: David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: First call for votes for the Lenny release GR

[Manoj Srivastava]

On Wed, Dec 17 2008, David Weinehall wrote:

> On Wed, Dec 17, 2008 at 01:54:40PM -0600, Manoj Srivastava wrote:
>> On Mon, Dec 15 2008, Russ Allbery wrote:
>> 
>> > Thomas Weber  writes:
>> >> Am Montag, den 15.12.2008, 10:06 + schrieb Steve McIntyre:
>> >
>> >>> I've been talking with Manoj already, in private to try and avoid
>> >>> flaming. I specifically asked him to delay this vote until the numerous
>> >>> problems with it were fixed, and it was started anyway. I'm *really*
>> >>> not happy with that, and I'm following through now.
>> >>
>> >> Uh, I don't quite get this: you shortened the discussion period, but at
>> >> the same time asked the secretary to delay the vote?
>> >
>> > Where did Steve shorten the discussion period?  He did so for the *other*
>> > vote, but I haven't seen a thread where he did for this one.  (I may have
>> > just missed it.)
>> 
>> I mis remembered.  Steve shortened the discussion period for
>>  this vote, and the discussion and voting period for the _other_ vote,
>>  but I missed that the vote period for the gr_lenny vote was not
>>  shortened. I'll send out a new CFV.
>
> OK, does this mean that everyone who already cast their vote will need
> to do so again, or will the voting period simply be extended another
> week?

I was just thinking of postposing the end-of-vote cron job, so
 no re-voting would be needed.

If there is sufficient support, we could also scrap the current
 vote, change our ballot, add options to it, or something, and restart
 the vote, but that would  need a strong grass roots support (I do not
 think the secretary has the power to do so).

manoj
-- 
today, n.: A nice place to visit, but you can't stay here for long.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: First call for votes for the Lenny release GR

[Margarita Manterola]

On Wed, Dec 17, 2008 at 9:02 PM, Manoj Srivastava  wrote:
>If there is sufficient support, we could also scrap the current
>  vote, change our ballot, add options to it, or something, and restart
>  the vote, but that would  need a strong grass roots support (I do not
>  think the secretary has the power to do so).

As far as I understand from reading the immense threads, most people
(me included) don't want more options in the ballot.  We want separate
ballots for separate subjects. This means that 4 and 6 should get
their own ballot.  This is not "gaming" the system, it's voting
separate subjects separately.

Also, titles should summarize the included text without bias. i.e. 1:
"Delay the release of lenny until all licensing problems are solved",
5: "Allow sourceless firmware as long as the license complies with
DFSG", and probably 4, too, since the text does not speak about "DFSG
violations" but rather "usage of problematic software".

And finally, if we were to do the vote again, there really is no need
to have the trio of 2, 3 and 5.  They are basically the same thing,
you need to be extremely "into" the problem to understand the
differences.  Only one option, crafted by those who have real
knowledge of what the actual problems are (and that does not requiere
3:1 majority), would be enough.

If we do all this, we would be voting:

A) If we trust or not the release team on making the right choices of
which bugs to ignore and which not (regardless of this being firmware
issues or what have you).  This is from now on, not just for Lenny.

B) If we want to allow sourceless firmware in Debian, defining
firmware in a way that doesn't give a waiver to anything else without
source. This is also from now on, not just for Lenny. But it's only
for firmware, not for everything with licensing problems.

C) If we want to allow stuff with some problems into Lenny, as we
already did for Sarge and Etch.

These three issues are obviously related, but are NOT the same issue,
a positive result in one does not determine what happens to the
others.  And creating one mega ballot with all the different
possibilities, only creates confusion and frustration.  So, this
should be three independent ballots.

This is, basically the same that dato proposed:
http://lists.debian.org/debian-vote/2008/11/msg00126.html

And I think (I haven't counted, but I've followed the threads, the
chats and the blogs) that most developers that have participated on
this matter have manifested that they would prefer a group of sensible
ballots to the monster ballot we have now.

I hope that you can take that into consideration.

-- 
Love,
Marga


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#509063: ITP: libproxy -- automatic proxy configuration management library

[Emilio Pozuelo Monfort]

Package: wnpp
Severity: wishlist
Owner: Emilio Pozuelo Monfort 


* Package name: libproxy
  Version : 0.2.3
  Upstream Author : Nathaniel McCallum 
Alex Panait
* URL : http://code.google.com/p/libproxy/
* License : LGPL
  Programming Lang: C
  Description : automatic proxy configuration management library

 libproxy is a lightweight library which makes it easy to develop
 applications proxy-aware with a simple and stable API.


-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Packages still depending on GTK+ 1.2

[Drew Parsons]

> 
> GTK+ 1.2 has been deprecated upstream for 6 years. There is no security
> support for it, and no new applications using it have been out for quite
> a long time as well.
> 
> 
> Here is a first list of packages that could either be removed right now
> because they seem to have replacements, or updated with little work. If
> there are no objections, I think we should ask for removal of all of
> those which don’t have a GTK+ 2 version.
> 
> 
> Drew Parsons 
>zangband
>  => yay, a rogue game

zangband has features not present in other rogue clones, namely an
outdoor wilderness environment connecting different towns and different
dungeons.

The chief charm of the rogue clones is their beautiful ascii animation.
To my mind the gtk interface is a step backwards which defeats the
point of these dumb but addictive little games.

There is no need to remove zangband, we can simply drop the gtk build
instead if required.

Drew



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: First call for votes for the Lenny release GR

[Brian May]

Margarita Manterola wrote:

If we do all this, we would be voting:

A) If we trust or not the release team on making the right choices of
which bugs to ignore and which not (regardless of this being firmware
issues or what have you).  This is from now on, not just for Lenny.

B) If we want to allow sourceless firmware in Debian, defining
firmware in a way that doesn't give a waiver to anything else without
source. This is also from now on, not just for Lenny. But it's only
for firmware, not for everything with licensing problems.

C) If we want to allow stuff with some problems into Lenny, as we
already did for Sarge and Etch.

These three issues are obviously related, but are NOT the same issue,
a positive result in one does not determine what happens to the
others.  And creating one mega ballot with all the different
possibilities, only creates confusion and frustration.  So, this
should be three independent ballots.
  


I think the concern is, what if the results conflict?

e.g. if we get a "No" for (C) but Yes for (A). We trust the release team 
to make the right choices but we don't trust them to make the right 
choices for Lenny?


My suggestion would be to vote for (C) first, and then decide the 
wording on (A) and (B) depending on the outcome of (C). In which case, 
even if there is a conflict, the wording can clarify if the second vote 
overrides or doesn't override the first result.


--
Brian May 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Gtk1.2/Imlib/gnome-lib packages (Long)

[Paul Wise]

On Thu, Dec 18, 2008 at 2:03 AM, Barry deFreese  wrote:

> Just in case anyone cares/is interested, here is some work I have been doing
> on packages using Gtk1.2, Imlib, gnome-libs, or any combination thereof.

The playdv binary from libdv-bin can be dropped until it is ported to
GTK+ 2, bug filed upstream:

http://sourceforge.net/tracker/index.php?func=detail&aid=1925173&group_id=4393&atid=354393

PS: cult??

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: First call for votes for the Lenny release GR

[Russell Coker]

On Thursday 18 December 2008 11:45, Brian May  
wrote:
> Margarita Manterola wrote:
> > If we do all this, we would be voting:
> >
> > A) If we trust or not the release team on making the right choices of
> > which bugs to ignore and which not (regardless of this being firmware
> > issues or what have you).  This is from now on, not just for Lenny.
> >
> > B) If we want to allow sourceless firmware in Debian, defining
> > firmware in a way that doesn't give a waiver to anything else without
> > source. This is also from now on, not just for Lenny. But it's only
> > for firmware, not for everything with licensing problems.
> >
> > C) If we want to allow stuff with some problems into Lenny, as we
> > already did for Sarge and Etch.
>
> My suggestion would be to vote for (C) first, and then decide the
> wording on (A) and (B) depending on the outcome of (C). In which case,
> even if there is a conflict, the wording can clarify if the second vote
> overrides or doesn't override the first result.

This makes sense to me.

I would like to see the current vote abandoned.  Manoj said that this will be 
done if there is sufficient grass-roots support.  We have had a series of 
blog posts on Planet Debian from people who don't like the current vote.  I 
like Brian's idea (or something similar).

It seems that the grass-roots support for doing something quite different to 
the current vote includes me, Brian, and quite a few bloggers on Planet 
Debian.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable -> testing

[Russell Coker]

On Wednesday 17 December 2008 10:55, Tzafrir Cohen  
wrote:
> > The Fedora vs RHEL model that Red Hat uses has some benefits.
>
> The Fedora and RHEL is:
>
> Fedora: a somewhat equivalent of Debian Testing. The rules for updating
> a package even after a version is released are way more laxed than
> Debian Stable.

In terms of the requirements for version updates, Debian/Testing and Fedora 
are quite similar.  Debian/Testing is often suggested for home (not 
corporate) desktop use and Fedora is the home desktop system from Red Hat.

> RHEL: Much less software. You can't expect to maintain the whole
> archive of Debian Stable for 5 or 7 years without it. There are many
> packages I miss in the CentOS archive.

True.

There are a number of possibilities for alleviating this.  One suggestion that 
has been made is to split Debian into different sections with different 
release requirements.  One possible way of doing this is to have one section 
for core and server software which would also be the base for a Fedora-like 
distribution and the entire package list for a CentOS/RHEL like distribution.

One possibility if we were to have a Debian equivalent to CentOS/RHEL would be 
to have apt sources repositories from newer distributions.  Having a system 
with most packages coming from a stable binary package set and a couple of 
missing packages compiled from a source base such as Debian/Testing should 
give a good result.

If I could find a good set of package sources that would build on CentOS then 
my CentOS sys-admin work would be a lot easier.

> Also note that none of those distribution has a distinction between
> "server" and "desktop" in the release cycle management. Ubuntu has a
> "server" variant, but it is merely a way to package different packages
> and defaults into the installation CD. RHEL has a distinction between
> "server" and "desktop", but I figure that this is because supporting a
> server instance costs more (or that people are willing to pay more for
> it).

The various versions of RHEL have different price-points and different package 
sets.  Pay more money and more server packages are supported.

The recommended use of Fedora is desktops not servers.  While desktop 
environments are supported in RHEL, this tends to be mostly centrally managed 
corporate desktops not individual one-off systems - so it's a similar 
situation to servers in terms of a resource being centrally managed by the IT 
group.  You can consider the release cycle difference between Fedora and RHEL 
to be the difference between desktop and server systems.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org