Re: congratulations to our ftp-master team

[Olaf van der Spek]

On 12/14/05, Anand Kumria <[EMAIL PROTECTED]> wrote:
> [1]: As I write this 79 NEW packages, 85 total.

With only four entries more than a month old I think it's doing fine,
especially compared to other maintainers/teams that have bugs open
months or years.

Re: congratulations to our ftp-master team

[Marc Haber]

On Wed, 14 Dec 2005 11:25:03 +1100, Anand Kumria
<[EMAIL PROTECTED]> wrote:
>I'd like to congratulate our ftp-master team on their ability to timely
>process packages progressing through the NEW queue.

Acknowledged. Debian might have problems, but NEW queue processing
surely isn't one of them (any more).

I have had a new source package (as in completely new) approved on the
day of first upload in the summer. No problem here.

Greetings
Marc

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

Re: congratulations to our ftp-master team

[Javier Fernández-Sanguino Peña]

On Wed, Dec 14, 2005 at 01:40:09AM +0100, Steinar H. Gunderson wrote:
> On Wed, Dec 14, 2005 at 11:25:03AM +1100, Anand Kumria wrote:
> > I'd like to congratulate our ftp-master team on their ability to timely
> > process packages progressing through the NEW queue.
> > 
> >  [1]
> > 
> > I think you are an excellent example of people who are too busy for Debian.
> 
> ...
> 
> In my entire involvement with Debian from the development side, I've never
> seen the NEW queue being processed as quickly as it is these days. It used to
> be irritating to me -- it isn't today.
> 
> I don't know the details of the three longest-running packages, but I assume 
> you
> asked an ftpmaster about those?

It's a long story, I asked about it in the thread starting at
http://lists.debian.org/debian-devel/2005/08/msg01510.html
but got no final answer

It *seems* [1] that ftp-master has its issues about software that *encodes*
mpeg but not about software that decodes it. Either way it makes no sense
to have a package in the queue for a year when the software (i.e. the source
code) that makes it be problematic  is readily available in other packages
and that software can be used for both encoding and decoding [2] and
there's no RC bug asking for their removal from the archive.

Also, patent issues are not listed under the "serious violations" at
http://ftp-master.debian.org/REJECT-FAQ.html

So, who knows. Not that xvidcap is critical for me, but it is somewhat
annoying to have it sitting there for no (declared) reason.

Javier

[1] Look at http://lists.debian.org/debian-devel/2005/08/msg01562.html
although Joerg says he is not speaking for the team
[2] ffmpeg, package description: multimedia player, server and *encoder*


signature.asc
Description: Digital signature

Re: congratulations to our ftp-master team

[Marc 'HE' Brockschmidt]

Anand Kumria <[EMAIL PROTECTED]> writes:
[...]
> As this post indicates, it isn't just the ftp-master team failing Debian.

Yeah, some Debian Developers suck a lot.

Hm. The ftp-team is quite good in comparision, I'd say.

Marc
-- 
BOFH #208:
Your mail is being routed through Germany ... and they're censoring
us.


pgp9GxxYhB79z.pgp
Description: PGP signature

Re: congratulations to our ftp-master team

[Thijs Kinkhorst]

On Wed, December 14, 2005 09:42, Javier Fernández-Sanguino Peña wrote:
> So, who knows. Not that xvidcap is critical for me, but it is somewhat
> annoying to have it sitting there for no (declared) reason.

While I generally agree with the other posters that NEW queue handling is
going very well, I can also understand that you're getting a bit
frustrated when ftpmaster just keeps on delaying the decision on your
package, to even over a year. It seems the queue is suffering from
starvation: a lot of effort is put in approving new packages as soon as
possible, but the "difficult" packages do not seem to make any progress.

I think the most important problem that inspires many of the frustrated
posts to debian-devel, is that people are just left uncertain. In this
particular case: the FTP-master responsible doesn't make any decision
(either approves or rejects). At least, that's the only thing that's
visible. I take from Anands post that he hasn't been informed recently
about any updates aswell.

If there are still open problems, the best thing would be to communicate
them as clearly as possible. Currently the NEW queue webpage just lists
package, age and bugs closed. Why not add a comments section where the
FTP-master can indicate what has to happen in order for it to be accepted?
The only thing we have now is some postings to this list which are many
months ago, and our own guesswork.

If the problem is that the situation is just very complicated and needs
time: I'd gladly accept for other packages to be queued for a couple of
weeks longer on this point if that would mean that the top-3 packages are
finally decided upon.


Thijs


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

Re: congratulations to our ftp-master team

[David Pashley]

On Dec 14, 2005 at 00:25, Anand Kumria praised the llamas by saying:
> I'd like to congratulate our ftp-master team on their ability to timely
> process packages progressing through the NEW queue.
> 
>  [1]
> 
> I think you are an excellent example of people who are too busy for Debian.
> 
> I must say that I am particularly impressed that you've managed to
> frustrate our users for over 1 year with the package 'xvidcap'.
> 
> Truly the works of Gods among both Debian users _and_ Debian developers.
> 
> If only more of the infrastructure teams displayed your attitude and
> dedication to volunteering for the benefit of all Debian users and
> developers.
> 
2875   + Dec 13 18:17   Debian Installer  (   0) irssi_0.8.10-1_multi.changes 
is NEW
2876   + Dec 13 23:48   Debian Installer  (   0) irssi_0.8.10-1_multi.changes 
ACCEPTED

5.5 hours for a package to make it through NEW. I think you owe some people an 
apology.

(Oh and to who ever processed irssi, thank you. Was a nice surprise to wake up 
to. :) )
-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.


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

Re: congratulations to our ftp-master team

[Petter Reinholdtsen]

[Marc Haber]
> Acknowledged. Debian might have problems, but NEW queue processing
> surely isn't one of them (any more).

I agree that the NEW processing is working quite well these days, and
is no longer the source of much frustration in debian.  The
ftp-masters are doing a great job processing new uploads in a timely
fashion. :)

But it is not doing a great job with processing a few old uploads.  I
consider it a problem that no decision have been taken on the few
really old uploads (xvidcap, rte, mplayer).  I believe the maintainer
deserve a reply and an acceptance or rejection in a predictable and
reasonable time frame.  Waiting indefinitely is not acceptable, as the
maintainer do not really know what is wrong with the packages.  So I
do not agree with your statement that there is no problem at all with
NEW processing.  But this problem is a minor one, compared to other
problems in Debian, and compared to the problems with NEW processing
earlier.


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

buildd.debian.org (was Re: buildd administration

[Nathanael Nerode]

So for various reasons the buildd.net status code is not considered ready
to be integrated on buildd.debian.org, either by its author or by its 
maintainer or by Ryan Murray.  Fine, I understand.

Well, after looking at http://buildd.debian.org/~jeroen/status/ ,
I concur that it's as good a general interface to buildd status as buildd.net, 
and much better than the http://buildd.debian.org/ interface.

(The contact addresses and machine up/down statuses are a valuable part of 
buildd.net which *isn't* there, but that's another matter entirely, which 
requires different and additional work.)

However, even though this is on the same machine, this isn't linked from the 
main http://buildd.debian.org webpage, or from the Developer's Corner.  
Meanwhile, the andrea link on http://buildd.debian.org is completely dead.  
(http://buildd.debian.org/andrea/)

I politely request that a prominent link to 
http://buildd.debian.org/~jeroen/status/ be placed on 
http://buildd.debian.org/, and that the andrea link be either fixed or 
removed.  This should take less than five minutes for someone with access to 
the web pages.

Sending to rmurray as the listed maintainer of the webpages.  Cc:ing 
debian-devel on the theory that publicizing such a request will prevent 
duplicate requests.

--
Nathanael Nerode
neroden  fastmail.fm


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

Re: congratulations to our ftp-master team

[Moritz Muehlenhoff]

Petter Reinholdtsen wrote:
> But it is not doing a great job with processing a few old uploads.  I
> consider it a problem that no decision have been taken on the few
> really old uploads (xvidcap, rte, mplayer). 

One of the FTP masters (I forgot who) once said that the best way to
help get mplayer into the archive would be to present an overview of
the patent situation surrounding MPEG and the like. ffmpeg has such
an overview in README.patents, which might serve as a good basis, as
the core library code of mplayer, ffmpeg and xvidcap is identical.
(libavcodec/libavformat)

Cheers,
Moritz


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

Re: congratulations to our ftp-master team

[Nathanael Nerode]

Yes, ftpmaster is getting efficient at the routine processing.  Congrats!  

Moritz Muehlenhoff wrote:
> Petter Reinholdtsen wrote:
>> But it is not doing a great job with processing a few old uploads.  I
>> consider it a problem that no decision have been taken on the few
>> really old uploads (xvidcap, rte, mplayer).
Indeed, the unfortunate part is the uploads which appear to have been
stalled in limbo.

> One of the FTP masters (I forgot who) once said that the best way to
> help get mplayer into the archive would be to present an overview of
> the patent situation surrounding MPEG and the like. ffmpeg has such
> an overview in README.patents, which might serve as a good basis, as
> the core library code of mplayer, ffmpeg and xvidcap is identical.
> (libavcodec/libavformat)

Hmm, good idea.  mplayer has had all of its long-standing copyright
licensing problems dealt with in recent years and debian-legal would be sad
to see that go to waste.

It looks like the packagers of mplayer and xvidcap have not been notified of
the potential problems with their packages, and *that* is disturbing.  I'm
sure Javier Fernandez-Sanguino Pen~a would be willing to do whatever's
needed with xvidcap up to and including repackaging the upstream tarball
and removing functionality, and I expect Dariush Pietrzak would do the
same.  But they haven't been *asked* to.

In contrast, Christian Marillat has been asked to and didn't, and the
exchange is a matter of record, so the same complaint cannot be made about
the ftpmasters' recent behavior regarding rte.

Communication from the ftp team regarding these packages would be very
helpful, since debian-legal didn't see any copyright problems with them,
and all the possibly-patent-encumbered code is already present in other
packages in the archive, AFAICS.

With regard to rte, the stated problem was the presence of the MPEG encoder
-- could this be the problem with the other two?  But exactly the same code
is also present in the ffmpeg package in the archive already (and in fact
any version in Debian would simply use the ffmpeg code from that package
rather than using its own copy).  So I'm not really sure what the problem
is.  Is there an unfiled serious bug in ffmpeg?  Is there a difference
between ffmpeg and the others which I don't know about (perhaps they *are*
using their own copies?)  Is the problem purely one of documentation, in
which case the ffmpeg README.patents file would be sufficient to get such
packages in?  Do the ftpmasters need help from -legal?  Which is it?

Similarly, what's wrong with xmovie (1 month)?  More importantly, has David
Martinez Moreno been *told* what's wrong?  (Given what I've heard about the
state of the upstream source, I imagine that lots and lots of things could
be wrong, but David should at least be told.)

Likewise for mozilla-firefox-adblock (2 months), new version of tidy (1
month), xplc (1 month), cvsconnect (1 month), cvssuck (1 month), libmpd (1
month); if there's something wrong with each of these packages, the
packager should know by now.  Maybe in some cases he does, but in others it
appears clear that the packager doesn't know.

-- 
ksig --random|


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

Re: apt PARALLELISM

[Martijn van Oosterhout]

2005/12/13, Henrique de Moraes Holschuh <[EMAIL PROTECTED]>:
>
> Time to devise a way to teach it about that, then.  HOW to do it is the big
> problem, though.  How should one deal with round-robin DNS mirrors which are
> supposed to be equal, but are not.   What are the failure modes to cater
> for?

I'm not sure about all the failure modes but the two I can think of would be:

1. One of the mirrors out of sync
2. One of the mirrors down

ISTM the easiest would be for apt to lookup the hostname itself and
treat the single entry as a list of entires, one for each possible
address the hostname can resolve to. If one fails, try the next. If
you randomise the order you should be able to avoid most of the
failure modes...

Have a nice day,

Re: apt PARALLELISM

[Robert Lemmen]

On Wed, Dec 14, 2005 at 01:23:17PM +0100, Martijn van Oosterhout wrote:
> ISTM the easiest would be for apt to lookup the hostname itself and
> treat the single entry as a list of entires, one for each possible
> address the hostname can resolve to. If one fails, try the next.

apt already does that as far as i understand it

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: congratulations to our ftp-master team

[Olaf van der Spek]

On 12/14/05, Nathanael Nerode <[EMAIL PROTECTED]> wrote:

> Likewise for mozilla-firefox-adblock (2 months), new version of tidy (1
> month), xplc (1 month), cvsconnect (1 month), cvssuck (1 month), libmpd (1
> month); if there's something wrong with each of these packages, the
> packager should know by now.  Maybe in some cases he does, but in others it
> appears clear that the packager doesn't know.

Shouldn't information like what's wrong be posted in public so others know too?

Re: buildd.debian.org (was Re: buildd administration

[Francesco P. Lovergine]

On Wed, Dec 14, 2005 at 05:23:48AM +, Nathanael Nerode wrote:
> (The contact addresses and machine up/down statuses are a valuable part of 
> buildd.net which *isn't* there, but that's another matter entirely, which 
> requires different and additional work.)
> 
> However, even though this is on the same machine, this isn't linked from the 
> main http://buildd.debian.org webpage, or from the Developer's Corner.  
> Meanwhile, the andrea link on http://buildd.debian.org is completely dead.  
> (http://buildd.debian.org/andrea/)
> 
> I politely request that a prominent link to 
> http://buildd.debian.org/~jeroen/status/ be placed on 
> http://buildd.debian.org/, and that the andrea link be either fixed or 
> removed.  This should take less than five minutes for someone with access to 
> the web pages.
> 

Changes in DD's corner contents should be discussed on d-www, eventually.
It already links official and unofficial urls and it seems reasonable
for listing those kinds of things.

-- 
Francesco P. Lovergine


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

Re: congratulations to our ftp-master team

[Thijs Kinkhorst]

On Wed, 2005-12-14 at 13:35 +0100, Olaf van der Spek wrote:
> On 12/14/05, Nathanael Nerode <[EMAIL PROTECTED]> wrote:
> 
> > Likewise for mozilla-firefox-adblock (2 months), new version of tidy (1
> > month), xplc (1 month), cvsconnect (1 month), cvssuck (1 month), libmpd (1
> > month); if there's something wrong with each of these packages, the
> > packager should know by now.  Maybe in some cases he does, but in others it
> > appears clear that the packager doesn't know.
> 
> Shouldn't information like what's wrong be posted in public so others know 
> too?

My proposal would be exactly like that: extend the NEW queue information
page with a comments field where FTP-master can add any comments for
packages that aren't approved or rejected when first examined. It would
just have to contain a quick note about the problems and what this
package is waiting for.


Thijs


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

Re: congratulations to our ftp-master team

[Amaya]

Thijs Kinkhorst wrote:
> My proposal would be exactly like that: extend the NEW queue
> information page with a comments field where FTP-master can add any
> comments for packages that aren't approved or rejected when first
> examined. It would just have to contain a quick note about the
> problems and what this package is waiting for.

Every ITP opens a bug, every upload stalled in NEW should close it. 
No need to extend anything, the BTS is where these comments belong,
IMHO.

-- 
 .''`.   Follow the white Rabbit - Ranty (and Lewis Carroll)
: :' :   
`. `'   Proudly running unstable Debian GNU/Linux
  `- www.amayita.com  www.malapecora.com  www.chicasduras.com


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

Re: congratulations to our ftp-master team

[Thijs Kinkhorst]

On Wed, 2005-12-14 at 14:27 +0100, Amaya wrote:
> Every ITP opens a bug, every upload stalled in NEW should close it. 
> No need to extend anything, the BTS is where these comments belong,
> IMHO.

Packages can end up in NEW for other reasons, but for the cases that are
currently the hot topic, that is indeed not relevant. I don't really
care that much how it's implemented, as long as status updates are
given.


Thijs


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

Bug#343332: ITP: libtour8 -- tournament processing library

[Al Nikolov]

Package: wnpp
Severity: wishlist


* Package name: libtour8
  Version : 0.9.6
  Upstream Author : Viktor Pavlenko <[EMAIL PROTECTED]>
* URL : http://libtour.sourceforge.net
* License : GPL
  Description : tournament processing library

 libtour is a generic tournament processing library written in
 C++. Rules, teams and schedule of a tournament are defined in the
 Scheme programming language (Guile) and given to the library as
 input. What makes libtour generic is the fact that it only expects
 the structure of a tournament be described, and does not know anything 
 else about it. Therefore it is possible to make libtour interpret 
 virtually any sporting tournament.
 .
 Scheme language seems a perfect choice for tournament definitions as it
 allows to easily intermix data and processing logic. Guile interpreter
 packaged as a library (libguile) makes it simple to mix C and Scheme
 function calls. Many thanks to the people who made Guile happen.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8


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

Re: congratulations to our ftp-master team

[Jeroen van Wolffelaar]

On Wed, Dec 14, 2005 at 11:08:52AM +0100, Moritz Muehlenhoff wrote:
> Petter Reinholdtsen wrote:
> > But it is not doing a great job with processing a few old uploads.  I
> > consider it a problem that no decision have been taken on the few
> > really old uploads (xvidcap, rte, mplayer). 
> 
> One of the FTP masters (I forgot who) once said that the best way to
> help get mplayer into the archive would be to present an overview of
> the patent situation surrounding MPEG and the like. ffmpeg has such
> an overview in README.patents, which might serve as a good basis, as
> the core library code of mplayer, ffmpeg and xvidcap is identical.
> (libavcodec/libavformat)

That would have been me:

http://lists.debian.org/debian-devel/2005/04/msg00997.html

With the additional note that I now know the answer of [6], and iirc, it
isn't even this thread, but an earlier one or two threads on the subject
ago. Oh well.

Mr. Ray has made an unofficial overview page at [1].

Anyway, there was no noteable response to my mail at all, specifically,
I cannot remember any mail to myself or to ftpmaster with insights on
the patent matter and/or efforts to simply drop it from mplayer (it
seemed as if those were not really needed at all for its function? At
least then the re-inclusion of it can be discussed later, while the
less-controversion bits are in the archive...).

--Jeroen

[1] http://people.debian.org/~mjr/legal/mplayer.html

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

Bug#343334: ITP: libparams-check-perl -- A generic input parsing/checking mechanism

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>

* Package name: libparams-check-perl
  Version : 0.23
  Upstream Author : Jos Boumans <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~kane/Params-Check-0.23/
* License : Perl: Artistic/GPL
  Description : A generic input parsing/checking mechanism

 Params::Check is a generic input parsing/checking mechanism.
 .
 It allows you to validate input via a template. The only requirement
 is that the arguments must be named.
 .
 Params::Check can do the following things for you:
  * Convert all keys to lowercase
  * Check if all required arguments have been provided
  * Set arguments that have not been provided to the default
  * Weed out arguments that are not supported and warn
about them to the user
  * Validate the arguments given by the user based on strings,
regexes, lists or even subroutines
  * Enforce type integrity if required
  

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


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

Re: congratulations to our ftp-master team

[Amaya]

Thijs Kinkhorst wrote:
> I don't really care that much how it's implemented, as long as status
> updates are given.

Sure :)


-- 
 .''`.   Follow the white Rabbit - Ranty (and Lewis Carroll)
: :' :   
`. `'   Proudly running unstable Debian GNU/Linux
  `- www.amayita.com  www.malapecora.com  www.chicasduras.com


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

Bug#343340: ITP: libtest-classapi-perl -- Perl extension for basic first-pass API testing for class trees

[Jonas Genannt]

Package: wnpp
Severity: wishlist
Owner: Jonas Genannt <[EMAIL PROTECTED]>


* Package name: libtest-classapi-perl
  Version : 1.02
  Upstream Author : Adam Kennedy <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~adamk/
* License : GPL
  Description : Perl extension for basic first-pass API testing for class 
trees

 For many APIs with large numbers of classes, it can be very useful to
 be able to do a quick once-over to make sure that classes, methods, and
 inheritance is correct, before doing more comprehensive testing.
 This module aims to provide such a capability.

New build depend for #329990

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686-smp
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: congratulations to our ftp-master team

[Thaddeus H. Black]

Thijs Kinkhorst wrote:
> If there are still open problems, the best thing would
> be to communicate them as clearly as possible.

If James Troup and Ryan Murray have made one thing
abundantly clear, it is this: as a general rule, they
will not communicate.  Not clearly, not consistently,
not but rarely, not with the Project at large.  James is
not evil, nor presumably is the mysterious Ryan.  They
probably have their reasons.

The infrastructure people who *do* communicate---Steve
Langasek, A.J. Towns and Joerg Jaspert particularly come
to mind---appear to value James' and Ryan's
collaboration.  Nevertheless, suggesting that James and
Ryan themselves communicate is obviously a non-starter.
How many years have we been suggesting this?  Continuing
to debate among ourselves how we wish James and Ryan
would communicate is demeaning to us and, presumably,
irritating to them.  It stirs up loyal friends like
Wouter Verhelst and accomplishes nothing.

Unless James unexpectedly meets a vision of light on the
road to Debian Damascus and mends his ways, the reality
appears to be as follows.

1.  Debian's infrastructure largely works rather
well, probably in significant part because of
the long volunteer hours James (and presumably
the mysterious Ryan) devote to it.

2.  Where Debian's infrastructure fails, we who
want it fixed are required to play by James'
rules: we must either work circumspectly through
James' trusted lieutenants; or we must spend
hundreds of hours hacking dak or whatever,
proving our worthiness in the hope that James
will someday let us join the Imperium's inner
circle.

3.  If James' imperial rules are unacceptable to
us, then the alternative is to change the person
in James' position.  It has been years since any
other option was credible.  We all know this.
This means dismissing James from his fortified
posts of Project power---and accepting the
potential consequences of converting a powerful
James from a difficult friend to a difficult
foe.

I am just one insignificant DD.  I do not flatter myself
that my opinion counts for much (especially given my
zero willingness to take over any of James' duties
myself, and my zero credibility to do so, even were I
willing).  Nevertheless such as it is, I personally feel
that despite good intentions James became a net
liability to the Project years ago, and that the only
good reason to retain him is that my hero Steve
Langasek---who probably will spank me for writing these
words---seems to want him.  I really, really do not want
to lose Steve, who is a bigger positive than James is a
negative.  Otherwise, the time had come for James to go,
and the way to make him go were simply to thank him
(sincerely) for his long service, to demand from him the
relevant Project root passwords, and to dismiss him from
his posts.

And if, hypothetically, James would not peaceably turn
over the root passwords?  Aye, that's always the risk
one runs in such revolutions, isn't it?  That would
hurt.  Yet the very prospect of the danger is itself the
sign that James has too much power.

Still, even now, could James not change for the better?
Probably, yes, he could.  But after all these years the
likelihood that he will is small, and at some point our
continuing to beg him to change only unmasks us as
fools.  James is our J. Edgar Hoover: he is in some ways
a good influence and in other ways a bad, but he does
not want to change and he does not want to go, and you
and I are going to have to face these facts.  It has
long been evident that further discussion with James on
the matter is futile.  Tolerate him, or dismiss him and
face the the consequences; these are our choices.

Your view may vary.  Since I am not in the Imperium's
inner circle, it would not surprise me if I had some of
the details wrong, so detailed correction is welcome;
but I think that the broad strokes of this post are
right in any case.  Perhaps you will agree.  Thanks for
reading.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]

[My preference is that this post not be reported in
the DWN.]



signature.asc
Description: Digital signature

Re: buildd administration

[Joe Smith]

"Steve Langasek" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Sun, Dec 11, 2005 at 03:46:12PM -0800, Thomas Bushnell BSG wrote:

You have failed to detail any particular difficulty that this causes,


I'm pretty sure I saw him do this already, by noting that it increases the
number of packages that the release and QA teams have to keep track of.
It's great that you're concerned about the portability of the package, but
there are 500+ open RC bugs known to be relevant to the next release, and
1300+ RC bugs all up that affect packages in unstable.  Packages with bugs
in the first category add to the release team's workload of
downgrading bugs/NMUing/pestering maintainers/removing packages; packages
with bugs in the second category add to the QA team's workload of figuring
out if maintainers are MIA, whether packages should be removed from the
archive, and so on.  Bugs in both categories make it harder for would-be
bugsquashers to sift through the bug lists to find packages that they can
usefully NMU.


Steve, I'm not sure i agree with what you are saying here, although i do 
generally agree with you.
Keep-out-of-testing bugs seem to be fairly common, Especially on packages 
that maintainers belive
are not stable enoughto possibly be included in releases.This is often found 
in convience packages
such as the weekly cvs snapshots of emacs, which proably should never be 
part of a stable release.
It sounds to me like what is needed as a tag for bugs that tells QA (you 
post noted that the release team
would ignore RC bugs on packages not in testing) that it can ignore those 
bugs.




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

Re: Debian and the desktop

[Thomas Viehmann]

Bill Allombert wrote:
>> ... generic menu entries ... SuSE ...

> What is needed at this point is a draft policy defining what will be
> the new layout and what will be the generic titles.

KDE seems to use the GenericName .desktop entry.
Probably a good starting point would be to cannibalize these, maybe?
Are there technical issues, too, or is it just the naming?

I'm sorry, but my vage recollection is that someone somewhere wanted to
have menu transitioned to desktop, but I don't think that this has ever
been done...

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

HPPA, Arm, or M68k with g++ >= 4:4.0.2-2 ?

[Jens Peter Secher]

I need to test that a package can be built with g++ >= 4:4.0.2-2 on 
HPPA, Arm, or M68k.  Is there a DD accessible machine that has a current 
version of g++ installed?


Cheers,
/JP


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

Re: HPPA, Arm, or M68k with g++ >= 4:4.0.2-2 ?

[Adeodato Simó]

* Jens Peter Secher [Wed, 14 Dec 2005 18:50:26 +0100]:

> I need to test that a package can be built with g++ >= 4:4.0.2-2 on 
> HPPA, Arm, or M68k.  Is there a DD accessible machine that has a current 
> version of g++ installed?

  paer's sid chroot.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
-- F. Nietzsche


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

Bug#206537: ITP: horde-sam -- spam module for Horde Framework

[Gregory Colpart]

Package: wnpp
Severity: wishlist
Owner: Gregory Colpart (evolix) <[EMAIL PROTECTED]>


* Package name: horde-sam
  Version : 0.1
  Upstream Author : The Horde Team <[EMAIL PROTECTED]>
* URL : http://cvs.horde.org/sam/
* License : GPL
  Description : spam module for Horde Framework

 Sam is the Horde module to write SpamAssassin or Amavisd-new
 user prefs. Rules can be stored in a variety of backends such
 as a SQL database, LDAP storage or on an FTP server.


I use Horde-SAM in production environment.
For information, horde-sam needs some works (full compatibility
with SpamAssassin 3.x, Amavisd-new LDAP driver, etc.) and I make plans
to contact upstream project for helping to hack this patches. But
even with no patch, horde-sam is usable today and that's why I
want to debianize it.

Regards,
-- 
Gregory Colpart <[EMAIL PROTECTED]>  GnuPG:1024D/C1027A0E
Evolix - Informatique et Logiciels Libres http://www.evolix.fr/



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

Bug#343368: ITP: unix2tcp -- connection forwarder that converts Unix sockets into TCP sockets

[Radu Spineanu]

Package: wnpp
Severity: wishlist
Owner: Radu Spineanu <[EMAIL PROTECTED]>


* Package name: unix2tcp
  Version : 0.8.2 
  Upstream Author : Mihai Rusu <[EMAIL PROTECTED]>
* URL : http://dizzy.roedu.net/unix2tcp/
* License : GPL
  Description : connection forwarder that converts Unix sockets into TCP 
sockets
   unix2tcp tunnels all traffic between a (remote) address/port and a
   local UNIX socket. 

-- 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.12-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

New email address

[grant]

Thanks for your message.   Unfortunately, after more than 10 years of use,
the email address "[EMAIL PROTECTED]" now receives thousands (literally) of
spam and viral emails every day.  My spam filtering service can no longer
keep up.   So, I've decided to retire the address.  Please correct your
address book and resend your mail.   My new address can be obtained by
replacing "grant" with "grg" and using the same domain, torque.net.   Sorry
for being a little cryptic, but I'd prefer that only human beings follow me
to my new address  :-) 

Thanks

Grant


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

Re: Debian and the desktop

[Bill Allombert]

On Wed, Dec 14, 2005 at 07:02:03PM +0100, Thomas Viehmann wrote:
> Bill Allombert wrote:
> >> ... generic menu entries ... SuSE ...
> 
> > What is needed at this point is a draft policy defining what will be
> > the new layout and what will be the generic titles.
> 
> KDE seems to use the GenericName .desktop entry.
> Probably a good starting point would be to cannibalize these, maybe?
> Are there technical issues, too, or is it just the naming?

There are no technical issues:

1) Make a list of all valid genericname and add it to menu-section.pot
and translate it.

2) Change the menu entries to include a genericname field that is in
the list.

3) Change the menu-method to display the genericname. One global way 
to do this is to change the function title() in 
/etc/menu-methods/menu.h to 
ifelse($genericname,$genericname "(" $title ")", $title).
but this can be done in a per-menu-method basis or debconfiscated, etc.

4) Change menu-xdg menu-method to generate multilingual .desktop
files as we do already for the .directory files

You have made 0 code changes to menu but now you have a fully i18n
genericname support in all the window managers! 

Not that menu officially support longtitle but this is not an overly
popuar feature.

However I don't have time to do that myself, but certainly I have no
objection.

But there are another way: KDE and GNOME provide a non-Debian menu.
However there are no clear definition about what should go in this menu.
Maybe the policy could be to only put in this menu the applications
relevant to "Bob User" and keep the Debian menu to "Bob Hacker". This
might be a simpler way to get the same results.

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

Imagine a large red swirl here. 


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

Re: apt PARALLELISM

[Claus Färber]

Olaf van der Spek <[EMAIL PROTECTED]> schrieb/wrote:
> That's not true. Suppose you've only got 3 users. If each user
> connects to one (different) mirror, he gets 1/1 of that mirror's
> bandwidth. If each user connects to each mirror, he only gets 1/3 of
> that mirror's bandwidth.

They could get 1/1 of each server (total 3/1) if they connect at   
different times. With three users, this needs coordination (which makes  
the effect useless). With several hundred, it only needs statistics.

Claus
-- 
http://www.faerber.muc.de



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

Re: apt PARALLELISM

[Olaf van der Spek]

On 13 Dec 2005 15:56:00 +0100, Claus Färber <[EMAIL PROTECTED]> wrote:
> Olaf van der Spek <[EMAIL PROTECTED]> schrieb/wrote:
> > That's not true. Suppose you've only got 3 users. If each user
> > connects to one (different) mirror, he gets 1/1 of that mirror's
> > bandwidth. If each user connects to each mirror, he only gets 1/3 of
> > that mirror's bandwidth.
>
> They could get 1/1 of each server (total 3/1) if they connect at
> different times.

True if you assume the users have three times the bandwidth of a
mirror (on average). A 'bit' unlikely.

> With three users, this needs coordination (which makes
> the effect useless). With several hundred, it only needs statistics.

Again only if the bottleneck is the mirror's bandwidth.

Re: Debian and the desktop

[Linas Zvirblis]

David Nusinow wrote:


What are you talking about Debian Style?


Color scheme, artwork (default wallpaper, login screen, even CD covers). 
All those little things that would make a user say "Yep, that's Debian".


Check out the windowmaker package. It has (or had as of a few years ago) a
beautiful Debian theme complete with a very nice wallpaper. Creating
similar themes for other window managers and desktop environments would be
great.


I looked into it. Is indeed interesting artwork, but for something that 
would represent Debian, it is way too personal (as in not neutral). Not 
many people would find it acceptable for day to day use. Try that 
wallpaper on a DE that has a couple (or better, a lot) of icons on the 
desktop and you will see what I mean.


The theme itself is also not too bad, but maintaining similar theme for 
different DEs might cause more problems that it would solve. Anyway, 
plain unthemed KDE and plain unthemed GNOME look pretty much alike, so 
that is no problem.



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

Re: Debian and the desktop

[Andreas Schuldei]

* Linas Zvirblis <[EMAIL PROTECTED]> [2005-12-15 00:02:01]:

> David Nusinow wrote:
> 
> >>>What are you talking about Debian Style?
> >>
> >>Color scheme, artwork (default wallpaper, login screen, even CD covers). 
> >>All those little things that would make a user say "Yep, that's Debian".
> >
> >Check out the windowmaker package. It has (or had as of a few years ago) a
> >beautiful Debian theme complete with a very nice wallpaper. Creating
> >similar themes for other window managers and desktop environments would be
> >great.
> 
> I looked into it. Is indeed interesting artwork, but for something that 
> would represent Debian, it is way too personal (as in not neutral). Not 
> many people would find it acceptable for day to day use. Try that 
> wallpaper on a DE that has a couple (or better, a lot) of icons on the 
> desktop and you will see what I mean.
> 
> The theme itself is also not too bad, but maintaining similar theme for 
> different DEs might cause more problems that it would solve. Anyway, 
> plain unthemed KDE and plain unthemed GNOME look pretty much alike, so 
> that is no problem.

so where can i have a look at this? could it please be put up
somewhere on the web?


signature.asc
Description: Digital signature

Re: Debian and the desktop

[Thomas Viehmann]

Hi,

thanks for your comments.

Bill Allombert wrote:
> But there are another way: KDE and GNOME provide a non-Debian menu.
> However there are no clear definition about what should go in this menu.
> Maybe the policy could be to only put in this menu the applications
> relevant to "Bob User" and keep the Debian menu to "Bob Hacker". This
> might be a simpler way to get the same results.
This could be a very good idea.

One of the things that are probably impossible without a decider (which
is one of the things that many Debian derivatives have and Debian does)
to single out one package for a purpose (e.g. one word processor) to
include in a simple default install/menu. Having a dozen entries with
"Text Editor" denoting applications from gedit to emacs is probably not
too cool.

As I'm into specific and possible things, though (and have two 1-item
categories in my gnome menu which I can file bugs about but maybe
maintainers should be helped to get this right):
- how about linda/lintian check for empty longtitle in menu files
  and comment in .desktop files.
  (this is used as a hint (shown when the mouse hovers over the menu
  entry) in the Debian/Gnome/KDE(?) menu)
- a linda/lintian check for categories in .desktop to match
  with freedesktop.org's register [1]
- mention .desktops in some Debian packaging documentation (which one)
  to point people to the freedesktop.org documents [2] (I missed the
  category register at first), saying something about how binding
  that is and implement some further checks in lintian
- maybe standardize on the .desktop locations

Kind regards

T.

P.S.: Could someone give me a pointer about moving to .desktop and why
it is/was considered a bad idea? (Or if it's just a not worth it/noone
has time issue...) It seems burdenful for maintainers to provide both
and they're not always well synced (I noticed that emacs21's .desktop
comment used as hint in the Gnome menu was meaningful whereas the menu
file lacked a longtitle that is used as hint in the Debian menu.)

1. http://standards.freedesktop.org/menu-spec/latest/apa.html
2. http://standards.freedesktop.org/desktop-entry-spec/latest/
   http://standards.freedesktop.org/menu-spec/latest/
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Re: Debian and the desktop

[Linas Zvirblis]

Gustavo Noronha Silva wrote:


What are you talking about Debian Style?


Color scheme, artwork (default wallpaper, login screen, even CD covers). 
All those little things that would make a user say "Yep, that's Debian".


The desktop-base package was supposed to address exactly that problem,
but there was not a lot of interest in the KDE and GNOME teams to
actually work on that.


Maybe they simply need someone to provide them with the artwork? Would 
accepting an official default wallpaper (also GDM and KDM themes) be a 
problem? I am sure there are a lot of people out there (including 
myself) that would gladly do the dirty (art)work.



I think we have managed to create some feeling on the GNOME front,
though, with a default desktop and customized splash screen. GDM lacks
integration, though.


The artwork used in GNOME is probably too dark. On an old dark monitor 
the details are almost invisible. Just a bit of my personal experience.


Every major distribution has that little something (be it only a default 
wallpaper) that makes it what it is (navy blue Mandriva, brownish 
Ubuntu), so if desktop is the goal for Debian, it should also have that.


That'd be something, but there's much more that we should think about.
This is just the top of the iceberg.


That is the whole point. People that are already busy with some other 
work should not be bothered about something that can be done independently.



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

Re: Debian and the desktop

[Linas Zvirblis]

Andreas Schuldei wrote:


so where can i have a look at this? could it please be put up
somewhere on the web?


The package is called wmaker. It is in Debian.


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

Unstable status

[Kai Hendry]

Hi there crazy Unstable users,

Kamaraju Kusumanchi has started a Wiki page where I hope to see current
(as of today) *major* (blocking) unstable upgrade issues linked from: 

http://wiki.debian.org/StatusOfUnstable

Do I need to explain why? Ok, finding out what is responsible for my
system breaking can be a chore:

http://natalian.org/archives/2005/12/14/unstable-is-just-that/

Perhaps this could be dealt with by some extra features in the BTS.

Though often while I am upgrading and I see some important bug (if the
bug has been reported!) I just install anyway (nuts, eh?), just because
I can't be bothered to read if the bug will really disrupt my system.

I don't mind fixing my system from some sort of unstable breakage. It's
just that I would like to see it easier to find the relevant
information.

Best wishes,


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

Re: buildd administration

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> I'm pretty sure I saw him do this already, by noting that it increases the
> number of packages that the release and QA teams have to keep track of.

Seems to me that packages which aren't in testing should not occupy
the release team's time at all.  Just ignore them entirely.

> Bugs in both categories make it harder for would-be bugsquashers to
> sift through the bug lists to find packages that they can usefully
> NMU.

But I *do* want bugsquashers who are able to help fix the bug to do so!

> If we suddenly decided to release etch next month, what would you do with
> this package -- keep the RC bug open because you think s390 support is more
> important, or ask for the removal of the old s390 binaries because the
> package is worth something to users of other architectures?

I would probably ask upstread and defer to his judgment.  My best
guess is that he would prefer it to be released without s390 support,
but he *really* would rather just get the support working, as would
I. 

>> You have not pointed at any documentation of maintainer policies that
>> indicates that one must clear an RC bug as soon as possible, for
>> unreleased packages, to push them into testing before the maintainer
>> thinks they are ready.
>
> Rather, it seems much more likely that we would want to push such packages
> *out* of unstable.

Really?  So now, unstable should be maintained in a releasable state
*too*?


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

Re: congratulations to our ftp-master team

[Thomas Bushnell BSG]

"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:

> In my entire involvement with Debian from the development side, I've never
> seen the NEW queue being processed as quickly as it is these days. It used to
> be irritating to me -- it isn't today.

I have the same feeling.  I would rather give *genuine*
congratulations to the ftp-master team, which seems to me to be doing
an excellent job.

I think it would be nice if the reasons for long-standing packages
hanging around in the NEW queue were documented publicly, but I do
think in these cases the maintainers actually know the reasons.


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

Bug#343403: ITP: libwww-topica-perl -- Read emails from a Topica mailing list

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise <[EMAIL PROTECTED]>

* Package name: libwww-topica-perl
  Version : 0.5
  Upstream Author : Simon Wistow <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~simonw/WWW-Topica-0.5/
* License : Perl
  Description : Read emails from a Topica mailing list

This module screen scrapes the Topica website and fetches back RFC822 text 
representations
of all the mails posted to a given list. Where possible it fills in the from, 
to and date
fields. It should be noted that in some cases it's impossible to get both the 
sender name
and their email address.

I'll need a sponsor for this module.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: apt PARALLELISM

[Wesley J. Landaker]

On Wednesday 14 December 2005 14:41, Olaf van der Spek wrote:
> On 13 Dec 2005 15:56:00 +0100, Claus Färber <[EMAIL PROTECTED]> 
wrote:
> > Olaf van der Spek <[EMAIL PROTECTED]> schrieb/wrote:
> > > That's not true. Suppose you've only got 3 users. If each user
> > > connects to one (different) mirror, he gets 1/1 of that mirror's
> > > bandwidth. If each user connects to each mirror, he only gets 1/3 of
> > > that mirror's bandwidth.
> >
> > They could get 1/1 of each server (total 3/1) if they connect at
> > different times.
>
> True if you assume the users have three times the bandwidth of a
> mirror (on average). A 'bit' unlikely.

It's not that simple; you have to count multiple users. If there are 500 
users accessing the mirror simultaneously, the mirror needs to have 500x 
the bandwidth of every user.

This isn't even taking into account the complexity of the internet routing 
in between, which can make multiple simultaneous sources faster--in actual 
wall-clock time--for the user no matter how fast or slow the user's or the 
mirror's connection is "on average".

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


pgpHrkni4PEXL.pgp
Description: PGP signature

Re: petsc_2.3.0-1_i386.changes REJECTED

[Adam C Powell IV]

Joerg,

Did you receive this email or any of this thread?  It's now more than
two weeks old, and I'd really like to upload a new PETSc 2.3.0 ASAP.  If
you didn't see it, the discussion was on debian-release, archive at
http://lists.debian.org/debian-release/2005/11/msg00107.html , then
Steve Langasek moved it to debian-devel (and I copied debian-beowulf) at
http://lists.debian.org/debian-devel/2005/11/msg00986.html

In particular, can you please reply to:

  * Strong support for versioned -dev packages, and in particular,
the PETSc alternatives system which lets admins choose between
different versions or different builds of the same version
(single/double/complex, with/without parmetis and hypre, gcc/ccc
compilers, mpich/lab MPI implementation, etc.), and PETSC_DIR
which lets user/developers choose between installed versions.
Removing the version from the -dev package would cause all
user/devs a lot of trouble during upgrades -- and the vast
majority of users are devs, 43 have -dev vs. 45 the lib.
  * Inconsistent application of the "no empty packages" rule, a rule
which is not found in policy (or if it is, please show me
where), cf. octave, python(-dev), linux-image-2.6, etc.

As mentioned, I'd be happy to remove petsc-dbg, it's petsc-dev which is
important -- and installed by 39/43 of the users of petsc2.2.0-dev
according to popcon.

Regards,
Adam

On Mon, 2005-11-28 at 15:11 -0500, Adam C Powell IV wrote:
> On Sun, 2005-11-20 at 17:50 -0800, Steve Langasek wrote:
> > On Sun, Nov 20, 2005 at 06:57:36PM -0500, Adam C Powell IV wrote:
> > > > Well, I think the factor there is that we "usually" want users to 
> > > > upgrade to
> > > > the latest kernel automatically, whereas users of petsc usually can't
> > > > auto-upgrade to the new API.
> > 
> > > Okay, then what about octave, another empty package which forced an
> > > incompatible auto-upgrade from octave2.0 to octave2.1, and now to 2.9?
> > 
> > Probably depends on how incompatible the upgrades are.
> 
> I've only worked with octave a bit, but such upgrades have bit me on all
> of the .m files I've written.  I'd say roughly similar backward
> compatibility to PETSc-linked source.  There's a larger user community
> for octave, but that's why I don't put multiple PETSc versions in Debian
> simultaneously.
> 
> > BTW, the other big reason for linux-image-2.6-$flavor metapackages is that
> > they provide a hook for debian-installer, so the installer doesn't have to
> > be futzed with in 5 places every time there's a kernel update.
> 
> Okay, fair enough.
> 
> > > And come to think of it, the python-dev python version consistency
> > > argument doesn't really apply to anyone running a single distribution,
> > > because the "python" version in that distribution is automatically
> > > identical to the "python-dev" version.  The only way this "guarantee" of
> > > the same pythonx.y-dev and python -> pythonx.y actually does anything is
> > > if an admin somehow attempts to shoehorn the woody python with the sarge
> > > python-dev onto the same system, and how likely is that?
> > 
> > So you're suggesting that people who package python tools should be ok with
> > having to update their build-dependencies as part of every python
> > transition, even when nothing else in their package needs to change?  (This
> > also has implications for backports and cross-ports, mind you...)
> 
> No, I'm merely saying that the versioning in the python dep is
> irrelevant because python-dev and python will automatically have the
> same version in every Debian release.
> 
> As for what should be OK, two scenarios: (1) empty upgrade packages are
> good, so people build-dep on python-dev, which depends on python; (2)
> empty upgrade packages are bad, so people build-dep on "python2.3-dev |
> python-dev", the latter of which is a virtual package provided by
> python*-dev.  No need to change the python-dependent package.
> 
> > > Again, the point is that these are all over Debian, and it's
> > > inconsistent to accept all but one.
> > 
> > I don't think anyone has been proposing an inconsistent guideline, here.
> > I'll grant you that these guidelines probably haven't been *applied*
> > consistently in the past, but that's not the same thing.
> 
> Makes sense.  Can someone please write the guideline somewhere,
> preferably in policy, so we can apply it?
> 
> Thanks,
> -Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


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

Re: buildd administration

[Anthony Towns]

On Wed, Dec 14, 2005 at 12:26:50PM -0500, Joe Smith wrote:
> It sounds to me like what is needed as a tag for bugs that tells QA (you 
> post noted that the release team
> would ignore RC bugs on packages not in testing) that it can ignore those 
> bugs.

If your package isn't going to be suitable for release; it should probably
be in experimental instead, which is even autobuilt these days. There's
almost no reason to have RC bugs that are open longer than a couple of
weeks these days.

Cheers,
aj



signature.asc
Description: Digital signature

Re: buildd administration

[Thomas Bushnell BSG]

Anthony Towns  writes:

> On Wed, Dec 14, 2005 at 12:26:50PM -0500, Joe Smith wrote:
>> It sounds to me like what is needed as a tag for bugs that tells QA (you 
>> post noted that the release team
>> would ignore RC bugs on packages not in testing) that it can ignore those 
>> bugs.
>
> If your package isn't going to be suitable for release; it should probably
> be in experimental instead, which is even autobuilt these days. There's
> almost no reason to have RC bugs that are open longer than a couple of
> weeks these days.

There is a big difference between "isn't going to be suitable for
release" and "isn't suitable for release yet."

Now, Anthony, I've asked you a half dozen times.  

I have been patient with your questions, despite their nasty tone.
Are you willing to join me in calling for all Debian developers to
likewise be patient and willing to answer questions about their areas
of responsibility?  Or is this all just a giant smokescreen to deflect
attention from the inexcusable way that James Troup carries himself in
this project?

Thomas


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

Re: congratulations to our ftp-master team

[Thomas Bushnell BSG]

"Thaddeus H. Black" <[EMAIL PROTECTED]> writes:

> 3.  If James' imperial rules are unacceptable to
> us, then the alternative is to change the person
> in James' position.  It has been years since any
> other option was credible.  We all know this.
> This means dismissing James from his fortified
> posts of Project power---and accepting the
> potential consequences of converting a powerful
> James from a difficult friend to a difficult
> foe.

It was my understanding that the new DPL would seriously consider this
possibility.  It seems to have been simply ignored instead.  As usual.


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

Re: petsc_2.3.0-1_i386.changes REJECTED

[Anthony Towns]

On Wed, Dec 14, 2005 at 09:29:11PM -0500, Adam C Powell IV wrote:
> Did you receive this email or any of this thread?  It's now more than
> two weeks old, and I'd really like to upload a new PETSc 2.3.0 ASAP.

So upload it? If you've replied to the REJECT message with appropriate
reasons why the REJECTion was wrong, that seems the natural thing
to do? 

Leaving a pointer to the analysis in the changelog entry ("Introduce
unversioned development packages, libpetsc-{dev,dbg} as per
http://lists.debian.org/debian-release/...";) would be helpful, but I
don't think even that's necessarily required or expected.

It's usually best just to upload stuff rather than wait for permission --
we've got plenty of procedures in place to stop bad uploads from doing
too much harm; in this case, the queue/new delay. (Not that that's an
excuse to setup a procmail script to reupload everything that gets a
REJECT or anything crazy like that...)

Cheers,
aj



signature.asc
Description: Digital signature

Re: Unstable status

[Adrian von Bidder]

On Wednesday 14 December 2005 23.31, Kai Hendry wrote:

> http://natalian.org/archives/2005/12/14/unstable-is-just-that/

Well, the topic of #debian-devel is quite a standard place to look for up to 
the minute information - and is a place developers actually update as they 
fix things or notice breakage.  Who will update this wiki page with the 
breakage-of-the-minute information?

Idea: write a script that listens for topic changes on #d-d and send mail to 
a mailing list (perhaps onnly if the topic is stable for at least 1h or so 
to avoid sending tons of emails during topic wars or typo corrections in 
quick succession.)  How would I start this?  Sorry, I don't know anything 
about IRC...

cheers
-- vbi

-- 
A printer consists of three main parts: the case, the jammed paper tray
and the blinking red light.


pgpe95VUlSbwQ.pgp
Description: PGP signature

Re: Debian and the desktop

[Sune Vuorela]

On 2005-12-12, Linas Zvirblis <[EMAIL PROTECTED]> wrote:
> A user should get the same visual feeling whether he chose GNOME or KDE 
> for his desktop, whether he decided for KDM or GDM etc. This might sound 

Why try to make kde and gnome look the same?
If it is a goal to make all Bob User desktops look the same, then why
not just skipping either gnome or kde ?

Why not try to give the possibility to Bob User and others to make their
desktops look cool instead of making it look the same ?

> Every major distribution has that little something (be it only a default 
> wallpaper) that makes it what it is (navy blue Mandriva, brownish 
> Ubuntu)
bluish kubuntu.

That leaves debian for 
greenish
yellowish
silver
red
pink

okay. let us make debian pink ;)

or silverish:
http://kde-look.org/content/show.php?content=21420

or black and nerdish (contains a semi-naked girl, so might not be
worksafe)
http://kde-look.org/content/show.php?content=32139

I like the fact that that my programs visibility feeling are so
untouched by debian as possible.
I want to paint my own apartment ;)

/Sune
Bob User, who is working on being Bob Hacker


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