Re: new mplayer 1.0pre7try2 package

[Andreas Schuldei]

* Anthony Towns  [2006-01-21 06:06:36]:
> No, we have real problems with video codec stuff in Debian and they need
> to be resolved thoroughly, not expediently.

i was under the impression that the ftp-master team had started
to work on that several month ago, shortly before the last mention
of this on [EMAIL PROTECTED] is that the case?



signature.asc
Description: Digital signature

Re: Backports

[Joseph Smidt]

Joseph Smidt wrote:> Were you writing this  just to ridicule  me?No, not at all. It was just supposed to be a joke.I appologize; I should have been clearer.


I'm sorry I lashed back.  I know it was supposed to be a
joke.   So I need to apoligize too.  Humer is good,
laughter is the best medicine.

Re: new mplayer 1.0pre7try2 package

[Andrew Pollock]

On Sat, Jan 21, 2006 at 06:06:36AM +1000, Anthony Towns wrote:
> On Fri, Jan 20, 2006 at 12:08:39PM -0500, Nathanael Nerode wrote:
> > aj@azure.humbug.org.au wrote:
> > >mplayer has had an explicit warning from upstream that it's patented;
> > The proposed tarball for Debian has stuff excised left and right in
> > order to guarantee legality.  Just check that the patented stuff was
> > excised, right?
> 
> If you can demonstrate that there's nothing in there that's potentially
> patented, sure. That seems pretty unlikely, though.

Aren't we in a similar situation with other stuff that is in main already?
rsync springs to mind.

regards

Andrew


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

Re: Backports

[Joseph Smidt]

On 1/20/06, Anthony DeRobertis <[EMAIL PROTECTED]> wrote:
Joseph Smidt wrote:Well, perhaps you should read the following, printed whenever you log into your Debian machine:"Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extentpermitted by applicable law."
Hey, "without any warranty" is at least a step up from "ABSOLUTELY NOWARRANTY", and the latter is even yelling at you.:-DWere you writing this  just to ridicule  me?  I was just trying to ask an honest question.  I would never make a post to make fun of another debian user.  I feel it is against the social contract.  Things like this can give Debian a black eye, won where people feel the developers are just going to make fun of them.

Re: Backports

[Anthony DeRobertis]

Joseph Smidt wrote:

> Were you writing this  just to ridicule  me?

No, not at all. It was just supposed to be a joke.

I appologize; I should have been clearer.


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

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Manoj Srivastava]

On Fri, 20 Jan 2006 11:45:26 -0500, Christopher Martin
<[EMAIL PROTECTED]> said:  

> So let's start again. Let's say that someone tried put forward a new
> amendment in place of the old. This amendment makes clear its
> intention to assert the position of the Debian Project as viewing
> the GFDL, minus invariant sections, to be sufficiently free to meet
> the DFSG and be included in main. Would you accept the amendment?
> Given all my arguments in previous posts, would you require a
> supermajority for the amendment to pass?

If you want to override the delegates decision that works
 licensed under the GFDL are incontrovertibly non-free, that is a
 separate GR.  We'll even fast track it to appear before this
 one. (This falls under determining which issues are the same and fall
 on the same ballot).

manoj
-- 
I love dogs, but I hate Chihuahuas.  A Chihuahua isn't a dog.  It's a
rat with a thyroid problem.
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: new mplayer 1.0pre7try2 package

[Anthony Towns]

On Fri, Jan 20, 2006 at 12:08:39PM -0500, Nathanael Nerode wrote:
> aj@azure.humbug.org.au wrote:
> >mplayer has had an explicit warning from upstream that it's patented;
> The proposed tarball for Debian has stuff excised left and right in
> order to guarantee legality.  Just check that the patented stuff was
> excised, right?

If you can demonstrate that there's nothing in there that's potentially
patented, sure. That seems pretty unlikely, though.

> mplayer should go in if it links to the ffmpeg library in Debian, and its
> own copies of any mp3 and AAC encoding stuff are removed.   Right?

No, we have real problems with video codec stuff in Debian and they need
to be resolved thoroughly, not expediently.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Backports

[Anthony DeRobertis]

Joseph Smidt wrote:

> " I provide these files without any warranty. Use them at your own risk.
> If one of these packages eats your cat or your rabbit, kills your
> neighbour, or burns your fridge, don't bother me. "

Well, perhaps you should read the following, printed whenever you log in
to your Debian machine:

"Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law."

Hey, "without any warranty" is at least a step up from "ABSOLUTELY NO
WARRANTY", and the latter is even yelling at you.

:-D


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

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Anthony DeRobertis]

Christopher Martin wrote:

> Therefore, no modification of the DFSG would be required after the passage 
> of the amendment, since it would have been decided by the developers that 
> there was no inconsistency.

If a simple majority can yell, "there is no inconsistency" then the 3:1
requirement has little meaning. I think it'd be reasonable to request
that people who believe [0] is wrong should produce reasoned arguments
against it; to the best of my knowledge (and memory, of course), no one
has done so.

Without a reasoned argument for why the GFDL w/o Invariant Sections is
free, I don't see how the Secretary can consider the amendment anything
else than an attempt to change a foundation document, and either rule it
out of order or require the supermajority.

[0] http://people.debian.org/~srivasta/Position_Statement.xhtml


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

Re: Implicition declarations of functions and bugs

[Steve Greenland]

On 20-Jan-06, 16:55 (CST), Russ Allbery <[EMAIL PROTECTED]> wrote: 
> Yes, and definitely maintainers should clean this up when they see it
> unless they know it's safe.  On the other hand, *most* of the cases of
> this warning in my experience are harmless because the function returns an
> int.  It's most commonly seen in ancient software that doesn't include all
> of the right headers for functions like getopt().

Right. And in such cases it's trivial to fix, which makes it easier
to browse the build log for real errors. There's really no excuse for
letting these bugs live.

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


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

Re: For those who care about their packages in Ubuntu

[Sven Luther]

On Fri, Jan 20, 2006 at 10:46:51AM -0800, Matt Zimmerman wrote:
> On Fri, Jan 20, 2006 at 07:24:57PM +0100, Sven Luther wrote:
> > On Fri, Jan 20, 2006 at 09:20:33AM -0800, Matt Zimmerman wrote:
> > > 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
> > 
> > The thing is not exactly like that though, what really happens is that you
> > simply rebuild those packages and upload them to universe, without even 
> > asking
> > the debian maintainers, which is exactly the reason for this long thread,
> > since some object to getting bug reports for the ubuntu builds of their
> > packages.
> 
> I've already addressed all of your points repeatedly in this thread.

Huh, what points ? First, sorry but i got lost in the thread somewhere at
about a quarter of its current size, so i may have missed some.

That said, you claim that "Most of the packages in universe are maintained
only by the Debian maintainer", and that is simply a mis-representation, if
not an outhright lie. 

Friendly,

Sven Luther


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

[Sven Luther]

On Fri, Jan 20, 2006 at 10:54:40AM -0800, Matt Zimmerman wrote:
> On Fri, Jan 20, 2006 at 07:35:55PM +0100, Sven Luther wrote:
> > Arg, and to make matters worse, this discussion is CCed to a
> > closed-moderated-list, Matt, this is really not a friendly way to have a
> > conversation.
> 
> I didn't add the CC to ubuntu-motu, nor the one to debian-project.  I've
> merely participated in the discussion and respected Mail-Followup-To.

Oh well, i wonder who added it then. I guess it is a closed list, but they
could at least disable the automatic reply or something.

Friendly,

Sven Luther


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

Re: Implicition declarations of functions and bugs

[Russ Allbery]

Samuel Thibault <[EMAIL PROTECTED]> writes:
> Kurt Roeckx, le Fri 20 Jan 2006 23:56:22 +0100, a écrit :

>> But this really is the maintainer of the package that should look
>> at this.  I don't think it's up to the buildd's maintainers to
>> go and look for this type of bugs.

> Ok, but maintainers don't seem to care so far. Something is needed to
> get their attention on this issue.

It's sometimes a notable divergence from upstream to fix this kind of
thing, so I can understand why maintainers don't fix it if it's not
actually causing problems.

If you identify a case where it causes or is likely to cause problems,
surely that's a regular bug report that maintainers should then deal with
according to its severity.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: Implicition declarations of functions and bugs

[Samuel Thibault]

Kurt Roeckx, le Fri 20 Jan 2006 23:56:22 +0100, a écrit :
> On Fri, Jan 20, 2006 at 11:19:58PM +0100, Samuel Thibault wrote:
> > Samuel Thibault, le Fri 20 Jan 2006 23:15:11 +0100, a écrit :
> > > Maybe the debian policy should require
> > > -Werror-implicit-function-declaration in CFLAGS so as to avoid such
> > > issue?
> > 
> > Or buildds could check for "implicit declaration of function" warnings.
> 
> We could also check for lots of other things in buildd logs.  One
> that happens alot more is "cast to pointer from integer of
> different size" and "cast from pointer to integer of different
> size".

Indeed, though it can be perfectly valid (int casted to void* for
pthread_create(), then casted back to int in the thread, for instance).

> But this really is the maintainer of the package that should look
> at this.  I don't think it's up to the buildd's maintainers to
> go and look for this type of bugs.

Ok, but maintainers don't seem to care so far. Something is needed to
get their attention on this issue.

Regards,
Samuel


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

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

[Matt Zimmerman]

On Fri, Jan 20, 2006 at 02:05:40PM -0500, Joey Hess wrote:
> Matt Zimmerman wrote:
> > On Thu, Jan 19, 2006 at 03:34:58PM -0500, Joey Hess wrote:
> > > If we followed the same method for python-base, then we would
> > > 
> > > a) instroduce python-base iff we had some package(s) written in python
> > >that we wanted in the base system (apt-listchanges comes to mind)
> > > b) include only the modules needed by the package(s).
> > 
> > Please don't do this; it implies that python-minimal would be part of base,
> > but not full python, and this is something that python upstream explicitly
> > objects to.
> 
> It implies no such thing.

If you won't acknowledge that, then know that upstream also object to the
name "python-base" for something which has a stripped-down standard library.

-- 
 - mdz


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

Re: Implicition declarations of functions and bugs

[Russ Allbery]

Samuel Thibault <[EMAIL PROTECTED]> writes:

> In buildd logs, I could find several
> test.c:3: warning: implicit declaration of function 'f'
> warnings

> This can be very problematic on 64bits architectures such as AMD64:

Yes, and definitely maintainers should clean this up when they see it
unless they know it's safe.  On the other hand, *most* of the cases of
this warning in my experience are harmless because the function returns an
int.  It's most commonly seen in ancient software that doesn't include all
of the right headers for functions like getopt().

The problems generally only arise with functions that return pointers.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Implicition declarations of functions and bugs

[Kurt Roeckx]

On Fri, Jan 20, 2006 at 11:19:58PM +0100, Samuel Thibault wrote:
> Samuel Thibault, le Fri 20 Jan 2006 23:15:11 +0100, a écrit :
> > Maybe the debian policy should require
> > -Werror-implicit-function-declaration in CFLAGS so as to avoid such
> > issue?
> 
> Or buildds could check for "implicit declaration of function" warnings.

We could also check for lots of other things in buildd logs.  One
that happens alot more is "cast to pointer from integer of
different size" and "cast from pointer to integer of different
size".  During the past 24 hours I had 300 such warnings, and 94
of "implicit declaration of function".

But this really is the maintainer of the package that should look
at this.  I don't think it's up to the buildd's maintainers to
go and look for this type of bugs.


Kurt


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

[Matthew Palmer]

On Fri, Jan 20, 2006 at 01:40:11PM -0800, Matt Zimmerman wrote:
> On Sat, Jan 21, 2006 at 08:31:44AM +1100, Matthew Palmer wrote:
> > All you'll get is the loud minority having a whinge then, no matter what the
> > outcome.
> 
> It will certainly beat the hell out of continuing this thread.

It will just be this thread all over again.

- Matt


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

Re: Implicition declarations of functions and bugs

[Samuel Thibault]

Samuel Thibault, le Fri 20 Jan 2006 23:15:11 +0100, a écrit :
> Maybe the debian policy should require
> -Werror-implicit-function-declaration in CFLAGS so as to avoid such
> issue?

Or buildds could check for "implicit declaration of function" warnings.

Regards,
Samuel


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

Implicition declarations of functions and bugs

[Samuel Thibault]

Hi,

In buildd logs, I could find several
test.c:3: warning: implicit declaration of function 'f'
warnings

This can be very problematic on 64bits architectures such as AMD64:

test.c:
#include 
int main(void) {
printf("%p\n",f(-1));
return 0;
}

test2.c:
#include 
void *f(long a) {
char c;
printf("%ld %p\n",a,&c);
return &c;
}

result:
4294967295 0x7ffc725f
0xfffc725f

instead of
-1 0x7ffc725f
0x7ffc725f

, which can of course entail a lot of bugs...

Maybe the debian policy should require
-Werror-implicit-function-declaration in CFLAGS so as to avoid such
issue?

Regards,
Samuel


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

[Matt Zimmerman]

On Sat, Jan 21, 2006 at 08:31:44AM +1100, Matthew Palmer wrote:
> All you'll get is the loud minority having a whinge then, no matter what the
> outcome.

It will certainly beat the hell out of continuing this thread.

-- 
 - mdz


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

Re: new mplayer 1.0pre7try2 package

[Ron Johnson]

On Fri, 2006-01-20 at 22:29 +0100, Joerg Jaspert wrote:
> On 10540 March 1977, Christian Marillat wrote:
> 
> >> Right, you've got a list of reasons why it got rejected and half
> >> of that is still true.
> > I still don't see why rte can't enter in main, when ffmpeg is already
> > in main and does the same.
> 
> Two bads doesnt make one good, so we stay with one bad.  Or
> Just because foo killed bar you dont go and kill baz.

Sure it does, if you don't get punished for it.

Other relevant phrases are "precedent" (for all the Progressives
worried that Alito will turn the US into a fascist theocracy) and
"slippery slope" (for Republicans remembering "Sliding Towards
Gomorrah").

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA

"A C program is like a fast dance on a newly waxed dance floor by
people carrying razors."
Waldi Ravens


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

Re: Backports

[Norbert Tretkowski]

* Andreas Schuldei wrote:
> * Norbert Tretkowski <[EMAIL PROTECTED]> [2006-01-19 17:38:45]:
> > * Andreas Schuldei wrote:
> > > i remember a conversation where you pointed out some principal
> > > problems (security support, manpower) but in general were in
> > > favour of the idea and prefered fixing those. what happend?
> > 
> > Manpower is no longer a problem, thanks to Ganneff we're now using
> > dak, which means every Debian developer can upload his packages
> > (but I still need to manually add his gpg key to the backports.org
> > keyring).
> > 
> > A while back, I talked with Joey about the required infrastructure
> > to provide security advisories, but until now I had no time to
> > implement it.
> 
> Then why did you answer "no" above? Things look comparatively peachy
> to me.

Indeed, looks I was a bit overhasty.

Norbert


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

[Matthew Palmer]

On Fri, Jan 20, 2006 at 12:41:49PM -0800, Matt Zimmerman wrote:
> On Sat, Jan 21, 2006 at 07:13:31AM +1100, Matthew Palmer wrote:
> > On Fri, Jan 20, 2006 at 09:20:33AM -0800, Matt Zimmerman wrote:
> > > By way of example, the Debian maintainer is equipped to answer questions
> > > like "why is the package set up this way?", "what are your plans for it?",
> > > etc., while the MOTU team are not.
> > 
> > What the?  By that logic, the upstream author should be in the Maint: field,
> > since they're in the *best* position to answer those questions for the
> > majority content of the package.  At any rate, in most cases the answer,
> > from the Debian maintainer, to the first question would either be "Dunno,
> > can't remember" or "the previous maintainer was a known crack addict", while
> > the answer to the second would be " make sure it doesn't break, I
> > suppose" -- none of whick are particularly more interesting answers than
> > what you'd get from the MOTUs.
> 
> If I were to accept your declaration that the Debian maintainer is equally
> ill-equipped to discuss the package, then it follows that they are an
> equally valid value for the Maintainer field.

It only follows if your definition of maintainer is "can answer all
development questions".  If you're going to go that way, you may as well put
the man in the moon as the maintainer of your packages, as he's got as much
chance, in the general case, of answering those questions.  Thus, I'd say
that your definition of "Maintainer" is bollocks.

> There really isn't any point in arguing our individual views, though.  What
> I'm interested in is what will satisfy a majority of Debian developers, and
> the proposed poll seems like the closest we'll get to that.

All you'll get is the loud minority having a whinge then, no matter what the
outcome.

- Matt


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

Re: new mplayer 1.0pre7try2 package

[Joerg Jaspert]

On 10540 March 1977, Christian Marillat wrote:

>> Right, you've got a list of reasons why it got rejected and half
>> of that is still true.
> I still don't see why rte can't enter in main, when ffmpeg is already
> in main and does the same.

Two bads doesnt make one good, so we stay with one bad.  Or
Just because foo killed bar you dont go and kill baz.

-- 
bye Joerg
<[EMAIL PROTECTED]>
Windows ME? Mit 13? Kann der nicht lieber Drogen nehmen wie andere Kinder
in dem Alter?


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

Re: klik, loop mounts, and insecurity [was: statement from one of the klik project members]

[Don Armstrong]

On Fri, 20 Jan 2006, Sam Morris wrote:
> AFAIK Linux only supports eight loopback mounts at a time. This
> won't be a problem once FUSE becomes more widespread.

The default is 8; by seting the max_loop kernel option, you can
increase this to 256.


Don Armstrong

-- 
"You have many years to live--do things you will be proud to remember
when you are old."
 -- Shinka proverb. (John Brunner _Stand On Zanzibar p413)

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


signature.asc
Description: Digital signature

Re: For those who care about their packages in Ubuntu

[Matt Zimmerman]

On Sat, Jan 21, 2006 at 07:13:31AM +1100, Matthew Palmer wrote:
> On Fri, Jan 20, 2006 at 09:20:33AM -0800, Matt Zimmerman wrote:
> > On Fri, Jan 20, 2006 at 07:08:38PM +1100, Matthew Palmer wrote:
> > > I keep hearing this, but I really don't believe it.  In Debian, 
> > > "Maintainer"
> > > means "An individual or group of people primarily responsible for the
> > > on-going well being of a package".  As I understand it, in Ubuntu, the 
> > > MOTUs
> > > have responsibility for all of the packages in Universe.
> > 
> > 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.
> 
> But if a problem in a package in Ubuntu universe does appear, whose
> responsibility[1][2] is it to fix it?  Whatever the answer to that question,
> also answers the question "what should go in the Maintainer: field?".

And unsurprisingly, it, too, doesn't have a straightforward answer.  If a
user reports such a bug to Ubuntu, it is approximately the domain of the
MOTU team, in that they triage those bugs (on a time-available prioritized
basis, across the entire set of packages).  However, this is not the same
thing as saying "the maintainer of this package is the MOTU team",
especially not in the same sense as "[EMAIL PROTECTED] is the maintainer of
libapache2-mod-auth-mysql".

> > By way of example, the Debian maintainer is equipped to answer questions
> > like "why is the package set up this way?", "what are your plans for it?",
> > etc., while the MOTU team are not.
> 
> What the?  By that logic, the upstream author should be in the Maint: field,
> since they're in the *best* position to answer those questions for the
> majority content of the package.  At any rate, in most cases the answer,
> from the Debian maintainer, to the first question would either be "Dunno,
> can't remember" or "the previous maintainer was a known crack addict", while
> the answer to the second would be " make sure it doesn't break, I
> suppose" -- none of whick are particularly more interesting answers than
> what you'd get from the MOTUs.

If I were to accept your declaration that the Debian maintainer is equally
ill-equipped to discuss the package, then it follows that they are an
equally valid value for the Maintainer field.

There really isn't any point in arguing our individual views, though.  What
I'm interested in is what will satisfy a majority of Debian developers, and
the proposed poll seems like the closest we'll get to that.

-- 
 - mdz


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

Re: klik, loop mounts, and insecurity [was: statement from one of the klik project members]

[Joey Hess]

Sam Morris wrote:
> If suidperl does not ensure that the scripts it interprets have the suid 
> bit set, then shouldn't a critical bug be filed?

The nosuid mount option does not cause the suid bit to be unset, it
causes the kernel to not honor it when executing binaries. This doesn't
work for programs like suidperl that deal with suid bits on their own.

With that said, suidperl has been modified since that man page was
written to detect nosuid filesystems on its own:

[EMAIL PROTECTED]:/tmp>./foo.pl  
Setuid script "./foo.pl" on nosuid filesystem.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Re: klik, loop mounts, and insecurity [was: statement from one of the klik project members]

[Kurt Pfeifle]

> > Please try "man mount". If your manpage is similar to mine, it will
> > contain something like:
> >
> >  snip --
> > OPTIONS
> >user   Allow an ordinary user to mount the file system.  The name
> >   of the mounting user is written to mtab so that he can un-
> >   mount the file system again.   This option implies the op-
> >   tions noexec, nosuid, and nodev (unless overridden by sub-
> >   sequent options, as in the option line user,exec,dev,suid).
> >  snap --
> >
> > Note the part mentioning "nosuid" - and compare it to the fstab line
> > used by klik.   :-)
>
> You might want to read your manpage a bit more:
>
>nosuid   Do not allow set-user-identifier or set-group-identifier
> bits to take effect. (This seems safe, but is in fact
> rather unsafe if you have suidperl(1) installed.)
>
> Particularly note the parenthetical sentence.

I do.

But if I have suidperl(1) installed on my (multiuser) system, then I have
bigger fish to fry than just the klik ones anyway. Then practically every 
script can be tricked into setuid execution of all criminal commands you
want.

So... you are right here.

> On another point, I believe you said earlier that the admin is required to
> add 7 of those lines to fstab before klik could be used. 

Yes. ("root privileges" -- meaning a sudoer user can also install the klik
client and modify the fstab).

> Does that mean 
> that no more than 7 applications can be installed, or that no more than 7
> users can use klik on the one machine? 

It means that no more than 7 klik .cmg apps can be used concurrently by
the default klik client installations. No more than 7 concurrent loop
mounts by mortal users.

Actually, the kernel limit is 8. But klik leaves generously one over for
other uses (such as Knoppix)  ;-)

> Either way, it seems quite 
> artificially limiting. 

Yes.

I said so in an earlier posting:

   We know this is ugly (and a big limitation) -- but
   once Kernel 2.6.14 with FUSE will become more widespread, 
   this will no longer be required.

It is just the way that loopmounting is limited. You can tune it up to 32
concurrent mount points, by editing the config file and using the appropriate
kernel parameter for booting.

> If I have an 8th user who wants to use klik, what 
> do I do?

Whatever you prefer:   :-)  
 * kick off one user
 * reboot with a tuned setting
 * install a 2.6.14 Kernel with FUSE support (and install the
   experimental modifications to klik to make use of it).

(well, the 8th is still easy. The problem starts with the 9th, or the 33th...)

> - Matt

Cheers,
Kurt


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

Bug#349064: ITP: flash-plugin -- installer for Macromedia Flash Plugin

[Bart Martens]

Package: wnpp
Severity: wishlist
Owner: Bart Martens <[EMAIL PROTECTED]>

* Package name: flash-plugin
  Version : 7.0.61.1
  Upstream Author : Bart Martens <[EMAIL PROTECTED]>
* URL : http://members.chello.be/ws35943/flash-plugin/
* License : GPL
  Description : installer for Macromedia Flash Plugin

This package downloads the Macromedia Flash plugin and installs it.
The plugin itself is not in this package.

Homepage of the plugin itself: http://macromedia.mplug.org/

The Debian package flash-plugin is meant as an alternative or as a
replacement for flashplugin-nonfree.

Similarities: Both Debian packages are GPL, and download the .tar.gz
from the Macromedia website to comply to the Macromedia license.

Some differences:
- less bugs :-)
- simple scripting in preinst and postinst, no ruby
- uses wget, so simple proxy support
- versions are linked (MD5), thus support downgrade of the plugin
- asks to accept the Macromedia license before downloading the plugin
- no support (yet) for installing a manually downloaded file

Regards,

Bart Martens


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

[Matthew Palmer]

On Fri, Jan 20, 2006 at 09:20:33AM -0800, Matt Zimmerman wrote:
> On Fri, Jan 20, 2006 at 07:08:38PM +1100, Matthew Palmer wrote:
> > I keep hearing this, but I really don't believe it.  In Debian, "Maintainer"
> > means "An individual or group of people primarily responsible for the
> > on-going well being of a package".  As I understand it, in Ubuntu, the MOTUs
> > have responsibility for all of the packages in Universe.
> 
> 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.

But if a problem in a package in Ubuntu universe does appear, whose
responsibility[1][2] is it to fix it?  Whatever the answer to that question,
also answers the question "what should go in the Maintainer: field?".

> By way of example, the Debian maintainer is equipped to answer questions
> like "why is the package set up this way?", "what are your plans for it?",
> etc., while the MOTU team are not.

What the?  By that logic, the upstream author should be in the Maint: field,
since they're in the *best* position to answer those questions for the
majority content of the package.  At any rate, in most cases the answer,
from the Debian maintainer, to the first question would either be "Dunno,
can't remember" or "the previous maintainer was a known crack addict", while
the answer to the second would be " make sure it doesn't break, I
suppose" -- none of whick are particularly more interesting answers than
what you'd get from the MOTUs.

- Matt

[1] Subject to the usual "we're all volunteers, yada yada" proviso.

[2] Remember also that with responsibility should come authority, so the
Debian maintainer is usually an immediate non-candidate in Ubuntu.

Re: klik, loop mounts, and insecurity [was: statement from one of the klik project members]

[Sam Morris]

Matthew Palmer wrote:

The klik client installation needs root privileges once, to add 7 lines
like this one to /etc/fstab:

 /tmp/app/1/image /tmp/app/1 cramfs,iso9660 user,noauto,ro,loop,exec 0
0


Doesn't this introduce a local root exploit?  A user can easily write
their own /tmp/app/1/image file which contains, say, a setuid root bash
executable.


Yes, that's exactly what I was afraid of, myself.


Please try "man mount". If your manpage is similar to mine, it will 
contain something like:


 snip --
OPTIONS
  user   Allow an ordinary user to mount the file system.  The name 
 of the mounting user is written to mtab so that he can un-

 mount the file system again.   This option implies the op-
 tions noexec, nosuid, and nodev (unless overridden by sub-
 sequent options, as in the option line user,exec,dev,suid).
 snap --

Note the part mentioning "nosuid" - and compare it to the fstab line 
used by klik.   :-)


You might want to read your manpage a bit more:

   nosuid   Do not allow set-user-identifier or set-group-identifier
bits to take effect. (This seems safe, but is in fact
rather unsafe if you have suidperl(1) installed.)
 
Particularly note the parenthetical sentence.


If suidperl does not ensure that the scripts it interprets have the suid 
bit set, then shouldn't a critical bug be filed?



On another point, I believe you said earlier that the admin is required to
add 7 of those lines to fstab before klik could be used.  Does that mean
that no more than 7 applications can be installed, or that no more than 7
users can use klik on the one machine?  Either way, it seems quite
artificially limiting.  If I have an 8th user who wants to use klik, what do
I do?


Write to lkml. ;) AFAIK Linux only supports eight loopback mounts at a 
time. This won't be a problem once FUSE becomes more widespread.



- Matt


--
Sam Morris
http://robots.org.uk/

PGP key id 5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


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

Re: sarcastic

[Ambrose Al]

 
 
 
dread When I explained my altered position to you, sir, I began again,
pus uncomfortable state, and with a warm shooting all over me, as if my
marquis You are very much to blame, sir, said Mr. Spenlow, walking to and
involuntary saying that perhaps I should consult his feelings best by
beetle mastered the alphabet, which was an Egyptian Temple in itself,
nightingale me that crowning service.  Miss Mills accepted this trust, too; but
peril was not quite right in that direction; but he soon relieved my
anon After perusing it, I taxed Miss Spenlow with having many such
pious those letters, and throw them in the fire.  Give me Miss Spenlows
conservancy and busily keeping red-hot all the irons I now had in the fire, I
rewarding consequences, that he became uncomfortable in his mind sometimes.
ask Well.  I loved her, and I went on loving her, most absorbingly,
unfold my waking hours, but reappeared before me in my sleep.  When I had
settled something, tending to the annihilation of the British constitution,
platoon I found that they had driven everything else out of it; then,
restructure off dancing, La ra la, La ra la, until I felt a much greater
predominantly Miss Spenlow, if you please, said her father, majestically.
somebody them.  I was always punctual at the office; at the Doctors too:
mayhem Parliamentary career, and was made responsible for such awful
airs a navigator, and went balancing myself up and down a plank all day

Re: klik, loop mounts, and insecurity [was: statement from one of the klik project members]

[Matthew Palmer]

On Fri, Jan 20, 2006 at 03:59:23PM +, Kurt Pfeifle wrote:
> Wouter Verhelst wrote on debian-devel@lists.debian.org:
> > [Re-adding Cc to Kurt, as he's mentioned he isn't subscribed]
> >
> > On Fri, Jan 20, 2006 at 01:20:26PM +0800, Cameron Patrick wrote:
> > > Kurt Pfeifle wrote:
> > > > The klik client installation needs root privileges once, to add 7 lines
> > > > like this one to /etc/fstab:
> > > >
> > > >   /tmp/app/1/image /tmp/app/1 cramfs,iso9660 user,noauto,ro,loop,exec 0
> > > > 0
> > >
> > > Doesn't this introduce a local root exploit?  A user can easily write
> > > their own /tmp/app/1/image file which contains, say, a setuid root bash
> > > executable.
> >
> > Yes, that's exactly what I was afraid of, myself.
> 
> Please try "man mount". If your manpage is similar to mine, it will 
> contain something like:
> 
>  snip --
> OPTIONS
>user   Allow an ordinary user to mount the file system.  The name 
>   of the mounting user is written to mtab so that he can un-
>   mount the file system again.   This option implies the op-
>   tions noexec, nosuid, and nodev (unless overridden by sub-
>   sequent options, as in the option line user,exec,dev,suid).
>  snap --
> 
> Note the part mentioning "nosuid" - and compare it to the fstab line 
> used by klik.   :-)

You might want to read your manpage a bit more:

   nosuid   Do not allow set-user-identifier or set-group-identifier
bits to take effect. (This seems safe, but is in fact
rather unsafe if you have suidperl(1) installed.)
 
Particularly note the parenthetical sentence.

On another point, I believe you said earlier that the admin is required to
add 7 of those lines to fstab before klik could be used.  Does that mean
that no more than 7 applications can be installed, or that no more than 7
users can use klik on the one machine?  Either way, it seems quite
artificially limiting.  If I have an 8th user who wants to use klik, what do
I do?

- Matt

Re: For those who care about their packages in Ubuntu

[Matt Zimmerman]

On Fri, Jan 20, 2006 at 07:35:55PM +0100, Sven Luther wrote:
> Arg, and to make matters worse, this discussion is CCed to a
> closed-moderated-list, Matt, this is really not a friendly way to have a
> conversation.

I didn't add the CC to ubuntu-motu, nor the one to debian-project.  I've
merely participated in the discussion and respected Mail-Followup-To.

I won't even start to discuss which end of the "friendly" stick I've been on
so far.

-- 
 - mdz


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

[Sven Luther]

On Fri, Jan 20, 2006 at 07:24:57PM +0100, Sven Luther wrote:
> On Fri, Jan 20, 2006 at 09:20:33AM -0800, Matt Zimmerman wrote:
> > On Fri, Jan 20, 2006 at 07:08:38PM +1100, Matthew Palmer wrote:
> > > I keep hearing this, but I really don't believe it.  In Debian, 
> > > "Maintainer"
> > > means "An individual or group of people primarily responsible for the
> > > on-going well being of a package".  As I understand it, in Ubuntu, the 
> > > MOTUs
> > > have responsibility for all of the packages in Universe.
> > 
> > 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
> 
> The thing is not exactly like that though, what really happens is that you
> simply rebuild those packages and upload them to universe, without even asking
> the debian maintainers, which is exactly the reason for this long thread,
> since some object to getting bug reports for the ubuntu builds of their
> packages.

Arg, and to make matters worse, this discussion is CCed to a
closed-moderated-list, Matt, this is really not a friendly way to have a
conversation.

Friendly,

Sven Luther


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

[Matt Zimmerman]

On Fri, Jan 20, 2006 at 07:24:57PM +0100, Sven Luther wrote:
> On Fri, Jan 20, 2006 at 09:20:33AM -0800, Matt Zimmerman wrote:
> > 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
> 
> The thing is not exactly like that though, what really happens is that you
> simply rebuild those packages and upload them to universe, without even asking
> the debian maintainers, which is exactly the reason for this long thread,
> since some object to getting bug reports for the ubuntu builds of their
> packages.

I've already addressed all of your points repeatedly in this thread.

-- 
 - mdz


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

Bug#349055: ITP: python-imdbpy -- Python package to access the IMDb's movie database

[Ana Guerrero]

Package: wnpp
Severity: wishlist
Owner: Ana Guerrero <[EMAIL PROTECTED]>


* Package name: python-imdbpy
  Version : 2.3
  Upstream Author : Davide Alberani 
* URL : http://imdbpy.sourceforge.net
* License : GPL
  Description : Python package to access the IMDb's movie database 

IMDbPY is a Python package useful to retrieve and manage the data of 
the IMDb movie database about both movies and people.
It can be very easily used by programmers and developers to provide 
access to the IMDb's data to their programs. 
.
Homepage: http://imdbpy.sourceforge.net


-
I don't plan package this until March, so if you're very interested, please,
mail me and maybe we can co-maintain, or you can package it instead of me. 


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

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

[Joey Hess]

Kevin Mark wrote:
> Giving away code (GPL or otherwise) to the world is done for many
> reasons.  Aparently some folks are more concerned about how their work
> is used. As with the attribution in .debs, folks want the users to not
> associate possible (as judged by them) 'bad'/'unofficial'/'off
> project'/'different' work with their projects. But the perl folks don't
> seem to have that objection! x-) (at least none have spoken yet!)

perl is priority standard and so it is part of default Debian installs
unless the user explcitly asks aptitude not to install it.

-- 
see shy jo


signature.asc
Description: Digital signature

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

[Joey Hess]

Matt Zimmerman wrote:
> On Thu, Jan 19, 2006 at 03:34:58PM -0500, Joey Hess wrote:
> > If we followed the same method for python-base, then we would
> > 
> > a) instroduce python-base iff we had some package(s) written in python
> >that we wanted in the base system (apt-listchanges comes to mind)
> > b) include only the modules needed by the package(s).
> 
> Please don't do this; it implies that python-minimal would be part of base,
> but not full python, and this is something that python upstream explicitly
> objects to.

It implies no such thing.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: statement from one of the klik project members [was: The klik project and Debian]

[Bernhard R. Link]

* Peter Palfrader <[EMAIL PROTECTED]> [060120 13:31]:
> user implies noexec, nosuid, and nodev unless overridden by subsequent
> options according to the mount(8) manpage.

Please always keep in mind that this only reduces the chance, but still
keeps the possibility for holes open. (Like noexec could be circumvented
by calling ld.so directly, nosuid by perl-suid and so on, and there might
always be some other program sleeping somewhere waiting for its chance)

Hochachtungsvoll,
  Bernhard R. Link


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

[Sven Luther]

On Fri, Jan 20, 2006 at 09:20:33AM -0800, Matt Zimmerman wrote:
> On Fri, Jan 20, 2006 at 07:08:38PM +1100, Matthew Palmer wrote:
> > I keep hearing this, but I really don't believe it.  In Debian, "Maintainer"
> > means "An individual or group of people primarily responsible for the
> > on-going well being of a package".  As I understand it, in Ubuntu, the MOTUs
> > have responsibility for all of the packages in Universe.
> 
> 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

The thing is not exactly like that though, what really happens is that you
simply rebuild those packages and upload them to universe, without even asking
the debian maintainers, which is exactly the reason for this long thread,
since some object to getting bug reports for the ubuntu builds of their
packages.

I believe that altough in most case there is not much difference there may be
subtle differences between the ubuntu environment and the debian one, which
makes the handlign of bug reports non-evident. Also a pure debian maintainer
will have some trouble checking and testing any possible fix, not having a
ubuntu install done.

Friendly,

Sven Luther


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

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

[Frank Küster]

Thomas Hood <[EMAIL PROTECTED]> wrote:

> /usr/lib/python2.4/interpreter.  Packages that currently Depend on
> python but use only minimal functionality could Depend on python-minimal
> but they would have to run python using /usr/lib/python/interpreter.
> The stripped down python interpreter would be "hidden" from command-line
> users but would still be available for use by packaged programs.

That sounds good, but wouldn't it be even better to have a symlink
/usr/bin/debpython-minimal or so, pointing to the interpreter?  Then one
could still replace the interpreter by something else (by putting it
into /usr/local/bin), for example in order to debug a particularly weird
problem in a config script?


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

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

[Steve Langasek]

On Fri, Jan 20, 2006 at 09:52:09AM -0800, Matt Zimmerman wrote:
> On Fri, Jan 20, 2006 at 09:40:55AM -0800, Steve Langasek wrote:
> > I asked this question earlier, and no one answered.  Are there .config
> > scripts being written in python today in Ubuntu?  (Hmm, where are the python
> > bindings for debconf, and what ensures that they're installed?)

> No, not yet.  The promotion to Essential needed to happen prior to writing
> any such scripts.

Well, technically a .config script that fails because /usr/bin/python
doesn't exist would get a second chance when the postinst runs, just like
any other config script failure... so you could get away with this just
using a Depends:, you just lose pre-configuration support ;)

> The python bindings for debconf are, of all places, in the 'debconf'
> package.

Hurray! :)

-- 
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: when and why did python(-minimal) become essential?

[Bernhard R. Link]

* Andreas Schuldei <[EMAIL PROTECTED]> [060119 13:15]:
> you are able to do init.d scripts, pre- and postinsts etc in
> python. That is a "ease of development" helper for ubuntu.
> 
> how agressive does debian use it's perl in this regard? i think
> hardly at all.

Well, set a locale you did not (yet) generate and run some larger
install, you will see those half-page warning of perl about this
running over the screen. (But before trying this make sure no
sharp things are on the way to the next exit, as you might want
to run that route in screaming panic while trying this experiment).

Hochachtungsvoll,
  Bernhard R. Link


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

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

[Simon Richter]

Hello,

Loïc Minier wrote:


 Rationale: you don't want to see konqueror launched as the default
 browser in GNOME but you want GNOME to be integrated with Debian.


Ah, I remember that one as well.


 It is simple to extend this scheme with:
 - gnome-www-browser for browsers with GNOME support (epiphany-browser,
   galeon, firefox-gnome-support, ...)


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



 - check for $DISPLAY and eg. $GNOME_DESKTOP_SESSION_ID in
   sensible-browser to decide to launch gnome-www-browser or default to
   x-www-browser


Sounds good.


 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?


 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.



 Simon, would this help with the problem you mentionned?


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.


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.


   Simon



signature.asc
Description: OpenPGP digital signature

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

[Matt Zimmerman]

On Fri, Jan 20, 2006 at 09:40:55AM -0800, Steve Langasek wrote:
> I asked this question earlier, and no one answered.  Are there .config
> scripts being written in python today in Ubuntu?  (Hmm, where are the python
> bindings for debconf, and what ensures that they're installed?)

No, not yet.  The promotion to Essential needed to happen prior to writing
any such scripts.

The python bindings for debconf are, of all places, in the 'debconf'
package.

-- 
 - mdz


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

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

[Steve Langasek]

On Fri, Jan 20, 2006 at 09:22:53AM -0800, Matt Zimmerman wrote:
> On Thu, Jan 19, 2006 at 10:38:08PM -0800, Thomas Bushnell BSG wrote:
> > Ok, but now I'm confused: why is python-minimal needed in Essential?
> > Why not simply depend on it straightforwardly?

> Because there are parts of the packaging system where there is no way to
> express such a dependency relationship, and so only Essential packages can
> be relied upon to be available.

> One example is .config maintainer scripts, some of which are quite complex
> and worth writing in a higher-level language than shell.

I asked this question earlier, and no one answered.  Are there .config
scripts being written in python today in Ubuntu?  (Hmm, where are the python
bindings for debconf, and what ensures that they're installed?)

-- 
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: Derived distributions and the Maintainer: field

[Matt Zimmerman]

On Fri, Jan 20, 2006 at 12:12:39PM -0500, Nathanael Nerode wrote:
> Henning Makholm <[EMAIL PROTECTED]> wrote:
> >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
> 
> Good point.  If Ubuntu wishes to keep the Maintainer field the same,  but
> use NMU version numbers and add a "Changed-By:" field which is different, that
> seems perfectly reasonable as well.

There is no Changed-By: field in source or binary packages which are NMUd in
Debian, and Ubuntu *does* use something quite similar (though not identical)
to NMU version numbers.  An Ubuntu-specific upload of foo 1.0-1 is versioned
1.0-1ubuntu1.

-- 
 - mdz


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

[Matt Zimmerman]

On Fri, Jan 20, 2006 at 07:08:38PM +1100, Matthew Palmer wrote:
> I keep hearing this, but I really don't believe it.  In Debian, "Maintainer"
> means "An individual or group of people primarily responsible for the
> on-going well being of a package".  As I understand it, in Ubuntu, the MOTUs
> have responsibility for all of the packages in Universe.

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.

By way of example, the Debian maintainer is equipped to answer questions
like "why is the package set up this way?", "what are your plans for it?",
etc., while the MOTU team are not.

-- 
 - mdz


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

Re: Derived distributions and the Maintainer: field

[Nathanael Nerode]

Henning Makholm <[EMAIL PROTECTED]> wrote:
>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

Good point.  If Ubuntu wishes to keep the Maintainer field the same,  but
use NMU version numbers and add a "Changed-By:" field which is different, that
seems perfectly reasonable as well.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Read it and weep.
http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html


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

Re: new mplayer 1.0pre7try2 package

[Nathanael Nerode]

aj@azure.humbug.org.au wrote:
>mplayer has had an explicit warning from upstream that it's patented;
The proposed tarball for Debian has stuff excised left and right in
order to guarantee legality.  Just check that the patented stuff was
excised, right?

Alternatively, I would be quite happy with the response "We just can't
trust mplayer's upstream enough to include mplayer; we suspect them of
having done something underhanded and including illegal code we haven't
spotted."

>ffmpeg
>has an explicit document in its packaging indiciating it's okay.

A, the "I stripped the patented parts" comment in 
README.Debian.

All right.  Sorry!

So, we have a solid summary, which could be a FAQ answer:

mplayer should go in if it links to the ffmpeg library in Debian, and its
own copies of any mp3 and AAC encoding stuff are removed.   Right?

Likewise xvidcap, I presume?

And rte, as was already stated?  (And sorry for not giving credit to Joerg
there!)

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

"(Instead, we front-load the flamewars and grudges in
the interest of efficiency.)" --Steve Lanagasek,
http://lists.debian.org/debian-devel/2005/09/msg01056.html


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

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

[Matt Zimmerman]

On Fri, Jan 20, 2006 at 10:32:06AM +0100, Thomas Hood wrote:
> I'll assume that python2.4-minimal Recommending: python2.4 won't be
> enough.

I'd imagine not.

> How about this?  The current python2.4-minimal package contains
> /usr/bin/python2.4.  We would move this to /usr/lib/python2.4/interpreter
> so that it is no longer present on the standard search path.  The full
> python2.4 package would contain a symlink /usr/bin/python2.4 ->
> /usr/lib/python2.4/interpreter to make the interpreter available on the
> path.  python-minimal Depends on python2.4-minimal and contains the
> symlink /usr/bin/python -> /usr/bin/python2.4.  In addition it would
> contain the symlink /usr/lib/python/interpreter ->
> /usr/lib/python2.4/interpreter.  Packages that currently Depend on
> python but use only minimal functionality could Depend on python-minimal
> but they would have to run python using /usr/lib/python/interpreter.
> The stripped down python interpreter would be "hidden" from command-line
> users but would still be available for use by packaged programs.

It seems a bit obscure to me, but honestly, I can't speak for upstream on
this point, only the ones that I specifically discussed with them.

-- 
 - mdz


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

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

[Matt Zimmerman]

On Thu, Jan 19, 2006 at 10:38:08PM -0800, Thomas Bushnell BSG wrote:
> Ok, but now I'm confused: why is python-minimal needed in Essential?
> Why not simply depend on it straightforwardly?

Because there are parts of the packaging system where there is no way to
express such a dependency relationship, and so only Essential packages can
be relied upon to be available.

One example is .config maintainer scripts, some of which are quite complex
and worth writing in a higher-level language than shell.

-- 
 - mdz


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

Re: new mplayer 1.0pre7try2 package

[Christian Marillat]

Joerg Jaspert <[EMAIL PROTECTED]> writes:

> On 10540 March 1977, Christian Marillat wrote:
>
>>> Contrast rte, where the ftpmasters told Marillat exactly what he needed to 
>>> remove to get the package in Debian, and he didn't do it, and declared that 
>>> he would keep uploading it.  Leaving *that* in limbo is totally reasonable.
>> I've *never* received any e-mail saying that.
>
> Right, you've got a list of reasons why it got rejected and half
> of that is still true.

I still don't see why rte can't enter in main, when ffmpeg is already
in main and does the same.

For the record rte is an mpeg encoder. Now from the ffmpeg package
0.cvs20050918-5.1 I see :

,
| $ ffmpeg -formats | grep -i mpeg
| ffmpeg version CVS, build 3276800, Copyright (c) 2000-2004 Fabrice Bellard
|   configuration:  --build i486-linux-gnu --enable-gpl --enable-pp 
--enable-zlib --enable-vorbis --enable-libogg --enable-theora --enable-a52 
--enable-dts --enable-dc1394 --enable-libgsm --disable-debug --prefix=/usr 
|   built on Jan 17 2006 23:46:35, gcc: 4.0.3 20060115 (prerelease) (Debian 
4.0.2-7)
|   E dvd MPEG2 PS format (DVD VOB)
|  DE m4v raw MPEG4 video format
|  D  mov,mp4,m4a,3gp,3g2 QuickTime/MPEG4 format
|   E mp2 MPEG audio layer 2
|  D  mp3 MPEG audio
|  DE mpegMPEG1 System format
|   E mpeg1video  MPEG video
|   E mpeg2video  MPEG2 video
|  DE mpegts  MPEG2 transport stream format
|  D  mpegvideo   MPEG video
|   E svcdMPEG2 PS format (VOB)
|   E vcd MPEG1 System format (VCD)
|   E vob MPEG2 PS format (VOB)
|  DE yuv4mpegpipeYUV4MPEG pipe format
|  DEVSDT mpeg1video
|  DEVSDT mpeg2video
|  DEVSDT mpeg4
|  D VSDT mpegvideo
|  DEVSD  msmpeg4
|  DEVSD  msmpeg4v1
|  DEVSD  msmpeg4v2
`

D is for Decoding and E is for Encoding, so ffmpeg can encode in
mpeg1video and mpeg2video.

Christian


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

Re: new mplayer 1.0pre7try2 package

[Nathanael Nerode]

I wrote:
>> Contrast rte, where the ftpmasters told Marillat exactly what he needed to 
>> remove to get the package in Debian, and he didn't do it, and declared that 
>> he would keep uploading it.  Leaving *that* in limbo is totally reasonable.

Christian Marillat wrote:
>I've *never* received any e-mail saying that.

Perhaps I have misinterpreted the following message from the bug
trail to bug 112699:

>From: Joerg Jaspert <[EMAIL PROTECTED]>
>To: Christian Marillat <[EMAIL PROTECTED]>
>Cc: Joerg Jaspert <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>Subject: Re: rte_0.4-0.0_i386.changes REJECTED
>Date: Sat, 19 Mar 2005 14:32:55 +0100
>
>On 10233 March 1977, Christian Marillat wrote:
>
>>> Yes, this is the reject of the rte package which was in NEW until now.
>>> Reasons:
>>> - It is an encoding thing, which encodes to formats which are patented, and
>>>   the patent holder are actually enforcing their patents. Found some
>>>   hits for this  with a little question to google.
>> Are you serious ? We have ffmpeg (and soon mencoder in the mplayer
>> package)in Debian who does exactly what rte does and rte can't enter
>> Debian ? ffmpeg should be removed then.
>
>Yes, ffmpeg encoding stuff shouldnt be there, and no, mplayer wont get
>in with mencoder included. I already talked with upstream about it, he
>will talk with Debian maintainer to exclude this thing, before we take a
>closer look at it.

>>> If this reasons are no longer true in the future feel free to
>>>  re-upload it, but for now it is out.
>> Done. I've uploaded 0.5.6-1
>
>As written above: ENCODING is still an issue and therefore at least one
>reason is still true. So dont hope too much it will get through.
>
>-- 
>bye Joerg
>Die d??mmsten H??hne haben die dicksten Eier.

I read this as "remove MPEG encoding and it will go in."  Don't you?

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Read it and weep.
http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html


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

Re: Derived distributions and the Maintainer: field

[Henning Makholm]

Scripsit Nathanael Nerode <[EMAIL PROTECTED]>

> If they are also compiled with a toolchain unchanged from Debian,
> the binaries can legitimately have the same Maintainer: field as in
> Debian, because they are essentially the same package.

> If not, the binary packages should have different Maintainer:
> fields, unless the maintainer agrees to have his name on it.

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.

-- 
Henning Makholm "That's okay. I'm hoping to convince the
  millions of open-minded people like Hrunkner Unnerby."


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

Re: new mplayer 1.0pre7try2 package

[Joerg Jaspert]

On 10540 March 1977, Christian Marillat wrote:

>> Contrast rte, where the ftpmasters told Marillat exactly what he needed to 
>> remove to get the package in Debian, and he didn't do it, and declared that 
>> he would keep uploading it.  Leaving *that* in limbo is totally reasonable.
> I've *never* received any e-mail saying that.

Right, you've got a list of reasons why it got rejected and half
of that is still true.

-- 
bye Joerg
 I'm kinky and perverse, but my illness is laziness


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

Re: KD-Tree library

[Jacob Bensabat]

Hi
Do you know about an implementation of libkdtree 
that works with MS visual C++ (6.0 or 7.*) ?
 
thanks
 
Jacob Bensabat, Ph.D.EWRE Ltd.PO Box 
6770, Haifa 31067, IsraelTel: 972-4-838-3919Mobile: 
972-54-441-7511Fax: 972-4-838-7621

Re: Understanding the GFDL GR proposal and amendment

[Manoj Srivastava]

Hi,

I would like to throw my hat in the ring to try to clarify to
 y'all what I believe the GR and amendments are doing, and which may
 explain why the ballot is shaping up the way it is -- and that
 involves the release tea decision that the GFDL is non-free.

I am currently reconsidering the 3:1 requirement for the
 amendment, and also am considering splitting the amendment off into a
 separate GR, since the issues may be only superficially related.


For example, follow the URL in [1], you can see that a number
 of bugs have been declared serious RC bugs. Then, the messages to
 debian-devel-announce@lists.debian.org referred to in [1] and [2] are
 messages frmo the release team before ([1]) and after ([2]) the
 release of sarge laying out their position unequivocally.

,[ The release team states: ]
|   * Debian says GFDL is non-DFSG-free
|   * GFDL material will not be included in main
`


I posit the GR is a position statement explaining Debian's
 stance. 

,[ Anthony's proposal states: ]
|   * The problems with GFDL are "Invariant Sections", "Transparent
| Copies" and "Digital Rights Management"
|   * FSF could make a new version of the license DFSG-free but hasn't
| done so despite four years of negotiation
`


I also think Adeodato's amendment  is actually conflating a 
 position statement and an overturning of the rm team decision. 

,[ Adeodato's amendment states: ]
|   * Override the RM team, and Debian state that  says GFDL is
| non-DFSG-free only in some modes of use 
|   * GFDL material in these modes of use will not be included in main
|   * The problems with GFDL are "The DRM Restriction", "Transparent
| and Opaque Copies" and "Invariant Sections"
|   * Only the "Invariant Sections" problem makes the GFDL
| non-free
|   * The other problems make GFDL incompatible with some other
| licenses, but does not make material with no "Invariant
| Sections" non-free -- thus Debian continues to include it
| in main 
`

manoj

[1]
http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]:gfdl

[2]
Subject: Bits (Nybbles?) from the Vancouver release team meeting
Message-ID: <[EMAIL PROTECTED]>
Date: Sun, 13 Mar 2005 20:45:09 -0800

[3]
Subject: Removing non-free documentation from main
Message-ID: <[EMAIL PROTECTED]>
Date: Wed, 14 Sep 2005 02:36:11 +0200


-- 
Conquering Russia should be done steppe by steppe.
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: KD-Tree library

[martin f krafft]

also sprach Jacob Bensabat <[EMAIL PROTECTED]> [2006.01.20.1703 +0100]:
> Do you know about an implementation of libkdtree that works with
> MS visual C++ (6.0 or 7.*) ?

No. My library is ANSI C++ compatible. If MSVC can't handle that,
there's another reaons why I've successfully avoided it for the past
10 years.

Sorry.

BTW: this has nothing to do with debian-devel, and even if, you
don't need to CC me as I read the list. There's a libkdtree-users
list on sourceforge.

-- 
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!
 
windoze is the one-night-stand of operating systems;
you feel so cheap after having used it.


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

Re: Re: Re: statement from one of the klik project members [was: The klik project and Debian]

[Kurt Pfeifle]

Wouter Verhelst wrote on debian-devel@lists.debian.org:
> [Re-adding Cc to Kurt, as he's mentioned he isn't subscribed]
>
> On Fri, Jan 20, 2006 at 01:20:26PM +0800, Cameron Patrick wrote:
> > Kurt Pfeifle wrote:
> > > The klik client installation needs root privileges once, to add 7 lines
> > > like this one to /etc/fstab:
> > >
> > >   /tmp/app/1/image /tmp/app/1 cramfs,iso9660 user,noauto,ro,loop,exec 0
> > > 0
> >
> > Doesn't this introduce a local root exploit?  A user can easily write
> > their own /tmp/app/1/image file which contains, say, a setuid root bash
> > executable.
>
> Yes, that's exactly what I was afraid of, myself.

Please try "man mount". If your manpage is similar to mine, it will 
contain something like:

 snip --
OPTIONS
   user   Allow an ordinary user to mount the file system.  The name 
  of the mounting user is written to mtab so that he can un-
  mount the file system again.   This option implies the op-
  tions noexec, nosuid, and nodev (unless overridden by sub-
  sequent options, as in the option line user,exec,dev,suid).
 snap --

Note the part mentioning "nosuid" - and compare it to the fstab line 
used by klik.   :-)

Cheers,
Kurt  [not subscribed]

Re: new mplayer 1.0pre7try2 package

[Christian Marillat]

Nathanael Nerode <[EMAIL PROTECTED]> writes:

> aj@azure.humbug.org.au:

[...]

> Contrast rte, where the ftpmasters told Marillat exactly what he needed to 
> remove to get the package in Debian, and he didn't do it, and declared that 
> he would keep uploading it.  Leaving *that* in limbo is totally reasonable.

I've *never* received any e-mail saying that.

Christian


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

Re: Obsolete packages in Experimental

[Paul Brossier]

On Fri, Jan 20, 2006 at 04:09:28AM -0600, Peter Samuelson wrote:
> 
> [Jérôme Warnier]
> > Or even better: a list of all packages already installed on my system
> > which have an experimental version?
> 
> There might be a better way, but assuming you have experimental in your
> sources.list...
> 

aptitude search ~Aexperimental | grep ^i

ciao, piem


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

Re: Obsolete packages in Experimental

[Michal Politowski]

On Fri, 20 Jan 2006 10:34:11 +0100, Jérôme Warnier wrote:
[...]
> BTW, is there a way to list all packages in experimental?

aptitude search '~Aexperimental'

> Or even better: a list of all packages already installed on my system
> which have an experimental version?

aptitude search '~i~Aexperimental'

Also
aptitude search '~S~i~Aexperimental'
will find packages where the installed version is the one in experimental.

-- 
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.


signature.asc
Description: Digital signature

Re: Backports

[John Gee]

So is it safer for me to use backports or to get ubdated software from 
testing?  Which will be more stable on my stable system?


_
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/



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

Re: APT public key updates?

[Jon Dowland]

On Fri, Jan 06, 2006 at 07:35:27AM +, Andrew Suffield wrote:
> However, we don't have to do this annually; with a 2048-bit key,
> replacing every five years and generating the new key one year before
> the old one expires should be safe at present.

That's true for the crypto strength issue, however if the key was
rotated that infrequently, the systems that perform the operation will
have succumbed to a lot of bit-rot between invocations and the people
doing it will be out of practise.

-- 
Jon Dowland
http://alcopop.org/


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

Re: statement from one of the klik project members [was: The klik project and Debian]

[Peter Palfrader]

On Fri, 20 Jan 2006, Wouter Verhelst wrote:

> > >   /tmp/app/1/image /tmp/app/1 cramfs,iso9660 user,noauto,ro,loop,exec 0 0
> > 
> > Doesn't this introduce a local root exploit?  A user can easily write
> > their own /tmp/app/1/image file which contains, say, a setuid root bash
> > executable.
> 
> Yes, that's exactly what I was afraid of, myself.

user implies noexec, nosuid, and nodev unless overridden by subsequent
options according to the mount(8) manpage.

-- 
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
messages preferred.| : :' :  The  universal
   | `. `'  Operating System
 http://www.palfrader.org/ |   `-http://www.debian.org/


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

Re: Need for launchpad

[Thomas Hood]

I wrote:
> Suppose Ubuntu were to cease claiming[0] that it gives back to Debian.
> Would everyone be happy then?  I doubt it.
> 
> [0] Here: http://ubuntu.com/ubuntu/relationship?highlight=%28debian%29
> there's a claim that "they send their bugfixes to the Debian developers
> responsible for that package in debian and record the patch URL in the
> debian bug system."


Looking at that page today I see that it has changed.  It seems to be
more accurate now, though I didn't keep a copy of the old text with which
I could compare what is written now:

> Ubuntu and Debian are distinct but parallel and closely linked
> systems. The Ubuntu project seeks to complement the Debian project in
> the following areas:
> [...]
> When a bug is reported in the Debian bug tracking system and then later
> fixed in Ubuntu, the fixes are communicated back directly to the Debian
> developers responsible for that package in Debian and record the patch
> URL in the debian bug system.
-- 
Thomas Hood


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

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

[Matthias Klose]

Joey Hess writes:
> Colin Watson wrote:
> > FWIW the relevant design docs from when this was done in Ubuntu are
> > here:
> > 
> >   https://wiki.ubuntu.com/EssentialPython (requirements)
> >   https://wiki.ubuntu.com/PythonInEssential (details)
> > 
> > The rationale for the set of included modules is in the latter, and was
> > basically done by taking each module in perl-base and mapping it to its
> > Python equivalent.
> 
> FWIW, that's a fairly strange way to do it, since modules are
> added/removed from perl-base as needed by the perl-using programs in the
> base system.

No, if you do look at https://wiki.ubuntu.com/PythonInEssential, you
will notice:

  Do not include:
* _ssl, pickle, cPickle,

pickle ends up as a dependency of subprocess.

> For example, perl-base includes Data::Dumper because debconf
> (used to) use it, not because there's any other particular reason to
> include that module in base, and I've just asked that Data::Dumper be
> removed, so including its equivilant (pickle) in python-base on that
> rationalle is decidely strange.

Ubuntu did use perl-base just as a starting point.

> If we followed the same method for python-base, then we would
> 
> a) instroduce python-base iff we had some package(s) written in python
>that we wanted in the base system (apt-listchanges comes to mind)
> b) include only the modules needed by the package(s).

We once had a python-base package and got complaints about the name
being misleading.  Besides that, I got questions from Debian only
developers and Debian users to have the minimal package in Debian as
well.  That does not look misleading, as long as the name implies that
you cannot expect a complete python installation.

  Matthias


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

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

[Jon Dowland]

On Thu, Jan 19, 2006 at 05:58:20PM -0500, David Nusinow wrote:
> For what it's worth, we've caught hell from the ruby community for
> breaking the standard library in to its component parts and not
> installing it all by default. This problem has been largely abrogated
> as of late, but I'd rather not see us piss off the python community
> for making a similar mistake.

I believe the problem with the ruby situation wasn't that the monolithic
ruby distribution was split up; but that there was no clear way to
install the lot in one go, without prior knowledge of what the whole
distribution was: a simple meta-package with the correct dependencies
was all that was missing.

-- 
Jon Dowland
http://alcopop.org/


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

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

[Matthias Klose]

Joe Wreschnig writes:
> On Thu, 2006-01-19 at 12:12 +1000, Anthony Towns wrote:
> > I don't know what's actually in (or more importantly not in)
> > python2.4-minimal though.
> 
> I'm eyeballing right now. Things that jump out at me:
>  * No character encoding, translation, or locale handling.
>  * A little oddly, loss of shutil.
>  * No sockets.
> 
> The first one seems like it would be a show-stopper to me, unless we
> expect programs in the base system to only deal with ASCII. This is a
> fairly large addition to package, too.
> 
> The second can easily be fixed; possibly just oversight. It's a small
> module and gives Python equivalents of cp -r, rm -r, and mv.
> 
> The third seems like something software in base may want to do; I
> mention it specifically because perl-base include socket support.

Colin already mentioned that the socket modules are in -minimal.
shutil looks reasonable.  encodings and locale handling come with a
prize: a size of about 3MB, which would more than double the size of
-minimal (2.4 ships with the cjk codecs).

  Matthias


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

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

[Kevin Mark]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jan 19, 2006 at 05:58:20PM -0500, David Nusinow wrote:
> On Thu, Jan 19, 2006 at 01:47:18PM -0800, Matt Zimmerman wrote:
> > On Thu, Jan 19, 2006 at 09:23:30PM +, Martin Michlmayr wrote:
> > > * Matt Zimmerman <[EMAIL PROTECTED]> [2006-01-19 12:45]:
> > > > Please don't do this; it implies that python-minimal would be part
> > > > of base, but not full python, and this is something that python
> > > > upstream explicitly objects to.
> > > 
> > > Why?  Surely having a sub-set of python is better than nothing at all, no?
> > 
> > One of the appealing things about the Python language is their "batteries
> > included" philosophy: users can assume that the standard library is
> > available, documentation and examples are written to the full API, etc.
> > When it's broken into pieces, they get complaints and support requests from
> > their user community when things don't work the way they should.
> 
> For what it's worth, we've caught hell from the ruby community for breaking
> the standard library in to its component parts and not installing it all by
> default. This problem has been largely abrogated as of late, but I'd rather
> not see us piss off the python community for making a similar mistake.
> 
> That said, I don't really understand why it's Ok for Ubuntu to do this but
> not us.
> 
>  - David Nusinow
Hi Debian folks,
Debian seems to like to support embedded devices and allow folks to
install as little as possible in/for a base install. And in that vein,
the discussion is on 'essential' packages. I can understand if a whole
language community got pissed if when you install a standard-level
packages like 'perl' and then it was missing pieces, but aren't Debian devs
allowed to design packages for our philosophical/project goals in regards to
a 'mininal' install when we design an 'essential' packages? If Ubuntu's
goals are to heavily use/promote Python and feel its 'essential' to
include the whole shebang and not part, then that's their goals and its
fine by me. 

Giving away code (GPL or otherwise) to the world is done for many
reasons.  Aparently some folks are more concerned about how their work
is used. As with the attribution in .debs, folks want the users to not
associate possible (as judged by them) 'bad'/'unofficial'/'off
project'/'different' work with their projects. But the perl folks don't
seem to have that objection! x-) (at least none have spoken yet!)
cheers,
Kev
- -- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD0JFJv8UcC1qRZVMRAmvJAJ9AVNJDhdpKRYO2bcCj80u084hPVQCfXnn3
qCUzzKlIHj8v4eieYXR1JvE=
=lEuL
-END PGP SIGNATURE-


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

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

[Thomas Hood]

Matt Zimmerman wrote:
> The compromise we struck with upstream was that we would not give
> the user a system with a "broken" Python.


So upstream objects to the separate packaging of python-minimal unless
all of python is installed when python-minimal is installed (which in
Ubuntu's case is: always) unless the user takes special action to
prevent this.  Hmm.

Given that Debian does not have python in base and that some Debian
packagers would like to make use of python-minimal, and Debian
presumably does not want to make python-minimal Essential: yes, I'd
suggest that a different way be sought for satisfying upstream.

I'll assume that python2.4-minimal Recommending: python2.4 won't be
enough.

How about this?  The current python2.4-minimal package contains
/usr/bin/python2.4.  We would move this to /usr/lib/python2.4/interpreter
so that it is no longer present on the standard search path.  The full
python2.4 package would contain a symlink /usr/bin/python2.4 ->
/usr/lib/python2.4/interpreter to make the interpreter available on the
path.  python-minimal Depends on python2.4-minimal and contains the
symlink /usr/bin/python -> /usr/bin/python2.4.  In addition it would
contain the symlink /usr/lib/python/interpreter ->
/usr/lib/python2.4/interpreter.  Packages that currently Depend on
python but use only minimal functionality could Depend on python-minimal
but they would have to run python using /usr/lib/python/interpreter.
The stripped down python interpreter would be "hidden" from command-line
users but would still be available for use by packaged programs.


Thomas Bushnell wrote:
> Ok, but now I'm confused: why is python-minimal needed in Essential?
> Why not simply depend on it straightforwardly?


   http://marc.theaimsgroup.com/?l=debian-devel&m=113768382100129&w=2
-- 
Thomas Hood


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

Re: Obsolete packages in Experimental

[Peter Samuelson]

[Jérôme Warnier]
> Or even better: a list of all packages already installed on my system
> which have an experimental version?

There might be a better way, but assuming you have experimental in your
sources.list...

  t=$(tempfile);
  awk > $t '/^Package:/{print "^" $2 "$"}' \
/var/lib/apt/lists/*_dists_experimental_main_binary-*_Packages
  dpkg --get-selections | awk '/\tinstall$/{print $1}' | grep -f $t
  rm $t

This relies on package names being regex-friendly.  (I think the only
regex character they can have is ".", which causes few problems.)


signature.asc
Description: Digital signature

Alberta

[Alberta Vera]

Good afternoon,
Vera
Good Bye



Vera
Vera
Vera
Vera
Vera
Vera
Vera
Vera
Vera
Vera


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

Re: Obsolete packages in Experimental

[Jérôme Warnier]

Le jeudi 19 janvier 2006 à 16:38 +, Adam D. Barratt a écrit :
> On Thursday, January 19, 2006 11:35 AM, Jérôme Warnier
> <[EMAIL PROTECTED]> wrote:
> 
> > After the last update of OOo in Sid (aka Unstable), I wonder if it is
> > generally considered acceptable to keep obsolete packages in
> > experimental (currently, Sid has 2.0.1-2 and Experimental 2.0.1-1).
> 
> Further to other answers, in this particular case you were about six and a
> half hours out of date ;-)
You were right. It is out of experimental now.

BTW, is there a way to list all packages in experimental?
Or even better: a list of all packages already installed on my system
which have an experimental version?
I would like to see which ones are available.


> =
> [Date: Wed, 18 Jan 2006 21:06:31 -0800] [ftpmaster: Ryan Murray]
> Removed the following packages from experimental:
> [...]
> openoffice.org |2.0.1-1 | source, i386, powerpc, sparc
> openoffice.org-base |2.0.1-1 | i386, powerpc, sparc
> [...]
> openoffice.org-writer |2.0.1-1 | i386, powerpc, sparc
> [...]
> --- Reason ---
> [rene] NVIU
> --
> =
> 
> (i.e. rene, the archive "cruft remover" flagged the experimental packages
> for removal as there was a newer version in unstable).
> 
> Cheers,
> 
> Adam

Re: Size matters. Debian binary package stats

[Ron Johnson]

On Thu, 2006-01-19 at 20:49 -0800, Thomas Bushnell BSG wrote:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> 
[snip]
> (And really, data about which mirrors would be dropped would help:
> maybe we can buy *them* a disk.  Disks are cheap!)

Unless the shelf is full, there's no more plugs left on the PS,
there's no more room on the SCSI chain, they only allow purchases
in "RAID-5 units" of SCSI disks, etc, etc.


-- 
-
Ron Johnson, Jr.
Jefferson, LA USA

"Not peace at any price! Chains are worse than bayonets."
Douglas William Jerrold


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

[Matthew Palmer]

On Fri, Jan 20, 2006 at 12:10:54AM +0100, JanC wrote:
> On 1/17/06, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > How about renaming Maintainer to Debian-Maintainer in Ubuntu's binary
> > packages, and having a specific Ubuntu-Maintainer?
> 
> This should probably happen in a way that all (or most) Debian-derived
> distro's agree on then.
> 
> And one more problem: Ubuntu doesn't have the same "maintainer"
> concept as Debian has...

I keep hearing this, but I really don't believe it.  In Debian, "Maintainer"
means "An individual or group of people primarily responsible for the
on-going well being of a package".  As I understand it, in Ubuntu, the MOTUs
have responsibility for all of the packages in Universe.

- Matt


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

Work-needing packages report for Jan 20, 2006

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 187 (new: 20)
Total number of packages offered up for adoption: 99 (new: 6)
Total number of packages requested help for: 20 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   boson-base (#348062), orphaned 5 days ago
 Description: Core package for Boson
 Reverse Depends: boson-music boson-data boson
 Installations reported by Popcon: 24

   boson-data (#348589), orphaned 2 days ago
 Description: Data files for Boson
 Reverse Depends: boson boson-base
 Installations reported by Popcon: 24

   boson-music (#348588), orphaned 2 days ago
 Description: Music Pack for Boson
 Reverse Depends: boson
 Installations reported by Popcon: 23

   dancer-ircd (#348746), orphaned yesterday
 Installations reported by Popcon: 41

   dancer-services (#348748), orphaned yesterday
 Installations reported by Popcon: 21

   dbacl (#348949), orphaned today
 Description: A digramic Bayesian text classifier
 Installations reported by Popcon: 31

   kexi (#348832), orphaned today
 Description: tool for manipulating database objects in KDE3
 Reverse Depends: kexi-mysql-driver libkexi-dev
   kexi-postgresql-driver
 Installations reported by Popcon: 118

   libcache-mmap-perl (#348951), orphaned today
 Reverse Depends: libbric-perl
 Installations reported by Popcon: 8

   libmasonx-interp-withcallbacks-perl (#348952), orphaned today
 Reverse Depends: libbric-perl
 Installations reported by Popcon: 6

   libparams-callbackrequest-perl (#348953), orphaned today
 Reverse Depends: libbric-perl
 Installations reported by Popcon: 7

   libstring-crc32-perl (#348954), orphaned today
 Reverse Depends: ubh libcache-memcached-perl
 Installations reported by Popcon: 180

   manpages-fi (#348790), orphaned yesterday
 Installations reported by Popcon: 12

   oneko (#348199), orphaned 4 days ago
 Description: a cat chases the cursor (now a mouse) around the screen
 Reverse Depends: junior-toys
 Installations reported by Popcon: 278

   qglviewer (#348793), orphaned yesterday
 Reverse Depends: libqglviewer-dev
 Installations reported by Popcon: 1

   rep-xmms (#348786), orphaned yesterday
 Reverse Depends: sawfish-xmms
 Installations reported by Popcon: 195

   rxvt-unicode (#348719), orphaned yesterday
 Description: RXVT-like terminal emulator with Unicode support
 Installations reported by Popcon: 221

   sawfish-xmms (#348789), orphaned yesterday

   scottfree (#348950), orphaned today
 Installations reported by Popcon: 40

   x-symbol (#348060), orphaned 5 days ago
 Description: WYSIWYG TeX mode for XEmacs
 Installations reported by Popcon: 93

   xmailbox (#348656), orphaned yesterday
 Description: mail notifier with animation and sound effects
 Installations reported by Popcon: 28

167 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   apmd (#348468), offered 3 days ago
 Description: utilities for advanced power management
 Reverse Depends: battery-stats apmd osdsh sleepd libapm-dev xapm
   wmbattery gnome-applets
 Installations reported by Popcon: 4674

   ircii-pana (#348456), offered 3 days ago
 Description: Advanced Internet Relay Chat client
 Reverse Depends: bitchx-gtk bitchx-ssl
 Installations reported by Popcon: 1063

   laptop-net (#348471), offered 3 days ago
 Description: automatically adapt laptop ethernet
 Installations reported by Popcon: 71

   mozilla-firefox-locale-all (#348217), offered 4 days ago
 Reverse Depends: mozilla-firefox-locale-he-il
 Installations reported by Popcon: 365

   oss-preserve (#348469), offered 3 days ago
 Description: save/restore OSS mixer settings
 Installations reported by Popcon: 33

   tra (#348473), offered 3 days ago
 Description: a file-system synchronizer
 Installations reported by Popcon: 28

93 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 210 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot-cross ltsp-server dfsbuild aboot
 Installations reported by Popcon: 55

   athcool (#278442), requested 450 days ago
 Description: Enable powersaving mode for Athlon/Du

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Brian Nelson]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Brian Nelson <[EMAIL PROTECTED]> writes:
>
>> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
>>
>>> Brian Nelson <[EMAIL PROTECTED]> writes:
>>>
 I completely agree, and hereby question whether the secretary is capable
 of being impartial in this case given his personal interests[1] in this
 issue.
>>>
>>> You may question it, but it doesn't affect the case.
>>
>> W, look at me!  I'm Thomas Bushnell and I reply to every single
>> message on every single Debian mailing list, regardless of whether I
>> have anything useful to say!
>
> Huh?  You seemed to be saying (using quite formal language like
> "hereby") that your questioning should have some effect.

It was a jest, partly at Manoj's writing style because I knew he'd read
it, and partly at the overall absurdity that seems to be plaguing the
project. The point still stands, however.

> My point is that it does not, and need not.  It has only whatever
> effect Manoj chooses to give it.

The secretary is supposed to "make decisions... preferably consistent
with the consensus of the Developers".  By speaking out against it, I'm
trying to change the consensus.

-- 
Captain Logic is not steering this tugboat.


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