Bug#195481: Microsoft Qffice Pro (Vista/XP Edition) 79$, Save 999.95$ 0ff Retai|

[Larry Perry]

cheapxpsoftware . com



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

Handling of poorly maintained and useless packages

[Lucas Nussbaum]

Hi,

This mail tries to address the problem of not orphaned, poorly maintained
or useless packages in Debian. The proposal below tries to address both
cases, because they are often related. (useless packages tend to be poorly
maintained, and vice-versa).

[I originally planned to discuss this during the QA meeting. But it might
be a better idea to first start the discussion on the mailing list, so we
get a rough idea of the things that have to be discussed in the meeting.
Also, this was originally posted to [EMAIL PROTECTED] Since it didn't 
degenerate into
a flamewar, I'm posting this to -devel@ after doing some minor changes to
get opinions from a larger audience.]

Why is it bad to have those packages in Debian?
---
Some distributions have a "the more, the better" policy. I don't think
that it is what we want for Debian, because:
- we (try to) support all packages the same way. Which means we have to
  support those packages as well.
- such packages eat DD time. Bugs are filed against them when doing
  archive-wide QA, people fix RC bugs in them, etc.
- some poorly maintained packages are actually useful, and have people
  willing to take over maintenance, but it's currently difficult to
  hijack packages, especially when the maintainer is unresponsive.
- such packages eat user time: when trying to find a package doing X,
  it's better if users only have to evaluate 4 packages, instead of 6
  packages, with 2 packages being clearly inferior solutions. Even
  worse, some users might be using the inferior packages, ignoring that
  there are better alternatives.

Current status
--
Michael Ablassmeier and me filed some bugs some time ago on packages
that were good candidates for orphaning or removal from Debian. The list
can be viewed at [1]. However, we haven't orphaned/removed the packages
so far.
In 2005, Marc Brockschmidt did the same kind of bug filing, but was
brave enough to orphan/file removal requests.

Why do we need a workflow for that?
---
There's an authority problem in Debian. Even if nobody disagrees that a
package should be removed, if the maintainer is unresponsive, usually,
nobody takes the decision to remove it. Having some "rules" one could
refer to would help. Also, we have to agree on common "rules", so
everybody processes this stuff the same way. Of course, this looks like
overkill, but the resulting workflow is simple.

Proposed workflow
-
Suspicious packages are found by combining different metrics into a
scoring system:
- popcon score
- RC bugs
- number of bugs (possibly per popcon inst)
- age of last maintainer upload
- testing status (in testing? trying to migrate? for how long?)

Some additional info might also be useful:
- age of last upload
- WNPP status (O, RFH, RFA) (for how long?)
- Maintainer's MIA status
- number of packages maintained by the maintainer
- number of maintainers for the package
- is the package team maintained?

Step 1:
- Based on the scoring system, find a suspicious package.
- Review the package manually (look at bugs, etc)
- If the package needs action, file a bug:
  - severity: serious
  - explaining what are the problems with the package
  - proposing a solution (orphaning the package, or removing it
from Debian, or finding co-maintainers)
  - make it clear that, without answer, the proposed solution will
be carried out

Step 2: (when the problems haven't been solved)
- Review the package again
- Take the proposed actions

Delays and control:
---
It's important to decide on reasonable delays.
- If the procedure takes too long, it will be discouraging
- If the procedure is too short, decisions will be contested
I think that the following makes sense:
- For packages where orphaning was proposed: 50 days
- For packages where removal was proposed: 100 days
Additionally, before removals, at least one DD should second the removal
request (after reviewing the package).

Rationale: orphaning can be easily reversed in case the maintainer
suddenly wakes up again. Removal is a bit harder to reverse (need to fetch
the package from snapshot.d.n), thus the longer delay and the seconder.
 
So, what do you think about that? Any proposed changes?

[1] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=proposed-orphan,proposed-removal;[EMAIL
 
PROTECTED];nam0=Proposals;pri0=tag:proposed-removal,proposed-orphan;ttl0=Proposed%20to%20be%20removed,Proposed%20to%20be%20orphaned;nam1=Status;pri1=severity:serious,normal;ttl1=No%20answer%20yet,acknowledged;nam2=Progress;pri2=pending:pending,done;ttl2=In%20progress,Solved
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: migration and installation 50 THOUSAND machines

[Lucas Nussbaum]

On 11/10/07 at 17:58 -0700, andremachado wrote:
> What tools are suitable for some of the remaining tasks: managing
> systems, user accounts, monitoring such big deployment?

To connect to all the systems and execute commands on them, you can have
a look at taktuk and kanif (a frontend for taktuk that makes it a bit
easier to use). In general, looking at software for HPC clusters might
help.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: migration and installation 50 THOUSAND machines

[Henning Glawe]

On Fri, Oct 12, 2007 at 08:40:44AM +0200, Henning Glawe wrote:
> In my experience, a FAI setup like this scales quite well (although the
> updating frontend FAI-updater would need some improvements to scale better).

ok, a few side remarks to the scaling of "fai softupdate" style of
configuration management: In my experience, the bottlenecks are server
throughput and network bandwidth. With server I mean both the debian 
package repository accessed by apt and the SCM servers. Both can be
replicated, so this should be a non-issue: put one or more of both server
replicas into each branch office and let the local clients pull from them,
while the admin team works on the "master" servers.

-- 
c u
henning


signature.asc
Description: Digital signature

Re: Handling of poorly maintained and useless packages

[Sune Vuorela]

On 2007-10-12, Lucas Nussbaum <[EMAIL PROTECTED]> wrote:

[snip]
full ack to whatever you wrote here - and thank you for your nice work
with this.

> It's important to decide on reasonable delays.
> - If the procedure takes too long, it will be discouraging

I think that your proposed "times" falls slightly into this category.

> - If the procedure is too short, decisions will be contested
> I think that the following makes sense:
> - For packages where orphaning was proposed: 50 days

1 month

At least in cases where there is interested people in taking over, I
think we need to be able to move "faster" than 50 days. 

> - For packages where removal was proposed: 100 days

2 month
(But this one is not that important)

> So, what do you think about that? Any proposed changes?

/Sune


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

Re: Handling of poorly maintained and useless packages

[Pierre Habouzit]

On Fri, Oct 12, 2007 at 07:13:11AM +, Lucas Nussbaum wrote:
> Hi,
> 
> This mail tries to address the problem of not orphaned, poorly maintained
> or useless packages in Debian. The proposal below tries to address both
> cases, because they are often related. (useless packages tend to be poorly
> maintained, and vice-versa).

  FWIW I heartily welcome such an initiative !

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpq1M1x5mkHj.pgp
Description: PGP signature

Re: UTF-8 manual pages

[Josselin Mouette]

Le jeudi 11 octobre 2007 à 12:22 +0100, Colin Watson a écrit :
> My original plan was that UTF-8 manual pages should be installed in
> /usr/share/man/.UTF-8/ (unless your language is Chinese or
> Portuguese, just use the language code, not the country code, so for
> example French manual pages would go in /usr/share/man/fr.UTF-8/). I had
> a long discussion with Adam Borowski on debian-mentors recently in which
> he persuaded me that it was both possible and worth it to implement
> compatibility with the scheme used by e.g. Red Hat, in which manual
> pages installed in unadorned directories such as /usr/share/man/fr/ are
> assumed to be in UTF-8.

Sorry? Do you mean that in Debian this is currently not the case?

How can you expect the encoding of a file given only its language?
Anything else than a unique encoding is doomed to produce very ugly
results.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Handling of poorly maintained and useless packages

[Josselin Mouette]

Le vendredi 12 octobre 2007 à 09:13 +0200, Lucas Nussbaum a écrit :
> This mail tries to address the problem of not orphaned, poorly maintained
> or useless packages in Debian. The proposal below tries to address both
> cases, because they are often related. (useless packages tend to be poorly
> maintained, and vice-versa).

I couldn't agree more. Such a process can only improve the quality of
Debian as a whole.

> Some additional info might also be useful:
> - age of last upload
> - WNPP status (O, RFH, RFA) (for how long?)
> - Maintainer's MIA status
> - number of packages maintained by the maintainer
> - number of maintainers for the package
> - is the package team maintained?

- are there better maintained packages with similar functionality?

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: UTF-8 manual pages

[Colin Watson]

On Fri, Oct 12, 2007 at 10:00:21AM +0200, Josselin Mouette wrote:
> Le jeudi 11 octobre 2007 à 12:22 +0100, Colin Watson a écrit :
> > My original plan was that UTF-8 manual pages should be installed in
> > /usr/share/man/.UTF-8/ (unless your language is Chinese or
> > Portuguese, just use the language code, not the country code, so for
> > example French manual pages would go in /usr/share/man/fr.UTF-8/). I had
> > a long discussion with Adam Borowski on debian-mentors recently in which
> > he persuaded me that it was both possible and worth it to implement
> > compatibility with the scheme used by e.g. Red Hat, in which manual
> > pages installed in unadorned directories such as /usr/share/man/fr/ are
> > assumed to be in UTF-8.
> 
> Sorry? Do you mean that in Debian this is currently not the case?

That is correct. /usr/share/man/fr/ is historically ISO-8859-1 and we
can't go around breaking that.

> How can you expect the encoding of a file given only its language?

*shrug* It's not an ideal situation but it's what we're historically
stuck with. man has a big table of what people have historically used.

> Anything else than a unique encoding is doomed to produce very ugly
> results.

That's why I advocate putting UTF-8 manual pages in
/usr/share/man/fr.UTF-8/ to make it explicit for the future.

However, it *is* possible to detect the special case of UTF-8 vs.
practically anything else we care about fairly reliably, so manconv
implements that anyway. Files that have historically been assumed to be
ISO-8859-1 should still work fine as such. I've taken a fair amount of
care not to break this.

Do you have a practical example of something that's breaking? Your
concern is not very specific.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: Handling of poorly maintained and useless packages

[Leo "costela" Antunes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Josselin Mouette wrote:
>> Some additional info might also be useful:
>> - age of last upload
>> - WNPP status (O, RFH, RFA) (for how long?)
>> - Maintainer's MIA status
>> - number of packages maintained by the maintainer
>> - number of maintainers for the package
>> - is the package team maintained?
> 
> - are there better maintained packages with similar functionality?
> 

- - upstream status: dead, unresponsive, very active (since useless
packages can become useful very fast in the case of new software),
normal, etc

ACK to all the rest.

Cheers

- --
Leo "costela" Antunes
[insert a witty retort here]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHD2BbImLTb3rflGYRAhfNAKC/bJM9rbdU+DHc4g1UUp5J8TqeDgCeK2fW
PYUh93wWg7B6hRcd2M6GsNc=
=j9bE
-END PGP SIGNATURE-


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

Re: Handling of poorly maintained and useless packages

[Michael Biebl]

Lucas Nussbaum schrieb:
> Hi,
> 
> This mail tries to address the problem of not orphaned, poorly maintained
> or useless packages in Debian. The proposal below tries to address both
> cases, because they are often related. (useless packages tend to be poorly
> maintained, and vice-versa).

I whole heartedly agree with your proposal.

> - For packages where orphaning was proposed: 50 days
> - For packages where removal was proposed: 100 days

As sune suggested, 1 and 2 months would be enough imo.

Additionaly maybe extending the wnpp packages report with packages that
are going to be removed would give interested people a last chance to
pick such a package up.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#446387: ITP: libtest-expect-perl -- Test::Expect - Automated driving and testing of terminal-based programs

[Peter Makholm]

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


* Package name: libtest-expect-perl
  Version : 0.30
  Upstream Author : Leon Brocard, C<< <[EMAIL PROTECTED]> >>
* URL : http://search.cpan.org/dist/Test-Expect/
* License : as perl, GPL or Artistic
  Programming Lang: Perl
  Description : Automated driving and testing of terminal-based programs

 Test::Expect is a module for automated driving and testing of
 terminal-based programs.  It is handy for testing interactive programs
 which have a prompt, and is based on the same concepts as the Tcl
 Expect tool.  As in Expect::Simple, the Expect object is made
 available for tweaking.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-xen-amd64
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968) (ignored: LC_ALL set to en_DK.ISO-8859-15)



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

Re: Handling of poorly maintained and useless packages

[Kevin Mark]

On Fri, Oct 12, 2007 at 09:13:11AM +0200, Lucas Nussbaum wrote:
> Hi,
> 
> This mail tries to address the problem of not orphaned, poorly maintained
> or useless packages in Debian. The proposal below tries to address both
> cases, because they are often related. (useless packages tend to be poorly
> maintained, and vice-versa).
> 
> [I originally planned to discuss this during the QA meeting. But it might
> be a better idea to first start the discussion on the mailing list, so we
> get a rough idea of the things that have to be discussed in the meeting.
> Also, this was originally posted to [EMAIL PROTECTED] Since it didn't 
> degenerate into
> a flamewar, I'm posting this to -devel@ after doing some minor changes to
> get opinions from a larger audience.]
> 

It seems like a great idea to remove some pacakges that are not getting
the attention from the developers and are not the best they can be for
the users. I have a point to add:

If I am a user of one of these packages who may have the skill to adopt
it or may know someone who can, I may want to know about its orphaning.
At current, this is going to be noted on -devel. 

I would like a message on the user lists on _all_ orphaned packages,
maybe just a CC of the current WNPP report?

While I guess interested folks may be expected to look into maintaining
a package they use, it may not happen because they assume 'someone out
there' is doing it. But an ocassional email to the 'users of debian'
telling that something is going to be orphaned, might wake up those "out
of the loop." Any chance to get folks interested in Debian seem like a
great thing, even if its only an odd email on user list. What's a few
bytes between friends ;-)

-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|  my keyserver: subkeys.pgp.net | my NPO: cfsg.org |
|join the new debian-community.org to help Debian!  |
|___  Unless I ask to be CCd, assume I am subscribed ___|


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

Re: Handling of poorly maintained and useless packages

[Steve Greenland]

On 12-Oct-07, 02:13 (CDT), Lucas Nussbaum <[EMAIL PROTECTED]> wrote: 
> Proposed workflow
> -
> Suspicious packages are found by combining different metrics into a
> scoring system:
> - popcon score

You might need to be a little careful with this one. A package can be
quite useful to a small audience. I don't have any specific examples,
but I can imagine such a package that is stable (thus unfrequently
updated) and might well be the only source of such functionality. Of
course, such a package wouldn't have a bunch of RC bugs, either.

Regarding other comments, I think the one month/two month periods are
bit short - people do take vacations. 

Other than that, good proposal.

Steve


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


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

Re: Handling of poorly maintained and useless packages

[Giovanni Mascellani]

All'incirca Fri, 12 Oct 2007 09:13:11 +0200,  Lucas Nussbaum
<[EMAIL PROTECTED]> sembrerebbe aver scritto:

> I think that the following makes sense:
> - For packages where orphaning was proposed: 50 days
> - For packages where removal was proposed: 100 days

I am not a DD, so my opinion is not very relevant. However I'd suggest
to send the warning message at least twice before orphaning or removing
the package, because just one warning could, for some reason, be dropped
(e.g. an antispam error). There is no need to fire him a message a day,
two or three in the 50 days period (or a month, or whatever else) is
enough, I think.

Regards, Giovanni.
-- 
Giovanni Mascellani <[EMAIL PROTECTED]>
Pisa, Italy

Web: http://giomasce.altervista.org
SIP: [EMAIL PROTECTED]
Jabber: [EMAIL PROTECTED] / [EMAIL PROTECTED]
GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD  003F FCB0 BB5C 5F1F BF70)



signature.asc
Description: PGP signature

Re: Handling of poorly maintained and useless packages

[Pierre THIERRY]

Scribit Michael Biebl dies 12/10/2007 hora 15:06:
> > - For packages where orphaning was proposed: 50 days
> > - For packages where removal was proposed: 100 days
> As sune suggested, 1 and 2 months would be enough imo.

As a compromise, the delay to orphan a package could be set to 1 month
when there is someone actively wanting to adopt it, 2 months otherwise.
The delay for removal shouldn't be less than 3 months.

Chronologically,
Pierre
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature

Re: UTF-8 manual pages

[Adam Borowski]

On Thu, Oct 11, 2007 at 12:22:18PM +0100, Colin Watson wrote:
> I have uploaded man-db 2.5.0-1, which includes the following changes of
> note:
[...] 
> 
> groff does not yet support UTF-8 input, so at the moment this is
> implemented by recoding in man. For the time being, the implementation
> requires that the page be convertible to the legacy encoding for the
> language using iconv (it uses //TRANSLIT so that it will make an attempt
> at characters that aren't directly convertible, but that isn't perfect);
> so a German manual page should avoid using UTF-8 characters without an
> equivalent in ISO-8859-1. I do not expect this to be particularly
> onerous for the time being, though there are a few cases (particularly
> proper names) where it may be a problem. I ask for your patience in
> those cases. If you need to use a character not in the corresponding
> legacy encoding, then I recommend using named character escapes as
> documented in groff_char(7).

Actually, groff is _almost_ capable of supporting UTF-8.  It understands it
internally, and has problems just on input and output.  For input, a minimal
patch can be as simple as:

--- src/libs/libgroff/encoding.cc   (revision 6)
+++ src/libs/libgroff/encoding.cc   (revision 8)
@@ -369,6 +369,9 @@
   // groff 1 defines ISO-8859-1 as the input encoding, so this is required
   // for compatibility. groff 2 will define UTF-8 (or possibly officially
   // allow it to be switchable?)
+  select_input_encoding_handler("UTF-8");
+  select_output_encoding_handler("UTF-8");
+  return;
   select_input_encoding_handler("ISO-8859-1");
   select_output_encoding_handler("C");
  (no longer relevant special cases for CJK follow)

and then instead of:
source -[?]-manconv-[ISO-8859-1]-> groff -[ISO-8859-1]-iconv-[$LOCALE]-> less
 man-db could do:
source -[?]-manconv-[UTF-8]-> groff -[UTF-8]-iconv-[$LOCALE]-> less


Too bad, output is harder.  By adjusting char widths
(http://angband.pl/deb/man/groff-devutf8.diff) I've got terminal output
working neatly for everything but arabic/hebrew (not a regression), but I
have neither the time nor knowledge to fix PostScript and such.

Yet, since the current groff supports only ISO-8859-? and CJK, I guess at
least a no-regression change could be easy to do.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: UTF-8 manual pages

[Colin Watson]

On Thu, Oct 11, 2007 at 12:42:49PM -0400, Joey Hess wrote:
> I don't much like any of the switch ideas, since they would probably
> not be able to express all possible collections of man pages (given
> debhelper's current command line parser). The manpage:encoding idea
> could work, but might have ambiguity issues with man pages with colons
> in their name (perl ones have two colons, but I'll bet there are some
> with one).

Mm, yes, colon was a bad choice.

> I'd be ok with DWIM here if it worked the same way man does, perhaps
> by using manconv directly?

manconv is a bit too low-level; you have to tell it the encodings you
want to convert from and to. It can't look at where your manual page is
installed and guess likely encodings from it. I think we need a --recode
option to man that spits out a version of the source manual page in the
requested encoding, without doing .so elimination or any other kind of
preprocessing. Does that sound about right?

-- 
Colin Watson   [EMAIL PROTECTED]


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

Bug#446388: ITP: libexpect-simple-perl -- Expect::Simple - wrapper around the Expect module

[Peter Makholm]

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


* Package name: libexpect-simple-perl
  Version : 0.03
  Upstream Author : Diab Jerius ([EMAIL PROTECTED])
* URL : http://search.cpan.org/dist/Expect-Simple/
* License : GPL
  Programming Lang: Perl
  Description : wrapper around the Expect module

 Expect::Simple is a wrapper around the Expect module which
 should suffice for simple applications.  It hides most of the
 Expect machinery; the Expect object is available for tweaking if
 need be.

This is a dependency for Test::Expect, which is needed to build Devel::ebug.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-xen-amd64
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968) (ignored: LC_ALL set to en_DK.ISO-8859-15)



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

Re: UTF-8 manual pages

[Joey Hess]

Colin Watson wrote:
> > I don't much like any of the switch ideas, since they would probably
> > not be able to express all possible collections of man pages (given
> > debhelper's current command line parser). The manpage:encoding idea
> > could work, but might have ambiguity issues with man pages with colons
> > in their name (perl ones have two colons, but I'll bet there are some
> > with one).
> 
> Mm, yes, colon was a bad choice.

It's probably still possible to disambiguate, with a tight enough regexp
for /:$locale$/

> > I'd be ok with DWIM here if it worked the same way man does, perhaps
> > by using manconv directly?
> 
> manconv is a bit too low-level; you have to tell it the encodings you
> want to convert from and to. It can't look at where your manual page is
> installed and guess likely encodings from it. I think we need a --recode
> option to man that spits out a version of the source manual page in the
> requested encoding, without doing .so elimination or any other kind of
> preprocessing. Does that sound about right?

Sounds about right, and since you mentioned the coding: directive --
this is a way out of the DWIM if it doesn't DWYM, so dh_installman can
just document that as how to override its guesses.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: UTF-8 manual pages

[Antti-Juhani Kaijanaho]

On Thu, Oct 11, 2007 at 12:42:49PM -0400, Joey Hess wrote:
> The manpage:encoding idea could work, but might have ambiguity issues
> with man pages with colons in their name 

I think that's solvable by taking the last colon.  I don't think
encodings have colons in them.

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/


signature.asc
Description: Digital signature

Re: UTF-8 manual pages

[Colin Watson]

On Fri, Oct 12, 2007 at 08:51:31AM +0900, Junichi Uekawa wrote:
> Hi,
> > o Per-locale directory handling has been improved. Directories such
> >   as "fr.UTF-8" may be used for occasions when it is appropriate to
> >   specify the character set but not the country, and so a full
> >   locale name is inconvenient.
> > 
> > o There is a new "manconv" program which can try multiple possible
> >   encodings for a file, thus allowing UTF-8 manual pages to be
> >   installed in any directory even without an explicit encoding
> >   declaration.
> 
> This is cool.
> 
> A great workaround for that compatibility mess RedHat has created for US.
> 
> I assume UTF-8 / local-encoding detection can fail sometimes; which
> encoding has precedence?

You're right, it can. It's much more likely that a random non-UTF-8
document will fail to decode as UTF-8 than the other way round, so man
tries UTF-8 first and that will take precedence.

I did just notice a bug in manconv's detection which I've fixed for
2.5.1. With that bug fixed, the only circumstances in which a page will
be decoded incorrectly should be if it is not valid UTF-8 but contains
some text which looks like valid UTF-8 in the first 64KB. I don't know
of an example of this happening in practice. The only hard case you get
in practice is a very large mostly-ASCII page with some ISO-8859-1 near
the end (maybe in an author's name), and manconv handles that fine.

However, if there is still ambiguity due to this, you can either install
the page in a directory name that's explicitly tagged with an encoding
(another reason I'd like to do that by default, as otherwise we get a
few pages that are put there anyway to disambiguate) or use a coding:
declaration in the file. This is documented in manconv(1).

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: UTF-8 manual pages

[Adam Borowski]

On Fri, Oct 12, 2007 at 12:03:56PM +0100, Colin Watson wrote:
> On Fri, Oct 12, 2007 at 08:51:31AM +0900, Junichi Uekawa wrote:
> > I assume UTF-8 / local-encoding detection can fail sometimes; which
> > encoding has precedence?
> 
> You're right, it can. It's much more likely that a random non-UTF-8
> document will fail to decode as UTF-8 than the other way round, so man
> tries UTF-8 first and that will take precedence.
> 
> I did just notice a bug in manconv's detection which I've fixed for
> 2.5.1. With that bug fixed, the only circumstances in which a page will
> be decoded incorrectly should be if it is not valid UTF-8 but contains
> some text which looks like valid UTF-8 in the first 64KB. I don't know
> of an example of this happening in practice. The only hard case you get
> in practice is a very large mostly-ASCII page with some ISO-8859-1 near
> the end (maybe in an author's name), and manconv handles that fine.

I went through the whole archive a couple of months ago (except for packages
with no binary for i386), and there's not a single false positive if you
read the whole file; reading first 64KB is wrong in three cases but Colin
handled them another way.

It is possible but very unlikely that locale encoding can fail in the
future, but there are two workarounds:
1) explicitely specify the encoding
2) use UTF-8

I would like to point you to the second solution.  In fact, it's long
overdue, and I really think that debian/changelog and debian/control should
be joined by /usr/share/man/ and /usr/share/doc/ in the mandatory Unicode
club.  Preferably as of right now.

Having more than one encoding in the wild = guaranteed lossage.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Testing parallel builds

[Pierre THIERRY]

Scribit Manoj Srivastava dies 09/10/2007 hora 00:04:
> It is kinda scary that my typical ./debian/rules has a minimum of 61
> targets, and that is just the base number.  But it sure makes for
> pretty pictures :)

How did you generate those dependency graphs, BTW? I didn't find
anything relevant in the reverse dependencies of graphviz...

Curiously,
Pierre
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature

Re: UTF-8 manual pages

[Frank Lichtenheld]

On Fri, Oct 12, 2007 at 01:41:49PM +0300, Antti-Juhani Kaijanaho wrote:
> On Thu, Oct 11, 2007 at 12:42:49PM -0400, Joey Hess wrote:
> > The manpage:encoding idea could work, but might have ambiguity issues
> > with man pages with colons in their name 
> 
> I think that's solvable by taking the last colon.  I don't think
> encodings have colons in them.

Only if the encoding specification is mandatory, which would require
changing alot of packages...

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: Testing parallel builds

[Manoj Srivastava]

On Fri, 12 Oct 2007 15:34:45 +0200, Pierre THIERRY <[EMAIL PROTECTED]> said: 

> Scribit Manoj Srivastava dies 09/10/2007 hora 00:04:
>> It is kinda scary that my typical ./debian/rules has a minimum of 61
>> targets, and that is just the base number.  But it sure makes for
>> pretty pictures :)

> How did you generate those dependency graphs, BTW? I didn't find
> anything relevant in the reverse dependencies of graphviz...

Heh. It was simple:
 1) use sed to substitute '/#.*$//g' from target.mk, and pipe the output
to 
 2)  grep for ^[^^I:]+:  in targets.mk (bot tab, not : stuff, followed
 by colons and save
 3) eliminate anything that is extraneous (nothing in my case)
 4) now, you have a file full of lines like 
target target : deendency dependency (or ::)
 5) Write a little Perl script that reads that, and creates
dependencies: for each target, add a dependency as needed, so the
line above will break out into 4 dependencies.
 6) For all targets, spit out a node line
 7) for all targets, spit uout an edge line for all dependencies
 8) Go in with emacs and replace color values for different nodes, make
some filled, others not, and so on. Not too bad, really.

The interesting thing is, now I realize that my dependency graph
 is suboptimal: for example, if you wanted to do just arch-dependent or
 arch-indep packages, my new dependency graph does config for both arch
 dependenct and arch indep packages -- though only arch-dependent or
 arch-independent packages are created. This is because the dependency
 graph comes together at choke points.

I need to change my Make dependencies to allow for parrallel
 dependency lines -- so you can build just arch dependent package, or
 arch-indep packages, and not have to go through targets on the other
 side.

Would there be any interest in my final target dependency tree?
 Please let me know off-list.

manoj
-- 
History tends to exaggerate. Col. Green, "The Savage Curtain", stardate
5906.4
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#229357: Can we require build-arch/indep targets for lenny?

[Steve Langasek]

On Fri, Oct 12, 2007 at 10:49:13PM +0200, Frank Lichtenheld wrote:
> On Sat, Sep 29, 2007 at 10:09:19PM +0200, Frank Lichtenheld wrote:
> > On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
> > > Attached is a patch to dpkg which implements a check for a 'build-arch'
> > > target using 'make -f debian/rules -qn build-arch'.

> > Is there actually a defined semantic for make -qn ? The make info manual
> > states:

> > "It is an error to use more than one of these three flags [-q, -t, -n] in 
> > the same
> > invocation of `make'."
> 
> No answer? I would like to work on this, but someone would need to
> answer my questions about it...

> (explicetly sending to vorlon, too, ignoring the M-F-T)

I have no answers for you about whether there are defined semantics for this
use of make. :)

Anyway, I thought this patch was ruled out in later discussion in the
thread.

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


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Frank Lichtenheld]

On Sat, Sep 29, 2007 at 10:09:19PM +0200, Frank Lichtenheld wrote:
> On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
> > Attached is a patch to dpkg which implements a check for a 'build-arch'
> > target using 'make -f debian/rules -qn build-arch'.
> 
> Is there actually a defined semantic for make -qn ? The make info manual
> states:
> 
> "It is an error to use more than one of these three flags [-q, -t, -n] in the 
> same
> invocation of `make'."

No answer? I would like to work on this, but someone would need to
answer my questions about it...

(explicetly sending to vorlon, too, ignoring the M-F-T)

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Frank Lichtenheld]

On Fri, Oct 12, 2007 at 02:13:49PM -0700, Steve Langasek wrote:
> On Fri, Oct 12, 2007 at 10:49:13PM +0200, Frank Lichtenheld wrote:
> > No answer? I would like to work on this, but someone would need to
> > answer my questions about it...
> 
> > (explicetly sending to vorlon, too, ignoring the M-F-T)
> 
> I have no answers for you about whether there are defined semantics for this
> use of make. :)
> 
> Anyway, I thought this patch was ruled out in later discussion in the
> thread.

Hmm, it was opposed by some but I don't see a consensus reached
anywhere. Let's try to give a summary of the discussion.

So far the proposed solutions for this problem are:

1) Build-Options field

As pointed out this doesn't scale very well and there is no real way to
make it default behaviour one day. This would be the way to go though if
it only needs to be specified for few packages (either because we think
that few packages actually need build-arch support or because of the
solution I propose below, combining it with autodetection).

I'm not particulary impressed with this.

2) Standards-Version, i.e. make it 'must' in policy

This should work but it completly contradicts the past Debian standards
process (according to Lucas' numbers, the new policy would currently
only be satisfied by < 2000 packages, i.e. somewhere in the 20% region)
and would make a solution dependant on the policy team, which is currently
somewhat MIA...

It would be really nice to have a policy someday that acutally matches
reality, though.

3) Autodetection

Would be clearly the easiest solution if it works reliably.
There are some problems:
 - Works only with GNU make
 - depends on a _should_ in policy, not a _must_
   (error code)
On the other hand, according to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229357#172 it
mostly works, and most of the cases where it doesn't work seem
to be the packages fault (i.e. the binary-arch target seems to
depend on the build-indep target without actually declaring
that dependency).


BTW, the "correct" solution in any case would be to run checkbuilddeps
again if we don't find build-arch support, since we need b-d-i, too.
And *poof*, there go our buildds ;) which brings me to the last
solution which I think wasn't actually proposed:

4) Adapt policy to sbuilds behaviour

I.e. don't require b-d-i on build, but only on binary and binary-indep.



Conclusion:

I would be interested to gather some input from the interested persons
regarding their exact position. I think the following questions should
give us a good understanding or their position:
(want == 'I want it and I also think it would be possible to do')

 1) Do you want to change sbuild to actually respect policy?
 1a) (SKIP if 'no' to 1) Before lenny's release?
 2) (SKIP if 'yes' to 1) Do you want to change policy to declare sbuild's
behaviour official?
 3) Do you want for all packages to support build-arch in the
nearer future (longest lenny+1) [== policy 'must']?
 4) (SKIP if 'yes' to 3) In the farer future?
 5) Do you think autodetection can work and should be used?
 6) (SKIP if 'yes' to 5) Do you think that autodetection can
work and should be used, if packages would have the ability
to override it if they know they get detected wrong?

My answers are:
YN-NNNY

After considering all the arguments I believe that the best solution
would be to try to implement autodetection _and_ support Build-Options
to give maintainers the ability to override it. Build-Options is simply
the easiest and best-working possibility, but for good behaving packages
it should not be neccessary. And I strongly believe that after lenny's
release dpkg-buildpackage should start to check the 'correct'
build-dependencies according to policy (i.e. requiring b-d-i if
build-arch is not supported).

I would volunteer to implement the solution I propose (in the near
future) if there are enough supporters.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: Handling of poorly maintained and useless packages

[Raphael Geissert]

Kevin Mark wrote:

> On Fri, Oct 12, 2007 at 09:13:11AM +0200, Lucas Nussbaum wrote:
>> Hi,
>> 
>> This mail tries to address the problem of not orphaned, poorly maintained
>> or useless packages in Debian. The proposal below tries to address both
>> cases, because they are often related. (useless packages tend to be
>> poorly maintained, and vice-versa).
>> 
>> [I originally planned to discuss this during the QA meeting. But it might
>> be a better idea to first start the discussion on the mailing list, so we
>> get a rough idea of the things that have to be discussed in the meeting.
>> Also, this was originally posted to [EMAIL PROTECTED] Since it didn't 
>> degenerate into
>> a flamewar, I'm posting this to -devel@ after doing some minor changes to
>> get opinions from a larger audience.]
>> 
> 
> It seems like a great idea to remove some pacakges that are not getting
> the attention from the developers and are not the best they can be for
> the users. I have a point to add:
> 
> If I am a user of one of these packages who may have the skill to adopt
> it or may know someone who can, I may want to know about its orphaning.
> At current, this is going to be noted on -devel.
> 
> I would like a message on the user lists on _all_ orphaned packages,
> maybe just a CC of the current WNPP report?

I think many people wouldn't be happy to receive all those emails.
What about just running wnpp-alert once a week? you can even setup a weekly
cronjob and receive the reports in your email account ;-)

> 
> While I guess interested folks may be expected to look into maintaining
> a package they use, it may not happen because they assume 'someone out
> there' is doing it. But an ocassional email to the 'users of debian'
> telling that something is going to be orphaned, might wake up those "out
> of the loop." Any chance to get folks interested in Debian seem like a
> great thing, even if its only an odd email on user list. What's a few
> bytes between friends ;-)
> 



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

Re: Handling of poorly maintained and useless packages

[Raphael Geissert]

Steve Greenland wrote:

> On 12-Oct-07, 02:13 (CDT), Lucas Nussbaum <[EMAIL PROTECTED]>
> wrote:
>> Proposed workflow
>> -
>> Suspicious packages are found by combining different metrics into a
>> scoring system:
>> - popcon score
> 
> You might need to be a little careful with this one. A package can be
> quite useful to a small audience. I don't have any specific examples,
> but I can imagine such a package that is stable (thus unfrequently
> updated) and might well be the only source of such functionality. Of
> course, such a package wouldn't have a bunch of RC bugs, either.

I do have an example: dak.

> 
> Regarding other comments, I think the one month/two month periods are
> bit short - people do take vacations.

Talking about this topic, there should be a way for maintainers (non-DDs) to
say they are on holidays in a similar way DD's do in db.d.o

If a maintainer says he will be on holidays for two months, people could
then do NMU's if needed without having to wait a month or so to see whether
the maintainer replies or not.

> 
> Other than that, good proposal.
> 
> Steve
> 
> 



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

Packages looking for a new home (RFAs)

[Steffen Joeris]

Hi folks

Unfortunately, I have to admit that I can not give all my packages the best 
care anymore. My spare time is limited and a lot is already used for other 
debian stuff. I will try to keep up with the other packages and see how that 
goes. If I find out that they are better off without me, I will write the 
appropriate RFAs later.
For now, I ask, if someone is willing to take care of one (or more) of these 
packages:

xoscope: digital oscilloscope
#446445

k3dsurf: tool for mathematical surfaces
#446446

kalgebra: calculator based on MathML language
#446447

qliss3d: demonstration tool for Lissajous figures
#446448

dc-qt: GUI frontend for the dc protocol
#446449

Take good care of them :)

Cheers
Steffen


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