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

[Martijn van Oosterhout]

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

The software as distributed is complete, it has all the files in the
.deb packages, and the dependencies ensure that on the user's system the
software layout is like Sun requires, with the optional bits indeed
being optional.

[snip]

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, ...

[snip]

The license says "distribute [...] to run in conjunction with". We do
distribute eclipse, kaffe, gcj, and various others tools and
applications, but not "to run in conjunction" with the Sun Java. Our own
policy even prevents us from doing so unless we move the aforementioned
stuff to contrib.

[snip]

Sun wants that every legal entity using the software agrees
to its license, but doesn't want to, and doesn't require, the license to
be explicitely affirmed manually on each computer.

[snip]

I think at the very least we can say the licence is terribly worded.
The word "with" has at least 27 meanings, the word "software" is not
adequately defined. Conjunction also has several possible meanings.
Thing like estoppel don't apply the same way everywhere, so you can't
rely on things like that.

Maybe someone should come back with a "More Carefully Worded New Sun
Java Licence"
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

Re: RFC: Better portability for package maintainers

[Petter Reinholdtsen]

[Erast Benson]
> And thanks to upstream folks, 90% of OSS software is platform
> independent and just works.

Just to get the facts straight here.  I compile and port free software
regularly to Linux, Solaris, Irix, HP-UX, Tru64 Unix, AIX and MacOSX,
and do not share your view that 90% of "OSS software" (what is that?
Lets call it free software for now), is platform independent.  I
regularly run into build problems on all of these, because most free
software is never before compiled with an ANSI C compiler (only GCC,
which have a number of "extentions" not supported by ANSI C), and need
rewrites to compile on Irix, HP-UX and AIX, which happen to have good
and strict ANSI C compilers.  And there are heaps of endian problems
(triggering on big-endian and alignment problems (triggering on hppa
and sometimes sparc) too.  Luckily, GCC is getting closer and closer
to ANSI C these days, so perhaps some time in the near future, the
code developed by free software developers will be platform
independent. :)

So I would say less than 20% of the free software is platform
independent, based on personal problems.

On the positive side, most of the upstream developers believe platform
independence and standard compliance is a good thing, so patches are
almost always accepted when submitted. :)

Friendly,
-- 
Petter Reinholdtsen


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

Re: Sun Java available from non-free

[David A.]

I would like to thank all debian-guys for getting Sun Java into the
normal debian repository. I appriciate your effort, and I believe there
are many out there that think this is great!

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?

Anyhow, I yust want to lighten the tone of this thread, and thank you
all. Thanks for makeing Debian good. Thanks for getting Sun Java in.
Thanks for keeping an eye at license-stuff etc.

regards, David.


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

Re: RFC: Better portability for package maintainers

[Hendrik Sattler]

Am Samstag, 20. Mai 2006 12:01 schrieb Petter Reinholdtsen:
> [Erast Benson]
>
> > And thanks to upstream folks, 90% of OSS software is platform
> > independent and just works.
>
> Just to get the facts straight here.  I compile and port free software
> regularly to Linux, Solaris, Irix, HP-UX, Tru64 Unix, AIX and MacOSX,
> and do not share your view that 90% of "OSS software" (what is that?
> Lets call it free software for now), is platform independent.  I
> regularly run into build problems on all of these, because most free
> software is never before compiled with an ANSI C compiler (only GCC,
> which have a number of "extentions" not supported by ANSI C), and need
> rewrites to compile on Irix, HP-UX and AIX, which happen to have good
> and strict ANSI C compilers.  And there are heaps of endian problems
> (triggering on big-endian and alignment problems (triggering on hppa
> and sometimes sparc) too.  Luckily, GCC is getting closer and closer
> to ANSI C these days, so perhaps some time in the near future, the
> code developed by free software developers will be platform
> independent. :)

I'd never program for pure ANSI C. We are living in 2006 and can make use of 
ISO C99. If commercial and professional systems don't catch up in seven years 
but free software does, I don't care for such systems.
Authors of free software might take the freedom to use current standards.

Sure, using gcc-specific stuff sucks and is rarely intentional.

> So I would say less than 20% of the free software is platform
> independent, based on personal problems.

And the other authors cannot test on such system anyway as they often need 
specific hardware or the OS/compiler cannot be tested without extra costs.
Often, ports to such systems are done without feedback to the original author.

HS


pgppte1usq36d.pgp
Description: PGP signature

Re: Delivery failed

[gboyd]

From: [EMAIL PROTECTED]
Subject: Vacation Message

I'll be on a bicycle tour until May 9, 2004.

Any real messages, please contact my wife by phone.



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

debdelta , Re: effectiveness of rsync and apt

[A Mennucc1]

hi

I recollected my earlier experiments on computing package diffs, and
prepared a package called 'debdelta'. It is available at
   http://tonelli.sns.it/pub/mennucc1/debdelta and also uploaded into
experimental.

This package contains both a command 'debdelta', to compute deltas of
Debian packages, and a command 'debpatch', to apply them.

Given the old file.deb (*) and the correct file.debdelta ,
'debpatch' builds the new deb; the new deb is identical to the
original new deb.

Here are some results

debdelta emacs-snapshot-common_1%3a20060512-1_all.deb  
emacs-snapshot-common_1%3a20060518-1_all.deb /tmp/e.debdelta
 deb delta is  12.1 % of deb
 that is, 15528kB would be saved

debdelta  nautilus-data_2.14.1-2_all.deb  nautilus-data_2.14.1-3_all.deb  
/tmp/n.deb
 deb delta is  4.5 % of deb
 that is, 3261kB would be saved

debdelta emacs-snapshot-gtk_1%3a20060512-1_i386.deb 
emacs-snapshot-gtk_1%3a20060518-1_i386.deb /tmp/eg.deb
 deb delta is  69.8 % of deb
 that is, 603kB would be saved

debdelta openssh-client_1%3a4.3p2-1_i386.deb 
openssh-client_1%3a4.3p2-2_i386.deb /tmp/o.deb
 deb delta is  4.6 % of deb
 that is, 549kB would be saved

This is a security upgrade:

 debdelta mozilla-browser_1.7.8-1sarge3_i386.deb  
mozilla-browser_1.7.8-1sarge6_i386.deb  /tmp/m.debdelta
 deb delta is  16.3 % of deb
 that is, 8447kB would be saved

Note that it works also on different debs:

debdelta kernel-image-2.6.8-2-k7_2.6.8-16sarge1_i386.deb 
kernel-image-2.6.8-i386/kernel-image-2.6.8-3-k7-smp_2.6.8-16sarge2_i386.deb 
/tmp/ks.debdelta
 deb delta is  53.8 % of deb
 that is, 6819kB would be saved

debdelta kernel-image-2.6.8-2-686_2.6.8-16sarge1_i386.deb 
kernel-image-2.6.8-2-686-smp_2.6.8-16sarge1_i386.deb /tmp/k.debdelta
 deb delta is  52.3 % of deb
 that is, 7141kB would be saved


As you see, results are good.

The best way to use it would be to keep in repository only small
deltas; otherwise, the benefit of saving some download time would not
outweight the cost of using 'debpatch' (that can take a lot of time on
large debs; for example, the last example on kernel takes 30sec on a
Athlon64 3000).

TODO:
- apt support : implement a http-delta method .
- change 'debmirror' so that it invokes 'debdelta' before deleting a
  old file.

Anyone want to help ?

Other work in progress:
- (*) I am working on 'deltas' that may be applied even when the
  original  .deb is not around, but is installed in the host.
- support for data.tar.bz2 is half done. Are there any .debs around
  that use it?
- Try different schemes for computing deltas.
- Study how tar works, or use jigdo.
- recursive deltas... to compute deltas of files that are inside data.tar.gz 
 This would be fantastic for kernel sources

a.

---

A Mennucc <[EMAIL PROTECTED]> writes:

> Brian Eaton wrote:
>> Hello all -
>> 
>> Regarding the ideas discussed here:
>> 
>> http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html
>> 
>> Has anyone ever done some log file analysis to figure out how much
>> bandwidth would be saved by transferring package deltas instead of
>> entire new packages?
>> 


pgpMXdQuvlIyr.pgp
Description: PGP signature

Re: RFC: Better portability for package maintainers

[Josselin Mouette]

Le vendredi 19 mai 2006 à 13:15 -0700, Alex Ross a écrit :
> Ideally though, there'd be an augmented policy of package acceptance,
> reflecting the fact that the packages with "Architecture: any" should build
> and run on one of the Debian POSIX-compliant systems. NexentaOS is
> certainly one such system. To help implement this new policy we could "plug"
> our AutoBuilder [1] into the existing build environment.

Please wake up. Debian is a GNU system and needs a GNU environment. I
doubt that more than half of the archive can build without the GNU libc.
This is the reason why the FreeBSD port started by porting the glibc.
-- 
 .''`.   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: RFC: Better portability for package maintainers

[Russ Allbery]

Hendrik Sattler <[EMAIL PROTECTED]> writes:
> Am Samstag, 20. Mai 2006 12:01 schrieb Petter Reinholdtsen:

>> So I would say less than 20% of the free software is platform
>> independent, based on personal problems.

> And the other authors cannot test on such system anyway as they often
> need specific hardware or the OS/compiler cannot be tested without extra
> costs.  Often, ports to such systems are done without feedback to the
> original author.

Yes.  There is no (non-trivial) portable software, only software that has
been ported.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Bug#368204: ITP: unpaper -- post-processing tool for scanned pages

[Julien BLACHE]

Package: wnpp
Severity: wishlist
Owner: Julien BLACHE <[EMAIL PROTECTED]>


* Package name: unpaper
  Version : 0.2
  Upstream Author : Jens Gulden <[EMAIL PROTECTED]>
* URL : http://unpaper.berlios.de
* License : GPL
  Programming Lang: C
  Description : post-processing tool for scanned pages

Description: post-processing tool for scanned pages
 unpaper is a post-processing tool for scanned sheets of paper,
 especially for book pages that have been scanned from previously
 created photocopies.
 .
 The main purpose is to make scanned book pages better readable on
 screen after conversion to PDF. Additionally, unpaper might be useful
 to enhance the quality of scanned pages before performing optical
 character recognition (OCR).

JB.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
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 12:01 +0200, Petter Reinholdtsen wrote:
> [Erast Benson]
> > And thanks to upstream folks, 90% of OSS software is platform
> > independent and just works.
> 
> Just to get the facts straight here.  I compile and port free software
> regularly to Linux, Solaris, Irix, HP-UX, Tru64 Unix, AIX and MacOSX,
> and do not share your view that 90% of "OSS software" (what is that?
> Lets call it free software for now), is platform independent.  I
> regularly run into build problems on all of these, because most free
> software is never before compiled with an ANSI C compiler (only GCC,
> which have a number of "extentions" not supported by ANSI C), and need
> rewrites to compile on Irix, HP-UX and AIX, which happen to have good
> and strict ANSI C compilers.  And there are heaps of endian problems
> (triggering on big-endian and alignment problems (triggering on hppa
> and sometimes sparc) too.  Luckily, GCC is getting closer and closer
> to ANSI C these days, so perhaps some time in the near future, the
> code developed by free software developers will be platform
> independent. :)

I don't want to argue about the numbers. Nobody can say for sure, but
from my "7000+ packages Solaris port" (yes we have 7000+ packages in
Nexenta APT repo now) experience, I could say software already ported in
most cases and upstream tarballs just works. The same true for FreeBSD.
Other OSes will catch over time too up to (once they open sourced).

> So I would say less than 20% of the free software is platform
> independent, based on personal problems.

Lets do not count non open sourced OSes for now.

> On the positive side, most of the upstream developers believe platform
> independence and standard compliance is a good thing, so patches are
> almost always accepted when submitted. :)

Sure. When bug is found in upstream, FreeBSD, OpenSolaris or Darwin
developers sends patches this way. But I think packaging bugs needs to
be handled by their maintainers or at least effort needs to be
coordinated somehow.

-- 
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 Sat, 2006-05-20 at 07:38 -0700, Russ Allbery wrote:
> Hendrik Sattler <[EMAIL PROTECTED]> writes:
> > Am Samstag, 20. Mai 2006 12:01 schrieb Petter Reinholdtsen:
> 
> >> So I would say less than 20% of the free software is platform
> >> independent, based on personal problems.
> 
> > And the other authors cannot test on such system anyway as they often
> > need specific hardware or the OS/compiler cannot be tested without extra
> > costs.  Often, ports to such systems are done without feedback to the
> > original author.
> 
> Yes.  There is no (non-trivial) portable software, only software that has
> been ported.

yes. been ported or possible to port with minimal efforts.

-- 
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 Sat, 2006-05-20 at 16:33 +0200, Josselin Mouette wrote:
> Le vendredi 19 mai 2006 à 13:15 -0700, Alex Ross a écrit :
> > Ideally though, there'd be an augmented policy of package acceptance,
> > reflecting the fact that the packages with "Architecture: any" should build
> > and run on one of the Debian POSIX-compliant systems. NexentaOS is
> > certainly one such system. To help implement this new policy we could "plug"
> > our AutoBuilder [1] into the existing build environment.
> 
> Please wake up. Debian is a GNU system and needs a GNU environment. I
> doubt that more than half of the archive can build without the GNU libc.
> This is the reason why the FreeBSD port started by porting the glibc.

Let me just give you an freebsd example:

"""The FreeBSD Ports and Packages Collection offers a simple way for
users and administrators to install applications. There are currently
14682 ports available."""

14000+ (source ports) is quite a number and far bigger than the half of
Debian APT repo.

Flink is a good Darwin example and actively growing too.

Nexenta is a good candidate of OpenSolaris ports. Besides it uses GNU
userland (instead of SUN userland), this simplifies porting efforts too.

-- 
Erast


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

Re: RFC: Better portability for package maintainers

[Gustavo Noronha Silva]

Em Sex, 2006-05-19 às 17:52 -0700, Erast Benson escreveu:
> is platform independent and just works. And if Debian's meta-information
> introduces problem for package which compiles and runs just fine from
> out of upstream tarball on non-glibc ports than maintainer might be
> interested to fix it, otherwise "Architecture: any" doesn't make much
> sense in its debian/control file.

Our Architecture: field is about the arches that Debian itself supports.
If the meaning was broad as you describe, would we have to make sure our
packages build on MS DOS?

I'll agree with Josselin here: Debian is a GNU operatig system, not a
POSIX OS. If there are porting problems which are specific to Nexenta
and you want them to be integrated, you can provide patches. Or you can
port the GNU libc to Nexenta (and, after this happens, you can even
integrate Nexenta into Debian, why not?).

I do care about Free Software principles, but my time for working on
Debian is very limited these days, and porting my packages to an
"unsupported" architecture is not very high in my priorities list.

See you,

-- 
Gustavo Noronha Silva <[EMAIL PROTECTED]>
http://people.debian.org/~kov/


signature.asc
Description: Esta é uma parte de mensagem	assinada digitalmente

Re: RFC: Better portability for package maintainers

[Gustavo Noronha Silva]

Em Sáb, 2006-05-20 às 08:07 -0700, Erast Benson escreveu:
> 14000+ (source ports) is quite a number and far bigger than the half of
> Debian APT repo.

Many of them are probably patched in the build process. I know that one
of my packages do get many patches on netbsd's pkgsrc, for instance,
although it apparently built without a problem in Nexenta. Go figure.

See you,

-- 
Gustavo Noronha Silva <[EMAIL PROTECTED]>
http://people.debian.org/~kov/


signature.asc
Description: Esta é uma parte de mensagem	assinada digitalmente

Re: alternatives and priorities

[Luca Capello]

Hello!

On Fri, 19 May 2006 08:46:28 -0500, Wouter Verhelst wrote:
> On Fri, May 19, 2006 at 02:28:30PM +0100, Jon Dowland wrote:
>> At 1148052328 past the epoch, Wouter Verhelst wrote:
>> >  Using popcon would ensure that the applications which most
>> >  people prefer would be the default; this is a fair and objective
>> >  criterion.
>> > 
>> > Thoughts?
>> 
>> Interesting idea, but by my reckoning that would make "ed" the
>> default editor for most people, which I don't think is a good idea:
>>  
>
> That's not an issue. First, ed doesn't install an alternatives for
> "editor". Second, there's also 'by_vote', which puts vim on top.

ed is installed as an alternative "editor":
=
[EMAIL PROTECTED]:~$ su
Password:
gismo:/home/luca# update-alternatives --list editor
/bin/ed
/usr/bin/emacs21
/usr/bin/mcedit-debian
/usr/bin/emacs-snapshot
/usr/bin/vim.tiny
gismo:/home/luca#
=

And the postinst script says so, too:
=
[EMAIL PROTECTED]:~$ grep alternatives /var/lib/dpkg/info/ed.postinst
 update-alternatives --quiet --install /usr/bin/editor editor /bin/ed -100 \
[EMAIL PROTECTED]:~$
=

Thx, bye,
Gismo / Luca


pgpfsxFY6kze9.pgp
Description: PGP signature

Re: RFC: Better portability for package maintainers

[Josselin Mouette]

Le samedi 20 mai 2006 à 08:07 -0700, Erast Benson a écrit :
> > Please wake up. Debian is a GNU system and needs a GNU environment. I
> > doubt that more than half of the archive can build without the GNU libc.
> > This is the reason why the FreeBSD port started by porting the glibc.
> 
> Let me just give you an freebsd example:
> 
> """The FreeBSD Ports and Packages Collection offers a simple way for
> users and administrators to install applications. There are currently
> 14682 ports available."""
> 
> 14000+ (source ports) is quite a number and far bigger than the half of
> Debian APT repo.

I'm talking about porting the Debian packages as they are.

> Flink is a good Darwin example and actively growing too.

If you compare the time Fink needed to attain 158 hundred packages and
the time kFreeBSD needed to build 78% of the Debian archive, you will
understand that without the GNU libc the amount of work is not even
comparable.

> Nexenta is a good candidate of OpenSolaris ports. Besides it uses GNU
> userland (instead of SUN userland), this simplifies porting efforts too.

AFAIK Nexenta doesn't use the GNU libc, which is the basis of what is
called a GNU userland.

On a totally different matter, if the non-free packages required to run
OpenSolaris are still part of your base installation, I doubt that many
developers will be interested in helping you developing on your OS.
(This, added to the disagreement with Sun on the GPLv2 interpretation.)
-- 
 .''`.   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: RFC: Better portability for package maintainers

[Erast Benson]

On Sat, 2006-05-20 at 12:37 -0300, Gustavo Noronha Silva wrote:
> Em Sex, 2006-05-19 às 17:52 -0700, Erast Benson escreveu:
> > is platform independent and just works. And if Debian's meta-information
> > introduces problem for package which compiles and runs just fine from
> > out of upstream tarball on non-glibc ports than maintainer might be
> > interested to fix it, otherwise "Architecture: any" doesn't make much
> > sense in its debian/control file.
> 
> Our Architecture: field is about the arches that Debian itself supports.
> If the meaning was broad as you describe, would we have to make sure our
> packages build on MS DOS?

Sure not. :-)
I was talking about existing Debian architectures which are part of
official dpkg ostable:

linux   linux-gnu   linux[^-]*(-gnu.*)?
darwin  darwin  darwin[^-]*
freebsd freebsd freebsd[^-]*
kfreebsdkfreebsd-gnukfreebsd[^-]*(-gnu.*)?
knetbsd knetbsd-gnu knetbsd[^-]*(-gnu.*)?
netbsd  netbsd  netbsd[^-]*
openbsd openbsd openbsd[^-]*
hurdgnu gnu[^-]*

+

solaris pc-solaris2 solaris.*


> I'll agree with Josselin here: Debian is a GNU operatig system, not a
> POSIX OS. If there are porting problems which are specific to Nexenta
> and you want them to be integrated, you can provide patches. Or you can
> port the GNU libc to Nexenta (and, after this happens, you can even
> integrate Nexenta into Debian, why not?).

Is that a requirement for Debian port (i.e. marked as "supported")? It
is not correlates with what officials were saying in regards of
non-glibc ports half a year ago. Could someone elaborate?

> I do care about Free Software principles, but my time for working on
> Debian is very limited these days, and porting my packages to an
> "unsupported" architecture is not very high in my priorities list.

"supported" and "existing"(unsupported) architectures are still Debian
architectures. But I see your point.

-- 
Erast


-- 
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 samedi 20 mai 2006 à 04:17 -0700, David A. a écrit : 
> I would like to thank all debian-guys for getting Sun Java into the
> normal debian repository. I appriciate your effort, and I believe there
> are many out there that think this is great!

This is surely good news, but there are many people here who are very
disappointed with the lack of transparency.

> 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?

There are forces that are worried with the legal risks the project faces
by distributing this software. I don't think anybody of those supporting
the non-free archive is opposing the idea of having the Sun JVM in 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

Bug#368221: ITP: glbsp -- nodes builder for Doom engine level files (has GL support)

[Darren Salt]

Package: wnpp
Severity: wishlist

* Package name: glbsp
  Version : 2.20
  Upstream Author : Andrew Apted <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/glbsp/
* License : GPL 2.0 or later
  Description : nodes builder for Doom-style games; has support for OpenGL

 glBSP is a node builder specially designed to be used with OpenGL ports of
 the DOOM game engine. It adheres to the "GL-Friendly Nodes" specification,
 which means it adds some new special nodes to a WAD file that makes it very
 easy (and fast!) for an OpenGL DOOM engine to compute the polygons needed
 for drawing the levels.
 .
 There are many DOOM ports that understand the GL Nodes which glBSP creates,
 including EDGE, the Doomsday engine (JDOOM), Doom3D, PrBoom, and Vavoom.


The source package provides three binary packages: glbsp, libglbsp2 and
libglbsp-dev.

http://www.youmustbejoking.demon.co.uk/progs.sid.html>

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Output less CO2 => avoid massive flooding.TIME IS RUNNING OUT *FAST*.

You might have mail.


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

Re: RFC: Better portability for package maintainers

[Michael Banck]

On Sat, May 20, 2006 at 08:43:25AM -0700, Erast Benson wrote:
> > I'll agree with Josselin here: Debian is a GNU operatig system, not a
> > POSIX OS. If there are porting problems which are specific to Nexenta
> > and you want them to be integrated, you can provide patches. Or you can
> > port the GNU libc to Nexenta (and, after this happens, you can even
> > integrate Nexenta into Debian, why not?).
> 
> Is that a requirement for Debian port (i.e. marked as "supported")? It
> is not correlates with what officials were saying in regards of
> non-glibc ports half a year ago. Could someone elaborate?

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).


Michael

-- 
 I did send an email to propose multithreading to
grub-devel on the first of april.
 Unfortunately everyone thought I was serious ;-)


-- 
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 17:54 +0200, Josselin Mouette wrote:
> Le samedi 20 mai 2006 à 08:07 -0700, Erast Benson a écrit :
> > > Please wake up. Debian is a GNU system and needs a GNU environment. I
> > > doubt that more than half of the archive can build without the GNU libc.
> > > This is the reason why the FreeBSD port started by porting the glibc.
> > 
> > Let me just give you an freebsd example:
> > 
> > """The FreeBSD Ports and Packages Collection offers a simple way for
> > users and administrators to install applications. There are currently
> > 14682 ports available."""
> > 
> > 14000+ (source ports) is quite a number and far bigger than the half of
> > Debian APT repo.
> 
> I'm talking about porting the Debian packages as they are.
> 
> > Flink is a good Darwin example and actively growing too.
> 
> If you compare the time Fink needed to attain 158 hundred packages and
> the time kFreeBSD needed to build 78% of the Debian archive, you will
> understand that without the GNU libc the amount of work is not even
> comparable.

Recent Nexenta progress proves that packages (meta information) could be
ported in much faster rates. It is all depends on different factors...

My personal opinion is that kernel and libc must not be split out.
Especially this is true for OpenSolaris world where kernel provides a
lot of extensions which are in heavy use by SUN C and others SUN core
libraries. Besides, we are aiming to provide 100% native OpenSolaris
compatibility which is very beneficial in the long run.

> > Nexenta is a good candidate of OpenSolaris ports. Besides it uses GNU
> > userland (instead of SUN userland), this simplifies porting efforts too.
> 
> AFAIK Nexenta doesn't use the GNU libc, which is the basis of what is
> called a GNU userland.

It is part of it. But as long as glibc extensions available separately,
we are OK. GNU userland is far more than just glibc. Besides, SUN C
library perfectly implements all we need to run a majority of existing
ported apps.

-- 
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 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?

-- 
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 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?

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


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

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

[Josh Triplett]

Jeroen van Wolffelaar wrote:
> On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong 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.

Does that imply, though, that one cannot mirror non-free separately from
Debian, or put it on a separate CD which one can purchase or distribute
separately?  For example, such a clause would prevent Debian from
distributing non-free on a separate server, as proposed a while back.

>>> (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;
>> This means that we can't distribute eclispse or anything else which
>> implements part of the Java API (or if you're going to read this
>> clause as broadly as possible,[1] things like perl which implement
>> similar functionality in that perl is an implementation of a cross
>> platform language Perl.)
> 
> The license says "distribute [...] to run in conjunction with". We do
> distribute eclipse, kaffe, gcj, and various others tools and
> applications, but not "to run in conjunction" with the Sun Java.

As I mentioned elsewhere in this thread, the alternatives system means
that any Java library in Debian could fall under "configure [...] to run
in conjunction with".  Thus, what about software like SWT, which
provides "similar functionality", or SwingWT, which provides the Swing
API on top of SWT?  Does this clause prevent us from shipping those?

> What this clause seeks to prevent is using Sun's JVM with the Classpath
> java library, or to use the Java library code together with Kaffe.

So, for example, Debian would need to stop shipping the jikes-sun
package  which uses the Jikes
compiler to compile against the Sun Java library?

>>> 4. COMPATIBILITY. If you exercise the license in Section 2, and Sun
>>> or a licensee of the Software (under section 4(b)) notifies you
>>> that there are compatibility issues [...] caused by the
>>> interaction of the Software with your Operating System, then
>>> within ninety (90) days you must either: (a) modify the
>>> Operating System in a way that resolves the compatibility issue
>>> (as determined by Sun) and make a patch or replacement version
>>> available [...]
>> Oh, right... so if the Sun JDK is buggy, we have to modify our
>> operating system to make it unbuggy in some way that makes Sun happy.
>> Makes sense to me.
> 
> Or option (b), remove the Sun packages. If we were to face this
> situation, there's always this option if there isn't a better one.

And if a problem comes up with the Sun Java package shipped in stable,
or oldstable?

> 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.

I agree.  However, that doesn't prevent them from doing it, once.

- Josh Triplett




signature.asc
Description: OpenPGP digital signature

Re: RFC: Better portability for package maintainers

[Roger Leigh]

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.


Regards,
Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


pgptOJO1gUca3.pgp
Description: PGP signature

Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)

[Bill Allombert]

On Fri, May 19, 2006 at 02:44:14PM +0200, Turbo Fredriksson wrote:
> Quoting Stephen Frost <[EMAIL PROTECTED]>:
> 
> > * Turbo Fredriksson ([EMAIL PROTECTED]) wrote:
> >> But regarding the build system, I REALLY object to any major changes! 
> >> Fixes yes,
> >> but not REPLACEMENT!!
> >
> > Uhh, or, not...  Sorry, but the build system was terrible and is
> > certainly something which should not be encouraged.
> 
> Rubish! There is nothing (major) wrong with it as it is now. Yes, hardcoding
> isn't good, but neither is 'an-hour-build'. Which you'd get if you do three
> full builds after each other...

I suggest you look at ccache. This will take care of avoiding spurious
recompilation without changing the build system.

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]

ITP: elfutils

[Kurt Roeckx]

Package: wnpp
Severity: wishlist

* Package name : elfutils
* Version : 0.120
* Upstream Author : redhat (Ulrich Drepper <[EMAIL PROTECTED]>)
* URL :ftp://sources.redhat.com/pub/systemtap/elfutils/
* License : GPL
Description : A collection of utilities and DSOs to handle compiled
objects.
Elfutils is a collection of utilities, including ld (a linker),
nm (for listing symbols from object files), size (for listing the
section sizes of an object or archive file), strip (for discarding
symbols), readelf (to see the raw ELF file structures), and elflint
(to check for well-formed ELF files).  Also included are numerous
helper libraries which implement DWARF, ELF, and machine-specific ELF
handling.


>From the changelog:
- The license is now GPL for most files.  The libelf, libebl, libdw,and
libdwfl libraries have additional exceptions.  Add reference toOIN.

(This allow to link with any open source license approved by OSI)

It contains other libraries which have something simular in Debian
already.

libelf (with binary package libelfg0) seems to do exactly the same, so
maybe we should look at only providing one of them.  I have no idea why
it has the g in it's name though.

libdw seems to be simular to libdwarf, but differ alot.



Kurt



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

Re: RFC: Better portability for package maintainers

[Adam Borowski]

On Sat, May 20, 2006 at 12:37:36PM -0300, Gustavo Noronha Silva wrote:
> Our Architecture: field is about the arches that Debian itself supports.
> If the meaning was broad as you describe, would we have to make sure our
> packages build on MS DOS?
> 
> I'll agree with Josselin here: Debian is a GNU operating system, not a
> POSIX OS. If there are porting problems which are specific to Nexenta
> and you want them to be integrated, you can provide patches. Or you can
> port the GNU libc to Nexenta (and, after this happens, you can even
> integrate Nexenta into Debian, why not?).

Still, I would say that Erast has a good point.  The problem is, there
are three different sides:
* Sun
They want people to support their platform.
* upstreams
They just *love* having their software ported everywhere.  And I mean:
* purely commercial upstreams (more customers!)
* purely noncommercial ones (free ego boost)
* anything in-between (bigger user base, more potential patches, etc)
With Nexenta being more similar to Solaris, the ported software will
be more likely to work there as well, giving it more coverage.
* Debian
Easy porting, and keeping porting that way in the future.  Supporting
wildly diverse libcs stands against this goal.

Note that the first two groups would prefer a new project which is not
very likely to have a lot of users soon to use the Sun libc.
Sun: for obvious reasons.
Upstreams: free porting to near-Solaris, hardly any users lost due to
harder porting.

On the other hand, Debian obviously would prefer to have Nexenta be
close -- preferably as an arch.  Without GNU libc, Nexenta can't really
be a part of Debian.

> I do care about Free Software principles, but my time for working on
> Debian is very limited these days, and porting my packages to an
> "unsupported" architecture is not very high in my priorities list.

In other words, Nexenta can choose between:
* GNU libc: easy porting of nearly all of Debian's repository, more
  cooperation from Debian developers
* Sun libc: better interoperability with Solaris

GNU libc would give Nexenta lots of usability fast, Sun libc would make
it a more experimental bridge to Solaris.

I don't really love Sun -- but, if we can give them a reason to relicense
their stuff to something GPL-compatible, it would be a big win.  Without
compatibility with GPL, we'll have more and more wars and crap similar to
the recent Java issue.

Cheers and schtuff,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//Never attribute to stupidity what can be
//adequately explained by malice.


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

Multiarch preparations needed for etch dpkg

[Goswin von Brederlow]

Matt Taggart and others <[EMAIL PROTECTED]> writes:

> Hi debian-dpkg,
>
> 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)

The wiki has more details on each of the 3 steps.

I'm preparing patches for this but I would like to hear any comments,
specificaly on the syntax to be used, before I submit any. No point
in submitting a patch if the syntax then has to be changed.

If those 3 changes are accepted into dpkg for etch then there should
be no special steps needed in etch+1 to convert a system from uni-arch
to multi-arch. A simple dpkg upgrade should do the trick.

MfG
Goswin


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

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

[Ron Johnson]

--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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.
> 
[snip]
> 
> 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.

If you aren't getting Solaris-specific features (dtrace, etc ?),
then what's the point of running Solaris?

(Please don't think this a flame, it's a sincere question.)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEb7YNS9HxQb37XmcRAnZSAJ9lvT+eRUeI1h49XKB4h01O20oGvgCg7mt4
muS1l9raaQ8ZU9LxIcEeyNA=
=zANb
-END PGP SIGNATURE-


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

--- End Message ---


signature.asc
Description: OpenPGP digital signature

Re: ITP: elfutils

[Daniel Jacobowitz]

On Sat, May 20, 2006 at 10:12:24PM +0200, Kurt Roeckx wrote:
> - The license is now GPL for most files.  The libelf, libebl, libdw,and
> libdwfl libraries have additional exceptions.  Add reference toOIN.
> 
> (This allow to link with any open source license approved by OSI)
> 
> It contains other libraries which have something simular in Debian
> already.
> 
> libelf (with binary package libelfg0) seems to do exactly the same, so
> maybe we should look at only providing one of them.  I have no idea why
> it has the g in it's name though.

They are roughly ABI compatible, but they are neither license
compatible (you can link libelfg0 with whatever you please) nor
completely quirk compatible (I've reported bugs in using the elfutils
version to modify files where it would corrupt output, I have no idea
if they've been fixed).

-- 
Daniel Jacobowitz
CodeSourcery


-- 
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 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.

Now, I really think Fink was a good idea to begin with and sure Nexenta
following the same idea and in many ways extends it. i.e. Fink capable
to run Debian packaged OSS stack on existing Darwin core, while they
need to trade off some design issues. Meanwhile Nexenta is the OS from
ground to up, which helps us to make/design a lot of things in cleaner
way and form. The fact that in Nexenta OSS porting efforts are minimized
is not a coincidence...

-- 
Erast


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

Bug#368266: ITP: stardict-xmlittre -- Littré dictionary for Stardict

[Itay Ben-Yaacov]

Package: wnpp
Severity: wishlist
Owner: "Itay Ben-Yaacov" <[EMAIL PROTECTED]>


* Package name: stardict-xmlittre
  Version : 2.4.2
  Upstream Author : François Gannaz <[EMAIL PROTECTED]>
* URL : http://francois.gannaz.free.fr/Littre/horsligne.php
* License : GPL
  Programming Lang: None.
  Description : Littré dictionary for Stardict

(Include the long description here.)

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

Re: Packages violating policy 8.2

[Thomas Bushnell BSG]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Hi,
>
> Debian policy says:
>
> | 8.2 Run-time support programs
> | 
> | If your package has some run-time support programs which use the
> | shared library you must not put them in the shared library
> | package. If you do that then you won't be able to install several
> | versions of the shared library without getting filename clashes.
> | 
> | Instead, either create another package for the runtime binaries
> | (this package might typically be named libraryname-runtime; note the
> | absence of the soversion in the package name), or if the development
> | package is small, include them in there.
>
> After seeing several packages that violate 8.2 I set out to find out
> how common that is:

What about runtime support programs whose purpose is to print
information for use in autoconf tests belonging to other programs
which want to use the library?


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

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

[Steve Langasek]

On Sat, May 20, 2006 at 02:18:57PM -0700, Josh Triplett wrote:
> > 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.

> Does that imply, though, that one cannot mirror non-free separately from
> Debian, or put it on a separate CD which one can purchase or distribute
> separately?  For example, such a clause would prevent Debian from
> distributing non-free on a separate server, as proposed a while back.

It may imply this, but this is not a barrier to Debian's inclusion of the
packages under the current non-free regime.

The only real requirement for a package's inclusion in non-free is: "can we
distribute it?"  We don't make any guarantees that other people can also
distribute it outside of a Debian mirror, or on CDs, or anything else.
There have definitely been non-free packages in the past that could *not* be
distributed separately from the Debian mirrors or that could not be
distributed on CDs.

-- 
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: Packages violating policy 8.2

[Goswin von Brederlow]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> Hi,
>>
>> Debian policy says:
>>
>> | 8.2 Run-time support programs
>> | 
>> | If your package has some run-time support programs which use the
>> | shared library you must not put them in the shared library
>> | package. If you do that then you won't be able to install several
>> | versions of the shared library without getting filename clashes.
>> | 
>> | Instead, either create another package for the runtime binaries
>> | (this package might typically be named libraryname-runtime; note the
>> | absence of the soversion in the package name), or if the development
>> | package is small, include them in there.
>>
>> After seeing several packages that violate 8.2 I set out to find out
>> how common that is:
>
> What about runtime support programs whose purpose is to print
> information for use in autoconf tests belonging to other programs
> which want to use the library?

I would call those "compile-time support programs" and as the name
indicates they should be in the -dev package. I filed a bug against
policy clarifying the "or if the development package is small, include
them in there." to cover that meaning.

A foobar-config program to get the right CFLAGS and LDFLAGS certainly
does not need to be present without the header files.


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.

MfG
Goswin


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

Bug#368275: ITP: overgod -- bi-directional scrolling arcade game

[Sam Hocevar (Debian packages)]

Package: wnpp
Severity: wishlist
Owner: "Sam Hocevar (Debian packages)" <[EMAIL PROTECTED]>


* Package name: overgod
  Version : 1.0
  Upstream Author : Linley Henzell <[EMAIL PROTECTED]>
* URL : https://sourceforge.net/projects/overgod/
* License : GPL
  Programming Lang: C
  Description : bi-directional scrolling arcade game

 Overgod is an arcade game with bi-directional scrolling where you need to
 destroy all enemies in an area in a given time. The game is a mix of the
 classic arcade games Asteroids and Thrust with a lot of additional features.
 .
 Overgod can also be played in two-player duel or cooperative modes, or in
 a special "Time Attack" version where enemies endlessly appear.

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


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

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

[Erast Benson]

On Sat, 2006-05-20 at 20:32 -0500, Ron Johnson wrote:
> If you aren't getting Solaris-specific features (dtrace, etc ?),
> then what's the point of running Solaris?

Nexenta is absolutely rock stable OS (thanks to legendary Solaris
history) and moving towards running any applications written for Solaris
and OpenSolaris as is without re-compilation. All cool features like
DTrace, ZFS, Zones, Kernel DDI, world class UNIX management tools are
are available and integrated.

-- 
Erast


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

Re: Sun Java available from non-free

[Anthony Towns]

On Fri, May 19, 2006 at 01:12:19PM +0200, Martin Zobel-Helas wrote:
> On Friday, 19 May 2006, you wrote:
> > > > As a final note, did anyone from Debian who usually examines licences
> > > > actually examine this one? 
> > > Yes.
> > I take it you were too busy to elaborate on this when you wrote this
> > email. So you will probably give us the name of this person later on,
> > right? Or even better this person may stand up now and speak
> > for himself and share his reasoning.
> i hope it is just due to the lag of bandwidth, so AJ is just trying to
> use as little bandwidth as possible, to leave the rest for us, watching
> the videostream from outside. ;)

Lack of temporal bandwidth is an issue too, as you can probably guess by
the length of time it's taken to actually reply to this. I was actually
surprised to see that I'd posted that mail; I'd thought I'd left it in
my queue to think about for a bit before sending... Oh well.

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.

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
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
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.

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.

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 -- "some of these issues from the FAQ remain ambiguous in
the license, perhaps you would consider clarifying it in the license in
a future version by saying ___" or "this issue isn't clarified in
either the FAQ or the license, and is important because _".

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.

Tom Marble has begun responding to concerns raised on -legal [0] and
I would strongly encourage folks to work with him and other Sun folks
in a positive and constructive manner so that we can further encourage
Sun's current forays into the free software world, hopefully resulting
in them immersing themselves completely, eventually.

Cheers,
aj

[0] Message-id: <[EMAIL PROTECTED]>



signature.asc
Description: Digital signature

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

[Josh Triplett]

Steve Langasek wrote:
> On Sat, May 20, 2006 at 02:18:57PM -0700, Josh Triplett wrote:
>>> 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.
> 
>> Does that imply, though, that one cannot mirror non-free separately from
>> Debian, or put it on a separate CD which one can purchase or distribute
>> separately?  For example, such a clause would prevent Debian from
>> distributing non-free on a separate server, as proposed a while back.
> 
> It may imply this, but this is not a barrier to Debian's inclusion of the
> packages under the current non-free regime.
> 
> The only real requirement for a package's inclusion in non-free is: "can we
> distribute it?"  We don't make any guarantees that other people can also
> distribute it outside of a Debian mirror, or on CDs, or anything else.
> There have definitely been non-free packages in the past that could *not* be
> distributed separately from the Debian mirrors or that could not be
> distributed on CDs.

I certainly didn't mean to suggest otherwise.  Just raising a point for
discussion.  Even non-free licenses could stand improvement towards
becoming less non-free.

- Josh Triplett




signature.asc
Description: OpenPGP digital signature

Re: RFC: Better portability for package maintainers

[Matt Taggart]

Erast Benson 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?

This is Debian, we care about the ability to run proprietary
applications (so people who depend on them can move to free software), but
mostly we run free software. Both combinations are interesting from a
free software perspective, but most people in Debian are more likely to
get excited about the more free option.

-- 
Matt Taggart
[EMAIL PROTECTED]


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

Re: RFC: Better portability for package maintainers

[Matt Taggart]

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).

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.

-- 
Matt Taggart
[EMAIL PROTECTED]


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

VLGC ViroLogic

[Alphonse Numbers]

Floyd,

http://au.geocities.com/comprehensibleness54357

Alphonse Numbers, Acct. Rep. m7785125



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