Save our lives , save our business , save China !

[Anndy Firstsing]

Our 3 brothers have been put into prison for *17 days* till now .
I've sent the same email to *all the relative CHinese government departments
and medias* , but no one stand out to save us till now .
The Chinese government wolves are USED TO rob , abduct and kill people for
ransom like this !
It's very difficult to save our 3 brothers out and save our business , save
such a China . Please kindly ask for as much help as possible for us ,
please send this letter to all your government departments , medias and
friends and PUSH them everyday for saving us .
Thank you in God's sake !
Details and proves attached .

*The government wolves has just noted our younger sister-in-law to tell me
that they are coming to Beijing to ARREST ME !!!*
*Why they should NOTE my younger sister-in-law about this ???*
*And why they always want to KILL all of us instead of correct their killing
actions ???*
*We've prepared our kitchen knives here to fight against them before death
!!!*

MY FAMILY MEMBERS ARE SENDING MONEY TO THE GOVERNMENT WOLVES AND LAWYERS
EVERY DAY BUT DARE NOT TO TELL ME HOW MUCH MONEY THEY'VE SENT TO THEM AND
WHAT'S THE LAWYERS' NAMES !!! They've employed THREE LAWYERS since May. 22nd
. Which have earned much money from them but don't permit them to meet our 3
brothers in prison till now !!! They give them only threat except for any
hope or schedule of releasing our 3 brothers !!!
The Chinese Law is famoused by " Only permits the government officers to '
set fire ' but not permits the people to ' make lights '  " !

I'VE ALSO NOTED THIS TO SONY , but sony doesn't care !
SONY knows this product has been produced in China for more than 10 years
and have more than 400 factories !
SONY knows it's the Chinese government which has made more than 400
factories to produce it for more than 10 years and still producing here and
there !
We are just a small seller !

COPY IS NOT BECAUSE OF US ， IT'S BECAUSE OF THE CHINESE GOVERNMENT ， WHICH
MADE MORE THAN 400 FACTORIES PRODUCE IT FOR MORE THAN 10 YEARS ， WE ARE JUST
A SMALL SELLER
AND IN CHINA ， EVEVERY ONE USE COPIED SOFTWARE ， INCLUDING THE GOVERNMENT
WOLVES ， THIS IS ALSO WORLDWIDE KNOWN ！
WHO caused it ?

There is a famouse Chinese poem says , " The country developped , the (
Chinese ) people living hard ; the country failed , the ( Chinese )  people
living hard . "
Why the Chinese people is always living hard ?
Because of the UNFAIRED Chinese LAW beteen the government wolves and the
people !!!

Anndy from www.firstsing.com

Re: Dependencies on shared libs, take 2

[Russ Allbery]

Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Russ Allbery]

>> They *usually* do, but not all E tags are certain problems.  Of course,
>> maintainers could use overrides.

> I'm opposed to adding overrides to my packages for cases where, in my
> view, lintian should somehow have enough information to see the case as
> a false positive.

Yes, there is that too.  I don't think people should have to add an
override if it's a bug in lintian.  And if dak ever starts using lintian
results, we'll have to figure out a way to handle that.

But of course if that happens, please do report the bug if it isn't
already reported.  There are no false-positive bugs currently open against
lintian; every false positive that's been reported has either been fixed
or is sufficiently difficult to fix for one reason or another that we've
decided overrides are the correct way of handling exceptions.  Also, in
the latter case, if overrides are the right way to handle exceptions, the
lintian tag description, with -i, should say so, and if it doesn't, please
report a minor bug.

> I suppose others feel that being lintian-clean is so important that it's
> worth muddying the waters by overriding all false positives, not only
> the exceptional situations but the lintian bugs.  If most people feel
> that way, I guess it would be reasonable to add lintian to the set of
> dak sanity checks.  But I don't believe I'm the only one who disagrees.

I think it makes sense to add certain lintian checks to the dak sanity
checks.  I'm certain that you don't want all of them, and I'm fairly
certain that you don't even want all of the current Es.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Dependencies on shared libs, take 2

[Peter Samuelson]

[Russ Allbery]
> They *usually* do, but not all E tags are certain problems.  Of course,
> maintainers could use overrides.

I'm opposed to adding overrides to my packages for cases where, in my
view, lintian should somehow have enough information to see the case as
a false positive.  I use them only when a lintian check seems useful in
the general case but I cannot think of a reasonable way for the check
to be fixed to ignore my situation.

I suppose others feel that being lintian-clean is so important that
it's worth muddying the waters by overriding all false positives, not
only the exceptional situations but the lintian bugs.  If most people
feel that way, I guess it would be reasonable to add lintian to the set
of dak sanity checks.  But I don't believe I'm the only one who
disagrees.


signature.asc
Description: Digital signature

Re: Reasonable maximum package size ?

[Charles Plessy]

Le Tue, Jun 05, 2007 at 09:47:37PM +0100, Roger Leigh a écrit :
> Anthony Towns <[EMAIL PROTECTED]> writes:
> >
> > Are either of you going to debconf, or able to point out some example
> > large (free?) data sets that should be packaged like this as a test case
> > for playing with over debconf?
> 
> The NCBI non-redundant database (nr).  Having this packaged and
> frequently updated (maybe in volatile) would be fantastic.  There are
> also quite a number of other significant (popular) databases used for
> bioinformatics, genomics, proteomics and other biological fields which
> would be really nice to have in Debian.  Here's a selection:
> 
> ftp://ftp.ncbi.nih.gov/blast/db/
> ftp://ftp.ncbi.nih.gov/refseq/
> ftp://ftp.ncbi.nih.gov/repository/
> ftp://ftp.ncbi.nih.gov/pub/taxonomy/

Hi all,

Thanks to Roger, I do not need to give more examples of big datasets. I
recently tried to explore the issues of packaging biological sequence
databases with a small one, miRbase:

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

This example shows why using a packaging system is useful to process the
data, and why it is space-hungry:

Let us examine the contents of miRbase:

ftp://ftp.sanger.ac.uk/pub/mirbase/sequences/CURRENT/ (no tarball
available)

File: README5 KB25.05.2007  15:43:00
File: THIS_IS_RELEASE_9_2   1 KB25.05.2007  15:47:00
Directory: database_files   25.05.2007  15:41:00
Directory: genomes  25.05.2007  15:40:00
File: hairpin.fa.gz 171 KB  25.05.2007  15:40:00
File: mature.fa.gz  62 KB   25.05.2007  15:40:00
File: miFam.dat.gz  24 KB   25.05.2007  15:40:00
File: miRNA.dat.gz  507 KB  25.05.2007  15:40:00
File: miRNA.dead.gz 3 KB25.05.2007  15:40:00
File: miRNA.diff.gz 3 KB25.05.2007  15:40:00
File: miRNA.str.gz  362 KB  25.05.2007  15:40:00
File: miRNA.xls 1193 KB 25.05.2007  15:40:00

The core data is miRNA.dat.gz. Its compression ratio is almost 90%: DNA
sequences are mostly A,C,T,G,N and headers. To use the database, we can
search it either by sequence name (researcher name known sequences), or
by similarity ("find anything more than 85% similar to AACTGAATTCGAT").
Debian has tools for this, but they can not work directly on miRNA.dat.

Here is a longer summary on many ways to search miRbase (you may skip it
if you are busy):

* Finding by name: using the (experimental) package emboss, the build
  rules of a mirbase binary package should create an index in EMBOSS
  format. The latest format produces indexes which are bigger than the
  database itself. And it has been specially written to index files
  bigger than 2 Go !

* Finding by similarity: again, emboss is needed, this time to convert
  miRNA.dat to an intermediary format, which can be used to create a
  database in the NCBI blast (package blast2) format. EMBOSS can also
  index these databases by name, but it sacrifices some information.
  NCBI blast users may nevertheless opt for these indexes, because it
  saves a lot of space (the blast databases are binary, not flat files)

* Finding through a warehouse. Most databases are interconnectable. A
  gene in the "nr" database (see above) can signal that it is the target
  of a miRNA of miRbase, which lists other targets, which code for
  proteins, which have domains, which have strucure, which bind drugs,
  which cure diseases, which are caused by mutations in genes, which are
  the target of miRNA... The most famous warehouse is SRS, but it is
  proprietary. Luckily, there is an alternative being developed, MRS
  (http://mrs.cmbi.ru.nl/mrs-3/status.do).

* Finding by SQL: in the particular case of miRbase, which is rare,
  some mySQL dumps are provided in the directory database_files, so that
  people can set up a SQL database indexing in details all fields.

* Finding at the office: did you notice the extension of the biggest
  file? Ironically it is the only one not to be zipped. miRbase is small
  enough to fit a spreadsheet (which can be used by OpenOffice).

* Finding by chance: the 'genomes' directory contain coordinates of the
  entries in the different genomes. When displaying a portion of the
  sequence of a human chromosome, for instance, the provided files can
  be used to flag places in which the sequences of miRbase originate (a
  la Google Maps).


Consequences from the packaging point of view:

In order to provide data packages which take advantage of the dependancy
relationships with binary packages, we need some build mechanims, mostly
to reformat and create the indexes in a format compatible with the
current versions of the packages in Debian such as emboss and blast2.
This could be done:

 - In buildds,
 - on the users computers,
 - in "data buildds"

Once processed, the data is sort of duplicated. In the example of
mirbase, we would have:

 - Th

Re: Dependencies on shared libs, take 2

[Russ Allbery]

Felipe Sateler <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:

>> The primary barrier to enforcing the use of lintian is #243976. lintian
>> needs to get much better about identifying the source of checks, the
>> certainty that something is wrong, and the severity level so that dak
>> can run lintian in a very specific way to only reject packages with
>> fairly certain errors according to sources with the strength of Policy.

> man lintian says that when the exit status is 1, policy violations have
> been detected.

man lintian lies.  :)  An exit status of 1 just means that lintian found
errors, not all of which are policy violations, and not all of which are
definitely package problems.  Right now, lintian only has three levels of
classification of tags, on a single axis.  It needs to gain three axes of
classification: severity, certainty, and source.

> As a first step, dak could check the exit code, and reject packages when
> it is 1, forwarding the lintian output to the maintainer (since E tags
> have high certainty, right?).

They *usually* do, but not all E tags are certain problems.  Of course,
maintainers could use overrides.

It's probably a workable idea, but it's not a slam-dunk.  If I can enhance
lintian so that you can say "show me only Debian Policy 'must' violations
about which you're certain," it would be a slam-dunk.

> This way, although tests won't be comprehensive, they would better than
> the current status quo. If a test result is indeed a false positive, the
> maintainer should have filed a bug to lintian and/or provided an
> override file before doing the upload.

I try to be a very responsive maintainer, but I'm a little scared of being
a gating factor for the archive.  :)  But I guess there are overrides.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Dependencies on shared libs, take 2

[Felipe Sateler]

Steve Langasek wrote:

> On Tue, Jun 05, 2007 at 04:47:07PM -0400, Felipe Sateler wrote:
> 
>> > Throwing a sensible error at build-time if the soname has changed
>> > without a package name change is also something that needs to be done,
>> > as well as throwing an error at build-time if symbols listed in the
>> > symbols file have gone missing;
> 
>> Lintian already does the first,
> 
> That's not a build-time error.

Only because lintian is not part of the build chain. As I said before,
enforcing the use of lintian would give you build time errors.

>> and a new check could be added for the second. There should be no need to
>> complicate Raphaël's proposal when there is already a tool specifically
>> designed for tests of this sort.
> 
> Yes, there is: the symbol information that needs to be stored is identical
> for both and should be shared for the two tasks.

I don't understand this. As I see it, the test can be performed in a later
stage along with several other tests. Why special case this one, or worse,
duplicate the test? 
If I read my books correctly, each unit should do only one task (when
possible).


-- 

  Felipe Sateler


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

Re: Dependencies on shared libs, take 2

[Felipe Sateler]

Russ Allbery wrote:

> Felipe Sateler <[EMAIL PROTECTED]> writes:
> 
>> What you want may be achieved by enforcing the use of lintian, but I
>> don't know how that can be done.
> 
> The primary barrier to enforcing the use of lintian is #243976. lintian 
> needs to get much better about identifying the source of checks, the
> certainty that something is wrong, and the severity level so that dak can
> run lintian in a very specific way to only reject packages with fairly
> certain errors according to sources with the strength of Policy.

man lintian says that when the exit status is 1, policy violations have been
detected. As a first step, dak could check the exit code, and reject
packages when it is 1, forwarding the lintian output to the maintainer
(since E tags have high certainty, right?).
This way, although tests won't be comprehensive, they would better than the
current status quo. If a test result is indeed a false positive, the
maintainer should have filed a bug to lintian and/or provided an override
file before doing the upload.

-- 

  Felipe Sateler


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

Bug#427709: ITP: movabletype -- A well-known blogging engine

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves <[EMAIL PROTECTED]>

* Package name: movabletype
  Version : 4
  Upstream Author : SixApart, Ltd.
* URL : http://www.movabletype.org/opensource/
* License : GPL[*]
  Programming Lang: Perl
  Description : A well-known blogging engine

[*] Not yet, due later this year

MovableType is a popular blogging, or web publishing platform. It
provides an easy to use web interface to publishing blogs and contains
many features and plugins.

Please note, this is a very initial ITP and I won't be working on this
properly until there's actually some visible sign of GPL'd code.


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

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Javier Fernández-Sanguino Peña]

On Mon, Jun 04, 2007 at 04:16:29PM -0400, Lennart Sorensen wrote:
> On Sun, Jun 03, 2007 at 11:16:08PM +0200, Javier Fern?ndez-Sanguino Pe?a 
> wrote:
> > Think about Enterprise (non-free) software like Oracle, HP Openview, Tivoli,
> > Remedy... Do you expect vendors of this software to understand^Wimplement
> > package management based dependencies for *all* Linux distributions?
> > LSB tries to simplify the Linux environment for such software. Lsb_release
> > is defined as the an answer to the question "which distribution am I running
> > in and which release is it?"
> 
> For the kind of cash the enterprise vendors tend to charge, yes actually
> now that you ask, I think I can expect them to figure out dependancies
> and making proper packages.  Opera seems to manage, and they are giving
> away their non-free software for free.  Managing to package and test
> your code on most major distributions is actually a good way to ensure
> the programmers didn't go do something stupid that is going to cause
> problems later.

I'm afraid you're comparing apples and oranges here.

Opera is a rather small product and codebase when compared to the products of
any of the Enterprise software players I placed above. In some of the
examples I placed above a software release of a given version of their
product is made up of 4-5 CDs of binary software. Opera is, what, a 4-7 MB
download?

Believe me, people running Linux and using this kind of software will, in
most cases, not get a package integrated into their $distribution package's
management system but an installation program from the vendor that works by
its own rules.

The funny thing is, some of these installation systems actually installs a
package management system of itself which is completely unrelated to the
system's. That's the case of HP's depots, the package management system for
HP-UX, which is also used in software like HP Openview when installed in
other operating systems too (at least I know of Sun's Solaris and IBM's AIX)

And, even funnier, those that *do* provide packages (RPM packages in all the
cases I've stumbled upon) don't setup proper dependencies so even if they
install fine on a system they were not prepared for (think SuSE vs. RedHat)
they just don't run. Vendors just use the package management system as an
archiver (a 'bigger' tar.gz or zip file if you will).

Many organisations I've worked with in Spain (including Telcos and Banks) pay
large amounts of cash in licenses to these (overseas) software vendors and
no, they are not pushing them to get packages for their favorite
distribution. They just push them to make it *works* (i.e. run and be
supported) in $distribution and are not always succesful (which means they
have to install the vendor software in the official/supported/approved
platforms the vendor has decided upon). 

Long-term, the fact that the software was installed using a .deb, .rpm, an
installation script or a tar.gz is not important at all. Having the vendor
support your environment is.

Regards

Javier


signature.asc
Description: Digital signature

ITP: evolvotron -- Texture generator

[Gürkan Sengün]

Package: wnpp
Severity: wishlist

* Package name: evolvotron
   Version : 0.4.0
   Upstream Authors: Tim Day
* URL : http://www.bottlenose.demon.co.uk/share/evolvotron/
* License : GNU GPL
   Description : Texture generator
 This is an interactive generative art application to evolve
 images/textures/patterns/animations through an iterative process of 
random
 mutation and user-selection driven evolution. (This process is also 
often
 referred to as "evolutionary art" or "genetic art".) If you like lava 
lamps,
 and still think the Mandelbrot set is cool, this could be the 
software for

 you.


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

Re: Dependencies on shared libs, take 2

[Steve Langasek]

On Tue, Jun 05, 2007 at 04:47:07PM -0400, Felipe Sateler wrote:

> > Throwing a sensible error at build-time if the soname has changed without
> > a package name change is also something that needs to be done, as well as
> > throwing an error at build-time if symbols listed in the symbols file have
> > gone missing; 

> Lintian already does the first,

That's not a build-time error.

> and a new check could be added for the second. There should be no need to
> complicate Raphaël's proposal when there is already a tool specifically
> designed for tests of this sort.

Yes, there is: the symbol information that needs to be stored is identical
for both and should be shared for the two tasks.

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


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

Re: Dependencies on shared libs, take 2

[Russ Allbery]

Felipe Sateler <[EMAIL PROTECTED]> writes:

> What you want may be achieved by enforcing the use of lintian, but I
> don't know how that can be done.

The primary barrier to enforcing the use of lintian is #243976.  lintian
needs to get much better about identifying the source of checks, the
certainty that something is wrong, and the severity level so that dak can
run lintian in a very specific way to only reject packages with fairly
certain errors according to sources with the strength of Policy.

I have some ideas on how to do this, but it's substantial work and I'm not
sure when I'll have the time to do it.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Reasonable maximum package size ?

[Roger Leigh]

Anthony Towns <[EMAIL PROTECTED]> writes:

> On Tue, Jun 05, 2007 at 06:28:53PM +0900, Charles Plessy wrote:
>> Le Tue, Jun 05, 2007 at 10:09:07AM +0200, Michael Hanke a ?crit :
>> > My question is now: Is it reasonable to provide this rather huge amount
>> > of data in a package in the archive?
>> many thanks for bringing this crucial question on -devel. In my field, I
>> wish that it would be possible to apt-get install the human genome for
>> instance.
>
> Are either of you going to debconf, or able to point out some example
> large (free?) data sets that should be packaged like this as a test case
> for playing with over debconf?

The NCBI non-redundant database (nr).  Having this packaged and
frequently updated (maybe in volatile) would be fantastic.  There are
also quite a number of other significant (popular) databases used for
bioinformatics, genomics, proteomics and other biological fields which
would be really nice to have in Debian.  Here's a selection:

ftp://ftp.ncbi.nih.gov/blast/db/
ftp://ftp.ncbi.nih.gov/refseq/
ftp://ftp.ncbi.nih.gov/repository/
ftp://ftp.ncbi.nih.gov/pub/taxonomy/

Because these are all in standard formats, it might even be possible
to have updated packages generated and uploaded semi-automatically.
These would be really useful in conjunction with much of the
bioinformatics software already available in Debian, which could make
good use of them if they were put in standardised locations.

As has been mentioned previously, a separate archive section so that
mirrors could skip them would be nice.  Together, all these databases
are eye-wateringly huge.  Especially when uncompressed.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


pgpRo5RfEC3v7.pgp
Description: PGP signature

Re: Dependencies on shared libs, take 2

[Felipe Sateler]

Steve Langasek wrote:

> Throwing a sensible error at build-time if the soname has changed without
> a package name change is also something that needs to be done, as well as
> throwing an error at build-time if symbols listed in the symbols file have
> gone missing; 

Lintian already does the first, and a new check could be added for the
second. There should be no need to complicate Raphaël's proposal when there
is already a tool specifically designed for tests of this sort.

What you want may be achieved by enforcing the use of lintian, but I don't
know how that can be done.

-- 

  Felipe Sateler


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

Re: Reasonable maximum package size ?

[Andreas Tille]

On Wed, 6 Jun 2007, Anthony Towns wrote:


Are either of you going to debconf, or able to point out some example
large (free?) data sets that should be packaged like this as a test case
for playing with over debconf?


For a first shot we could play with sauerbraten-data.  I just
stumbled upon it some days ago because debmirror was not able
to mirror it on my side.  I just didn't cared about the debmirror
problem much because it was a "nice reminder" to exclude this
package from mirroring, but from this point of view the package
size just seems to have crossed a border that might need extra
care.

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: License discussions in Debian

[Julien Cristau]

On Wed, Jun  6, 2007 at 06:07:46 +1000, Anthony Towns wrote:

> Perhaps a more interesting example is xserver-xorg-core's inclusion of the
> GLX Public License, which includes:
> 
>  Any litigation relating to this License shall be subject to the
>  exclusive jurisdiction of the Federal Courts of the Northern District
>  of California (or, absent subject matter jurisdiction in such courts,
>  the courts of the State of California), with venue lying exclusively
>  in Santa Clara County, California, with the losing party responsible
>  for costs, including without limitation, court costs and reasonable
>  attorneys fees and expenses.
> 
> The CID Font Code Public License and the SGI Free Software License B in the 
> same
> package have similar clauses.
> 
> Sourced from http://lists.debian.org/debian-legal/2005/11/msg00113.html and
> some quick grepping through copyright files in the lintian lab on gluck.
> 

Given #211765 and friends, you could probably have found better examples
(and choice of venue is not the most important issue with these).  The
CID Font Code Public License is probably not relevant anymore, btw, the
affected code has been removed upstream, and the only reference to this
license I can find in the X server tree is in debian/copyright :)

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Reasonable maximum package size ?

[Michael Hanke]

On Wed, Jun 06, 2007 at 01:58:33AM +1000, Anthony Towns wrote:
> On Tue, Jun 05, 2007 at 06:28:53PM +0900, Charles Plessy wrote:
> > Le Tue, Jun 05, 2007 at 10:09:07AM +0200, Michael Hanke a ?crit :
> > > My question is now: Is it reasonable to provide this rather huge amount
> > > of data in a package in the archive?
> > many thanks for bringing this crucial question on -devel. In my field, I
> > wish that it would be possible to apt-get install the human genome for
> > instance.
> 
> Are either of you going to debconf, or able to point out some example
> large (free?) data sets that should be packaged like this as a test case
> for playing with over debconf?
No, I'm not going to Debconf, but here is an example package (arch:all) to play
with (approx. 150MB):

http://apsy.gse.uni-magdeburg.de/~hanke/bigpack/caret-data_5.5~dfsg.1-1.dsc

or if you prefer the (repackaged) orig tarball only

http://apsy.gse.uni-magdeburg.de/~hanke/bigpack/caret-data_5.5~dfsg.1.orig.tar.gz

FYI: this is among other stuff a stereotaxic brain atlas.

The data is GPL licensed, but for some reason (I guess user-tracking)
upstream requires everyone to register prior to download. It is a little
strange, but this is the current situation. Therefore uscan doesn't
work -- the watch file doesn't list the login/password. I'm trying to convince
upstream to get rid of the registration requirement rather than
impolitely bypassing it by putting it in the watchfile. Anyway, that should
not matter for this purpose.


Thanks for working on this problem,

Michael



-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050


signature.asc
Description: Digital signature

Re: Reasonable maximum package size ?

[Alexander Schmehl]

Hi!

* Anthony Towns <[EMAIL PROTECTED]> [070605 17:42]:

> Moving game data elsewhere would require some way for games in main to
> depend on data elsewhere.

That's one of topics the pkg-games team is planing to adress during a
BoF at DebConf7 (beside some other stuff).  Hints welcome ;)


Yours sincerely,
  Alexander


signature.asc
Description: Digital signature

Re: License discussions in Debian

[Anthony Towns]

On Tue, Jun 05, 2007 at 10:20:40PM +1000, Anthony Towns wrote:
> ] > I thought choice-of-venue is non-free by default?

An example of a different MPL 1.1 derived choice-of-venue clause is
firebird2's:

This License shall be governed by California law provisions (except to
the extent applicable law, if any, provides otherwise), excluding its
conflict-of-law provisions. With respect to disputes in which at least
one party is a citizen of, or an entity chartered or registered to
do business in the United States of America, any litigation relating
to this License shall be subject to the jurisdiction of the Federal
Courts of the Northern District of California, with venue lying in
Santa Clara County, California, with the losing party responsible
for costs, including without limitation, court costs and reasonable
attorneys' fees and expenses.

Perhaps a more interesting example is xserver-xorg-core's inclusion of the
GLX Public License, which includes:

 Any litigation relating to this License shall be subject to the
 exclusive jurisdiction of the Federal Courts of the Northern District
 of California (or, absent subject matter jurisdiction in such courts,
 the courts of the State of California), with venue lying exclusively
 in Santa Clara County, California, with the losing party responsible
 for costs, including without limitation, court costs and reasonable
 attorneys fees and expenses.

The CID Font Code Public License and the SGI Free Software License B in the same
package have similar clauses.

Sourced from http://lists.debian.org/debian-legal/2005/11/msg00113.html and
some quick grepping through copyright files in the lintian lab on gluck.

Cheers,
aj



signature.asc
Description: Digital signature

Re: discussion with the FSF: GPLv3, GFDL, Nexenta

[Francesco Poli]

On Wed, 6 Jun 2007 00:55:43 +1000 Anthony Towns wrote:

> On Mon, Jun 04, 2007 at 07:55:18PM +0200, Francesco Poli wrote:
> > On Mon, 4 Jun 2007 19:30:36 +1000 Anthony Towns wrote:
> > > And I mean, I know what a GR is for, why are you telling me? It's
> > > still not a *good solution* for deciding these things; it's a last
> > > resort, and the only other options we currently have a "ftpmaster
> > > decides" and "it's obvious to pretty much everybody".
> > I'm rather surprised to hear you saying that, since you seem to have
> > been the proposer of GR-2006-001...
> 
> Sometimes you have to choose the best of a lot of bad options. When
> that happens, it's often good to spend some time trying to get better
> options for the future.

Could you please elaborate?
I'm not sure I understand correctly: are you saying that you are unhappy
with how GR-2006-001 worked out and that you are looking for better
strategies for similar situations?

-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpOdkyAGBSE6.pgp
Description: PGP signature

Re: i386 33meg boot iso

[Andrew M.A. Cater]

On Tue, Jun 05, 2007 at 11:14:14AM -0500, Gunnar Wolf wrote:
> [EMAIL PROTECTED] dijo [Mon, Jun 04, 2007 at 11:19:25PM -0400]:
> > To: All
> > 
> This list is targetted at the development of Debian, not at user
> support. You will find better answers if you try
> [EMAIL PROTECTED]
> 

I think you may have missed the context of this: as I read this, this is
simply a "Thanks for everything: I've tried installing Debian before 
with no success but this time it only took 40 minutes to get me a fully 
running Debian desktop and system - good work guys :)" type post so 
intended as a thanks to the project and developers. I'm not sure he's 
still having problems :)

It's always nice when someone posts a success story: I try to point out
to people that Debian's no longer difficult to install but that you may
need to know what hardware's in your computer and be prepared to make 
some preparations.

Thanks to all at Debian for making this stuff work and making my work 
life easier :)

All the best,

Andy


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

Bug#427680: RFH: moc -- ncurses based console audio player

[Elimar Riesebieter]

Package: wnpp
Severity: normal

I request assistance with maintaining the moc package.

The package description is:
 moc (music on console) is a full-screen player designed to be powerful
 and easy to use.
 .
 Supported file formats are: MP3, OGG Vorbis, FLAC, WAVE, SPEEX, Musepack (MPC),
 AIFF, AU, WMA (and other less popular formats supported by libsndfile).
 New formats support is under development.
 .
 Other features: simple mixer, colour themes, searching the menu (the playlist
 or a directory) like M-s in Midnight Commander, the way MOC creates titles
 from tags is configurable, optional character set conversion for file tags
 using iconv(), OSS or ALSA output.
 .
  Homepage: http://moc.daper.net

As reported in #427473, with no response yet, I want to build moc
against new libflac-dev. Configuring the source gives:

...
checking for libFLAC... yes
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: 
ignored.
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: 
ignored.
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: 
ignored.
...

This is shown on a pbuild as well. Configuring against libflac-dev
1.1.2 gives no ERROR.  Any way, the package builds fine with
libflac-dev 1.1.4, but I don't want to upload with the above config
ERROR.

Is someone out there to give me a hint?

Thanks for cooperation.

Elimar


-- 
  The path to source is always uphill!
-unknown-


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

Re: discussion with the FSF: GPLv3, GFDL, Nexenta

[Russ Allbery]

MJ Ray <[EMAIL PROTECTED]> writes:
> Anthony Towns <[EMAIL PROTECTED]> wrote: [...]

>> No, punting to a GR [...] ends up with -legal folks complaining that
>> the resolution doesn't make sense.

> I think that most are reasonable and do that only if the resolution
> includes no explanation.

One of the inherent problems of resolving license discussions about
specific licenses by GR is that you probably won't get a rationale, since
everyone voting may have a different rationale.  With the GFDL, for
instance, I expect that among the people voting to allow it into main were
people who believe that the GFDL license terms sans invarient sections
truly are DFSG-free, people who feel the DFSG is too restrictive, people
who think that they aren't DFSG-free but we should make an exception for
the GFDL, people who feel the DFSG are only guidelines and shouldn't be
applied restrictively, and probably several other opinions.

There's no way of separating those out afterwards, and I don't think we're
likely to come up with a reasonable ballot on a single license that would
do so.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Lennart Sorensen]

On Tue, Jun 05, 2007 at 09:37:58AM -0400, Kris Deugau wrote:
> ... by making reasonable assumptions about what is on the system based
> on a standard install of $version of $distribution.

Well too many seem to assume that you are running some version of
redhat, and that redhat equals linux and there are no reasons to
consider anything else.

> Asking enterprise vendors to support your (customised, hacked-up,
> non-standard) OS install is, um, unlikely.  Unless you're paying them
> enough for them to completely mirror your environment in the dev lab and
> certify their product on *your* particular combination of software.  (Of
> course, most people running mixed-version Debian systems are unlikely to
> be buying enterprise software like Oracle.  )

Sure.  If I say I run debian sarge, and I install the .deb for debian
sarge, it should work, unless I have mixed in stuff that isn't part of
sarge, in which case that would be my problem.  So yes as long as they
provide a proper .deb targeted at sarge, that would be fine.  Of course
Etch would be more interesting than Sarge by now.

> (This is drifting off from my original question:  what simple test(s)
> for uniqueness can I use to determine which version of which
> distribution I'm on?   FWIW, it seems that for my purposes, the contents
> of /etc/debian_version and the full version+release string from the
> base-files package are sufficiently unique.)

Certainly the /etc/debian_version is what I would rely on.

--
Len Sorensen


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

Re: Dependencies on shared libs, take 2

[Joey Hess]

Steve Langasek wrote:
> > Finally, why not add the symbol informations to the shlibs file (that
> > can be done in a backwards compatible way) instead of creating yet
> > another control file ?
> 
> I'd rather we didn't, even if it doesn't break anything it still abuses the
> shlibs file format as defined in policy.  And what happens if you
> (improbably) have an overlap between a library name and a symbol name?

Note that policy doesn't fully document[1] the current shlibs format,
which is:

[package-type:] library-name soname-version-number dependencies...

It seems that this could be extended to include symbol information:

[package-type:] library-name soname-version-number dependencies...
[symbol dependencies...]
[...]

Like the package-type extension, this extra information will be
transparently ignored by old versions of dpkg-shlibdeps. Besides being
slightly more compact[2], it also has benefit of allowing inclusion of
differing symbol information for udebs, if it ever becomes useful to do
so.

-- 
see shy jo

[1] #363133
[2] Would it be worthwhile to support multiple symbols on one line to
save even more space?
symbol [symbol...] dependencies...


signature.asc
Description: Digital signature

Re: Dependencies on shared libs, take 2

[Peter Samuelson]

[Josselin Mouette]
> A possible part of the solution would be a script parsing the diff
> between headers and emitting warnings such as:
>   * type foo has changed, please check it doesn't affect functions
> bar/baz/...
>   * enum foo has new possible values, please check it doesn't affect
> functions ABI
>   * OMFFSM function bar's prototype has changed!
>   * struct foo has changed, please kill upstream

Sounds like a job for icheck (maintainer CC'd).  Consider adapting that
rather than reinventing it.

> Of course it wouldn't be enough to detect more subtle changes like new
> supported file formats, which only change the code, not the headers.

Right, in cases where new _features_ (or, indeed, bug fixes) affect a
particular reverse dep, obviously there's no general way to handle that
automatically.  Which is comforting, in a way; it's nice to know we
can't all be replaced with a very small shell script.


signature.asc
Description: Digital signature

Re: Reasonable maximum package size ?

[Joey Hess]

Anthony Towns wrote:
> Debug packages: (369MB) (not arch:all)
>  53959746 boson-dbg
>  55430908 icedove-dbg
>  56274922 koffice-dbg
>  59787420 iceape-dbg
>  86404478 libgl1-mesa-dri-dbg

These seem to be built with separated debugging symbols. They could
probably still be reduced in size with compilation flags as discussed in
the recent thread on dbg packages.

>  57383550 libqt4-debug

This doesn't use separated debug symbols, so it's a good candidate for a
bug report to switch to them.

> > The advantages would be: [...]
> > - make it possible to not include such data on the regular binary CDs,
> >   but for example on separate arch-independent "data" CDs
> 
> Particularly for game data, it seems like it'd make more sense (at least
> from a user's pov) to include the game code and the game data on the same
> CD, given they'd always be installed at the same time. I've no idea if
> that could realistically be done, or if there's any point thinking about
> it 'til later though.

debian-cd already supports multiarch CDs. It seems fairly doable to
exclude a set of packages from the main CD sets and put them on a set of
multiarch game CDs. It seems worthwhile as it would reduce the total
number of CDs containing said game data from approx 36 to 4. It might
even make the resulting CDs more likely to be used; currently few people
bother to use a full 23 CD set, but if they're into games and know which
4 CDs contain the large ones, it's worth getting just those 4. Better
yet, put it on a single DVD.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: discussion with the FSF: GPLv3, GFDL, Nexenta

[Don Armstrong]

On Tue, 05 Jun 2007, Anthony Towns wrote:
> Two different analogous licenses might be:
> 
>   By distributing the covered work, you agree that the copyright holder
>   can sue you for violations of the license.
> 
>   If you distribute the covered work, the licensor agrees not to sue you
>   in any jurisdiction other than Berlin, Germany.
>
> Heck, is choice of venue actually different to the combination of those
> clauses?

Yes; choice of venue is better written as "if you distribute the
convered work, you agree for all suits covering the work to be held in
Berlin, Germany."

> > [...] The current clause, though, puts the copyright holder in the
> > dealer's seat, and the house always wins.
> 
> Well, that's only true over the long term, and I don't think it's
> necessarily true even over the long term for court cases.

Considering Sun's apparent interpretation though, they could easily
rewrite this clause to be in the position of resolving abiguities of
jurisdiction, or a defensive only jurisidiction clause. Either would
resolve my personal problems with the CDDL, and I believe would solve
the problems most -legal contributors have with the license.


Don Armstrong

-- 
Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly).
 -- Matt Welsh

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: i386 33meg boot iso

[Gunnar Wolf]

[EMAIL PROTECTED] dijo [Mon, Jun 04, 2007 at 11:19:25PM -0400]:
> To: All
> 
>Wow!!!  I have tried to install debian 4 or 5 times and hungup on vidio 
> drivers or mem address for the drivers.
> 
>   I downloaded the 33 meg. i386 boot iso on 6/4/07 daily build #2 It
>   whent from boot to a desktop system in 35-40 minutes with only
>   input at the prompts.  If you need any other info from me, email
>   me at: 
> 
>  [EMAIL PROTECTED]
> 
>  I will be away from my computer for about 12 days but I will be checking 
> email.

Hi,

This list is targetted at the development of Debian, not at user
support. You will find better answers if you try
[EMAIL PROTECTED]

Also, I suggest you try contacting them when you are actually able to
implement the possible answers you get - Usually, user help is not
limited to a recipe, but can be a process that requires several mail
interchanges.

Greetings

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: Reasonable maximum package size ?

[Anthony Towns]

On Tue, Jun 05, 2007 at 06:28:53PM +0900, Charles Plessy wrote:
> Le Tue, Jun 05, 2007 at 10:09:07AM +0200, Michael Hanke a ?crit :
> > My question is now: Is it reasonable to provide this rather huge amount
> > of data in a package in the archive?
> many thanks for bringing this crucial question on -devel. In my field, I
> wish that it would be possible to apt-get install the human genome for
> instance.

Are either of you going to debconf, or able to point out some example
large (free?) data sets that should be packaged like this as a test case
for playing with over debconf?

Cheers,
aj



signature.asc
Description: Digital signature

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Steve Greenland]

On 05-Jun-07, 08:37 (CDT), Kris Deugau <[EMAIL PROTECTED]> wrote: 
> Lennart Sorensen wrote:
> > For the kind of cash the enterprise vendors tend to charge, yes actually
> > now that you ask, I think I can expect them to figure out dependancies
> > and making proper packages.
> 
> ... by making reasonable assumptions about what is on the system based
> on a standard install of $version of $distribution.
> 
> Asking enterprise vendors to support your (customised, hacked-up,
> non-standard) OS install is, um, unlikely.

No, I'd ask them to build correct packages for the current stable
version, e.g. etch. If they've got their dependencies correct, I should
be able to install packages from other releases without too much
anguish.

Of course, if I have problem, I shouldn't be surprised to hear "we can't
duplicate it on our pure etch system..."

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: discussion with the FSF: GPLv3, GFDL, Nexenta

[Anthony Towns]

On Mon, Jun 04, 2007 at 07:55:18PM +0200, Francesco Poli wrote:
> On Mon, 4 Jun 2007 19:30:36 +1000 Anthony Towns wrote:
> > And I mean, I know what a GR is for, why are you telling me? It's
> > still not a *good solution* for deciding these things; it's a last
> > resort, and the only other options we currently have a "ftpmaster
> > decides" and "it's obvious to pretty much everybody".
> I'm rather surprised to hear you saying that, since you seem to have
> been the proposer of GR-2006-001...

Sometimes you have to choose the best of a lot of bad options. When that
happens, it's often good to spend some time trying to get better options
for the future.

> [...]
> > The official position of Debian is what we allow in main.
> That is to say?  Bugs never happen?!?  Nothing can possibly enter main
> by mistake or overlook?!?

Of course it can -- official positions can be wrong, can be made by
mistake or without due care, and can be changed.

> [...]
> > Unfortunately, since "-legal in general" becomes an amorphous set of
> > individuals who reserve the right to hold whatever opinions they like
> > whenever questioned, there's little hope of -legal ever learning from
> > its mistakes.
> Are you going to call the orwellian thought police, since I hold my
> *own* opinions?!?

You don't need to call the thought police, you only have to think of
them and they'll know to come!

Cheers,
aj



signature.asc
Description: Digital signature

Re: Reasonable maximum package size ?

[Anthony Towns]

On Tue, Jun 05, 2007 at 03:58:08PM +0200, Frans Pop wrote:
> IMO it would be worth it if we could split out gigabytes of data from the 
> main archive and thus significantly reduce the bandwidth needed for 
> mirror syncs. Especially if that data is only used by an extremely small 
> subset of users/developers.

Hrm, packages larger than 50MB in sid/i386 (main, contrib and non-free) [0]:

Eclipse NLS: (76MB)
 76498868 eclipse-platform-nls

Software: (104MB) (not arch:all)
104032026 gcc-snapshot

Clipart: (144MB)
144354894 openclipart-png

Documentation: (147MB)
 52801680 context-doc-nonfree
 94869090 koffice-doc

TeX: (192MB)
 56200406 texlive-fonts-extra
 56559816 tetex-src
 79907246 texlive-latex-extra

Debug packages: (369MB) (not arch:all)
 53959746 boson-dbg
 55430908 icedove-dbg
 56274922 koffice-dbg
 57383550 libqt4-debug
 59787420 iceape-dbg
 86404478 libgl1-mesa-dri-dbg

Game data: (1,413MB)
 52247006 nexuiz-music
 52552812 scorched3d-data
 60332050 vegastrike-music
 63569974 fillets-ng-data
 69398222 beneath-a-steel-sky
 75266604 openarena-data
 86669382 torcs-data-tracks
100913422 tremulous-data
103359260 freedroidrpg-data
132611332 vdrift-full
138455838 nexuiz-data
140544192 vegastrike-data
161313228 fgfs-base
176337384 sauerbraten-data

Largest deb in unstable is sauerbraten-data at 176MB, largest
arch-specific deb is atlas3-test for ia64 at 158MB. Total size of debs
in sid/i386 is 17,259MB, so packages above 50MB make up about 10%-15%
of the archive by size already.

Moving game data elsewhere would require some way for games in main to
depend on data elsewhere.

Moving -dbg data elsewhere would presumably require some way to upload
to both archives in a single step, and we'd want to keep them reasonably
tightly coupled.

Not moving -dbg stuff elsewhere would mean there'd be no need to worry
about supporting arch-specific stuff, afaics. OTOH, if we did support
arch-specific stuff, maybe it'd make sense to move the game engines
into the other area along with the data if there's no point to having
the engine without a huge amount of data to use it with.

> The advantages would be: [...]
> - make it possible to not include such data on the regular binary CDs,
>   but for example on separate arch-independent "data" CDs

Particularly for game data, it seems like it'd make more sense (at least
from a user's pov) to include the game code and the game data on the same
CD, given they'd always be installed at the same time. I've no idea if
that could realistically be done, or if there's any point thinking about
it 'til later though.

Cheers,
aj

[0] find dists/sid -name Packages.gz | 
xargs zcat | 
awk '/^Package:/ {P=$2} /^Architecture:/ {A=$2} /^Size:/ {S=$2} /^$/ 
{if (S > 5000) { print S, P, A }}' | 
sort -n | uniq | less



signature.asc
Description: Digital signature

Re: Dependencies on shared libs, take 2

[Oleg Verych]

* From: Steve Langasek
* Date: Tue, 5 Jun 2007 02:56:14 -0700
>
> On Tue, Jun 05, 2007 at 08:56:40AM +0200, Raphael Hertzog wrote:
>> On Mon, 04 Jun 2007, Steve Langasek wrote:
[]
>> > Considering the number of bugs I see because of maintainers who don't 
>> > notice
>> > they need to change package names due to upstream soname changes, or who
>> > routinely fail to bump their shlibs when new symbols are added, I think
>> > there is definitely room here for a recommended solution for maintainers
>> > that aren't watching the subtleties, even without trying to bump
>> > dependencies based on API extensions.
>
>> Would you care to elaborate? (What would you recommend? How do you expect
>> it to improve the situation with those maintainers?)
>
> Maintaining library symbol files with a tool that updates the symbol lists
> with behavior analogous to dh_makeshlibs -V would be a significant
> improvement over either dh_makeshlibs -V (force a shlibs bump for every
> rev), or dh_makeshlibs alone (get too weak shlibs for any API additions).
>
> Throwing a sensible error at build-time if the soname has changed without a
> package name change is also something that needs to be done, as well as
> throwing an error at build-time if symbols listed in the symbols file have
> gone missing; I don't see these features mentioned in your proposal, but I
> think they're part and parcel of a good implementation of what you're
> describing.

If one will take look in the message with subject "checklibs...", one will
see similar items in the wish list on top of the script. But i don't
know much (yet) about build infrastructure to store information
script already (and can easily) generate.

For colleagues with python implemented ELF parsing, i will suggest to
help either elfutils, or binutils with their TODO lists.



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

Re: Reasonable maximum package size ?

[Luis Matos]

Frans Pop wrote:

On Tuesday 05 June 2007 15:14, Anthony Towns wrote:
  

I'm not sure if avoiding duplicating the data (1G of data is bad, but
1G of the same data in a .orig.tar.gz _and_ a .deb is absurd) is enough
to just use the existing archive and mirror network, or if it'd still
be worth setting up a separate apt-able archive under debian.org
somewhere for _really_ big data.



IMO it would be worth it if we could split out gigabytes of data from the 
main archive and thus significantly reduce the bandwidth needed for 
mirror syncs. Especially if that data is only used by an extremely small 
subset of users/developers.


The advantages would be:
- overall reduced use of resources like disk space and bandwidth
- lower the barrier to create local mirrors, not only for home users,
  but also for mirrors in areas that are not that well connected to
  the rest of the world [1]
- make it possible to not include such data on the regular binary CDs,
  but for example on separate arch-independent "data" CDs
  
Debian 15 cd's, 2 dvd  + 1 DVD human genome + 2 DVD games + 2 DVD other 
data :P


this would be really fun ...

and i agree with this ... LOL.

also,  i agree with dividing the main package in smaller packages (pkg-1 
+ pkg-2 = PKG)


also ajt really touched a point: orig.tar.gz would also be hudge. So, 
maybe introducing some kind of packaging that would "forget" the 
orig.tar.gz would be nice.


dividing the data separed like 
main/contrib/non-free/DATA/DATA-non-free/DATA-contrib would be good. A 
few "faster" mirrors could support the few users that need this kind of 
packages.
It is likely that this issue will only become bigger with time, so 
investing in a structural solution IMO makes sense.
  

makes all sense.


Cheers,
FJP

[1] This was for example a real problem when I was in Bhutan last year.
  



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

Re: Reasonable maximum package size ?

[Ron Johnson]

On 06/05/07 08:58, Frans Pop wrote:

On Tuesday 05 June 2007 15:14, Anthony Towns wrote:

I'm not sure if avoiding duplicating the data (1G of data is bad, but
1G of the same data in a .orig.tar.gz _and_ a .deb is absurd) is enough
to just use the existing archive and mirror network, or if it'd still
be worth setting up a separate apt-able archive under debian.org
somewhere for _really_ big data.


IMO it would be worth it if we could split out gigabytes of data from the 
main archive and thus significantly reduce the bandwidth needed for 
mirror syncs. Especially if that data is only used by an extremely small 
subset of users/developers.


The advantages would be:
- overall reduced use of resources like disk space and bandwidth
- lower the barrier to create local mirrors, not only for home users,
  but also for mirrors in areas that are not that well connected to
  the rest of the world [1]
- make it possible to not include such data on the regular binary CDs,
  but for example on separate arch-independent "data" CDs

It is likely that this issue will only become bigger with time, so 
investing in a structural solution IMO makes sense.


Cheers,
FJP

[1] This was for example a real problem when I was in Bhutan last year.


What about putting such data in a special branch (correct term?), 
parallel to main, contrib and non-free?  That way, mirror sites can 
decide whether or not to mirror it?  Call it "hugedatasets"? 
(Boring name, but explicitly describes the contents.)


The other idea that I really like is to package a cron script which 
periodically examines the data file timestamps on the FTP server and 
the timestamps of the local files, and if the FTP files are newer, 
send an email to the user.  And, of course, provide a script to do 
the wgets/curls and data installs.  That way, you don't use use 
double the space on your system.


P.S. I *Really* Appreciates All The Hard Work You All Do.

--
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!


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

Re: License discussions in Debian

[Frank Küster]

Thomas Weber <[EMAIL PROTECTED]> wrote:

> Am Dienstag, 5. Juni 2007 14:20:40 schrieb Anthony Towns:
>> On Tue, Jun 05, 2007 at 12:07:52PM +0200, Frank K?ster wrote:
>> > You could ask Anthony whether you're allowed to publish his reasons on
>> > -legal.  That would do the project a great favor.
>>
>> You could just ask me directly you know...
>
> As my mail to you was private as well, I think Frank's approach was correct.

For what it's worth, I think it would have been correct to attach this
information to the bug log in the first place.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: License discussions in Debian

[Thomas Weber]

Am Dienstag, 5. Juni 2007 14:20:40 schrieb Anthony Towns:
> On Tue, Jun 05, 2007 at 12:07:52PM +0200, Frank K?ster wrote:
> > You could ask Anthony whether you're allowed to publish his reasons on
> > -legal.  That would do the project a great favor.
>
> You could just ask me directly you know...

As my mail to you was private as well, I think Frank's approach was correct.


> ] Via Simon Phipps's talk at debconf, we've got Sun on the record
> ] as interpreting "choice of venue" as only being relevant when the
> ] two parties to a suit both have a presence in multiple jurisdictions,
> ] including the one that's "chosen", which means it's not a problem at all.
> ]
> ] For the other case, even if Sun did want to make German laws apply to
> ] an Australian or similar, I don't think that holds up as a claim anyway.
>
> I don't think that's a particularly useful addition to what's already
> been in this thread. 

Actually, it is. If you look at the sub-thread involving Arnoud Engelfriet, 
you will see that Simon's idea of ' "choice of venue" being only important 
for multinational companies' is flawed, at least for the case at hand (star, 
choice of venue: Berlin, Germany, Europe).

The same goes for the second paragraph as well (well, not for Australia and 
the United States, but EU is not that small, either).

Additionally, the cited text is Sun's interpretation. What's the 
interpretation of star's licensor?

Thomas


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

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Kris Deugau]

Lennart Sorensen wrote:
> For the kind of cash the enterprise vendors tend to charge, yes actually
> now that you ask, I think I can expect them to figure out dependancies
> and making proper packages.

... by making reasonable assumptions about what is on the system based
on a standard install of $version of $distribution.

Asking enterprise vendors to support your (customised, hacked-up,
non-standard) OS install is, um, unlikely.  Unless you're paying them
enough for them to completely mirror your environment in the dev lab and
certify their product on *your* particular combination of software.  (Of
course, most people running mixed-version Debian systems are unlikely to
be buying enterprise software like Oracle.  )

(This is drifting off from my original question:  what simple test(s)
for uniqueness can I use to determine which version of which
distribution I'm on?   FWIW, it seems that for my purposes, the contents
of /etc/debian_version and the full version+release string from the
base-files package are sufficiently unique.)

-kgd


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

Re: Reasonable maximum package size ?

[Frans Pop]

On Tuesday 05 June 2007 15:14, Anthony Towns wrote:
> I'm not sure if avoiding duplicating the data (1G of data is bad, but
> 1G of the same data in a .orig.tar.gz _and_ a .deb is absurd) is enough
> to just use the existing archive and mirror network, or if it'd still
> be worth setting up a separate apt-able archive under debian.org
> somewhere for _really_ big data.

IMO it would be worth it if we could split out gigabytes of data from the 
main archive and thus significantly reduce the bandwidth needed for 
mirror syncs. Especially if that data is only used by an extremely small 
subset of users/developers.

The advantages would be:
- overall reduced use of resources like disk space and bandwidth
- lower the barrier to create local mirrors, not only for home users,
  but also for mirrors in areas that are not that well connected to
  the rest of the world [1]
- make it possible to not include such data on the regular binary CDs,
  but for example on separate arch-independent "data" CDs

It is likely that this issue will only become bigger with time, so 
investing in a structural solution IMO makes sense.

Cheers,
FJP

[1] This was for example a real problem when I was in Bhutan last year.


pgpnzEjqWm1pi.pgp
Description: PGP signature

Re: Dependencies on shared libs, take 2

[Marc 'HE' Brockschmidt]

Loïc Minier <[EMAIL PROTECTED]> writes:
> On Mon, Jun 04, 2007, Raphael Hertzog wrote:
>> Library maintainers are supposed to maintain the *.symbols file.  For
>> this, they have to create files "debian/.symbols."
>> (dpkg-gensymbols will try too fallback to "debian/symbols.",
>> "debian/.symbols" and "debian/symbols"). They are
>> required to provide the minimal version (as used in the dependency
>> generated) associated to each symbol.
>  While this seemed sensible on my first read, I think it's a burden to
>  effectively maintain multiple *.symbols.* files for multiple arches or
>  packages (for example flavors of the same library) with only small
>  differences between the lists.

Showers need to be good for something, so I thought about this today in
the shower and wondered why the arch files couldn't be treated as simple
override files. I expect that most libraries keep the same version data
for (almost) all archs in sync, so it seems to be sensible to simply use
a debian/$package.symbols file and only override the information for the
few needed symbols in a debian/$package.symbols.$arch file. 

The current codebase would only need a few changes (loading
debian/symbols, then loading debian/symbols.$arch into the same hash).

This doesn't reduce the work needed for various flavours of the same
lib, so an include statement would perhaps still be a good idea. Or
simply preprocess all files with cpp :-)

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
70: It is essential that implementations by different vendors interoperate.
   Unsere proprietären Basteleien dokumentieren wir gar nicht erst.
   (Sven Türpe)


pgpCpHf973tZm.pgp
Description: PGP signature

Re: Reasonable maximum package size ?

[Andreas Tille]

On Tue, 5 Jun 2007, Anthony Towns wrote:


Bug#38902 for hysterical interest, btw.


Ahh, my memory that this topic came up in 2000 was not that bad -
just missed it by 7 months.

I wonder, whether there is a more verbose explanation for tagging
it wontfix

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=38902;msg=171

Isn't it good style to add some comments to commands of the
BTS mail control interface?

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: discussion with the FSF: GPLv3, GFDL, Nexenta

[Anthony Towns]

On Tue, Jun 05, 2007 at 02:09:06AM -0700, Steve Langasek wrote:
> Why doesn't it matter?  If I've been sued because of something I've actually
> done that infringed the license, then surely the DFSG and Debian shouldn't
> be concerned with that (other than the question of whether what I've done is
> something that the DFSG requires of copyright holders); but if I'm being
> sued over something I *didn't* do, [...]

If you're going to be sued for something you didn't do, and lose because
in your absence you're assumed to have done it, why not go the whole
hog and just have them assert you've used/distributed a program you've
never actually used/distributed?

AFAICS this is an issue only when there's a not completely trivial
possibility that you have actually violated the license.

> - If I don't have the resources to fight the case in a court overseas, I
>   risk summary judgement; the cost to me is the liberty to travel unmolested
>   to Australia at some future date when I might have resources for travel.

Speaking of which, the linux.conf.au 2008 CFP is open:

http://linux.conf.au/presentations

I suspect that anyone who can get their paper accepted will be able to get
their travel costs covered by one of LCA, Debian or the Linux Foundation.

(Kickass segues 'r' us)

> * If I get sued in Oregon, I have a wide range of local resources at my
>   disposal to help me find appropriate legal representation; if I get
>   sued in Australia, I'm stretching my connections pretty thin to find
>   and evaluate legal counsel, and this process is going to cost more
>   time and money on my part (and may leave me with inferior legal
>   counsel anyway in the end due to logistical issues)

For Australia, assuming you were being sued over free software stuff
that you'd be doing in good faith, I think we could do a fairly good
job helping you out.

> * Effective realtime communication with the lawyer is more expensive
>   (transoceanic phone calls), and more inconvenient due to timezone
>   differences (fine, fine, not for *me*, but you know what I mean)

Yes, Australian lawyers seem to be in a very inconvenient timezone for
me... ;)

> As an analogy, suppose that a license included the following clause:
>   By distributing the covered work, you agree that the copyright holder can
>   compel you at any time to play in an on-line black jack tournament at his
>   website, geekblackjackstars.net, with an initial ante of $100.
> Should Debian consider this to be a free license because the clause won't
> necessarily be invoked and because some people win at blackjack?

Clearly not. BTW, that site doesn't seem to exist.

The difference between blackjack and choice of venue is that in one
case you're being compelled to do something, and in the other you're
pre-determining an argument. AFAICS that breaks that analogy.

Two different analogous licenses might be:

  By distributing the covered work, you agree that the copyright holder
  can sue you for violations of the license.

  If you distribute the covered work, the licensor agrees not to sue you
  in any jurisdiction other than Berlin, Germany.

I'd consider both those to be clearly free. Choice of venue goes beyond
either of them, certainly. But I'm still not seeing a way in which it
goes so far beyond them as to become non-free.

Heck, is choice of venue actually different to the combination of those
clauses?

> > Simon Phipps' argument, presented at debconf last year, is (aiui) that
> > the clause only comes into play when both parties are organisations
> > that cross multiple jurisdictions anyway -- in which case they're both
> > presumed to have a presence in the given jurisdiction anyway, and could
> > reasonably be expected to be following its rules, afaics.
> Has this opinion been confirmed by a lawyer on *SPI's* payroll, not just by
> one on *Sun's* payroll? :)  

TTBOMK, no. ITYM "acting on behalf of SPI" rather than "on SPI's payroll"
btw. :)

> [...] The current
> clause, though, puts the copyright holder in the dealer's seat, and the
> house always wins.

Well, that's only true over the long term, and I don't think it's
necessarily true even over the long term for court cases.

Cheers,
aj



signature.asc
Description: Digital signature

Re: License discussions in Debian

[Anthony Towns]

On Tue, Jun 05, 2007 at 09:08:31AM +0200, Frank K?ster wrote:
> That's true, as an ideal.  In reality, you can't expect every DD or even
> maintainer to subscribe to -legal except when they've got a particular
> problem to discuss.  

Sure, but you don't need or want that. All you need is an unbiassed
sampling of developers to participate, which is to say the list needs
to be just as open to extremist opinions from people who think the GFDL
is completely "free" as people who think the GPL is actually "non-free".

AFAICS the only way that's going to happen is by taking the view that
Debian's definition of "free" as per the DFSG-free is just one view
you can take, and that people who take alternative views -- whether
stricter or more liberal, whether focussed on legal details or ignorant
of them in favour of just doing stuff -- are still worth listening to,
even though their views on what's free or not may well be fundamentally
different to Debian's.

If the only question is "is this free or not?" then you're going to get
turf wars because there's just no middle ground, and whoever gets to make
that decision controls the debate. Even just having analyses take the form
of "these are the consequences, personally I'd avoid them, though Debian
doesn't think the problem's a big enough deal to worry about; Don agrees
with me, but Francesco doesn't" seems like it'd be most of the way there.

But as it stands, -legal's analysis seems to me more to fit the mold of
"this is conceivably bad in some circumstances, not the same as anything
in any good licenses, therefore it's non-free, and that's all there is
to it".

> I'm not sure, however, that this is the general attitude on -legal: I've
> never encountered it.  

Take Don and Jordi G. H.'s exchange this month:

] > If you disagree with the determination of the Developers, you can
] > easily install the work from non-free, or cease supporting Debian in
] > its entirety. The choice is yours, really.
] 
] "Our way or the highway" isn't a nice thought either. Do you really
] think that the DDs that voted against putting the GFDL in non-free
] should fork off too? Debian is the best distro out there, and I'm very
] loyal to it, but I'malso  very unhappy with its treatement of the
] GFDL, and I think this horrible mess should be fixed.

And no, to be fair, skimming the archives does indicate it's not the
"general attitude" at all, and I'm also pleased to have stumbled across
an example of Michael Poole noting he's not a lawyer or DD while giving
his thoughts/advice. Equally, if -legal were working 100% how I wanted
it to, that'd just mean I'd be happy to trust it implicitly and wouldn't
pay any attention to it at all; which probably means that the times
I do pay attention now are the times it's going (imo) severely wrong,
which is going to produce a pretty biassed view on my behalf.

Comparing Ted Tso's and Thomas Bushnell's views, as cited on LWN some time
ago [0] is probably a good reference point too. Having disagreements like
the current one over choice of venue be escalated into claims that are
one set of DDs are trying to "prov[e] they are Holier Than Stallman",
or another are "sell[ing] out [freedom]" isn't very helpful if we want
the DFSG to be useful at helping upstreams and users.

In *my* opinion, and ymmv etc, analysing licenses so that we can say:

* These are almost certainly the effects, which barely anyone
  disagrees with (GPL is viral, CDDL is viral and GPL
  incompatible, QPL requires modifications to be made as patches)

* These are things that might not happen, but that you might be
  concerned at (GFDL stuff can't be encrypted, or even have Unix
  permission bits set? CDDL leaves you vulnerable to nuisance
  suits in foreign countries)

* These are ways you can avoid some of the drawbacks (use
  MIT instead of the old BSD license, explicitly limit when
  "choice of venue" comes into play)

* Different people and organisations may reasonably have different
  views on the acceptability of various effects -- the FSF view
  the Affero GPL and GFDL as free, OSI views the APSL as free;
  and you may want to make a different choice to any or all of
  those organisations. Debian's choices are focussed on ensuring
  we can develop and distribute a high quality operating system
  that works for our users. This may mean we'll accept some
  licenses that aren't as free as we'd like them to be, in
  some cases (such as licenses with patch clauses, or obnoxious
  advertising clauses, etc).

From what I've seen, debian-legal isn't very good at accepting anything
less free than it'd like. Which is pretty understandable, but not really
helpful either in advocating Debian's views (which are more accepting),
or in working with other groups (upstream or down) who don't have the
patience for endless nitpicking.

I

Re: License discussions in Debian

[Anthony Towns]

On Tue, Jun 05, 2007 at 12:07:52PM +0200, Frank K?ster wrote:
> You could ask Anthony whether you're allowed to publish his reasons on
> -legal.  That would do the project a great favor.

You could just ask me directly you know...

] > I thought choice-of-venue is non-free by default?
] 
] Via Simon Phipps's talk at debconf, we've got Sun on the record
] as interpreting "choice of venue" as only being relevant when the
] two parties to a suit both have a presence in multiple jurisdictions,
] including the one that's "chosen", which means it's not a problem at all.
] 
] For the other case, even if Sun did want to make German laws apply to
] an Australian or similar, I don't think that holds up as a claim anyway.

I don't think that's a particularly useful addition to what's already
been in this thread. Well, beyond as inspiration as to how much better
-legal could do if it was willing to come to with a conclusion of the
form "this license is flawed in these novel ways, but none of them are
enough to make it non-free for Debian".

Cheers,
aj



signature.asc
Description: Digital signature

Re: Reasonable maximum package size ?

[Anthony Towns]

On Tue, Jun 05, 2007 at 06:28:53PM +0900, Charles Plessy wrote:
> Le Tue, Jun 05, 2007 at 10:09:07AM +0200, Michael Hanke a ?crit :
> > My question is now: Is it reasonable to provide this rather huge amount
> > of data in a package in the archive?
> > An alternative to a dedicated package would be to provide a
> > download/install script for the data (like the msttcorefonts package)
> > that is called at package postinst.
> I recently had a heretic idea that I did not dare to submit yet: we
> could port fink to Debian, and use it to build .debs from info files
> shipped in Debian packages in main, and sources downloaded from
> upstream's FTP sites.

Some thoughts on constraints:

* it's better to have stuff distributed by Debian than sourced
  elsewhere; we're a distribution, distributing is What We Do

* it's better for users to have stuff in .deb's, so they don't
  have to worry about different ways of managing different stuff
  on their system

* some large data sets are just "compiled" -- it can be good to
  distribute a small amount of source in a .deb and compile
  it on the user's machine.

* some large data sets are "compiled" but it takes long enough that
  we don't want to do it on user's machines, so we have the usual
  source/deb situation here, and that's fairly easy too.

* (***) many data sets don't fit those patterns though, but
  instead are just a bunch of data that needs to be shipped to
  users. doubling that by having it duplicated in a .orig.tar.gz
  and _all.deb is less than ideal

* some data sets have large raw data and large compiled versions,
  so need a large source _and_ a large .deb containing different
  info. nothing much to be done in that case, though

* (###) having .deb's generated on a user's system means they
  can't use aptitude or apt-get to install them easily; having
  .deb's generated on mirrors requires smart mirroring software
  rather than just rsync or similar; having .deb's generated by
  the maintainer or buildds requires both the source and .deb
  to be mirrored separately; having .deb's be the source format
  requires converting from the upstream source format adding
  complexity and making it harder to trace how the packaging
  worked

For the ***'d case, it seems like having a debian.org mirror network
that distributes unprocessed data tarballs, that're converted into debs
and installed on user's systems would be workable.

I don't see how we could resolve that with the ###'d concern though.

If we were to resolve the ###'d concern by changing apt etc, we could
conceivably add foobar_1.0.7-1_data.tar.bz2 files to the archive in the
existing sections, for instance, and providing some form of "Packages.gz"
file for them.

I guess an evil solution to *** that doesn't cause problems with ###
would be to create a dummy source package that Build-Depends: on the
exact version of the package it builds, so that uploads include a
basically empty .tar.gz that just has instructions on how to download
new versions of the data, and an unprocessed copy of the actual data
converted to _all.deb form. That'd give the correct behaviour for all
the tools we've got, avoid unnecessarily duplicating the data, and maybe
not be *too* confusing.

Hrm, actually, I kind-of like that approach...

I'm not sure if avoiding duplicating the data (1G of data is bad, but
1G of the same data in a .orig.tar.gz _and_ a .deb is absurd) is enough
to just use the existing archive and mirror network, or if it'd still be
worth setting up a separate apt-able archive under debian.org somewhere
for _really_ big data.

Bug#38902 for hysterical interest, btw.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Accepted cowdancer 0.29 (source amd64)

[Loïc Minier]

On Tue, Jun 05, 2007, Loïc Minier wrote:
>  Thanks; I think I found the reason of the problem: I used to call
>  cowbuilder like this:

 (Ups; sent to debian-devel because I hit reply in a
 debian-devel-changes mail thinking it would behave like a commit mail.)

-- 
Loïc Minier


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

Re: Accepted cowdancer 0.29 (source amd64)

[Loïc Minier]

On Tue, Jun 05, 2007, Junichi Uekawa wrote:
>* qemubuilder, cowbuilder: 'set -e' when sourcing configuration file.

 Thanks; I think I found the reason of the problem: I used to call
 cowbuilder like this:

#  /usr/sbin/cowbuilder --update --configfile 
/home/lool/.pbuilder/sid.pbuilderrc --buildplace 
/home/lool/.pbuilder/build/sid/cow.3197 --basepath 
/home/lool/.pbuilder/basepath/sid/base.cow

 But recent cowbuilder support "--configfile", so they started eating
 --configfile; I changed cowdancer 0.29 to pass through --configfile,
 and everything is fixed here again; pfiu.

 Perhaps it should work even when not passing --configfile, but here it
 doesn't; I do have a very complex setup though.

-- 
Loïc Minier


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

Re: discussion with the FSF: GPLv3, GFDL, Nexenta

[MJ Ray]

Anthony Towns <[EMAIL PROTECTED]> wrote: [...]
> That's mostly because -legal won't even say that the GPLv2 is DFSG-free,
> except in so far as it's explicitly listed as being DFSG-free.

Got a reference for that?

GPLv2 is a very frequently-suggested DFSG-free licences, has been the
subject of repeated analysis, http://lists.debian.org/search.html
is in the FAQ, http://people.debian.org/~bap/dfsg-faq
the web page http://www.uk.debian.org/legal/licenses/
and probably other places.

I don't think it's particularly interesting that periodically posters pop
up on debian-legal thinking they've spotted a new flaw in GPLv2.  I expect
that [EMAIL PROTECTED] gets a number of those too - debian's difference is its
openness.  I think almost all of them end up agreeing once it's explained
clearly.

Hope that explains,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: discussion with the FSF: GPLv3, GFDL, Nexenta

[MJ Ray]

Anthony Towns <[EMAIL PROTECTED]> wrote: [...]
> and a vaguely interesting note is:
> 
>   * actually suing based on the license might be complicated by a
> choice of venue
> 
> That you can argue the latter is analogous to a "fee" isn't really
> very interesting. That some people are concerned about it is more so,
> though so far the only concrete concern I've seen is MJ's comment --
> "A possible arbitrary lawyer-fee-bomb, depending on the venue specified
> and its sanity." and that's not really very concrete either.

How about a reference for that quote?  I suspect it's from an analysis
of the CDDL rather than a package, so it's not concrete because this
needs to be checked for each venue used by an actual package.

AIUI, star specifies Berlin, Germany, so I think
Message-ID: <[EMAIL PROTECTED]>
is maybe relevant and any EU venue could be a problem for us.

So the other thing that needs checking is how those courts will behave
if an unjustly-accused distributor does not attend court or employ a
representative to attend.  Any German-speakers willing to point us at
a relevant gov.de document?  My German language skills are not up to
navigating legal German safely.

I'm also worried by '3.4. Application of Additional Terms' discriminating
against commercial support, but it only becomes a concrete problem if the
Initial Developer or any Contributor has authorised support agents.

> No, punting to a GR [...] ends up with -legal
> folks complaining that the resolution doesn't make sense.

I think that most are reasonable and do that only if the resolution
includes no explanation.


> ] From: Anthony DeRobertis <[EMAIL PROTECTED]>
> ] Subject: Re: Results for Debian's Position on the GFDL
> ] Date: Sun, 12 Mar 2006 17:15:40 -0500
> ] [...]
> ] Alas, now that pi != 4*atan(1), how shall we proceed? Interpreting
> ] licenses and the DFSG is nowhere near as clear as mathematics and,
> ] unfortunately, just ignoring the GR would, I think, make us look like
> ] sore losers.
> 
> because clearly everyone who voted for the winning option is the sort
> of person who would think pi can be redefined willy-nilly, or that the
> only reason to respect the GR is to avoid looking like sore losers...

Anthony DeRobertis himself seemed to accept the above quote was hyperbole:
] It isn't quite as bad as pi = 3, as there is certainly some abiguity in
] both the DFSG and the GFDL.
Message-ID: <[EMAIL PROTECTED]>

Can't we can both respect the GR as a project and let individual Developers
note that they don't understand it?  As I wrote at the time:

] It should be noted that even though the Standard Resolution
] Procedure resolved the disagreement, a 211:145 (roughly 3:2) split
] when comparing the first two options is hardly a great consensus.
] There remains a deep division over whether FDL'd works follow DFSG.

Anyway, I welcome aj's realisation that giving good references is vital
and I ask everyone to do that.  I just wish his posts had more!

Regards,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: Dependencies on shared libs, take 2

[Steve Langasek]

On Tue, Jun 05, 2007 at 08:07:20AM +0200, Mike Hommey wrote:
> On Mon, Jun 04, 2007 at 02:32:10PM -0700, Steve Langasek <[EMAIL PROTECTED]> 
> wrote:
> > On Mon, Jun 04, 2007 at 10:29:07PM +0200, Josselin Mouette wrote:
> > > Le lundi 04 juin 2007 à 21:29 +0200, Raphael Hertzog a écrit :
> > > > > Again, this doesn't take into account existing symbols that change 
> > > > > their
> > > > > ABI across versions. I won't insist too much, as I have already
> > > > > explained at large how heavy a burden it puts on the maintainer's
> > > > > shoulders.

> How ironic the proper solution to this would be to use C++ symbol
> mangling

Two types can be ABI-compatible in C (on some or all architectures), but
have different representations in C++ symbol mangling.

> > > I agree that the benefits are worth the deal, but we should make clear
> > > that the price to pay for these benefits is a continuous effort from the
> > > maintainer. Therefore it should not be used by maintainers not aware of
> > > its subtleties. 

> > Considering the number of bugs I see because of maintainers who don't notice
> > they need to change package names due to upstream soname changes, or who
> > routinely fail to bump their shlibs when new symbols are added, I think
> > there is definitely room here for a recommended solution for maintainers
> > that aren't watching the subtleties, even without trying to bump
> > dependencies based on API extensions.

> I think only a very small subset of libraries actually will benefit
> having a symbols file. Most libraries and programs will benefit from
> their dependencies having one, though.

Well, I think that's exactly the point of the exercise; the benefit is for
the reverse-deps, not for the libs themselves.  I don't know about you, but
I generally don't work on libs for their own sake. :)

> I'm not a big fan of the global approach, though it can help having
> figures. I would rather see this as a tool to enhance shlibs for
> carefully selected libraries. For instance, I would first target
> libraries with the most reverse dependencies.

Good candidates for early adoption would probably be libraries with:

- active maintainers
- stable sonames
- frequent API extensions
- many reverse-deps

So obviously glibc is at the top of the list, but it's also trickiest due to
per-arch symbol differences. :)

> Finally, why not add the symbol informations to the shlibs file (that
> can be done in a backwards compatible way) instead of creating yet
> another control file ?

I'd rather we didn't, even if it doesn't break anything it still abuses the
shlibs file format as defined in policy.  And what happens if you
(improbably) have an overlap between a library name and a symbol name?

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


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

Bug#427630: ITP: ingimp -- Instrumented version of the GNU Image Manipulation Program

[Francois Marier]

Package: wnpp
Severity: wishlist
Owner: Francois Marier <[EMAIL PROTECTED]>

* Package name: ingimp
  Version : 2.2.15.20070604
  Upstream Author : Michael Terry <[EMAIL PROTECTED]>
* URL : http://www.ingimp.org/
* License : GPL
  Programming Lang: C, Python
  Description : Instrumented version of the GNU Image Manipulation Program

 ingimp is an instrumented version of the GNU Image Manipulation Program that 
collects real-time 
 usability data, such as the commands used, the size of images worked on, and 
so on. This 
 usability data is automatically transmitted to ingimp.org for anyone to 
download and analyze.
 .
 It is meant to be a snap-in replacement for the GIMP, so it can be used for 
normal, everyday image 
 manipulation tasks. By using it, the user and developer communities can gain 
new insights into how
 the GIMP is actually used "in the wild." This information, in turn, has the 
potential to feed into
 future design and development efforts. Thus, you have the chance of 
contributing to open usability
 efforts simply by using ingimp as you would the regular version of the GIMP.
 .
 Homepage: http://www.ingimp.org

Two files will be included in /usr/share/doc/ingimp:

- See consent.txt for the conditions related to the collection of data in this 
project.  Note that this is
  entirely optional and that no data will be collected unless you give your 
consent.

- README.privacy explains what kind of data is collected and what is done to 
protect your privacy.


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

Re: Reasonable maximum package size ?

[Frank Küster]

[EMAIL PROTECTED] (Marco d'Itri) wrote:

>> > Also, you should think about this issue not just in the context of the
>> > single package you are interested in but as a general policy.
>> I was hoping to give that impression...
> Then it should be obvious that it's a bad idea to add to the archive
> multiple packages each containing hundred of megabits of data which are
> only useful for a few users.

In my view, there's a problem with this argument.  Fortunately, the core
of a Debian GNU/Linux system consists of reasonably small packages.  A
large scatter notwithstanding, larger (source) packages tend to have
less users (compare bash - XOrg - KDE).  So it's not surprising that
some of the packages with comparably small user base (games, scientific
data) have a large size.

On the other hand, if we want the best operating system in the world to
also be great for playing games and for doing scientific research, we
should care about these user groups, too.  They might get larger
finally, and even if they continue to be a small proportion, it's worth
supporting them.

I guess gamers and scientists are also similar in that they want the
software to simply work, and not bother too much with additional
installations.  Therefore, providing apt-get'able packages for them is
important.  Even if we can't do it in our usual infrastructure.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: License discussions in Debian

[Frank Küster]

Thomas Weber <[EMAIL PROTECTED]> wrote:

> Am Dienstag, 5. Juni 2007 09:08:31 schrieb Frank Küster:
>> Anthony Towns <[EMAIL PROTECTED]> wrote:
>> > On Mon, Jun 04, 2007 at 11:08:39PM +0200, Frank K?ster wrote:
>> And a mail like
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350624;msg=142;att=0
>> is not only not-helpful-at-all, it's really discouraging to see a
>> discussion ending like this.  Well, in that particular case I'd
>> understand if you don't answer to the bug, but the reasoning could be
>> published elsewhere where Mr. $greps_for_his_name_on_debian_lists cannot
>> answer easily.
>
> I was the bug submitter. I asked Anthony in private mail and he gave a few 
> reasons. I'm not really convinced by them, but in the end, it's not my 
> responsability. I just make sure I don't install star on my systems and I'm 
> done with it. If everyone else (maintainer, ftp-masters, mirror 
> operators, ...) is happy with it, why should I bother any longer?

You could ask Anthony whether you're allowed to publish his reasons on
-legal.  That would do the project a great favor.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Reasonable maximum package size ?

[Andreas Tille]

On Tue, 5 Jun 2007, Marco d'Itri wrote:


Then it should be obvious


   obvious = common sense

... but the "commons sense" has to be defined in a technical document.


that it's a bad idea to add to the archive
multiple packages each containing hundred of megabits of data which are
only useful for a few users.


So you propose "hundred of megabits" as the size border?
Could you please be more verbose on "a few".

Please stop teaching people who try to discuss a problem by
dead beat arguments and give precise numbers as answers if
you have any.

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: Bug#427558: ITP: fenix0.92 -- development environment for making 2D games

[paddy]

> * Package name: fenix0.92

That's a fab name for a piece of software, isn't it ?
I'm surprised it hasn't been used more often :-)

Regards,
Paddy


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

Re: Dependencies on shared libs, take 2

[Steve Langasek]

On Tue, Jun 05, 2007 at 08:56:40AM +0200, Raphael Hertzog wrote:
> On Mon, 04 Jun 2007, Steve Langasek wrote:
> > On Mon, Jun 04, 2007 at 10:29:07PM +0200, Josselin Mouette wrote:
> > > I agree that the benefits are worth the deal, but we should make clear
> > > that the price to pay for these benefits is a continuous effort from the
> > > maintainer. Therefore it should not be used by maintainers not aware of
> > > its subtleties. 

> > Considering the number of bugs I see because of maintainers who don't notice
> > they need to change package names due to upstream soname changes, or who
> > routinely fail to bump their shlibs when new symbols are added, I think
> > there is definitely room here for a recommended solution for maintainers
> > that aren't watching the subtleties, even without trying to bump
> > dependencies based on API extensions.

> Would you care to elaborate? (What would you recommend? How do you expect
> it to improve the situation with those maintainers?)

Maintaining library symbol files with a tool that updates the symbol lists
with behavior analogous to dh_makeshlibs -V would be a significant
improvement over either dh_makeshlibs -V (force a shlibs bump for every
rev), or dh_makeshlibs alone (get too weak shlibs for any API additions).

Throwing a sensible error at build-time if the soname has changed without a
package name change is also something that needs to be done, as well as
throwing an error at build-time if symbols listed in the symbols file have
gone missing; I don't see these features mentioned in your proposal, but I
think they're part and parcel of a good implementation of what you're
describing.

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


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

Re: Reasonable maximum package size ?

[Marco d'Itri]

On Jun 05, Michael Hanke <[EMAIL PROTECTED]> wrote:

> I believe this is a valid problem. I think that is exactly the reason why
> the Debian archive also provides the sources of each package
> (orig.tar.gz) and does not simply point to the upstream sites while
> keeping only the diffs in the archive.
No, the main reason is GPL compliance.

> > Also, you should think about this issue not just in the context of the
> > single package you are interested in but as a general policy.
> I was hoping to give that impression...
Then it should be obvious that it's a bad idea to add to the archive
multiple packages each containing hundred of megabits of data which are
only useful for a few users.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#426874: ITP: pkg -- High-level library for managing Debian package information

[Enrico Zini]

On Tue, Jun 05, 2007 at 11:08:17AM +0200, Stefano Zacchiroli wrote:

> > After some discussion in #debian-devel, I went for 'upt'.
> Wow ... cool ... a TLA! ... except that I've no idea what does it mean :-)
> But I guess I can wait to read the long description ...

You're late: it's ept now :)

http://lists.debian.org/debian-devel/2007/06/msg00103.html


Ciao,

Enrico

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


signature.asc
Description: Digital signature

Re: discussion with the FSF: GPLv3, GFDL, Nexenta

[Steve Langasek]

On Mon, Jun 04, 2007 at 08:17:42PM +1000, Anthony Towns wrote:
> On Mon, Jun 04, 2007 at 01:13:44AM -0700, Steve Langasek wrote:
> > It is a freedom that I have by default; if I accept the CDDL I no longer
> > have that freedom[1].  [...]
> > [1] Technically, not the right to "choose a venue", but the right to not be
> > sued in a venue where I have no legal presence.

> Err, that's not a violation of your rights, it's a waste of the court's
> time... If the court doesn't see it as a waste of its time, and issues
> you with a summons anyway, you're involved. Cf [0]. You might as
> well say you've got the "right" not to be flamed on a list you're not
> subscribed to.

Addressing a flame to me that I will never see does me no harm.  I would say
that I have the right to not be *slandered* on a list that I'm not
subscribed to; given the trends toward globalization and data mining of
citizens, I wouldn't assume at all that a default judgement against me in
some foreign land is equivalent to an unseen flame instead of an unseen
slander.

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


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

Re: Reasonable maximum package size ?

[Pierre Habouzit]

On Tue, Jun 05, 2007 at 10:27:26AM +0200, Marco d'Itri wrote:
> On Jun 05, Michael Hanke <[EMAIL PROTECTED]> wrote:

> >  - diskspace is rather cheap and bandwith should be no problem as the
> >number of downloads will remain relatively low.
> Diskspace *is* a problem for mirrors, as is bandwidth in many countries.
> Also, you should think about this issue not just in the context of the
> single package you are interested in but as a general policy.

  Honnestly, no, this is not true anymore nowadays. With a 500Gb sata
hard drive, you're able to have a full debian mirror (all archs). Such a
disk is around 100€ nowadays. There is even machines that now have
enough ram to put an arch+all mirror in a ramdisk (though they cost a
bit more than 100€ ;p).

  So please, yest this was an issue not to long ago. Now ? no it's not.

  No, the real issue IMHO is indeed bandwidth, as this is still a quite
expensive resource.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpLl79I7b2Oo.pgp
Description: PGP signature

Re: Reasonable maximum package size ?

[Charles Plessy]

Le Tue, Jun 05, 2007 at 10:09:07AM +0200, Michael Hanke a écrit :
> 
> My question is now: Is it reasonable to provide this rather huge amount
> of data in a package in the archive?
> 
> An alternative to a dedicated package would be to provide a
> download/install script for the data (like the msttcorefonts package)
> that is called at package postinst.

Hi Michael,

many thanks for bringing this crucial question on -devel. In my field, I
wish that it would be possible to apt-get install the human genome for
instance.

I recently had a heretic idea that I did not dare to submit yet: we
could port fink to Debian, and use it to build .debs from info files
shipped in Debian packages in main, and sources downloaded from
upstream's FTP sites.

This way, we would not exponentialy inflate the size of the Debian
mirrors, while benefiting of the full strengh of Debian's package
management system.

 The Fink project: http://finkproject.org

 An example of info file : 
http://bindist.finkmirrors.net/bindist/dists/10.4/release/main/finkinfo/sci/emboss.info

Bug reporting could be done on the Debian package containing the info
files.

In the case of scientific databases, the "sources" are hosted on FTP
sites which usually have more bandwith than the internal network of the
lab I am working in. I understand the opinion that duplicating this
would be a waste.

The use of the fink system would permit to depend on the correct Debian
packages to post-process the databases and install them where expected.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan


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

Re: discussion with the FSF: GPLv3, GFDL, Nexenta

[Steve Langasek]

On Sun, Jun 03, 2007 at 10:54:38PM +1000, Anthony Towns wrote:
> On Sun, Jun 03, 2007 at 04:51:40AM -0700, Steve Langasek wrote:
> > On Sun, Jun 03, 2007 at 12:25:14PM +0200, Wouter Verhelst wrote:
> > > Additionally, personally I don't think it's unreasonable for people to
> > > say "if you use my software in a way that I didn't want you to, I'll sue
> > > you in a court that works by a set of rules that I'm actually
> > > comfortable with". You know, it makes fighting those who do not follow
> > > your license the way you intended them to quite a bit easier.
> > That's a strawman.  The objection raised to choice-of-venue clauses is not
> > what they specify to happen when the licensee has *infringed* the license,
> > it's what they specify to happen when the licensee *hasn't* infringed the
> > license but the copyright holder files a lawsuit against them anyway out of
> > malice.

> I don't think that's meaningful; if I sue you in a court in Australia
> for not complying with debootstrap's license, and they find that you've
> infringed the license, it doesn't really matter if I'm doing that out
> of maliciousness or a genuine.

Why doesn't it matter?  If I've been sued because of something I've actually
done that infringed the license, then surely the DFSG and Debian shouldn't
be concerned with that (other than the question of whether what I've done is
something that the DFSG requires of copyright holders); but if I'm being
sued over something I *didn't* do, isn't it relevant that this license
clause is going to cost me something that I wouldn't otherwise have to give
up, just because the copyright holder has taken a dislike to me?

- If I don't have the resources to fight the case in a court overseas, I
  risk summary judgement; the cost to me is the liberty to travel unmolested
  to Australia at some future date when I might have resources for travel.
- If I do have the resources to fight the case overseas, I can file a motion
  to dismiss based on improper venue, which as a consequence of this license
  clause may or may not be accepted.
  - If the motion is granted, I can presumably ask for the plaintiff to pay
my legal costs; but I presumably can't ask for the plaintiff to
compensate me for my lost time (at least, this seems unlikely to be
granted by this court since the existence of the contract's clause is
likely to be a defense against assertions of bad faith; please correct
me if I'm wrong).
  - If the motion is denied, I'm stuck litigating in a foreign court, which
implies certain costs in time and money that I wouldn't otherwise have,
some of which are not recoverable legal expenses and some of which are
expenses that may not be awarded to the defendant in all jurisdictions
and in all circumstances (concrete references here would be welcome):
* If I get sued in Oregon, I have a wide range of local resources at my
  disposal to help me find appropriate legal representation; if I get
  sued in Australia, I'm stretching my connections pretty thin to find
  and evaluate legal counsel, and this process is going to cost more
  time and money on my part (and may leave me with inferior legal
  counsel anyway in the end due to logistical issues)
* Effective realtime communication with the lawyer is more expensive
  (transoceanic phone calls), and more inconvenient due to timezone
  differences (fine, fine, not for *me*, but you know what I mean)
* If I have to travel to Australia at any point during the suit, this
  is an expensive and time-consuming trip.

AFAICS, it's likely that the logistical problems of mounting a transoceanic
legal defense will also increase my up-front legal costs.  These costs are
recoverable if I win, but they may be large enough to make it infeasible for
me to take the lawsuit all the way to the end at all.  At least around here,
most suits end up being settled out of court due to the uncertainty of a
ruling in one's favor and the high cost of seeing litigation through;
increased legal expenses imply an increased probability of settling out of
court, which means the cost is whatever is specified in the settlement, plus
lost time, plus whatever legal expenses are incurred up to that point.

There's also the additional issue that an evil copyright holder may be more
likely in the first place to file a lawsuit that they know they can't win,
if they can do so in their own home jurisdiction at low cost to them with a
higher possibility of a default judgement or an out-of-court settlement.

I'll grant that the absolute theoretical minimum cost increase to someone
targetted by the copyright holder as a result of this clause is still zero
(and, in exceptional cases in exceptional jurisdictions, perhaps less than
zero).  But that looks to me like a pretty low-probabilty outcome; in spite
of the difficulties in measuring the probability of particular outcomes, or
their associated costs, I don't think they s

Re: Bug#426874: ITP: pkg -- High-level library for managing Debian package information

[Stefano Zacchiroli]

On Fri, Jun 01, 2007 at 11:01:16AM +0100, Enrico Zini wrote:
> > Great to see this!, but I'm rather scared about its name: isn't "pkg"
> > too generic? Wouldn't "debpkg" be a better (since more specific and
> > describing) name?
> After some discussion in #debian-devel, I went for 'upt'.

Wow ... cool ... a TLA! ... except that I've no idea what does it mean :-)
But I guess I can wait to read the long description ...

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


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

Re: Reasonable maximum package size ?

[Michael Hanke]

Hi,

On Tue, Jun 05, 2007 at 10:27:26AM +0200, Marco d'Itri wrote:
> On Jun 05, Michael Hanke <[EMAIL PROTECTED]> wrote:


> >  - much easier to handle for users (thinking of offline machines)
> I could not care less, since the number of users affected is with very
> good approximation zero.
Agreed.

> >  - if upstream goes offline, the relevant software package in the archive 
> > are
> >basically useless as the required datasets are not distributed anymore
> Create your own distribution site if you really believe this to be a
> problem.
I believe this is a valid problem. I think that is exactly the reason why
the Debian archive also provides the sources of each package
(orig.tar.gz) and does not simply point to the upstream sites while
keeping only the diffs in the archive.

> 
> >  - diskspace is rather cheap and bandwith should be no problem as the
> >number of downloads will remain relatively low.
> Diskspace *is* a problem for mirrors, as is bandwidth in many countries.
Right.

> Also, you should think about this issue not just in the context of the
> single package you are interested in but as a general policy.
I was hoping to give that impression...


Cheers,

Michael



-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050


signature.asc
Description: Digital signature

Re: Reasonable maximum package size ?

[Lars Wirzenius]

On ti, 2007-06-05 at 10:37 +0200, Andreas Tille wrote:
> We also have some funny 3D games with huge data packages.  So
> were is the borderline for this.  Does it make sense to install
> a data repository that is not mirrored? 

I suggest that it makes sense to a) package the data as .debs, for
easier management, b) not have it on the normal mirror network, and c)
use BitTorrent instead of (or in addition to) plain http. There is a
Google Summer of Code project in Debian this year to implement the
BitTorrent part, which might be ideal for the last part.

Having a data.debian.org to act as the master repository for such
packages would take care of the second part. It may require some setting
up of dak in difficult ways.

We already know how to do the first part.

-- 
I'm a Luddite with neophilia


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

Re: Reasonable maximum package size ?

[Andreas Tille]

On Tue, 5 Jun 2007, Marco d'Itri wrote:


Also, you should think about this issue not just in the context of the
single package you are interested in but as a general policy.


I think because Michael actually is thinking about a general
policy he just asked this question here.  He was asking for
a reasonable measure what is regarded as "to big".
The parameters are

   1. Size of package
   2. Estimated number of users

So I agree that a download package seems to be reasonable in the
situation Michael has described, but what is the general answer
to his question.

We also have some funny 3D games with huge data packages.  So
were is the borderline for this.  Does it make sense to install
a data repository that is not mirrored?  (Uhm, I think this is a
FAQ on debian-devel - at least I think I remember to have read about
this idea back in 2000 ...)

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: Reasonable maximum package size ?

[Miriam Ruiz]

2007/6/5, Michael Hanke <[EMAIL PROTECTED]>:


Hi,

I'm packaging some neuroimaging tools that come with datasets that
are required for those tools to work properly. The size of these
datasets is up to 400 MB (some others at least well over 100 MB).

My question is now: Is it reasonable to provide this rather huge amount
of data in a package in the archive?

An alternative to a dedicated package would be to provide a
download/install script for the data (like the msttcorefonts package)
that is called at package postinst.

Another alternative would be to provide a package like the
(googleearth-package)-package. This would have the advantage that the
users could easily build packages, that they can distribute themselves.


Arguments for download wrappers/package-maker would be:

- only the datasets fill yet another CD
- only very few people actually benefit from this package (it is a rather
   very-special-interest-package)
- datasets change infrequently
- saves a lot of diskspace in archive and mirrors

Arguments for a package:

- much easier to handle for users (thinking of offline machines)
- if upstream goes offline, the relevant software package in the archive
are
   basically useless as the required datasets are not distributed anymore
- diskspace is rather cheap and bandwith should be no problem as the
   number of downloads will remain relatively low.

There was already a little discussion about this, starting from here:

http://lists.debian.org/debian-devel/2007/05/msg00207.html


I'd like to hear you comments about this.



Some games, and number increasing, are in the same situation that you
describe. I do not have a proper solution to it, but I'm very interested in
possible ways to go, as the number of packages in this situation will keep
increasing.

Greetings,
Miry

Re: Reasonable maximum package size ?

[Marco d'Itri]

On Jun 05, Michael Hanke <[EMAIL PROTECTED]> wrote:

> My question is now: Is it reasonable to provide this rather huge amount
> of data in a package in the archive?
Not for a niche package, at least.

>  - much easier to handle for users (thinking of offline machines)
I could not care less, since the number of users affected is with very
good approximation zero.

>  - if upstream goes offline, the relevant software package in the archive are
>basically useless as the required datasets are not distributed anymore
Create your own distribution site if you really believe this to be a
problem.

>  - diskspace is rather cheap and bandwith should be no problem as the
>number of downloads will remain relatively low.
Diskspace *is* a problem for mirrors, as is bandwidth in many countries.
Also, you should think about this issue not just in the context of the
single package you are interested in but as a general policy.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#427610: ITP: gmobilemedia -- GTK application used to browse a mobile phone filesystem

[Michal Čihař]

Package: wnpp
Severity: wishlist
Owner: "Michal Čihař" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: gmobilemedia
  Version : 0.4
  Upstream Author : Iván Gabriel Campaña-Naranjo <[EMAIL PROTECTED]>
* URL : http://gmobilebrowser.sourceforge.net/
* License : GPL
  Programming Lang: Python
  Description : GTK application used to browse a mobile phone filesystem

gMobileMedia is a simple GTK application used to browse and handle a
mobile phone filesystem. It can handle phones with more than one memory
area (thanks to Gammu). It lets you easily upload and download images,
ringtones, photos, and applications to/from your mobile phone. All you
need is a data cable or any other connection method supported by Gammu.

- -- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (99, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGZRXD3DVS6DbnVgQRAsSZAJ4kHvNzglYbPgY/DjM4+MjneTGtmACeN/5u
0yf+Xr+bXjjVUQvp8iZaNlc=
=lqHh
-END PGP SIGNATURE-

Reasonable maximum package size ?

[Michael Hanke]

Hi,

I'm packaging some neuroimaging tools that come with datasets that
are required for those tools to work properly. The size of these
datasets is up to 400 MB (some others at least well over 100 MB).

My question is now: Is it reasonable to provide this rather huge amount
of data in a package in the archive?

An alternative to a dedicated package would be to provide a
download/install script for the data (like the msttcorefonts package)
that is called at package postinst.

Another alternative would be to provide a package like the
(googleearth-package)-package. This would have the advantage that the
users could easily build packages, that they can distribute themselves.


Arguments for download wrappers/package-maker would be:

 - only the datasets fill yet another CD
 - only very few people actually benefit from this package (it is a rather
   very-special-interest-package)
 - datasets change infrequently
 - saves a lot of diskspace in archive and mirrors

Arguments for a package:

 - much easier to handle for users (thinking of offline machines)
 - if upstream goes offline, the relevant software package in the archive are
   basically useless as the required datasets are not distributed anymore
 - diskspace is rather cheap and bandwith should be no problem as the
   number of downloads will remain relatively low.

There was already a little discussion about this, starting from here:

http://lists.debian.org/debian-devel/2007/05/msg00207.html


I'd like to hear you comments about this.


Thanks,

Michael


-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050


signature.asc
Description: Digital signature

Re: License discussions in Debian

[Thomas Weber]

Am Dienstag, 5. Juni 2007 09:08:31 schrieb Frank Küster:
> Anthony Towns <[EMAIL PROTECTED]> wrote:
> > On Mon, Jun 04, 2007 at 11:08:39PM +0200, Frank K?ster wrote:
> And a mail like
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350624;msg=142;att=0
> is not only not-helpful-at-all, it's really discouraging to see a
> discussion ending like this.  Well, in that particular case I'd
> understand if you don't answer to the bug, but the reasoning could be
> published elsewhere where Mr. $greps_for_his_name_on_debian_lists cannot
> answer easily.

I was the bug submitter. I asked Anthony in private mail and he gave a few 
reasons. I'm not really convinced by them, but in the end, it's not my 
responsability. I just make sure I don't install star on my systems and I'm 
done with it. If everyone else (maintainer, ftp-masters, mirror 
operators, ...) is happy with it, why should I bother any longer?

Thomas

Re: License discussions in Debian

[Frank Küster]

Anthony Towns <[EMAIL PROTECTED]> wrote:

> On Mon, Jun 04, 2007 at 11:08:39PM +0200, Frank K?ster wrote:
>> I think that Debian would very much benefit if there was a place (call
>> it [EMAIL PROTECTED] or whatever) where our policy with regard to
>> individual software's licenes could be discussed with the input of those
>> who actually set this policy: the ftpmasters.
>
> Yes, that's the main reason for my involvement in this thread.
>
> Though it's not just ftpmasters, it's Debian developers in general; so
> that we don't end up with a consensus on debian-legal (or in ftpmaster)
> that doesn't match the views of Debian as a whole.

That's true, as an ideal.  In reality, you can't expect every DD or even
maintainer to subscribe to -legal except when they've got a particular
problem to discuss.  In this case it's a pity when you finally get the
impression that what you are told there neither matches the opinion of
the majority of your colleagues, nor of the ftpmasters - but the
ftpmasters' opinion is more insteresting for you in that case.

> AFAICS, that means welcoming developers who don't know the difference
> between "subpoena" and "summons", not using it as a reason to ignore
> them completely.

Definitely - if the NM process works as it should, at least every DD who
entered since it's been established should have a working understanding
of licensing, and that should be enough to *start* a discussion.  

I'm not sure, however, that this is the general attitude on -legal: I've
never encountered it.  Instead, I had the feeling that it was in
particular directed at you, since you seemed to claim to have better
understanding of the legal situation than your counterpart, and use that
as an argument for your position: In which case I can well understand
that the counterpart argues against this "better understanding".

>> If debian-legal isn't the place for you (and AFAIK none of the other
>> ftpmasters is a regular), maybe we need a new start and a different
>> format.  
>
> I used to be a regular on -legal, and I'm still subscribed. My views
> (such as "people who aren't speaking on behalf of the project shouldn't
> make it sound like they are"...) don't seem particularly welcome though,
> so I tend not to bother.

I don't expect that you engage in all those discussions.  But I remember
several cases where ftpmasters were mentioned on -legal, either in a
phrase like "finally, you'd have to ask the ftpmasters", or in
complaints like "the ftpmasters appear to have a different opinion, but
we don't know why".  In these cases, it would be really helpful if one
of you could step up and take part in the discussion.

And a mail like
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350624;msg=142;att=0
is not only not-helpful-at-all, it's really discouraging to see a
discussion ending like this.  Well, in that particular case I'd
understand if you don't answer to the bug, but the reasoning could be
published elsewhere where Mr. $greps_for_his_name_on_debian_lists cannot
answer easily.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)