slib and Debian ?

[Gregor Hoffleit]

While trying to compile the latest gnome CVS snapshot, I found that the 
guile1.2_1.2-3 on my Debian system doesn't suffice to compile guile-gtk. It 
complains about a missing slib/require.scm not found in /usr/share/guile:... 
etc.. After that recent discussion about slib, I found that hamm indeed has an 
slib_2c0-2 package, but this package seems to be intended for use with scm only 
(or the other way round: I think guile1.2_1.2-3 won't find it currently).

Now I have no idea about guile and scm and slib: Should I file a bug against 
guile that it should apply Marius' recent patch to ice-9/slib.scm and 
furthermore that it should use slib when installed ? Or is this a problem with 
the slib_2c0-2 package that it should announce itself to guile somehow ?

Gregor


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?  e-mail to [EMAIL PROTECTED] .

Non-maintainer release of python-1.5 appreciated ?

[Gregor Hoffleit]

I expect a new python release, 1.5, in the next few days (a public 1.5b2  
is out and will be the last beta). Since the current python packages are  
still libc5 and Klee Dienes as maintainer seems to be quite busy  
otherwise, I wonder if a non-maintainer libc6 release of python 1.5 is  
appreciated.

The use of lib6 should also resolve the outstanding bugs of the  
python-base package regarding threading.

Any objections to a non-maintainer release as soon as 1.5 final is out ?

Gregor

BTW: Bruce, python 1.5 contains a FAQ wizard that resembles Faq-O-Matic.  
To see it in action, have a look at the PyModules FAQ at  
http://starship.skyport.net/crew/aaron_watters/faqwiz/contrib.cgi


---
|Gregor Hoffleit   Mathematisches Institut, Uni HD|
| [EMAIL PROTECTED]   INF 288, 69120 Heidelberg, Germany |
|   (NeXTmail, MIME)   (49)6221 54-5771fax  54-8312   |
|  "We will make windows invisible"   |


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Python upgrade: dependency question

[Gregor Hoffleit]

I'm currently trying to prepare python for an non-maintainer upgrade from  
1.4 to 1.5, and I'm running into several issues that I don't know how to  
resolve correctly. Since some people classified python as an important  
package, I'm reposting this mail to the bigger audience of debian-devel,  
hoping to get some more answers.


1.) Python 1.4 (at release 1.4-4) consisted of one base package  
python-base and several extensions: python-dev, -misc, -tk, -mpz, -gdbm,  
-curses, -bsddb, -net, -stdwin, -elisp and -examples. All of them depend  
on python-base (= ${Source-Version}).

python-base installs the interpreter in /usr/bin/python and .py libraries  
in /usr/lib/python1.4 (with a symlink from /usr/lib/python to python1.4)  
and it calls a python script, compileall.py, in its postinst to precompile  
the .py files in /usr/lib/python1.4. postrm removes the precompiled .pyc  
files. The extensions also use compileall.py in their postinst and postrm  
to precompile and remove their .pyc files.

The .pyc format of python 1.5 is not backwards compatible with 1.4.

Principly, python 1.4 and 1.5 can happily coexist on one system, if there  
wasn't /usr/bin/python, which both of them want to use. Debian only has a  
very small number of packages that depend on python, and apart from the  
pyc format, 1.5 should be nearly completely backwards compatible with 1.4,  
therefore I don't see a need for a cohabitation solution.

My question is now, what Depends, Replaces and Conflicts I have to choose  
to make the upgrade smooth.

An added complication is that I'd like to merge the mpz, gdbm, curses,  
bsddb, net and stdwin packages back into python-misc.


One problem is that python-base-1.4 is needed in the postrm's of all the  
other 1.4 packages, therefore -base has to be the last to be replaced.  
OTOH, base-1.5 should conflict with base (<< 1.5), while misc-1.5 will  
depend on base (= 1.5), so I can't simple replace misc-1.4 and friends  
with misc-1.5.

The only solution I found so far is to completely remove all python-1.4  
packages and then install the 1.5 packages, but then I'm also forced to  
remove all other packages that depend on python like dpkglint or  
dpkg-python. Hmm, since they may have to recompile pyc files, that may be  
a necessity anyway ?

Is there a clean solution for those kinds of problems ?

Gregor


---
| Gregor Hoffleit admin MATHInet / contact HeidelNeXT |
| MAIL: Mathematisches Institut   PHONE: (49)6221 56-5771 |
|   INF 288, 69120 Heidelberg / Germany  FAX: 56-3812 |
| EMAIL: [EMAIL PROTECTED] (NeXTmail)|


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

gmp_2.0.2-3.deb in hamm/devel ?

[Gregor Hoffleit]

Pardon my ignorance, but why is there an gmp_2.0.2-3.deb in hamm's devel  
directory when we have gmp2_2.0.2-4.deb in hamm/libs ?

Gregor


---
|    Gregor Hoffleit   Mathematisches Institut, Uni HD|
| [EMAIL PROTECTED]   INF 288, 69120 Heidelberg, Germany |
|   (NeXTmail, MIME)   (49)6221 54-5771fax  54-8312   |
|  "We will make windows invisible"   |


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Removing directories in postrm ?

[Gregor Hoffleit]

A few of python's postinst scripts byte-compile the source files they  
install. The byte-compiled files are to be removed by the postrm scripts  
(a script removes all byte-compiled files where sources can't be found).  
Now if the python package had created a new directory, this directory is  
not empty until after postrm and won't be removed therefore.

Should I keep this procedure and perhaps try to remove the directory in  
postrm with something like "(rmdir /usr/lib/python1.5/lib-tk 2>/dev/null  
|| true)" ? The user still will get a warning about the non-empty  
directory.

Should I come up with a solution that tries to remove the byte-compiled  
files in the prerm ? (I had to keep track of the files that were created  
in postinst).

Or should I include the byte-compiled files in the packages ?

Gregor


---
|    Gregor Hoffleit   Mathematisches Institut, Uni HD|
| [EMAIL PROTECTED]   INF 288, 69120 Heidelberg, Germany |
|   (NeXTmail, MIME)   (49)6221 54-5771fax  54-8312   |
|  "We will make windows invisible"   |


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Custom library for emacs 19.34 ?

[Gregor Hoffleit]

The most recent python-mode for emacs needs a recent version of Per  
Abrahams' Custom library (http://www.dina.kvl.dk/~abraham/custom/). The  
version supplied with xemacs19/20 and Emacs 20 is fine, but the version  
supplied with emacs-19.34 won't work.

I have tried to package custom (look at  
http://www.mathi.uni-heidelberg.de/~flight/debian-private/custom/) so that  
it can be dropped in for emacs-19.34 and that works for python-mode.el  
3.28. Still I've heard rumours that custom-1.9961 breaks GNUS. Perhaps  
interested parties could try this package.

If it does no big damage, I'd like to suggest to include this in hamm  
somehow (either as separate package, or as addition to emacs).

Gregor


---
|    Gregor Hoffleit   Mathematisches Institut, Uni HD|
| [EMAIL PROTECTED]   INF 288, 69120 Heidelberg, Germany |
|   (NeXTmail, MIME)   (49)6221 54-5771fax  54-8312   |
|  "We will make windows invisible"   |


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Snapshots of python 1.5 packages

[Gregor Hoffleit]

I've put a snapshot of my python 1.5 non-maintainer packages at  
http://www.mathi.uni-heidelberg.de/~flight/debian-private/python/.

There are still some unresolved problems regarding the removal of the old  
python-1.4 packages (their postrm scripts are due to fail), but the  
upgrade seems to work somehow now (at least when using dselect or one  
straight dpkg run), while it still leaves some old files in place.

Gregor


---
|    Gregor Hoffleit   Mathematisches Institut, Uni HD|
| [EMAIL PROTECTED]   INF 288, 69120 Heidelberg, Germany |
|   (NeXTmail, MIME)   (49)6221 54-5771fax  54-8312   |
|  "We will make windows invisible"   |


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Anybody tried to compile COAS ?

[Gregor Hoffleit]

Has anybody tried the COAS 0.09 snapshot with Debian ? With a few  
small modifications it compiled and installed for me. Many of the  
tests succeed, but the `table' UI test with qt interface hangs, all UI  
tests with curses interface segfault or dump cores, and all python  
programs with UI don't work.

I tried this with two different versions of python 1.5, once with  
threading enabled (linked against libc6' libpthread) and once without  
threading support. This seemed to influence the point of crash, so  
there might be a problem with compiling threading into python  
(although python did pass all other threading tests).

I'd like to hear other experiences with COAS and Debian. Did anybody  
try it on an libc5 system ?

Gregor


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Custom library for emacs 19.34 ?

[Gregor Hoffleit]

Hannu Koivisto <[EMAIL PROTECTED]> wrote in reply to me:

>  If it does no big damage, I'd like to suggest to include this in
>  hamm somehow (either as separate package, or as addition to
>  emacs).

Sorry, but you don't get my vote with this plan. Unless you
provide at least Gnus as a separate package, users can
easily break emacs by installing a package (custom in this
case) that conflicts with something (Gnus 5.3 in this case) in a
way that dpkg can't see (because custom conflicts with Gnus 5.3,
which is contained in emacs-19.34, which custom doesn't conflict
with (according to your idea)).

Ok, I could make python-elisp 1.5 depend on  
xemacs19|xemacs20|emacs20|custom-el, make a second package  
python-oldelisp (no dependencies since it would work with all  
emacsen), and finally a third package custom-el which recommends a  
fourth package gnus (>=5.5).

That would make the users of 67% of Debian emacsens happy and provide  
the remaining with two options.

Isn't it a pity that there's no established way to package elisp for  
Debian in a way that supports all emacsens, as far as possible.


Gregor


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Libc6 progress: 1998-01-07

[Gregor Hoffleit]

Neil A. Rubin <[EMAIL PROTECTED]>:
wmaker-0.6.3-1   (Mixed dependencies)

Marcelo E. Magallon <[EMAIL PROTECTED]> is working on  
WindowMaker packages based on wmaker-0.12.3.

Gregor


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Snapshots of python 1.5 packages

[Gregor Hoffleit]

Mike Orr wrote:
> > I've put a snapshot of my python 1.5 non-maintainer packages at
> > 
> Hi again, Gregor.  I tried to download these today, but both lynx and
> netscape want to display the files as text and when you save it into a
> file it gets corrupted (text mode mangling?).  That site does not accept
> anonymous ftp connections, so I can't ftp it.  Do you have a real ftp
> site available?

Thanks for the hint. I've set the MIME type for .deb files to  
application/octet-stream, hope this works better.


I have also updated the python 1.5 package snapshots on the page above. I  
think I'm gone release this stuff as non-maintainer packages in the next  
few days.

Then, I've grabbed all the python-dependent packages from hamm (that's  
python-wpy, python-pmw, dpkg-python, dpkg-ftp-x, dpkglint and glint) and  
started to rework the for python 1.5. The maintainers of those packages  
may want to have a look at them. I think I'll release 1.5-0.1 first, file  
bugs against those packages and then wait for a while to give the  
maintainers a fair chance to update their packages. The current standings  
are on

http://www.mathi.uni-heidelberg.de/~flight/debian-private/

I'm providing a default postinst and prerm for byte-compiling python  
add-on packages, which IMHO provides a better solution than 1.4.

Gregor


PS: If you're really interested in these packages, please have a look at  
the postinst/prerm/compileall.py part and tell me what you think. Ugly,  
but IMHO the only way to cleanly remove python 1.4 while upgrading.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: fltk and XForms compliance

[Gregor Hoffleit]

Mark Baker wrote:
On Fri, Apr 17, 1998 at 11:56:02AM +0100, Enrique Zanardi wrote:

> > That will be a problem with lyx as the upstream side is
> > thinking about a switch anyway, but qt is the leading candidate
> > there.
> 
> Someone should tell them about GTK, now that version 1.0 has been
> released. A little bit of info about the distribution problems
> they will face if the choose Qt

Unfortunately they've already chosen Qt. And done all the work to
port it.

Have a look at
http://www-pu.informatik.uni-tuebingen.de/users/ettrich/klyx.html

It's a shame he chose to use a non-free toolkit, as klyx looks very
nice.

It's not correct that the LyX project ahs choosen Qt. The Qt port (KLyX) was 
done overnight by two KDE project members, Matthias Ettrich and Kalle 
Dallheimer. Matthias happens to be the original LyX author and KDE project 
founder.

The release of KLyX was not completely welcomed by the LyX project. They plan 
to separate the GUI layer from the engine so that different toolkits can be 
plugged in, but from what I understood, Matthias just took out the XForms 
routines and replaced it by Qt code instead of helping to make the thing more 
independent by the toolkit.

Try looking up Matthias' announcment and the reactions in the LyX mailing list 
archives (http://la1ad.uio.no/lyx/).

LyX definitely doesn't bet on Qt.

Gregor


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

ObjC runtime (was: Upcoming Debian Releases)

[Gregor Hoffleit]

> Include the multi-thread support patch for the Objective-C runtime lib (???)

According to Scott Christley <[EMAIL PROTECTED]> (de-facto  
maintainer of the gcc Objective-C runtime), the Objective-C runtime should  
be kept in sync with the gstep-base included in the release.

bo includes gstep-base-0.2.12 and gstep-base-0.2.12 includes a patch file  
gcc-2.7.2.1-objc.diff, which therefore should be applied to the gcc in bo  
(the patch applies fine to gcc-2.7.2.2).

The remaining question the thread model to be enabled in the patched objc  
runtime. The patched runtime can be compiled for e.g. PCthreads,  
LinuxThreads or no threads at all. Who is to decide this ?

Gregor


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: 14 days till bug horizon

[Gregor Hoffleit]

On Mon, Mar 13, 2000 at 01:54:04PM +0100, Tomasz Wegrzanowski wrote:
> On Mon, Mar 13, 2000 at 11:14:55AM +0100, Richard Braakman wrote:
> 
> > Package: fortify (non-US/non-free).
> > Maintainer: Roberto Lumbreras <[EMAIL PROTECTED]>
> >   60162 fortify: Does the index file / database need to be updated?  Is 
> > there a new upstream?

Well, last time I noticed, fortify didn't work with the navigator-base-47
package in potato (somehow the Navigator binary had a checksum different
from the upstream version included in fortify's database).

This is easy to fix, but IMHO it's worse enough to not let fortify be
released with potato.

Gregor

I don't get copies of bug reports to my packages

[Gregor Hoffleit]

For some reason, since a while I don't get copies of bug reports against my
packages mailed to me. I'm tracking debian-bugs-dist now and checking the
web page once in a while, but this is less than satisfying.

Is this feature of the BTS still supposed to work, and how can I check what
goes wrong ?

Gregor



pgpxl1BMfT1ZR.pgp
Description: PGP signature

Re: next week in Heidelberg

[Gregor Hoffleit]

On Fri, Mar 17, 2000 at 10:10:53AM +0100, Philipp Frauenfelder wrote:
> I'm going to be in Heidelberg (Universitäts-Rechenzentrum) the
> next week (20th to 24th of march). I'd like to meet some other
> Debian developers to swap keys and have a beer in the evening.

Fine. I can't yet suggest an exact date, but I should have time for a beer
any evening from Monday to Thursday. Are you still reading mails over the
weekend and next week, or how could I contact you ?

Gregor



pgpFVKXH91xjX.pgp
Description: PGP signature

Re: Release-critical Bugreport for March 24, 2000

[Gregor Hoffleit]

On Fri, Mar 24, 2000 at 03:15:02AM -0600, BugScan reporter wrote:
> Package: gnucash (debian/main)
> Maintainer: Tyson Dowd <[EMAIL PROTECTED]>
>   60417  docs are split between /usr/doc/gnucash and /usr/share/doc/gnucash
>   60615  gnucash: LANG=de_DE does weird things
>   60655  should depend on libesd0 | libesd-alsa0, not just libesd0

I just noticed that #60615 and 60655 are fixed in woody's gnucash package,
gnucash_1.2.5.cvs.2204-1.

#60417 is easy to fix.

If the maintainer doesn't speak up now, I will take
gnucash_1.2.5.cvs.2204-1, fix #60417 and upload it to frozen and
unstable as NMU.

Gregor



pgpaWT8inEN5b.pgp
Description: PGP signature

Re: Release-critical Bugreport for March 24, 2000

[Gregor Hoffleit]

Ok, I'm preparing a NMU for gnucash.

   Gregor
   

On Sat, Mar 25, 2000 at 06:48:39PM +1100, Tyson Dowd wrote:
> On 24-Mar-2000, Gregor Hoffleit <[EMAIL PROTECTED]> wrote:
> > On Fri, Mar 24, 2000 at 03:15:02AM -0600, BugScan reporter wrote:
> > > Package: gnucash (debian/main)
> > > Maintainer: Tyson Dowd <[EMAIL PROTECTED]>
> > >   60417  docs are split between /usr/doc/gnucash and 
> > > /usr/share/doc/gnucash
> > >   60615  gnucash: LANG=de_DE does weird things
> > >   60655  should depend on libesd0 | libesd-alsa0, not just libesd0
> > 
> > I just noticed that #60615 and 60655 are fixed in woody's gnucash package,
> > gnucash_1.2.5.cvs.2204-1.
> > 
> > #60417 is easy to fix.
> > 
> > If the maintainer doesn't speak up now, I will take
> > gnucash_1.2.5.cvs.2204-1, fix #60417 and upload it to frozen and
> > unstable as NMU.
> 
> Hi,
> 
> I'm the maintainer for gnucash.  An NMU would be great.  
> I've run out of time to work on this stuff at the moment.  I have a
> prospective new developer in the wings who would like to take over this
> package, but it hasn't been time to do this before potato is released.


pgpj9JwslYTr6.pgp
Description: PGP signature

wnpp@debian.org still alive ?

[Gregor Hoffleit]

Is [EMAIL PROTECTED] still alive and maintained ? During the last few months,
I sent several ITP's and a request to remove a package from the list to this
address, but AFAICS all of them were ignored.

E.g. I requested to remove "dgs" from the list of packages needing a new
maintainer, and I sent an ITP for WorldPilot.

Gregor



pgpPC0yAuHGPW.pgp
Description: PGP signature

Re: Ian Jackson, please get me the hell off your blacklist.

[Gregor Hoffleit]

On Fri, Mar 31, 2000 at 11:18:47PM +1000, Craig Sanders wrote:
> On Fri, Mar 31, 2000 at 03:43:27AM -0500, Branden Robinson wrote:
> why? it's his mail server, he can do what he likes with it. he is
> entitled to reject or defer mail delivery to his system for any reason
> he chooses, regardless of whether you happen to approve or not. he can
> run whatever insane spam filtering software he likes (and yes, i do
> happen to think that SAUCE is insane, but my opinion - like yours - is
> irrelevant because it's his mail server, not yours or mine).
> 
> on your machines, your policy applies. on his machines, his policy.  simple.
> 
> your right to free speech does not include the right to force anyone
> else to listen.  

I think Branden's whole point was that he doesn't like to be forced to
listen to something he's not able to respond to (to Ian's bug report,
that is) and that therefore he will just do this: not listen to Ian's
bug reports. So I think your argument doesn't work well here.

Gregor

Python 1.6 released and GPL incompatible

[Gregor Hoffleit]

Python 1.6 was released finally today (for an announcement, see 
http://www.python.org/1.6/), and it was released under the discussed
CNRI license. This license was intended to be compatible with the GPL,
but RMS says he thinks it's not (cf. the announcement).

Moments later, Guido and BeOpen's PythonLabs released Python 2.0b1, 
under the same license terms so far.

AFAIK, there were consultations until the last mintue between CNRI, 
FSF (i.e. RMS and his law consultant Prof. Moglen) and BeOpen, moderated 
by Guido, but they were not able to settle the question in time for a
timely release of Python 1.6. Therefore, Guido decided in order to not
delay the work on 2.0 (which is supposed to come out later this year),
that 1.6 would be released under this imperfect license, and 2.0b1 as
well.

The consultations will go on, and there's still hope that a settlement
between RMS and CNRI will be found that produces a license that's 
compatible with the GPL. If this succeeds, Python 2.0 would be released
under this license.


This opens the question what Debian should do with Python 1.6:

I'll ask debian-legal for a comment about the CNRI license. AFAICS, it's
a fair DFSG-free license otherwise, so we could include Python 1.6 in
woody/main.

Still, if 1.6 were to replace 1.5.2, we had to check all packages that 
depend on Python, if we think their license is still compatible with the 
new Python license, and remove them if it's not. I'd opt against this.

That leaves me with two possible solutions:

1) Ignore Python 1.6 and up, as long as the license is not compatible
   with the GPL. That's probably the easiest way to go, but is it
   justified ? Looks like a deliberate discrimination against a
   DFSG-free license, only because it's not GPL compatible.

2) Include both Python 1.5.2 and 1.6 in woody/main. The 1.6 packages
   would not satisfy the dependencies of existing packages; any maintainer
   who'd make a package depend on Python 1.6 would have to make sure that
   its license is compatible with the Python 1.6 license.

I think I'd prefer the second solution. What do others think ?

Gregor


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

Re: Python 1.6 released and GPL incompatible

[Gregor Hoffleit]

On Thu, Sep 07, 2000 at 10:47:01AM -0700, Joey Hess wrote:
> Gregor Hoffleit wrote:
> > Still, if 1.6 were to replace 1.5.2, we had to check all packages that 
> > depend on Python, if we think their license is still compatible with the 
> > new Python license, and remove them if it's not. I'd opt against this.
> 
> Hm, I'm confused. Are you saying that you think that code written in
> pthon must have a license that is compatable with python's license?
>
> I don't see us making this kind of check for code written in perl, or
> code wirtten in C, or any other language.

That's why I wrote that we have to check the packages that
_depend_on_Python_ ;-) 

No need to worry, I don't want to open that can of worms with a discussion
about the relation between interpreted code and the interpreter. I don't see
this as an issue here.

Still the issue is: 

A dependency on python-base either says that the package has code written in
Python and therefore needs a Python interpreter to run. No problem here.

> Or are you really only talking about packages that dymanically or
> statically link with python?

Indeed. A dependency may also mean that the package is a binary extension
module for the Python interpreter which will be linked dynamically with the
interpreter (at some time, when the module is imported).

In this case, if the module contains GPL code, I would currently stay away
from distributing it with a dependency on Python 1.6.

Gregor



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

Re: Pyton 1.6's license

[Gregor Hoffleit]

> "KK" == Ken Kinder <[EMAIL PROTECTED]> writes:
KK> I'm a little worried about Debian not packaging Python 1.6
KK> because RMS feels so strongly (it's RMS) that it isn't
KK> compatible with GPL. I release Python GPL code and don't feel
KK> it's incompatible, but it could be damaging to either Debian,
KK> Python, or both if it can't be packaged.  Can't Python 1.6 be
KK> licensed under more than one license like Perl?


Just a word of clarification from the Debian Python maintainer:


The Python 1.6 license is completely fine for Debian; it's perfectly free
software (RMS admits that, too).

The point is that it's different than the old Python license, and therefore
some things that were fine with the old Python now seems to become illegal
(at least that's what RMS's impression is).

Debian has no big war chest. If some author claims that he regards
distribution of binaries of his GPL code linked code under the new Python
license as illegal, then this is a kind of legal threat that we have to take
seriously. Debian doesn't want to get involved in a legal action on this
ground, and therefore I think our safest bet is to stay away from
distributing GPL code linked with Python 1.6 code. At least as long as the
issue is settled (which I still have hope will happen with before the
release of 2.0).

Based on this, that leaves us with three options:

1.) Replace Python 1.5.2 with Python 1.6 in the Debian development tree
  ("woody").

  Then we had to remove all packages that might be troublesome,
  license-wise. Among them are python-gdbm, python-gtk, python-gnome,
  python-glade. Would also affect codecommander, solfege, bg5ps, icepref,
  routeplanner, gimp-python and so on. I.e. quite some work to check and
  discriminate among all of them.

2.) Stick with Python 1.5.2 and ignore Python 1.6 and up until this issue is
  settled.

  The easiest solution. Many propose that.  

  Anyway, if the issue is not settled in the near future, that would more or
  less automatically mean a fork of Python at some time, a VERY bad thing.
  
3.) Stick with Python 1.5.2 and package Python 1.6 as optional packages
  (something like python1.6-base etc. pp.) that could be installed parallel
  to Python 1.5.2.

  All existing packages would continue to depend on Python 1.5.2, with no
  license trouble.

  Maintainers and users would have to decide if their application/package is
  compatible with the new Python license.


You see that Debian has nothing against the new Python 1.6 license; it's
just a matter of labour involved to implement the consequences of the new
license in our distribution.


OTOH, a resolution of the discussion about the compatibility of the licenses
would help us very much.

  
Based on the experience with KDE, I'd request that authors of GPL code that
think that it's fine to link the code with code under the Python 1.6
license, do add a short note to their copyright plate that declares that the
code is licensed under the GPL with the amendment that it's ok to link the
code with Python 1.6 code. Don't ask me how to spell this in a legally
meaningful way ;-)

Gregor



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

NMU of sitecopy ?

[Gregor Hoffleit]

Tom,

the sitecopy package is heavily out of date. sitecopy in sid is at 0.9.10
(the upstream release as of Apr 2000). Since then, there were more than ten
new upstream releases with various major improvements. The most recent
upstream version is now 0.10.12.

The bug page for sitecopy lists various bugs as open that already have been
fixed by you, (e.g. #55156, which was fixed by 0.9.10-1), and bug reports
that were subsequently fixed in NMUs have not been touched by you when you
uploaded 0.9.10-1.

I filed a report about a new upstream version some three months ago
(#74548), and got no reaction so far. Likewise for #71077 (124 days old) and
most other bug reports, where you never showed any reaction (at least
nothing is recorded in the BTS).

As reaction to #71077, you wrote on Sep 07, 2000 that you uploaded 0.10.4 to
Incoming for woody. This package never arrived in woody, but you didn't seem
to care.

Tom, are you still with us, and are you still interested in maintaining this
package ? Then, please take this as a strong reminder that there are some
people who are interested in this package.


If I don't get a reaction, I will bring up the issue how to take away this
package from the current maintainer, and I'll upload an NMU RSN.


Gregor

Amaya still maintained ?

[Gregor Hoffleit]

Hi Steve,

are you still maintaining amaya ? The package is very much out of date
(3.2.1-1 is in sid, while upstream is now at 4.2.1, which has significant
improvements). 

The BTS lists three bugs reports regarding new upstream versions, and you
didn't even reply to any of them.


db.debian.org lists no date for your last occurrence on a Debian list; my
search gave that you made an upload of pump on Oct 22, so I guess you're
still with the project.

If I don't get a reply to this mail, I think I'll go on and make an NMU of
amaya with the most recent upstream version.


Gregor

Re: Packages not making it into testing

[Gregor Hoffleit]

On Wed, Apr 25, 2001 at 03:53:15PM +1000, Anthony Towns wrote:
> The following packages haven't been uploaded this year, and also haven't
> made it into testing for a while. If people could go through and make
> sure the maintainer knows about the issues, or do NMUs as appropriate, or
> work out what the problem actually is, or similar, that'd be pretty cool.

On a related note, could somebody tell me what keep python 1.5.2-16 out of
testing ?

update_excuses says:

  python 1.5.2-16 (currently 1.5.2-10) (standard) (high) 
  - Maintainer: Gregor Hoffleit <[EMAIL PROTECTED]> 
  - python uploaded 14 days ago, out of date by 12 days! 
  - valid candidate (will be installed unless it's dependent upon 
other buggy pkgs)

Do I have to check all dependencies in all 54 python packages in the pool
(10 architectures, 4 arch-dependent packages, 4 arch-independent packages),
to see what's the reason that keeps the packages out of testing ?

All I can find about python in update_output.txt are things like

  tried: python (0) 38 a-38
  tried: python (0) 42 a-42

If there's a reason that keeps the package out of testing, it would be nice
to have that reason explained as well. Is that being worked on ? If nobody
else is working on this, could somebody give me a hint where to start
working on improving the status output ?

Gregor

Re: Packages not making it into testing

[Gregor Hoffleit]

On Thu, Apr 26, 2001 at 01:07:58AM +1000, Anthony Towns wrote:
[...]

> task-python-dev just depends on -imaging-tk.
> 
> So this means python can't be updated without also updating palm-doctoolkit
> and python-imaging, and those can't be updated without updating python.
> 
> Further some of the binary packages from python-imaging in sid depend on
> python2, which isn't in testing yet. So they can't go in until python2
> does. Python2 at the moment isn't going in because the last upload was
> only 8 days ago, and looks like it has strict enough dependencies that
> it won't go in until it's built on m68k.
> 
> There may be other things involved too, but I suspect not.

I see.

So that means the python, palm-doctoolkit and python-imaging packages in
unstable are somehow 'grouped' together, and since python-imaging also
depends on python2, they all depend on python2 being moved into testing ?

Hmm, does this mean that although update_excuses.html says '(but m68k isn't
keeping up, so ignoring this problem)', the lack of m68k packages will hold
back the move of python2 into testing ? Is this because some python-imaging
packages depend on python2-tk, and because it would not be  available in
testing ? Hmm, I'm starting to understand...


> > If there's a reason that keeps the package out of testing, it would be nice
> > to have that reason explained as well. Is that being worked on ? If nobody
> > else is working on this, could somebody give me a hint where to start
> > working on improving the status output ?
> 
> http://ftp-master.debian.org/testing/ says where the code is and so forth.
> Hacking on the code isn't very straightforward; if you like you can write
> some sort of filter for the various output that's already there to make it
> more comprehensible. Arm does this to get a list of out of date packages for
> arm that don't have RC bugs against them already, eg.

I see. Well, after you explained the lines in update_output.txt, I think I
see better what's going on.

Gregor

Re: Intent for NMU of python-2.1 packages

[Gregor Hoffleit]

* Jérôme Marant <[EMAIL PROTECTED]> [010904 11:18]:
> Matthias Klose <[EMAIL PROTECTED]> writes:
> 
> ...
> > in June (2.1) and July (2.1.1). Gregor (the python-1.5 and python-2.0
> > maintainer) has put experimental packages at
> > http://people.debian.org/~flight/python and was asking for help
> > regarding the packaging (20010801). Jérôme Marant answered (20010803),
> > but since this date nothing happened. I intend to do a NMU of
> > python2.1 based on Gregor's experimental packages that can coexist
> ...
> 
> Do you know what happened to Gregor since 20010801? I periodicaly
> had a look to his page at debian.org but nothing happened since then.
> Did you contact him? Do you have his agreement for the NMU?
> What do you plan to do about the idle package?

I'm still alive, I'm not lost ;-)

I'm just back from a ten day vacation after several weeks of intense
real world work, which will continue until the mid of September.


I'm +2 on uploading the python2.1 packages into unstable. All I wanted
to do was a little bit cosmetic cleanup, and (and that was the stumbling
point due to lack of time), some kind of documentation included in the
packages. Matthias, have you already done some work on these packages ?
Could you forward your modifications to me ?


Also, I'm +1 on uploading the python1.5 packages into unstable.

That means they would replace the existing python-* packages.

And that's the problem where I was stuck.

The dependencies of the current experimental python1.5 packages aren't
good enough to allow an easy upgrade from potato or earlier. AFAICS, I
would have to include empty transitional packages for almost all
python-* packages built from the python source. That's butt ugly IMHO.

Furthermore, it's my current impression that we have to orphan all
python-* packages in order to get a clean upgrade path!

There are many packages with broken dependencies in potato (i.e.
packages that install stuff in /usr/lib/python1.5, but don't have a
versioned dependency on Python 1.5). Therefore, any future python-base
package either has to be compatible with stuff in /usr/lib/python1.5,
or has to list all those broken packages as conflicts. Either is ugly.

Therefore I think we have to get rid of all the problem-ridden package
names, i.e. at least python-base and python-tk, perhaps even python-dev.
I don't see any other solution.



Please provide me with feedback if I should make this radical
transition. I would then go on and upload python1.5 and python2.1
(perhaps even a python2.0 source package to ease the migration). The
existing python (and python2) packages would be removed by this upload
(the packages built from python.orig.tar.gz, that is).

Python package maintainers should then change their packages to build
python1.5-* and python2.1-* packages (python2.0 if needed), and make
them depend on python1.5-base etc. That would remove the need for
versioned dependencies.

At a later point, we could implement a kind of registry like the emacsen
have, so that third-party packages could build only one python-*
package, that registers itself with all existing pythons.


How does that sound ?


Gregor

ftp1.us.debian.org down ?

[Gregor Hoffleit]

Since a few days, I'm unable to connect to ftp1.us.debian.org.
I always get an error "530 Unable to chdir.". Could somebody look
into this ?

Gregor


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

Re: ftp1.us.debian.org down ?

[Gregor Hoffleit]

You wrote:
> On Mon, Jun 08, 1998 at 11:02:57AM +0200, Gregor Hoffleit wrote:
> > Since a few days, I'm unable to connect to ftp1.us.debian.org.
> > I always get an error "530 Unable to chdir.". Could somebody look
> > into this ?
> 
> Netgod "stole" its disk in order to produce some Debian CD-ROMs.
> The system should come back today (monday).

Fine. Now (Tuesday morning GMT) I'm finally getting a "Connection refused". I 
guess the disk is back again ;-)

Perhaps there's an European mirror of the preliminary hamm CD images ??? ;-)

Gregor


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

Compiling stuff for frozen with g++272 ?

[Gregor Hoffleit]

I don't know how to handle this:

My swig package in frozen has a small, but `important' bug dealing with  
version numbers (#20068, swig: dpkg thinks 1.1p5-1 < 1.1.b5.p2-1).

I thought about simply rebuilding the package with a changed revision  
number "1.1.p5-1" which would fix the bug in a very transparent way.

But when I compared the resulting packages, I found that the old package  
had been built with a g++/libstdc++ based on 2.7.2, while nowadays g++  
2.90 is the official C++ compiler, going with libstdc++2.8.

Now I don't know: When I recompile the package using the official g++  
2.90 / libstdc++ 2.80 combo, this may introduce new bugs, therefore I'm  
sure Brian won't allow this to go into frozen.

The alternative is faking an build environment that installs g++272 as  
c++ and uses libstdc++272. Is this the accepted way to go ?

Gregor


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

Re: Intenet To Package: Electric Eyes

[Gregor Hoffleit]

Aaron Van Couwenberghe wrote:
I will shortly post an intent to package OmniORB. It is a more...
lean, shall we say, CORBA ORB implementation than mico. Eventually
(by word from the gnome mailing lists), gnome will be ported to
OmniORB.

Well, most certainly GNOME won't switch back to OmniORB. Instead they are 
developing their own object request broker, ORBit. IIRC, you can see early 
snapshots of ORBit on Jim Pick's gnome snapshot site at ftp.jimpick.com.

Gregor


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

Freeze and soon-to-be-freed package

[Gregor Hoffleit]

Since I've heard rumours about the slink freeze taking place soon:

Bobo by Digital Creations consists of three independent packages which 
recommend each other. Two of them (python-bobo, python-bobodtml)
already are in slink with a BSD style license. The license of the
third package, BoboPOS, will be fixed with the next release, which can 
be expected anytime between tomorrow and in two months.

Can I rest assured that this new package will be accepted for slink
even after the freeze ? Would it be better to upload the current
version to "non-free" and move it into "main" after the freeze ?

Gregor

Intent to package: python-mxtexttools, python-mxcrypto

[Gregor Hoffleit]

I'd like to announce my intention to package two more python add-on
modules:

 Package: python-mxtexttools
 Version: 1.0.1-0
 Section: interpreters
 Priority: optional
 Architecture: i386
 Depends: libc6, python-base (>= 1.5)
 Installed-Size: 132
 Maintainer: Gregor Hoffleit <[EMAIL PROTECTED]>
 Description: Fast text manipulation tools for Python
  Fast text manipulation tools for Python.

 Package: python-mxcrypto
 Version: 0.1.0-0
 Section: non-US/interpreters
 Maintainer: Gregor Hoffleit <[EMAIL PROTECTED]> 
 Description: Generic SSLeay crypto wrapper type for Python
  A Python wrapper for the ciphers and hash functions in Eric Young's
  SSLeay library.



-- 
| Gregor Hoffleit admin MATHInet / contact HeidelNeXT |
| MAIL: Mathematisches Institut   PHONE: (49)6221 56-5771 |
|   INF 288, 69120 Heidelberg / Germany  FAX: 56-3812 |
| EMAIL: [EMAIL PROTECTED] (NeXTmail)|

Intent to package python-opengl and pcgi

[Gregor Hoffleit]

Then, I'd like to announce my intention to package python-opengl and 
pcgi. python-opengl depends on togl, which has not yet been packaged.

 Package: python-opengl
 Depends: mesag2, togl, python-tk
 Description: An Python interface for OpenGL, GLU, GLUT and Togl
  PyOpenGL provides bindings between the Python language and OpenGL and 
  related libraries.

 See also: 

 Package: togl
 Depends: mesag2, tk80
 Description: A Tk OpenGL widget
  Togl is a Tk widget for OpenGL rendering.Togl allows one to create and 
  manage a special Tk/OpenGL widget with Tcl and render into it with a C
  program. That is, a typical Togl program will have Tcl code for managing 
  the user interface and a C program for computations and OpenGL rendering. 

 Home page: http://www.ssec.wisc.edu/~brianp/Togl.html



 Package: pcgi
 Recommends: python-bobo
 Depends: python-net
 Description: Persistent CGI for Python
  Persistent CGI provides a transparent architecture for accessing 
  published web objects as long-running processes. Published objects may 
  be accessed on any server supporting CGI.
  Pcgi is designed to work with Bobo (the Python object publisher), 
  effectively turning a Bobo application into a fast, long-running web 
  application without requiring any changes to the application code.

 Home page: http://www.digicool.com/releases/pcgi/

When will the freeze happen ???

[Gregor Hoffleit]

Sorry, maybe I'm deaf or blind or my mail spool went to /dev/null, but I 
never saw a concrete date for the freeze in the last months. Can somebody 
enlighten me when it will happen ?

Gregor

Wrong dependencies for a single deb: How to reupload ?

[Gregor Hoffleit]

Probably a pretty dumb question: 

dpkg-shlibdeps got the dependencies wrong for a single deb in the
python package (tkstep8.0 instead of tk8.0).

The package is already DONE; is it possible to reupload just that
single python-tk with a fixed control file and the same revision, or
do I have to reupload a complete new revision of all python packages ?

The source is completely unchanged, only packed with a different
configuration.

Gregor

Re: Debian booth at LinuxTag '99?

[Gregor Hoffleit]

Christian Weisgerber wrote:
>   Because we, the organizers of LinuxTag '99, would like to invite the
>   Debian project to set up a booth at this year's event. Several major
>   Linux distributions will be there: SuSE, DLD, representatives for Red
>   Hat, etc. Last year quite a few visitors expressed their disap-
>   pointment about Debian's absence.

If time permits, I'd like to attend and help with a Debian booth. 
Kaiserslautern is just a stone throw away, still I didn't manage to 
attend last year.

Are there any other volunteers that would like to help setting up a booth 
there ? 

    Gregor


---
|Gregor Hoffleit   Mathematisches Institut, Uni HD|
| [EMAIL PROTECTED]   INF 288, 69120 Heidelberg, Germany |
|   (NeXTmail, MIME)   (49)6221 54-5771fax  54-8312   |

Re: New DFSG Draft revision #3

[Gregor Hoffleit]

On Sat, Jan 16, 1999 at 06:39:53PM -0800, Darren Benham wrote:
> I'm not sure I'd agree that the version of DFSG aj and I are working
> would allow the "powered by" clause -- atleast not as a binding
> restriction. In our proposal, the section you quote says nothing
> about the notices in finished work the way Ian's proposal did. I
> wouldn't call a produced web page either source or documentation and
> it's certainly not the software being executed.

In the case of Zope, I have to disagree. You have to think of Zope as
an application with an GUI realized in HTML. I don't see a difference
to an application that publishes its GUI as X11 calls:

Your DFSG2 draft says "The license may require such notices to be
displayed: * during execution of the software".

Consider a license for an application with an X11 GUI. If the license
would require that you always give credits to the original author by
the way of an "About" panel, I think this would be acceptable
according to your draft.

Now where's the difference if the same program also has an web GUI and
if the license had the same requirement ?


> Personally, I think it would be a far reach to even call any/all web
> pages "advertising material".  And if it could, under the current
> wording, I'd change it to be "material offering the software
> package" or some such thing... Unless
> Debian *wants* that sort of attribution clause to be DFSG-free

Yep. This has nothing to do with the advertising clause.


> > This leads me to the following question: The current DFSG doesn't
> > explicitely rule out postcard-ware nor things like the ZPL attribution
> > requirement [2]. The new proposals all disallow postcard-ware
> 
> hence the desire to release a second version of the DFSG...
> 
> > requirements, but specifically allow notice requirements. This leads
> 
> but in a very restricted sense...
> 
> > me to the conclusion that notice requirements are accepted by the
> > common interpretation of the current DFSG (contrary to
> > postcard-ware-like requirements). Is that correct ?
> 
> I supposed it could be argued, in letter.. but they seem unacceptable in the
> spirt of the DFSG.

Well, do you think requirements for notices during the executions of
the software are acceptable in the spirit of the DFSG ? If that's the
cause, I don't think you can rule out the "powered by" clause in the
ZPL.

Don't get me wrong: I don't advocate the notices clause in your
proposal. It's just that I think it's obvious that it includes
licenses like Zope's, and since nobody argued against the clause, I
wondered if that was an commonly accepted interpretation of the DFSG
between the developers.

Gregor

Re: New DFSG Draft revision #3

[Gregor Hoffleit]

On Tue, Jan 19, 1999 at 08:56:09PM -0800, Darren Benham wrote:
> On 20-Jan-99 Anderson MacKay wrote:
> > As I read the license, it just requires that you display notice that your
> > website was created using Zope, e.g. a sort of "powered by Zope" logo
> > kinda thing, and you need a "credits" page of some sort.  I'm not even
> > sure this license requires that this notice be on every page, just that it
> > be in some obvious place near the "front" of the site.  (But I don't have
> > the license here in front of me, unfortunately ...)

Thanks, Andy for your uninvited response. Probably the best
description of Zope I've seen so far.

> So, does Zope run when the URL is clicked and serve the HTML (like
> CGI?) or does it generate the HTML page before hand and it just get served
> "real time".

It *is* a CGI script. In fact its preferred use is to run alongside
the web server as a long running process (LRP). It has an event-loop
just as an ordinary application.


> I think, and this is just off the cuff, that my problem with the
> license, be it the former OR latter, is the fact that the USER now
> has a license issue to deal  with.  I think (again, on the fly) that
> there should be no extra licensing worries for the user.  They
> shouldn't *have* to look at the license of every package, the first
> time they use it, to determine if there are any "extra" restrictions
> that they have to comply with and we don't have (AFAIK) any way to
> inform the user that I would consider adequate.  (ie, they might not see
> messages via dselect/dpkg if a sysadmin installs it for them.  They
> might not see the description if they install via apt... etc)

You're certainly right, but this is in fact a problem with the notice
clause in your drafts.

You mean USER in contrast to DEVELOPER ? This distinction is a little
bit deliberate with free software IMHO, since we do educate the users
that they have the right to modify the software.

Imagine you have an GUI application. According to your draft, the
application's license could carry a requirement that however you
modify the application, you had to include credits to the original
author in the start window.

Now imagine the application came with an library. Could this
requirement also apply to the library ? I.e. could the license require 
that I have to credit the author of the library in any application
that used the library ? I guess we won't call that DFSG free.

But now what if I would take the original, DFSG free application with
the notice requirement, moved the biggest part of it in a library (I'm
certainly allowed to do that according to the DFSG) and used that
library in my own application. According to the DFSG, this modified
library would be free of notice requirements, but then this is
certainly not what the author of the application wanted.

I don't see the borderline between restrictions on the USER (which you 
don't like) and restrictions on the DEVELOPER (which you seem to
tolerate).


Gregor

Re: Revision 4 of DFSG

[Gregor Hoffleit]

Now for something different:

> 4.5. Example Licenses 
> --
> 
>  As examples, we consider the following licenses DFSG-free: 
> 
> * the Artistic License 
> 
> * the BSD License 
> 
> * the MIT/X Consortium License 
> 
> * the GNU General Public License (GPL) 
> 
> * the GNU Library General Public License (LGPL) 
> 
> * the Mozilla Public License (MPL) 
> 
> * the Q Public License (QPL)
> 
>released, the list would be modified to mention the licenses that
>  truly do fit> 


www.gnu.org has an RMS article about the evil BSD advertisment
clause. IIRC, he referred to the XFree86 license as an truly free
license, while the old BSD license with the advertisment clause was
depreciated. His reasonsing was that one should avoid the terms
"BSD-like license" and instead use XFree86 as an example, since some
BSD licenses are evil.

I guess the same reasoning holds for the X Consortium License (or how
did they call this evil, new license for X11R6.4 ?).

Perhaps we could mention this problem with the advertisment clause
here, and add XFree86 to the list ? There were no problems with any
XFree86 license, so it's reasonable to say that the XFree86 license is 
a good template for a free license.

Gregor

Re: Zope license

[Gregor Hoffleit]

If you want to now what this talk is all about, I have put a
preliminary Zope package on
http://master.debian.org/~flight/zope/. The dependencies are not yet
in place (you need python-base, python-pcgi and a few other python-*
packages), the Debian instructions are very rough, but you might get
it up and working.

Gregor

Re: DFSG v2 Draft #5

[Gregor Hoffleit]

On Mon, Jan 25, 1999 at 08:48:36AM -0500, Raul Miller wrote:
> Darren Benham <[EMAIL PROTECTED]> wrote:
> > 3.1. Notices of Authorship 
> > ---
> >  The license may require the copyright, license, and any associated
> >  disclaimers be prominently displayed in the modified software or any
> >  derived software. The license may require such notices to be
> >  displayed: (in order of preference) 
> > 
> > * wherever the modified/derived software displays copyrights
> > 
> > * in the source code or documentation
> > 
> > * in advertising materials (deprecated)
> > 
> >  
> > 
> >   >  current licenses?>
> 
> This seems to imply that the emacs license can't prohibit someone
> from removing its copyright display at load time.  [Because that's
> where the >>unmodified<< software displays copyrights.]

Umm, upon re-reading the GPL, I get a little bit sceptical about this
section 3.1. If I want to modify a GPLed work, the GPL makes the following
restriction:

  "2. You may modify your copy or copies of the Program or any portion
  of it, thus forming a work based on the Program, and copy and
  distribute such modifications or work under the terms of Section 1
  above, provided that you also meet all of these conditions:"

  ...
  
  "c) If the modified program normally reads commands interactively
  when run, you must cause it, when started running for such
  interactive use in the most ordinary way, to print or display an
  announcement including an appropriate copyright notice and a
  notice that there is no warranty (or else, saying that
  you provide a warranty) and that users may redistribute the
  program under these conditions, and telling the user how to
  view a copy of this License.  (Exception: if the Program itself
  is interactive but does not normally print such an announcement, 
  your work based on the Program is not required to print
  an announcement.)"

Furthermore, the appendix "How to Apply These Terms to Your New Programs"
says:

  "If the program is interactive, make it output a short notice like this
  when it starts in an interactive mode:

  Gnomovision version 69, Copyright (C) 19yy name of author
  Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type
  `show w'. This is free software, and you are welcome to redistribute
  it under certain conditions; type `show c' for details.


IMHO this restriction is much stronger than what 3.1 allows ("The license
may require such notices to be displayed: ... wherever the modified/derived 
software displays copyrights"). In the above example, the GPL would forbid
to remove the copyright notice that's displayed after executing the
program, while the proposed 3.1 would require that I have the right to do
this.

IMHO this makes the GPL non-free.


On a separate note, since this started the discussion about this point,
(I must sound like an advocatus diaboli ;-): What happened if the Zope
people would replace their "attribution button" with a copyright notice,
and modified Zope so that this notice (e.g. "Zope Copyright (C) 1999
Digital Creations, www.zope.org") would be displayed on the first page of
every session ? Couldn't they use a similar clause like the GPL to 
reject any modification of Zope that would remove this copyright notice ?
Zope is certainly a program that "reads commands interactively when run",
so they could mostly copy this requirement from the GPL.


Gregor

Vacation for one week

[Gregor Hoffleit]

Hi, 

I'm going on vacation tomorrow until May 27. Going with a nice Python
tradition, my last action is an upload of a new revision of the Python
packages (although I didn't manage to finish the Zope packages right
in time ;-). Please feel free to make non-maintainer uploads if any
serious problems should show up.

Gregor

Re: extipl, mbr--why? (was: GRUB)

[Gregor Hoffleit]

On Wed, Sep 15, 1999 at 10:34:24AM +0100, Philip Hands wrote:
> To stop the annoying FAQ:
> --
>   Subject: ARRGGH!!!  HOW DO I GET RID OF LINUS!

Who wants to do that ? You're silly.

Gregor



pgpEuV2qYtWHB.pgp
Description: PGP signature

BTS question: How to "forward" to an upstream BTS like jitterbug ?

[Gregor Hoffleit]

We're supposed to record if we forward a bug report to the developer of the
upstream source package. The BTS assumes that the upstream developer has a
mail address to which the report is forwarded, and the BTS somehow relies on
this address.

Now what if the upstream developer expects bug reports in a web-driven BTS
like Jitterbug ? How can I record in the BTS that I have submitted the
report into the upstream BTS ?

Gregor



pgpx93ByieGWN.pgp
Description: PGP signature

RFP/ITP: MasqMail

[Gregor Hoffleit]

MasqMail (http://merlin.uni-sw.gwdg.de/~okurth/masqmail/) is a free MTA
targetted at small networks/single hosts without a permanent internet
connection:

   "MasqMail is a mail server designed for hosts that do not have a
   permanent internet connection eg. a home network or a single host at
   home. It has special support for connections to different ISPs. It
   replaces sendmail or other MTAs such as qmail or exim.

   MasqMail is released under the GPL license."

MasqMail is in a early stage, still already usable. It could use a security
auditing, but since by definition it should only be used on leaf node hosts
without permanent internet connection and since it doesn't listen to any
port, that should be no critical concern.

If somebody would like to take the package, please go on. I guess I'll use
it for myself, therefore I'll step in when nobody else takes it.

Gregor



pgpKVLqhuPgzJ.pgp
Description: PGP signature