Re: Problems found by piuparts

2006-02-20 Thread Lars Wirzenius
I added a Cc to Manoj since I would like to hear his comment. Whoever
responds may want to remove the Cc to avoid stuffing his inbox
unnecessarily.

su, 2006-02-19 kello 23:42 -0800, Steve Langasek kirjoitti:
> On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote:
> > * Use of ucf in postrm during a purge, without checking that ucf
> > is installed. Since ucf is not an essential package, postrm
> > during purge cannot rely on it. As it happens, I think it might
> > be good to have ucf (or a subset of it) as an essential package,
> > since this error happens a lot.
> 
> So assuming that we're stuck with the current implementation for a bit where
> ucf is not part of essential, I do wonder if checking whether ucf is
> installed is actually the correct thing to do in postrm purge.  The state
> prior to purge is defined as "config files"; the difference between config
> files state and "purged" is whether there are still config files left on the
> system.  If the package can't actually succeed in removing its config files
> because ucf is not installed, isn't it *correct* for the postrm purge
> command to fail?  I.e., I think it's more of a bug to allow dpkg to put the
> package into "purged" state leaving orphaned config files behind than it is
> for postrm purge to fail and leave the package in "config files" state.

Hm. I don't use ucf on my own packages (yet), so my understanding is a
bit hazy, but if I have understood correctly, the actual config file is
removed with rm anyway, and ucf is needed on purge only to remove the
config file also from ucf's history data. Thus, only running ucf if it's
there should be the right thing.

Manoj, could you comment on this?

-- 
Yet another password: just say no.


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



Re: Problems found by piuparts

2006-02-20 Thread Frank Küster
Lars Wirzenius <[EMAIL PROTECTED]> wrote:

> Hm. I don't use ucf on my own packages (yet), so my understanding is a
> bit hazy, but if I have understood correctly, the actual config file is
> removed with rm anyway, and ucf is needed on purge only to remove the
> config file also from ucf's history data. Thus, only running ucf if it's
> there should be the right thing.

Yes, one has to care about manual removing, anyway, and if ucf is
already removed or purged, its database is already gone, so there's no
point in calling it.

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



Re: AT&T Korn Shell

2006-02-20 Thread Andrew Porter




On Sat, 2006-02-18 at 14:19 +0100, Josh Hurst wrote:



Does the Debian ksh93 package include libast and libshell?



No - 

dpkg -L ksh
/.
/bin
/bin/ksh93
/usr
/usr/bin
/usr/bin/shcomp
/usr/share
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/ksh93.1.gz
/usr/share/man/man1/shcomp.1.gz
/usr/share/man/fr
/usr/share/man/fr/man1
/usr/share/man/fr/man1/shcomp.1.gz
/usr/share/ksh
/usr/share/ksh/functions
/usr/share/ksh/functions/dirs
/usr/share/ksh/functions/popd
/usr/share/ksh/functions/pushd
/usr/share/doc
/usr/share/doc/ksh
/usr/share/doc/ksh/OBSOLETE
/usr/share/doc/ksh/example.kshrc
/usr/share/doc/ksh/copyright
/usr/share/doc/ksh/COMPATIBILITY.gz
/usr/share/doc/ksh/RELEASE.gz
/usr/share/doc/ksh/RELEASE88.gz
/usr/share/doc/ksh/RELEASE93.gz
/usr/share/doc/ksh/PROMO.mm.gz
/usr/share/doc/ksh/changelog.Debian.gz
/usr/share/menu
/usr/share/menu/ksh






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


Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Peter Samuelson

[Kevin Mark]
> if a piece of software was initially created to enable the use of
> non-dfsg software with a dfsg system it is classified as 'ícontri',
> but then someone creates dfsg-software to use this software, now its
> classified as 'main'. Would this follow?

You're trying to sneak in an unspoken premise: namely, that there is
reason to believe ndiswrapper would ever be used with a free driver.  I
claim that this is ridiculous.  As far as I've ever heard, free Linux
drivers get written much faster than free Windows drivers.

If, as I claim, it's exceedingly unlikely that ndiswrapper would ever
be used to run free software, it is pure pedantry to say "but, but,
but, you *could* use it for that".


> But it also seems that the dfsg-use is not an absolute condition, it
> has to be deem non-toy and useful which is not an easily agreed upon
> idea.

You seem to be arguing that the Social Contract doesn't say that our
software must be of any use.  What you're forgetting is that it also
doesn't say we *should* ship useless things.  Common sense would seem
to indicate that we not do so.

I don't see a meaningful distinction between "non-functional without
non-free software" and "pointless without non-free software".  Either
way, that's the primary reason we have contrib.


signature.asc
Description: Digital signature


Re: TrueType fonts packages maintenance team proposal

2006-02-20 Thread Mohammed Adnène Trojette
On Mon, Feb 20, 2006, Christian Perrier wrote:
> ttf-arabeyes - Arabeyes GPL TrueType Arabic fonts
> ttf-kacst - KACST free TrueType Arabic fonts
> ttf-paktype - PakType free OpenType Urdu fonts

I am maintaining those three, and would really be happy to know what are
the other maintainers best practices in maintaining fonts.

As I am not a big font expert too, such a team will be a way to learn a
lot. To sum up, count me in!

-- 
adn
Mohammed Adnène Trojette


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



Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Jérôme Warnier
[..]

> Ndiswrapper probably is better compared to such drivers than to wine
> or dosemu.
I'm sorry, but Wine and Dosemu can run free softwares (respectively for
Windows and DOS), so they are not unuseful without proprietary
softwares.
I can't think of any free NDIS driver, but if such thing exists,
NDIS-wrapper should be allowed in main without any problem.

[..]


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



Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Peter Samuelson

  [Peter Samuelson]
> > There's a big difference between enabling someone to install
> > non-free software, and enabling someone to view data.  (Some of
> > which is free, some not.)  Also, in case this was your point, swf
> > content is sometimes generated with free tools such as ploticus.

[Michael Poole]
> What is the difference?  I thought GR 2004-003 was all about
> recognizing software as software, whether some people call it
> "documentation" or "programs".

I suggest you reread GR 2004-003, if you believe it was about defining
the term "software".  It was actually more to the tune of "We'll stop
using the term 'software' in certain places because it's ambiguous: not
everyone interprets it to mean the same thing."  If you were confused
by my use of the term "software" to mean "executable code", I
apologise; I'll try to be more precise in the future.  I thought it was
clear enough from context, but perhaps it wasn't.

Anyway, that's a minor point; the important distinction here is not
really whether something is programs or data.  You might be familiar
with the Doom video game, of which various implementations and forks
exist in Debian.  Until a free Doom "wad" file (the game data) was
created, the various Doom engines lived in 'contrib', because they were
useless without non-free data.  Nowadays, free data exists, so the Doom
programs are in main.

Of all the "data viewer" programs I can think of in Debian main, there
is ample reason to believe there exists content out there for each
which is either (a) free (and not useless), and/or (b) created by a
Debian user who would want to use Debian to view it.  I find it
extremely unlikely that the analogous situation is true of ndiswrapper.


> SWF may be generated with free tools, but under a strict reading of
> Policy, that is insufficient to qualify for main.

OK so I don't understand why you brought up a SWF viewer as an example.
I thought it was because the content is generated with non-free tools
like Macromedia Flash.  Apparently that's not it, since we are agreed
that this is not always so.  So how else does SWF differ from, say,
HTML?  What point were you trying to make about libflash?


> Again, there is no mention of "pointless" software in Policy -- if
> there were, some large fraction of main would be moved because it is
> duplicative, trivial or otherwise pointless to have.

No document I'm aware of requires that we ship all free software
whether or not it is useful.  As it happens, I've always been opposed
to pointless software in Debian.  It's hard, however, to get it kicked
out, because nobody wants to make the judgment call (the maintainer
obviously thinks the package has a use, even if nobody else does).

I'm sorry if you thought Debian was committed to shipping software with
no regard to whether it is useful; this has never been true, although
considering some of the fringe packages in the archive, I guess I can
see why you might get that impression.  But I'm sure you can see that
"Policy doesn't say we can't" is not equivalent to "Policy backs up my
argument that we should".


> Likewise, there is no mention of "Windows driver developers ... who
> really wish they could conveniently test their Windows drivers on
> Debian".

Without those developers, and without non-free software, I contend that
ndiswrapper is useless.  And see above for what I think of *that*.


signature.asc
Description: Digital signature


Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Peter Samuelson

[Eduard Bloch]
> I cannot remember a GR which says exactly this. Neither a GR which
> would clarify our definition of "firmware". And the one I follow is
> that it is more hardware than a software component.

Good.  If firmware is hardware rather than software, there is nothing
to discuss.  Debian doesn't distribute hardware.  (And since we don't
distribute it, there's no reason to argue about whether it's free or
not.)

If you think Debian should *distribute* firmware, that's pretty much an
admission that it is not hardware.


> I guess you mean that "Editorial changes" farce where the majority of
> the developers just did not participiate and still feel beeing
> cheated by its creators.

Come on.  The farce is that, two years later, people are _still_
complaining because they didn't read the thing they voted on, or that
they didn't bother to vote at all.  Can you all please stop?


> please file RC bugs against all kernel packages immediately. Their
> packagers allow people to run non-free software, we need to strike
> against this evil, now!

I know you're not that stupid.  You know very well that there is a
difference between something that _can_ work with both free and
non-free software, and something that _must_ use non-free software.
People have speculated that ndiswrapper "could be used with free
Windows drivers", but that seems not to be true, as nobody has been
able to find any free Windows drivers.  Oh, except the one nobody would
use, because it's a port of a native Linux driver which is already in
Debian.


signature.asc
Description: Digital signature


Bug#353688: ITP: Malayalam-Omega -- A package for typesetting Malayalam using Omega

2006-02-20 Thread Mahesh T. Pai
Package: wnpp
Severity: wishlist
Owner: "Mahesh T. Pai" <[EMAIL PROTECTED]>

* Package name: Malayalam-Omega
  Version : 1.0.0
  Upstream Author : Alex A. J.  <[EMAIL PROTECTED]>, C. V. Radhakrishnan 
<[EMAIL PROTECTED]>
* URL : http://malayalam.sarovar.org; 
http://sarovar.org/projects/malayalam.
* License : Latex Project Public License
  Description : A package for typesetting Malayalam using Omega

The Malayalam-Omega Package offers a set of macros and fonts for
typesetting Malayalam, which is the primary language of an estimated
33 million people in the South Indian state of Kerala.

This version of Malayalam-Omega provides the ability to typeset UTF-8
encoded text in Malayalam using LaTeX.

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


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



Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Hendrik Sattler
Am Montag, 20. Februar 2006 11:11 schrieb Jérôme Warnier:
> [..]
>
> > Ndiswrapper probably is better compared to such drivers than to wine
> > or dosemu.
>
> I'm sorry, but Wine and Dosemu can run free softwares (respectively for
> Windows and DOS), so they are not unuseful without proprietary
> softwares.

Read again, that's just what I said in the part that you deleted.

HS



Re: Bug#353688: ITP: Malayalam-Omega -- A package for typesetting Malayalam using Omega

2006-02-20 Thread Frank Küster
"Mahesh T. Pai" <[EMAIL PROTECTED]> wrote:

>   Description : A package for typesetting Malayalam using Omega
>
> The Malayalam-Omega Package offers a set of macros and fonts for
> typesetting Malayalam, which is the primary language of an estimated
> 33 million people in the South Indian state of Kerala.
>
> This version of Malayalam-Omega provides the ability to typeset UTF-8
> encoded text in Malayalam using LaTeX.

Nice to see this in Debian.  Be sure to follow the Debian Policy draft
in the tex-common package.  You can send questions and Policy criticizm
to [EMAIL PROTECTED]

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



Re: Bug#353381: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system

2006-02-20 Thread Florian Weimer
* David Weinehall:

>> Upstream includes non-free manpages these days, so in reality, we have
>> already forked.  Further Debian-specific changes are needed to address
>> bugs such as #295211 (upstream does not document our libc/kernel
>> combination).
>
> What manpages in upstream are non-free?  Do we have rewritten
> alternatives in Debian, or are those pages simply removed without
> replacement?

They are simply removed without replacement.  For most of the older
system calls, the old free manpages (which also contain Linux-specific
details) are still included in the upstream package.  Only new system
calls (such as mq_receive) appear to be undocumented.


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



Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Marco d'Itri
On Feb 20, Peter Samuelson <[EMAIL PROTECTED]> wrote:

> Come on.  The farce is that, two years later, people are _still_
> complaining because they didn't read the thing they voted on, or that
> they didn't bother to vote at all.  Can you all please stop?
No, it will never end. A few people managed to change the definition of
freedom which was commonly accepted when I joined the project nine years
ago and I do not feel a moral need to support their position.

For the records, I voted against the GR.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Bernhard R. Link
* Marco d'Itri <[EMAIL PROTECTED]> [060219 11:34]:
> > Nevertheless, if you think abiword and openoffice.org should be moved then 
> > go
> > for it.  Just don't use them as excuse to turn warez wrappers into "generic"
> > driver interfaces.
> No excuses are needed, the definition of contrib is enough and
> ndiswrapper has been uploaded to main using the same criteria which have
> been used in the past for emulators. Stop rewriting history.
> Please also stop insulting ndiswrapper users and developers by calling
> it a "warez wrapper".

emulators, game engines and other stuff not usefull without something to
act on has always been placed in contrib when there was no free stuff available 
for them.  History has always been: "Write something free for it, then
it is main; if you don't then it is obviously at most contrib".

  Bernhard R. Link


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



Re: Draft DDP policy

2006-02-20 Thread Frank Küster
Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote:

> On Fri, Feb 17, 2006 at 08:58:12AM +0100, Frank Küster wrote:
>> Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote:
>> 
>> >> Policy says to ship HTML, else I wouldn't.
>> >
>> > Policy is somewhat out of date with respect to documentation. There's
>> > actually a (draft) DDP policy which covers this already. I know, I've 
>> > written
>> > it.
>> 
>> Where can we look at the draft?
>
> http://www.debian.org/doc/docpolicy will direct you to 
> http://www.debian.org/doc/manuals/ddp-policy/ddp-policy
>
> BTW, it probably needs a rewrite

Indeed, it seems so.  I won't have time to do this, but I'd like to make
some suggestions.  

It seems to me that the document addresses two related, but rather
different issues.  One is "How should documentation packages install and
register their documents", and it's targetted at any maintainer and
could finally find its place in "The Policy".  The other is "How do we
want to document Debian and its procedures, administration etc.", and it
is mostly uninteresting for everybody except those who actually maintain
those documents.  Even people who regularly submit patches (like I do
for developer's reference) need not know this.

I therefore suggest to split the document in two, one with the aim of
becoming a "Documentation Packages Policy" within the debian-policy
package; the other a kind of "Documenting Debian HOWTO" with a more
limited audience.  If casual contributors need to know anything from it
(like a requirement to license one's patch explicitly under the license
of the document with a signed mail or things like this), it could be
included in a "how to improve this" section in every document.

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



Re: TrueType fonts packages maintenance team proposal

2006-02-20 Thread Rene Engelhard
Christian Perrier wrote:
> List of current ttf-* packages
> --
> (just looking at the packages descriptions give a good idea of the
> non-coordination of font packaging..:-)))
[...]
> ttf-opensymbol - The OpenSymbol TrueType font

built from OOo...

Regards,

Rene


signature.asc
Description: Digital signature


Re: TrueType fonts packages maintenance team proposal

2006-02-20 Thread Frank Küster
Christian Perrier <[EMAIL PROTECTED]> wrote:

> The first goal for this team would be setting up a font packaging
> policy. 
[...]
> I have voluntarily limited the scope of the project to TTF fonts,
> which become more an more popular. This is mostly by ignorance and
> because of my loose knowledge of other font systems. Feel free to
> propose a wider project (but not too much wide, also: having a first
> limited focus is probably more realistic).

I'd be glad if you'd keep the Debian TeX Task Force (currently at
[EMAIL PROTECTED], soon at [EMAIL PROTECTED]) informed about
drafts of this policy.  Although we don't currently package any TTF
fonts, pdftex can in principle use them (as well as PostScript Type1
fonts and, to a still limited extend, OTF).  Unfortunately, it has
rather specific requirements with respect to file placement and even
naming.  It would be nice if we'd manage to keep the needed setup
(symlink farms...)  as simple as possible.

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



Re: TrueType fonts packages maintenance team proposal

2006-02-20 Thread Daniel Baumann
Beeing the new ttf-bitstream-vera maintainer, I have the same opinion as
to other 'team-maintenance-proposals': As long as the package itself is
not as complicated as I could not been handled well by one person, I
don't like the 'team'-idea - it's unecessary overhead for me.

Let's write a fontpackages sub-policy instead, and let it up to the
people to decide how they want to maintain their packages.

(Sorry, if this sounds a bit harsh, but it's not ment as an offence, and
I appreciate your initiative).

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


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



Re: TrueType fonts packages maintenance team proposal

2006-02-20 Thread Marcus Better
Christian Perrier wrote:
> I have voluntarily limited the scope of the project to TTF fonts,
> which become more an more popular.

Perhaps the PostScript fonts in Debian could use some attention as well.
I've been trying to package a very simple PHP library which in the upstream
version includes copies of the "standard" Adobe fonts  (Courier, Times
etc). It turns out that these fonts are included in various Debian
packages, but unfortunately they don't make them available to other
applications in a uniform manner (especially not if you want to preserve
the association between .pfa and .afm files).



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



Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Jérôme Warnier
Le lundi 20 février 2006 à 11:56 +0100, Hendrik Sattler a écrit :
> Am Montag, 20. Februar 2006 11:11 schrieb Jérôme Warnier:
> > [..]
> >
> > > Ndiswrapper probably is better compared to such drivers than to wine
> > > or dosemu.
> >
> > I'm sorry, but Wine and Dosemu can run free softwares (respectively for
> > Windows and DOS), so they are not unuseful without proprietary
> > softwares.
> 
> Read again, that's just what I said in the part that you deleted.
Well, I read it again, and I'm sorry to say that I did not understand
that from your wording.
Also, not breaking lines and having that strange reply format renders it
much more difficult to read.

But anyway, the essential is that we mean the same.

> HS



Re: User-defined fields in control file

2006-02-20 Thread Goswin von Brederlow
Steve Langasek <[EMAIL PROTECTED]> writes:

> On Tue, Feb 14, 2006 at 08:09:00PM +0100, Andre Majorel wrote:
>> Would it be OK for an ISV to insert a user-defined field
>> (X-Yoyodyne-Peanuts) in their binary Debian packages ? Name
>> collisions aside, no chance of causing problems with dpkg, apt and
>> friends ?
>
> Nope, the most you should get is a warning from dpkg-deb.
>
> 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/

dpkg has a special syntax that tells if a custom field in
debian/control should end up in the deb, dsc and/or changes
file. Correctly used that should cause no problems.

MfG
Goswin


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



Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Adeodato Simó
* Goswin von Brederlow [Sun, 19 Feb 2006 23:42:55 +0100]:

> But that is just me. Do what you want as long as ndiswraper stays out
> of non-free.

  Now, that's an idea. Robert, you listening?

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
In Italy, for 30 years under the Borgias they had warfare, terror,
murder, bloodshed, but they produced Michelangelo, Leonardo da Vinci, and
the Renaissance. In Switzerland they had brotherly love - they had 500
years of democracy and peace, and what did that produce? The cuckoo clock.
-- Harry Lime in “The Third Man”


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



Type1 fonts in Debian (was: TrueType fonts packages maintenance team proposal)

2006-02-20 Thread Frank Küster
Marcus Better <[EMAIL PROTECTED]> wrote:

> Christian Perrier wrote:
>> I have voluntarily limited the scope of the project to TTF fonts,
>> which become more an more popular.
>
> Perhaps the PostScript fonts in Debian could use some attention as well.
> I've been trying to package a very simple PHP library which in the upstream
> version includes copies of the "standard" Adobe fonts  (Courier, Times
> etc). It turns out that these fonts are included in various Debian
> packages, 

... and sometimes in quite buggy versions.  I don't recall the details
(but could look them up), but AFAIR the gsfonts package contains a
version of the URW fonts that has been labelled "experimental" and
actually is; especially in the Courier font there were severe problems. 

Somewhere in the debian-tetex-maint list Ralf Stubner posted a
description how to make gs use the variants included in tetex instead.

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



Re: Type1 fonts in Debian (was: TrueType fonts packages maintenance team proposal)

2006-02-20 Thread martin f krafft
also sprach Frank Küster <[EMAIL PROTECTED]> [2006.02.20.1619 +0100]:
> ... and sometimes in quite buggy versions.  I don't recall the details
> (but could look them up), but AFAIR the gsfonts package contains a
> version of the URW fonts that has been labelled "experimental" and
> actually is; especially in the Courier font there were severe problems. 

i recently purchased some non-free fonts and would like to make them
into debian packages for internal use. Thus, I would be very
interested in following such efforts to learn how to accomplish what
i need.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"i started taking an online add test, linked from
 someone's blog. i never finished it; i got distracted, and clicked
 on random other shiny things"
   -- andres salomon


signature.asc
Description: Digital signature (GPG/PGP)


Re: Type1 fonts in Debian

2006-02-20 Thread Frank Küster
martin f krafft <[EMAIL PROTECTED]> wrote:

> also sprach Frank Küster <[EMAIL PROTECTED]> [2006.02.20.1619 +0100]:
>> ... and sometimes in quite buggy versions.  I don't recall the details
>> (but could look them up), but AFAIR the gsfonts package contains a
>> version of the URW fonts that has been labelled "experimental" and
>> actually is; especially in the Courier font there were severe problems. 
>
> i recently purchased some non-free fonts and would like to make them
> into debian packages for internal use. Thus, I would be very
> interested in following such efforts to learn how to accomplish what
> i need.

Hm, this is a general remark about a "font packaging/integration
policy", right?  You hardly have bought non-free drop-in replacements
for Times, Helvetica, Courier and friends.  But Ralf's instructions were
only for replacing these Base35 fonts.

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



Re: Type1 fonts in Debian

2006-02-20 Thread martin f krafft
also sprach Frank Küster <[EMAIL PROTECTED]> [2006.02.20.1644 +0100]:
> Hm, this is a general remark about a "font packaging/integration
> policy", right?  You hardly have bought non-free drop-in
> replacements for Times, Helvetica, Courier and friends.  But
> Ralf's instructions were only for replacing these Base35 fonts.

Ah, yes. General policy/instructions. Sorry.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"if builders built buildings the way
 programmers wrote programs,
 then the first woodpecker that came along
 would destroy civilization."
  -- gerald weinberg


signature.asc
Description: Digital signature (GPG/PGP)


Brazilian Soccer News

2006-02-20 Thread Brazilian Soccer News















    




 

  





  








TetraBrazil offers International Coaches the unique opportunity to travel to Brazil and get the Brazilian National Soccer Association Professional Coaches’ License ("A" License). Brazilian National Soccer Coaches Association - ABTF - is  the only organization in Brazil that certifies the Professional Soccer Coach. Recognized by FIFA, CBF, and other established soccer organizations. ABTF has been developing educational programs for coaches for the last 25 years.  
















 
 







Register for a TetraBrazil TEAM CLINIC  this summer by March 31 and get FREE Tuition to one of our Coahching Programs in Brazil: 
Choose from one of the following options:

 














 
 
 
 




Tours Media Kit: Video - View Slideshow - FAQ's - Request info






















Club Partner in Brazil



 



 





Home | About TB |  Partnership Program | Soccer Camps |  Team Clinics | FUTSAL Training |

©1999-2006 TetraBrazil Soccer Academy, LLC. All Rights Reserved




We hope you enjoyed receiving this message. However, if you'd rather not receive future e-mail updates from TetraBrazil Soccer Academy, please reply this e-mail with subject “REMOVE".
\


Re: TrueType fonts packages maintenance team proposal

2006-02-20 Thread Jaldhar H. Vyas

On Mon, 20 Feb 2006, Daniel Baumann wrote:


Let's write a fontpackages sub-policy instead, and let it up to the
people to decide how they want to maintain their packages.



Christian, I have to agree with Daniel here.  We don't really need joint 
maintenance but coordination on font policy would be a good idea.  (Also if 
someone could explain just how the heck defoma is supposed to work...)


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


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



Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Robert Millan
On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote:
> > Please also stop insulting ndiswrapper users and developers by calling
> > it a "warez wrapper".

Actualy, since such "ndis drivers" are often provided with very restrictive
licensing, or with no licensing at all, I have my doubts that inserting them
into Linux kernel is a legal activity.

This is of no concern to Debian though, but makes the name "warez" very
appropiate.

-- 
Robert Millan


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



Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Robert Millan
reopen 353278
reassign 353278 tech-ctte
reopen 353277
reassign 353277 tech-ctte
merge 353278 353277
thanks

Hi,

I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to contrib.

My reasons are:

  - The sole purpose of these packages is allowing the use of non-free Windows
  drivers.

  - There are no free Windows drivers for this interface, except a port of a
  Linux driver to Windows (cipe), which is only used on native Windows
  platform (since it is pointless to emulate it from Linux, where the original
  cipe is already available).

The maintainer refuses to move it unless you rule a formal decision or a
consensus is reached.  I think the latter is impossible, and therefore I ask you
to consider the issue.

Thank you.

On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote:
> On Sun, 2006-02-19 at 11:34 +0100, Marco d'Itri wrote:
> > On Feb 19, Robert Millan <[EMAIL PROTECTED]> wrote:
> > 
> > > Nevertheless, if you think abiword and openoffice.org should be moved 
> > > then go
> > > for it.  Just don't use them as excuse to turn warez wrappers into 
> > > "generic"
> > > driver interfaces.
> > No excuses are needed, the definition of contrib is enough and
> > ndiswrapper has been uploaded to main using the same criteria which have
> > been used in the past for emulators. Stop rewriting history.
> > Please also stop insulting ndiswrapper users and developers by calling
> > it a "warez wrapper".
> > 
> 
> And for fuck's sake, stop filling up my inbox w/ this crap.  I'm not
> doing a thing unless either a) you people come to a consensus on the
> issue (which you have not in the past threads, and probably never will),
> or b) a governing body like the ctte tells me that it should be in
> contrib.  Otherwise, it's staying right where it is.  Honestly, I could
> care less whether it's in contrib or main, but it was a decision that
> was made long ago, and I see no reason to make the change.

-- 
Robert Millan


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



Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Marco d'Itri
On Feb 20, "Bernhard R. Link" <[EMAIL PROTECTED]> wrote:

> emulators, game engines and other stuff not usefull without something to
> act on has always been placed in contrib when there was no free stuff 
> available 
> for them.  History has always been: "Write something free for it, then
> it is main; if you don't then it is obviously at most contrib".
Yes (even if it was a trivial application), and this has been the case
for ndiswrapper too.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Adeodato Simó
* Mike Hommey [Sun, 19 Feb 2006 11:07:33 +0100]:

> (Which means apt-file searches over *all* debian packages, contrib
> and non-free included, despite the fact that i only have main in my apt
> sources)

  (Note that the Content.gz files come per dist/arch, not per
  dist/component/arch.)

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
A conference is a gathering of important people who singly can do nothing
but together can decide that nothing can be done.
-- Fred Allen


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



Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Thomas Bushnell BSG
[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Feb 20, Peter Samuelson <[EMAIL PROTECTED]> wrote:
>
>> Come on.  The farce is that, two years later, people are _still_
>> complaining because they didn't read the thing they voted on, or that
>> they didn't bother to vote at all.  Can you all please stop?

> No, it will never end. A few people managed to change the definition of
> freedom which was commonly accepted when I joined the project nine years
> ago and I do not feel a moral need to support their position.

This is, I believe, unacceptible.

GR's are the way we make decisions as a project.  Maintainers are
expected to abide by those decisions when they do their work.


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



Re: Bug#352073: ITP: gerwin -- CASE tool for edit data model

2006-02-20 Thread Fernando Ike de Oliveira
retitle 335018 ITP:GNU Ferret - GNU Free Entity
Relationship and Reverse Engineering Tool

Change name package to GNU Ferret.

Em Qui, 2006-02-09 às 17:13 +0100, Krzysztof Krzyzaniak escreveu:
> Fernando Ike de Oliveira wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Fernando Ike de Oliveira <[EMAIL PROTECTED]>
> > 
> > 
> > * Package name: gerwin
> >   Version : 0.6
> >   Upstream Author : Jose E. Marchesi <[EMAIL PROTECTED]>
> > * URL : http://www.nongnu.org/gerwin/project/what.html
> > * License : GPL
> >   Description : CASE tool for edit data model
> > 
> >  GerWin (the GNU Entity/Relationship Wished Incarnation) is a CASE
> >  tool for edit data models. These data models can then be 
> >  implemented on some relational dataDB base implementation 
> >  such as PostgreSQL, Mysql or SGDB compatible SQL-92.
> 
> When you go to URL page you'll see:
> 
> The GerWin project has changed its name!
> 
> The GerWin project has changed its name to GNU Ferret: GNU Free Entity
> Relationship and Reverse Engineering Tool. The rationale behind the name
> changing is to avoid futurable legal conflicts with the owners of the
> Erwin(TM) trademark.
> 
>   eloy
> -- 
> [EMAIL PROTECTED]
> 
>jak to dobrze, że są oceany - bez nich byłoby jeszcze smutniej
> 
> 
-- 
Fernando Ike de Oliveira <[EMAIL PROTECTED]>


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


Re: Accepted ibm-3270 3.3.4p6-1 (source all i386)

2006-02-20 Thread Richard A Nelson

On Mon, 20 Feb 2006, Joerg Jaspert wrote:


On 10571 March 1977, Richard A. Nelson wrote:


Not only did you hijack these packages, and without *ANY* communication,
you missed tcl3270, ICU builds (for the non-US folk)...


You know that this package set was removed since march, so you
cant say much against him bringing it back?


Yes I know... I'm the one that had it removed !  The issues for which
it was removed have gotten better, but have not yet been fully resolved.

If you had the courtesy to contact me, as did the last person - who at
least followed procedure and issued an ITP, you would know this.

You would also know that I use this package every day, have kept it
current, fixed some bugs...  Even distribute updates.

So yes, I can, and will say much against you bringing it back ! Look,
I depend upon on this package for my living - It wasn't lightly that
it was removed from Debian, some of the final issues were, in my
opinion nits - but they still needed to be resolved.

If you had managed to clear the remaining issues, courtesy would've
compelled you to contact me - I've not fallen off the face of the earth;
especially since you started with the last Debian version of the
package (even leaving my changelogs intact).
--
Rick Nelson
<_Anarchy_> Argh.. who's handing out the paper bags  8)


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



Re: Type1 fonts in Debian

2006-02-20 Thread Ralf Stubner
Frank Küster <[EMAIL PROTECTED]> writes:

> Somewhere in the debian-tetex-maint list Ralf Stubner posted a
> description how to make gs use the variants included in tetex instead.

For the record, these instructions can be found at
http://www.tfkp.physik.uni-erlangen.de/~ralf/debian/tex-lw35.html>. 

cheerio
ralf


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



Re: Accepted ibm-3270 3.3.4p6-1 (source all i386)

2006-02-20 Thread Adeodato Simó
* Richard A Nelson [Mon, 20 Feb 2006 09:36:52 -0800]:

> If you had the courtesy to contact me, as did the last person - who at
> least followed procedure and issued an ITP, you would know this.

  Why are you addressing Joerg Jaspert instead of Bastian Blank?

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Create a system that is usable even by idiots, and only idiots will use it.


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



Re: Bug#353545: ITP: wormsofprey -- Worms like multiplayer, realtime game

2006-02-20 Thread Alexander Schmehl
Hi!

* Oya <[EMAIL PROTECTED]> [060220 03:04]:

> * Package name: wormsofprey
[..]
>   Description : Worms like multiplayer, realtime game
> This is another multi-player, real-time clone of Worms just like Liero and
> NiL.
> You control a little worm and try to score as many frags as possible by
> shooting other worms or scoring goals.

You might want to extend the long description a bit:  What's so special
about this one? What are the differences to Liero and NiL?


Yours sincerely,
  Alexander

-- 
http://learn.to/quote/
http://www.catb.org/~esr/faqs/smart-questions.html


signature.asc
Description: Digital signature


Re: Type1 fonts in Debian

2006-02-20 Thread Ralf Stubner
martin f krafft <[EMAIL PROTECTED]> writes:

> i recently purchased some non-free fonts and would like to make them
> into debian packages for internal use. Thus, I would be very
> interested in following such efforts to learn how to accomplish what
> i need.

The main intention behind mk-tex-fontpack (see
http://svn.debian.org/wsvn/debian-tex/make-texfontpkg/trunk/scripts/>)
is to ease the installation of Type 1 fonts for TeX, which needs several
other files beside the fonts themselfs. However, it also registers the
fonts with X11 and defoma in the following way:

* PFB and AFM files are installed in /usr/share/fonts/type1/$packname

* links pointing from /usr/X11R6/lib/X11/fonts/Type1 to PFB and AFM
  files are created

* a fonts.scale (created via mkfontscale or type1inst) is installed as
  /etc/X11/fonts/Type1/$packname.scale and activated via
  dh_installxfonts  

* a defoma-hints file (created via defoma-hints --no-questionin) is
  palced as debian/$packname.defoma-hints and activated via
  dh_installdefoma 

One has to keep in mind that the autogenerated fonts.scale and
defoma-hints files are often bad. That is ok for mk-tex-fontpack since
its main purpose is fonts for TeX. But if one want to install only for
use with X11/defoma, one ought to carefully review these files.

cheerio
ralf


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



Re: TrueType fonts packages maintenance team proposal

2006-02-20 Thread Will Newton
On Monday 20 February 2006 06:40, Christian Perrier wrote:

> The project could also include the maintenance of font-related tools,
> such as fontforge or defoma (which seems mostly abandoned, but
> probably requires solid knowledge or Perl and cryptic
> programming...:-)).

As several people have noticed, the FreeType packages in Debian could do with 
some serious love that I do not have time to give. There are several issues 
in the BTS that are issues with either fonts or FreeType's rendering of a 
particular font, so it would be useful to get font maintainers actively 
involved with maintenance of this package.


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



Re: TrueType fonts packages maintenance team proposal

2006-02-20 Thread Adrian von Bidder
On Monday 20 February 2006 07:40, Christian Perrier wrote:
> So, I hereby propose to think about a possible TTF fonts packaging
> team.

A comment as a pure user insofar as fonts are concerned:  I don't care if 
what I see comes from a ttf, metafont, ps, bdf or PEX font.  I just want 
the font to be available everywhere.  So I'd suggest that at least ttf and 
ps fonts should be managed in some common way - so a font packaging (or 
policy?) team may want to look at more than just ttf fonts.

cheers
-- vbi

(Yes, I realize that bdf and PEX are dying or dead, and that there probably 
is currently support for TeX/Metafont fonts in X/Pango/whatever KDE 
uses ;-)

(Hmmm.  I think I forgot Linux console bitmap fonts...  Or are these bdf, 
too?)



-- 
OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481


pgpIyzPA0AgbQ.pgp
Description: PGP signature


Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Raul Miller
On 2/20/06, Robert Millan <[EMAIL PROTECTED]> wrote:
> I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to contrib.

This proposal is clear enough.

> My reasons are:
>
>   - The sole purpose of these packages is allowing the use of non-free Windows
>   drivers.
>
>   - There are no free Windows drivers for this interface, except a port of a
>   Linux driver to Windows (cipe), which is only used on native Windows
>   platform (since it is pointless to emulate it from Linux, where the original
>   cipe is already available).

I'm not sure I agree with this.

When I look at the list of drivers that ndiswrapper supports
http://ndiswrapper.sourceforge.net/mediawiki/index.php/List
I see several that seem to be open source.

You've asserted that none of these drivers satisfy the DFSG,
but I think we would need more than an assertion on this issue.

As a specific counter example, consider
http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
which is a project porting a windows driver to linux.  This port
appears to be possible because the windows driver was made
available under a free license.

--
Raul



Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Wouter Verhelst
On Sat, Feb 18, 2006 at 06:12:36PM +0200, Lars Wirzenius wrote:
> la, 2006-02-18 kello 10:43 -0500, Michael Poole kirjoitti:
> > What's the purpose of an assembler without assembly code to use it on?
> 
> It can be used, for example, to assemble code you write yourself.

Exactly.

ndiswrapper can be used, for example, to run a driver you write
yourself.

Software that requires the use of non-free libraries can not ever be
used without those non-free libraries.

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


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



Bug#353777: ITP: multixterm -- drive multiple xterms separately or together

2006-02-20 Thread gregor herrmann
Package: wnpp
Severity: wishlist
Owner: gregor herrmann <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: multixterm
  Version : 1.8
  Upstream Author : Don Libes <[EMAIL PROTECTED]>
* URL : http://expect.nist.gov/example/
* License : Public domain
  Description : drive multiple xterms separately or together

 Multixterm creates multiple xterms that can be driven together or
 separately.

 In its simplest form, multixterm is run with no arguments and commands are
 interactively entered in the first entry field. Press return (or click the
 "new xterm" button) to create a new xterm running that command.

 Keystrokes in the "stdin window" are redirected to all xterms started by
 multixterm. xterms may be driven separately simply by focusing on them.

 The stdin window must have the focus for keystrokes to be sent to the
 xterms. When it has the focus, the color changes to aquamarine. As
 characters are entered, the color changes to green for a second. This
 provides feedback since characters are not echoed in the stdin window.

 Typing in the stdin window while holding down the alt or meta keys sends an
 escape character before the typed characters. This provides support for
 programs such as emacs.

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

iD8DBQFD+infOzKYnQDzz+QRAr/kAKDU/SPWN6IyEdP4Zhow20+1QZdxIwCgqU/V
5N8CR2jHtf1ISI/RhttJTlo=
=Zzao
-END PGP SIGNATURE-


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



Re: Bug#352073: ITP: gerwin -- CASE tool for edit data model

2006-02-20 Thread Otavio Salvador
Fernando Ike de Oliveira <[EMAIL PROTECTED]> writes:

> retitle 335018 ITP:GNU Ferret - GNU Free Entity

This should be sent to [EMAIL PROTECTED]

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


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



Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Michael Poole
Robert Millan writes:

> On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote:
> > > Please also stop insulting ndiswrapper users and developers by calling
> > > it a "warez wrapper".
> 
> Actualy, since such "ndis drivers" are often provided with very restrictive
> licensing, or with no licensing at all, I have my doubts that inserting them
> into Linux kernel is a legal activity.

This is an interesting theory.  Drivers' licenses are obviously
irrelevant to a discussion of whether ndiswrapper is freely licensed.
The FSF's usual position[1] is that the GPL does not require GPL
compatibility for non-distributed modifications of a GPLed program.
Are you saying that the FSF is incorrect about the GPL, or are you
making some other claim about what behavior is permitted?

[1]- http://www.gnu.org/licenses/gpl-faq.html#StolenCopy

Michael Poole


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



Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Wouter Verhelst
On Mon, Feb 20, 2006 at 05:10:42PM +1000, Anthony Towns wrote:
> On Sun, Feb 19, 2006 at 03:14:40AM +0100, Wouter Verhelst wrote:
[...]
> > It is already possible to use ndiswrapper without having any non-free
> > software installed. Granted, it doesn't do much useful that way, 
> 
> If you have to differentiate between "able to be used" and "useful",
> you don't have a point.

What if I'm interested in writing such a driver myself, but less
interested in having to run Windows?

> > but a)
> > neither the DFSG nor the SC say anything about usefulness, and b) if a
> > free library package exists in main which no other free package uses it,
> > we don't move the free library package to contrib either.
> 
> If it's only useful for non-free software, we should probably consider it.
> More likely, it's not useful at all, and we should consider dropping it
> entirely. How many libraries do we have in this state?

apt-cache rdepends libstdc++2.10-glibc2.2

Gee, only -dev, -dbg and gcc packages. Isn't that for non-free software?

It's very easy, really. "Requires the use of non-free software" is a far
cry from "only non-free software requires this software". You need
wheels to use a car; you don't need a car to use wheels.

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


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



Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Wouter Verhelst
On Sun, Feb 19, 2006 at 02:11:30AM -0600, Peter Samuelson wrote:
> [Michael Poole]
> > If you want to move ndiswrapper to contrib, I expect the next step is
> > to do the same to libflash, for the same reasons.
> 
> There's a big difference between enabling someone to install non-free
> software, and enabling someone to view data.

Uh, isn't data and software the same thing according to the latest
version of the DFSG?

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


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



Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Olaf Titz
> The difference is that antiword is a tool for the user. The user will
> have doc files to use with antiword, e.g. send by mail. The antiword
> program on its own provides the user with the ability to view his/her
> word files. It does not depend on the existance of such a file on the
> system to provide that service.

And what's exactly the difference to:
The user will have drivers to run his hardware with, provided by the
vendor. ndiswrapper on its own provides the user with the ability to
use his/her drivers (and therefore, hardware).
?

Olaf


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



Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Peter Samuelson

[Wouter Verhelst]
> What if I'm interested in writing such a driver myself, but less
> interested in having to run Windows?

Then you should get busy writing that driver.  Without any such drivers
in existence, it's hard to take this line of reasoning seriously.  I
find it absurd that someone would be interested in writing a Windows
driver but not interested in running Windows to test it on.  If that's
really what you want to do, please say so, preferably with some sort of
evidence.  I hate to have to ask for evidence rather than taking your
word for it, but the scenario seems so contrived that I'm afraid only
evidence will make it seem less so.


> apt-cache rdepends libstdc++2.10-glibc2.2
> 
> Gee, only -dev, -dbg and gcc packages. Isn't that for non-free software?

No, not really.  There's plenty of software, free and otherwise, which
one might wish to compile with g++ 2.95.  Newer g++ versions get
pickier about C++ syntax and semantics, and thus it's reasonable to
retain g++ 2.95 so that people don't have to port their old software to
modern C++.  (Yes, I said "their" old software.  Lots of people have
written C++ code that they want to run on Debian, unlike Windows
drivers.)

Fortunately it seems very few packages in Debian require gcc-2.95 or
g++-2.95 anymore.  So yes, I agree, at some point we should drop the
whole gcc-2.95 source package.


signature.asc
Description: Digital signature


Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Olaf Titz
> > Why on earth would anyone want to run the Windows version of a native
> > Linux app under a Windows emulation under Linux? :-)
>
> Because they're a developer of that app and they want to test the Windows
> port before releasing?

Okay, that's a bit of a corner case ;-) but nonetheless valid.

Olaf


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



Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Russ Allbery
Anthony Towns  writes:

> If it's only useful for non-free software, we should probably consider
> it.  More likely, it's not useful at all, and we should consider
> dropping it entirely. How many libraries do we have in this state?

We went through this whole discussion with emulators, with people pushing
them towards contrib under the theory that there was no free firmware for
them to play.  Then people packaged various free firmware just to get the
emulators back into main.  This process strikes me as a significant waste
of time and energy, and I'm not sure what it's supposed to accomplish.

If the package absolutely requires a piece of non-free software to work,
or if it's an installer for non-free software (such as the various
installer packages or the packaging wrappers around djb software), it goes
in contrib.  If it just implements some sort of API or ABI that isn't
specific to some *particular* piece of non-free software, I think shoving
it towards contrib is just a waste of everyone's time.  As we already saw
with emulators, free uses of that API or ABI tend to eventually
materialize, making this distinction requires drawing a lot of thin and
hazy lines, and (worst of all) it always sparks long, pointless threads
about the definition of freedom on debian-devel.

I don't think the distinction between main and contrib should be so
unstable as to change based on the existence of some theoretical piece of
third-party software.  As long as the software implements some reasonably
generic API or ABI that isn't inherently non-free and doesn't require a
dependency on non-free software in the dpkg sense, I say just put it in
main and not worry about whether anyone has used that API or ABI in free
software yet.  It saves on moving things around later, I can't see how it
breaks anything in the DFSG, and it means one less controversial grey area
decision that we have to make all the time.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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



Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Wouter Verhelst
On Sun, Feb 19, 2006 at 11:11:32AM +0100, Robert Millan wrote:
> On Sat, Feb 18, 2006 at 05:36:37PM +0100, Mike Hommey wrote:
> > On Sat, Feb 18, 2006 at 05:04:54PM +0100, Goswin von Brederlow
> > > The availability to do this is enough even if there are other
> > > (possibly better) ways to do the same. One free driver _in_ Debian and
> > > the package should stay in main.
> > > 
> > > But does the cipe-source build or ship the windows driver for use with
> > > ndiswraper? I doubt that.
> > > 
> > > Which means you need some software (even if it is free) from outside
> > > Debian for ndiswraper. That makes it contrib imho.
> > 
> > Are there any free MSWord files in main ? No ? Then please move
> > antiword and similar tools to contrib.
> 
> You're turning this into non-sense.  An NDIS wrapper is OBVIOUSLY for the
> exclussive purpose of using non-free Windows drivers.  It is so obvious
> because nobody has written [1] free GPLed NDIS drivers.  EVER.  It has nothing
> to do with Wine and MSWord [2].
> 
> So, stop throwing unrelated points to this matter.  Just fix the bug.  Move 
> this
> to contrib, with all the other warez wrappers.
> 
> [1] Written, not ported.  I know someone ported that CIPE thing from Linux to
> Windows, but the sole idea of porting something to Windows in order to emulate
> it from Linux makes me laugh.

The sole idea to run Internet Explorer under Wine on Linux makes _me_
laugh. But I've seen people do it. And they were not amused by my
laughing.

The fact that there is at least one GPL driver for ndiswrapper means
that it is possible to use ndiswrapper for useful purposes without
non-free software. And since cipe is not part of the kernel yet, that
might be a good idea anyway if the native driver doesn't work with the
kernel which you're using for some reason while ndiswrapper does.
Which is not _that_ strange, I've seen it often enough with
out-of-(vanilla)-kernel modules.

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


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



Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Wouter Verhelst
On Mon, Feb 20, 2006 at 04:21:44PM -0600, Peter Samuelson wrote:
> [Wouter Verhelst]
> > apt-cache rdepends libstdc++2.10-glibc2.2
> > 
> > Gee, only -dev, -dbg and gcc packages. Isn't that for non-free software?
> 
> No, not really.  There's plenty of software, free and otherwise, which
> one might wish to compile with g++ 2.95.  Newer g++ versions get
[...]
> Fortunately it seems very few packages in Debian require gcc-2.95 or
> g++-2.95 anymore.

Uhm. How many reasonable and up-to-date free software exists that is not
in Debian? Seriously.

> So yes, I agree, at some point we should drop the whole gcc-2.95
> source package.

I happen to think this discussion is getting increasingly silly.

"There's only one free driver which would work with ndiswrapper! there's
many many many more Windows applications which are free!"

What people fail to mention is that there are many many many more
Windows applications than there are drivers that use the NDIS
environment, and that percentually, one free driver might be a *lot*
more than the number of Free applications that are ran under wine.

How many have ever used wine to run Free Software?

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


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



Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Steve Langasek
[ObRC: 343781]

On Tue, Feb 21, 2006 at 12:16:23AM +0100, Wouter Verhelst wrote:
> How many have ever used wine to run Free Software?

I have.  FWIW.

I've also used wine in the process of developing and testing non-free
software.  I think that's a valid rationale for keeping wine in main; we
don't require that people demonstrate word processors being used to create
free documents before we say they can go in main, because using them to
create *non*-free documents is a valid use case, and the Social Contract
only talks about whether we *depend* on non-free stuff -- not whether the
user chooses to use the program for non-free stuff.

The same reasoning potentially applies to ndiswrapper, but I don't think it
makes sense to base this on a hypothetical.  If people *are* using
ndiswrapper for developing drivers -- free or non-free -- then ok.  If we're
just saying it *could* be used that way, then this is rationalization.  I
know ndiswrapper wouldn't be useful to me if I didn't have a non-free
Windows driver to go with it.

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


signature.asc
Description: Digital signature


Re: Accepted ibm-3270 3.3.4p6-1 (source all i386)

2006-02-20 Thread Joerg Jaspert
On 10571 March 1977, Richard A. Nelson wrote:

> If you had the courtesy to contact me, as did the last person - who at
> least followed procedure and issued an ITP, you would know this.

Tss, calm down, i absolutely do not care about this stupid package.

-- 
bye Joerg
> Or write yourself a DFSG-free replacement for that piece of software.
Using the copy and paste method from the old source, obscured by 
irrelevant changes.


pgp3wQnZdDGCQ.pgp
Description: PGP signature


Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Anthony Towns
On Mon, Feb 20, 2006 at 05:36:13PM +0100, Robert Millan wrote:
> I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to contrib.

ndiswrapper is a program to allow users to load Windows drivers for their
hardware and use them on Linux. The drivers are executed on the main CPU;
there are no free drivers that ndiswrapper is useful for, apart from a
single example driver that is a port of a driver already in the kernel.

We currently allow both emulators, that play non-free ROMs, and clients
for network protocols for which there is no non-free server into main.

ndiswrapper was accepted into main in November 2004.

AFAICS, this would come under the "overrule a developer (3:1 majority)"
power.

> The maintainer refuses to move it unless you rule a formal decision or a
> consensus is reached.  I think the latter is impossible, and therefore I ask 
> you
> to consider the issue.

While I would personally rather see the "contrib" demarkation cover
this, emulators, and clients for propietary protocols, I'm disinclined
to override both the maintainer and the ftpmaster that accepted it,
particularly on this single issue rather than as a global policy change
for those issues. I expect I'll either abstain or vote against.

Cheers,
aj



signature.asc
Description: Digital signature


Bug#353802: ITP: gcom -- Option GlobeTrotter and Vodafone datacard control tool

2006-02-20 Thread Andreas Gredler
Package: wnpp
Severity: wishlist
Owner: Andreas Gredler <[EMAIL PROTECTED]>

* Package name: gcom
  Version : 0.3
  Upstream Author : Paul Hardwick <[EMAIL PROTECTED]>
* URL : http://www.pharscape.org/content/view/46/70/
* License : GPL
  Description : Option GlobeTrotter and Vodafone datacard control tool

Gcom is a scripting language interpreter useful for establishing
communications on serial lines and through PCMCIA modems as well as
GPRS and 3G datacards. Works with Option GlobeTrotter
GPRS/EDGE/3G/HSDPA and Vodafone 3G/GPRS datacards.



I also want to package the kernel modules but have to get more
experience/knowledge with the creation of kernel packages, first.

greets Jimmy

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


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



Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Adam McKenna
On Sat, Feb 18, 2006 at 09:40:26AM +0100, Robert Millan wrote:
> 
> Because it's free software that processes asm input, and there is a 
> significant
> amount of useful, free i386 asm that makes nasm necessary ?
> 
> I'll ask again:  Is the purpose of ndiswrapper running non-free drivers?  If 
> it
> isn't, show me a free, non-toy, non-POC driver that would prove otherwise.

This is beside the point.

IMHO, the main purpose of contrib is to avoid shipping things on CD that 
depend on programs in non-free.  It is not a section that we put programs in
in order to 'punish' them for depending on non-free code.

ndiswrapper doesn't depend (in a control file sense) on stuff in non-free, so
there's no reason it can't go in main.  In fact, since it would be
tremendously useful to be able to activate wireless ethernet devices with
non-free drivers (from floppy/cd) during the install process, I'd say that
it makes even more sense for ndiswrapper to go into main (and maybe even 
into base).

--Adam
-- 
Adam McKenna  <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>


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



Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Adam McKenna
On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote:
> And for fuck's sake, stop filling up my inbox w/ this crap.  I'm not
> doing a thing unless either a) you people come to a consensus on the
> issue (which you have not in the past threads, and probably never will),
> or b) a governing body like the ctte tells me that it should be in
> contrib.  Otherwise, it's staying right where it is.  Honestly, I could
> care less whether it's in contrib or main, but it was a decision that
> was made long ago, and I see no reason to make the change.

The driver should stay in main and hooks should be written into the installer
so that our users can easily enable their wireless cards during installation.

--Adam


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



Re: Problems found by piuparts

2006-02-20 Thread Manoj Srivastava
On 20 Feb 2006, Lars Wirzenius stated:

> I added a Cc to Manoj since I would like to hear his
> comment. Whoever responds may want to remove the Cc to avoid
> stuffing his inbox unnecessarily.
>
> su, 2006-02-19 kello 23:42 -0800, Steve Langasek kirjoitti:
>> On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote:
>>> * Use of ucf in postrm during a purge, without checking that ucf
>>> is installed. Since ucf is not an essential package, postrm
>>> during purge cannot rely on it. As it happens, I think it might
>>> be good to have ucf (or a subset of it) as an essential package,
>>> since this error happens a lot.
>>
>> So assuming that we're stuck with the current implementation for a
>> bit where ucf is not part of essential, I do wonder if checking
>> whether ucf is installed is actually the correct thing to do in
>> postrm purge.  The state prior to purge is defined as "config
>> files"; the difference between config files state and "purged" is
>> whether there are still config files left on the system.  If the
>> package can't actually succeed in removing its config files because
>> ucf is not installed, isn't it *correct* for the postrm purge
>> command to fail?  I.e., I think it's more of a bug to allow dpkg to
>> put the package into "purged" state leaving orphaned config files
>> behind than it is for postrm purge to fail and leave the package in
>> "config files" state.
>
> Hm. I don't use ucf on my own packages (yet), so my understanding is
> a bit hazy, but if I have understood correctly, the actual config
> file is removed with rm anyway, and ucf is needed on purge only to
> remove the config file also from ucf's history data. Thus, only
> running ucf if it's there should be the right thing.
>
> Manoj, could you comment on this?

Your analysis is correct.

manoj

-- 
"I'd love to go out with you, but I did my own thing and now I've got
to undo it."
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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



Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Adam McKenna
On Mon, Feb 20, 2006 at 09:13:15PM -0800, Adam McKenna wrote:
> The driver should stay in main and hooks should be written into the 

s/driver/package..

--Adam


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



Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Steve Langasek
On Tue, Feb 21, 2006 at 10:40:06AM +1000, Anthony Towns wrote:
> On Mon, Feb 20, 2006 at 05:36:13PM +0100, Robert Millan wrote:
> > I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to 
> > contrib.

> ndiswrapper is a program to allow users to load Windows drivers for their
> hardware and use them on Linux. The drivers are executed on the main CPU;
> there are no free drivers that ndiswrapper is useful for, apart from a
> single example driver that is a port of a driver already in the kernel.

> We currently allow both emulators, that play non-free ROMs, and clients
> for network protocols for which there is no non-free server into main.

> ndiswrapper was accepted into main in November 2004.

> AFAICS, this would come under the "overrule a developer (3:1 majority)"
> power.

Yes, this is not a request from Andres that we make a decision on his
behalf, therefore the Technical Committee would be acting to override the
maintainer under 6.1.4 with a 3:1 majority.

> > The maintainer refuses to move it unless you rule a formal decision or a
> > consensus is reached.  I think the latter is impossible, and therefore I 
> > ask you
> > to consider the issue.

> While I would personally rather see the "contrib" demarkation cover
> this, emulators, and clients for propietary protocols, I'm disinclined
> to override both the maintainer and the ftpmaster that accepted it,
> particularly on this single issue rather than as a global policy change
> for those issues. I expect I'll either abstain or vote against.

I suspect I disagree with Anthony on where exactly the line should be drawn,
but it does seem to me that the arguments used to justify ndiswrapper's
presence in main are rather contrived.  Nobody is going to want to run
drivers under ndiswrapper in a production environment if there is a suitable
free equivalent available for Linux; the only practical applications I see
here are using non-free Windows drivers under Linux for
otherwise-unsupported hardware, and using ndiswrapper as a tool for
preliminary testing of drivers being written for Windows in an environment
that doesn't require booting Windows.  The former is what I use it for, and
what every user I know uses it for, and doesn't justify a claim that
ndiswrapper does not depend on non-free software.  The latter, IMHO, would
be grounds for shipping the software in main, but AFAIK this is purely a
hypothetical at this point.

Either way, I do agree with Anthony that one-off overrides of maintainers
don't seem like the best way for us to be spending our time.

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


signature.asc
Description: Digital signature


Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Anthony Towns
On Mon, Feb 20, 2006 at 09:01:40PM -0800, Adam McKenna wrote:
> IMHO, the main purpose of contrib is to avoid shipping things on CD that 
> depend on programs in non-free.  It is not a section that we put programs in
> in order to 'punish' them for depending on non-free code.

That's a mistaken view; the purpose of contrib is to give us a place
to ship free software that we can't ship in Debian proper (ie, main)
because it would violate "We will never make the system require the use
of a non-free component" or, historically, "... we will never make the
system depend on an item of non-free software".

> ndiswrapper doesn't depend (in a control file sense) on stuff in non-free,

The "Depends:" field isn't really that relevant.

Cheers,
aj



signature.asc
Description: Digital signature


Re: Bug#353277: ndiswrapper in main

2006-02-20 Thread Glenn Maynard
On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote:
> Honestly, I could care less whether it's in contrib or main

It's nice to see that Debian Developers actually care about their Social
Contract, and hold acceptance by Debian in such high regard.

-- 
Glenn Maynard


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



Re: TrueType fonts packages maintenance team proposal

2006-02-20 Thread Christian Perrier
> I'd be glad if you'd keep the Debian TeX Task Force (currently at
> [EMAIL PROTECTED], soon at [EMAIL PROTECTED]) informed about
> drafts of this policy.  Although we don't currently package any TTF


Of courseActually, I see some difference between TTF fonts which
most common use are desktop environments and Type1 fonts, which use is
more specialized (correct me if I say stupid things, I'm far from
having good knowledge of all this...which is actually one of the
motivations for a team...:-))

So, unless some good arguments come up, this team and "loose policy"
would then be limited to TTF fontsbut of course, the TSF will be
kept posted (will try to remember crosspositing for a next
announcement).



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



Re: TrueType fonts packages maintenance team proposal

2006-02-20 Thread Christian Perrier
Quoting Jaldhar H. Vyas ([EMAIL PROTECTED]):

> >Let's write a fontpackages sub-policy instead, and let it up to the
> >people to decide how they want to maintain their packages.
> >
> 
> Christian, I have to agree with Daniel here.  We don't really need joint 
> maintenance but coordination on font policy would be a good idea.  (Also if 
> someone could explain just how the heck defoma is supposed to work...)


I actually have no intent to enforce this to people who prefer
maintaining the package they maintain alone.

My current view is more having a common place for package maintenance
(for maintainers who want to join), possibly with "sub-places" for
packages which have joined this "loose team". There, each package
maintainer would have to choice to either be the only responsible
person for the package (aka be "Maintainer" and "Uploader"
alone)or give precedence to the team...or whatever combination.

Again, no enforcement for anyone to join the team and the packaging
policy would then be more a set of guidelines rather than an enforced
policy such as other packaging policies.

As you mention, Jaldhar, there are a few things related to font
packaging which are not obvious to people who package fonts. "defoma"
is among theseand fontforge os probably another one. So the team
could also be a good place for font maintainers to share their
experience and maybe also benefit from a wider experience by epople
who have a good knowledge of such deep technical stuff.



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



PROPOSAL: debian/control file to include new License: field

2006-02-20 Thread Jari Aalto

To my understanding the only way to obtain the license information
for a package is to actually download it (or install it) and the
study the content of

/usr/share/doc//copyright

It would be better if user could use the packaging search commands,
like

grep-dctrl -F License ... --and -F package ...

PROPOSAL:

Add new field to the debian/control (which would be generated by dh-make):

License:

It would contain a canonicalized word to describe the license in 
questions, like:

GPL, GPL2, GPL3, LGPL, BSD, Perl Artistic, MIT/X . Custom

The number of generic license name can be debated and instead of
the last resort "Custom" there could be word like:

DFSG-approved, OSI-approved, FSF-approved etc.

DH_MAKE TEMPLATE

If given the option --copyright, then the field is initialised with
that value, otherwise add

Licence: http://wiki.debian.org/DFSGLicenses>

Jari

[PS]
Should this be disccussed in, (crossposted to) debian-legal as well? 


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



Re: PROPOSAL: debian/control file to include new License: field

2006-02-20 Thread Russ Allbery
Jari Aalto <[EMAIL PROTECTED]> writes:

> To my understanding the only way to obtain the license information for a
> package is to actually download it (or install it) and the study the
> content of

> /usr/share/doc//copyright

> It would be better if user could use the packaging search commands, like

> grep-dctrl -F License ... --and -F package ...

Out of curiosity, why?  What problem are you trying to solve?

> PROPOSAL:

> Add new field to the debian/control (which would be generated by
> dh-make):

> License:

> It would contain a canonicalized word to describe the license in 
> questions, like:

> GPL, GPL2, GPL3, LGPL, BSD, Perl Artistic, MIT/X . Custom

This has been proposed before.  One of the problems with this idea is that
many packages have more complex licenses than that, ones that cannot be
easily encapsulated into a single term.  Many packages contain files under
various different licenses and many packages are covered under minor
modifications to standard licenses, so coming up with these terms becomes
a bit complicated, can't be fully accurate, and seems likely to spawn a
complicated set of rules that are hard to verify.

In other words, it seems like a lot of work, and it's not clear what
problem it would really solve.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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



Re: TrueType fonts packages maintenance team proposal

2006-02-20 Thread Miles Bader
Christian Perrier <[EMAIL PROTECTED]> writes:
> Of courseActually, I see some difference between TTF fonts which
> most common use are desktop environments and Type1 fonts, which use is
> more specialized

>From a user point of view, TTF and Type1 fonts are essentially the same;
they both work well for typical desktop use in debian.

[Maybe in the past there were differences due to e.g. the different
hinting strategies, but these days freetype seems to handle both equally
well.  I don't know whether windows/macos are similarly advanced.]

-Miles
-- 
.Numeric stability is probably not all that important when you're guessing.


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



Re: PROPOSAL: debian/control file to include new License: field

2006-02-20 Thread Martin Wuertele
* Jari Aalto <[EMAIL PROTECTED]> [2006-02-21 08:01]:

> To my understanding the only way to obtain the license information
> for a package is to actually download it (or install it) and the
> study the content of
> 
> /usr/share/doc//copyright

That information can also be obtained from packages.debian.org
(currently use pdo.debian.net).

yours Martin
-- 
<[EMAIL PROTECTED]>  Debian GNU/Linux - The Universal Operating System


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



Re: PROPOSAL: debian/control file to include new License: field

2006-02-20 Thread Kevin Mark
On Mon, Feb 20, 2006 at 11:12:46PM -0800, Russ Allbery wrote:
> Jari Aalto <[EMAIL PROTECTED]> writes:
> 
> > To my understanding the only way to obtain the license information for a
> > package is to actually download it (or install it) and the study the
> > content of
> 
> > /usr/share/doc//copyright
> 
> > It would be better if user could use the packaging search commands, like
> 
> > grep-dctrl -F License ... --and -F package ...
> 
> Out of curiosity, why?  What problem are you trying to solve?
> 
> > PROPOSAL:
> 
> > Add new field to the debian/control (which would be generated by
> > dh-make):
> 
> > License:
> 
> > It would contain a canonicalized word to describe the license in 
> > questions, like:
> 
> > GPL, GPL2, GPL3, LGPL, BSD, Perl Artistic, MIT/X . Custom
> 
> This has been proposed before.  One of the problems with this idea is that
> many packages have more complex licenses than that, ones that cannot be
> easily encapsulated into a single term.  Many packages contain files under
> various different licenses and many packages are covered under minor
> modifications to standard licenses, so coming up with these terms becomes
> a bit complicated, can't be fully accurate, and seems likely to spawn a
> complicated set of rules that are hard to verify.
> 
> In other words, it seems like a lot of work, and it's not clear what
> problem it would really solve.
Hi,
would it provide any automation or easier processing for the NEW
queue(ftpmasters)?  would it allow for reducing package size by removing
license text from all packages and having them installed in a seperate
essential package stored in a canonical location
(/usr/share/doc/dfsg-license-texts/) (dfsg-license-texts.deb) and have a
file-license.txt to list which files are licensed under which license?
Cheers,
Kev

-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature


Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

2006-02-20 Thread Adam McKenna
On Tue, Feb 21, 2006 at 03:36:16PM +1000, Anthony Towns wrote:
> On Mon, Feb 20, 2006 at 09:01:40PM -0800, Adam McKenna wrote:
> > IMHO, the main purpose of contrib is to avoid shipping things on CD that 
> > depend on programs in non-free.  It is not a section that we put programs in
> > in order to 'punish' them for depending on non-free code.
> 
> That's a mistaken view; the purpose of contrib is to give us a place
> to ship free software that we can't ship in Debian proper (ie, main)
> because it would violate "We will never make the system require the use
> of a non-free component" or, historically, "... we will never make the
> system depend on an item of non-free software".

Practically, it's to avoid shipping things on our CDs that depend on stuff
that's not on our CDs.  In this case, even in the absence of free NDIS
drivers, one could argue that the utility of having ndiswrapper in main
(especially if it is integrated into the install) outweighs any potential 
drawbacks (and since the only drawback I can see is pissing off
zealots/fundamentalists, I'd be all for it.)  Thankfully, there is no need
to make that argument, since at least one free NDIS driver exists (the
aforementioned CIPE).

> > ndiswrapper doesn't depend (in a control file sense) on stuff in non-free,
> 
> The "Depends:" field isn't really that relevant.

What is relevant is that ndiswrapper technically meets all requirements for
inclusion into main.  Did I miss a solid argument refuting that assertion?

--Adam

-- 
Adam McKenna  <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>


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