Re: RFC: Better portability for package maintainers

[George Danchev]

On Sunday 21 May 2006 05:35, Erast Benson wrote:
> On Sat, 2006-05-20 at 21:11 +0200, Steinar H. Gunderson wrote:
> > On Sat, May 20, 2006 at 11:51:09AM -0700, Erast Benson wrote:
> > > Do you really believe so? Do you understand that such a "hybrid" will
> > > not run any existing Solaris apps like you will not be able to run
> > > simple thinks like Macromedia flush player, JRE, JDK, Oracle, SAP, etc
> > > etc... Do you still wanna do that?
> >
> > Erm.
> >
> > If Oracle and SAP are on your list of “simple things”, what then are
> > large complex things for you?
>
> But I hope you still got me right. For me, all these "things" are
> existing applications which must run. The world is not 100% open sourced
> yet and we are in it, we are part of it, therefore my ideal OS need to
> be capable to run existing freeware and closed binaries as is without
> re-compilation. I want to run VMware, Oracle, Skype, SAP, Macromedia
> flush, etc, etc, etc. I want my Nexenta to run DTrace, BrandZ
> virtualization, ZFS, Zones without major re-design, etc, etc, etc...
>
> Once you accompany OpenSolaris kernel with GLIBC, you will kill this
> capability, you will not be able to run anything other than OSS compiled
> for your particular distro. That was my point. And isn't LSB is what
> GNU/Linux moving towards to? In OpenSolaris we have its Core which we
> following as a standard and I don't see any single reason not to do so.

You have your points right, but you should realize that Debian GNU / , 
is glibc based. This means that your Base System without the kernel should 
come from GNU sources. Having that said, you should invest some efforts to 
port glibc to the Solaris (or OpenSolaris, Nevada, whatever[1]) kernel (to 
support all these fancy features mentioned above), as this has been done for 
glibc and the FreeBSD kernel by Bruno Haible.

On the other hand if you go for Solaris [1] own kernel and libc and porting 
Free Software on the top of that, your Nexenta OS is as much GNU as say MS 
Windows or Mac OS X since such (non-core or non-base) applications could be 
ported and compiled on them too, but these OS'es does not have GNU in their 
names (yet ;). Thus in this case Nexenta or GNUSolaris should be named like 
Nexenta Sun / OpenSolaris ( as in Distributor Base / Kernel ;-)

P.S. no offence implied, just sharing some thoughts ;-)

[1] http://opensolaris.org/os/community/onnv/
Note that Opensolaris / Nevada are not GCC ready yet, Sun Studio 10 is the 
preferred compiler

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Bug#368287: ITP: numl -- library for manipulating UML 2.0 models.

[Victor Seva]

Package: wnpp
Severity: wishlist
Owner: Victor Seva <[EMAIL PROTECTED]>


* Package name: libnuml-cil
  Version : 2.0
  Upstream Author : Rodolfo Campero <[EMAIL PROTECTED]>
* URL : http://numl.sourceforge.net
* License : LGPL
  Programming Lang: C#
  Description : library for manipulating UML 2.0 models.

nUML is a set of libraries for manipulating UML 2.0 models, for .NET, Mono,
and DotGNU. It provides serialization to and from XMI 2.1, manipulation of MOF 
models,
and a collections library for internal use.

These libraries were part of ExpertCoder, a toolkit that supports the
creation of code generators based on expert systems. 
http://expertcoder.sourceforge.net/


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-amd64-k8
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)


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

Bug#368291: ITP: libnuml-cil -- library for manipulating UML 2.0 models.

[Victor Seva]

Package: wnpp
Severity: wishlist
Owner: Victor Seva <[EMAIL PROTECTED]>


* Package name: libnuml-cil
  Version : 2.0.0
  Upstream Author : Rodolfo Campero <[EMAIL PROTECTED]>
* URL : http://numl.sourceforge.net
* License : LGPL
  Programming Lang: C#
  Description : library for manipulating UML 2.0 models.

nUML is a set of libraries for manipulating UML 2.0 models, for .NET, Mono,
and DotGNU. It provides serialization to and from XMI 2.1, manipulation of MOF 
models,
and a collections library for internal use.

These libraries were part of ExpertCoder, a toolkit that supports the
creation of code generators based on expert systems. 
http://expertcoder.sourceforge.net/

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-amd64-k8
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)


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

Bug#368292: ITP: libnuml-cil -- library for manipulating UML 2.0 models.

[Victor Seva]

Package: wnpp
Severity: wishlist
Owner: Victor Seva <[EMAIL PROTECTED]>


* Package name: libnuml-cil
  Version : 2.0
  Upstream Author : Rodolfo Campero <[EMAIL PROTECTED]>
* URL : http://numl.sourceforge.net
* License : LGPL
  Programming Lang: C#
  Description : library for manipulating UML 2.0 models.

nUML is a set of libraries for manipulating UML 2.0 models, for .NET, Mono,
and DotGNU. It provides serialization to and from XMI 2.1, manipulation of MOF 
models,
and a collections library for internal use.

These libraries were part of ExpertCoder, a toolkit that supports the
creation of code generators based on expert systems. 
http://expertcoder.sourceforge.net/


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-amd64-k8
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)


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

Re: RFC: Better portability for package maintainers

[Tollef Fog Heen]

Erast Benson wrote:

On Sat, 2006-05-20 at 12:32 -0500, Michael Banck wrote:

We had a pure NetBSD port before, but so far no non-glibc port got added
to the archive officially (but that doesn't mean it would get rejected
if it was of release quality).  


IMHO a glibc-based OpenSolaris would certainly be the better and more
interesting option (but might take some effort initially).


Do you really believe so? Do you understand that such a "hybrid" will
not run any existing Solaris apps like you will not be able to run
simple thinks like Macromedia flush player, JRE, JDK, Oracle, SAP, etc
etc... Do you still wanna do that?



Then provide the Solaris libc and other support libraries somewhere 
proprietary applications can use them, while building your system around 
glibc.  This would also solve the problem of shipping binaries linked 
with a non-GPL-compatible glibc together with said libc, which as it 
currently stands is a violation of the GPL (AIUI, anyway).


- tfheen


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

drupal orphaned?

[Erik Steffl]

  is drupal debian package effectively  orphaned? It is already two 
major upgrades (more than a year) behind upstream (and upstream 
recommends to upgrade from one version to next so the upgrades to 
current might get complicated).


  there are bugs asking for new version (one about a year old for 
previous version, one I filed few weeks ago for the just released 4.7), 
so far the only response from maintainer is that he has no time.


http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307821

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365709

  is it time for /opt/drupal-4.7.0?

erik


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

Re: Packages violating policy 8.2

[Martijn van Oosterhout]

On 5/21/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

For multiarch this will be an inconvenience though as people might
want to install both 32bit and 64bit of a -dev package. For such small
scripts spliting them into extra packages seems wrong but then you
have to use alternatives or similar to avoid conflicts.


Hmm, if a program to be compiled requires libfoo and libbar, and the
user  has installed libfoo32-dev and libbar64-dev, where is the error
going to be picked up? Are the -dev package actually architecture
sensetive?

I'd suggest pkgconfig could be used to fix this, except that the
--libs produces too much rubbish to be truly useful (see Bug#340904).
But if it worked correctly, you could add a --arch flags there to
ensure you get the right version.
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

Bug#368309: ITP: pcf2bdf -- convert X11 font from PCF to BDF format

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard <[EMAIL PROTECTED]>

* Package name: pcf2bdf
  Version : 1.04
  Upstream Author : TAGA Nayuta <[EMAIL PROTECTED]>
* URL : http://www.tsg.ne.jp/GANA/S/pcf2bdf/
* License : BSD
  Programming Lang: C++
  Description : convert X11 font from PCF to BDF format

 Pcf2bdf is a font de-compiler.  It converts an X11 font from Portable
 Compiled Format (PCF) to Bitmap Distribution Format (BDF).
 .
 FONTBOUNDINGBOX in a BDF file is not used by bdftopcf, so pcf2bdf
 generates irresponsible values.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (100, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-powerpc
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8)


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

#252593: roxen2: Won't purge

[Turbo Fredriksson]

I've had some time left and I thought I'd spend that to fix some
bugs...

What should I do with this bug? Roxen2 is only available in 'oldstable'
(woody)... But how do I direct an upload there? Or should I put it into
sarge, so that it can be removed THERE instead?


The same question goes for '#250544: roxen: upgrade breaks package'.
-- 
Albanian supercomputer arrangements NORAD 747 pits nuclear PLO Soviet
$400 million in gold bullion SEAL Team 6 Peking critical kibo DES
[See http://www.aclu.org/echelonwatch/index.html for more about this]
[Or http://www.europarl.eu.int/tempcom/echelon/pdf/rapport_echelon_en.pdf]
If neither of these works, try http://www.aclu.org and search for echelon.


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

Changing the default syslogd (again...)

[Nathanael Nerode]

OK, I brought this up a while back.  (For some reason I can't seem to find the
beginning of the topic, but see 
http://lists.debian.org/debian-devel/2006/01/msg00238.html )
I got a few comments in favor.

Someone asked what syslog other distros are using.  RedHat is still using 
sysklogd.
However, they are discussing switching to syslog-ng for Fedora Core 6
(http://fedoraproject.org/wiki/FC6Future).  SuSE is using syslog-ng.  Mandriva 
is
still using sysklogd.  I haven't found out about anyone else.

Every admin I know switches to something else.  :-(

Issues:
(1) Quality.
sysklogd has 105 open bugs: 3 important (1 with patch), 43 normal (11 with 
patches),
11 minor (4 with patches), and 19 wishlist (some of which are really quite 
important,
such as 44523)

The source code is a hairy mess, in my opinion, and I can see why these bugs 
aren't
being fixed.  It's been prone to repeated RC bugs, IMO due to the hairiness of 
the
codebase.  (I would also really not like to try a licensing audit of this 
package.)

Contrast:
syslog-ng: 26 open bugs, 3 important, 9 normal, 2 minor (1 with patch).
metalog: 15 open bugs, 1 RC (patched), 2 normal, 1 minor
inetutils-syslogd: 3 open bugs (2 normal, 1 wishlist).
socklog-run: 1 open bug, wishlist

(2) Upstream status.
There hasn't been a new upstream for sysklogd since 2001.
All of the others are active upstream.

(3) Features.
Essentially all of the others are considered more featureful.

(4) Size.
Installed sizes:

sysklogd: 204
depends on klogd: 132
total 336

inetutils-syslogd: 104
depends on lsb-base ('required'): 24
depends on zlib1g ('required'): 164
depends on netbase ('important'): 188
(depends on some Essential: yes packages as well)

syslog-ng: 492
depends on util-linux ('required'): 992
depends on lsb-base ('required'): 24
(depends on some Essential: yes packages as well)

metalog: 132
depends on libpcre3: 380
total: 512

socklog-run: 148
depends on socklog: 244 
depends on runit: 488
depends on ipsvd: 384
depends on libmatrixssl1.7: 100
total: 1364

Conclusion
--
We should change the default syslogd.

Size may be an issue.  However, except for socklog-run, the alternate syslog 
packages
depend almost entirely on packages which will probably already be installed.

If we want the default syslogd to be small, and assume that netbase will be 
installed,
we should default to inetutils-syslogd.

If we aren't so worried about size, we should go with syslog-ng or metalog.  
Probably
syslog-ng just for the familiarity of SuSE users.

The installer can use whatever seems most appropriate (does it even log?): but 
based on size, I strongly suspect inetutils-syslogd will be the winner, even 
over 
sysklogd.  I expect that most of what it needs from netbase will turn out to 
already be available in the installer.

Given the state of sysklogd, I hope that it can be removed entirely from a 
future
release of Debian.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Theocracy, fascism, or absolute monarchy -- I don't care which it is, I don't 
like it.


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

Re: RFC: Better portability for package maintainers

[Erast Benson]

On Sat, 2006-05-20 at 23:05 -0700, Matt Taggart wrote:
> Erast Benson writes...
> 
> > Once you accompany OpenSolaris kernel with GLIBC, you will kill this
> > capability, you will not be able to run anything other than OSS compiled
> > for your particular distro. That was my point. And isn't LSB is what
> > GNU/Linux moving towards to? In OpenSolaris we have its Core which we
> > following as a standard and I don't see any single reason not to do so.
> 
> How is this being implemented? I know Solaris did it by running an
> entire copy of Red Hat in a virtual machine, which isn't really supporting
> the LSB ABIs IMO. If you're actually supporting the LSB ABIs in the system
> root that would be cool (but the easiest way of doing it would be using
> glibc).

Not in the global, in the Branded Zone. It is possible to run GNU/Linux
binaries unmodified. Stuff like Skype does not yet exist on OpenSolaris,
so we run it over BrandZ with very small overhead.

In global zone, Nexenta provides SYSV init LSB scripts to make original
Debian daemon scripts to run seamlessly as a legacy services of SMF. We
are using SMF (Service Management Facility)[1] to manage daemons.

> This stuff could be really interesting to work on, get Sun to make the
> license GPL compatible and you'll see people in Debian interested in
> working on it.

It might be possible that OpenSolaris will be dual-licensed in the near
future. Jonathan Schwartz (Sun's CEO) actually were thinking about it at
his blog[2].

[1] http://www.opensolaris.org/os/community/smf
[2] http://blogs.sun.com/roller/page/jonathan?entry=hp_and_sun_partnering_around

-- 
Erast


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

Re: RFC: Better portability for package maintainers

[Erast Benson]

On Sun, 2006-05-21 at 10:44 +0200, Tollef Fog Heen wrote:
> Erast Benson wrote:
> > On Sat, 2006-05-20 at 12:32 -0500, Michael Banck wrote:
> >> We had a pure NetBSD port before, but so far no non-glibc port got added
> >> to the archive officially (but that doesn't mean it would get rejected
> >> if it was of release quality).  
> >>
> >> IMHO a glibc-based OpenSolaris would certainly be the better and more
> >> interesting option (but might take some effort initially).
> > 
> > Do you really believe so? Do you understand that such a "hybrid" will
> > not run any existing Solaris apps like you will not be able to run
> > simple thinks like Macromedia flush player, JRE, JDK, Oracle, SAP, etc
> > etc... Do you still wanna do that?
> 
> 
> Then provide the Solaris libc and other support libraries somewhere 
> proprietary applications can use them, while building your system around 
> glibc.

It is not easy possible to achieve. I'd say it would be impossible to
make it clean. The better way which we could follow in the future is to
port missing GLIBC functionality to SUN C library.

-- 
Erast


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

Re: RFC: Better portability for package maintainers

[Erast Benson]

On Sun, 2006-05-21 at 09:49 +0300, George Danchev wrote:
> On Sunday 21 May 2006 05:35, Erast Benson wrote:
> > On Sat, 2006-05-20 at 21:11 +0200, Steinar H. Gunderson wrote:
> > > On Sat, May 20, 2006 at 11:51:09AM -0700, Erast Benson wrote:
> > > > Do you really believe so? Do you understand that such a "hybrid" will
> > > > not run any existing Solaris apps like you will not be able to run
> > > > simple thinks like Macromedia flush player, JRE, JDK, Oracle, SAP, etc
> > > > etc... Do you still wanna do that?
> > >
> > > Erm.
> > >
> > > If Oracle and SAP are on your list of “simple things”, what then are
> > > large complex things for you?
> >
> > But I hope you still got me right. For me, all these "things" are
> > existing applications which must run. The world is not 100% open sourced
> > yet and we are in it, we are part of it, therefore my ideal OS need to
> > be capable to run existing freeware and closed binaries as is without
> > re-compilation. I want to run VMware, Oracle, Skype, SAP, Macromedia
> > flush, etc, etc, etc. I want my Nexenta to run DTrace, BrandZ
> > virtualization, ZFS, Zones without major re-design, etc, etc, etc...
> >
> > Once you accompany OpenSolaris kernel with GLIBC, you will kill this
> > capability, you will not be able to run anything other than OSS compiled
> > for your particular distro. That was my point. And isn't LSB is what
> > GNU/Linux moving towards to? In OpenSolaris we have its Core which we
> > following as a standard and I don't see any single reason not to do so.
> 
> You have your points right, but you should realize that Debian GNU / 
> , 
> is glibc based. This means that your Base System without the kernel should 
> come from GNU sources. Having that said, you should invest some efforts to 
> port glibc to the Solaris (or OpenSolaris, Nevada, whatever[1]) kernel (to 
> support all these fancy features mentioned above), as this has been done for 
> glibc and the FreeBSD kernel by Bruno Haible.

I'm personally will not do that. As I said earlier, I did it a year ago,
I even managed to run statically linked binaries on GLIBC + OpenSolaris
kernel. Than I realized that the resulted Operating Environment will not
be compatible with *anything* existing... how much it will be better
than GNU/Linux or GNU/OpenSolaris or SUN/OpenSolaris? I realized that
porting effort might be greatly minimized by utilizing different
approaches:

1) provide 100% Debian environment, so native Debian scripts will run as
is;
2) extend SUN C library with missing GLIBC functionality;
3) use of side libraries like libiconv, gettext, libintl;
4) use of transitional packages.

As the result, we are fast approaching to the point when all existing
Debian APT repo will be fully ported to Nexenta. We have 7000+ packages
at the moment and will probably have 1+ by the end of next month.

> On the other hand if you go for Solaris [1] own kernel and libc and porting 
> Free Software on the top of that, your Nexenta OS is as much GNU as say MS 
> Windows or Mac OS X since such (non-core or non-base) applications could be 
> ported and compiled on them too, but these OS'es does not have GNU in their 
> names (yet ;). Thus in this case Nexenta or GNUSolaris should be named like 
> Nexenta Sun / OpenSolaris ( as in Distributor Base / Kernel ;-)
> 
> P.S. no offence implied, just sharing some thoughts ;-)
> 
> [1] http://opensolaris.org/os/community/onnv/
> Note that Opensolaris / Nevada are not GCC ready yet, Sun Studio 10 is the 
> preferred compiler
> 
> -- 
> pub 4096R/0E4BD0AB 2003-03-18 
> fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 
> 
> 
-- 
Erast


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

Re: RFC: Better portability for package maintainers

[Tollef Fog Heen]

Erast Benson wrote:

On Sun, 2006-05-21 at 10:44 +0200, Tollef Fog Heen wrote:


Then provide the Solaris libc and other support libraries somewhere 
proprietary applications can use them, while building your system around 
glibc.


It is not easy possible to achieve. I'd say it would be impossible to
make it clean. The better way which we could follow in the future is to
port missing GLIBC functionality to SUN C library.


Uh, why would that be hard?  Solaris and Linux binaries doesn't hardcode 
the same elf interpreter, so you'd just put the solaris ld.so in 
/usr/lib (where it's hardcoded that it should go) and make sure its 
default rpath includes something like /usr/lib/sparc-sunos-sun (or what 
the architecture's triplet is).  You'd obviously want to ship the 
Solaris libc and any other needed libs there.


- tfheen


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

Re: Sun Java available from non-free

[Francesco Poli]

On Sat, 20 May 2006 16:18:44 -0500 Anthony Towns wrote:

[...]
> Anyway, the background is that James Troup, Jeroen van Wolffelaar and
> myself examined the license before accepting it into non-free (which
> is three times the usual examination,

It may be three times the usual examination, but when the license is not
*clearly* suitable for the archive under consideration (non-free, in
this case), the general recommendation is to check with debian-legal,
AFAICT.
Do you three think that the DLJ is trivially suitable for the non-free
archive?
I don't.

> and was done given the inability
> to examine the license in public),

Why weren't you able to examine the license in public?
The license was going to be made public shortly after (and with a
trumpeting announce that Debian had accepted it for the non-free
archive!)...

> and both James and Jeroen had
> extensive contact with Sun to ensure that the tricky clauses were
> actually okay.

Unfortunately that didn't mean the tricky clauses were fixed or made
harmless in any (legally binding) way.
I can believe that many fine people within Sun Microsystems are willing
to cooperate with Debian in a friendly fashion; but, without legally
binding statements from Sun legal department, how can we trust Sun to
never change mind and become aggressive (even despite the desires of the
above-mentioned fine people)?

> 
> There are three factors that are particularly relevant: the first is
> Sun's intentions and ability and interest to work with us as a proxy
> for the broader free software community -- this is an important issue
> because it ensures that we can resolve any problems with the license,

That is really good, but... why haven't you resolved the problems with
the license *before* uploading the packages to the archive?
It seems it would have been straightforward and easy to accomplish, at
least from what you say; yet it wasn't done... 

> and reduces the concern that Sun will try to screw us over, as it
> would become a PR problem rather than just a quiet argument on the
> lists;

I don't buy the PR argument.
Unfortunately many many people out there are not very interested in
dissecting licenses and in telling "real" and "fake" free software
apart. Even less in examining potential issues with non-free packages.

I don't know how much Sun decision-makers are worried that a move
against Debian could be bad PR...

> the second is that both the legal principle of estoppel and the
> general common sense principle of not going back on your word if you
> want people to work with you prevents Sun from realistically saying
> "the FAQ is completely wrong and should be ignored";

Both the FAQ itself and the DLJ state that the FAQ is not legally
binding.
The precise terms are to be found in the license: as long as the license
is unchanged or unamended (with legally binding additions), the issues
should not be considered solved...

> and the third
> aspect, which is probably most important, is that should any of these
> problems actually happen, we can fairly simply just drop Sun Java from
> non-free if we can't come to a better conclusion.

As has already been pointed out: what if Sun Java manages to enter a
future stable (or oldstable) release?
How quickly can Debian "effectively" drop a package from there?

> 
> That's not to say the license issues aren't problems, they are, and I
> hope debian-legal will be able to work with Sun both on helping them
> improve their non-free license, and in the future, helping them work
> through their concerns in applying a free license to Java. Obviously
> the Sun and Java guys have different priorities to -legal, but that
> doesn't mean it's not worth working together to solve what problems
> can be.

Exactly. Working together is what has not been done yet. At least, not
enough on the legal/license side.

> 
> In particular, saying "sure, you spent all that time writing a FAQ,
> but we're going to pretend you didn't" isn't a good way to start a
> productive relationship

They really should spend time in writing a more carefully worded
license, rather than drafting non-legally-binding explanations that seem
to be inconsistent with the actual terms and conditions.

[...]
> Unfortunately the possibility of Sun Java being relicensed suitably
> for non-free wasn't mentioned to us in enough time to build up a
> relationship with -legal folks that wouldn't primarily involve telling
> the Sun guys how this wasn't going to work. Fortunately James and
> Jeroen have been able to build a reasonably effective relationship
> with the Sun folks involved in the time provided; hopefully now that
> it's public, -legal in general will have the time and opportunity to
> do likewise, in a more thorough and transparent way.

It would be bad PR if Debian will have to remove Sun Java from the
archive, shortly after public announcements that it accepted it in.
I think that more time was needed to review possible issues, before
deciding that Debian could go on an

Re: Sun Java available from non-free

[Steinar H. Gunderson]

On Sun, May 21, 2006 at 01:38:57PM +0200, Francesco Poli wrote:
> As has already been pointed out: what if Sun Java manages to enter a
> future stable (or oldstable) release?
> How quickly can Debian "effectively" drop a package from there?

Is this really a problem? After all, nothing in main can depend on anything
in non-free, so all such a removal would do, would be that part of non-free
becomes uninstallable without installing external software (say, the JRE
using java-package). (I don't know the internals of dak, but still.)

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Bug#368334: ITP: libexpertcoder-cil -- ExpertCoder is a toolkit that supports the creation of code generators based on expert systems.

[Victor Seva]

Package: wnpp
Severity: wishlist
Owner: Victor Seva <[EMAIL PROTECTED]>


* Package name: libexpertcoder-cil
  Version : 0.2
  Upstream Author : Rodolfo Campero <[EMAIL PROTECTED]>
* URL : http://expertcoder.sourceforge.net/
* License : GPL
  Programming Lang: C#
  Description : ExpertCoder is a toolkit that supports the creation of code 
generators based on expert systems.

ExpertCoder is a toolkit for the .NET platform that supports the creation of
code generators based on expert systems. It's not a generator of code
generators, but rather a set of libraries useful to write generators.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-amd64-k8
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)


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

Re: Packages violating policy 8.2

[Goswin von Brederlow]

"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:

> On 5/21/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>> For multiarch this will be an inconvenience though as people might
>> want to install both 32bit and 64bit of a -dev package. For such small
>> scripts spliting them into extra packages seems wrong but then you
>> have to use alternatives or similar to avoid conflicts.
>
> Hmm, if a program to be compiled requires libfoo and libbar, and the
> user  has installed libfoo32-dev and libbar64-dev, where is the error

Under multiarch packages are not renamed. There is libfoo-dev i386 and
libfoo-dev amd64. Hopefully they are coinstallable. For core libraries
like libc6, zlib, ... this will be pretty much a requirement.

> going to be picked up? Are the -dev package actually architecture
> sensetive?

Every -dev package contains the libfoobar.so -> libfoobar.so.X.Y.Z
link. Under multiarch they would be in the architecture specific
library directory and thereby not architecture independent. So -dev
can not be architecture all.

Further, so that one can install both the 32bit and 64bit -dev package
it has to set "Multi-Arch: yes", which automaticaly means any depends
on it has to match the ABI. If installation of both packages is not
possible then the Multi-Arch tag has to be omited, which also causes
the ABI to be matched.

A libblub-dev with "Depends: libfoo-dev, libbar-dev" then
automatically pulls in the same ABI for those 2 packages as it has
itself ensuring that they fit. Same would go for Build-Depends (pull
in the systems native architecture).

> I'd suggest pkgconfig could be used to fix this, except that the
> --libs produces too much rubbish to be truly useful (see Bug#340904).
> But if it worked correctly, you could add a --arch flags there to
> ensure you get the right version.

pkgconfig currently has no multiarch support. The *.pc files are
architecture dependent and will have to be moved into multiarch
directories. But then how will pkgconfig know which one to use? It
might have to use and merge all of them creating even more rubbish.

This is one of the unsolved problems.

> -- 
> Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

MfG
Goswin


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

Re: RFC: Better portability for package maintainers

[Erast Benson]

On Sun, 2006-05-21 at 17:09 +0200, Tollef Fog Heen wrote:
> Erast Benson wrote:
> > On Sun, 2006-05-21 at 10:44 +0200, Tollef Fog Heen wrote:
> 
> >> Then provide the Solaris libc and other support libraries somewhere 
> >> proprietary applications can use them, while building your system around 
> >> glibc.
> > 
> > It is not easy possible to achieve. I'd say it would be impossible to
> > make it clean. The better way which we could follow in the future is to
> > port missing GLIBC functionality to SUN C library.
> 
> Uh, why would that be hard?  Solaris and Linux binaries doesn't hardcode 
> the same elf interpreter, so you'd just put the solaris ld.so in 
> /usr/lib (where it's hardcoded that it should go) and make sure its 
> default rpath includes something like /usr/lib/sparc-sunos-sun (or what 
> the architecture's triplet is).  You'd obviously want to ship the 
> Solaris libc and any other needed libs there.

I'm not saying it will be hard. All I'm saying is that it will be
impossible to make it clean.. Think about dual-architectures which are
common these days. You'll pretty much need to duplicate your mulitarch
libraries set by 2. Also, resulted OS will have 2 standard libraries
which is not sounds clean enough too, for instance you'll need to
provide 2 sets of localizations mechanisms one is sunc-way another is
glibc-way. Keep in mind that Networking stack is pretty much always
platform dependent, so it is not like you could provide OpenSolaris
libraries as an add-ons. They needs to be present and needs to be
compiled against sunc. Talking about compilations and naming conflicts,
they are going to be all over and you will be forced to resolve it one
way or another. And who knows what else?

-- 
Erast


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

Re: [draft] Re: Sun Java available from non-free

[Michael Meskes]

On Fri, May 19, 2006 at 10:59:33PM +0200, Jeroen van Wolffelaar wrote:
> > > (f) you agree to defend and indemnify Sun and its licensors from
> > > and against any damages, costs, liabilities, settlement amounts
> > > and/or expenses (including attorneys' fees) incurred in
> > > connection with any claim, lawsuit or action by any third party
> > > that arises or results from (i) the use or distribution of your
> > > Operating System, or any part thereof, in any manner, or (ii)
> > > your use or distribution of the Software in violation of the
> > > terms of this Agreement or applicable law.
> > 
> > I'm really not entirely sure what this clause is getting at, but it
> > seems that the intention is that Debian needs to indemnify Sun for any
> > litigation resulting by users of the package of Sun's JDK which Debian
> > has distributed, even if Sun is grossly negligent.[2]
> 
> I'm not an expert at all on indemnification, that's to the best of my
> knowledge quite US-centric. Pass on this one.

So I assume that one of the other two who had a look at it know more
about this and will share their insights later on. 

> ...
> Speaking realistically, such a move of Sun would be spectacularly bad PR
> for them esp. considering their statements about future Java licensing
> efforts they have committed to.

That's true. But why did they release this license and used no other
wording?

You essantially say, why worry about a license if it's bad PR too sue
the licensees. I doubt it really works that way. After all you could, at
some point somehow, get into a situation where Sun doesn't care about
the PR effect.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: RFC: Better portability for package maintainers

[Erast Benson]

On Sat, 2006-05-20 at 22:45 +0100, Roger Leigh wrote:
> Erast Benson <[EMAIL PROTECTED]> writes:
> 
> > On Sat, 2006-05-20 at 12:32 -0500, Michael Banck wrote:
> >> We had a pure NetBSD port before, but so far no non-glibc port got added
> >> to the archive officially (but that doesn't mean it would get rejected
> >> if it was of release quality).  
> >> 
> >> IMHO a glibc-based OpenSolaris would certainly be the better and more
> >> interesting option (but might take some effort initially).
> >
> > Do you really believe so? Do you understand that such a "hybrid" will
> > not run any existing Solaris apps like you will not be able to run
> > simple thinks like Macromedia flush player, JRE, JDK, Oracle, SAP, etc
> > etc... Do you still wanna do that?
> 
> Yes, IMO.
> 
> This binary compatibility with Solaris would have the same value as
> the iBCS2/Linux-ABI of yesteryear (that is, have very little value at
> all).  The only practical use is to run proprietary Solaris
> applications.  That's it.  Ten years ago, iBCS on GNU/Linux was a
> useful tool, but today proprietary software runs natively on Linux,
> but more importantly the proprietary software in common use ten years
> ago now has plenty of Free replacements.  As a result, iBCS is no
> longer in use; I'm not even sure if Linux-ABI has been maintained for
> the last four years.  It's dead.
> 
> I the same vein, I don't believe ABI compatibility with Solaris is
> particularly useful nowadays for a GNU/Solaris port.  Let's face it,
> the libc and system call interfaces are only a small part of the ABI
> of an application, and soname revs in all of the other libraries are
> going to make it deviate from Solaris if it becomes part of Debian
> proper.  That is, the libc ABI isn't the whole picture for anything
> but a trivial program.
> 
> Having GNU libc and ld.so /would/ be useful, certainly of much higher
> value than limited Solaris compatibility.  We would get the same
> linker (and extensions), plus the same libc (and extensions) as all
> our other ports.  Having a uniform toolchain across all the ports has
> a number of advantages.
> 
> GNU libc likely does not support Solaris-specific features.  This is
> not a reason to not use GNU libc however, but is a reason to add the
> missing features.  I understand that glibc was known to work on
> Solaris in the past, so it can surely be fixed up to work with some
> effort.  In the long term, having GNU libc on GNU/Solaris is very
> desirable, and I wouldn't call it GNU/Solaris myself until it uses GNU
> libc.

This is what I call utopia...

Existing API and ABI must be respected, especially when we are talking
about major existing Operating Environments such as Linux, Solaris,
FreeBSD and MacOSX.

If you'd like to produce new OS which is not compatible with anything
and not done clean, go ahead, I'm not going to participate.

Clean way would be to extend SUN C library with missing GLIBC
functionality. Btw, have you seen SUN C library code? Its done very
clean, very polished code base which runs at least on i386, amd64, sparc
and powerpc arches.

-- 
Erast


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

Re: RFC: Better portability for package maintainers

[George Danchev]

On Sunday 21 May 2006 17:34, Erast Benson wrote:
--cut--
> > > But I hope you still got me right. For me, all these "things" are
> > > existing applications which must run. The world is not 100% open
> > > sourced yet and we are in it, we are part of it, therefore my ideal OS
> > > need to be capable to run existing freeware and closed binaries as is
> > > without re-compilation. I want to run VMware, Oracle, Skype, SAP,
> > > Macromedia flush, etc, etc, etc. I want my Nexenta to run DTrace,
> > > BrandZ
> > > virtualization, ZFS, Zones without major re-design, etc, etc, etc...
> > >
> > > Once you accompany OpenSolaris kernel with GLIBC, you will kill this
> > > capability, you will not be able to run anything other than OSS
> > > compiled for your particular distro. That was my point. And isn't LSB
> > > is what GNU/Linux moving towards to? In OpenSolaris we have its Core
> > > which we following as a standard and I don't see any single reason not
> > > to do so.
> >
> > You have your points right, but you should realize that Debian GNU /
> > , is glibc based. This means that your Base System without the
> > kernel should come from GNU sources. Having that said, you should invest
> > some efforts to port glibc to the Solaris (or OpenSolaris, Nevada,
> > whatever[1]) kernel (to support all these fancy features mentioned
> > above), as this has been done for glibc and the FreeBSD kernel by Bruno
> > Haible.
>
> I'm personally will not do that. As I said earlier, I did it a year ago,
> I even managed to run statically linked binaries on GLIBC + OpenSolaris
> kernel. Than I realized that the resulted Operating Environment will not
> be compatible with *anything* existing... how much it will be better
> than GNU/Linux or GNU/OpenSolaris or SUN/OpenSolaris? I realized that

This is how (around glibc) the Debian's Linux and non-Linux ports are being 
constructed. And yes, they are innovative. Glibc is not tighten to any 
existing kernel or arch. I know that it all depends on what Base System you 
are targeting and want to be a part of. Seems you prefer being a distribution 
of OpenSolaris (kernel+libc) to allow existing Solaris proprietary binaries 
to run unmodified and use the packaging system tools from the Debian Project. 
Still I can not find anything innovatiove here, except that the broken 
Solaris pkg system is replaced by a more comprehensive and robust one. Being 
also a (not very impressed) Solaris (7/8/9) user this seems as an progress 
and I appreciate that, but it is not enough for users like me ;-)

> porting effort might be greatly minimized by utilizing different
> approaches:
>
> 1) provide 100% Debian environment, so native Debian scripts will run as
> is;
> 2) extend SUN C library with missing GLIBC functionality;
> 3) use of side libraries like libiconv, gettext, libintl;
> 4) use of transitional packages.

Good. You are working for extending OpenSolaris kernel+libc, but why do you 
believe it is technically possible and feasible to become an official Debian 
port with such a system ? Being an independent OpenSolaris distribution using 
packaging system from Debian should be enough for your effort I believe.

> As the result, we are fast approaching to the point when all existing
> Debian APT repo will be fully ported to Nexenta. We have 7000+ packages
> at the moment and will probably have 1+ by the end of next month.

I believe that in this case the Easiest is not the Right [tm] ;-)

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: Sun Java available from non-free

[Michael Meskes]

On Sat, May 20, 2006 at 04:18:44PM -0500, Anthony Towns wrote:
> Anyway, the background is that James Troup, Jeroen van Wolffelaar and
> myself examined the license before accepting it into non-free (which is
> three times the usual examination, and was done given the inability to
> examine the license in public), and both James and Jeroen had extensive
> contact with Sun to ensure that the tricky clauses were actually okay.

You won't expect Sun to say they are not, would you? :-)

> There are three factors that are particularly relevant: the first is
> Sun's intentions and ability and interest to work with us as a proxy
> for the broader free software community -- this is an important issue
> because it ensures that we can resolve any problems with the license,
> and reduces the concern that Sun will try to screw us over, as it would
> become a PR problem rather than just a quiet argument on the lists; the

This is true but you only need a license if anything goes wrong. So the
PR argument essantially is not a very good one.

> second is that both the legal principle of estoppel and the general common
> sense principle of not going back on your word if you want people to work
> with you prevents Sun from realistically saying "the FAQ is completely
> wrong and should be ignored"; and the third aspect, which is probably

I'm not sure. Would be interesting to hear a lawyer's meaning on this
topic.

> most important, is that should any of these problems actually happen,
> we can fairly simply just drop Sun Java from non-free if we can't come
> to a better conclusion.

Do you mean we can drop it if problems arise? Or do you mean we can drop
it if we cannot conlcude it's okay to distribute it?

I doubt you mean the first case, as it would be too late then. But if
you mean the second case, why just putting it in that quickly? Isn't it
the normal way to discuss things while the package is in NEW and not
after it made it into the archive?

> That's not to say the license issues aren't problems, they are, and I
> hope debian-legal will be able to work with Sun both on helping them
> improve their non-free license, and in the future, helping them work
> through their concerns in applying a free license to Java. Obviously the
> Sun and Java guys have different priorities to -legal, but that doesn't
> mean it's not worth working together to solve what problems can be.

Right, but again, why bringing the package with a bad license into the
archive first?

> Unfortunately the possibility of Sun Java being relicensed suitably for
> non-free wasn't mentioned to us in enough time to build up a relationship
> with -legal folks that wouldn't primarily involve telling the Sun guys
> how this wasn't going to work. Fortunately James and Jeroen have been
> able to build a reasonably effective relationship with the Sun folks
> involved in the time provided; hopefully now that it's public, -legal
> in general will have the time and opportunity to do likewise, in a more
> thorough and transparent way.

I wonder if we ever had another package or if anyone could imagine a
"normal" package being brought into non-free without discussions but
with a license that creates so many questions?

DPL, I wonder Why the Sun-Java package is not handled the same as any
other package. What makes it so special that it deserves special
treatment?

Isn't this a discrimination against all other packages? :-)

Again, to all the Sun folks reading this, this is not against your
efforts that I like a lot. But the same PR effect could have been
reached by announcing that Sun and Debian jointly work on a way to
distribute Java instead of pushing it into the archive.

Michael

-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: Sun Java available from non-free

[Michael Meskes]

On Sat, May 20, 2006 at 04:17:04AM -0700, David A. wrote:
> I've briefly folllowed this legal discussion and I understand there are
> details and stuff to sort out. Somehow I'm struck by the impression
> that there are forces that don't want Sun JVM even in non-free?

No, I don't think your impressions are right. People would love to have
Sun JVM in non-free or even better in main, but the current license does
not allow us to distribute Sun JVM. This game is being played by some
rules and those people just don't like the idea of breaking the rules
just to have Sun JVM. Well at least that's my impression.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: RFC: Better portability for package maintainers

[George Danchev]

On Sunday 21 May 2006 19:06, Erast Benson wrote:
-cut--
> Clean way would be to extend SUN C library with missing GLIBC
> functionality. Btw, have you seen SUN C library code? Its done very
> clean, very polished code base which runs at least on i386, amd64, sparc
> and powerpc arches.

Peace, but I do not share this opinion though ;-). I remember having troubles 
with _trivial_ things like:

printf("The Absolute Zero is: %5.5lf°[C] or 0°[K]!\n", ABSZ);

° is not accepted by solaris 9 libc printf function. I haven't bother to check 
that out on a recent OpenSolaris distribution though, since fortunately we 
have not been locked to any legacy proprietary binaries and the development 
machines have been easily debianized.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: RFC: Better portability for package maintainers

[Erast Benson]

On Sun, 2006-05-21 at 19:14 +0300, George Danchev wrote:
> On Sunday 21 May 2006 17:34, Erast Benson wrote:
> --cut--
> > > > But I hope you still got me right. For me, all these "things" are
> > > > existing applications which must run. The world is not 100% open
> > > > sourced yet and we are in it, we are part of it, therefore my ideal OS
> > > > need to be capable to run existing freeware and closed binaries as is
> > > > without re-compilation. I want to run VMware, Oracle, Skype, SAP,
> > > > Macromedia flush, etc, etc, etc. I want my Nexenta to run DTrace,
> > > > BrandZ
> > > > virtualization, ZFS, Zones without major re-design, etc, etc, etc...
> > > >
> > > > Once you accompany OpenSolaris kernel with GLIBC, you will kill this
> > > > capability, you will not be able to run anything other than OSS
> > > > compiled for your particular distro. That was my point. And isn't LSB
> > > > is what GNU/Linux moving towards to? In OpenSolaris we have its Core
> > > > which we following as a standard and I don't see any single reason not
> > > > to do so.
> > >
> > > You have your points right, but you should realize that Debian GNU /
> > > , is glibc based. This means that your Base System without the
> > > kernel should come from GNU sources. Having that said, you should invest
> > > some efforts to port glibc to the Solaris (or OpenSolaris, Nevada,
> > > whatever[1]) kernel (to support all these fancy features mentioned
> > > above), as this has been done for glibc and the FreeBSD kernel by Bruno
> > > Haible.
> >
> > I'm personally will not do that. As I said earlier, I did it a year ago,
> > I even managed to run statically linked binaries on GLIBC + OpenSolaris
> > kernel. Than I realized that the resulted Operating Environment will not
> > be compatible with *anything* existing... how much it will be better
> > than GNU/Linux or GNU/OpenSolaris or SUN/OpenSolaris? I realized that
> 
> This is how (around glibc) the Debian's Linux and non-Linux ports are being 
> constructed. And yes, they are innovative. Glibc is not tighten to any 
> existing kernel or arch. I know that it all depends on what Base System you 
> are targeting and want to be a part of. Seems you prefer being a distribution 
> of OpenSolaris (kernel+libc) to allow existing Solaris proprietary binaries 
> to run unmodified and use the packaging system tools from the Debian Project. 
> Still I can not find anything innovatiove here, except that the broken 
> Solaris pkg system is replaced by a more comprehensive and robust one. Being 
> also a (not very impressed) Solaris (7/8/9) user this seems as an progress 
> and I appreciate that, but it is not enough for users like me ;-)

So, why GLIBC is so important to you? What do you miss in SUN C library?
And why do you think technically impossible to extend SUN C library with
missing GLIBC functionality? I'm just trying to understand your point of
view..

> > porting effort might be greatly minimized by utilizing different
> > approaches:
> >
> > 1) provide 100% Debian environment, so native Debian scripts will run as
> > is;
> > 2) extend SUN C library with missing GLIBC functionality;
> > 3) use of side libraries like libiconv, gettext, libintl;
> > 4) use of transitional packages.
> 
> Good. You are working for extending OpenSolaris kernel+libc, but why do you 
> believe it is technically possible and feasible to become an official Debian 
> port with such a system ? Being an independent OpenSolaris distribution using 
> packaging system from Debian should be enough for your effort I believe.

because non-glibc Debian architectures does exists (i.e.
FreeBSD,Solaris,Darwin), and it is time to consider them and accept
their existence. Those core architectures are open sourced and their
communities will only grow over time. It is not like they will
disappear, that means Debian must adjust to the new fact of life: "we
have more than one major OS totally open-sourced at its core".

-- 
Erast


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

Re: RFC: Better portability for package maintainers

[Steinar H. Gunderson]

On Sun, May 21, 2006 at 09:44:50AM -0700, Erast Benson wrote:
> So, why GLIBC is so important to you? What do you miss in SUN C library?
> And why do you think technically impossible to extend SUN C library with
> missing GLIBC functionality? I'm just trying to understand your point of
> view..

There's a distinction between “missing in the Sun C library” and “technically
impossible to create in the Sun C library” -- especially given that there's
limited manpower in the world, and that there might always be an element of
time involved. You seem to insist that since the Sun C library is possible to
extend, glibc can't possibly be advantageous in any way, and this position is
a bit confusing.

> because non-glibc Debian architectures does exists (i.e.
> FreeBSD,Solaris,Darwin), and it is time to consider them and accept
> their existence. Those core architectures are open sourced and their
> communities will only grow over time. It is not like they will
> disappear, that means Debian must adjust to the new fact of life: "we
> have more than one major OS totally open-sourced at its core".

Again, there's a certain difference between “there exist more than one free
kernel and libc” (ignoring the problems the current Sun license might have
with the DFSG) and “Debian must do whatever Nexenta wishes”. This isn't a new
situation -- the BSDs have been around forever. I think you'd meet a lot more
acceptance and friendliness if you stopped insisting that Debian unilaterally
adopted your conclusions and world view.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: Bug#368309: ITP: pcf2bdf -- convert X11 font from PCF to BDF format

[Ben Pfaff]

Jonas Smedegaard <[EMAIL PROTECTED]> writes:

>  Pcf2bdf is a font de-compiler.  It converts an X11 font from Portable
>  Compiled Format (PCF) to Bitmap Distribution Format (BDF).
>  .
>  FONTBOUNDINGBOX in a BDF file is not used by bdftopcf, so pcf2bdf
>  generates irresponsible values.

I don't think that "irresponsible" is the word you are looking for.
-- 
Ben Pfaff 
email: [EMAIL PROTECTED]
web: http://benpfaff.org


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

Re: RFC: Better portability for package maintainers

[George Danchev]

On Sunday 21 May 2006 19:44, Erast Benson wrote:
--cut--
> So, why GLIBC is so important to you? What do you miss in SUN C library?
> And why do you think technically impossible to extend SUN C library with
> missing GLIBC functionality? I'm just trying to understand your point of
> view..

Glibc is so important to me because its license is proven being free and it 
gets much more support/development/and user base than any libc in existance. 
In addition I have some technical issues with sun's libc I'm not prepared to 
discuss right now, and more importantly I'm not inclined to spent any time on 
sources I personally believe are non-free software (I have legal issues with 
the current CDDL 1.0, which have being discussed to death in the past and 
which could be improved in the future ;-)

> > > porting effort might be greatly minimized by utilizing different
> > > approaches:
> > >
> > > 1) provide 100% Debian environment, so native Debian scripts will run
> > > as is;
> > > 2) extend SUN C library with missing GLIBC functionality;
> > > 3) use of side libraries like libiconv, gettext, libintl;
> > > 4) use of transitional packages.
> >
> > Good. You are working for extending OpenSolaris kernel+libc, but why do
> > you believe it is technically possible and feasible to become an official
> > Debian port with such a system ? Being an independent OpenSolaris
> > distribution using packaging system from Debian should be enough for your
> > effort I believe.
>
> because non-glibc Debian architectures does exists (i.e.
> FreeBSD,Solaris,Darwin), 

Hm, I'm only aware of glibc-based Debian ports, like: 
http://www.debian.org/ports/kfreebsd-gnu/
and they are not utopia ;-)

Could you point me to non-glibc Debian port please ? Note, that I'm not 
against Debian non-glibc ports.

> and it is time to consider them and accept 
> their existence. Those core architectures are open sourced and their
> communities will only grow over time. It is not like they will
> disappear, that means Debian must adjust to the new fact of life: "we
> have more than one major OS totally open-sourced at its core".

That is true, there are many open-sourced OS'es, or at least they claim to be 
such, but this does not mean that it is technically and legaly possible and 
feasible to make all of them official Debian ports.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: RFC: Better portability for package maintainers

[Erast Benson]

On Sun, 2006-05-21 at 19:40 +0300, George Danchev wrote:
> On Sunday 21 May 2006 19:06, Erast Benson wrote:
> -cut--
> > Clean way would be to extend SUN C library with missing GLIBC
> > functionality. Btw, have you seen SUN C library code? Its done very
> > clean, very polished code base which runs at least on i386, amd64, sparc
> > and powerpc arches.
> 
> Peace, but I do not share this opinion though ;-). I remember having troubles 
> with _trivial_ things like:
> 
> printf("The Absolute Zero is: %5.5lf°[C] or 0°[K]!\n", ABSZ);

this problem been fixed a long time ago... any software has bugs, so
lets do not accept this as a arguments. GLIBC had/has plenty of bugs all
over too, especially when you start talking about non-Linux ports where
it is not yet polished.

> ° is not accepted by solaris 9 libc printf function. I haven't bother to 
> check 
> that out on a recent OpenSolaris distribution though, since fortunately we 
> have not been locked to any legacy proprietary binaries and the development 
> machines have been easily debianized.

OpenSolaris is aimed to be 100% open sourced... what are you talking
about? I can not accept this as an argument too. Peace? :-)

-- 
Erast


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

Re: Changing the default syslogd (again...)

[Thiemo Seufer]

Nathanael Nerode wrote:
[snip]
> The installer can use whatever seems most appropriate (does it even log?):

The installer does log and puts the logs at /var/log/debian-installer/ on
the successfully installed system. If the installation fails, the logs (in
the installer ramdisk) are a valuable source of information.


Thiemo


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

Bug#368371: ITP: gp2c -- PARI/GP GP to C compiler

[Bill Allombert]

Package: wnpp
Severity: wishlist
Owner: Bill Allombert <[EMAIL PROTECTED]>

* Package name: gp2c
  Version : 0.0.4pl5
  Upstream Author : Your truly <[EMAIL PROTECTED]>
* URL : http://pari.math.u-bordeaux.fr/
* License : GPL
  Programming Lang: C
  Description : PARI/GP GP to C compiler
  PARI/GP is a widely used computer algebra system designed for fast
  computations in number theory (factorizations, algebraic number theory,
  elliptic curves...), but also contains a large number of other useful
  functions to compute with mathematical entities such as matrices,
  polynomials, power series, algebraic numbers, etc., and a lot of
  transcendental functions. PARI is also available as a C library to allow
  for faster computations.
  .
  Originally developed by Henri Cohen and his co-workers (University Bordeaux I,
  France), PARI is now under the GPL and maintained by Karim Belabas
  (University Paris XI, France) with the help of many volunteer contributors.
  .
  This package contains the G2PC compiler that convert GP scripts to C
  libpari modules.

This package depends on PARI/GP 2.3 which should be released soon. 
I will upload gp2c once pari-gp 2.3 is in the archive.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Re: RFC: Better portability for package maintainers

[Erast Benson]

On Sun, 2006-05-21 at 18:54 +0200, Steinar H. Gunderson wrote:
> On Sun, May 21, 2006 at 09:44:50AM -0700, Erast Benson wrote:
> > So, why GLIBC is so important to you? What do you miss in SUN C library?
> > And why do you think technically impossible to extend SUN C library with
> > missing GLIBC functionality? I'm just trying to understand your point of
> > view..
> 
> There's a distinction between “missing in the Sun C library” and “technically
> impossible to create in the Sun C library” -- especially given that there's
> limited manpower in the world, and that there might always be an element of
> time involved. You seem to insist that since the Sun C library is possible to
> extend, glibc can't possibly be advantageous in any way, and this position is
> a bit confusing.

"..there's limited manpower in the world..." can not be an acceptable
argument for future development. First, we need to make sure that our
goals and ideas meats our idealistic view on how Debian should evolve.
Second we need to make a decision whether this or other way would be the
right one.

> > because non-glibc Debian architectures does exists (i.e.
> > FreeBSD,Solaris,Darwin), and it is time to consider them and accept
> > their existence. Those core architectures are open sourced and their
> > communities will only grow over time. It is not like they will
> > disappear, that means Debian must adjust to the new fact of life: "we
> > have more than one major OS totally open-sourced at its core".
> 
> Again, there's a certain difference between “there exist more than one free
> kernel and libc” (ignoring the problems the current Sun license might have
> with the DFSG) and “Debian must do whatever Nexenta wishes”. This isn't a new
> situation -- the BSDs have been around forever. I think you'd meet a lot more
> acceptance and friendliness if you stopped insisting that Debian unilaterally
> adopted your conclusions and world view.

I do not insist, instead I propose to consider. See the diff?

-- 
Erast


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

Re: Sun Java available from non-free

[Raphael Hertzog]

On Sun, 21 May 2006, Francesco Poli wrote:
> > Anyway, the background is that James Troup, Jeroen van Wolffelaar and
> > myself examined the license before accepting it into non-free (which
> > is three times the usual examination,
> 
> It may be three times the usual examination, but when the license is not
> *clearly* suitable for the archive under consideration (non-free, in
> this case), the general recommendation is to check with debian-legal,
> AFAICT.
> Do you three think that the DLJ is trivially suitable for the non-free
> archive?

There's something that you must keep in mind. Ftpmasters are responsible
to decide if the license is OK for us or not. debian-legal is nothing more
than an "advisory board" for them. They can examine a license and share
remarks to ftpmasters but they certainly can't decide if the ftpmasters
have to accept the package or not.

In that case, ftpmasters accepted it, end of discussion. You HAVE to
accept decisions of delegates within Debian, that's how we can effectively
work. 

If you really fear legal problems, then you should work with Sun to see if
you can reword the license so that it better matches the FAQ which gives us
currently all the warranties that we need. We can terminate the license as
soon as Sun starts bothering us with non-FAQ-conforming interpretations of
their license.

> Why weren't you able to examine the license in public?

Because the license change was not yet public and that we *cooperate* with
Sun (because we want them to free the product even more in the future).

Furthermore, doing a bit of Debian PR by having a timely announce of the
new java license, is good for us too.

> > extensive contact with Sun to ensure that the tricky clauses were
> > actually okay.
> 
> Unfortunately that didn't mean the tricky clauses were fixed or made
> harmless in any (legally binding) way.

You are not responsible to make that decision in Debian, ftpmasters are.
Criticizing ftpmasters won't help them changing their minds.

> As has already been pointed out: what if Sun Java manages to enter a
> future stable (or oldstable) release?
> How quickly can Debian "effectively" drop a package from there?

Just like usual.

> It would be bad PR if Debian will have to remove Sun Java from the
> archive, shortly after public announcements that it accepted it in.

No it wouldn't.

> I really hope we can solve the issues in a graceful manner.

You're not interested in that. "graceful manner" means you want ftpmasters
to agree with you. They won't. And I don't.

Thanks to everyone who worked (even privately) on this issue!

> Even better, I hope that Sun Java can become DFSG-free as quickly as
> possible,

You're not facilitating it. People who managed that java upload did
discuss with Sun and they probably know that this was the right first
step. You have no idea of the internal lobbying that may be going on and
you can't judge how to best achieve DFSG-freeness of java.

Cheers,

PS: Yeah I'm a bit pissed of that we only have people criticizing when we
do great things.
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: RFC: Better portability for package maintainers

[Steinar H. Gunderson]

On Sun, May 21, 2006 at 10:29:17AM -0700, Erast Benson wrote:
> "..there's limited manpower in the world..." can not be an acceptable
> argument for future development.

Why not? It's certainly better than “with an unspecified amount of work done
by an unspecified labor force, option A can be as good as option B, so we'll
choose that”. Heck, with an unspecified amount of work, glibc on OpenSolaris
can be compatible with all the Solaris applications you like... but nobody is
really going to do all that work. Likewise, I do not really think a horde of
developers are going to begin working on OpenSolaris' libc to make it closer
to glibc.

It boils down to what you see as most important -- you seem to put a lot of
weight into running major non-free applications on OpenSolaris, and I'm not
sure if the average DD is willing to accept that as a basic goal.

> I do not insist, instead I propose to consider. See the diff?

There might be an issue of communication here, but given that you claim that
“Debian must adjust to the new fact of life” (which at least I interpret as
“Debian must adjust its views to support a port to OpenSolaris kernel and
libc”), it sure looks like you're insisting -- it's all about words like
“must”. If you allow me to make a counter-claim using the same words, it
would probably be “Nexenta must adjust to the fact that Debian on OpenSolaris
is a relatively obscure port, which probably will not get all that much
influence in a short timeframe, and thus cannot expect package maintainers to
put in a considerable effort to adjust their packages”.

You might disagree with my goals as a package maintainer, but you should
realize that you'll either have to make porting very easy and accessible (and
using glibc makes this quite a lot easier), or do 95% of it yourself (and
hopefully submit patches upstream and to the BTS).

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: drupal orphaned?

[Christoph Berg]

Re: Erik Steffl 2006-05-21 <[EMAIL PROTECTED]>
>   is drupal debian package effectively  orphaned? It is already two 
> major upgrades (more than a year) behind upstream (and upstream 
> recommends to upgrade from one version to next so the upgrades to 
> current might get complicated).

No, please have a look at http://packages.qa.debian.org/d/drupal.html.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


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

Re: Sun Java available from non-free

[Alexander Wirt]

Raphael Hertzog schrieb am Sonntag, den 21. Mai 2006:

 
> PS: Yeah I'm a bit pissed of that we only have people criticizing when we
> do great things.
You can get applause if you do great things, not if you do harm to debian and
opensource. 
As I said, the license has to be changed. 
 
Alex


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

Re: Sun Java available from non-free

[Russ Allbery]

Francesco Poli <[EMAIL PROTECTED]> writes:
> On Sat, 20 May 2006 16:18:44 -0500 Anthony Towns wrote:
> [...]
>> Anyway, the background is that James Troup, Jeroen van Wolffelaar and
>> myself examined the license before accepting it into non-free (which
>> is three times the usual examination,

> It may be three times the usual examination, but when the license is not
> *clearly* suitable for the archive under consideration (non-free, in
> this case), the general recommendation is to check with debian-legal,
> AFAICT.

At least so far as I understand it, the ftp-masters (i.e., the people who
did this check) are the people responsible for verifying and checking
licenses in uploaded packages and debian-legal exists as an advisory body
for the ftp-masters and a place for Debian maintainers to ask for advice,
not the other way around.

Is that not correct?

> Why weren't you able to examine the license in public?

Maybe because Sun didn't want to do multiple public releases of the
license and look indecisive, and instead wanted the license to be vetted
in private first so that they could fix any issues that they considered
problems before the release?

I would have liked them to make more of it clearer, but I have no idea
what the original looked like.  It's possible it improved quite a bit in
that process, and it's not unusual for companies to want to not air their
laundry in public.  That's one of the big differences with free software,
and personally I prefer free software, but we *are* talking about a
license in non-free.  Some degree of standard corporate behavior is to be
expected.

> Both the FAQ itself and the DLJ state that the FAQ is not legally
> binding.

> The precise terms are to be found in the license: as long as the license
> is unchanged or unamended (with legally binding additions), the issues
> should not be considered solved...

No one has addressed my question about estoppel.  My guess is that Sun's
publicly stated interpretation of a clause of the license is more legally
binding than you think it is, but I'd love to see a legal opinion.

> It would be bad PR if Debian will have to remove Sun Java from the
> archive, shortly after public announcements that it accepted it in.

It would be bad PR for Sun.  I'm not sure that Debian should care.  We're
on the free software side, remember -- we *do* work through our problems
in public.  That includes changing our mind if need be.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Sun Java available from non-free

[Julien BLACHE]

Raphael Hertzog <[EMAIL PROTECTED]> wrote:

Hi Raphael,

> In that case, ftpmasters accepted it, end of discussion. You HAVE to
> accept decisions of delegates within Debian, that's how we can effectively
> work.

Nope, you don't have to accept decisions made by delegates. You have
the option to overrule the decision by a GR.

JB.

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


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

Re: Changing the default syslogd (again...)

[Florian Weimer]

* Nathanael Nerode:

> (2) Upstream status.
> There hasn't been a new upstream for sysklogd since 2001.
> All of the others are active upstream.

Have you checked if SuSE's syslog-ng is heavily patched?  If it's
mostly alright, it's probably a good indicator that syslog-ng is the
way to go (and I assume that it can log to files larger than 2GB
nowadays 8-).


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

Re: #252593: roxen2: Won't purge

[Florian Weimer]

* Turbo Fredriksson:

> I've had some time left and I thought I'd spend that to fix some
> bugs...
>
> What should I do with this bug? Roxen2 is only available in 'oldstable'
> (woody)... But how do I direct an upload there? Or should I put it into
> sarge, so that it can be removed THERE instead?

Hmm?  roxen2 isn't part of sarge or anything more recent, so there is
no bug left to fix, it seems.


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

Re: Sun Java available from non-free

[Josselin Mouette]

Le dimanche 21 mai 2006 à 13:38 +0200, Francesco Poli a écrit :
> It may be three times the usual examination, but when the license is not
> *clearly* suitable for the archive under consideration (non-free, in
> this case), the general recommendation is to check with debian-legal,
> AFAICT.

But this would have meant transparency and public discussion, respecting
the social contract, and so on. All these secondary issues AJ doesn't
want to deal with.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Sun Java available from non-free

[Josselin Mouette]

Le dimanche 21 mai 2006 à 12:34 -0500, Raphael Hertzog a écrit :
> You are not responsible to make that decision in Debian, ftpmasters are.
> Criticizing ftpmasters won't help them changing their minds.

If not, it has to help changing the ftpmasters.

> Thanks to everyone who worked (even privately) on this issue!

No thanks to everyone who worked (only privately) on this issue.

> PS: Yeah I'm a bit pissed of that we only have people criticizing when we
> do great things.

What great things? Taking irresponsible decisions that expose the whole
project to legal actions from Sun? I don't feel like thanking anyone for
that.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Sun Java available from non-free

[Thomas Weber]

I don't have a particular opinion for Java in Debian or not, but there
are some points you raise:

Am Sonntag, den 21.05.2006, 12:34 -0500 schrieb Raphael Hertzog:
> In that case, ftpmasters accepted it, end of discussion. 

Don't you think that the main problem here is that there *wasn't* any
discussion, at least for the vast majority of Debian developers and
users? And yes, as a Debian user I'm surprised that such decisions are
taken behind closed doors; this is not a security related issue and it
wouldn't have done any harm to Debian to discuss this in the open.

If that had delayed the inclusion, so be it; after several years without
Sun's Java in Debian, some more weeks wouldn't have hurt neither users
nor the project itself.



> Furthermore, doing a bit of Debian PR by having a timely announce of the
> new java license, is good for us too.

I agree with you that it was a good PR stunt. At the same time, it was
an internal communication disaster.

Oh, and the impression that pushing non-free packages in after several
hours has a high priority, while (license-wise) simple packages linger
for weeks in NEW was probably a bonus[1].



> > It would be bad PR if Debian will have to remove Sun Java from the
> > archive, shortly after public announcements that it accepted it in.
> 
> No it wouldn't.

Well, there I disagree with you: it would. At the very least, it would
give the impression that Debian can't decide what it wants.


[1] Yes, I know that this was due to the fact, that three ftp-admins
have examined the license probably far longer than the package was in
the NEW queue. Why do I know it? Because AJ did *communicate* it.

Regards
Thomas


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

Re: Making init scripts use dash

[Wouter Verhelst]

On Fri, May 19, 2006 at 04:49:49PM +0200, Olaf van der Spek wrote:
> On 5/19/06, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> >On Fri, May 19, 2006 at 05:45:46AM +0200, David Weinehall wrote:
> >> Well, most of those scripts can be fixed quite easily, some require
> >> a bit more work.  I hereby promise to help fixing them to the extent
> >> of my capability.
> >
> >Let's see. The nbd-client and nbd-server initscripts use bash arrays. Do
> >you have an alternative way to implement their current behaviour, so
> >that it would work with dash?
> 
> Don't those scripts use #!/bin/bash?

Of course.

> Why would they have to work with dash?

If the difference in speed is indeed that insane, that's nice.

I've received a bugreport with patch against the nbd packages now which
implement whatever it's doing now with eval rather than bash arrays. Now
I'm not sure whether this is actually going to be any faster (eval might
require more processing time than arrays?), but if it is, and I can find
a sane way to convert my config files from arrays to "regular"
variables, then I'll use that.

Or I might just not bother, and finish nbd 2.9, which has support for
config files in the C bits rather than the initscript. I'll see :)

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: alternatives and priorities

[Wouter Verhelst]

On Fri, May 19, 2006 at 09:51:58PM +0200, Petter Reinholdtsen wrote:
> [Gregor Herrmann]
> > If you look at by_vote [0] the situation is different:
> > http://popcon.debian.org/main/editors/by_vote
> >
> > [0] which seems more relevant to me:
> > # is the number of people who installed this package;
> > # is the number of people who use this package regularly;
> 
> Note, the popcon vote is not always accurate.  It only use files in
> some directories (like */bin/, but not */lib/*), so most library
> packages will never get a vote, and most user packages will get votes.

Which, I'm sure, is important for popcon maintainers; however, I don't
think it is very relevant in this discussion (unless you can point me
towards an editor that is implemented as a library ;-)

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Sun Java available from non-free

[Romain Beauxis]

Hi!

Le Dimanche 21 Mai 2006 19:34, Raphael Hertzog a écrit :
> PS: Yeah I'm a bit pissed of that we only have people criticizing when we
> do great things.

I know I shouldn't, but I was really upset by your answer.

I'm happy that people speak up and claim their fear with this licence, and no, 
I won't hide my personal reponsability behind the ftp masters' decision: my 
concern is not a fear for myself but a fear for the project.

To all the questions and fears raised consciously and with arguments, you 
answer them to shut up and respect the others decisions, that is not the way 
I would work in this project as for sure.

Romain
-- 
mama say
son, you've got to stay home today
there's a hole in the roof
you've got to make it waterproof

Re: alternatives and priorities

[Wouter Verhelst]

On Fri, May 19, 2006 at 03:23:09PM -0300, Maximiliano Curia wrote:
> On Friday 19 May 2006 10:25, Wouter Verhelst wrote:
> > So, instead of using static feature lists to define an application's
> > priority with which it would be configured in the alternatives system,
> > why not use popcon data to do that instead? Using popcon would ensure
> > that the applications which most people prefer would be the default;
> > this is a fair and objective criterion.
> 
> You would end up with nvi or nano as editors, since they are installed by 
> default. Probably more as viewer and so on. 

Which is bad why?

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Unidentified subject!

[3185570860]

Need 2 find some locals for sex only, monroe, La.

--

Mobile Email from a Cingular Wireless Customer http://www.cingular.com


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

Re: RFC: Better portability for package maintainers

[Ondrej Sury]

On Sun, 2006-05-21 at 18:54 +0200, Steinar H. Gunderson wrote:
> > because non-glibc Debian architectures does exists (i.e.
> > FreeBSD,Solaris,Darwin), and it is time to consider them and accept
> > their existence. Those core architectures are open sourced and their
> > communities will only grow over time. It is not like they will
> > disappear, that means Debian must adjust to the new fact of life: "we
> > have more than one major OS totally open-sourced at its core".
> 
> Again, there's a certain difference between “there exist more than one free
> kernel and libc” (ignoring the problems the current Sun license might have
> with the DFSG) and “Debian must do whatever Nexenta wishes”. This isn't a new
> situation -- the BSDs have been around forever. I think you'd meet a lot more
> acceptance and friendliness if you stopped insisting that Debian unilaterally
> adopted your conclusions and world view.

I would like to add that I would happily accept patches submitted to BTS
if it doesn't break anything.  But I won't check some obscure logs just
to make life of Nexenta easier, and certainly not after I have seen so
much unrelated marketing blobs posted on {ubuntu,debian}-devel from
Nexenta people.  So it's only your effort to supply enough
information/patches if you are interested in seamless recompiling of
debian packages on Nexenta.

Ondrej.
-- 
Ondrej Sury <[EMAIL PROTECTED]>


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

Re: SPNT Shopnet.com

[Valarie Kurtz]

Kolby,

http://au.geocities.com/creepily23335/

Valarie Kurtz, Ref. jzm322



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

Re: alternatives and priorities

[Petter Reinholdtsen]

[Wouter Verhelst]
> Which, I'm sure, is important for popcon maintainers; however, I
> don't think it is very relevant in this discussion (unless you can
> point me towards an editor that is implemented as a library ;-)

The problem do not only affect libraries.  There are other packages
(with user applications) which show up with no votes, or with a very
low number of votes.  I have not investigated this in detail, but want
everyone looking at the vote numbers to be aware of the problems with
it.

Heck, even the installation number have problems.  Just check out
http://qa.debian.org/developer.php?popcon=popularity-contest>,
showing that 99.72% of the machines reporting to popcon have popcon
installed.  I believe that when I figure out how the rest are
reporting to popcon.

(I suspect the last issue is a problem with corrupt dpkg data.)


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

Re: alternatives and priorities

[George Danchev]

On Sunday 21 May 2006 22:48, Petter Reinholdtsen wrote:
--cut--
> Heck, even the installation number have problems.  Just check out
> http://qa.debian.org/developer.php?popcon=popularity-contest>,
> showing that 99.72% of the machines reporting to popcon have popcon
> installed.  I believe that when I figure out how the rest are
> reporting to popcon.
>
> (I suspect the last issue is a problem with corrupt dpkg data.)

or some hosts have popularity-contest installed from pure upstream sources 
instead from a popularity-contest debian package, thus don't have it 
registered with the dpkg db.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Processed: Re: Bug#368383: dumb "manual page for..." NAME section on many man pages

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 368383 general
Bug#368383: dumb "manual page for..." NAME section on many man pages
Bug reassigned from package `man-db' to `general'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Sun Java available from non-free

[Thijs Kinkhorst]

On Sun, May 21, 2006 21:18, Josselin Mouette wrote:
>> PS: Yeah I'm a bit pissed of that we only have people criticizing when
>> we do great things.
>
> What great things? Taking irresponsible decisions that expose the whole
> project to legal actions from Sun? I don't feel like thanking anyone for
> that.

You appear to be legally schooled, as you are appearently able to judge
that the decisions are irresponsible.

Given this legal background of yours, could you please help by using that
to improve the licence, instead of just complaining about how others
handled it? Please give the right example.


Thijs


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

Unidentified subject!

[3185570860]

I want to suck dick

--

Mobile Email from a Cingular Wireless Customer http://www.cingular.com


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

Re: Sun Java available from non-free

[Martijn van Oosterhout]

On 5/21/06, Russ Allbery <[EMAIL PROTECTED]> wrote:

> The precise terms are to be found in the license: as long as the license
> is unchanged or unamended (with legally binding additions), the issues
> should not be considered solved...

No one has addressed my question about estoppel.  My guess is that Sun's
publicly stated interpretation of a clause of the license is more legally
binding than you think it is, but I'd love to see a legal opinion.


Given the word "estoppel" only has meaning in jurisdictions deriving
from English common law, I think it'd be silly to assume it works the
way you think it does in any of the other jurisdictions Debian or any
of its mirrors may come in contact with... If the choice-of-venue
clause is debatable, then certainly any talk of estoppel is also.

Certainly when it comes to licences, I'd say the written version
trumps anything. After all, that can be verified, I havn't heard
anything verbally from Sun myself saying what may or may not be
allowed. But IANAL.
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

Re: Sun Java available from non-free

[Josselin Mouette]

Le dimanche 21 mai 2006 à 22:38 +0200, Thijs Kinkhorst a écrit :
> Given this legal background of yours, could you please help by using that
> to improve the licence, instead of just complaining about how others
> handled it? Please give the right example.

I'm afraid I have more interesting things to do than helping non-free
software developers to get their non-free crap in the non-free archive.

I don't feel like I have to justify myself, and I also think my work at
Debconf has been more productive and more of a right example than that
of people interested in Sun-related PRs.

If Sun doesn't fix the license (and I don't think it is our work to fix
their license), we should simply remove the Sun software from non-free.
Well, I say "we", but in fact I should say "they", because only a small
number of persons in the project have the power to do that.

By the way, they also have the power to accept GNOME 2.14 in main. Don't
you think that would have been more productive than accepting the Sun
JVM?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Sun Java available from non-free

[Raphael Hertzog]

On Sun, 21 May 2006, Thomas Weber wrote:
> Don't you think that the main problem here is that there *wasn't* any
> discussion, at least for the vast majority of Debian developers and
> users?

No, if we should discuss before taking any action we wouldn't get
anything done. If you really want to contest the decision, you have the
GR.

That's it, but it would be unproductive.

> And yes, as a Debian user I'm surprised that such decisions are
> taken behind closed doors; this is not a security related issue and it
> wouldn't have done any harm to Debian to discuss this in the open.

Someone from Sun contacts you to examinate a new license for Java and ask
you advice and all, and ask you to keep that info private. What do you
respond to him ? "No sorry, we really don't care, go away"?

There was no other choice, that's all. 

> If that had delayed the inclusion, so be it; after several years without
> Sun's Java in Debian, some more weeks wouldn't have hurt neither users
> nor the project itself.

And we would have lost an opportunity to do some PR stuff and show
everyone that we're an important player in the Linux world.

The choice has already been made. Both sides have positive sides and
negative ones. The choice has been made, no point in discussing it over
again and again.

> Oh, and the impression that pushing non-free packages in after several
> hours has a high priority, while (license-wise) simple packages linger
> for weeks in NEW was probably a bonus[1].

I have to agree this sucks but if you have the schedule in mind it's easy
to understand:
- NEW is done by Joerg usually, he's organizing debconf so there's a
  backlog due to that
- Sun guys are here at debconf and finalize discussions with the java
  maintainers (Jeroen, Matthias Klose, Barry Hawkins), the package is
  finally uploaded and immediately installed by Jeroen (or another
  ftpmaster)
- We make an announce (almost) the same day than Sun announces its stuff
  at Javaone ...

> > > It would be bad PR if Debian will have to remove Sun Java from the
> > > archive, shortly after public announcements that it accepted it in.
> > 
> > No it wouldn't.
> 
> Well, there I disagree with you: it would. At the very least, it would
> give the impression that Debian can't decide what it wants.

No, it would simply show that Sun is not committed to what they told us.
We have been reasonable and accepted to work with them. If they change
their mind, then it's Sun which is not reasonable.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: RFC: Better portability for package maintainers

[Josselin Mouette]

Le dimanche 21 mai 2006 à 09:44 -0700, Erast Benson a écrit :
> because non-glibc Debian architectures does exists (i.e.
> FreeBSD,Solaris,Darwin)

Stop the lies.
  * The FreeBSD port is glibc-based.
  * There is no Darwin port. Fink is a toy based on APT and has
nothing in common with a complete distribution like Debian. It
doesn't even use the official Debian packages as a basis.
  * There is no Solaris port yet.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Sun Java available from non-free

[Raphael Hertzog]

On Sun, 21 May 2006, Romain Beauxis wrote:
> I know I shouldn't, but I was really upset by your answer.

You shouldn't be upset.

> I'm happy that people speak up and claim their fear with this licence, and 
> no, 

This is OK. They can ask questions and have a right to know why ftpmasters
accepted the package.

> I won't hide my personal reponsability behind the ftp masters' decision: my 
> concern is not a fear for myself but a fear for the project.
> 
> To all the questions and fears raised consciously and with arguments, you 
> answer them to shut up and respect the others decisions, that is not the way 
> I would work in this project as for sure.

No I don't answer to "shut up". I answer to stop now because Anthony Tows
responded to all the questions and give a precise course of action on how
we can continue improving the situation concerning the java licensing.

And I responded to someone who clearly doesn't agree with the ftpmasters
decision and will continue flaming as hell when he already knows
everything that he needs.

Fears are unfounded, we can at any time terminate the license by removing
java!

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: RFC: Better portability for package maintainers

[Josselin Mouette]

Le dimanche 21 mai 2006 à 09:44 -0700, Erast Benson a écrit :
> 

(Debian-devel, sorry for the spam.)

Erast, you shouldn't post on public mailing lists if you don't even
accept the email replies. Please fix your SMTP server by removing use of
the stupid and broken MAPS RBL, or simply stop posting.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Sun Java available from non-free

[Raphael Hertzog]

On Sun, 21 May 2006, Josselin Mouette wrote:
> Le dimanche 21 mai 2006 à 22:38 +0200, Thijs Kinkhorst a écrit :
> > Given this legal background of yours, could you please help by using that
> > to improve the licence, instead of just complaining about how others
> > handled it? Please give the right example.
> 
> I'm afraid I have more interesting things to do than helping non-free
> software developers to get their non-free crap in the non-free archive.

Good, but you shouldn't decide what others have to do. Some people are
interested in java in non-free, it's not your job to try to forbid them to
work on that.

> If Sun doesn't fix the license (and I don't think it is our work to fix

The license is good enough for Debian (ftpmasters took their decisions).
There's no fix to require, but it would be good to continue working them
to enhance even more the license. Such a constructive behaviour would put
us in a good position to make sure that Sun releases java in a DFSG-free
compliant license when they will open-source it.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Sun Java available from non-free

[Pierre Habouzit]

Le Dim 21 Mai 2006 23:04, Raphael Hertzog a écrit :
> Fears are unfounded, we can at any time terminate the license by
> removing java!

just do it, shall we ?
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpo1qHU0EPaw.pgp
Description: PGP signature

Re: Section of -dev packages

[Enrico Zini]

On Thu, May 18, 2006 at 05:06:13PM +0200, Goswin von Brederlow wrote:

> While we are at it why not remove sections alltogether?
> We have the debtags system that by far superseeds the sections and
> since the pool structure is used sections have been quite useless.

There are some reasons I'm not trying to push for this:

 1) some sections still are meaningful (base comes to my mind)
 2) there is no direct debtags 1-1 mapping for sections, so we have no
clear upgrade path for applications that still use sections
 3) I'm stuck with review of submitted tags, which means that the
reviewed set of tags that goes in the Packages page is outdated.
There is no current sustainable way to keep it up-to-date, and
debtags cannot go prime time until that happens.
Luckily they are ideas, some made it into the Summer of Code bundle,
some are mostly SMOP, in a way or another we'll have updated tags in
unstable again.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Unidentified subject!

[Hex Star]

o_O...I wonder if these explicit messages, and these obviously have the intent of being explicit are going to cause the same rise as the last explicit message sent to this list...a shame people send such nonsense to these helpful and knowladgeable lists...*sigh*...
On 5/21/06, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:I want to suck dick--Mobile Email from a Cingular Wireless Customer 
http://www.cingular.com--To UNSUBSCRIBE, email to [EMAIL PROTECTED]with a subject of "unsubscribe". Trouble? Contact 
[EMAIL PROTECTED]

Re: Sun Java available from non-free

[Raphael Hertzog]

On Sun, 21 May 2006, Josselin Mouette wrote:
> > interested in java in non-free, it's not your job to try to forbid them to
> > work on that.
> 
> Not if it hurts the project. And it does.

You think it does. Others do. Others don't. I don't. Start a GR if you
think the ftpmasters are wrong. There's no point in telling everyone that
you don't agree just for the sake of it.

> Collaborating with Sun is a good idea for people interested in it. But
> those people abused of their position in the project to force the
> software directly into non-free, without any kind of discussion.

How can someone force the inclusion when he's ultimately the one which
decides if the software can go in or not?

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Sun Java available from non-free

[Josselin Mouette]

Le dimanche 21 mai 2006 à 17:04 -0500, Raphael Hertzog a écrit :
> You think it does. Others do. Others don't. I don't. Start a GR if you
> think the ftpmasters are wrong. There's no point in telling everyone that
> you don't agree just for the sake of it.

I think this is going to happen.

> How can someone force the inclusion when he's ultimately the one which
> decides if the software can go in or not?

Please stop playing with words. If you don't want to discuss about this
matter, just don't do it.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Sun Java available from non-free

[Bill Allombert]

On Sun, May 21, 2006 at 11:09:04AM -0700, Russ Allbery wrote:
> At least so far as I understand it, the ftp-masters (i.e., the people who
> did this check) are the people responsible for verifying and checking
> licenses in uploaded packages and debian-legal exists as an advisory body
> for the ftp-masters and a place for Debian maintainers to ask for advice,
> not the other way around.
> 
> Is that not correct?

I want to clear a misonception: debian-legal is not an advisory body.
debian-legal is the Debian mailing list where public discussions about
legal issues are to be directed. 

As a consequence this is the list where you can expect to find people
interested to deal with legal issues, and it is where license
discussions happen.

Of course the FTP masters do use input from the debian-legal mailing
list.

However, in the normal process, ftp-masters are not the first and only 
people to deal with the package. The normal process for new packages
(documented in the developers-reference) is to issue an ITP stating in
particular the license of the package and send a copy to debian-devel.
New licenses are then sent to debian-legal for review.

In the case at hand no ITP has been issued. Unfortunately we can only
speculate on the motive.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Sun Java available from non-free

[Steve Langasek]

On Sun, May 21, 2006 at 11:24:12PM +0200, Josselin Mouette wrote:
> Le dimanche 21 mai 2006 à 16:17 -0500, Raphael Hertzog a écrit :
> > Good, but you shouldn't decide what others have to do. Some people are
> > interested in java in non-free, it's not your job to try to forbid them to
> > work on that.

> Not if it hurts the project. And it does.

How?

> > The license is good enough for Debian (ftpmasters took their decisions).
> > There's no fix to require, but it would be good to continue working them
> > to enhance even more the license. Such a constructive behaviour would put
> > us in a good position to make sure that Sun releases java in a DFSG-free
> > compliant license when they will open-source it.

> Collaborating with Sun is a good idea for people interested in it. But
> those people abused of their position in the project to force the
> software directly into non-free, without any kind of discussion.

No discussion is required.  The only requirement for non-free is that the
ftp-masters, as the parties directly responsible for deciding what ends up
on the Debian mirrors, are comfortable with the consequences of distributing
the work.

If you have a reason to believe that the ftpmasters have *misjudged* the
liability involved, or you are approaching this as a mirror operator who is
not comfortable with the license and might have to drop non-free as a
result, it is reasonable for you to voice such concerns and try to persuade
the ftpmasters to revert the decision.  But arguing that they have wronged
the project by not consulting you first is so much bullshit, because *they*
are the ones who bear the primary liability from distributing these
packages, and other developers (as opposed to mirror operators) bear none at
all.  They didn't ask you because Debian is not a democracy and random
opinions on this decision *don't* matter.

Even debian-legal isn't particularly relevant here, because the culture on
that list is oriented towards identifying worst-case scenarios and testing
them against the DFSG's requirements, *not* doing risk-assessment for
non-free.  For the latter, you ought to be recommending the ftpmasters
consult a lawyer, not a mailing list.

> Individual collaborations with companies like Sun can indeed benefit the
> project. Involving the whole project by force doesn't.

No one involved you by force; the bitching you're doing on the mailing lists
is of your own free will.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Section of -dev packages

[Goswin von Brederlow]

Enrico Zini <[EMAIL PROTECTED]> writes:

> On Thu, May 18, 2006 at 05:06:13PM +0200, Goswin von Brederlow wrote:
>
>> While we are at it why not remove sections alltogether?
>> We have the debtags system that by far superseeds the sections and
>> since the pool structure is used sections have been quite useless.
>
> There are some reasons I'm not trying to push for this:
>
>  1) some sections still are meaningful (base comes to my mind)

[EMAIL PROTECTED]:~% grep-dctrl -F Priority required 
/var/lib/apt/lists/storage_debian-amd64_dists_stable_main_binary-amd64_Packages 
-s Section | sort | uniq -c
  1 Section: admin
 36 Section: base
  1 Section: devel
 12 Section: libs
  1 Section: oldlibs

Not so usefull with over 25% exceptions to the rule.

>  2) there is no direct debtags 1-1 mapping for sections, so we have no
> clear upgrade path for applications that still use sections

Does anything use them apart from sorting them into sections for
display? It should not be so difficult to add the value of section to
each packages debtags in some form if that is considered usefull.

MfG
Goswin


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

Re: Sun Java available from non-free

[Josselin Mouette]

Le dimanche 21 mai 2006 à 16:17 -0500, Raphael Hertzog a écrit :
> Good, but you shouldn't decide what others have to do. Some people are
> interested in java in non-free, it's not your job to try to forbid them to
> work on that.

Not if it hurts the project. And it does.

> The license is good enough for Debian (ftpmasters took their decisions).
> There's no fix to require, but it would be good to continue working them
> to enhance even more the license. Such a constructive behaviour would put
> us in a good position to make sure that Sun releases java in a DFSG-free
> compliant license when they will open-source it.

Collaborating with Sun is a good idea for people interested in it. But
those people abused of their position in the project to force the
software directly into non-free, without any kind of discussion.

Individual collaborations with companies like Sun can indeed benefit the
project. Involving the whole project by force doesn't.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Sun Java available from non-free

[Pierre Habouzit]

Le Lun 22 Mai 2006 00:55, Steve Langasek a écrit :
> On Sun, May 21, 2006 at 11:24:12PM +0200, Josselin Mouette wrote:
> > Le dimanche 21 mai 2006 à 16:17 -0500, Raphael Hertzog a écrit :
> > > Good, but you shouldn't decide what others have to do. Some
> > > people are interested in java in non-free, it's not your job to
> > > try to forbid them to work on that.
> >
> > Not if it hurts the project. And it does.
>
> How?

I personally thinks it hurts our users, and as a secondary effect, us. 
Beeing distributable is a property that should not be depends upon the 
time, the color of your hair, or the phase of the moon.

Java license (especially clause 4) makes the distribution of a specific 
version of java beeing revocable, which can hurts a lot of users that 
may then depends on it. A re-licensing e.g. would not be the same, 
because the last previous version that had a distributable license 
would still be allowed to stay in non-free until full deprecation or 
even for life.

the java license is full of retro-active clauses, that can lead into the 
removal of *any* version of java that has ever been in debian. Even one 
that has been distributed to millions of users. *that* would hurt.

another writing of the clause 4 that would be acceptable for debian is 
the following:


 » this version of java comes with that list of requirements your
 » kernel/OS/arch/... *must* support [the list]. If you don't or can't,
 » you are not allowed to ship that version of java.


that would be acceptable for non-free, because if a version of java 
qualifies for a given stable release, it will for life.

beeing distributable is not a property that is 50% true and need killing 
a cat to know if it's rather 1 or rather 0.


for me, this issue *is* the real one. and I'd support any GR (or any 
kind of action) that would precise what we call "distributable" implies 
durability of that state. I just cannot imagine that we allow a package 
even into non-free if we are not sure it can stay here forever.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp62Tg9RDUWb.pgp
Description: PGP signature

Re: [Fwd: Re: RFC: Better portability for package maintainers]

[Josselin Mouette]

Le samedi 20 mai 2006 à 19:43 -0700, Erast Benson a écrit :
> Nexenta is absolutely rock stable OS (thanks to legendary Solaris
> history)

Solaris history is indeed legendary, but not for its stability.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Making init scripts use dash

[David Weinehall]

On Fri, May 19, 2006 at 03:34:17PM +0200, Wouter Verhelst wrote:
> On Fri, May 19, 2006 at 05:45:46AM +0200, David Weinehall wrote:
> > Well, most of those scripts can be fixed quite easily, some require
> > a bit more work.  I hereby promise to help fixing them to the extent
> > of my capability.
> 
> Let's see. The nbd-client and nbd-server initscripts use bash arrays. Do
> you have an alternative way to implement their current behaviour, so
> that it would work with dash?
> 
> (note that requiring the configuration file format to be changed would
> not be something I would oppose too strongly, if it would make sense)

I'll have a look at it and see what I can do.


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


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

Re: Sun Java available from non-free

[Josselin Mouette]

Le dimanche 21 mai 2006 à 15:55 -0700, Steve Langasek a écrit :
> If you have a reason to believe that the ftpmasters have *misjudged* the
> liability involved,

This is the whole point of the discussion.

> or you are approaching this as a mirror operator who is
> not comfortable with the license and might have to drop non-free as a
> result, it is reasonable for you to voice such concerns and try to persuade
> the ftpmasters to revert the decision.  But arguing that they have wronged
> the project by not consulting you first is so much bullshit, because *they*
> are the ones who bear the primary liability from distributing these
> packages, and other developers (as opposed to mirror operators) bear none at
> all.  They didn't ask you because Debian is not a democracy and random
> opinions on this decision *don't* matter.

Indeed, they will bear the *primary* liability. However if legal action
is taken against them or our mirror operators because of their decision,
the whole distribution process might suffer, affecting all developers
and users.

By reading your email, I feel you are acknowledging the fact the
ftp-masters cabal (I can't name it otherwise after seeing their behavior
IRL) is treating other developers as second-class contributors who
should just do as they say.

Re-read the constitution. By several aspects, Debian *is* a democracy.
Some developers are ignoring it, but this is something that should be
fixed.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Sun Java available from non-free

[Alexander Wirt]

Raphael Hertzog schrieb am Sonntag, den 21. Mai 2006:

*snip*

> The license is good enough for Debian (ftpmasters took their decisions).
> There's no fix to require, but it would be good to continue working them
> to enhance even more the license. Such a constructive behaviour would put
> us in a good position to make sure that Sun releases java in a DFSG-free
> compliant license when they will open-source it.
I strongly disagree, did you ever red the licence?
And even a ftp-master decision can be wrong. Or it can be overriden by the
project via a GR (a way that I'll go if I have to)

Alex


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

Bug#368395: ITP: blockattack -- Tetris Attack Clone

[Gonéri Le Bouder]

Package: wnpp
Severity: wishlist
Owner: "Gonéri Le Bouder" <[EMAIL PROTECTED]>

* Package name: blockattack
  Version : 1.1.2 
  Upstream Author : Poul Sander 
* URL : http://blockattack.sourceforge.net/
* License : GPL
  Programming Lang: C, C++
  Description : Tetris Attack Clone

Block Attack - Rise of the Blocks is a puzzle/blockfall game inspired by
Nintendo's Tetris Attack for the Super Nintendo. The game is pretty
action packed for a puzzle game

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-amd64-k8
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

Re: Sun Java available from non-free

[Steve Langasek]

On Mon, May 22, 2006 at 01:06:42AM +0200, Pierre Habouzit wrote:
> Le Lun 22 Mai 2006 00:55, Steve Langasek a écrit :
> > On Sun, May 21, 2006 at 11:24:12PM +0200, Josselin Mouette wrote:
> > > Le dimanche 21 mai 2006 à 16:17 -0500, Raphael Hertzog a écrit :
> > > > Good, but you shouldn't decide what others have to do. Some
> > > > people are interested in java in non-free, it's not your job to
> > > > try to forbid them to work on that.

> > > Not if it hurts the project. And it does.

> > How?

> I personally thinks it hurts our users, and as a secondary effect, us. 
> Beeing distributable is a property that should not be depends upon the 
> time, the color of your hair, or the phase of the moon.

> Java license (especially clause 4) makes the distribution of a specific 
> version of java beeing revocable, which can hurts a lot of users that 
> may then depends on it. A re-licensing e.g. would not be the same, 
> because the last previous version that had a distributable license 
> would still be allowed to stay in non-free until full deprecation or 
> even for life.

These are fine reasons why Sun should be encouraged to make Java free
software, instead of merely making it redistributable; or why we should
educate users about the importance of Free Software and why they should
think twice before accepting non-free solutions.  This might even be an
argument for Debian discontinuing non-free altogether.

But I don't really see that they apply as reasons to keep Java out of
non-free.  Non-free is, well, non-free: very little, if any, of the stuff in
there is distributed under terms that would prevent a copyright holder from
later forbidding us from distributing the existing work, AFAIK, and there's
no reason in general that we should be *happy* with the licenses of any
works in non-free (though some individuals in the community may be).

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Sun Java available from non-free

[Brett Parker]

On Sun, May 21, 2006 at 11:51:38PM +0200, Pierre Habouzit <[EMAIL PROTECTED]> 
wrote:
> Le Dim 21 Mai 2006 23:04, Raphael Hertzog a écrit :
> > Fears are unfounded, we can at any time terminate the license by
> > removing java!
> 
> just do it, shall we ?

Gets my, uncountable, vote.

Cheers,
Brett.


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

Re: [draft] Re: Sun Java available from non-free

[Gustavo Franco]

On 5/19/06, Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:

(...)
> > (b) the Software is distributed with your Operating System, and
> > such distribution is solely for the purposes of running Programs
> > under the control of your Operating System and designing,
> > developing and testing Programs to be run under the control of
> > your Operating System;
>
> non-free is not part of Debian so we definetly don't distribute it as
> part of the Operating system.

Note that the license says "... is distributed *with* your Operating
System", and not "is part of". I don't know where you read the "part of"
bit? Anyway, we definitely do distribute non-free *with* our OS, it's in
debian/pool/non-free on all our mirrors alongside debian/pool/main, and
distributing it in the same directory hierarchy is definitity "with" in
my book.


Could you paste your answer to the p&p question below[0] ?

- What is Debian's (current) approach to non-free software?  Why?  Is
non-free part of the Debian System?

[0] = "Mini-HOWTO for Debian New Maintainers Application Managers" /
APPENDIX 3: SAMPLE QUESTIONS ON PHILOSOPHY
URL: http://people.linux.org.tw/~chihchun/cddp/www/devel/join/nm-amhowto


(...)


Thanks in advance,
-- stratus

Re: Bug#368371: ITP: gp2c -- PARI/GP GP to C compiler

[Bill Allombert]

On Sun, May 21, 2006 at 10:18:19PM +0200, Nacho Barrientos Arias wrote:
> > * Package name: gp2c
> >   Version : 0.0.4pl5
> >   Upstream Author : Your truly <[EMAIL PROTECTED]>
> > * URL : http://pari.math.u-bordeaux.fr/
> > * License : GPL
> >   Programming Lang: C
> >   Description : PARI/GP GP to C compiler
> 
> IMHO, pari-gp-c or pari-gp2c could be better than 'gp2c' to avoid
> this namespace pollution, at your option.

Good catch, I will consider this option. gp2c is the upstream source
package name.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Re: [draft] Re: Sun Java available from non-free

[Drew Parsons]

Michael wrote:
> 
> > Speaking realistically, such a move of Sun would be spectacularly bad PR
> > for them esp. considering their statements about future Java licensing
> > efforts they have committed to.
> 
> That's true. But why did they release this license and used no other
> wording?
> 
> You essantially say, why worry about a license if it's bad PR too sue
> the licensees. I doubt it really works that way. After all you could, at
> some point somehow, get into a situation where Sun doesn't care about
> the PR effect.

True.  We only have to look at the once-noble company called Santa Cruz
Operations for a real-life example.

Drew


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

[EMAIL PROTECTED] list has moved

[Aaron Leonard]

The [EMAIL PROTECTED] list has been superseded by the list
[EMAIL PROTECTED] (see: http://puck.nether.net/mailman/listinfo/cisco-nas).


-Original Message-
Return-path: <[EMAIL PROTECTED]>
Received: from fire.cisco.com (firebird.cisco.com)
 by Cisco.COM (PMDF V5.1-7 #12361) with ESMTP id <[EMAIL PROTECTED]>
 for ~aaron; Sun, 21 May 2006 18:32:59 PDT
Received: from firebird.cisco.com (firebird.cisco.com [171.68.227.73])
 by fire.cisco.com (8.11.7p2+Sun/8.11.7) with ESMTP id k4M1WwT27104 for
 <[EMAIL PROTECTED]>; Sun, 21 May 2006 18:32:58 -0700 (PDT)
Received: (from [EMAIL PROTECTED]) by firebird.cisco.com (8.11.7p2+Sun/8.11.7)
 id k4M1WwC27082 for [EMAIL PROTECTED]; Sun,
 21 May 2006 18:32:58 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87])
 by fire.cisco.com (8.11.7p2+Sun/8.11.7) with ESMTP id k4M1WvT27070 for
 <[EMAIL PROTECTED]>; Sun, 21 May 2006 18:32:57 -0700 (PDT)
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
 by sj-iport-5.cisco.com with ESMTP; Sun, 21 May 2006 18:32:57 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
 by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k4M1WvF5021900; Sun,
 21 May 2006 18:32:57 -0700
Received: from sj-inbound-c.cisco.com
 (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-1.cisco.com
 (8.12.10/8.12.6) with ESMTP id k4M1WmB7025883 for
 <[EMAIL PROTECTED]>; Sun, 21 May 2006 18:32:49 -0700 (PDT)
Received: from c-24-60-48-44.hsd1.ma.comcast.net (HELO lists.debian.org)
 ([24.60.48.44]) by sj-inbound-c.cisco.com with ESMTP; Sun,
 21 May 2006 18:32:44 -0700
Date: Sun, 21 May 2006 21:32:22 -0400
From: debian-devel@lists.debian.org
Subject: [WARNING: VIRUS REMOVED] Delivery reports about your e-mail
To: [EMAIL PROTECTED]
Message-id: <[EMAIL PROTECTED]>
MIME-version: 1.0
X-Mailer: Microsoft Outlook Express 6.00.2600.
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_[ID_f9I6iKp8mR7RmXCiFRLrkQ]"
X-Priority: 3
X-from-outside-Cisco: 24.60.48.44
X-BrightmailFiltered: true
X-IronPort-AV: i="4.05,152,1146466800"; v="W32/MyDoom-O'3'rd";
 d="txt'?com'96,83?zip'96,83,48?scan'96,83,48,48,96,83,208";
 a="278081739:sNHsT202217082"
X-MSMail-Priority: Normal
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.
Authentication-Results: sj-dkim-2.cisco.com;
 [EMAIL PROTECTED]; dkim=neutral
X-Authentication-warning: firebird.cisco.com: aaron set sender to
 [EMAIL PROTECTED] using -f

This is a multi-part message in MIME format.

--Boundary_[ID_f9I6iKp8mR7RmXCiFRLrkQ]
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: QUOTED-PRINTABLE

X=C3=B7=A2D=C7=EA=A7g=A0\=F2=A4=F7=C2=D5=EEJ`Y(=A1=F9=98##=C1d4=D3=
=D0=91=D4=F9=A0w"=9D=92s_=B1[pb=CC5_=EC=C9G=DA=C8Mwd=E9=C9^=B3 hvLCp9=
I=93G=DFg3=EF3=D3Au=9B%I=CD5Y=AD.=F1=D6vQywp=87=F0a=C3O=C686e=C66=
=EFJ=9C=A1wl=B8=BB=88=8D=887[=B2=F6=F1k*t=B6N=D1;=F0xUn=E0,(]&g=BE=
=B7q[Q=B4d=F5=E9=D1OP=FB#>5=84=82=CE,b=CB=C0=D9`|S=A3=89=ED=95~k=D5=
=DFu=AF=A64=9BY=BD=F3=A1Q7d!4=95j=B7=F6=93=89h=BAl=8A=D3=ECB=D6=86=
=97=86kvMN{=A1=D4=C0=CF=AD=F5Q=93=8D=B3=CEJ=E2=B3{P=C0=95=AE=87=A3=
=A8=D4v;h=A32nfK!8=A4=81H=E8x=C8d=C9k=8E5_=FAb=BAm=B4=A9=EAU=A2=EEq=
=EB=99=AB=95=AC=F1=FD_=F6=E7=C0=E7=96=F1=87=B8{=B7Ob=99=DF=DC=FD=B7=
=F4=C5=D1[=A3=B7ozp=C0=84Y=D0<=BD,=C4=C8b=86=DB=F8t=A1=E3=8Fm=CDs=
=84=D0/xv=B2=D6HW=D6=C7=C7-=F2=C6=85=F1G=94o=D1=C7=CD=C8=F4RI=A0=FAz8=
=ACE=B8=CF=C8|=E6=C6o=EB=A7&=D3]=F2Z=CE=CC-J=F6=95=96=C5=BCL=97=F2=
=A8=D7F.2=B3=D0=86=C5 6N(=90^=85~_=C0j
f=BD=A99'=CD4)c=EB=9F=91C=B5=C7=ED=89=EAbc;=83=B5=A7=98=95=92=C7=F3=
=A7=B9=E3=C5=FC=95r=B6=95=96=E2U=B7=C8=A7S\=8F=ED=86K;d=DB|=F5=BD#=
=AB>
=99=B2=C4Xl=AF=9Dx3=85=BEG`=E5=DB=97Qh=BA=B9!=85=99=85=D9=A7Z=AC^T=
=B2c=F0_?B=F8o=B9=9F1=92=C1=C7=FB=E8=B1j,=FD=C0=C1=A3=B7
=DCF=AF=98DX=E3=D3=F6GS=F0=A9=87#6
=B9=F7hK=F4=A5/=A1=A9
=EE=93=C4=B11=A0=C9=C5?=836=B1TK=98g=EEk=F8=9FkY=EAyy=BCUL=C1D=F6=
=BF<=B4=ACg=C9=DB=AA=F8=94X}E<=88=86'=89=C0=CBhf=A0=D1_U"r=93I=A2=
=CE=BDU=BCF=D5\E|=A40
l=E4=AC
SR
,=92=82=92Q)W=9E=A2A-=D3=81=CAEYWoE.b=A0=A5=8203=B3Y=D8\=DC=DD=8D=
=9F=8A=C0=C2=C0=B7Bm=DF=EB=E6=8FFb=F2=9E=8Am7=F4=D7=90Z_kZ=99=A9`=
=8F=89=D3>U{=FDwr=D99=EB=93=9F=A5=D3=D5=D3w =A9p{=F5T=E2=91,n=8D*=
=CFfG=CF=A0=FC=DA=99=91=C6=83=BAM=ACu=F3=ADl
V=9C=83=9A=E5)=AB=CD=93]RX=88|=F3=95=E3=94=EE=E0=E4=F1}=AA=A2OpPp1=
=F5g=B8=FCb{=90
}=ED=842IT=B5=E6%?=B6=DD=B6=F0=D1=D7=8E14=9B=BE=9E=B2D=8B=DF=E2=E3e=
=FD=D5=9B=AC=AE=91=A9=E2=E9=BA=D4=D3=97=B5*wo=A89=F9W4=E2/=D5=D7=C14=
=87=C7\=DD\=CA=AF}"=F9]=BBY_=C4vt=8EF=A0>=81=843=C6g=D7rZ(k=92=C6=
=B1BX=EE=F8=A6=FBV=91^=BF8*K=A7/=F1?=DB=9C,=D0Z=B1=95=88s[=B0~=E8=
=F3c=89!d=86.=B0=D2=83=F7=90=DBA7=97=BE=96=F3=9Dm=B6=C4:QY=E1m=AC=
=88=87OZ:=8DBLK=D9=8B=9BFB(#^=A7=A2=8EL=87-=98s=ED=82$=C4=A9=C4=C8=
=CC=84=BA=8C=C1=B8=B2=87=CCp=A4=F5=ABKe&f=9C=A1o=BB~=AA=9E=8F=C8/=
=BF=EE=A5=ABH=B1Z!>=DD_=98=E0=9C=F3*=D5XW=827=C9I=94=CA=A5>C=B4=98KX=
=F5=A3{-=C2=9CL1M=FE
=C8}=D1}=9EU=BD_=92g=8E=89A|=C3=B9=F8=E0c=E9a#a
1=F3C=D1=D8=E3=E2=B1=98a
=EE=81=FD=A4SF=93=8Ea\=C8>=D2=9CV2=C3=F9=F4=FA
m =BA=81~=94=83=FA|=E

Re: Multiarch preparations needed for etch dpkg

[Steve Langasek]

On Sat, May 20, 2006 at 10:27:35PM +0200, Goswin von Brederlow wrote:
> Matt Taggart and others <[EMAIL PROTECTED]> writes:


> > Several people have been working on a project we've been calling 
> > "multiarch", 
> > to seamlessly support running applications for multiple different binary 
> > targets on the same system. The main example being running i386-linux-gnu 
> > applications on amd64-linux-gnu systems, but many other working 
> > combinations 
> > exist. More info on Debian's multiarch efforts at

> >   http://wiki.debian.org/multiarch

> > Part of implementing multiarch requires changes to dpkg.

> I've added another section to the wiki above listing the changes I
> would like to see implemented in etch dpkg in preparation for a future
> multiarch dpkg. I still think multiarch can be done in the current
> dpkg, esspecialy since I have an implementation that is 90% there.

> The listed changes are linked on the main page or directly under

> http://wiki.debian.org/dpkg-multiarch

> This comes down to 3 small changes with little to no impact on the
> current system but enabling features for the future:

> - Introduce the Multi-Arch field so sources can already set it

> - Store meta data with an arch tag when Multi-Arch: yes is set
>   (Note that no package yet sets this. This is so packages can start
>   using Multi-Arch: yes without confusing future dpkg about file
>   locations.)
>   I propose to use /var/lib/dpkg/info/..install as syntax.

> - Allow arch specific depends
>   I propose to use "Depends: : (>= 1.2-3)" as syntax for
>   thses. While for etch no package should use them dpkg should accept
>   them so installing etch+1 debs can go without hitch.
>   (Note that this also impacts on apt and aptitude)

Please provide a counter-example to the following assertion:

 A multiarch package's dependency on another package must be satisfied by a
 package of a particular (i.e., of the same) architecture IFF the depended-on
 package is also a multi-arch package.

If you don't have any counter-examples to this claim, then it's my belief
that the last of these changes is not required, because versioned
dependencies are enough to ensure the dependency is not incorrectly
satisfied by a non-multiarch version of the package, and Multi-Arch: yes
flags on the new versions of the package give dpkg & front-ends enough
information to correctly determine whether the dependency is properly
satisfied and to resolve the dependency if not.

I believe this removes the need for a backwards-incompatible syntax change
to the Depends: field, which is an objection I had to the posted dpkg v2
multiarch proposal as well.  (Note that without this change to Depends:
syntax, any of these "multiarch" packages can be installed fine on the
native architecture with the existing dpkg, but that with this syntax change
users must first upgrade to a new set of packaging tools before these
package relationships are parseable.)

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: CAN-2005-3163: polipo permits reading files outside of web root di

[Juliusz Chroboczek]

Hi Tom,

(I am the upstream author of Polipo.)

I have just checked the sources of polipo 0.9.8-1, and this bug is
still present.  This is a serious security bug, but is mitigated by
the Debian installation.

The bug allows anyone who has access to Polipo's local web server to
read any file that is readable by the Polipo process.  The following
factors mitigate the threat:

  - by default, Debian's Polipo only listens on 127.0.0.1;
  - Polipo is run by the proxy user, who should not have access to any
critical files.

There is, as far as I know, no possibility of an attacker managing to
write a file.

You may work around the issue by adding the line

  localDocumentRoot = ""

to the file /etc/polipo/config.

Still, I believe that this bug should definitely be fixed.  Choices
include:

  - applying the appended patch;
  - upgrading to 0.9.9, which has been out since September 2005.

I hold no opinion on whether this bug should be marked release-critical.

Juliusz

--- /usr/local/src/polipo/polipo-stable-0.9/diskcache.c 2006-05-20 01:33:04.
0 +0200
+++ polipo-0.9.8/diskcache.c2004-10-25 22:26:37.0 +0200
@@ -264,14 +264,10 @@
 if(n <= localDocumentRoot->length)
 return -1;
 
-i = 0;
-if(key[i] != '/')
-return -1;
-
 memcpy(buf, localDocumentRoot->string, localDocumentRoot->length);
-j = localDocumentRoot->length;
-if(buf[j - 1] == '/')
-j--;
+i = 1; j = localDocumentRoot->length;
+if(buf[j - 1] != '/')
+buf[j++] = '/';
 
 while(i < len) {
 if(j >= n - 1)


pgpgaFrNwXEWA.pgp
Description: PGP signature

Bug#368412: ITP: flup -- Implements Python Web Server Gateway Interface (WSGI)

[Kai Hendry]

Package: wnpp
Severity: wishlist
Owner: Kai Hendry <[EMAIL PROTECTED]>

* Package name: flup
  Version : 0.1913
  Upstream Author : Allan Saddi <[EMAIL PROTECTED]>
* URL : http://www.saddi.com/software/flup
* License : BSD
  Programming Lang: Python
  Description : Implements Python Web Server Gateway Interface (WSGI)

 Implements the standard interface between Python Web applications and Web
 servers, as described in PEP 333, http://www.python.org/dev/peps/pep-0333
 Speaks:
  * AJP - Apache JServ Protocol 1.3
  * FastCGI, see http://www.fastcgi.com/
  * SCGI - Simple Common Gateway Interface alternative

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


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

Re: Sun Java available from non-free

[Russ Allbery]

Martijn van Oosterhout <[EMAIL PROTECTED]> writes:

> Given the word "estoppel" only has meaning in jurisdictions deriving
> from English common law, I think it'd be silly to assume it works the
> way you think it does in any of the other jurisdictions Debian or any of
> its mirrors may come in contact with...

In the other jurisdictions that you're familiar with, is there any similar
principal where if you make a recorded public statement that something is
okay, you cannot then later sue someone for doing what you said was okay?

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: alternatives and priorities

[Miles Bader]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Similary any vi extension should top vi itself. Also zile, emacs,
> xemacs build kind of a progression.

"Kind of progression"??

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia


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

Re: Sun Java available from non-free

[Brett Parker]

On Sun, May 21, 2006 at 03:58:18PM -0500, Raphael Hertzog <[EMAIL PROTECTED]> 
wrote:
> On Sun, 21 May 2006, Thomas Weber wrote:
> > Don't you think that the main problem here is that there *wasn't* any
> > discussion, at least for the vast majority of Debian developers and
> > users?
> 
> No, if we should discuss before taking any action we wouldn't get
> anything done. If you really want to contest the decision, you have the
> GR.
> 
> That's it, but it would be unproductive.

How so? a GR to get it back out again because of a bad licence seems
like a good idea at the moment (but, IANADD, so your milage may vary).
It seems that there's a fairly large group of people that do not agree
with the licence, and from the discussion on the list I'm inclined to
agree with them.

> > And yes, as a Debian user I'm surprised that such decisions are
> > taken behind closed doors; this is not a security related issue and it
> > wouldn't have done any harm to Debian to discuss this in the open.
> 
> Someone from Sun contacts you to examinate a new license for Java and ask
> you advice and all, and ask you to keep that info private. What do you
> respond to him ? "No sorry, we really don't care, go away"?

Bing bing bing... and so they become too close to the situation...

> There was no other choice, that's all. 

Yes there was, just because you're reviewing a licence and giving
feedback doesn't then mean that it should be added to the archive
without discussion... 

> > If that had delayed the inclusion, so be it; after several years without
> > Sun's Java in Debian, some more weeks wouldn't have hurt neither users
> > nor the project itself.
> 
> And we would have lost an opportunity to do some PR stuff and show
> everyone that we're an important player in the Linux world.

Ah right, so it's all a PR excercise... I assume that it was part of the
planning that it'd go in and *then* there'd be an uproar about it then,
that's *great* PR that is.

> The choice has already been made. Both sides have positive sides and
> negative ones. The choice has been made, no point in discussing it over
> again and again.

*sigh* - so, in your eyes there's no fix, it's a one off "it's been
done, let's move on" and leave it in non-free?

> > Oh, and the impression that pushing non-free packages in after several
> > hours has a high priority, while (license-wise) simple packages linger
> > for weeks in NEW was probably a bonus[1].
> 
> I have to agree this sucks but if you have the schedule in mind it's easy
> to understand:
> - NEW is done by Joerg usually, he's organizing debconf so there's a
>   backlog due to that
> - Sun guys are here at debconf and finalize discussions with the java
>   maintainers (Jeroen, Matthias Klose, Barry Hawkins), the package is
>   finally uploaded and immediately installed by Jeroen (or another
>   ftpmaster)
> - We make an announce (almost) the same day than Sun announces its stuff
>   at Javaone ...

Right... and this is good in what way?

> > > > It would be bad PR if Debian will have to remove Sun Java from the
> > > > archive, shortly after public announcements that it accepted it in.
> > > 
> > > No it wouldn't.
> > 
> > Well, there I disagree with you: it would. At the very least, it would
> > give the impression that Debian can't decide what it wants.
> 
> No, it would simply show that Sun is not committed to what they told us.
> We have been reasonable and accepted to work with them. If they change
> their mind, then it's Sun which is not reasonable.

Errr, hang on... surely it shouldn't have been accepted in to the
archive *until* the commitment had reached it's potential so that we
then didn't have this endless debate on the list, and the potential of a
GR? Surely it's up to the project to decide what's fit for inclusion,
and with the current licence, I don't see as it is.

Cheers,
Brett.


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

Re: Sun Java available from non-free

[Adam Warner]

On Sun, 21 May 2006 16:17:52 -0500, Raphael Hertzog wrote:

>> If Sun doesn't fix the license (and I don't think it is our work to fix
> 
> The license is good enough for Debian (ftpmasters took their decisions).
> There's no fix to require, but it would be good to continue working them
> to enhance even more the license. Such a constructive behaviour would
> put us in a good position to make sure that Sun releases java in a
> DFSG-free compliant license when they will open-source it.

As Bill Allombert just pointed out, the Intention To Package process was
clearly subverted:


   Assuming no one else is already working on your prospective package,
   you must then submit a bug report (Bug reporting, Section 7.1) against
   the pseudo-package wnpp describing your plan to create a new package,
   including, but not limiting yourself to, a description of the package,
   the license of the prospective package, and the current URL where it
   can be downloaded from.

That is, "you must" submit descriptions of the new packages, including
their license(s). In this case the license was brand new and likely
controversial. Yet every stage was conducted in secret, including
immediate uploads into non-free.

Will YOU take personal responsibility to stand by this license as
appropriate for non-free? Reread clause 2 of the Distributor License for
Java version 1.1:

   License Grant. Subject to the terms and conditions of this
   Agreement, as well as the restrictions and exceptions set forth in
   the Software README file, Sun grants you a non-exclusive,
   non-transferable, royalty-free limited license to reproduce and use
   the Software internally, complete and unmodified, for the sole
   purposes of running Programs and designing, developing and testing
   Programs.  Sun also grants you a non-exclusive, non-transferable,
   royalty-free limited license to reproduce and distribute the
   Software, directly or indirectly through your licensees,
   distributors, resellers, or OEMs, electronically or in physical
   form or pre-installed with your Operating System on a general
   purpose desktop computer or server, provided that: (a) the Software
   and any proprietary legends or notices are complete and unmodified;
   (b) the Software is distributed with your Operating System, and
   such distribution is solely for the purposes of running Programs
   under the control of your Operating System and designing,
   developing and testing Programs to be run under the control of your
   Operating System; (c) you do not combine, configure or distribute
   the Software to run in conjunction with any additional software
   that implements the same or similar functionality or APIs as the
   Software; (d) you do not remove or modify any included license
   agreement or impede or prevent it from displaying and requiring
   acceptance; (e) you only distribute the Software subject to this
   license agreement; and (f) you agree to defend and indemnify Sun
   and its licensors from and against any damages, costs, liabilities,
   settlement amounts and/or expenses (including attorneys' fees)
   incurred in connection with any claim, lawsuit or action by any
   third party that arises or results from (i) the use or distribution
   of your Operating System, or any part thereof, in any manner, or
   (ii) your use or distribution of the Software in violation of the
   terms of this Agreement or applicable law.  You shall not be
   obligated under Section 2(f)(i) if such claim would not have
   occurred but for a modification made to your Operating System by
   someone not under your direction or control, and you were in
   compliance with all other terms of this Agreement.  If the Software
   README file permits certain files to be replaced or omitted from
   your distribution, then any such replacement(s) or omission(s)
   shall not be considered a breach of Section 2(a).

Distribution is conditioned upon acceptance of subclause (f). The
distributor agrees to defend and indemnify Sun and its licensors from and
against any damages, costs, liabilities, settlement amounts and/or
expenses (including attorneys' fees) incurred in connection with any
claim, lawsuit or action by any third party that arises or results from
(i) the use or distribution of your Operating System, or any part thereof,
in any manner...

IN ANY MANNER. Note that arises or results from in any manner is distinct
from "your use or distribution of the Software in violation of the terms
of this Agreement or applicable law."

There is a defence for (f)(i) if the modifications causing the damages,
costs, liabilities, settlement amounts, etc. were not under the
distributors direction or control (while being in compliance with all
other terms of the Agreement). This defence may not be applicable when
modifications that happen to cause damage, etc. are under the direction or
control of Debian/SPI.

When d

Re: [Fwd: Re: RFC: Better portability for package maintainers]

[Matthew Palmer]

On Sun, May 21, 2006 at 11:30:59PM +0200, Josselin Mouette wrote:
> Le samedi 20 mai 2006 à 19:43 -0700, Erast Benson a écrit :
> > Nexenta is absolutely rock stable OS (thanks to legendary Solaris
> > history)
> 
> Solaris history is indeed legendary, but not for its stability.

Well, when you consider what dict(1) has to say about 'legendary':

"Of or pertaining to a legend or to legends; consisting of legends"

when legends are:

"Any wonderful story coming down from the past, but not verifiable by
historical record; a myth; a fable"

You and Erast may be violently agreeing with each other.

> -- 
>  .''`.   Josselin Mouette/\./\
> : :' :   [EMAIL PROTECTED]
> `. `'[EMAIL PROTECTED]
>   `-  Debian GNU/Linux -- The power of freedom

Re: Sun Java available from non-free

[Steve Langasek]

On Mon, May 22, 2006 at 01:08:17AM +0200, Josselin Mouette wrote:
> Le dimanche 21 mai 2006 à 15:55 -0700, Steve Langasek a écrit :
> > If you have a reason to believe that the ftpmasters have *misjudged* the
> > liability involved,

> This is the whole point of the discussion.

Not that I can see.  Your preceding post focused on the *who* and the *how*
of the decision, *not* on the what.

> Indeed, they will bear the *primary* liability. However if legal action
> is taken against them or our mirror operators because of their decision,
> the whole distribution process might suffer, affecting all developers
> and users.

Er, of course we all might be affected by it, but the ftpmasters would be
affected *way* more by getting sued than *we* would be affected by their
getting sued, so I think it's ridiculously presumptuous to criticize the
ftpmasters for lack of transparency here instead of trying to support them
to make good decisions.

> By reading your email, I feel you are acknowledging the fact the
> ftp-masters cabal (I can't name it otherwise after seeing their behavior
> IRL) is treating other developers as second-class contributors who
> should just do as they say.

No, I'm acknowledging that the ftpmasters have no obligation to do as *you*
say.  The ftp-masters aren't the ones trying to tell other people what to do
in this thread.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Sun Java available from non-free

[Russ Allbery]

Adam Warner <[EMAIL PROTECTED]> writes:

> As Bill Allombert just pointed out, the Intention To Package process was
> clearly subverted:
> 

>Assuming no one else is already working on your prospective package,
>you must then submit a bug report (Bug reporting, Section 7.1)
>against the pseudo-package wnpp describing your plan to create a new
>package, including, but not limiting yourself to, a description of
>the package, the license of the prospective package, and the current
>URL where it can be downloaded from.

> That is, "you must" submit descriptions of the new packages, including
> their license(s).

Er, statements in the Developer's Reference are not Policy and are not a
requirement for Debian Developers.  The word "must" there does not mean
what it means in Policy.

It's an important document and certainly something that every developer
should read and endeavor to follow where it makes sense, but things go
into the Developer's Reference rather than Policy frequently precisely
*because* they don't make sense as global requirements and there are
reasons why one might not wish to follow them.

It is, in fact, quite common for no ITP to be filed when the people doing
the work believe that everyone involved already knows that it's going on
and the ITP would serve no useful coordination purpose.  For example, I
don't recall any ITPs filed for all the X.Org 7 packages, and I think
doing so would have been silly.

> When did we decide, as a community, to defend and indemnify Sun for the
> community's mistakes in packaging Sun's implementation of Java the
> language and platform?

Since Debian has no legal existence as an entity, we clearly didn't.
There is no legal "Debian" entity that could take on such an obligation
other than the SPI, and I think it's clear that the SPI didn't in this
case.  I'd say that the obvious interpretation would be that the
ftp-masters take on that responsibility individually.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Multiarch preparations needed for etch dpkg

[Goswin von Brederlow]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Sat, May 20, 2006 at 10:27:35PM +0200, Goswin von Brederlow wrote:
>> - Allow arch specific depends
>>   I propose to use "Depends: : (>= 1.2-3)" as syntax for
>>   thses. While for etch no package should use them dpkg should accept
>>   them so installing etch+1 debs can go without hitch.
>>   (Note that this also impacts on apt and aptitude)
>
> Please provide a counter-example to the following assertion:
>
>  A multiarch package's dependency on another package must be satisfied by a
>  package of a particular (i.e., of the same) architecture IFF the depended-on
>  package is also a multi-arch package.
>
> If you don't have any counter-examples to this claim, then it's my belief
> that the last of these changes is not required, because versioned
> dependencies are enough to ensure the dependency is not incorrectly
> satisfied by a non-multiarch version of the package, and Multi-Arch: yes
> flags on the new versions of the package give dpkg & front-ends enough
> information to correctly determine whether the dependency is properly
> satisfied and to resolve the dependency if not.

Say you have a binary package (Multi-Arch: no) firfox and a
library/plugin package firefox-mplayer-plugin.

This could be handled by firefox having a "Provides:
firefox-abiXX-arch-os-libc". Apt and perl for example already provide
an abi pseudopackage.


Another example would be build-essential:

Depends: libc6-dev | libc-dev, gcc (>= 3:3.3), g++ (>= 3:3.3), make, dpkg-dev 
(>= 1.4.1.19)

becomes

Depends: libc6-dev:arch | libc-dev:arch, gcc (>= 3:3.3), g++ (>= 3:3.3), make, 
dpkg-dev (>= 1.4.1.19), dpkg:arch

Again a provides could be used to achieve the same effect.

> I believe this removes the need for a backwards-incompatible syntax change
> to the Depends: field, which is an objection I had to the posted dpkg v2
> multiarch proposal as well.  (Note that without this change to Depends:
> syntax, any of these "multiarch" packages can be installed fine on the
> native architecture with the existing dpkg, but that with this syntax change
> users must first upgrade to a new set of packaging tools before these
> package relationships are parseable.)
>
> Thanks,
> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> [EMAIL PROTECTED]   http://www.debian.org/

The changes (to dpkg) required for the new depends syntax are rather
simple. The only non trivial change is in lib/fields.c in the actual
parser.

  * Add arch specific dependencies
+ lib/fields.c: Allow ':arch' in f_dependency()
+ lib/dpkg-db.h: struct deppossi: add const char *edname
+ lib/fields.c: f_dependency(): preserve deppossi->edname
+ src/processarc.c: process_archive(): copy deppossi->edname accross
+ Use edname instead of ed->name in:
  - lib/dump.c: w_dependency()
  - dselect/pkgsublist.cc
  - dselect/pkgdepcon.cc
  - src/archives.c
  - src/remove.c
  - src/depcon.c
  - src/processarc.c
  - src/packages.c

I think we should add the new syntax for future use instead of
requiring provides for this since provides can't be versioned and
therefore have to have the versioning inside the name. Actual use of
this feature could be delayed till etch+1 or etch+2 depending on how
much time we allow for updaters. But isn't the rule that you have to
update one release at a time and can't savely omit one? Users of
etch+1 would be expected to have an etch dpkg then.

MfG
Goswin


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

Re: Unidentified subject!

[Hex Star]

Hmmm...interesting...the other time someone posted something explicit and someone replied to it and pointed it out, everyone joined in and investigated it...this time the person who points it out gets criticized...go figure...I always get the short end of the stick...
On 5/21/06, Bas Zoetekouw <[EMAIL PROTECTED]> wrote:
Hi Hex!Wil you please, please refrain from replying to spam on the lists in thefuture?  Spam are easily filtered or deleted, replies on spam are not.Thanks.Bas.You wrote:>o_O...I wonder if these explicit messages, and these obviously have the
>intent of being explicit are going to cause the same rise as the last>explicit message sent to this list...a shame people send such nonsense to>these helpful and knowladgeable lists...*sigh*...
>>On 5/21/06, [EMAIL PROTECTED] <>[EMAIL PROTECTED]
> wrote:>>  I want to suck dick>>  -->>  Mobile Email from a Cingular Wireless Customer http://www.cingular.com>>  --
>  To UNSUBSCRIBE, email to [EMAIL PROTECTED]>  with a subject of "unsubscribe". Trouble? Contact>  
[EMAIL PROTECTED]--Kind regards,+--+| Bas Zoetekouw  | Sweet day, so cool, so calm, so bright, |
|| The bridall of the earth and skie:  || [EMAIL PROTECTED], [EMAIL PROTECTED] | The dew shall weep thy fall tonight;|
+|For thou must die.   | +-+Re: Hex Star 2006-05-22 <
[EMAIL PROTECTED]>
> o_O...I wonder if these explicit messages, and these obviously have the> intent of being explicit are going to cause the same rise as the last> explicit message sent to this list...a shame people send such nonsense to
> these helpful and knowladgeable lists...*sigh*...Replying to it (with a fullquote!) doesn't make things better,especially not the google rank in the list archive.
ChristophPS: Please set a real name when posting to Debian lists.--
[EMAIL PROTECTED] | http://www.df7cb.de/

Re: Sun Java available from non-free

[Adam Warner]

On Sun, 21 May 2006 20:20:09 -0700, Russ Allbery wrote:

> Adam Warner <[EMAIL PROTECTED]> writes:
> 
>> As Bill Allombert just pointed out, the Intention To Package process was
>> clearly subverted:
>> 
> 
>>Assuming no one else is already working on your prospective package,
>>you must then submit a bug report (Bug reporting, Section 7.1)
>>against the pseudo-package wnpp describing your plan to create a new
>>package, including, but not limiting yourself to, a description of
>>the package, the license of the prospective package, and the current
>>URL where it can be downloaded from.
> 
>> That is, "you must" submit descriptions of the new packages, including
>> their license(s).
> 
> Er, statements in the Developer's Reference are not Policy and are not a
> requirement for Debian Developers.  The word "must" there does not mean
> what it means in Policy.
> 
> It's an important document and certainly something that every developer
> should read and endeavor to follow where it makes sense, but things go
> into the Developer's Reference rather than Policy frequently precisely
> *because* they don't make sense as global requirements and there are
> reasons why one might not wish to follow them.

You're correct. So can you give reasonable and legitimate reasons why "one
might not wish to follow" the "you must" guidelines in this instance?

> It is, in fact, quite common for no ITP to be filed when the people doing
> the work believe that everyone involved already knows that it's going on
> and the ITP would serve no useful coordination purpose.

Yet in this case the ITP would have served an extremely useful
coordination purpose: letting interested parties participate. It would
only have served no useful purpose if the intent was to ensure the
packages went into non-free without dissent.

> For example, I don't recall any ITPs filed for all the X.Org 7 packages,
> and I think doing so would have been silly.

Because there was general consensus to move to x.org after *massive*
discussion on public mailing lists, including debian-legal. Also a
staggering amount of publicly accessible work was available while the
packages were being developed, all archived in debian-x.

>> When did we decide, as a community, to defend and indemnify Sun for the
>> community's mistakes in packaging Sun's implementation of Java the
>> language and platform?
> 
> Since Debian has no legal existence as an entity, we clearly didn't.
> There is no legal "Debian" entity that could take on such an obligation
> other than the SPI, and I think it's clear that the SPI didn't in this
> case. I'd say that the obvious interpretation would be that the
> ftp-masters take on that responsibility individually.

I'll tone down the rhetoric: Having FTP masters Anthony Towns (aka The
Debian Project Leader), James Troup and Ryan Murray personally liable to
defend and indemnify Sun for mistakes made in the Debian packaging and
distribution of Sun Java could adversely affect the wider Debian community.

Regards,
Adam


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

Re: Sun Java available from non-free

[Juergen A. Erhard]

On Sun, May 21, 2006 at 03:55:53PM -0700, Steve Langasek wrote:
> [...]  They didn't ask you because Debian is not a democracy and random
> opinions on this decision *don't* matter.

Wow, thanks for telling us.  I thought the Debian developers elected a DPL
every year.  Of course, since I'm not one, I got that wrong.

Bye, J


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

Re: Sun Java available from non-free

[Thomas Weber]

Am Sonntag, den 21.05.2006, 15:58 -0500 schrieb Raphael Hertzog:
> No, if we should discuss before taking any action we wouldn't get
> anything done. 
Oh, come on. Nobody expects you to ask before updating a simple package.


> If you really want to contest the decision, you have the
> GR.
ROFL, yes, that will give us a much higher productivity...; taking
decisions behind closed doors and then let people decide via a GR.


> Someone from Sun contacts you to examinate a new license for Java and ask
> you advice and all, and ask you to keep that info private. What do you
> respond to him ? "No sorry, we really don't care, go away"?
Discuss it with them; let them publish the license; announce your wish
to include it into Debian. If we assume that a discussion takes about
two weeks, that would have been the delay between the inclusion.


> There was no other choice, that's all. 
Sorry, that's not true, I've pointed out another choice above.


> And we would have lost an opportunity to do some PR stuff and show
> everyone that we're an important player in the Linux world.
How about is taking some time to include this stuff a lost opportunity?
Do you believe the announcement has a greater impact if it comes close
to Sun's announcement? Sorry, while this was really good for Sun, the
effect for Debian is probably negletable. 

By the way, did you actually check what kind of PR this generated?
Reading the german news sites (and Slashdot) [1,2], I fear that it
wasn't made clear that the packages go into non-free; I think people
will expect to find them in main.
Perhaps next time a real press release from Debian would be in order,
instead of letting Sun take the lead.


> The choice has already been made. Both sides have positive sides and
> negative ones. The choice has been made, no point in discussing it over
> again and again.
Raphael, if you keep pissing people of with this "we have decided, now
get back to working" attitude, you might find that your good PR might
backfire. Even a failed GR about this issue will generate more bad press
than the announcement created good one.


> I have to agree this sucks but if you have the schedule in mind it's easy
> to understand:
I point to my earlier posting about communication: I can't have a
schedule in mind if I didn't know there existed one in the first place.


> No, it would simply show that Sun is not committed to what they told us.
> We have been reasonable and accepted to work with them. If they change
> their mind, then it's Sun which is not reasonable.
If Debian publishes a press release saying "we remove this because of
Sun's actions", this will generate bad press for both Debian and Sun.
Even if it's worse for Sun, it's still something we should try to avoid.

[1] http://www.golem.de/0605/45369.html
[2] http://developers.slashdot.org/article.pl?sid=06/05/19/2044202


Thomas


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

Bug#368383: dumb "manual page for..." NAME section on many man pages

[Brendan O'Dea]

>dotlock (1)  - manual page for dotlock (GNU Mailutils 0.6.93)

This is the default NAME section generated by help2man.  Fairly useless,
but there needs to be *some* default.

Suggest that you file bugs on the particular packages which need either
to provide a --name="short description" argument, or a the "[name]"
block in an --include file (see coreutils/man/*.x for examples of the
latter usage).

--bod


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