ITP: lonewarrior -- Collect particles in universe with a spaceship

[Gürkan Sengün]

Package: wnpp
Severity: wishlist

* Package name: lonewarrior
 Version : 0.1
 Upstream Authors : Jetro Lauha <[EMAIL PROTECTED]>
* URL : http://jet.ro/creations (webpage currently down *)
* License : GNU GPL
 Description : Collect particles in universe with a spaceship
 In this game you are flying with a little ship, using collectors to
gather particle elements, and then pull the collectors to a disruptor
base to scoop them up.
.
Homepage: http://jet.ro/creations

* for now you can check google cache or look at
http://io.debian.net/~tar/debian/lonewarrior/lonewarrior-0.1.tar.gz
(the sound system used is FMOD which is not free, that code can be
disabled. but then i've tried this game on windows and the sound is
really great, so the goal will be to get sound to work with a free
sound system to work, help welcome)

-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc
Locale: LANG=POSIX, LC_CTYPE=POSIX


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

Re: NEW processing slowdown (Was: FAQ, Re: new mplayer)

[Francesco P. Lovergine]

On Sat, Oct 21, 2006 at 01:34:14PM +0200, Petter Reinholdtsen wrote:
> I suspect something need to be done with the NEW process, as adding
> more people seem to only improve the situation for a limited time.
> Perhaps it could be optimized to make it less time consuming for those
> processing it, or perhaps it need a complete redesign to avoid the
> current bottleneck.  I'm not sure, as I only see it from the outside
> through http://ftp-master.debian.org/new.html>.

AFAIK the real issue is auditing. Auditing task is slow and prone 
to bothering who does that. IMHO adding people to do that is the
only way to go, but for removing auditing (which is not acceptable).
This is the same reason why none can sponsor dozen of packages
without lowering reviewing quality.

-- 
Francesco P. Lovergine


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

Re: First draft of review of policy must usage

[Josselin Mouette]

Le mercredi 25 octobre 2006 à 01:03 -0500, Manoj Srivastava a écrit :
> Here is a first draft of changes to the policy that I think
>  are required to bring ot closer in line with extant practice. I
>  removed portions from the policy that linked policy violations to bug
>  severities, since this has been deemed controversial and a "bug" in
>  policy.  Next, I removed the DFSG text and replaced it by a pointer
>  to the DFSG document itself, this prevents duplication, and I am not
>  sure I would have remembered to edit it here if we ever changed the
>  DFSG.

FWIW, I strongly disagree with these changes. The solution is to bring
the release policy in line with the real policy, not the opposite.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: libc6 2.5 and Etch

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/25/06 21:42, Kevin Mark wrote:
> On Wed, Oct 25, 2006 at 08:21:39AM -0500, Ron Johnson wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/25/06 06:27, Aurelien Jarno wrote:
>>> Ron Johnson a écrit :
 On 10/25/06 04:53, Martin Michlmayr wrote:
> * Ron Johnson <[EMAIL PROTECTED]> [2006-10-25 04:36]:
>> [snip]
>>> For m68k and hurd, I have sent a mail to the porters a few months ago, I
>>> haven't received any answer. Maybe we should have to drop those
>>> architectures, at least temporarily.
>> m68k was dropped from Etch last week. :(
>>
> When Sarge was released, amd64 was not officially released but had an
> unofficial release. why not do the same with the hopes tha etch+1 will
> see m68k in relase shape?

If I read the (extended) thread correctly, they're going to do
exactly that: keep m68k on Sid, and do unofficial Etch releases.

There's a *huge* thread cross-posted to d-m68k and d-release that
hashes thru the whole thing.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFQHs7S9HxQb37XmcRAqUzAKCNQInsiK0tWeIBpQv2pSwnG7qA0gCfVWgO
UAk3ycOgEIlheOZYTvkh2Uk=
=M+Z8
-END PGP SIGNATURE-


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

Bug#395309: ITP: labyrinth -- Labyrinth is a powerful but simple mindmapping tool which supports images, drawings, and text.

[Kevin Kubasik]

Package: wnpp
Severity: wishlist
Owner: Kevin Kubasik <[EMAIL PROTECTED]>


* Package name: labyrinth
  Version : 0.2.1
  Upstream Author : [EMAIL PROTECTED] 
* URL : http://www.gnome.org/~dscorgie/labyrinth.html
* License : LGPL
  Description : Labyrinth is a powerful but simple mindmapping tool which 
supports images, drawings, and text.

(Include the long description here.)

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.32-grsec+f6b+gr217+nfs+a32+fuse23+tg+++opt+c8+gr2b-v6.194
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Re: Bug#395309: ITP: labyrinth -- Labyrinth is a powerful but simple mindmapping tool which supports images, drawings, and text.

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/26/06 04:02, Kevin Kubasik wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Kevin Kubasik <[EMAIL PROTECTED]>
> 
> 
> * Package name: labyrinth
>   Version : 0.2.1
>   Upstream Author : [EMAIL PROTECTED] 
> * URL : http://www.gnome.org/~dscorgie/labyrinth.html
> * License : LGPL
>   Description : Labyrinth is a powerful but simple mindmapping tool which 
> supports images, drawings, and text.
> 
> (Include the long description here.)

Adding "Labyrinth is " to the short description is redundant, and
makes it too long.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFQIKyS9HxQb37XmcRAreOAJ0ewnL+M8WIijXbPZJDVVBFnY35pACg1KZb
k7FamtyFNnmsf6noQML/pO0=
=jG4P
-END PGP SIGNATURE-


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

Re: incoming locked?

[Christoph Berg]

Re: Andreas Metzler 2006-10-13 <[EMAIL PROTECTED]>
> packages.debian.org is lagging almost a whole day (bug #335011), you
> should use madison on merkel or "apt-cache show" on a up to date sid
> system to check the available version.

'rmadison' in the devscripts package queries the database remotely
using http. Might be handier.

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


signature.asc
Description: Digital signature

Re: Bug mass filling

[Ian Jackson]

Manoj Srivastava writes ("Re: Bug mass filling"):
> On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson <[EMAIL PROTECTED]> said: 
> > There are two different and orthogonal properties of a policy
> > requirement:
> >   1. [...]
> > [and]
> >   2. Is a violation of the requirement release-critical ?  That is,
> >  would it be better to remove the package (or to stick with the
> >  old version of the package) than to live with this bug ?
> 
> I posit the second one is not a characteristic of the policy
>  requirement; it is a characteristic of the bug.

Well, yes.

> My stance is that bug severity tags are tied to policy
>  violations, since that can be determined mechanically; violate a must
>  directive, bug is serious.  Whether or not all serious bugs are RC is
>  anothermatter that the release team determines; hence the *-ignore
>  tags.

Why on earth is it useful to encode some scripturally-determined
property of a bug in the severity ?

The use for the severity is to 1. allow us to record whether the bug
is release critical (which is definitely something we need to track)
and 2. allow the project to prioritise its work (which is also
something we need to track).  Helpfully we can use the same linear
scale for both because all release-critical bugs should always have a
higher priority than all non-release-critical bugs.

> The problem is, since this involves human judgement, one can no
>  longer state in policy what category a must violation of policy falls
>  into; policy must waffle with well, if you find a policy violation,
>  fgiure out what severity the ciolation would be, consult your
>  feelings, other peoples feelings, release managers,  and perhaps the
>  phase of the moon.

This is a completely bizarre assertion.  If you're submitting a bug
you can look at the BTS web page which gives clear definitions of all
of the bug severities.

There is only one significant problem with the list at
 http://www.debian.org/Bugs/Developer#severities
which is the definition of `serious'.  It should be replaced with:

 serious
 Release critical bugs (other than `grave' and `critical' bugs);
 see also the Release Managers' policy at .  Do not set
 this severity unless it would be better to remove the package
 from the distribution than to ship it with this bug.  The
 final decision about whether a bug is release critical rests
 with the Release Managers.

Obviously there is room for judgement here by the submitter and the
maintainer - but we rely on our colleagues to make the right decisions
in all sorts of areas.

> Since we already feel that our RM's are overworked (hence
>  dunc-tank and payment schemes), I strongly suggest we not add to the
>  RM's burdens any more than we have to.

If the RMs want to write a document saying what counts as a release
critical bug, can do so.  And lo, look, they have.

Ian.


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

Policy incorrect use of `must', `should', etc

[Ian Jackson]

Manoj Srivastava writes ("Re: Bug mass filling"):
> On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson <[EMAIL PROTECTED]> said: 
> > There are two different and orthogonal properties of a policy
> > requirement:
> >
> >   1. Is the requirement applicable in all cases, or are there
> >  sometimes overriding reasons to it another way, or exceptional
> >  cases where the requirement ought not to apply ?
...
> Nothing you have said contradicts either what I or aba have
>  said; the devil lies in the details you have elided.

I see from s1.1 of the current policy manual that it describes must
and should as follows:

the words must, should and may, and the adjectives required,
recommended and optional, are used to distinguish the significance
of the various guidelines in this policy document. Packages that
do not conform to the guidelines denoted by must (or required)
will generally not be considered acceptable for the Debian
distribution. [etc]

This is quite different to the usual use of these terms, which is from
BCP14 (RFC2119):

  1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
 definition is an absolute requirement of the specification.
  ...
  3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
 may exist valid reasons in particular circumstances to ignore a
 particular item, but the full implications must be understood and
 carefully weighed before choosing a different course.
  [etc]

Indeed, most of the policy manual was written with RFC2119 terminology
in mind.  The 5th paragraph of policy should be replaced with:

  In this document, the words `must', `should' and `may', and the
  adjectives `required', `recommended', and `optional', are used
  in accordance with BCP14 (RFC2119).

Ian.


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

Re: mucking with dpkg control files in maintainer scripts?

[Ian Jackson]

Frank Küster writes ("Re: mucking with dpkg control files in maintainer 
scripts?"):
> In other words, "commits" to the dpkg database are atomic, and if dpkg
> is called from a script started by dpkg, it will report all packages in
> the correct, current and maybe partial state, including the package
> processed so far?

Yes, exactly.  (You only get to inspect the state, not modify it, for
obvious reasons.)

But: if you find yourself doing this you're probably doing something
wrong.

Ian.

Re: Getting package build dependencies

[Goswin von Brederlow]

Ross Boylan <[EMAIL PROTECTED]> writes:

> I am interested in getting build-dependencies for a source package on
> a system using aptitude.  In the past I've used apt-get build-dep, but
> that was on systems managed with apt-get.  I think aptitude won't know
> about apt-get's selections, and may toss the packages at the first
> chance (or perhaps get confused in some other way).
>
> Is this analysis correct?  If so, is there a good solution?
>
> The two other routes I see are to use dpkg-checkbuilddeps (but then I
> still need to get the output into aptitude) or to use one of the
> autobuilders that work in a chroot (which seems kind of heavy weight).
>
> Thanks.
>
> Ross Boylan
>
> cc's appreciated.
>
> P.S. apt-get build-dep has always made me a bit uncomfortable, since I
> presume it goes by the installed binary package.  If you want to build
> some other version (e.g., system is testing but you want to build
> unstable) the dependencies aren't necessarily quite right.  So I'd be
> happy to discover an alternative.

apt-get build-dep goes by the Sources file. Binary packages don't even
have that information.

As to your real problem. I was playing around with building dummy
packages (src-) on the fly from the Sources file that depends on
all Build-Depends. The idea was that you would 'aptitude install
src-foo' to install the build-depends for foo and src-foo would be
flagged manual then. Removing src-foo would drop all the build-depends
too.

I did this as apt-get and dpkg-deb wrapper when I played around with
it. You would have to extend it to wrap aptitude update as well.

If you want to revive the idea here is what you need:

1. pick a dummy deb on the server that has the Sources file.
2. Add a wrapper for aptitude update that does a normal update and
generates a fake Packages files from the Sources file it updated and
then runs apt-get -d update (or the python equivalent to update the
caches).
3. Add a wrapper for dpkg-deb that detects when it is asked to install
the dummy deb from 1 and then instead hands dpkg an empty data.tar.gz
and a fake control.tar.gz reflecting the Build-Depends (as
depends). You basically build the fake deb that is listed in Packages
at this point and pass it to dpkg.


When you update you just generate the fake Packages file.
When you install aptitude downloads the dummy deb, renames that to the
src-foo name (at least apt does) and then calls dpkg. dpkg calls
dpkg-deb (your wrapper) which ignores the dummy deb, builds a fake one
and passes that back to dpkg. Aptitude pulls in the build-depends as
depends from the fake Packages file.

MfG
Goswin

PS: alternatively to an apt wrapper an apt download method could work too.


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

Re: First draft of review of policy must usage

[Marco d'Itri]

On Oct 26, Josselin Mouette <[EMAIL PROTECTED]> wrote:

> FWIW, I strongly disagree with these changes. The solution is to bring
> the release policy in line with the real policy, not the opposite.
Yes, and let's forget about this "reality" bullshit...

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#395333: ITP: counter -- Simple and light web hits counter

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho <[EMAIL PROTECTED]>


* Package name: counter
  Version : 0.21
  Upstream Author : mein Herrchen <[EMAIL PROTECTED]>
* URL : http://home.arcor.de/momomops/counter
* License : GPL
  Programming Lang: PHP
  Description : Simple and light web hits counter

A PHP script with the ability to show the number of hits with text
or images. This script runs into web site directory and uses GIF
images in graphical mode. You can use your custom GIF images. It
isn't a CGI program.

URL: http://home.arcor.de/momomops/counter

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1)


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

Re: libc6 2.5 and Etch

[Wouter Verhelst]

On Wed, Oct 25, 2006 at 10:42:08PM -0400, Kevin Mark wrote:
> When Sarge was released, amd64 was not officially released but had an
> unofficial release. why not do the same with the hopes tha etch+1 will
> see m68k in relase shape?

That's exactly what we're planning to do.
-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: mucking with dpkg control files in maintainer scripts?

[Goswin von Brederlow]

Ian Jackson <[EMAIL PROTECTED]> writes:

> Frank Küster writes ("Re: mucking with dpkg control files in maintainer 
> scripts?"):
>> In other words, "commits" to the dpkg database are atomic, and if dpkg
>> is called from a script started by dpkg, it will report all packages in
>> the correct, current and maybe partial state, including the package
>> processed so far?
>
> Yes, exactly.  (You only get to inspect the state, not modify it, for
> obvious reasons.)
>
> But: if you find yourself doing this you're probably doing something
> wrong.
>
> Ian.

Isn't it more accurate to say that the dpkg database is transaction
based? Changes are recorded on the fly in updates and then commited
attomically when the transaction is finished.

And dpkg honors the updates log when being called again while
maintainer scripts poking around in the status file will not.

MfG
Goswin


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

Re: Policy incorrect use of `must', `should', etc

[Manoj Srivastava]

On Thu, 26 Oct 2006 12:09:18 +0100, Ian Jackson <[EMAIL PROTECTED]> said: 

> Manoj Srivastava writes ("Re: Bug mass filling"):
>> On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson
>> <[EMAIL PROTECTED]> said:
>> > There are two different and orthogonal properties of a policy
>> > requirement:
>> >
>> >   1. Is the requirement applicable in all cases, or are there
>> >  sometimes overriding reasons to it another way, or
>> >  exceptional cases where the requirement ought not to apply ?
> ...
>> Nothing you have said contradicts either what I or aba have said;
>> the devil lies in the details you have elided.

> I see from s1.1 of the current policy manual that it describes must
> and should as follows:

> This is quite different to the usual use of these terms, which is
> from BCP14 (RFC2119):

Yup, and we are well aware of the difference.

> Indeed, most of the policy manual was written with RFC2119
> terminology in mind.  The 5th paragraph of policy should be replaced
> with:

>   In this document, the words `must', `should' and `may', and the
>   adjectives `required', `recommended', and `optional', are used in
>   accordance with BCP14 (RFC2119).

Policy has not been written with that in mind since, oh, the
 1998, so if this is to be done then policy has to be rewritten from
 scratch.

I think such an effort is ill adviced.

manoj
-- 
Work smarter, not harder, and be careful of your speling.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug mass filling

[Manoj Srivastava]

On Thu, 26 Oct 2006 12:02:31 +0100, Ian Jackson <[EMAIL PROTECTED]> said: 

> Manoj Srivastava writes ("Re: Bug mass filling"):
>> On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson
>> <[EMAIL PROTECTED]> said:
>> > There are two different and orthogonal properties of a policy
>> > requirement:
>> >   1. [...]
>> > [and]
>> >   2. Is a violation of the requirement release-critical ?  That
>> >  is, would it be better to remove the package (or to stick
>> >  with the old version of the package) than to live with this
>> >  bug ?
>> 
>> I posit the second one is not a characteristic of the policy
>> requirement; it is a characteristic of the bug.

> Well, yes.

>> My stance is that bug severity tags are tied to policy violations,
>> since that can be determined mechanically; violate a must
>> directive, bug is serious.  Whether or not all serious bugs are RC
>> is anothermatter that the release team determines; hence the
>> *-ignore tags.

> Why on earth is it useful to encode some scripturally-determined
> property of a bug in the severity ?

Because developers and bug reporters are human, and may need
some guidance about bug severities, and 

> The use for the severity is to 1. allow us to record whether the bug
> is release critical (which is definitely something we need to track)
> and 2. allow the project to prioritise its work (which is also
> something we need to track).  Helpfully we can use the same linear
> scale for both because all release-critical bugs should always have
> a higher priority than all non-release-critical bugs.

A very developer centric view. But there are other pepople in
 the community; and as a general statement this falls far short of the
 mark for which bug severities are actually useful for. Bug severities
 have one other purpose, and perhaps the most importan of all: It lets
 people know whether or not it is OK to upgrade or install a package,
 and but severities are one way of gauging a release' quality. While
 only partially relevant to this case, you are making what seems like
 a general statement, and missing important bits.



>> The problem is, since this involves human judgement, one can no
>> longer state in policy what category a must violation of policy
>> falls into; policy must waffle with well, if you find a policy
>> violation, fgiure out what severity the ciolation would be, consult
>> your feelings, other peoples feelings, release managers, and
>> perhaps the phase of the moon.

> This is a completely bizarre assertion.  If you're submitting a bug
> you can look at the BTS web page which gives clear definitions of
> all of the bug severities.

I see you are trolling. However, I suppose I can say I have
 been trolled, since I am going to reply anyway.

People do not work like that. Simply ignoring the way people
 report bugs, and pretending that every one looks at all kinds of
 unrelated bug reports and cogently arrives at a working, consistent,
 and borderline correct severity may work in an, ahem, bizarre world
 you live in, but does not work on planet earth.

So, policy guidelines as to bug severities are a cheap way to
 arrive at a consistent default for bug severities, and there is no
 reason not to add such guidance, as long as the guidelines are
 flexible, and, more importantly, correct.

> There is only one significant problem with the list at
>  http://www.debian.org/Bugs/Developer#severitieswhich is the
>  definition of `serious'.  It should be replaced with:

May I suggest that his opinion is perhaps as, umm, ridiculous,
 as the rest of your rant?

> Obviously there is room for judgement here by the submitter and the
> maintainer - but we rely on our colleagues to make the right
> decisions in all sorts of areas.

Jindani.

manoj

-- 
All things that are, are with more spirit chased than
enjoyed. Shakespeare, "Merchant of Venice"
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

ITP: dphys-kernel-packages -- Generate many variants of kernel packages and modules

[Gürkan Sengün]

Package: wnpp
Severity: wishlist

* Package name: dphys-kernel-packages
 Version  : 20061026
 Upstream Authors : Neil Franklin <[EMAIL PROTECTED]>
* URL : 
http://www.phys.ethz.ch/~franklin/Projects/dphys-kernel-packages/
* License : Dual License GNU GPL or modified/non-advertising BSD
 Description : Generate many variants of kernel packages and modules
 Generates an range of kernel config files for various processors, SMP and
 memory size variants, Then compiles for each an kernel and an set of external
 kernel modules, and packages all of these as .deb packages for easy install
 .
 Homepage: http://www.phys.ethz.ch/~franklin/Projects/dphys-kernel-packages/

-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc
Locale: LANG=POSIX, LC_CTYPE=POSIX


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

Re: mucking with dpkg control files in maintainer scripts?

[Ian Jackson]

Goswin von Brederlow writes ("Re: mucking with dpkg control files in maintainer 
scripts?"):
> Isn't it more accurate to say that the dpkg database is transaction
> based? Changes are recorded on the fly in updates and then commited
> attomically when the transaction is finished.

No.  Updates written to /var/lib/dpkg/updates have been committed, in
the sense that dpkg has committed to them.  If dpkg decides to abort a
package installation, it will not roll back by unwinding updates in
/var/lib/dpkg/updates, but by writing new later updates of the
package's state (which will be moving in roughly reverse to usual), as
dpkg rewinds the installation attempt as applicable.  This ensures
that if dpkg dies, the whole system and status database are left in a
consistent (if perhaps undesirable) state.

> And dpkg honors the updates log when being called again while
> maintainer scripts poking around in the status file will not.

Those maintainer scripts are just buggy.

It would be simple to make a dpkg-query option to dump the current
status information to stdout but I'm not sure it's wise; it might
encourage maintainer scripts to use this information.  Perhaps we
should make the invocation fail if run from a maint script :-).

Ian.


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

Re: ITP: dphys-kernel-packages -- Generate many variants of kernel packages and modules

[Goswin von Brederlow]

Gürkan Sengün <[EMAIL PROTECTED]> writes:

> Package: wnpp
> Severity: wishlist
>
> * Package name: dphys-kernel-packages
>  Version  : 20061026
>  Upstream Authors : Neil Franklin <[EMAIL PROTECTED]>
> * URL : 
> http://www.phys.ethz.ch/~franklin/Projects/dphys-kernel-packages/
> * License : Dual License GNU GPL or modified/non-advertising BSD
>  Description : Generate many variants of kernel packages and modules
>  Generates an range of kernel config files for various processors, SMP and
>  memory size variants, Then compiles for each an kernel and an set of external
>  kernel modules, and packages all of these as .deb packages for easy install
>  .
>  Homepage: http://www.phys.ethz.ch/~franklin/Projects/dphys-kernel-packages/

If you intend to upload the kernel.debs you will get a problem with
the GPL and the security team.

The GPL requires the right source version to be present. A
Build-Depends: linux-tree-2.6 does not do that, not even versioned to
a specific release. So very quickly the sources used to build the deb
disapear.

And the security team doesn't like, lets call it 2nd level
sources. Fixing a security bug in those kernel debs requires first
fixing the linux source package and upload that and then on a second
pass rebuild your package against the new source.

Before you invest too much time please talk to the debian linux kernel
team and the security team about issues raised by your package.

MfG
Goswin


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

Re: Getting package build dependencies

[Matthias Julius]

Ross Boylan <[EMAIL PROTECTED]> writes:

> I am interested in getting build-dependencies for a source package on
> a system using aptitude.  In the past I've used apt-get build-dep, but
> that was on systems managed with apt-get.  I think aptitude won't know
> about apt-get's selections, and may toss the packages at the first
> chance (or perhaps get confused in some other way).
>
> Is this analysis correct?

Not completely.  When you install a package with apt-get (or dselect
or dpkg -i) the package will not be marked automatic in aptitude.
Thus aptitude will never automatically remove it.

So the real problem is to find and get rid of the build-depends when
you don't need them anymore.

I think it would be great if aptitude would learn about source
packages.  One could introduce a new flag ("S" maybe) that would cause
all build-depends to be installed automatically.  But of course this
would slow down aptitude update even more since it would have to
process the Sources files.

Matthias


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

Re: libc6 2.5 and Etch

[Michael Banck]

On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote:
> We plan to upload [glibc-2.5] right after the release of etch.
> 
> This version works on all architectures, but m68k, hurd and hppa which
> don't have TLS support.
> 
> For hppa the work is almost done, I am currently building the packages
> (but on a slow machine) to test them.
> 
> For m68k and hurd, I have sent a mail to the porters a few months ago, I
> haven't received any answer. Maybe we should have to drop those
> architectures, at least temporarily.

Speaking for the Hurd porters, we know that this needs to be done, but
so far nobody either had enough time or enough skill to do the necessary
work for it.


Michael

-- 
 for example, there is only one correct way to blank a screen,
and look at the number of screensavers
 people think it's cool, but apparently they have not seen
reservoir dogs


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

Bug#395364: ITP: wadc -- programming environment for creating doom levels

[Jon Dowland]

Package: wnpp
Severity: wishlist
Owner: Jon Dowland <[EMAIL PROTECTED]>

* Package name: wadc
  Version : 1.1
  Upstream Author : Wouter van Oortmerssen 
* URL : 
* License : GPL
  Programming Lang: Java
  Description : programming environment for creating doom levels

 wadc is an integrated development environment and
 functional programming language for developing doom-style
 levels.  It can be used to generate complex levels which
 can be saved out in Doom's native WAD format.
 .
 The IDE includes a text-editor component; a debug output
 pane and a 2D drawing pane which previews the current
 script's output.
 .
 An external nodes builder is required before the resulting
 WAD file can be played by a doom-engine.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


signature.asc
Description: Digital signature

Re: Getting package build dependencies

[Jon Dowland]

On Thu, Oct 26, 2006 at 01:48:45PM +0200, Goswin von
Brederlow wrote:
> As to your real problem. I was playing around with
> building dummy packages (src-) on the fly from the
> Sources file that depends on all Build-Depends.

Me too!

> The idea was that you would 'aptitude install src-foo' to
> install the build-depends for foo and src-foo would be
> flagged manual then. Removing src-foo would drop all the
> build-depends too.

I was going to generate src-foo locally and either drop the
.deb in $(pwd) or call aptitude install on the result.

I'll try and knock together a proof-of-concept...




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

Re: libc6 2.5 and Etch

[Thomas Schwinge]

Hello!

On Thu, Oct 26, 2006 at 05:45:24PM +0200, Michael Banck wrote:
> On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote:
> > For m68k and hurd, I have sent a mail to the porters a few months ago, I
> > haven't received any answer.

That is untrue.  I replied for the Hurd people.


> Speaking for the Hurd porters, we know that this needs to be done, but
> so far nobody either had enough time or enough skill to do the necessary
> work for it.

That is true.  Unfortunately.  So far, we're either required to revert a
number of patches from recent glibc versions or have to stick with the
2.3 branch.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: libc6 2.5 and Etch

[Aurelien Jarno]

Thomas Schwinge a écrit :
> Hello!
> 
> On Thu, Oct 26, 2006 at 05:45:24PM +0200, Michael Banck wrote:
>> On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote:
>>> For m68k and hurd, I have sent a mail to the porters a few months ago, I
>>> haven't received any answer.
> 
> That is untrue.  I replied for the Hurd people.
> 
> 
>> Speaking for the Hurd porters, we know that this needs to be done, but
>> so far nobody either had enough time or enough skill to do the necessary
>> work for it.
> 
> That is true.  Unfortunately.  So far, we're either required to revert a
> number of patches from recent glibc versions or have to stick with the
> 2.3 branch.
> 

Maybe hurd and m68k porters can maintain a glibc package using an old
version (2.3.6 ??) together? Well that's for after Etch.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: libc6 2.5 and Etch

[Barry deFreese]

- Original Message - 
From: "Michael Banck" <[EMAIL PROTECTED]>

To: 
Cc: 
Sent: Thursday, October 26, 2006 11:45 AM
Subject: Re: libc6 2.5 and Etch



On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote:

We plan to upload [glibc-2.5] right after the release of etch.

This version works on all architectures, but m68k, hurd and hppa which
don't have TLS support.

For hppa the work is almost done, I am currently building the packages
(but on a slow machine) to test them.

For m68k and hurd, I have sent a mail to the porters a few months ago, I
haven't received any answer. Maybe we should have to drop those
architectures, at least temporarily.


Speaking for the Hurd porters, we know that this needs to be done, but
so far nobody either had enough time or enough skill to do the necessary
work for it.


Michael



I have looked at it pretty in-depth.  Unfortunately as most of you know it 
is way outside of my skillset. :-(



-

"Programming today is a race between software engineers striving to build 
bigger and better idiot-proof programs, and the Universe trying to produce 
bigger and better idiots. So far, the Universe is winning." Rich Cook.


Barry deFreese (aka bddebian) 



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

Re: libc6 2.5 and Etch

[Marco d'Itri]

On Oct 26, Aurelien Jarno <[EMAIL PROTECTED]> wrote:

> Maybe hurd and m68k porters can maintain a glibc package using an old
> version (2.3.6 ??) together? Well that's for after Etch.
What for? Modern threaded software will require TLS more and more.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Thanks!

[Eike Nicklas]

I'm not sure where to post this email, so I am sending it to this list.
It is totally unproductive, but still I'd like to send it :-)

I know, these are troubling times for you developers: the dunc-tank
discussion, the firefox(tm)-iceweasel-debate, the hard work preparing
for the release of etch and so on...

So I think it is about time to send a big THANK YOU to ALL of you who
created this great distribution. Debian was the first distribution that
persuaded me of the advantages of linux and of free software and by now,
it has been my favourite operating system for a few years. No other
distribution I tried was as universal or suited my needs as well as Debian.

I don't want to bug you any longer, but again: Thank you for your great
work and keep on moving to release the best Debian ever!

Eike



signature.asc
Description: OpenPGP digital signature

Bug#395409: ITP: xfce4-mpc-plugin -- Xfce panel plugin which serves as client for MPD music player.

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: "Yves-Alexis Perez" <[EMAIL PROTECTED]>


* Package name: xfce4-mpc-plugin
  Version : 0.2.0
  Upstream Author : Landry Breuil <[EMAIL PROTECTED]>
* URL : 
http://goodies.xfce.org/projects/panel-plugins/xfce4-mpc-plugin/
* License : BSD-style, modeled after ISC licence.
  Programming Lang: C
  Description : Xfce panel plugin which serves as client for MPD music 
player.

This is a client for MPD music player which is added into a Xfce panel
as a plugin. It can control the playback and show the currently playing song.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-powerpc
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: ITP: dphys-kernel-packages -- Generate many variants of kernel packages and modules

[Daniel Baumann]

Goswin von Brederlow wrote:
> Gürkan Sengün <[EMAIL PROTECTED]> writes:
>>  Description : Generate many variants of kernel packages and modules
>>  Generates an range of kernel config files for various processors, SMP and
>>  memory size variants, Then compiles for each an kernel and an set of 
>> external
>>  kernel modules, and packages all of these as .deb packages for easy install
>>  .
>>  Homepage: http://www.phys.ethz.ch/~franklin/Projects/dphys-kernel-packages/
> 
> If you intend to upload the kernel.debs you will get a problem with
> the GPL and the security team.

Dear Goswin,

as you can read from the description, this package does not contain the
kernel, but rather a tool to generate kernel-packages on the user
machine. I don't know if this tool is usefull at all, however, your
raised problems are non-issues.

Regards,
Daniel

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


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

Re: Desktop task(sel) in Etch? (Bug #389092)

[Jari Aalto]

Joey Hess <[EMAIL PROTECTED]> writes:

> Jon Dowland wrote:
> > Hm. If you installed the gnome metapackage with aptitude,
> > then the dependencies would be marked 'auto' and removed
> > once you'd removed the manual package at the top of the
> > tree.
> 
> Or you can just tasksel remove gnome-desktop; tasksel install kde-desktop

If possible, document these commands in the help screen of the Debian
installed. Many don't know this.

Jari


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

Re: ITP: dphys-kernel-packages -- Generate many variants of kernel packages and modules

[Gürkan Sengün]

If you intend to upload the kernel.debs you will get a problem with
the GPL and the security team.


no i don't intend to upload any kernel binaries and i have no idea
where you get that impression from.


The GPL requires the right source version to be present. A
Build-Depends: linux-tree-2.6 does not do that, not even versioned to
a specific release. So very quickly the sources used to build the deb
disappear.


i know perfectly well the GNU GPL. if you had a look at the source
you would not blindly write like you do.


And the security team doesn't like, lets call it 2nd level
sources. Fixing a security bug in those kernel debs requires first
fixing the linux source package and upload that and then on a second
pass rebuild your package against the new source.


why am i even writing something to this??


Before you invest too much time please talk to the debian linux kernel
team and the security team about issues raised by your package.


pardon? what and why should i talk to the debian linux kernel team or
the security team?

yours,
guerkan


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

Re: ITP: dphys-kernel-packages -- Generate many variants of kernel packages and modules

[Goswin von Brederlow]

Gürkan Sengün <[EMAIL PROTECTED]> writes:

>> If you intend to upload the kernel.debs you will get a problem with
>> the GPL and the security team.
>
> no i don't intend to upload any kernel binaries and i have no idea
> where you get that impression from.

Sorry. Sounded like it could be doing so. You said it builds debs. Not
where/when. Obviously everything below was based on that and thus
becomes meaningless.

MfG
Goswin


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

Re: Getting package build dependencies

[Goswin von Brederlow]

Jon Dowland <[EMAIL PROTECTED]> writes:

> On Thu, Oct 26, 2006 at 01:48:45PM +0200, Goswin von
> Brederlow wrote:
>> As to your real problem. I was playing around with
>> building dummy packages (src-) on the fly from the
>> Sources file that depends on all Build-Depends.
>
> Me too!
>
>> The idea was that you would 'aptitude install src-foo' to
>> install the build-depends for foo and src-foo would be
>> flagged manual then. Removing src-foo would drop all the
>> build-depends too.
>
> I was going to generate src-foo locally and either drop the
> .deb in $(pwd) or call aptitude install on the result.
>
> I'll try and knock together a proof-of-concept...

That would require generating some 12K src-foo packages or filter
"apt* install" commands for src-foo packages and generate them on the
fly. Two things I found not so trivial. You also need the correct
md5sum for the packages file for apt* to accept your debs, so you are
back to generating all 12K src-foo packages in advance. Using a dummy
deb and wrapping dpkg-deb saves that.

Or you have to manualy create each src-foo deb when needed. That would
be simple too. A small wrapper around equivs to build the deb, then
dpkg -i and tell aptitude that it is manual.

MfG
Goswin


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

Re: How do I rebuild alternative symlinks?

[Tyler MacDonald]

I found a way to do it, but I think the solution was less than ideal:

Install "Debarnacle" from CPAN (isn't even in debian...)

Run this command:

perl -MDebian::Debarnacle::Alternatives -e 'my $i = 
Debian::Debarnacle::Alternatives->get_list; while(my($l,$r) = splice(@$i,0,2)) 
{ symlink($l,$r); print "$l $r\n"; }'

Now I have all my symlinks back... but I have a few questions still:

  1) is there a way to do this with just dpkg?

  2) if not, should there be? (update-alternatives --reinstall-all?)

  3) is it a bug or "feature" that keeps update-alternatives from installing
the symlinks in usr/bin and elsewhere if the ones in /etc/alternatives
already exist?

Thanks,
Tyler



Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> I just moved a debian installation from one system to another by mirroring
> /opt, etc, /home, /var, and /usr/local -- and then using dpkg
> --set-selections to get all the same packages installed on the new box.
> 
> Everything's gone great except for the alternatives system. For some reason,
> none of the symbolic links in /usr/bin (and i'm guessing anywhere) were
> reinstalled when I reinstalled the packages that provide them.
> 
> I see that there's a lot of state data in /var/lib/dpkg/alternatives -- is
> there any way to tell dpkg or update-alternatives to read that state data
> and make everything the way it should be, or am I going to have to
> reconfigure each alternative manually?
> 
> Thanks,
>   Tyler
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 


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

Re: Thanks!

[Christoph Berg]

Re: Eike Nicklas 2006-10-26 <[EMAIL PROTECTED]>
> So I think it is about time to send a big THANK YOU to ALL of you who
> created this great distribution. Debian was the first distribution that
> persuaded me of the advantages of linux and of free software and by now,
> it has been my favourite operating system for a few years. No other
> distribution I tried was as universal or suited my needs as well as Debian.

Hi,

thank you very much for the positive feedback. Reading all the
flamewars is quite exhausting, so your mail made my day. Thanks :)

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


signature.asc
Description: Digital signature

Re: ITP: dphys-kernel-packages -- Generate many variants of kernel packages and modules

[Gürkan Sengün]

Sorry. Sounded like it could be doing so. You said it builds debs. Not
where/when. Obviously everything below was based on that and thus
becomes meaningless.


yep. well it really builds kernel debs, and it's up to the user what he
does with them. i have no doubts debian kernel or security team
wouldn't want to support them, or anyone. but these will be useful
for people that have a wide variety of computers and they want to
"simple said" configure the linux kernel just once, and then have it
built for all varieties they have, say i586-smp, k7-4gb-smp, k8-64gb 
etc.

for now it is i386 only, but there's nothing which could stop it be
extended for other architectures.
we've been using this tool since two years, and i'm glad i can use it.
the only reason i want to maintain it for debian (and make it available
to others, that will want something like this).

yours,
guerkan


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

Re: Thanks!

[Ben Finney]

Eike Nicklas <[EMAIL PROTECTED]> writes:

> I'm not sure where to post this email, so I am sending it to this
> list.  It is totally unproductive, but still I'd like to send it :-)

Some businesses have a little sign that says: "If you don't like our
service, please tell us; if you do like our service, please tell
others!"

It's great to give positive feedback, and even better that you've done
so in public. I'd call it morale-boosting, certainly not unproductive.

-- 
 \   "Sunday School: A prison in which children do penance for the |
  `\   evil conscience of their parents."  -- Henry L. Mencken |
_o__)  |
Ben Finney


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

Re: How do I rebuild alternative symlinks?

[Jean-Christophe Dubacq]

On Thu, Oct 26, 2006 at 02:30:09PM -0700, Tyler MacDonald wrote:
> I found a way to do it, but I think the solution was less than ideal:
> 
> Install "Debarnacle" from CPAN (isn't even in debian...)

Supposing /etc/alternatives is correct, I have a script to do that:
for i in /var/lib/dpkg/alternatives/*; do
  j=$(basename $i)
  STATE=0
  while read a && [ -n "$a" ]; do
case $STATE in
  0) STATE=1
  ;;
  1) STATE=2
 mkdir -p $(dirname "$a")
 if [ -e $a -o -L $a ]; then rm -rf $a; fi
 ln -s /etc/alternatives/${j} ${a}
  ;;
  *) STATE=1
 j="$a"
esac
  done < $i
done
  for i in /var/lib/dpkg/alternatives/*; do
j=$(basename $i)
STATE=0
while read a && [ -n "$a" ]; do
  case $STATE in
 0) STATE=1
;;
 1) STATE=2
b=$(ls -lL "$a" 2>&1 >/dev/null|wc -l)
if [ "$b" -gt 0 ]; then
  rm -f "$a"; rm -f "/etc/alternatives/${j}"
fi
;;
 *) STATE=1
j="$a"
  esac
done < $i
  done

The second loop just removes dangling alternatives. I don't like them.


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

Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation

[Debian Project Secretary]

Hi,

As I count, this resolution to delay the decition of the DPL
 of the withdrawal of the Package Policy Committee delegation  has
 received 2K sponsors, which means that § 4.2.2.2 of the constitution
 to be called into action.

,
| 4. The Developers by way of General Resolution or election
|   4.1. Powers
| 3. Override any decision by the Project Leader or a Delegate.
|   4.2. Procedure
| 2. Delaying a decision by the Project Leader or their Delegate:
|  1. If the Project Leader or their Delegate, or the Technical
| Committee, has made a decision, then Developers can override
| them by passing a resolution to do so; see s4.1(3).
|  2. If such a resolution is sponsored by at least 2K Developers,
| or if it is proposed by the Technical Committee, the
| resolution puts the decision immediately on hold (provided
| that resolution itself says so).
|  4. If the decision is put on hold, an immediate vote is held to
| determine whether the decision will stand until the full vote
| on the decision is made or whether the implementation of the
| original decision will be delayed until then. There is no
| quorum for this immediate procedural vote.
`

So, an immediate procedural vote has to be held to determine
 whether the decision will stand until the full vote, on the decision
 is made or whether the implementation of the original decision
 (i.e. withdrawl of delegation from the policy delegates) will be
 delayed until then.

I am proposing the following draft ballot for this immediate
 vote, while I go about setting up the voting infrastructure.  The
 vote page containing the details of this general resolution is not
 yet up, but as soon as it is it would be found at:
   http://www.debian.org/vote/2006/vote_008



manoj

`This is a DRAFT ballot. Voting is not yet open.
==

 Voting period starts  00:00:01 UTC on Friday, 28 Oct 2006
 Votes must be received by 23:59:59 UTC on Friday, 10 Nov 2006

The following DRAFT ballot is for voting on a immediate procedural vote to
determine if the Debian project Leaders decision to un-delegate policy
delegates remain on hold until the full vote is called, in accordance
with section 4.2.2.4 of the Debian constitution. The vote is being
conducted in accordance with the policy delineated in Section A,
Standard Resolution Procedure, of the Debian Constitution.

You may see the constitution at http://www.debian.org/devel/constitution.
For voting questions contact [EMAIL PROTECTED]

HOW TO VOTE

Please read the debian-vote@lists.debian.org mailing lists for details
on why this procedural vote is being called.  

Do not erase anything between the lines below and do not change the
choice names.

In the brackets next to your preferred choice, place a 1. Place a 2 in
the brackets next to your next choice.  Do not enter a number smaller
than 1 or larger than 2.  You may skip numbers.  You may rank options
equally (as long as all choices X you make fall in the range 1<= X <=
2).

To vote "no, no matter what" rank "Further discussion" as more
desirable than the unacceptable choices, or You may rank the "Further
discussion" choice, and leave choices you consider unacceptable
blank. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices. (Note: if the Further
Discussion choice is unranked, then it is equal to all other unranked
choices, if any -- no special consideration is given to the Further
discussion choice by the voting software).

Then mail the ballot to: [EMAIL PROTECTED]  Don't worry
about spacing of the columns or any quote characters (">") that your
reply inserts. NOTE: The vote must be GPG signed (or PGP signed) (or
encrypted) with your key that is in the Debian keyring.

- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
2808c3bb-6d17-49b6-98c8-c6a0a24bc686
[   ] Choice 1: The DPLs decision remains on hold until the full vote
[   ] Choice 2: Further discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-


--

The responses to a valid vote shall be signed Devotee (DEbian VOTe
EnginE) using by the vote key created for this vote. The public key
for the vote, signed by the Project secretary, is appended below.

-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.5 (GNU/Linux)

mQGiBEVBK6wRBACsbjlsanpIl1F4IT6sWiML/khpUQjqtywggKt9hG0k4XpCIvsZ
YzioNdJyzODLCTCZWmmUEA1P5mSPKPosvqopp967wpF0fyu2TLoTNJnCsDCnSz3q
aofhlAF1LaOwfLDRpNFCW2J7bE+ELWBUhbPCN86T0D0ElelIvJvlR+maSwCgicvT
ClbqL2WuiYkLSLhnIk6BmI0D/Rd2ZO1/wXuWmYHacD1rOxKVxk8Zn5/1zDE+VaL1
K2ZYMdDCZMojxjncEtEQU3oKDuKwggSn/lYfXsNNEaeqafNnIDMpNlYT86IQiTnl
979uKKiEuRYA3t6GtoquPX0g3BoRwgeDrNUmyWD+a+FWop/YqkkBJfz+mcd

Linux 2.6.18 & etch

[Brian May]

Hello,

Is there any chance 2.6.18 will make it into etch to solve bugs like
#391448 and #389803?

Thanks.
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: Thanks!

[Warren Turkal]

On Thursday 26 October 2006 16:42, Ben Finney wrote:
> It's great to give positive feedback, and even better that you've done
> so in public. I'd call it morale-boosting, certainly not unproductive.

I guess some of us just forget how great Debian is or get blinded by the 
vision we have that Debian will be. To all the developers, thanks for your 
tireless work on Debian itself and evangelism for the Debian cause.

Thanks,
wt
-- 
Warren Turkal


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

Uploading openssh NMU for SELinux updates as per release policy

[Manoj Srivastava]

Hi,

Three days ago, I sent in a patch in Bug#394795 which updated
 SELinux patches to bring 'em in line with currently released  SELinux
 code in Debian.  I updated that patch [0], and the binaries were
 vetted by the debian installer folks, and ack'd. I have been running
 the patched openssh binaries for over a week, and they ahve been
 available for down load for the last three days or so.

I am planning on uploading this package to the 1 day delayed
 queue,  just in case, though it qualifies for the 0 day NMU. The
 changes are the patch in the mail below, followed by autoreconf
 (autoreconf was not run before generating the patch so as to not
 drown out relevant changes in atoconf noise).

manoj


[0] 
http://bugs.debian.org/cgi-bin/bugreport.cgi/openssh-selinux.patch?bug=394795;msg=10;att=1
-- 
To stay youthful, stay useful.
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]

Work-needing packages report for Oct 27, 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: 326 (new: 2)
Total number of packages offered up for adoption: 99 (new: 1)
Total number of packages requested help for: 34 (new: 0)

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



The following packages have been orphaned:

   sarien (#394369), orphaned 6 days ago
 Description: An interpreter for old Sierra games
 Installations reported by Popcon: 59

   turkey (#395253), orphaned yesterday
 Description: dummy text generator
 Installations reported by Popcon: 45

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

   zinc-compiler (#394562), offered 5 days ago
 Description: Compiler of Zinc, a functional logic programming
   language
 Installations reported by Popcon: 8

98 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 490 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client
 Installations reported by Popcon: 59

   apt-build (#365427), requested 180 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 467

   apt-show-versions (#382026), requested 79 days ago
 Description: lists available package versions with distribution
 Installations reported by Popcon: 1922

   athcool (#278442), requested 730 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 235

   cvs (#354176), requested 245 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage
   cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (16
   more omitted)
 Installations reported by Popcon: 8315

   docbook (#358522), requested 218 days ago
 Description: standard SGML representation system for technical
   documents
 Reverse Depends: alcovebook-sgml docbook-dsssl docbook-to-man
   sgmltools-lite
 Installations reported by Popcon: 3485

   docbook-xml (#358520), requested 218 days ago
 Description: standard XML documentation system, for software and
   systems
 Reverse Depends: dblatex docbook-dsssl docbook-ebnf
   docbook-html-forms docbook-jrefentry docbook-mathml docbook-simple
   docbook-slides docbook-website docbook-xsl-stylesheets-ko (6 more
   omitted)
 Installations reported by Popcon: 10928

   dpkg (#282283), requested 705 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-src backuppc
   build-essential clamsmtp crosshurd cvs-autoreleasedeb
   cvs-buildpackage (82 more omitted)
 Installations reported by Popcon: 18106

   grub (#248397), requested 899 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: dfsbuild grub-splashimages grubconf replicator
 Installations reported by Popcon: 14442

   gtkpod (#319711), requested 459 days ago
 Description: manage songs and playlists on an Apple iPod
 Installations reported by Popcon: 449

   ispell-et (#391105), requested 22 days ago
 Description: Estonian dictionary for Aspell/Ispell/MySpell
 Installations reported by Popcon: 15

   loop-aes-modules (#385615), requested 56 days ago
 Description: loop-AES modules
 Reverse Depends: loop-aes-2.6-486 loop-aes-2.6-686
   loop-aes-2.6-686-bigmem loop-aes-2.6-alpha-generic
   loop-aes-2.6-alpha-legacy loop-aes-2.6-alpha-smp loop-aes-2.6-amd64
   loop-aes-2.6-footbridge loop-aes-2.6-iop32x loop-aes-2.6-itanium (24
   more omitted)
 Installations reported by Popcon: 38

   loop-aes-source (#385437), requested 56 days ago
 Description: loop-AES encryption Linux kernel modules (source)
 Installations reported by Popcon: 150

   loop-aes-utils (#385614), requested 56 days ago
 Description: Tools for mounting and manipulating filesystems
 Reverse Depends: loop-aes-2.6.17-2-486 loop-aes-2.6.17-2-486-di
   loop-aes-2.6.17-2-686 loop-aes-2.6.17-2-686-bigmem
   loop-aes-2.6.17-2-alpha-generic loop-aes-2.6.17-2-alpha-generic-di
   loop-aes-2.6.17-2-alpha-legacy loop-aes-2.6.17-2-alpha-smp
   loop-aes-2.6.17-2-amd64 loop-aes-2.6.17-2-amd64-di (89 more omitted)
 Installations reported by Popcon: 415

   mc (#

Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation

[Sven Luther]

On Thu, Oct 26, 2006 at 06:10:46PM -0500, Debian Project Secretary wrote:
> Hi,
> 
> As I count, this resolution to delay the decition of the DPL
>  of the withdrawal of the Package Policy Committee delegation  has
>  received 2K sponsors, which means that § 4.2.2.2 of the constitution
>  to be called into action.
> 
> ,
> | 4. The Developers by way of General Resolution or election
> |   4.1. Powers
> | 3. Override any decision by the Project Leader or a Delegate.
> |   4.2. Procedure
> | 2. Delaying a decision by the Project Leader or their Delegate:
> |  1. If the Project Leader or their Delegate, or the Technical
> | Committee, has made a decision, then Developers can override
> | them by passing a resolution to do so; see s4.1(3).
> |  2. If such a resolution is sponsored by at least 2K Developers,
> | or if it is proposed by the Technical Committee, the
> | resolution puts the decision immediately on hold (provided
> | that resolution itself says so).
> |  4. If the decision is put on hold, an immediate vote is held to
> | determine whether the decision will stand until the full vote
> | on the decision is made or whether the implementation of the
> | original decision will be delayed until then. There is no
> | quorum for this immediate procedural vote.
> `
> 
> So, an immediate procedural vote has to be held to determine
>  whether the decision will stand until the full vote, on the decision
>  is made or whether the implementation of the original decision
>  (i.e. withdrawl of delegation from the policy delegates) will be
>  delayed until then.
> 
> I am proposing the following draft ballot for this immediate
>  vote, while I go about setting up the voting infrastructure.  The
>  vote page containing the details of this general resolution is not
>  yet up, but as soon as it is it would be found at:
>http://www.debian.org/vote/2006/vote_008

Manoj, ...

You are overpassing your rights as secretary, it is not for you as secretary
to call for a vote, or take any such actions, but it is only the proposer and
the seconders who can do such.

This action of yours right now, casts more light to your abysmal behaviour on
the non-free firmware vote, where you first let the issue wait until you where
able to propose a proposal of your liking, and then hurried in to get the vote
down, thus rejecting other proposals which where better and more in line of
what debian needed, and which you didn't want.

In light of this and your actions here, i strongly propose that on issues you
have a strong interest or opinion, that someone else than you is in charge of
doing the day-to-day work of the secretary, maybe the DPL or TC would be
adequate on this here, or maybe some kind of assistant secretary either
permanent or delegated for the occasion.

Anthony, can you comment on this ? 

Friendly,

Sven Luther


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