Re: For those who care about their packages in Ubuntu

[Scott Ritchie]

On Sat, 2006-01-21 at 01:53 -0800, Thomas Bushnell BSG wrote:
> Matt Zimmerman <[EMAIL PROTECTED]> writes:
> 
> > In practice, it doesn't work out to mean the same thing, however.  Most of
> > the packages in universe are maintained only by the Debian maintainer, and
> > propagated unmodified into Ubuntu.  It is only when there is a specific
> > motive to change the package in Ubuntu that anyone on that team will touch
> > it.
> 
> They are *not* maintained by the Debian maintainer, for the simple
> reason that the Debian maintainer does not have control over the
> contents of the package!

But what about when packages in universe are simply merged in straight
from Debian?  It might be a strange semantic question: Is that the same
package, or a different one?

In the case of such a package, the same fixes by the Debian maintainer
to the Debian package do end up in the contents of the Ubuntu package
when it gets resynched.

Now, before I confuse myself with word games and contemplate whether
that implies "control" or not, I'm going to offer up the conjecture that
bug reports on an Ubuntu universe package are potentially more relevant
to a Debian maintainer than bug reports on a Debian stable package,
since they're closer to the current unstable.

Thoughts?
Scott Ritchie


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

Re: For those who care about their packages in Ubuntu

[David Weinehall]

On Sun, Jan 22, 2006 at 02:26:57AM -0800, Scott Ritchie wrote:
[snip]
> In the case of such a package, the same fixes by the Debian maintainer
> to the Debian package do end up in the contents of the Ubuntu package
> when it gets resynched.
> 
> Now, before I confuse myself with word games and contemplate whether
> that implies "control" or not, I'm going to offer up the conjecture that
> bug reports on an Ubuntu universe package are potentially more relevant
> to a Debian maintainer than bug reports on a Debian stable package,
> since they're closer to the current unstable.

Since all Ubuntu packages are recompiled against a different set of
libraries, the bug might not even affect the Debian package, even though
they share the same source.  Hence having Ubuntu developers triage the
bugs to rule out such issues before they are forwarded to Debian's BTS
is always a good thing; thus the maintainer field should be changed
for *binary packages*.  The source is the same, so the field should NOT
be changed for *source packages*.

If the bug indeed exists in both Ubuntu and Debian, then the bug is in
the source and needs fixing in Debian too, but if the bug is caused by
the Ubuntu build environment, then the bug is purely in the package,
and any bugreport would just waste the Debian developer's time, *AND*
risk Ubuntu losing vital information about a bug in their build
environment.  


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


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

Re: For those who care about the GR

[Thijs Kinkhorst]

On Sat, January 21, 2006 21:52, Manoj Srivastava wrote:
> So, can the developers dispute this? Obviously, the developer
> body can dispute any delegated action. But a GR can't overturn something
> seen as fact (so no GR stating PI=exacly 3.14 or 22/7).

Could you please explain how you arrive at the conclusion that an
interpretation of guidelines can be seen as a fact? This is not exact
science, even though you link it to the value of pi. In judicial systems
one can dispute an interpretation of the law at a court, because the law
is seen as something that is subject to interpretation.

This goes even further here, because the DFSG is not even a strict set of
rules but are guidelines. As we all know, guidelines are subject to
interpretation on a case-by-case basis, that's what distinguishes them
from rules. Therefore, I think a specific application of guidelines can
not be seen as a fact.


Thijs


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

Re: For those who care about the GR

[Martijn van Oosterhout]

2006/1/22, Thijs Kinkhorst <[EMAIL PROTECTED]>:
> This goes even further here, because the DFSG is not even a strict set of
> rules but are guidelines. As we all know, guidelines are subject to
> interpretation on a case-by-case basis, that's what distinguishes them
> from rules. Therefore, I think a specific application of guidelines can
> not be seen as a fact.

As someone who can't vote and thus whose opinion doesn't matter, it
seems to me that the issue is that people may actually want to vote
multiple ways:

1. debian-legal is wrong, the GFDL is compatable with the DFSG and
thus should be included in main.
2. I know the GFDL isn't compatable with the DFSG but I think it
should be allowed in main anyway.
3. I know the GFDL isn't compatable with the DFSG but the DFSG is only
for software not documentation, so it's allowed in main for
documentation only. :)

It seems that some people see the vote as meaning 1 and others want
meaning 2. The latter would seems to require changing the SC, the
former wouldn't.
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

yet another mass bug filing on GFDL issues ?

[Holger Levsen]

Hi,

no, this is not really about the GFDL issue currently discussed, but about 
using the unmodified GFDL template in debian/copyright. Besides not being 
able to tell who has the copyright, it makes it also impossible to tell if 
there are invariant sections and/or cover texts.

Lots of packages (including most of kde, but also gcc-x.y-base, gdb, mtools, 
groff-base) are affected.

Do a 

 find /usr/share/doc -name copyright -exec grep -l "YOUR NAME" {} \;

to find those packages on your system. (This might cause a few false 
positives, figlet for example is not affected :)

AIUI, no matter how the outcome of the GFDL GR will be, these are bugs which 
needs to be fixed. So to me it smells like another mass bug filing, probably 
with user tags.

Hm, on a second thought this (*) _might_ be a feature: the GFDL says invariant 
sections need to be listed, but there aren't any, as a template has been 
used. Yay ?!

What do you think ?


regards,
Holger


pgpoBtwV4YIxp.pgp
Description: PGP signature

Re: yet another mass bug filing on GFDL issues ?

[Anthony DeRobertis]

Holger Levsen wrote:

> Hm, on a second thought this (*) _might_ be a feature: the GFDL says 
> invariant 
> sections need to be listed, but there aren't any, as a template has been 
> used. Yay ?!

I suspect that many of those cases might just be an accidental ommission
in the copyright file...

OTOH, it is hillarious that after typing 'info gdb' I was unable to
actually find the statement saying the documentation is under the GFDL;
it appears that the FSF has once again mis-applied their own license...


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

Re: For those who care about the GR

[Benjamin Seidenberg]

Martijn van Oosterhout wrote:


2006/1/22, Thijs Kinkhorst <[EMAIL PROTECTED]>:
 


This goes even further here, because the DFSG is not even a strict set of
rules but are guidelines. As we all know, guidelines are subject to
interpretation on a case-by-case basis, that's what distinguishes them
from rules. Therefore, I think a specific application of guidelines can
not be seen as a fact.
   



As someone who can't vote and thus whose opinion doesn't matter, it
seems to me that the issue is that people may actually want to vote
multiple ways:

1. debian-legal is wrong, the GFDL is compatable with the DFSG and
thus should be included in main.
2. I know the GFDL isn't compatable with the DFSG but I think it
should be allowed in main anyway.
3. I know the GFDL isn't compatable with the DFSG but the DFSG is only
for software not documentation, so it's allowed in main for
documentation only. :)

It seems that some people see the vote as meaning 1 and others want
meaning 2. The latter would seems to require changing the SC, the
former wouldn't.
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/


 

You forgot 1b) I think that the GFDL-without-invariant-sections is 
compatible with the DFSG. That's an interpretation, and should only need 
a majority. Other than that, you're right (IMHO)


Benjamin


signature.asc
Description: OpenPGP digital signature

Re: For those who care about the GR

[Manoj Srivastava]

On Sun, 22 Jan 2006 19:25:58 +0100, David N Welton <[EMAIL PROTECTED]> said: 

> Manoj Srivastava wrote:
>> On Sun, 22 Jan 2006 13:59:15 +0100, Martijn van Oosterhout
>> <[EMAIL PROTECTED]> said:
>> 
>> 
>>> 1. debian-legal is wrong, the GFDL is compatable with the DFSG and
>>> thus should be included in main.
>> 
>> 
>> Looking over the arguments for and against it in -legal, I am
>> trying to ascertain if this stance has a leg to stand on.

> ... and ?

And what? If someone tries to bring through a GR stating that
 MS office warez can be distributed in main since it meets the DFSG,
 one might rule that as frivolous and a waste of time.

> I am still trying to ascertain whether debian-legal has a leg to
> stand on.

Only insofar in how they convince people -- like delegates,
 for example. I am, for one, convinced that the GFDL does not meet the
 standards of freedom the project espouses.

manoj
-- 
It is impossible to make anything foolproof because fools are so
ingenious.
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]

DFSG, GFDL, and position statementsd

[Manoj Srivastava]

Hi,

If we were to deal with all these issues on one ballot, it
 would have to take the form somewhat like this:

A) The delegates decision that the GFDL licensed works are non-free is
   wrong, the GFDL meets the DFSG. Override the delegated decision,
   and  issue the following statement "..."
B) The delegates decision that the GFDL licensed works are non-free
   does not hold for works without invariant sections, modify the
   delegated decision to allow works with no invariant sections in
   main, and issue the following statement "..."
C) Yes, GFDL licensed works are non-free, but all such should be
   allowed in main anyway, since they are so important. Modify the SC,
   and issue the following statement "..." 3:1
D) Yes, GFDL licensed works are non-free, including those without
   invariant sections, but without invariant sections we should allow
   them in main, since the infractions are minor. Modify the SC,
   and issue the following statement "..." 3:1
E) The decision of the delegates was fine, issue the following
   position statement "..." [This is aj's proposal]
F) The decision of the delegates was fine, but we need issue no
   position statement, since it can inflame members of the
   community. Take no further action. (This is tantamount to the
   default option, but added here for finer granularity of opinions). 
G) Further discussion.


However, I am not in a position to hammer out and craft all
 these diverse ballot options -- let the proponents decide.  I
 currently am holding the amendment to be (D), as written, and the
 original proposal to be (E).

If there are people who seriously espouse options A, B, and C,
 they should offer such amendments, or even a separate GR to determine
 the handling of the GFDL licensed works, with or without the
 invariant clauses.

manoj
-- 
Microwaves frizz your heir.
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: For those who care about the GR

[Manoj Srivastava]

On Sun, 22 Jan 2006 12:48:05 +0100 (CET), Thijs Kinkhorst <[EMAIL PROTECTED]> 
said: 

> On Sat, January 21, 2006 21:52, Manoj Srivastava wrote:
>> So, can the developers dispute this? Obviously, the developer body
>> can dispute any delegated action. But a GR can't overturn something
>> seen as fact (so no GR stating PI=exacly 3.14 or 22/7).

> Could you please explain how you arrive at the conclusion that an
> interpretation of guidelines can be seen as a fact?

If you do not see closed source software as incontrovertibly
 non-free, I have no desire to discuss this issue with you.

> This is not exact science, even though you link it to the value of
> pi. In judicial systems one can dispute an interpretation of the law
> at a court, because the law is seen as something that is subject to
> interpretation.

Even inexact sciences have things accepted
 axiomatically. Under some (extreme) viewpoints, there are no facts
 (you, sir, are a figment of my imagination, as is the universe).

> This goes even further here, because the DFSG is not even a strict
> set of rules but are guidelines. As we all know, guidelines are
> subject to interpretation on a case-by-case basis, that's what
> distinguishes them from rules. Therefore, I think a specific
> application of guidelines can not be seen as a fact.

This is not a metaphysical or existential debate. If you are
 of the opinion that everything about licensing is a matter of
 opinion, and every opinion counts, I must beg to differ.  If opinions
 are scattered on an issue like a bell curve, I am not interested in
 the long tails --- and I am trying to determine how far off the mean
 ad along the tail my own opinion lies.


manoj

-- 
Good night, Mrs. Calabash, wherever you are.
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]

ITP vexim

[Daniel Knabl]

Hi there,

as i use this piece of software already on my own host, i would like to
provide it to any other users.

for the first steps i have created a directory "vexim-2.2.rc1". it
includes all of the used files (most are *.php files). next i did
"dh_make" on it.
as i think it is a single binary i have coosen this.

if there is anyone willing and/or able to help me with the next steps i
would be very happy. right now i have some questions on how to get
debconf and templates working, so that the user can interact whilest
installing. this would be very important - however i do not really know,
how to get the user's input and how to process it further. i think
about cryptic postinst script using many lines containing sed
s/@bla@/$user_in/ > $tempfile ...

but first of all i would need some help on the control-file, the
rules-file and on "how to resolve dependencies" of my package.

anyone willing to help: have a look at http://knabl.com/~daniel/vexim
there you will find my (at least daily) changed files, and every change
that seems to work or needs to be fixed will also be there.

sorry, but i can not install cvs or svn repository there, it is just my
user-account ;-)

thanks in advance
Daniel

-- 
mfg
Daniel Knabl  http://www.tirolinux.net
PGP Fingerprint   [EMAIL PROTECTED]
A069 671B 39F2 E9B9 FB34  68BB 4BEC 1344 C8A4 3F0B


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

Re: For those who care about the GR

[Manoj Srivastava]

On Sun, 22 Jan 2006 13:59:15 +0100, Martijn van Oosterhout
<[EMAIL PROTECTED]> said:  

> 1. debian-legal is wrong, the GFDL is compatable with the DFSG and
>thus should be included in main.

Looking over the arguments for and against it in -legal, I am
 trying to ascertain if this stance has a leg to stand on.

> 2. I know the GFDL isn't compatable with the DFSG but I think it
>should be allowed in main anyway.

Which is where we are.

> 3. I know the GFDL isn't compatable with the DFSG but the DFSG is
>only for software not documentation, so it's allowed in main for
>documentation only. :)

We have already decided this is incorrect via GR's

> It seems that some people see the vote as meaning 1 and others want
> meaning 2. The latter would seems to require changing the SC, the
> former wouldn't.

Quite.  I think that people who want to establish one should
 do it separately from this current GR that is trying to explain why
 we think it is non-free.

manoj
-- 
BEWARE!  People acting under the influence of human nature.
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: For those who care about the GR

[Manoj Srivastava]

On Sun, 22 Jan 2006 10:36:05 -0300, Margarita Manterola <[EMAIL PROTECTED]> 
said: 

> On 1/21/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>> 
>> So, I am seeking arguments and guidance from the developer body
>> whether issue 1 can, and should, be decidable by a general
>> resolution, or whether the freeness of the GFDL licensed works
>> without invariant clauses is incontrovertibly non-free, as the
>> license is currently written.

> Although I haven't yet made up my mind about the issue itself (i.e
> if the GFDL without invariant sections is free or not), I consider
> that it is a matter of interpretation, and not a matter of fact, and
> therefore it can be decided by a GR.

The issue remains happily moot unless that GR is actually
 proposed, though.

manoj
-- 
I hope if dogs ever take over the world and they choose a king, they
don't just go by size, because I bet there are some Chihuahuas with
some good ideas.
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: yet another mass bug filing on GFDL issues ?

[Daniel Jacobowitz]

On Sun, Jan 22, 2006 at 09:58:58AM -0500, Anthony DeRobertis wrote:
> Holger Levsen wrote:
> 
> > Hm, on a second thought this (*) _might_ be a feature: the GFDL says 
> > invariant 
> > sections need to be listed, but there aren't any, as a template has been 
> > used. Yay ?!
> 
> I suspect that many of those cases might just be an accidental ommission
> in the copyright file...
> 
> OTOH, it is hillarious that after typing 'info gdb' I was unable to
> actually find the statement saying the documentation is under the GFDL;
> it appears that the FSF has once again mis-applied their own license...

Incorrect.  I clarified this with the GDB documentation expert; for
some reason the license is in the Info file (you can find it with a
text editor) but deliberately does not show up in an Info browser.
Which makes fair sense; normally the license is in the source code,
not in the binary.

  http://sourceware.org/ml/gdb/2005-12/msg00126.html

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: For those who care about the GR

[Wesley J. Landaker]

On Sunday 22 January 2006 11:59, Manoj Srivastava wrote:
> On Sun, 22 Jan 2006 10:21:13 -0700, Wesley J Landaker <[EMAIL PROTECTED]> 
said:
> > On Saturday 21 January 2006 13:52, Manoj Srivastava wrote:
> >> So, I am seeking arguments and guidance from the developer body
> >> whether issue 1 can, and should, be decidable by a general
> >> resolution, or whether the freeness of the GFDL licensed works
> >> without invariant clauses is incontrovertibly non-free, as the
> >> license is currently written.

> > My reading of all the options of this GR so far have the effect of
> > stating how the Debian project is interpreting the DFSG with respect
> > to the GFDL.

> I beg to differ. The original proposal was to explain the
>  stance Debian has already taken, as evidenced  by the BTS usertags
>  gfdl and nonfree-doc, and the release team statement -- and how the
>  license may be fixed.

Well, I believe that the original proposal was to *determine* the stance 
Debian should take. Anyway, you asked, as Project Secretary, for arguments 
and guidance from developers, so I provied my input.

> If you someone wants to change how Debian interprets the GFDL,
>  it should be a separate issue -- and quite likely should be done
>  before. Why is it that no one cared to override the delegates
>  decision until a statement explaining the decision is being issued?

Well, this last paragraph makes it sound to me like you've already made up 
your mind. If you are actually interested in why I personally didn't 
publicly make a big deal about the delegates decision, I'd be happy to 
discuss it some other time, but I don't think my action or inaction 
actually relevent to this GR.

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgpUQiyx78o3N.pgp
Description: PGP signature

Re: Is mesa actually maintained?

[David Nusinow]

On Tue, Jan 10, 2006 at 11:18:18PM -0500, David Nusinow wrote:
> I've got an NMU prepared and sitting in the XSF svn repo[0]. Almost all the
> work was done by Daniel Stone, so I mainly had to add the appropriate bug
> closers in the changelog. 
> 
> This NMU will depend on a new version of libdrm.  I've uploaded the libdrm
> NMU as well, but because it involves an soname change it's sitting in NEW
> right now, waiting. This mesa NMU will also have to wait in NEW as well,
> because it involves various package name changes that were discussed
> between Daniel, Marcello, and Michel Dänzer. But things are ready to go and
> this will clear out the vast majority of the bugs filed against the
> packages.

I've just uploaded the NMU finally. Once it's processed in NEW, it should
be in good shape.

 - David Nusinow


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

Re: For those who care about the GR

[Bill Allombert]

On Sat, Jan 21, 2006 at 02:52:01PM -0600, Manoj Srivastava wrote:
> 
> I am, at this point, unclear whether I hold GFDL licensed
>  works without invariant texts non-free as a matter of opinion, or of
>  fact.

Fact 1: The GFDL include this:

 "You may not use technical measures to obstruct or control the
  reading or further copying of the copies you make or distribute."

Fact 2: The DFSG include this:

6. No Discrimination Against Fields of Endeavor

 The license must not restrict anyone from making use of the program in
 a specific field of endeavor. For example, it may not restrict the
 program from being used in a business, or from being used for genetic
 research.

Fact 3:

There exist fields of endeavours that require mandatory encryption.
For example, if you work in security-sensitive field, you can be
required to use a hard-drive with built-in encryption.  This technology
certainly control who can read the disk.  In that case, you cannot copy a
GFDL licensed document to your computer for reading it.

Fact 4: the GFDL is incompatible with DFSG 6.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: For those who care about the GR

[David N. Welton]

Manoj Srivastava wrote:
> On Sun, 22 Jan 2006 13:59:15 +0100, Martijn van Oosterhout
> <[EMAIL PROTECTED]> said:  
> 
> 
>>1. debian-legal is wrong, the GFDL is compatable with the DFSG and
>>   thus should be included in main.
> 
> 
>   Looking over the arguments for and against it in -legal, I am
>  trying to ascertain if this stance has a leg to stand on.

... and ?

I am still trying to ascertain whether debian-legal has a leg to stand on.

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/


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

Re: For those who care about the GR

[Manoj Srivastava]

On Sun, 22 Jan 2006 10:21:13 -0700, Wesley J Landaker <[EMAIL PROTECTED]> said: 

> On Saturday 21 January 2006 13:52, Manoj Srivastava wrote:
>> So, I am seeking arguments and guidance from the developer body
>> whether issue 1 can, and should, be decidable by a general
>> resolution, or whether the freeness of the GFDL licensed works
>> without invariant clauses is incontrovertibly non-free, as the
>> license is currently written.

> I believe this issue is a matter of interpretation, especially given
> that the DFSG is specifically and explicitly intended to be a set of
> guidelines.

Noted.

> My reading of all the options of this GR so far have the effect of
> stating how the Debian project is interpreting the DFSG with respect
> to the GFDL.

I beg to differ. The original proposal was to explain the
 stance Debian has already taken, as evidenced  by the BTS usertags
 gfdl and nonfree-doc, and the release team statement -- and how the
 license may be fixed.

If you someone wants to change how Debian interprets the GFDL,
 it should be a separate issue -- and quite likely should be done
 before. Why is it that no one cared to override the delegates
 decision until a statement explaining the decision is being issued? 

manoj
-- 
Dying is one of the few things that can be done as easily lying
down. Woody Allen
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: For those who care about their packages in Ubuntu

[Petter Reinholdtsen]

[David Weinehall]
> Since all Ubuntu packages are recompiled against a different set of
> libraries, the bug might not even affect the Debian package, even though
> they share the same source.

The same can be said about Debian architectures, when the autobuilder
build the packages at different times and with different sequences,
leaving the same source package build with different libraries on
different archs in Debian.  I guess on a good day we might see Ubuntu
as another arch for the packages were the same source is used...


> Hence having Ubuntu developers triage the bugs to rule out such
> issues before they are forwarded to Debian's BTS is always a good
> thing;

Yes, this is generally a good idea. :)

> thus the maintainer field should be changed for *binary packages*.

This is probably a good idea, yes.  Personally I do not mind being the
"maintainer" of binary packages build from unmodified sources in
Ubuntu.  I'm do not have any problem with being listed as "maintainer"
for modified packages either, but would prefer people with ubuntu to
do triage before a bug is reported to BTS, to make sure the problem
isn't related to the ubuntu environment.


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

Re: ITP vexim

[Marc 'HE' Brockschmidt]

Daniel Knabl <[EMAIL PROTECTED]> writes:
> but first of all i would need some help on the control-file, the
> rules-file and on "how to resolve dependencies" of my package.

There is no Hotline for desperate wannabe-DDs. Read the documentation as
everybody else and ask concrete questions when they arise.

Marc
-- 
BOFH #5:
static from plastic slide rules


pgpO2tl2bhnzX.pgp
Description: PGP signature

Re: Aptitude question

[Daniel Burrows]

On Mon, Jan 16, 2006 at 10:57:22AM +0900, Miles Bader <[EMAIL PROTECTED]> was 
heard to say:
> Daniel Burrows <[EMAIL PROTECTED]> writes:
> > When you say that normal operation is getting slower, do you mean just
> > the load time or its overall performance?  The time required to load
> > in all the state files is a bit long, but once they're loaded the
> > program seems to run reasonably quickly to me.
> 
> The really problematic thing is indeed the state-file loading time; it
> seems to take 30 - 40 seconds on my machine (with no disk I/O as the
> files are already cached by the kernel).

  It would be interesting to see profile data for this.  The new aptitude
has a "nop" command that does nothing but load the cache and then stop,
the better to get profiling information (but it's too fast on my computer
to yield useful results).

  A lot of what aptitude is doing there is parsing RFC822-alike files
using core apt code, and it's possible that the apt end of things could
be optimized.  There's even a patch in the BTS that eliminates various
unnecessary copies (#$319377), although it might be better in some cases
to prevent aptitude from calling those routines so many times (e.g., it
should really be caching configuration values rather than doing lookups
in the middle of a long loop).

> Normal operation is generally OK, though some searches (e.g. "~dfoo")
> are so slow as to be almost useless -- especially given that it's
> "i-search", so a super-slow search gets repeated for every key as you
> type the search string!

  I suspect that the problem with searches is due to locality: aptitude
has to access several structures/files to perform a search, and (IIRC)
it only attempts to order accesses along one "axis".  i.e., it accesses
packages in the order that they occur in the main cache, but this isn't
necessarily the same order that they occur in, e.g., the Description files.

  If you look at the apt-cache code, in contrast, you'll see that it does
a two-pass search, first iterating through the package cache to match
package names, then sorting packages according to their order in the
description file to match descriptions.  This is easy for apt-cache, since
it only has one type of match; aptitude's much more complex matching
language and search architecture would require some more effort to optimize
this way.

  I had some notes at one point on modifying aptitude's search to be
multi-pass in order to increase locality, but I didn't get around to
carrying through on the project.

> >   The main thing that changed recently that would impact the program's speed
> > under normal use is the switch to using Unicode internally, which means that
> > many string manipulations take 4x as long, and input strings (e.g., from
> > package descriptions) have to be decoded before they're used.
> 
> Do you know if the package/state files so large that it's really running
> against fundamental memory bandwidth problems?  I've noticed (in my own
> programs) that some standard C++ library code, e.g. reading from
> io-streams, seems suspiciously slow (though I've not confirmed this with
> measurements)...

  I doubt that the code is hitting any fundamental limits, since you
mentioned that the program is slow even when everything is cached.  The
standard library generally seems reasonably quick to me, although I avoid
iostream input like the plague.

  Daniel


signature.asc
Description: Digital signature

Re: Derived distributions and the Maintainer: field

[Hamish Moffatt]

> Thomas Bushnell BSG wrote:
> > Henning Makholm <[EMAIL PROTECTED]> writes:
> >> You seem to require a standard of attribution in the Maintainer field
> >> that Debian does not itself follow in our default procedures.  To wit:
> >> NMUs _within_ Debian keep the Maintainer field unchanged.
> > 
> > The difference is that a Debian Maintainer can replace the NMU any
> > time he wants with his own package.
> > 
> > I don't have the same ability to replace a non-Debian altered package.

On Sat, Jan 21, 2006 at 10:28:23PM +, Martin Meredith wrote:
> The only reason packages are changed in ubuntu is because they don't work
> as expected in ubuntu - whether this be a different "vision" for the
> package's use, or just a problem with it having gone through a different
> transition/having a different toolchain, is a different point. But even so
> - We DO try and use as many things as possible from debian unchanged ;)

ALSO, new upstream versions which weren't otherwise required for
transitions. Example package: xastir.

Please don't top post.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

[Loïc Minier]

Hi,

On Fri, Jan 20, 2006, Simon Richter wrote:
> And GNOME would by default be configured to launch gnome-www-browser,
> thus solving the problem for GNOME users who do not set any other
> browser in gnomecc. The question for me would be whether this affects 
> people who use neither GNOME nor KDE (the browsers optimized for a 
> specific environment could then be demoted to some lower priority than 
> the non-specific ones, perhaps?)

 GNOME could then be configured to launch either sensible-browser or
 gnome-www-browser (my preference would go to sensible-browser because
 it makes sense system-wide, not only under GNOME).

 I'm not sure about demoting the priorities.  I think priorities should
 decrease with the number of users because the more specific a package
 is (in terms of number of users) the more likely you want it to be the
 default, but I suppose there's no general rule, and it's difficult to
 measure the importance of launching a browser matching the current
 environment with respect to its popularity.

> > These changes were commited in galeon and epiphany's SVN, the changes
> > to sensible-browser and to firefox remain to be done.
> You mean, that they now register as an alternative for gnome-www-browser?

 epiphany-browser and galeon do, yes.

> > Of course, this could be followed for KDE too.
> It should not be difficult to get that done. I had somehow expected that 
> the bug report and any followups are forwarded to -devel to spark 
> discussion, so I'm explicitly forwarding it there.

 My response went through debian-devel when I Cc: the bug report, so
 I'm continuing this way.

> Not entirely, since it isn't limited to browsers or terminals. Many 
> users have personal preferences about things that are currently handled 
> through the alternatives system, and the sysadmin's choice (or 
> non-choice, as in the "bumping priorities" scenario) will affect them.

 Yes.  However, I consider that the system command sensible-browser is
 user-configurable (via $BROWSER) and the GNOME environment is
 user-configurable (via gconf settings), so for the browser choice front
 system-wide and in GNOME, I'm satisfied with the way of things.

> For example, everytime a GNOME or KDE application launches, a lot of 
> dotfiles will be created for me, so I'd like to avoid this as much as 
> possible as I will only have to clean up afterwards.

 Hmm, this sounds like a whole new class of problems.

   Cheers,
-- 
Loïc Minier <[EMAIL PROTECTED]>
Current Earth status:   NOT DESTROYED

Re: ITP vexim

[Marc Haber]

On Sun, 22 Jan 2006 17:50:32 +0100, Daniel Knabl
<[EMAIL PROTECTED]> wrote:
>but first of all i would need some help on the control-file, the
>rules-file and on "how to resolve dependencies" of my package.

You have already been pointed towards debian-mentors multiple times.

Greetings
Marc

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

Bug#349424: ITP: xcftools -- command-line tools for extracting data for XCF files

[Henning Makholm]

Package: wnpp
Severity: wishlist
Owner: Henning Makholm <[EMAIL PROTECTED]>

* Package name: xcftools
  Version : 0.5
  Upstream Author : Henning Makholm <[EMAIL PROTECTED]>
* URL : http://henning.makholm.net/software
* License : GPLv2
  Description : command-line tools for extracting data for XCF files

This is a set of fast command-line tools for extracting
information from the Gimp's native image file format XCF.
The tools are designed to allow efficient use of layered XCF
files as sources in a build system that use 'make' and similar
tools to manage automatic processing of the graphics. These
tools work independently of the Gimp engine and do not require
the Gimp to even be installed.

"xcf2pnm" converts XCF file to ppm, pgm or pbm format, flattening
layers if necessary. If the image contains transparency, an alpha map
can be written to a separate file, or a background color can be
specified on the command line. The tool can either flatten the XCF
file as given, or extract specific layers named on the command line.

"xcfinfo" lists information about layers in an XCF file.



... Note that I am the upstream author myself. I wrote this tool
because I need it myself and there seems to be nothing comparable
available on the net. Then I put some extra work into polishing it
up for general consumption, because it seemed to be the Right Thing
to do - I cannot be the only one who have whished for such a tool
to exist.

There is a "xcftopnm" binary in gimp-perl, but it is very slow,
starting the Gimp engine to do the work. "Convert" from imagemagick
supposedly also understands XCF files, but not the ones I work with,
and it would probably be overkill to try to extend its command-line
interface to know about layers.

Nonetheless, packaging one's own software does smell slightly of
"vanity package" -- I'd appreciate comments. (IAADD, so I don't
desperately _need_ to package this, but Debian is still the most
convenient channel for making this widely available).

-- 
Henning Makholm"Amanda, I'm a mad scientist!
Testing crazy things on myself and those
 who are close to me is my job. It's what I do!"


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

Re: For those who care about the GR

[Thijs Kinkhorst]

On Sun, 2006-01-22 at 10:57 -0600, Manoj Srivastava wrote:
>  If you do not see closed source software as incontrovertibly
>  non-free, I have no desire to discuss this issue with you.

You are exaggerating my point into ridicule.

> Under some (extreme) viewpoints, there are no facts
>  (you, sir, are a figment of my imagination, as is the universe).

You are exaggerating my point into ridicule.

> If you are of the opinion that everything about licensing is a
> matter of opinion,

You are exaggerating my point into ridicule.

I don't think it's useful to take this discussion any further if this is
the way it's done. I am willing to learn from a discussion, to accept
that I perhaps misunderstood things or that simply opinons differ. I'm
also willing to accept that someone doesn't want to discuss something at
all. This kind of response does nothing except demotivating me to even
care about this issue. Thanks.


Thijs


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

Re: Bug#349424: ITP: xcftools -- command-line tools for extracting data for XCF files

[Daniel Kobras]

On Sun, Jan 22, 2006 at 10:29:27PM +0100, Henning Makholm wrote:
> There is a "xcftopnm" binary in gimp-perl, but it is very slow,
> starting the Gimp engine to do the work. "Convert" from imagemagick
> supposedly also understands XCF files, but not the ones I work with,
> and it would probably be overkill to try to extend its command-line
> interface to know about layers.

Imagemagick in general can handle multi-layered images just fine. I'm
not sure whether this is true for its xcf module already, but the
necessary framework is certainly there. So if you don't want to keep
maintaining a separate utility, merging it with the code in imagemagick
might be an option for you.

Regards,

Daniel.


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

Re: For those who care about the GR

[Steve Langasek]

On Sun, Jan 22, 2006 at 12:53:00PM -0600, Manoj Srivastava wrote:
> On Sun, 22 Jan 2006 19:25:58 +0100, David N Welton <[EMAIL PROTECTED]> said: 

> > Manoj Srivastava wrote:
> >> On Sun, 22 Jan 2006 13:59:15 +0100, Martijn van Oosterhout
> >> <[EMAIL PROTECTED]> said:

> >>> 1. debian-legal is wrong, the GFDL is compatable with the DFSG and
> >>> thus should be included in main.

> >> Looking over the arguments for and against it in -legal, I am
> >> trying to ascertain if this stance has a leg to stand on.

> > ... and ?

> And what? If someone tries to bring through a GR stating that
>  MS office warez can be distributed in main since it meets the DFSG,
>  one might rule that as frivolous and a waste of time.

I'm not convinced the constitution gives the secretary the power to make
such a ruling.  There are no provisions in the constitution for the Project
Secretary to dismiss a GR -- *even* a GR stating that the Debian Project
holds the value of pi to be 3 -- so long as the GR has the requisite number
of seconds.

In the present case, I understand that the proposed ballot option is
ambiguous wrt whether it constitutes an implicit amendment to the foundation
docs, and that in the absence of clarification (in the form of a re-worded
proposal) on the part of the proposer, it is the project secretary's
prerogative to specify a supermajority requirement.  But I don't think that
extends to dismissing a GR that you happen to believe is inconsistent with
reality.

FWIW, aside from not being covered as a constitutional power of the
secretary, I think trying to stop a GR this way would be pretty darn futile.
If half of the project wants to vote in favor of saying pi=3, we're pretty
well screwed whether or not the vote actually happens.

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

A great weekend for Debian

[Joseph Smidt]

On Friday morning I looked at the RC report and there was about 1300
bugs total with 550 that will affect the next release.  Now there
is 1090 total and falling, possibly will go down to about 1000 as the
weekend finally ends.  Similarly there is currently 387 that will
affect the next release with the possibility of going down to 350 by
the end o the weekend.  That would be as many as 300 bugs fixed in
one weekend with 200 concerning the next release.  I say what a
great weekend! :)  

  
Joseph Smidt

Bug#349440: ITP: qfaxreader -- A versatile multipage TIFF and fax viewer

[Stan Vasilyev]

Package: wnpp
Severity: wishlist
Owner: Stan Vasilyev <[EMAIL PROTECTED]>


* Package name: qfaxreader
  Version : 0.3
  Upstream Author : Serghei Amelian <[EMAIL PROTECTED]>
* URL : http://qfaxreader.sourceforge.net
* License : GPL
  Description : A versatile multipage TIFF and fax viewer

QFaxReader is a monochrome/color multipage .TIFF files visualisation
utility designed for viewing faxes. Currently Debian lacks a
full-featured multipage viewer. There is kfax that does a similar job
but it fails on many tiff files. At this moment QFaxReader is the only
Linux application that renders multipage tiff files correctly.

Features:

* Handle multi page monochrome/color tiff/fax files
* Correctly display fax images in any resolution
* Printing fax files (multiple pages per sheet capability)
* Image transformation (rotate left, rotate right, vertical flip)
* Arbitrary zoom fax images (with fit height/width support)
* Sidebar with easy navigation through directories
* AutoRefresh + notification for new facsimiles
* Aliases database for replacing faxes id's with real name
* Export in all formats which your QT have support
* Fullscreen mode
* CID support

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: yet another mass bug filing on GFDL issues ?

[Ben Burton]

> Do a 
> 
>  find /usr/share/doc -name copyright -exec grep -l "YOUR NAME" {} \;
> 
> to find those packages on your system. (This might cause a few false 
> positives, figlet for example is not affected :)

Hmm, I suspect this will find a very large number of false positives
since "YOUR NAME" shows up in the addendum ("how to use this license for
your documents").

I looked up a couple of KDE packages (kdeedu, kdebase), which both match
your grep (due to the addendum) but which both have the full "no invariant
sections, no front-cover texts, no back-cover texts" blurb appearing before
the license itself.

Ben.


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

Meta pkgs in debian

[Ed Sweetman]

Ok, i'm not subscribed here so please cc me any responses directly.

Before I propose my suggestion I want to outline my issues with how meta 
pkgs are done currently. 

Meta pkgs by my own definition here are pkgs which have no payload of 
their own, but have their "Depends" field loaded with various selected 
pkgs, that dpkg and the like will ask or automatically retrieve and 
install when the meta pkg is installed.


The problem #1: Because meta pkgs use the Depends field to do their job, 
they are removed from the system whenever one of the pkgs they "Depend" 
on is removed. 

The problem #2: Meta pkgs in debian are one way.  Removing a meta pkg 
doesn't remove or even check for the pkgs it installed to see if they 
are no longer dependent on anything or ask the user if they want to 
remove them.  Because of problem #1, removing a meta pkg isn't even 
possible if you remove one of the pkgs it installed, because according 
to the system, the meta pkg is already uninstalled.



My proposed solution is to make meta pkgs use the Suggests field instead 
of the Depends field to cause frontends (dselect and i believe aptitude 
already support this) to either automatically or ask the user to install 
the pkgs the meta pkg is supposed to encompass.  This makes just as much 
sense when reading the control file as "Depends" does, and it doesn't 
really break the purpose of the Suggests field, no more than using the 
Depends field for meta pkgs does.   But, we get around the removal of 
the Meta pkg, when a pkg that was installed by it is removed, problem.  
Other than using the suggests field, nothing else changes, the only real 
userspace change you might want to make is to give apt-get the ability 
to install suggested pkgs (which isn't a totally bad idea regardless). 
(--suggest for example) 

The second problem is more controversial, and a bit complex, but not 
already solved mostly.  

Solution #1 : apt-get has very limited removal ability compared to 
something like debfoster.  The patch to debfoster would be to look at 
the pkg list field for the requested program to be removed and look at 
it's Depends and Suggests and create a list of those pkgs that are no 
longer being depended on, and allow the user to remove those it finds, 
automatically or not via a switch. 

Solution #2 : if we really want apt-get to remove meta pkg (it can't the 
current way it's done anyway), we can use our new argument (--suggest) 
with remove to tell apt-get to remove the pkgs in the "Suggests" 
field.   This isn't a necessary solution though, apt-get can't remove 
meta pkgs now anyway, so changing meta pkgs to "Suggests" wont affect 
apt-get in any way for remove. 

I personally would only consider debfoster for removing meta pkgs, since 
it requires some complexity for finding what's being depended on and 
already has flags for not selected non-libs and such.  Patching it would 
be much simpler than giving debfoster's features to apt-get (something 
that would be partly required to properly remove meta pkgs).



What this means : 
1.We can remove pkgs that a meta pkg installs, without removing the meta 
pkg (so we can later use debfoster to remove the rest, without 
remembering them all).
2. By using the Suggests field in the control file for the meta pkg, we 
already have out of box support for meta pkgs by dselect and aptitude.  
apt-get wouldn't be that hard to patch.
3. By using the Suggests field, non-aware pkg frontends wont break, 
there is no need to have them all updated at the same time, nor is there 
any problem with mixed old style and new style meta pkgs.  Using 
suggests wont be mutually exclusive with using Depends for meta pkgs, it 
just provides a way to remove pkgs it lists and still be able to remove 
the rest while keeping later code to remove the meta pkg from having 
dependency issues.
4. By using Suggests, we aren't reversing the dependency list when we 
use a frontend (like debfoster) to remove a meta pkg.  Of course this is 
just semantics, but it's an important one, reversing the Depends list is 
bad and could lead to problems.  Reversing the suggests list means there 
is no chance of circular dependency issues when removing, since the pkg 
manager doesn't use suggests as a dependency during resolution.


So we basically complete the meta pkg by making it possible to remove 
under all circumstances and install (install works now, without any 
changes with some common pkg installers), keep everything backwards 
compatible with older pkgs and pkg managing programs, keep the control 
file, installing and removing logically sane and all without having to 
add anything to the control file or change anything other than the 
frontends (and very little there needs to be done except maybe debfoster 
removal code...)


anyway, just an idea.  If people like it, i'll even work out a patch for 
apt-get to use suggests to install pkgs optionally, since that's a nifty 
feature anyway.  




--
To UNSUBSCRIBE, ema

Pre-Depends for Xorg 7.0

[David Nusinow]

Hi all,
   One of the changes happening for Xorg 7.0 is that it will finally become
FHS compliant. Currently, it fakes FHS compliancy by creating various
symlinks (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate
directories in /usr/X11R6. For 7.0, we need to make those symlinks become
actual directories. We're currently using the x11-common package to do
this, although the XSF is considering unifying this package with
xorg-common and naming the single common package xorg-common. Either way,
this transition will be done by one of the -common packages.

   Because the remainder of the Xorg 7.0 packages will require this change
to have taken place, they will have to pre-depend upon an appropriate
version of x11-common. As such, I'm writing to the list in accordance with
policy.

   The code to enact this change has been deployed successfully in Ubuntu
and should translate just fine to Debian. I'll be uploading packages to
experimental shortly to test for this, although I don't recommend anyone
use it outside of a chroot until we have a more or less complete X suite
available in experimental. If you have any questions or comments, please
feel free to ask.

 - David Nusinow


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

Re: A great weekend for Debian

[Steinar H. Gunderson]

On Sun, Jan 22, 2006 at 05:33:42PM -0700, Joseph Smidt wrote:
> On Friday morning I looked at the RC report and there was about 1300 bugs
> total with 550 that will affect the next release.  Now there is 1090 total
> and falling, possibly will go down to about 1000 as the weekend finally
> ends.  Similarly there is currently 387 that will affect the next release
> with the possibility of going down to 350 by the end o the weekend.  That
> would be as many as 300 bugs fixed in one weekend with 200 concerning the
> next release.  I say what a great weekend! :)

I think you're overly optimistic :-) Most of the simple RC bugs (related to
the xlibs-dev transition) have been fixed; there aren't 90 more like those.
Those left are:

  http://bugs.debian.org/cgi-bin/[EMAIL 
PROTECTED]:transition-xlibs-dev&repeatmerged=no

I guess there will soon be less than 50 left (some uploads haven't gone
through yet); ten of those are tagged pending (I won't NMU them under the
nose of an active maintainer, and I doubt many others will). The remaining
ones are either blocked by other packages, depend on other FTBFS bugs, on
removed packages or otherwise not possible to upload in five minutes like the
others were.

OTOH, the upload rate has really been impressive at times -- I guess the poor
buildds will have enough to do for a little while. :-)

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


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

Re: when and why did python(-minimal) become essential?

[Anthony Towns]

On Sat, Jan 21, 2006 at 01:16:55PM -0800, Matt Zimmerman wrote:
> I have said repeatedly that I am not expressing an opinion about what Debian
> does with regard to python-minimal.  The only reason I am participating in
> this thread is to answer questions about what we did in Ubuntu and why, and
> I think I've done that thoroughly now.

Are there any examples of .config's or base packages that use python
in python?

Cheers,
aj


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

Re: For those who care about the GR

[Anthony Towns]

On Sun, Jan 22, 2006 at 12:53:00PM -0600, Manoj Srivastava wrote:
> And what? If someone tries to bring through a GR stating that
>  MS office warez can be distributed in main since it meets the DFSG,
>  one might rule that as frivolous and a waste of time.

One answer to this would be to let them have that as a vote, and trust
the developers to vote that it's a daft resolution for the project to
make. I don't think the secretary needs to stand against that sort of
idiocy, in place of the project as a whole.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Pre-Depends for Xorg 7.0

[Joey Hess]

David Nusinow wrote:
>One of the changes happening for Xorg 7.0 is that it will finally become
> FHS compliant.

FWIW, the FHS 2.1 specifies /usr/X11R6 in section 4.1. I can't see
anything FHS-incompliant about the current setup.

> Currently, it fakes FHS compliancy by creating various
> symlinks (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate
> directories in /usr/X11R6. For 7.0, we need to make those symlinks become
> actual directories. 

I thought that the idea instead was to move everything directly into
/usr/include, /usr/bin, and /usr/lib. Why keep the X11 subdirectories?

Note that the FHS has this to say about /usr/bin/X11 and friends:

  In general, software must not be installed or managed via the above symbolic
  links. They are intended for utilization by users only. 

>Because the remainder of the Xorg 7.0 packages will require this change
> to have taken place, they will have to pre-depend upon an appropriate
> version of x11-common. As such, I'm writing to the list in accordance with
> policy.

What about all the packages that you don't control that also still put
things in /usr/X11R6? Recall that policy allows this for anything still
using Imake, as well as mandating it for any package containing X fonts.

If the idea is to make /usr/*/X11 real directories and stop using
/usr/X11R6 then all those package would also need to be updated and have
a predependency added too. Seems easier just to move everything in X to
/usr/bin, /usr/include, and /usr/lib.

Also, moving stuff to /usr/bin/X11 and making it a real directory will
break things for anyone having /usr/X11R6/bin in their path instead. One
example of such a path is in pbuilder.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Pre-Depends for Xorg 7.0

[David Nusinow]

On Mon, Jan 23, 2006 at 12:15:23AM -0500, Joey Hess wrote:
> David Nusinow wrote:
> >One of the changes happening for Xorg 7.0 is that it will finally become
> > FHS compliant.
> 
> FWIW, the FHS 2.1 specifies /usr/X11R6 in section 4.1. I can't see
> anything FHS-incompliant about the current setup.

As far as I understand it, this is simply grandfathered in. I'm not that up
on the FHS details though, so I may be wrong. Remember also that this isn't
X11R6 any more, but X11R7.

> > Currently, it fakes FHS compliancy by creating various
> > symlinks (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate
> > directories in /usr/X11R6. For 7.0, we need to make those symlinks become
> > actual directories. 
> 
> I thought that the idea instead was to move everything directly into
> /usr/include, /usr/bin, and /usr/lib. Why keep the X11 subdirectories?

Right. The everything that you'd expect to go in to /usr/bin and /usr/lib
will install there, at least as far as Xorg goes. An example of that is
that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin.
I haven't finished the packaging of everything, but it seems that some of
the header files are put in to differenct dirs of /usr/include. I'll
investigate the reasoning for this further. As for /usr/lib/X11, data files
like fonts currently go in there.

> Note that the FHS has this to say about /usr/bin/X11 and friends:
> 
>   In general, software must not be installed or managed via the above symbolic
>   links. They are intended for utilization by users only. 
> 
> >Because the remainder of the Xorg 7.0 packages will require this change
> > to have taken place, they will have to pre-depend upon an appropriate
> > version of x11-common. As such, I'm writing to the list in accordance with
> > policy.
> 
> What about all the packages that you don't control that also still put
> things in /usr/X11R6? Recall that policy allows this for anything still
> using Imake, as well as mandating it for any package containing X fonts.

Right, they're still allowed to as far as I'm concerned. It's basically
that Xorg is giving up claim on that directory in a sense. I don't know
about the fonts issue given the above, I'll look in to that. 

> If the idea is to make /usr/*/X11 real directories and stop using
> /usr/X11R6 then all those package would also need to be updated and have
> a predependency added too. Seems easier just to move everything in X to
> /usr/bin, /usr/include, and /usr/lib.
> 
> Also, moving stuff to /usr/bin/X11 and making it a real directory will
> break things for anyone having /usr/X11R6/bin in their path instead. One
> example of such a path is in pbuilder.

As far as I currently know, all the apps will go to /usr/bin so it
shouldn't break anything. I haven't packaged most of the apps though yet,
so I can't say this for certain. I'll investigate it when I get to that
stage of the process.

We also have to consider that these decisions were made by upstream, not
myself. These choices were made to make X a good citizen in the current
unix world, and the fact that they are disruptive is the reason for the
bump from X11R6 to 7.

 - David Nusinow


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

Re: Pre-Depends for Xorg 7.0

[Russ Allbery]

David Nusinow <[EMAIL PROTECTED]> writes:
> On Mon, Jan 23, 2006 at 12:15:23AM -0500, Joey Hess wrote:
>> David Nusinow wrote:

>>> Currently, it fakes FHS compliancy by creating various symlinks
>>> (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate
>>> directories in /usr/X11R6. For 7.0, we need to make those symlinks
>>> become actual directories.

>> I thought that the idea instead was to move everything directly into
>> /usr/include, /usr/bin, and /usr/lib. Why keep the X11 subdirectories?

> Right. The everything that you'd expect to go in to /usr/bin and
> /usr/lib will install there, at least as far as Xorg goes. An example of
> that is that the new xterm package installs to /usr/bin rather than
> /usr/X11R6/bin.  I haven't finished the packaging of everything, but it
> seems that some of the header files are put in to differenct dirs of
> /usr/include. I'll investigate the reasoning for this further. As for
> /usr/lib/X11, data files like fonts currently go in there.

I understand why /usr/include/X11 and /usr/lib/X11 would stay; after all,
those are perfectly reasonable names for what they are currently symlinks
to.  I don't understand why /usr/bin/X11 wouldn't go away completely, at
least for the programs that come with X.  Maybe that's the plan and the
above is just a bit confusing since all three of those directories aren't
treated quite the same way?

>> What about all the packages that you don't control that also still put
>> things in /usr/X11R6? Recall that policy allows this for anything still
>> using Imake, as well as mandating it for any package containing X
>> fonts.

> Right, they're still allowed to as far as I'm concerned. It's basically
> that Xorg is giving up claim on that directory in a sense. I don't know
> about the fonts issue given the above, I'll look in to that. 

Does upstream imake still dump everything into /usr/X11R6 or has it too
been modified to use a more conventional installation structure?  (Or is
imake going away completely?)

I'd love it if imake itself just used a better directory layout, since
it's going to be a *long* time before everything that currently uses imake
switches to some other build system (even if that's been in progress for
years).

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Pre-Depends for Xorg 7.0

[Peter Samuelson]

[David Nusinow]
> As far as I understand it, this is simply grandfathered in. I'm not
> that up on the FHS details though, so I may be wrong. Remember also
> that this isn't X11R6 any more, but X11R7.

Branden toyed with the idea of setting ProjectRoot to /usr when
packaging XFree86 4.0.  I was sorta hoping he'd just do it.  But in any
case I'm glad it's being done now.

> everything that you'd expect to go in to /usr/bin and /usr/lib will
> install there, at least as far as Xorg goes. An example of that is
> that the new xterm package installs to /usr/bin rather than
> /usr/X11R6/bin.  I haven't finished the packaging of everything, but
> it seems that some of the header files are put in to differenct dirs
> of /usr/include. I'll investigate the reasoning for this further. As
> for /usr/lib/X11, data files like fonts currently go in there.

Well, /usr/include/X11 continues to make sense, particularly for Xlib
and Xt, and probably for Xaw, SM, etc.  /usr/bin/X11, not so much.


signature.asc
Description: Digital signature

Re: What's the best directory to put a local Debian repository?

[Stig Sandbeck Mathisen]

Maurits van Rees <[EMAIL PROTECTED]> writes:

> - /srv/debian
>
>   According to the Filesystem Hierarchy Standard the /src dir is for
>   Data for services provided by this system, which seems to fit the
>   bill.

/srv is a good place for local data which does not fit into any other
hierarchy, so I'd go for /srv/debian.

-- 
Stig Sandbeck Mathisen <[EMAIL PROTECTED]>


pgpw5MjLrFY3P.pgp
Description: PGP signature

Re: Pre-Depends for Xorg 7.0

[Mike Hommey]

On Mon, Jan 23, 2006 at 12:48:24AM -0500, David Nusinow <[EMAIL PROTECTED]> 
wrote:
> Right. The everything that you'd expect to go in to /usr/bin and /usr/lib
> will install there, at least as far as Xorg goes. An example of that is
> that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin.
> I haven't finished the packaging of everything, but it seems that some of
> the header files are put in to differenct dirs of /usr/include. I'll
> investigate the reasoning for this further. As for /usr/lib/X11, data files
> like fonts currently go in there.

Shouldn't the fonts ans other such files go in /usr/*share*/X11, instead ?

Mike


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

Re: Pre-Depends for Xorg 7.0

[Joey Hess]

David Nusinow wrote:
> As far as I understand it, this is simply grandfathered in. I'm not that up
> on the FHS details though, so I may be wrong. Remember also that this isn't
> X11R6 any more, but X11R7.

Ok, /usr/X11R7 would probably violate either the spirit or the letter of the
FHS (probably not both :-), so I see why you want to move away from it,
it's just the issue of converting these symlinks to directories that
concerns me.

> Right. The everything that you'd expect to go in to /usr/bin and /usr/lib
> will install there, at least as far as Xorg goes. An example of that is
> that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin.
> I haven't finished the packaging of everything, but it seems that some of
> the header files are put in to differenct dirs of /usr/include. I'll
> investigate the reasoning for this further. As for /usr/lib/X11, data files
> like fonts currently go in there.

/usr/include/X11 makes some sense, it was mostly /usr/bin/X11 that I
didn't see the point of. However, even /usr/include/X11 could
potentially cause a problem, if a third party package currently installs
headers in /usr/X11R6/include/foo and xorg updates /usr/include/X11 to
be a directory rather than a symlink, then #include  will stop
working. Switching any of these directories from symlinks to real
directories seems likely to require some coordination beyond xorg.

> > What about all the packages that you don't control that also still put
> > things in /usr/X11R6? Recall that policy allows this for anything still
> > using Imake, as well as mandating it for any package containing X fonts.
> 
> Right, they're still allowed to as far as I'm concerned. It's basically
> that Xorg is giving up claim on that directory in a sense. I don't know
> about the fonts issue given the above, I'll look in to that. 

The fonts directory issue can be fixed in policy easily enough, although
again if a new version of X looks for fonts in /usr/lib/X11 and some
third party packages install them in /usr/X11R6/lib, when the former
directory stops being a symlink, those fonts won't be found.

Here's a maintainer-sorted list of packages that install files in
/usr/X11R6:

MJ Ray (Debian) <[EMAIL PROTECTED]>
   wily

Clint Adams <[EMAIL PROTECTED]>
   xmaddressbook

Russ Allbery <[EMAIL PROTECTED]>
   xfonts-jmk

Juan Alvarez <[EMAIL PROTECTED]>
   ipsc

Tore Anderson <[EMAIL PROTECTED]>
   xfonts-ay

Ryuichi Arafune <[EMAIL PROTECTED]>
   toolbar-fancy

Hakan Ardo <[EMAIL PROTECTED]>
   xfaces

Enrique Robledo Arnuncio <[EMAIL PROTECTED]>
   mctools-lite

Lars Bahner <[EMAIL PROTECTED]>
   xcal

Miros/law L. Baran <[EMAIL PROTECTED]>
   xenophilia

Michael Beattie <[EMAIL PROTECTED]>
   xdkcal

Jon Bernard <[EMAIL PROTECTED]>
   xfonts-knickers

Edward Betts <[EMAIL PROTECTED]>
   cmatrix

Bastian Blank <[EMAIL PROTECTED]>
   gpa

Eduard Bloch <[EMAIL PROTECTED]>
   emelfm

Philip Brown <[EMAIL PROTECTED]>
   kdrill

Rob Browning <[EMAIL PROTECTED]>
   guile-core

Martin Buck <[EMAIL PROTECTED]>
   xview

Randolph Chung <[EMAIL PROTECTED]>
   xgdipc

Artem Chuprina <[EMAIL PROTECTED]>
   xxkb

Debian GCC Maintainers 
   gcc-snapshot

Debian X Strike Force 
   libxrender
   renderext
   xcursor
   xft
   xorg-x11

Eric Delaunay <[EMAIL PROTECTED]>
   xtel

Scott M. Dier <[EMAIL PROTECTED]>
   xmeter

Randall Donald <[EMAIL PROTECTED]>
   gradio
   nvidia-graphics-drivers
   nvidia-graphics-drivers-legacy

Mattia Dongili <[EMAIL PROTECTED]>
   xfree86-driver-synaptics

Benjamin Drieu <[EMAIL PROTECTED]>
   w9wm

Baruch Even <[EMAIL PROTECTED]>
   xclip

Anthony Fok <[EMAIL PROTECTED]>
   xcingb
   xfonts-cmex-big5p

Gordon Fraser <[EMAIL PROTECTED]>
   wmavgload

Philipp Frauenfelder <[EMAIL PROTECTED]>
   wmnet

Peter S Galbraith <[EMAIL PROTECTED]>
   libforms1

Bdale Garbee <[EMAIL PROTECTED]>
   xtrkcad

Guenter Geiger <[EMAIL PROTECTED]>
   ivtools

Debian QA Group <[EMAIL PROTECTED]>
   dosemu
   goldedplus
   hanterm-classic
   hanterm-xf
   lmodern
   oneko
   pgaccess
   ppxp
   xmailbox
   xmem
   xsysinfo

Francois Gurin <[EMAIL PROTECTED]>
   xvkbd

Chris Halls <[EMAIL PROTECTED]>
   ayttm

Mikael Hedin <[EMAIL PROTECTED]>
   plotmtv

Joey Hess <[EMAIL PROTECTED]>
   big-cursor

Ralf Hildebrandt <[EMAIL PROTECTED]>
   xscreensaver

Simon Horman <[EMAIL PROTECTED]>
   xfont-nexus

Simon Horman <[EMAIL PROTECTED]>
   xfonts-nexus

Daniel Jacobowitz <[EMAIL PROTECTED]>
   ircii-pana

Guillem Jover <[EMAIL PROTECTED]>
   glide

Takao KAWAMURA <[EMAIL PROTECTED]>
   cmail
   xbatt

Tomohiro KUBOTA <[EMAIL PROTECTED]>
   xearth
   xfonts-efont-unicode

Zdenek Kabelac <[EMAIL PROTECTED]>
   fte

Tatsuya Kinoshita <[EMAIL PROTECTED]>
   bitmap-mule

Gerd Knorr <[EMAIL PROTECTED]>
   openmotif
   tv-fonts

Alexander Kotelnikov <[EMAIL PROTECTED]>
   fvwm-icons

Joshua Kwan <[EMAIL PROTECTED]>
   nethack

Rafael Laboissiere <[EMAIL PROTECTED]>
   tipa

Warren A. Layton <[EMAIL PROTECTED]>
   wmcpu
   wmdate
   wmscope