Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk, and java-jre/jdk

2010-04-06 Thread Niels Thykier

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

tag 365408 + wontfix
thanks

Hi

Based the latest entries and the latest update to the policy, I am marking 
this as wontfix. That being said, I intend to propose the removal of the 
java*-compiler packages.


~Niels

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Topal (http://freshmeat.net/projects/topal)

iEYEARECAAYFAku7ApoACgkQVCqoiq1Ylqxr+QCdG2YfTp4pi07ZxMW5EGvfZ/jh
RCYAoKZCCdgMh15HSKCfXLXrW3mf96Wk
=U7Ef
-END PGP SIGNATURE-



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



Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

2006-05-26 Thread Michael Koch
On Mon, May 22, 2006 at 06:03:19PM -0400, Charles Fry wrote:
   A virtual package name is a functional label, not a product name.
   Java is the name of an island and a natural language too. 
   I'm surprised if Sun can prevent use of a word in this way.
  
  A function that is used to call a runtime, compiler, etc of the Java(tm)
  language!
  
  Java? is a trademark of Sun Microsystems.
 
 There are already many free packages that provide a binary (or symlink
 to a binary) named java. There is one package named 'free-java-sdk'
 which uses the name java, as well as the previously mentioned virtual
 packages which we already have. It seems reasonable to continue to use
 the word java in the virtual packages which provide binaries named java.

The package name free-java-sdk is really a bad example as this package
has really a bad history. The SableVM people just want to force users to
use their VM. This package is not in line with the Debian Java
maintainers.

I still think that we need a distinction between classpath-derived and
SUN-derived VMs. Perhaps later for Harmony-derived VMs too. All families
have their issues. They ever will be. To work with this we need a clear
naming for the virtual packages. The classpaht-* and java-* solution
does this. The solultion you proposed does this only partially.


Cheers,
Michael
-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/


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



Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

2006-05-23 Thread MJ Ray
Arnaud Vandyck [EMAIL PROTECTED]
 MJ Ray a €crit :
 [...]
  A virtual package name is a functional label, not a product name.
  Java is the name of an island and a natural language too. 
  I'm surprised if Sun can prevent use of a word in this way.
 
 A function that is used to call a runtime, compiler, etc of the Java(tm)
 language!

A package name does not call the language.

Java is the name of an island.
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct



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



Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

2006-05-22 Thread Arnaud Vandyck
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

MJ Ray a écrit :
[...]
 A virtual package name is a functional label, not a product name.
 Java is the name of an island and a natural language too. 
 I'm surprised if Sun can prevent use of a word in this way.

A function that is used to call a runtime, compiler, etc of the Java(tm)
language!

Java? is a trademark of Sun Microsystems.

- --
Arnaud Vandyck, STE fi, ULg
Formateur Cellule Programmation.
Java Trap: http://www.gnu.org/philosophy/java-trap.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEceY34vzFZu62tMIRAhIBAJ9V4KCUXK/T9tnbamzmT/kK496V+QCeLoOg
G3m4rBxbMokjUR46sYFVu6Y=
=4NHo
-END PGP SIGNATURE-
begin:vcard
fn:Arnaud Vandyck
n:Vandyck;Arnaud
org;quoted-printable:Universit=C3=A9 de Li=C3=A8ge;STE-Formations Informatiques
adr;quoted-printable;quoted-printable;quoted-printable:B=C3=A2timent C1;;Rue Armand St=C3=A9vard, 2;Li=C3=A8ge;;4000;Belgique
email;internet:[EMAIL PROTECTED]
title;quoted-printable:Attach=C3=A9 (formateur)
tel;work:+32 4 366 90 55
tel;fax:+32 4 366 90 59
tel;home:+32 4 349 09 69
tel;cell:+32 486 31 10 47
x-mozilla-html:FALSE
url:http://www.ste.fapse.ulg.ac.be/
version:2.1
end:vcard



Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

2006-05-22 Thread Charles Fry
  A virtual package name is a functional label, not a product name.
  Java is the name of an island and a natural language too. 
  I'm surprised if Sun can prevent use of a word in this way.
 
 A function that is used to call a runtime, compiler, etc of the Java(tm)
 language!
 
 Java? is a trademark of Sun Microsystems.

There are already many free packages that provide a binary (or symlink
to a binary) named java. There is one package named 'free-java-sdk'
which uses the name java, as well as the previously mentioned virtual
packages which we already have. It seems reasonable to continue to use
the word java in the virtual packages which provide binaries named java.

Charles

-- 
On a highway ad
He spied it
Bought a jar
Now glad he
Tried it
Burma-Shave
http://burma-shave.org/jingles/1938/on_a_highway


signature.asc
Description: Digital signature


Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

2006-05-18 Thread Arnaud Vandyck
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cc'ing to debian-legal: summary:
The major question is about replacing java1-runtime, java1-compiler,
java2-runtime and java2-compiler virtual packages by classpath-jre,
classpath-jdk for free java implementation and java-jre and java-jdk for
non-free implementations. More informations on the bug report #365408.
Thanks to Cc to the bug report.

Charles Fry a écrit :
[...]
 But I strongly disagree with using classpath-* for free versions, and
 saving java for non-free implementations. That encourages the use of the
 non-free implementations.

No because java programs that work with free implementations will depend
on classpath-jre.

 How about java-* for both free and non-free, and then if some package
 explicitely requires non-free they can depend on sun-java5-jre.

I think we have to ask on debian-legal about this but I'm sure we cannot
use the java word if it's not something that has been approved by Sun.

Cheers,

- --
  .''`.
 : :' :rnaud
 `. `'
   `-
Java Trap: http://www.gnu.org/philosophy/java-trap.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEbE0i4vzFZu62tMIRAnAvAJ9TtTttz+a46PRaC3yb8nPxGKAgTACfQdfq
GMUyaRnDFDjt/or3Og+Dg6o=
=vHE4
-END PGP SIGNATURE-


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



Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

2006-05-18 Thread MJ Ray
Arnaud Vandyck [EMAIL PROTECTED]
 The major question is about replacing java1-runtime, java1-compiler,
 java2-runtime and java2-compiler virtual packages by classpath-jre,
 classpath-jdk for free java implementation and java-jre and java-jdk for
 non-free implementations. More informations on the bug report #365408.
 Thanks to Cc to the bug report.

The java* virtual package names should not direct people to non-free
implementations when there are free implementations available.
This is a project-y opinion rather than a legal-y one.

 Charles Fry a €crit :
 [...]
  But I strongly disagree with using classpath-* for free versions, and
  saving java for non-free implementations. That encourages the use of the
  non-free implementations.
 
 No because java programs that work with free implementations will depend
 on classpath-jre.

I think enough users will ask for Java in particular to cause problems.

  How about java-* for both free and non-free, and then if some package
  explicitely requires non-free they can depend on sun-java5-jre.
 
 I think we have to ask on debian-legal about this but I'm sure we cannot
 use the java word if it's not something that has been approved by Sun.

A virtual package name is a functional label, not a product name.
Java is the name of an island and a natural language too. 
I'm surprised if Sun can prevent use of a word in this way.
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct



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



Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

2006-05-17 Thread Arnaud Vandyck
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Charles Fry a écrit :

[...]

  2) I don't see the trademark problem. There are already virtual
 packages that use the word java. What would be the difference
 between continuing the same trend?

There is a trademark problem. The java1|2 virtual packages were targeted
to Sun's, IBM's and Blackdown JVM version 1.1.x and 1.2. By extension,
we have use the virtual packages with java1 for free runtimes and java2
for non-free runtimes. But I'm pretty sure there is a legal problem here.

Maybe you have another proposal (I mean a legal one ;-))
 
 As far as I can tell, the only real issue is #1 above. If that is the
 case then I propose:
 
 java-jre
 java-jdk

This is not a problem if you refer to a Sun trademarked Java product
(and affiliated vendors like IBM, Blackdown etc)

 java-jre-nonfree
 java-jdk-nonfree

So you think Sun will be OK with that? I'm not sure.

 The first two would be used by all implementations, whether free of
 non-free. The last two would be reserved for non-free implementations.

That's what we want but with classpath-* for free java and java-* for
non-free implementations.

Cheers,

- --
  .''`.
 : :' :rnaud
 `. `'
   `-
Java Trap: http://www.gnu.org/philosophy/java-trap.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEa6z44vzFZu62tMIRAnQeAJ0dvEtTrYeblv2cuZVRuqMsR1hYSACfZYDH
6Rt2R2nEgboejyaG9xKdhMg=
=XoOJ
-END PGP SIGNATURE-


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



Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

2006-05-17 Thread Charles Fry
   2) I don't see the trademark problem. There are already virtual
  packages that use the word java. What would be the difference
  between continuing the same trend?
 
 There is a trademark problem. The java1|2 virtual packages were targeted
 to Sun's, IBM's and Blackdown JVM version 1.1.x and 1.2. By extension,
 we have use the virtual packages with java1 for free runtimes and java2
 for non-free runtimes. But I'm pretty sure there is a legal problem here.

The fact is that java1 has been used by free runtimes, so I don't see
any reason why something with the word java would be any different now.
If there is a legal problem, it should be specifically identified.

 Maybe you have another proposal (I mean a legal one ;-))
  
  As far as I can tell, the only real issue is #1 above. If that is the
  case then I propose:
  
  java-jre
  java-jdk
 
 This is not a problem if you refer to a Sun trademarked Java product
 (and affiliated vendors like IBM, Blackdown etc)
 
  java-jre-nonfree
  java-jdk-nonfree
 
 So you think Sun will be OK with that? I'm not sure.
 
  The first two would be used by all implementations, whether free of
  non-free. The last two would be reserved for non-free implementations.
 
 That's what we want but with classpath-* for free java and java-* for
 non-free implementations.

But I strongly disagree with using classpath-* for free versions, and
saving java for non-free implementations. That encourages the use of the
non-free implementations.

How about java-* for both free and non-free, and then if some package
explicitely requires non-free they can depend on sun-java5-jre.

Charles

-- 
Saves your Jack -- Holds your Jill
Burma-Shave
http://burma-shave.org/jingles/1939/saves_your_jack


signature.asc
Description: Digital signature


Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

2006-05-11 Thread Arnaud Vandyck
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Charles Fry wrote:
Note that I added a paragraph from a proposal from Stefan Gybas,
modified by Ben Burton (see Bug#227587). Even if they did not really get
a consensus, I think, with the change of the virtual packages to
classpath-jre, classpath-jdk, java-jre and java-jdk, the proposal of
Stefan is good to integrate in our policy.
 
 I strongly oppose the classpath/java distinction for classpath vs.
 non-free JREs and JDKs. Instead I propose dropping classpath-* as well,
 and only using java-jre and java-jdk.

So people that wants to use Java should install non-free software?
That's not possible in Debian!

 Maybe I just have never seen a place where the distinction would be
 useful, but in my mind it widens the gap between free and non-free Java
 implementations. An ideal Debian world should, it seems, define JRE and
 JDK virtual packages in a way that works for free implementations, and
 can then be used for non-free implementations.

You are right but it's not the actual reality. When free vm's will be
100% compatible with non-free ones, maybe we'll be able to drop the
classpath-* virtual packages, but keep in mind that Java is a trademark
of Sun Microsystems and in the license of Java, we couldn't replace a
tool from the jdk with another with the same functionality!

I'm not sure Sun Microsystems'd like the idea of our virtual java-*
packages to be provided by free vm's! I'm really not sure this is legal!

Maybe you have another proposal (I mean a legal one ;-))

Cheers,

- --
  .''`.
 : :' :rnaud
 `. `'
   `-
Java Trap: http://www.gnu.org/philosophy/java-trap.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEYzPv4vzFZu62tMIRAkJiAJ0UqIbvQLhD96ulbQGJYD7M4VH7cgCgqpe3
71q5UXeiX+J7VfJ1VWKeSbc=
=WfGe
-END PGP SIGNATURE-


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



Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

2006-05-11 Thread Charles Fry
  I strongly oppose the classpath/java distinction for classpath vs.
  non-free JREs and JDKs. Instead I propose dropping classpath-* as well,
  and only using java-jre and java-jdk.
 
 So people that wants to use Java should install non-free software?
 That's not possible in Debian!

No, I want them to be able to use free software by default. The current
distinction will lead people to nonfree solutions by default.

  Maybe I just have never seen a place where the distinction would be
  useful, but in my mind it widens the gap between free and non-free Java
  implementations. An ideal Debian world should, it seems, define JRE and
  JDK virtual packages in a way that works for free implementations, and
  can then be used for non-free implementations.
 
 You are right but it's not the actual reality. When free vm's will be
 100% compatible with non-free ones, maybe we'll be able to drop the
 classpath-* virtual packages, but keep in mind that Java is a trademark
 of Sun Microsystems and in the license of Java, we couldn't replace a
 tool from the jdk with another with the same functionality!

It seems that there are two separate issues. Let me be sure that I
understand them correctly:

 1) You want to have different virtual packages for free and non-free
JVMs so that when there is no free JVM to meet a packages needs it
can depend on a generic non-free JVM?

 2) I don't see the trademark problem. There are already virtual
packages that use the word java. What would be the difference
between continuing the same trend?

 I'm not sure Sun Microsystems'd like the idea of our virtual java-*
 packages to be provided by free vm's! I'm really not sure this is legal!

See point #2 above.

 Maybe you have another proposal (I mean a legal one ;-))

As far as I can tell, the only real issue is #1 above. If that is the
case then I propose:

java-jre
java-jdk

java-jre-nonfree
java-jdk-nonfree

The first two would be used by all implementations, whether free of
non-free. The last two would be reserved for non-free implementations.

Charles

-- 
The wolf
Is shaved
So neat and trim
Red Riding Hood
Is chasing him
Burma-Shave
http://burma-shave.org/jingles/1952/the_wolf


signature.asc
Description: Digital signature


Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

2006-05-08 Thread Charles Fry
 Note that I added a paragraph from a proposal from Stefan Gybas,
 modified by Ben Burton (see Bug#227587). Even if they did not really get
 a consensus, I think, with the change of the virtual packages to
 classpath-jre, classpath-jdk, java-jre and java-jdk, the proposal of
 Stefan is good to integrate in our policy.

I strongly oppose the classpath/java distinction for classpath vs.
non-free JREs and JDKs. Instead I propose dropping classpath-* as well,
and only using java-jre and java-jdk.

Maybe I just have never seen a place where the distinction would be
useful, but in my mind it widens the gap between free and non-free Java
implementations. An ideal Debian world should, it seems, define JRE and
JDK virtual packages in a way that works for free implementations, and
can then be used for non-free implementations.

Charles

-- 
His face
Was loved
By just his mother
He Burma-Shaved
And now--
Oh, brother
http://burma-shave.org/jingles/1949/his_face


signature.asc
Description: Digital signature


Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

2006-04-29 Thread Arnaud Vandyck
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

package: java-common
version: 0.24

Hi all,

One of the result of our discussions in Oldenburg (devjam) and in
Bruxelles (FOSDEM) is about the use of the virtual packages.

One of our reflexion was the number in the java*-runtime and
java*-compiler was not useful anymore. First, nobody uses Java 1 and the
state of GNU Classpath is far better then Java 1.

For some informations, you can go to the draft:
http://wiki.debian.org/Java/Draft

I'd like to reach a consensus about the attached patch before sending
other proposals.

If you read the wiki, you'll notice I added a line with *later* so I
know where I have to re-start the futur proposals.

Note that I added a paragraph from a proposal from Stefan Gybas,
modified by Ben Burton (see Bug#227587). Even if they did not really get
a consensus, I think, with the change of the virtual packages to
classpath-jre, classpath-jdk, java-jre and java-jdk, the proposal of
Stefan is good to integrate in our policy.

I also integrated another proposal from Stefan Gybas, seconded by Ben
Burton (see Bug#227594). There was a consensus about it so I don't think
we need further discussion about this.

With this proposal, we can close:
- - this bug ;-) ;
- - #227587 (integrate the java libs dependency);
- - #227594 (integrate the removal of 'binfmt_misc');
- - #158984 (no more java 2 something);
- - #354026 (no more java*-runtime);
- - #166370 (because we have *-jdk and not *-compiler);

I attached a patch so it'd be easier to read.

Thanks for your comments or for seconding the proposal,

- --
  .''`.
 : :' :rnaud
 `. `'
   `-
Java Trap: http://www.gnu.org/philosophy/java-trap.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEU8ju4vzFZu62tMIRAlqPAJ0bi7Cv/BTQ8WTw1TCrqRpEXVrCRQCfUFxH
x4KgDEiCjdpFukjpoDqpXkc=
=qDAF
-END PGP SIGNATURE-
Index: policy.xml
===
--- policy.xml	(revision 2101)
+++ policy.xml	(working copy)
@@ -5,11 +5,11 @@
 !ENTITY must emphasismust/emphasis
 !ENTITY may emphasismay/emphasis
 !ENTITY should emphasisshould/emphasis
-!ENTITY jvm emphasisjava-virtual-machine/emphasis
-!ENTITY j1r emphasisjava1-runtime/emphasis
-!ENTITY j2r emphasisjava2-runtime/emphasis
-!ENTITY jc emphasisjava-compiler/emphasis
-!ENTITY j2c emphasisjava2-compiler/emphasis
+!ENTITY jjre emphasisjava-jre/emphasis
+!ENTITY jjdk emphasisjava-jdk/emphasis
+!ENTITY cjre emphasisclasspath-jre/emphasis
+!ENTITY cjdk emphasisclasspath-jdk/emphasis
+!ENTITY djava emaildebian-java@lists.debian.org/email
 ]
 
 book
@@ -18,11 +18,11 @@
 edition$Revision:$ $Date:$/edition
 authorgroup
   author
-	surnameLundqvist/surname
-	firstnameOla/firstname
+	surnameVandyck/surname
+	firstnameArnaud/firstname
 	authorblurb
 	  para
-	email[EMAIL PROTECTED]/email
+	email[EMAIL PROTECTED]/email
 	  /para
 	  para
 	The current author of the java policy.
@@ -30,6 +30,15 @@
 	/authorblurb
   /author
   author
+	surnameLundqvist/surname
+	firstnameOla/firstname
+	authorblurb
+	  para
+	email[EMAIL PROTECTED]/email
+	  /para
+	/authorblurb
+  /author
+  author
 	surnameBortzmeyer/surname
 	firstnameStephane/firstname
 	authorblurb
@@ -45,7 +54,7 @@
 	authorblurb
 	  para
 	Most issues of the java policy have been discussed on the
-	emaildebian-java@lists.debian.org/email mailinglist.
+	djava; mailinglist.
 	  /para
 	/authorblurb
   /author
@@ -83,7 +92,7 @@
   Feel free to report comments, suggestions and/or disagreements to the
   java-common package (email[EMAIL PROTECTED]/email)
   or the Debian Java mailing list
-  emaildebian-java@lists.debian.org/email. Change requests should
+  djava;. Change requests should
   be sent as a bug to the java-common package.
 /para
 
@@ -93,8 +102,8 @@
 titlePolicy/title
 
 para
-  Virtual packages are created: jc;, j2c;,
-  jvm;, j1r; and j2r;.
+  Virtual packages are created: jjre;, jjdk;,
+  cjre; and cjdk;.
 /para
 
 para
@@ -111,10 +120,10 @@
 para
   Both are shipped as Java bytecode (filename*.class/filename
   files, packaged in a filename*.jar/filename archive) and with
-  an Architecture: all since Java bytecode is supposed to be portable.
-  It may additionally be shipped as machine code, as produced for example
-  by the GNU Compiler for Java, in a separate architecture-specific
-  package.
+  an Architecture: all since Java bytecode is supposed to be
+  portable. It may additionally be shipped as BC (binary compatible)
+  compiled machine code, as produced by the GNU Compiler for Java,
+  in a separate architecture-specific package.
 /para
 
 para
@@ -126,38 +135,27 @@
   titleVirtual machines/title
   
   para
-	Java virtual machines must; provide jvm; and
-	depend on 

Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

2006-04-29 Thread Arnaud Vandyck
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Arnaud Vandyck wrote:
[...]
 One of the result of our discussions in Oldenburg (devjam) and in
 Bruxelles (FOSDEM) is about the use of the virtual packages.

I forgot to thanks Wolfgang Baer, Michael Koch, Matthias Klose, Stefan
Gybas, Ben Burton and all those who participated in the discussions
(sorry if I forgot some people).

- --
  .''`.
 : :' :rnaud
 `. `'
   `-
Java Trap: http://www.gnu.org/philosophy/java-trap.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEU85X4vzFZu62tMIRAshaAKCceYXvUIb/MRBC7XAKr0BE88q/CgCgryT8
JUcF9rQyCntGEFukY44XbKA=
=iNkx
-END PGP SIGNATURE-


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