Re: Ubuntu and its "appropriation" of Debian maintainers

[Martin Schulze]

Matt Zimmerman wrote:
> Another option would be to leave the source package maintainer the same (to
> retain proper credit, etc.), but override the binary package maintainer
> during the build (to reflect that it is a different build, and also display
> a more appropriate name in "apt-cache show" etc.).
> 
> What do you think about this approach?

With proper changelog entries (as usual) should be fine as well.

Regards,

Joey

-- 
If nothing changes, everything will remain the same.  -- Barne's Law


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

Re: Derived distributions and the Maintainer: field

[David Schmitt]

On Friday 06 May 2005 02:54, Matt Zimmerman wrote:
[ thanks for this summary ]
> Given the above, the relevant questions would seem to be:
>
>   If a binary package is built by a third party from unmodified Debian
>   sources, should its Maintainer field be kept the same as the source
>   package, or set to the name and address of the third party?
>
>   Should Debian-derived distributions change the Maintainer field in source
>   packages which are modified relative to Debian?  If so, should this be
>   done in all cases, or only if the modifications are non-trivial?
>
> I am interested in responses to these two questions from the Debian
> community.

To add a bit more analysis: The four important positions when releasing a 
package are:

1) upstream: She who maintains the software being packaged
2) maintainer: She who maintains the packaging of this software
3) latest-modifier: She who has touched the Debian diff last
4) builder: She who built this binary package

1) is found in the debian/copyright, 2) is the Maintainer:, 3) can be found in 
the debian/changelog and 4) is typically the signator of the .changes file. 

Since for many of Debians used packages 2)-4) are the same person, reporting 
bugs to the BTS is a good way to reach the right person for whatever problem 
the user has, while it probably be proper to report the bug to 4) or 3) 
(depending on the problem) - especially when they're not in the same 
organisation as 2). This is parallel to encouraging users to report _any_ bug 
in Debian first to Debians BTS instead of bothering 1) before verifying that 
the problem exists there too.

(bin)NMUs are another area where 3) and 4) should be kept in the loop.


Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir Ãber ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Is Petr Cech MIA?

[Petr Cech]

On Thu, May 05, 2005 at 10:38:39PM +0200 , Jeroen van Wolffelaar wrote:
> On Thu, May 05, 2005 at 11:23:51PM +0300, Lior Kaplan wrote:
> > The NMU is very simple... I don't have a problem with doing it myself in
> > a week or two.
> > 
> > Just try to catch Petr first.
> 

Hi,

> Eh, (1) there is a standing 0-day NMU policy for very long already (at
> least half a year, don't remember even), (2) two weeks definitely is too
> late, I suggest NMU'ing ASAP, (3) no need to start the "MIA procedure"
> thingy when just doing a NMU, everyone gets busy once in a while, a NMU
> is not a bad thingy, just an attempt to help out a maintainer who
> otherwise apparantly couldn't find the time to fix a particular issue.
> As #288741 is 120 days old without maintainer reaction, there was

I sent a ITO last july and I thought that it took someone. There were some
license problems IIRC, but it seems it's solved now.

As it seems that soneone has yesterday orphaned phpdoc for me (wtf?) I don't
have to do it myself :-) Anyone is welcome to take over maintaining phpdoc

Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

Try: cat /dev/urandom | perl


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

Re: Is Petr Cech MIA?

[Ondrej Sury]

Hi,

just send him SMS.  Most prolly he is very busy due to his job.

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


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

Stateless Debian Project

[linux romeo]

Hi,

We have just initiated  Stateless Debian Project and we are looking
for active volunteers/developers
Detail of project are  given below 
Summary
This project was started by Fedora (Redhat) but is no longer in active
development and  will  not be included in next release of fc4 , this
projects aims to provide longterm commitment to the concept & port it
to 100% community based distro like Debian

Stateless Linux  converts normal Linux desktop/clients to Stateless
machines or appliances, which means if throw your computer out of
window you still will be able to get exactly same same settings/data
when you log from any other pc in the network A single
administrator can easily manage network  thousands of desktops
...Stateless Linux centralizes the state in a Gold server (different
from CFengine) and  rest  of clients are updated regularly from it .
This is different from thin clients as local processing power and
memory of clients is used (or cached client)

http://sourceforge.net/projects/statelessdebian/
Project Goals

1) Port relevant parts of RH State Linux
(http://fedora.redhat.com/projects/stateless/) to Debian
2)Extend/integrate/enhance Stateless Linux thru existing projects like  DBRL
http://drbl.sourceforge.net/debian/wiki-view/pmwiki-view.php/DRBL/WhatIsDRBL
 
and Debian CCD infrastructure, FAI (Fully Automated
Installation,http://www.informatik.uni-koeln.de/fai/)
3) Add cluster support and node monitoring and autonomic capabilities 
4)Meets most of OSDL Desktop Linux specification
5) Long term community based , vendor neutral project
6) Member of "Move 2 Debian" project
7) Latter (2nd phase )Add p2p support for directory support(DHT), file
storage and retrieval(tuples), state transfer (Bittorent) to elinimate
any need of centralized servers/infrastructure and make it highly
scalable (to millions!!)


Right now this project is in pre beta stage and we are preparing
Stateless Linux White paper and started porting portions of RH
Stateless Linux to Debian .
Any  Suggestions/Ideas will appreciated :-) ..if anyone is interested
from this  list then pl let me know
Regards,
Gaurav

Re: Derived distributions and the Maintainer: field

[Frank Lichtenheld]

On Thu, May 05, 2005 at 05:54:01PM -0700, Matt Zimmerman wrote:
> 1. Most of the source packages in Ubuntu are inherited from Debian
>unchanged (example: tetex-base).
> 
> 2. Some source packages in Ubuntu are modified relative to Debian.  These
>are assigned a version number of the form
>"ubuntu".  Of those which
>are modified, in most cases the modifications are trivial, such as a
>library transition, Python transition or other dependency change
> 
> 3. A small number of packages are created specifically for Ubuntu.  These
>are assigned standard version numbers.  Of those, some have already been
>adopted by Debian (example: pmount), some are expected to be adopted by
>Debian at some point in the future (example: xorg), and some are not
>expected to be used in a Debian context (example: ubuntu-artwork).
> 
> Currently, only packages in category "3" are assigned a Maintainer field
> by Ubuntu.  The question has been raised about what should be done about
> packages in categories "1" and "2".

Actually a good first step would to be able to differentiate automatically
between packages in categories "1" and "3". AFAICT this isn't currently
possible (category "2" can be detected by the version number). This
would enable front-ends (like packages.ubuntu.com) to change the displayed
information depdending on a package's categorization.

Perhaps add a "Origin: ubuntu" or something similar for categorie "3"
in Sources files?

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Three way link exchange with your-legal-advice.co.uk

[James Wilson]

Hi

I'm offering a link from our directory at http://www.studio-103.co.uk 
on the most relevant page in exchange for links from your page at 
www.your-legal-advice.co.uk/mortgagelegaladvice and/or any other sites 
or pages that you may run and be relevant, to 
http://www.mortgagesforbusiness.co.uk.

3 way link exchanges like this are more effective for boosting search 
positions than straight reciprocal linking, so this should be mutually 
beneficial.  If you can provide more than one link we can give you 
featured listings on our directory and also consider it for inclusion 
in another directory.

Hope this is of interest to you and look forward to your response.  
Please feel free to send me any preferred link text and URLs, and where 
our URL will be featured.

I'll include some variations of our link details at the bottom of the 
email.  Please choose whichever you like.

Take care

James

--

URL:  http://www.mortgagesforbusiness.co.uk
Title: Buy to let mortgages
Description:  Excellent rates on buy to let mortgages

--

URL:  http://www.mortgagesforbusiness.co.uk
Title: Commercial Mortgages
Description:  Commercial property finance and mortgages


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

Re: Status of PHP5?

[Martin Geisler]

Andres Salomon <[EMAIL PROTECTED]> writes:

> On Tue, 26 Apr 2005 10:56:52 +0200, Martin Geisler wrote:
> 
>> * Do the PHP4 maintainers find PHP5 too buggy for inclusion in
>>   Debian?
>
> Yes.  Hell, I consider php4 too buggy for Debian.  php5 is even
> worse.  Have you seen the changelog[0]?  These are not minor little
> bugs that are being fixed...

No, I agree that PHP (both version 4 and 5) are far from frozen and
still receive lots of updates, as the ChangeLog clearly shows.

But does that mean that Debian Stable cannot carry a project like PHP
which is still undergoing heavy development?  Or will backports.org be
the home of such projects?

> The proper place for php5 right now (imo) is in experimental.  I
> don't speak for any of the other php maintainers, of course; but
> personally if feel it's a waste of time to deal w/ it right now,
> time that could be better spent fixing other bugs in Debian.

Yes, now it's too late, and I still feel that it is a shame.

> [0] http://www.php.net/ChangeLog-5.php#5.0.4


-- 
Martin Geisler GnuPG Key: 0x7E45DD38

PHP EXIF Library  |  PHP Weather |  PHP Shell
http://pel.sf.net/|  http://phpweather.net/  |  http://mgeisler.net/
Read/write EXIF data  |  Show current weather|  A shell in a browser


pgpviCl014sYG.pgp
Description: PGP signature

Stateless Debian Project

[gaurav p]

Hi,



We have just initiated  Stateless Debian Project and we are looking for 
active volunteers/developers

Detail of project are  given below  


Summary

This project was started by Fedora (Redhat) but is no longer in active 
development and  will  not be included in next release of fc4 , this 
projects aims to provide longterm commitment to the concept & port it to 
100% community based distro like Debian



Stateless Linux  converts normal Linux desktop/clients to Stateless 
machines or appliances, which means if throw your computer out of window 
you still will be able to get exactly same same settings/data when you log 
from any other pc in the network A single administrator can easily 
manage network  thousands of desktops ...Stateless Linux centralizes the 
state in a Gold server (different from CFengine) and  rest  of clients 
are updated regularly from it . This is different from thin clients as 
local processing power and memory of clients is used (or cached client)



http://sourceforge.net/projects/statelessdebian/

Project Goals



1) Port relevant parts of RH State Linux (http://fedora.redhat.com/projects/stateless/) to Debian

2)Extend/integrate/enhance Stateless Linux thru existing projects like  DBRL

http://drbl.sourceforge.net/debian/wiki-view/pmwiki-view.php/DRBL/WhatIsDRBL  


and Debian CCD infrastructure, FAI (Fully Automated Installation,http://www.informatik.uni-koeln.de/fai/) 
3) Add cluster support and node monitoring and autonomic capabilities 
4)Meets most of OSDL Desktop Linux specification

5) Long term community based , vendor neutral project

6) Member of "Move 2 Debian" project

7) Latter (2nd phase )Add p2p support for directory support(DHT),
file storage and retrieval(tuples), state transfer (Bittorent) to
elinimate any need of centralized servers/infrastructure and make it
highly scalable (to millions!!)





Right now this project is in pre beta stage and we are preparing
Stateless Linux White paper and started porting portions of RH
Stateless Linux to Debian .

Any  Suggestions/Ideas will appreciated  :-)  ..if anyone is interested from this  list then pl let me know 


Regards,

Gaurav 

Re: Questions about apt-get upgrade/install semantic

[Martin Braure de Calignon]

Daniel J. Axtens a écrit :

>>and not
>>"apt-get upgrade "
>>
>>
>
>Possibly because apt-get upgrade is used to upgrade the whole system,
>not just one package. My guess is that the developers didn't want to
>overload the upgrade command.
>
>HTH,
>Daniel
>
>  
>
Yes, ok for that. But when I want to upgrade a package, it is not really
logical to use "install", because the package is already installed, no ?

-- 
Martin Braure de Calignon
"Debian addict, active member of Amaya (Amayita)'s fan club (and fan of her 
tatoo)"


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

Re: Is Petr Cech MIA?

[Lior Kaplan]

Hi Petr,

It's good to hear from you (I've been looking for a while).

I orphaned your package (sorry for that). Since it was done in the wrong
way - Jeroen closed it. Please orphan it yourself. Thanks.


Any chance you'll at least fix the rc bug so phpdoc will enter sarge?
It's a very small fix to the build-dep line.


Petr Cech wrote:

>On Thu, May 05, 2005 at 10:38:39PM +0200 , Jeroen van Wolffelaar wrote:
>  
>
>>On Thu, May 05, 2005 at 11:23:51PM +0300, Lior Kaplan wrote:
>>
>>
>>>The NMU is very simple... I don't have a problem with doing it myself in
>>>a week or two.
>>>
>>>Just try to catch Petr first.
>>>  
>>>
>
>Hi,
>
>  
>
>>Eh, (1) there is a standing 0-day NMU policy for very long already (at
>>least half a year, don't remember even), (2) two weeks definitely is too
>>late, I suggest NMU'ing ASAP, (3) no need to start the "MIA procedure"
>>thingy when just doing a NMU, everyone gets busy once in a while, a NMU
>>is not a bad thingy, just an attempt to help out a maintainer who
>>otherwise apparantly couldn't find the time to fix a particular issue.
>>As #288741 is 120 days old without maintainer reaction, there was
>>
>>
>
>I sent a ITO last july and I thought that it took someone. There were some
>license problems IIRC, but it seems it's solved now.
>
>As it seems that soneone has yesterday orphaned phpdoc for me (wtf?) I don't
>have to do it myself :-) Anyone is welcome to take over maintaining phpdoc
>
>   Petr Cech
>  
>


-- 

Regards, 

Lior Kaplan
[EMAIL PROTECTED]
http://www.Guides.co.il

Debian GNU/Linux unstable (SID)


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

Re: Questions about apt-get upgrade/install semantic

[Guido Heumann]

Martin Braure de Calignon schrieb:
> Daniel J. Axtens a écrit :
> 
> 
>>>and not
>>>"apt-get upgrade "
>>>   
>>>
>>
>>Possibly because apt-get upgrade is used to upgrade the whole system,
>>not just one package. My guess is that the developers didn't want to
>>overload the upgrade command.
>>
>>HTH,
>>Daniel
>>
>> 
>>
> 
> Yes, ok for that. But when I want to upgrade a package, it is not really
> logical to use "install", because the package is already installed, no ?
> 

If you think of "upgrading" as "installing the newest version" of a
package, then it becomes more logical IMO. You can specify the version
number of a package to be installed with "apt-get install
package=version", and without explicit version argument it's simply the
default behaviour to install the newest version.

HTH,
Guido


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

Re: Stateless Debian Project

[Christoph Berg]

Re: gaurav p in <[EMAIL PROTECTED]>
> We have just initiated Stateless Debian Project and we are looking for 

Is the project itself also stateless such that it doesn't know whether
it already sent out an announcement?

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


signature.asc
Description: Digital signature

Re: Questions about apt-get upgrade/install semantic

[Martin Braure de Calignon]

Guido Heumann a écrit :

>Martin Braure de Calignon schrieb:
>  
>
>>Daniel J. Axtens a écrit :
>>
>>
>>
>>
and not
"apt-get upgrade "
  



>>>Possibly because apt-get upgrade is used to upgrade the whole system,
>>>not just one package. My guess is that the developers didn't want to
>>>overload the upgrade command.
>>>
>>>HTH,
>>>Daniel
>>>
>>>
>>>
>>>  
>>>
>>Yes, ok for that. But when I want to upgrade a package, it is not really
>>logical to use "install", because the package is already installed, no ?
>>
>>
>>
>
>If you think of "upgrading" as "installing the newest version" of a
>package, then it becomes more logical IMO. You can specify the version
>number of a package to be installed with "apt-get install
>package=version", and without explicit version argument it's simply the
>default behaviour to install the newest version.
>
>HTH,
>Guido
>
>
>  
>
If it is the default behaviour of "apt-get install" (and it is), it
should be mentionned in the man, or be mentionned more explicitly. I've
just seen that there is already a bug report about this feature for
upgrade (see #74067).

Cheers,

-- 
Martin Braure de Calignon
"Debian addict, active member of Amaya (Amayita)'s fan club (and fan of her 
tatoo)"


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

Re: Stateless Debian Project

[gaurav p]

On 5/6/05, Christoph Berg <[EMAIL PROTECTED]> wrote:
Re: gaurav p in <[EMAIL PROTECTED]
>> We have just initiated Stateless Debian Project and we are looking for

its Stateless project by State full people ;-) 


Is the project itself also stateless such that it doesn't know whetherit already sent out an announcement?


oops !..sorry ... must due to  announcement mail did'nt reflect in mailing list for long time 

Re: debian sarge is 3.2 or 4 ?

[David Nusinow]

On Fri, May 06, 2005 at 08:15:13AM +0200, Marc Haber wrote:
> On Thu, 5 May 2005 10:30:36 -0400 (EDT), "Jaldhar H. Vyas"
> <[EMAIL PROTECTED]> wrote:
> >On Thu, 5 May 2005, Andrea Mennucc wrote:
> >> I dont see it as a big stopper. You are saying that the number "3.1"
> >> appears /etc/debian_version (that lives in package "base-files")
> >> and in 3 documents (and translations).
> >
> >...and Debian 3.1 Bible whose publisher will be highly annoyed if they are
> >forced to change the title and all references just as they are about to
> >print.
> 
> Their fault for releasing a book about unreleased software which is
> bound to be outdated the day that sarge will actually release.

A lot of users request just such a book. It's been years since we had one,
and it's been sorely missed by a lot of new users.

 - David Nusinow


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

Re: Questions about apt-get upgrade/install semantic

[Daniel Burrows]

On Friday 06 May 2005 06:04 am, Martin Braure de Calignon wrote:
> Yes, ok for that. But when I want to upgrade a package, it is not really
> logical to use "install", because the package is already installed, no ?

  Yes.

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|   "But what *does* kill me bloody well leaves me dead!"   |
| -- Terry Pratchett, _Carpe Jugulum_   |
\--- News without the $$ -- National Public Radio -- http://www.npr.org ---/


pgpqTYDlXxvr4.pgp
Description: PGP signature

Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()

[Raul Miller]

On 5/5/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> Sorry to spam debian-devel -- and with a long message containing long
> paragraphs too, horrors! -- in replying to this.

Who is sorry?  How sorry?  

Let's assume, for the sake of argument, that this sorry-ness is not 
something that matters enough to you to avoid posting long and 
elliptical messages to debian-devel.

> > On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote:
> > The GPL simply defers to copyright law to define "derivative work".

> Actually, it tries to define "work based on the Program" in terms of
> "derivative work under copyright law", and then incorrectly
> paraphrases that definition.

It's probably worth noting that "derivative work" and "work based on the 
Program" are spelled differently.  What's not clear, to me, is whether the 
word "that" refers to the "d" phrase or the "w" phrase.  Careful study sheds 
no insight into this burning issue.

[If I read the GPL, I can't find where it paraphrases the "d" phrase.  On the
other hand I can't figure out how someone could claim that the GPL
incorrectly paraphrases the "w" phrase.]

> There has been so much silliness written about this topic ...

Agreed.

-- 
Raul

Re: GPL and linking

[Humberto Massa]

Raul Miller wrote:
> Actually, it tries to define "work based on the Program" in terms
> of "derivative work under copyright law", and then incorrectly
> paraphrases that definition.
 It's probably worth noting that "derivative work" and "work based on
 the Program" are spelled differently.  What's not clear, to me, is
 whether the word "that" refers to the "d" phrase or the "w" phrase.
 Careful study sheds no insight into this burning issue.
??? Let's try again: '' The GPL tries to define "work based on the 
Program" in terms of "derivative work under copyright law", and then, 
after this definition and a colon, it tries to explain what is a 
"derivative work under copyright law", but gives a wrong explanation, 
which would remain wrong even if only USC 17 was considered as a global 
copyright law. ''

See? The GPL says, in its section 0, caput, with [] braces mine:
''a "work based on the Program" means either the Program or any 
derivative work under copyright law [definition #1]: that is to say, a 
work containing the Program or a portion of it, either verbatim or with 
modifications and/or translated into another language [explanation, #2].''

I don't know if the meaning of "paraphrase" is the same in English as 
its Portuguese cognate, so maybe the misuse of this word is the only 
error in his analysis...

 [If I read the GPL, I can't find where it paraphrases the "d" phrase.
 On the other hand I can't figure out how someone could claim that
 the GPL incorrectly paraphrases the "w" phrase.]
> There has been so much silliness written about this topic ...
 Agreed.

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

Bug Squashing: List of remaining FTBFS bugs for amd64/sarge

[Andreas Jochens]

On 05-May-06 00:24, Steve Langasek wrote:
> On Fri, May 06, 2005 at 08:58:27AM +0200, Andreas Jochens wrote:
> A few things you might want to do with this list here:
...
> - post it to debian-devel so people can poke through these for the BSP this
>   weekend

The new list of FTBFS bugs will still not be perfect, but here it is.

Thank you to everyone who helped to fix some of the bugs from the 
previous version of this list.


Packages from sarge with build problems on amd64


There are still a few packages in sarge which fail to build on amd64.

Those packages and all their dependencies will be removed from the 
amd64 sarge release unless the problems are fixed and the fixed
version gets accepted into sarge by the release team. (For a very 
limited number of release critical packages, like debian-installer, the 
amd64 porting team may decide to make an exception to this rule and use 
a package version with a minimal patch to make the release possible.)

Please note that many of the problems listed below also occur on 
other architecures.

A '+' after the BTS bug number indicates that a patch is available 
which fixes the problem. A '*' after the BTS bug number indicates 
that there is a fixed version available in the 'unstable' distribution.

Any fixes for the listed bugs and any information regarding the status 
of the bugs will be highly appreciated. 

Especially the packages listed with a proper bug number and a patch 
sign ('+') may be candidates for the Bug Squashing Party this weekend.


Release critical bugs for amd64:

sarge/main/amd64 BTS Bug   Problem description
 ---   ---
debian-installer #306976+  libdevmapper1.00 does not exist (should be 1.01)
debian-installer #307306+  Uses kernel 2.6.10 which is not in sarge
syslinux #306123+  amd64 missing from architecture list and FTBFS


FTBFS bugs for amd64 which have been fixed in sid but not in sarge:

hfsutils #280310*  missing '#include '
krb4 #175491*  configure does not define HAVE_H_ERRNO
libglademm2.0#279985*  "$LD" vs. $LD in configure
libhdf4  #251275*  missing amd64 support in hdf/src/hdfi.h
lvm2 #298762*  "device/dev-io.c:342:3: #error miss O_NOATIME"
radiusd-livingst #273629*  missing '#include '


Other FTBFS bugs for sarge/main/amd64:

advi #307919+  missing Build-Depends on groff-base
amsynth  #274703+  missing '#include ' in main.cc
armagetron   - dh_installchangelogs: command returned error code 11
atari-fdisk  #248794+  amd64 not in architecture list
binutils-h8300-h #251648+  machine `x86_64-pc' not recognized
cbmlink  #207003+  uses i386 specific code
cdrdao   #249634+  x86_64-linux-{cc,gcc}.rul links missing
cfdisk-utf8  #249926+  missing 'defined(__x86_64__)' / not in Arch list
commons-daemon   #  +  x86_64 support missing in Makedefs and configure
elk  -  +  needs workaround for ICE with gcc-3.3
freewnn  #142253+  segfaults during build (same as on ia64 #229390)
ghdl #276399   ghdl internal compiler error: Segmentation fault
guile-core   #255894+  amd64 missing in UNSUPPORTED_QTHREAD_ARCHS
guile-gnome-plat #304936+  "comparison always false due to limited range..."
heaplayers   - "*** [allocators] Error 1"
ircd-ircu#254165+  configure check for res_mkquery fails
k3d  #278966   compilation of expression.cpp does not finish
kmatplot #286533+  missing -fPIC
libgtk-java  -  +  java.*.NullPointerException/builds without-javadoc
libnss-pgsql #273800+  should use pthread_mutex_t instead of libc_lock_t
libooc-vo#164726   "*** [EMAIL PROTECTED]@] Error 1"
libpolyxmass #303856+  passing arg 5 of `bsearch' from incompatible pointer
licq -  +  undefined reference to pthread_kill_other_threads_np
linux86  #260647+  elksemu's file format not recognized
lxdoom   #279190+  missing '#include '
masqmail #254720+  configure check for res_search in -lresolv fails
mindi-  +  missing amd64 in architecture list
mn-fit   #301509   segmentation fault on 64bit architectures
mondo-  +  missing amd64 in architecture list
mtr  #254089+  configure check for res_mkquery broken
muddleftpd   #253618   missing -fPIC
mypasswordsafe   #307316+  FTBFS if USER environment variable is not set
nntp #280278+  missing '#include '
octave-gpc   #307188*  no match for 'operator[]' in '*m["vertices"]'
octaviz  #302688+  cast from 'vtkObjectBase*' to 'int' loses precision
ogre - "no matching function for call to ..."
oleo #287854+  missing '#include '
oo2c #251577+  missing 64bit-arch handling in debian/rules
perlipq  #278944   links against non-fPIC libipq.a from iptables
pike

Re: debian sarge is 3.2 or 4 ?

[Jaldhar H. Vyas]

On Fri, 6 May 2005, Marc Haber wrote:

> Their fault for releasing a book about unreleased software which is
> bound to be outdated the day that sarge will actually release.

Uh-uh and when will that day be?  And don't give me any of that "when it
is ready" nonsense.  The release version number was ready a long time ago.
The problem isn't a concern for quality, it is people like you and Andrea
who don't follow process, who don't contribute when the actual decisions
are being made, but who come out of the woodwork at the last minute with
dumb attempts at tinkering.  That's why Debian has found it so hard to
release.

A book is just a minor example.  Do you think the CTO of a Debian-using
enterprise will just be reading slashdot at breakfast one day, see "oh
sarge has released" and do a dist-upgrade when he comes into the office?
People plan weeks if not months in advance for this sort of thing.  If
Debian is to be so unreliable, we cannot give even basic assurances about
our next release, we have doomed ourselves for _any_ kind of serious use.

Luckily I don't think most of our fellow DDs are as lackadaisical as you
are making yourself out to be.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/


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

Re: debian sarge is 3.2 or 4 ?

[Marc Haber]

On Fri, 6 May 2005 13:54:29 -0400 (EDT), "Jaldhar H. Vyas"
<[EMAIL PROTECTED]> wrote:
>The problem isn't a concern for quality, it is people like you and Andrea
>who don't follow process, who don't contribute when the actual decisions
>are being made, but who come out of the woodwork at the last minute with
>dumb attempts at tinkering. 

The actual decisions are made in the background without even trying to
talk to the body of developers. For example, the exim 4 maintainers
were not even contacted by whoever made the decision to move the
"default MTA" property from exim to exim4. We just found our package
to be at "important" priority some day.

Things like these demotivate people from trying to participate with
_any_ decision.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

5 Minutes of Sperancy

[felixproject]

Scusa il disturbo Gentile Utente del Web,
Excuse the trouble Nice Users of the Web

Un euro per un mattone! Aiutaci a costruire il canile!
One Dollar for a brick! Help to build the kennel!

Vogliamo lanciare un appello a tutti coloro che vorranno aiutarci nell'impresa 
per cui ci battiamo da quando la nostra Associazione 
è stata fondata: avere una struttura che possa ospitare i nostri adorati 
cuccioli, decorosamente.
Want launch an appeal to all those people that they will want help in the 
enterprise for which beat since our Association 
has been well-grounded:  have a structure that is able entertain the our adored 
pups, decently.

Ciò allo stato attuale è molto difficile in quanto la strutura dove dovrebbe 
sorgere la costruzione del canile è in rovinose condizioni,
e nonostante lo sforzo affrontato non riusciamo a raggiungere l’obiettivo.
That to the actual state is a lot of difficult in when structures it where it 
has to rise the construction of the kennel 
is in ruinous conditions, and in spite of the faced effort not succeed to reach 
the objectify.

La nostra Associazione ha lo scopo di combattere il randagismo, di diffondere 
il messaggio di amore e solidarietà verso gli animali, 
aiutare i rifugi che accolgono i cani e gatti abbandonati, ma deve essere anche 
in grado di poter affrontare situazioni a volte 
disperate in cui spesso ci troviamo per poter fornire un pronto intervento che 
può nella maggior parte dei casi salvare 
la vita dei nostri amici,purtroppo senza una struttura che possa tecnicamente 
sopperire a tutto ciò 
il nostro sforzo a volte risulta vano.
Our association has the purpose to fight the straying, to diffuse the love 
message and solidarity toward the animals, 
help the shelters that welcome they that they receive the dogs and cats 
abandons to you, but it has to be even in 
degree of can face situations to desperate times when often find to can furnish 
a ready intervention that 
it may in the most of the cases save the life of the our friends, unfortunately 
without a structure that is able 
technically provide to all that our effort to times results vain.

Il nostro progetto è molto difficile da realizzare in quanto non privo di 
ostacoli sia burocratici che puramente economici 
ed è per questo che chiediamo il Vostro aiuto siamo pronti ad affrontare 
qualsiasi difficoltà pur di vedere realizzato 
il sogno per cui ognuno di noi ha lavorato e continua a lavorare: regalare una 
vita migliore senza sofferenze senza crudeltà 
a chi non chiede mai niente ma da tanto in cambio, aiutaci ad aiutarli e a 
diffondere i valori dell’amore, del rispetto e 
della comprensione nei loro riguardi.
Our project is a lot of difficult to realize in when not destitute of hinder it 
is bureaucratic that purely economic and 
it is for this that ask your help is ready to face any difficulty too to see 
carried out the dream 
for which all of us has worked and continues to work: give a better life 
without sufferings without cruelty to anyone 
doesn't never ask anything but from much in change, help to help them and to 
diffuse the values of he is consumed by love, 
of the respect and of the comprehension in the they concern.

Crediamo che anche un piccolo aiuto da parte Vostra possa renderVi felici 
sapendo che avete donato una nuova speranza.
Believe that even a little help from departs yours is able make you happy 
knowing that you have given a new hope.

Visita ail nostro sito all’indirizzo 
http://digilander.libero.it/felixproject/
Visit our site to the address
http://digilander.libero.it/felixproject/

oppure fai un 'offerta
or make a shipment donation

Operazione"Felix" - Casella Postale 17104 RM GROTTAROSSA - ITALY
oppure Conto Corrente nr  :
IBAN :IT51 P030 1503 2000  0074 346
Casuale : "Operazione Felix"

Operation "Felix" - Post office box 17104 RM GROTTAROSSA - ITALY
or Checking Account Bank  nr :
IBAN :IT51 P030 1503 2000  0074 346
BIC bank receiving(swift): BROMITRR
BIC bank beneficiary: FEBIITM1
Accidental of Deposit : "Operation Felix" 



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

Re: Upcoming removals

[Ari Pollak]

Martin Michlmayr wrote:
> #287985: O: cantus -- Gnome tool to mass-rename/tag mp3 and ogg files
> Reported by: Jeroen van Wolffelaar <[EMAIL PROTECTED]>; 123 days old.
> obsoleted by cantus3 which is packaged already

>From what I can tell, cantus3 doesn't actually provide all of the
functionality originally present in cantus.


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

Re: Upcoming removals

[Igor Stroh]

Ari Pollak wrote:
> Martin Michlmayr wrote:
> 
>>#287985: O: cantus -- Gnome tool to mass-rename/tag mp3 and ogg files
>>Reported by: Jeroen van Wolffelaar <[EMAIL PROTECTED]>; 123 days old.
>>obsoleted by cantus3 which is packaged already
> 
> 
>>From what I can tell, cantus3 doesn't actually provide all of the
> functionality originally present in cantus.

And it won't either -- the upstream is unresponsive and seems to
have no interest neither in incorporating bug fixes nor in adding
features which the package formerly claimed to be offering[0].

I'd suggest to remove cantus3 from the archive if it wouldn't
have so many users (according to popcon.d.o) - there are better
tools for GNOME/GTK2 with same or better functionality[1].

[0]: formerly, 'cos I removed them from the long package description
[1]: e.g. tagtool, easytag, exfalso [from quodlibet] etc.

Cheers,
Igor


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

Debian Woody -> Sarge upgrade report

[Roberto C. Sanchez]

Last night (when I should have been working a project for my advanced
algorithms class) I decided it was time to upgrade my personal server
from Woody to Sarge.  I am writing this email im the hopes that the
release team and devs find it helpful and that other users who upgrade
can make use of the information.

In summary, here are the things that I saw:
1. Dependency resolution was spectacular (who would expect less from
Debian?)
2. New config files went OK.
3. Cyrus IMAP (going from cyrus v1.5 to cyrus21) broke very hard
4. sslwrap upgrade completely choked over openssl

In detail:

1.  Nothing more need be said.

2.  The standard yes, no, diff, shell approach could probably use
some tweaking.  What I mean is that with so many config files being
updated, there should be an option to "manually merge now."  This
can be done in one of a couple of ways.  A text editor could be
opened with both the current and proposed config loaded (e.g., vim
and emacs), or a single file could be presented with the diff'd
portions inserted and marked in the complete file (e.g., editors that
only support one open file).  I think that this can be done by
shelling out (with the Z option), but I am never really sure if my
changes will stick.  The option says "shell to examine the situation",
or something to that effect.  There is no indication that if I change
the config, the change will stick.

Also, some packages should adopt the policy of including a "local"
snippet.  What I mean is, for example, with the dhcpd package, or any
package that "requires" a change to the config immediately after
installation.  Simply put, a dhcpd config will always need to be
modified to tell which net, subnet mask, hostnames, MACs, and so on,
it needs to handle.  It is annoying when the messages throughout the
file change and cause the admin to have to intervene in the process
by choosing what to do.  Some packages (e.g., horde2) have a config
in /etc/ with a standard .conf and then somewhere
in the .conf file they source or include a snippet with the local
changes.  I encourage the maintainers of such packages (dhcpd and
ntp, come to mind immediately) to consider this approach.

3.  I really have no idea what happened here.  I carefully followed
the upgrade instructions, but my mailboxes.db ended up corrupted, which
caused the cyrus server to go crazy.  Also, once I got saslauthd to
where it would work correctly, cyrus refused all imap and imaps
connections.  I ended up having to go into /etc/hosts.allow and add
ALL:LOCAL for cyrus to finally accept only local imap connections.
I never figured out how to get it to accept imaps connections without
adding ALL:ALL, which is not an acceptable solution).  About 4 hours
of Google searching yielded no useful information.  I ended up setting
impas to go through sslwrap (as I had for cyrus v1.5), since it would
accept remote connections.  I can't tell if this is a bug or a mis-
configuration on my part.

4.  The upgrade to sslwrap tried to generate an ssl certificate.  For
some reason (I suspect becuase I have created my own CA), openssl
errored out, causing the sslwrap postinst to fail.  This caused me
repreated problems as it would hang up the postinst of other packages.
I finally copied /etc/ssl and /etc/sslwrap off to another location,
purge both openssl and sslwrap, reinstall both, remove /etc/ssl and
 /etc/sslwrap, and replace them with my backup copies.  I am not sure
why this happened, but I am pretty sure it is a bug.  I have not yet
filed a bug since I am not sure if it should go against openssl or
sslwrap.  Sugestions would be appreciated.

-- 
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr


signature.asc
Description: OpenPGP digital signature

Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()

[Michael K. Edwards]

On 5/6/05, Raul Miller <[EMAIL PROTECTED]> wrote:
> On 5/5/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> > Sorry to spam debian-devel -- and with a long message containing long
> > paragraphs too, horrors! -- in replying to this.
> 
> Who is sorry?  How sorry?
> 
> Let's assume, for the sake of argument, that this sorry-ness is not
> something that matters enough to you to avoid posting long and
> elliptical messages to debian-devel.

As I wrote, debian-devel is where the "Urgently need GPL compatible
libsnmp5-dev replacement" discussion is happening.  Andrew's somewhat
disingenuous "This part of the thread belongs on -legal"
notwithstanding, it had not previously been moved to -legal, just
copied there.

I was uncertain whether to remove -devel from my reply, but eventually
decided to leave it as it was; was there some onus on me to remove
-devel?  I am hardly a major source of -devel noise, by message count
or by bandwidth.  But perhaps -devel is reserved for short, erroneous,
discourteous messages?  (That's not really aimed at Raul, actually.)

> > > On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote:
> > > The GPL simply defers to copyright law to define "derivative work".
> 
> > Actually, it tries to define "work based on the Program" in terms of
> > "derivative work under copyright law", and then incorrectly
> > paraphrases that definition.
> 
> It's probably worth noting that "derivative work" and "work based on the
> Program" are spelled differently.  What's not clear, to me, is whether the
> word "that" refers to the "d" phrase or the "w" phrase.  Careful study sheds
> no insight into this burning issue.
> 
> [If I read the GPL, I can't find where it paraphrases the "d" phrase.  On the
> other hand I can't figure out how someone could claim that the GPL
> incorrectly paraphrases the "w" phrase.]

Second sentence in Section 0:  The "Program", below, refers to any
such program or work, and a "work based on the Program" means either
the Program or any derivative work under copyright law: that is to
say, a work containing the Program or a portion of it, either verbatim
or with modifications and/or translated into another language.

As I read it, the phrase after the colon is a paraphrase of the
"ether/or" clause it follows, i. e., an attempt to restate it in
layman's terms.  And it's incorrect, as I explained, and for which I
have previously given references to treaty, several countries'
statutes, and lots of case law, in messages on -legal to which you
responded (generally constructively and courteously, I might add).

Ignoring the actual definintion and taking the paraphrase would mean
that the largest possible "work" containing GPL licensed material
would still be subject to GPL constraints (modulo the "mere
aggregation" clause, which, if it has legal meaning, applies only to
Section 2).  And yes, anything copyrightable under the Berne
Convention is a "work", including (for instance) a Debian CD set. 
That's obviously problematic, it's obviously not what any GPL licensee
believes (GPL section 3 0wns my distro?  yeah, right), and it's
obviously not a reading any court would accept, even absent the rule
of construction against the offeror.

> > There has been so much silliness written about this topic ...
> 
> Agreed.

Lots of sarcasm and cheap shots, too; of which I have sometomes been
guilty as well.  But they do not constitute negative silliness, and
are not something I have associated with your by-line in the past.

Cheers,
- Michael

Re: Debian Woody -> Sarge upgrade report

[Humberto Massa]

Roberto C. Sanchez wrote:

I have made this transition a lot lately, too, and I would like to offer 
some insight about the following process:

2.  The standard yes, no, diff, shell approach could probably use
some tweaking.  What I mean is that with so many config files being
updated, there should be an option to "manually merge now."  This
can be done in one of a couple of ways.  A text editor could be
opened with both the current and proposed config loaded (e.g., vim
and emacs), or a single file could be presented with the diff'd
 

In my experience, I almost always hit D (show differences), select the 
configfile name, :!vimdiff configfile(pasted from clipboard) 
configfile(idem).dpkg-new, do the merging, :diffupdate, :wq, hit D 
again, repeat if not satisfied, and then hit N (keep mine). In a 
woody-to-sarge dist-upgrade, this *really* hurts my wrists.

What I would like is an option A (automerge) that did a 3-way merge of 
configfile and configfile.dpkg-new, open an editor in the conflict 
markers, let you edit the conflicts out, and when you save/exit, showed 
you the differences between your new configfile and configfile.dpkg-new, 
and asked again.

portions inserted and marked in the complete file (e.g., editors that
only support one open file).  I think that this can be done by
shelling out (with the Z option), but I am never really sure if my
changes will stick.  The option says "shell to examine the situation",
or something to that effect.  There is no indication that if I change
the config, the change will stick.
 

Yeah, I feel unsafe, altough I *know* whatever I save in the configfile 
will stick.

Also, some packages should adopt the policy of including a "local"
snippet.  What I mean is, for example, with the dhcpd package, or any
package that "requires" a change to the config immediately after
installation.  Simply put, a dhcpd config will always need to be
modified to tell which net, subnet mask, hostnames, MACs, and so on,
it needs to handle.  It is annoying when the messages throughout the
file change and cause the admin to have to intervene in the process
by choosing what to do.  Some packages (e.g., horde2) have a config
in /etc/ with a standard .conf and then somewhere
in the .conf file they source or include a snippet with the local
changes.  I encourage the maintainers of such packages (dhcpd and
ntp, come to mind immediately) to consider this approach.
 

I really agree with this.

HTH,
Massa

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

Re: GPL and linking

[Jeremy Hankins]

Humberto Massa <[EMAIL PROTECTED]> writes:

> ??? Let's try again:

All of this discussion of legal minutia misses (and perhaps supports)
what, to my mind, is the most compelling argument for accepting the
FSF's position on the subject.  The fact is that the question does
depend on a lot of legal minutia that almost all of us aren't qualified
to have an opinion on.  So unless it's a make-or-break issue for Debian
(which I just don't see), the obvious thing to do is to take the
agreeable, safe position.

So the question of whether or not the FSF is actually *right* doesn't
matter.  We should only disagree with them if we have to for the sake of
Debian -- in which case we're probably in trouble and should hire a
lawyer ASAP.

-- 
Jeremy Hankins <[EMAIL PROTECTED]>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03


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

unsubscribe

[Joe Bowman]

unsubscribe
-- 
Joe Bowman
[EMAIL PROTECTED]


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

Bug#78782: no one knew

[Tony Salinas]

You're Invited

Thanks to a nomination by an associate of yours, there are potentially three 
deals that will be offered to you.

Notice - past credit history is NOT a factor for this promotion as long as we 
recieve word from you within 24 hours. 

In accordance with our terms please verify your information on our secure, 
private site to ensure our records are accurate.

http://www.lendm.com/index.php?refid=windsor

Have a Great Day 

--Tony Salinas
Senior Business Consultant - Low-Rate Advisors Inc.

Did this reach you in error? please let us know...thx
http://www.lendm.com/r.php






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

Re: GPL and linking

[Michael K. Edwards]

On 5/6/05, Jeremy Hankins <[EMAIL PROTECTED]> wrote:
> All of this discussion of legal minutia misses (and perhaps supports)
> what, to my mind, is the most compelling argument for accepting the
> FSF's position on the subject.  The fact is that the question does
> depend on a lot of legal minutia that almost all of us aren't qualified
> to have an opinion on.  So unless it's a make-or-break issue for Debian
> (which I just don't see), the obvious thing to do is to take the
> agreeable, safe position.

You may not be qualified (as I am not) to offer legal advice.  But
you're certainly qualified to have an opinion.  And there isn't
necessarily an "agreeable, safe position".

If your livelihood depends on your continued ability to work in the
software field, I think it helps to have the ability to read deeply
into a contract.  Sometimes that requires a review of the law
applicable to you personally.  I know people who really, really wish
they hadn't accepted EULA X, let alone Shared Source Agreement Y. 
Subtle issues of what constitutes contract acceptance in a given
jurisdiction, whose interpretation of an ambiguity prevails, and what
things can only be agreed to in writing (or can't be made binding at
all) do matter.

My experience with lawyers has been quite positive overall, but I have
learned two cautionary lessons.  One: a lawyer's research is always
focused on either backing or influencing his or her client's position,
and his or her thinking about the arguments on the other side is often
limited to finding counter-arguments for them.  Two: in the absence of
a lawyer who's on your payroll -- not your company's, not your
friend's, not a trusted third party's -- you are your own best legal
researcher.  Actually, the lawyer I respect most says that's true even
when he is on my payroll.  Use the primary literature; it's not really
that hard, though you might have to do a lot of background reading. 
(Same goes for medicine and algorithms, and almost all science that
merits the name.)

> So the question of whether or not the FSF is actually *right* doesn't
> matter.  We should only disagree with them if we have to for the sake of
> Debian -- in which case we're probably in trouble and should hire a
> lawyer ASAP.

The FSF has its own agenda, and it's not principally about keeping
people out of the courtroom.  Many Debian contributors have said that
one recent FSF action or another has seriously damaged their trust in
the FSF as a steward of the portion of the software commons that they
have acquired by copyright assignment, let alone of all software
offered under the GPL.  Note that the FSF is not unique in this
(RedHat, XFree86, and the Mozilla Foundation are other recent
examples), and I still think they're on the side of the angels most of
the time.

Lots of people rely on Debian to have made the most informed judgment
its members can about legal issues.  That doesn't mean just the SPI's
legal counsel, the -legal regulars, or the ftpmasters; that means the
DDs and, to a lesser extent, fellow travelers like me.  Oh, with
respect to Debian as such it doesn't necessarily mean me; IANAL,
TINLA, IANADD, and all that.  But when it comes to other entities that
accept my recommendation of Debian for their IT or product platform,
it's my judgment (among others') that they rely on.  In the primary
literature I trust; all others pay cash.

Cheers,
- Michael

Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()

[Raul Miller]

On 5/6/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> On 5/6/05, Raul Miller <[EMAIL PROTECTED]> wrote:
> > On 5/5/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> > > > On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote:
> > > > The GPL simply defers to copyright law to define "derivative work".
> >
> > > Actually, it tries to define "work based on the Program" in terms of
> > > "derivative work under copyright law", and then incorrectly
> > > paraphrases that definition.
> >
> > It's probably worth noting that "derivative work" and "work based on the
> > Program" are spelled differently.  What's not clear, to me, is whether the
> > word "that" refers to the "d" phrase or the "w" phrase.  Careful study sheds
> > no insight into this burning issue.
> >
> > [If I read the GPL, I can't find where it paraphrases the "d" phrase.  On 
> > the
> > other hand I can't figure out how someone could claim that the GPL
> > incorrectly paraphrases the "w" phrase.]
> 
> Second sentence in Section 0:  The "Program", below, refers to any
> such program or work, and a "work based on the Program" means either
> the Program or any derivative work under copyright law: that is to
> say, a work containing the Program or a portion of it, either verbatim
> or with modifications and/or translated into another language.

I believe you're objecting to the "that is to say" phrase, which restates what
"work based on the Program": means.

> As I read it, the phrase after the colon is a paraphrase of the
> "ether/or" clause it follows, i. e., an attempt to restate it in
> layman's terms.

Yes.  And that "either/or" clause says what "work based on the Program"
means.

> And it's incorrect, as I explained, and for which I
> have previously given references to treaty, several countries'
> statutes, and lots of case law, in messages on -legal to which you
> responded (generally constructively and courteously, I might add).

I disagree:

"work based on the Program" is not the same thing as "derivative work".

The definition of "work based on the Program" uses the "derivative
work" concept, but builds on that concept.

I think claiming they're equivalent is silly.

-- 
Raul

Re: Debian Woody -> Sarge upgrade report

[Steve Greenland]

On 06-May-05, 15:21 (CDT), "Roberto C. Sanchez" <[EMAIL PROTECTED]> wrote: 
> There is no indication that if I change
> the config, the change will stick.

If you shell out, edit /etc/foo.conf to merge the updated from
foo.conf.dpkg-new (or in any other way), then return to the conffile
menu, then select 'N', your changes will be preserved. 


> Simply put, a dhcpd config will always need to be
> modified to tell which net, subnet mask, hostnames, MACs, and so on,
> it needs to handle.  

Policy explicitly says that using the conffile mechanism is
inappropriate for this kind of configuration file. Report a bug. Given
that we have UCF, there's really no excuse for this any more.

Steve




-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: GPL and linking

[Raul Miller]

On 5/6/05, Humberto Massa <[EMAIL PROTECTED]> wrote:
> ??? Let's try again: '' The GPL tries to define "work based on the
> Program" in terms of "derivative work under copyright law", and then,
> after this definition and a colon, it tries to explain what is a
> "derivative work under copyright law", but gives a wrong explanation,
> which would remain wrong even if only USC 17 was considered as a global
> copyright law. ''
> 
> See? The GPL says, in its section 0, caput, with [] braces mine:

Except what you're calling a paraphrase of the "derivative work" concept is a 
restatement of the "work based on the Program" concept.

Then again, other things you say, such as 'The GPL tries to define' shows 
that you're not really interested in talking about what the GPL is or what it's
saying.  The GPL does define "work based on the Program".  There is no 
element of "try" here.  The GPL -- not your email -- is the authoritative 
document about what the GPL does and does not define.

-- 
Raul

Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()

[Michael K. Edwards]

On 5/6/05, Raul Miller <[EMAIL PROTECTED]> wrote:
> On 5/6/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
[snip]
> > Second sentence in Section 0:  The "Program", below, refers to any
> > such program or work, and a "work based on the Program" means either
> > the Program or any derivative work under copyright law: that is to
> > say, a work containing the Program or a portion of it, either verbatim
> > or with modifications and/or translated into another language.
> 
> I believe you're objecting to the "that is to say" phrase, which restates what
> "work based on the Program": means.

Attempts to, anyway.

> > As I read it, the phrase after the colon is a paraphrase of the
> > "ether/or" clause it follows, i. e., an attempt to restate it in
> > layman's terms.
> 
> Yes.  And that "either/or" clause says what "work based on the Program"
> means.

Yep.  That phrase is, in its entirety: "either the Program or any
derivative work under copyright law".  And that's the definition of
"work based on the Program" for the duration of the GPL, as far as I'm
concerned.

> > And it's incorrect, as I explained, and for which I
> > have previously given references to treaty, several countries'
> > statutes, and lots of case law, in messages on -legal to which you
> > responded (generally constructively and courteously, I might add).
> 
> I disagree:
> 
> "work based on the Program" is not the same thing as "derivative work".
> 
> The definition of "work based on the Program" uses the "derivative
> work" concept, but builds on that concept.
> 
> I think claiming they're equivalent is silly.

Right.  "either the Program or any derivative work under copyright
law" \superset "derivative work".  But collections containing the
Program don't fit.  "That is to say" introduces an (incorrect)
paraphrase -- not a further expansion of the category.  To read
otherwise is to do violence to both the grammar and the legal sense of
the definition; and as I wrote, would result in an unacceptable scope
for the license (any "work" containing GPL material, up to and
including an entire CD set and the shelf of books bundled with it).

People who say publicly and often enough that they accept the FSF
FAQ's statement that programs using GPL libraries must be released
under the GPL (
http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL )
may well be estopped from arguing otherwise in court.  I prefer not to
be numbered among them.  (And no, before you say it, I'm not trolling
to build a defense for some court case.)  But that's completely
different from affecting the legal meaning of the license (see Linus's
LKML post again).

I'd be sorry to see, say, a GR swearing allegiance to the FSF FAQ;
that would probably estop Debian in perpetuity from linking GPL
against non-GPL, trigger the "automatic termation" provision
immediately and retrospectively due to any of a zillion inadvertent
build bugs in the past decade, and lead to the Death Of Debian (TM). 
But it wouldn't have any effect on what license terms I or any Debian
user or derivative would be obligated to accept.

Cheers,
- Michael

Re: GPL and linking

[Jeremy Hankins]

"Michael K. Edwards" <[EMAIL PROTECTED]> writes:

> You may not be qualified (as I am not) to offer legal advice.  But
> you're certainly qualified to have an opinion.

Sure.  But it's not relevant to this discussion -- despite what many of
the participants seem to believe.

> And there isn't
> necessarily an "agreeable, safe position".

Are you saying there's not?  So who's going to sue me (or Debian) for
adopting an overbroad idea of what constitutes a derivative?  "Hey, you
decided to abide by my license terms when you didn't have to.  I'm gonna
sue!"  (Standing?  What's that?)

Conversely, if our idea of what constitutes a derived work is too
narrow we could end up violating someone's copyright.

-- 
Jeremy Hankins <[EMAIL PROTECTED]>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03


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

Re: intend-to-implement: script to obtain Debian Source

[Adam Heath]

On Mon, 4 Apr 2005, Junichi Uekawa wrote:

> Hi,
>
> > The new toolset(tentatively called dbs-ng while I'm developing it) supports
> > what I call pre-patched source.
>
> Was this a April-fools joke, or do you have some code that we can look at?

While there is no code to look at, xen 2.0(in experimental) is using this
system.

> However, the concept looks possible to implement, and
> will fix most of the problems we have with handling Debian
> source packages; I'm not sure if it helps the maintainer side or not,
> since I have not looked into the usability aspect yet.


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

Re: GPL and linking

[Michael K. Edwards]

On 5/6/05, Jeremy Hankins <[EMAIL PROTECTED]> wrote:
> "Michael K. Edwards" <[EMAIL PROTECTED]> writes:
> 
> > You may not be qualified (as I am not) to offer legal advice.  But
> > you're certainly qualified to have an opinion.
> 
> Sure.  But it's not relevant to this discussion -- despite what many of
> the participants seem to believe.

Did you read any of the rest of my message?  This particular sentence
of mine disagrees with your claim that "almost all of us aren't
qualified to have an opinion" on license issues.  Then what are we
doing messing around with other people's copyrighted material?

> > And there isn't
> > necessarily an "agreeable, safe position".
> 
> Are you saying there's not?  So who's going to sue me (or Debian) for
> adopting an overbroad idea of what constitutes a derivative?  "Hey, you
> decided to abide by my license terms when you didn't have to.  I'm gonna
> sue!"  (Standing?  What's that?)

It's not particularly agreeable or safe to say, "we, Debian, interpret
the GPL to recursively follow the depends/reverse-depends
relationships of GPLed packages, crossing most of the individual API
and package boundaries within the work called Debian, and therefore
the strong set within Debian is being offered to our users under the
GPL alone, even if the individual packages contain MIT/BSD/whatever
licenses in debian/copyright".  That's probably a little stronger than
the estoppel one risks in saying the Debian consensus is that
dynamically linked Quagga -> NetSNMP -> OpenSSL is illegal (disallowed
under the GPL), but not much.

My take on it is that such relationships are perfectly legal, but that
as a courtesy to the FSF we undertake to resolve such situations when
they are discovered, either by efforts to obtain unambiguous license
compatibility or by package removal.  And if it were me, I'd keep
building Quagga against NetSNMP while proceeding with reasonable
dispatch, but not in a panic, to request that the Quagga upstream get
it together with respect to an OpenSSL exemption.

The risk in publicly acknowledging the FSF FAQ as a standard of
legitimacy is not that anyone will sue you but that Debian will
unwittingly provide a stalking-horse for some GPL copyright holder
(not necessarily the FSF) to attack Debian users and derivatives. 
Say, for instance, I write a program that uses an LGPL library whose
upstream doesn't follow a copyright assignment policy, and then
someone claims that their GPL code was pasted in a while ago.  I watch
helplessly while Debian relabels it GPL and purges all
GPL-incompatible engineering relationships to that library -- and
knowing that they have done so might put me at risk of being estopped
along with Debian even if I don't agree with the FSF FAQ myself.  That
would not be a good situation.

(By the way, my undying thanks to the Debian X Strike Force for
handling the XFree86 license situation the way they have.  No panic,
no sudden abandonment of the XFree86 code base, just a decision to
decline contributions not available under the MIT/X11 license even if
they're from upstream, and to move to an alternate upstream fork after
sarge.  And a carefully written FAQ, not over-commital on legal
issues.)

> Conversely, if our idea of what constitutes a derived work is too
> narrow we could end up violating someone's copyright.

Again, that's not how it works.  In the presence of a valid license
contract, one is entitled to contract-law standards of the
reasonableness of one's attempts to cure a breach when notified.  The
"automatic termination" clause is probably unenforceable in most
jurisdictions; I think (IANAL) few would even read it as authority to
terminate on inadvertent (non-material) breach, let alone on the
licensor's idea of breach if the licensee's (reasonable) construction
makes it not a breach.

Consider how it worked in Progress Software v. MySQL.  The FSF's
affidavit on MySQL's behalf claimed that Progress's license was
terminated, but the judge didn't buy it, and upheld Progress's right
to go on distributing MySQL's GPL material.  The judge called the
derivative work issue a "matter of fair dispute" -- and hence not a
deliberate breach -- noted that it was arguably cured anyway, that
MySQL had not demonstrated irreparable harm, and that the balance of
harms favored Progress, and denied the request for preliminary
injunction on GPL/copyright grounds.

For legal purposes, it often matters not only what you do and don't do
but why you say you're (not) doing it.  Saying in public that you're
trying to do X less often because you believe it's illegal is
injudicious at best.  Doubly so if you go on to say that you believe
that you permanently lost your rights under a license every time you
did X.

Cheers,
- Michael

Re: Debian Project Leader report for 2005-04-24

[Branden Robinson]

On Mon, Apr 25, 2005 at 01:45:52PM +0200, Josselin Mouette wrote:
> Le lundi 25 avril 2005 à 01:03 -0500, Branden Robinson / Debian Project
> Leader a écrit :
> > Woody Security Update Challenges and Progress
> > -
> > The ARM problems we've had have also affected the timeliness with which
> > we've been able to get security updates out.  A security fix to
> > ``xfree86``, for example, has been stalled for weeks because no ARM
> > build daemon has been operational to compile it.  (See `Debian bug
> > #298939`_ for details.)
> 
> Why, in this case, isn't the package released for the other
> architectures? There's nothing wrong with sending an update later for
> architectures that were missing in the first run.

I don't have an answer for this.  My guess is that the Security Team
decided delaying the update was the lesser of two evils.

Security folks, would you care to comment?

In any event, we have recovered from the ARM situation (and xfree86 for
stable/arm is built for it), and you can expect some happy details in my
next DPL report.

-- 
G. Branden Robinson| The power of accurate observation
Debian GNU/Linux   | is frequently called cynicism by
[EMAIL PROTECTED] | those who don't have it.
http://people.debian.org/~branden/ | -- George Bernard Shaw


signature.asc
Description: Digital signature

eDrugs Online

[Freddie]

eSecure Online Pharmacies
http://tvxlce.kznvo3kvzc2s6l2.paishnkmd.com

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

Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()

[Raul Miller]

On 5/6/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> On 5/6/05, Raul Miller <[EMAIL PROTECTED]> wrote:
> > On 5/6/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> [snip]
> > > Second sentence in Section 0:  The "Program", below, refers to any
> > > such program or work, and a "work based on the Program" means either
> > > the Program or any derivative work under copyright law: that is to
> > > say, a work containing the Program or a portion of it, either verbatim
> > > or with modifications and/or translated into another language.
> >
> > I believe you're objecting to the "that is to say" phrase, which restates 
> > what
> > "work based on the Program": means.
> 
> Attempts to, anyway.

I think this "attempts to" quip is meaningless.

> > > As I read it, the phrase after the colon is a paraphrase of the
> > > "ether/or" clause it follows, i. e., an attempt to restate it in
> > > layman's terms.
> >
> > Yes.  And that "either/or" clause says what "work based on the Program"
> > means.
> 
> Yep.  That phrase is, in its entirety: "either the Program or any
> derivative work under copyright law".  And that's the definition of
> "work based on the Program" for the duration of the GPL, as far as I'm
> concerned.

To recap:

W: "work based on the program"
D: "derivative work"
E: either/or phrase
C: phrase after the colon.

W means E
C paraphrases E

Thus, you have concluded, C attempts to paraphrase D

Should we keep going back and forth on this, trying to show why
you believe C attempts to paraphrase D?

Also, either: 

(1) Your other paragraphs are logically based on this concept
("C attempts to paraphrase D"), and therefore are based on
a false premise, or

(2) Your other paragraphs are not related to this paragraph by
theme or logic, and thus there's little point in continuing unless
they contain some worthwhile independent theme (personally,
I've not spotted one -- they just seem like a bunch of statements
with little cohesive logic).]

Or something else?

I don't know why it's important that all this be sent to debian-devel.  After
this post, I'm probably going to delete debian-devel from my followups
(and a great sigh of relief is heard throughout the land).

-- 
Raul

Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()

[Michael K. Edwards]

On 5/6/05, Raul Miller <[EMAIL PROTECTED]> wrote:
> On 5/6/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> > On 5/6/05, Raul Miller <[EMAIL PROTECTED]> wrote:
> > > I believe you're objecting to the "that is to say" phrase, which restates 
> > > what
> > > "work based on the Program": means.
> >
> > Attempts to, anyway.
> 
> I think this "attempts to" quip is meaningless.

How would you like me to say it?  "Purports to"?  "Professes to"? 
"Makes an honest but flawed effort to"?  Do you not understand my
interpretation that the use of quotes around "work based on the
Program" means that the writer is defining it as shorthand for "either
the Program or any derivative work under copyright law"?  And that an
attempt is then made to paraphrase (restate, whatever) the latter
phrase, and that restatement is just plain wrong?  You don't have to
agree with it, of course, but surely you get it now.

> > > Yes.  And that "either/or" clause says what "work based on the Program"
> > > means.
> >
> > Yep.  That phrase is, in its entirety: "either the Program or any
> > derivative work under copyright law".  And that's the definition of
> > "work based on the Program" for the duration of the GPL, as far as I'm
> > concerned.
> 
> To recap:
> 
> W: "work based on the program"
> D: "derivative work"
> E: either/or phrase
> C: phrase after the colon.
> 
> W means E
> C paraphrases E
> 
> Thus, you have concluded, C attempts to paraphrase D

No.  E defines W, which appears in quotes in the original to indicate
that it is being given a formal meaning.  C is grammatically a
paraphrase of E.  However, C and E are not the same thing according to
law; and grammatically and legally, E is the definition of W, and C is
not.  Neither is C \union E, C - D, or some other way to assign W a
meaning based on the wording of W, the content of an unrelated
document, or the distance to the moon.

> Should we keep going back and forth on this, trying to show why
> you believe C attempts to paraphrase D?

I don't, except insofar as C - "the Program" attempts to paraphrase E
- "the Program" (= D).  Are we done?  And if you're going to move it
to private e-mail, do it, don't grandstand about it.  That is also
more characteristic of others around here than it previously has been
of you.

Cheers,
- Michael

Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()

[Michael K. Edwards]

> I don't, except insofar as C - "the Program" attempts to paraphrase E
> - "the Program" (= D).

Oh for Pete's sake, (E - "the Program") (= D).  What a great place for
a word wrap.

- Michael