Re: Bug#362584: ITP: xindy -- a flexible indexing system

[Jörg Sommer]

Hello Agustin,

Agustin Martin <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 18, 2006 at 05:43:12PM +, Joerg Sommer wrote:
>> % export ACLOCAL=/bin/true AMTAR=/bin/true AUTOCONF=/bin/true \
>> AUTOHEADER=/bin/true AUTOMAKE=/bin/true MAKEINFO=/bin/true
>> % dpkg-buildpackage ...
>> 
>> but this looks more like a hack. I don't know why they get recreated and
>> how to prevent this. I don't want to patch the .am files, because this is
>> not needed.
>
> For the records, I get the same problem and I have both autoconf and
> automake1.{4,7,9} installed, automake alternative pointing to automake1.9.
>
> Somebody fluent with the autotools might give a clue here.

Stephen Gran has given the answer. It's a problem of the upstream
configure.in script:
http://lists.gnupg.org/pipermail/gnutls-dev/2002-August/000345.html

Regards, Jörg.
-- 
Der Hase läuft schneller als der Fuchs,
denn der Hase läuft um sein Leben.


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

Re: Bug#362584: ITP: xindy -- a flexible indexing system

[Jörg Sommer]

Hello Frank,

Frank Küster <[EMAIL PROTECTED]> wrote:
> Joerg Sommer <[EMAIL PROTECTED]> wrote:
>
>>> Here comes the usual comment:  Please make sure to follow the Debian TeX
>>> Policy Draft in /usr/share/tex-common/.
>>
>> Xindy does not provide any tex, style or class files. 
>
> Aren't there any index style files (like the ones passed to traditional
> makeindex with the -s option)?

Yes, you can give Xindy user defined style files. But how they are
related to TeX? They are LISP.

> And aren't those searched using kpathsea?

No. They are searched by xindy internal.

>> Are there any
>> other files covered by the TeX policy?
>
> The documentation should be made available to texdoc.

I will think about it.

Have a nice weekend, Jörg.
-- 
Ein Optimist ist in der Regel ein Zeitgenosse, der ungenuegend informiert ist.
   (John B. Priestley)


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

Re: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

On Fri, 21 Apr 2006, Mike Hommey wrote:
> > - when the maintainer changes, we logically need to unsubcribe the previous.
> >   So this must be recorded somewhere. (it's not a subscription like the
> >   others)
> 
> Isn't that a non issue if you subscribe @p.d.o ?

I didn't thought of subscribing this email. In this case, yes it's a non
issue but you have different issue: if the first maintainer changes the
default keyword he chooses to receive, then the second maintainer won't
know it and may not receive everything that he expect to receive.

We would still need a way to reset the set of keyword of this email when
the maintainer changes.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

On Sat, 22 Apr 2006, Andreas Metzler wrote:
> I guess more people are interested in that, but this should be
> different keyword triggered when debian-release marks a package for
> bin-NMU, but not for the >10 separate uploads.

I tend to agree. In fact I have a wishlist bug to show the bin-nmu on the
web interface already.

> cu andreas
> [1] I am interested when they do not build package, of course. ;-)

I wanted to do that from the very first day of the PTS but Ryan Murray
never agreed to send mails on failed build. He said that many
compilations fail because of a (temporarily) broken buildd and that
it would generate too many error messages for nothing because the
maintainer can't help fix the buildd issue.

I don't know if the situation improved in the last 3 years, would it be
more reasonable to do that nowadays?

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Bug#361418: [Proposal] new Debian menu structure

[Bill Allombert]

On Fri, Apr 21, 2006 at 10:13:53AM +0100, Jon Dowland wrote:
> At 1145044383 past the epoch, Linas ??virblis wrote:
> > Manoj Srivastava wrote:
> > 
> > > Amateur radio is the dumb name, for people who
> > > are confused by what the practioners call it --
> > > HAM radio.
> > 
> > It is translated as "amateur radio" to some languages.
> > Others translate it entirely to something specific to that
> > language. And some use HAM.
> > 
> > Can you claim that HAM is the most common name for this
> > worldwide?
> 
> One advantage of specifying this in the menu policy is ease
> of translations (whereas previously, the hints system was
> impossible to translate). Therefore, if it is referred to
> predominantly as "Ham Radio" in one locale and "Amateur
> Radio" in another, could we not accommodate both?

Of course we can. We have separated translation for pt and pt_BR, zh_CN
and zh_TW already. Adding en_US, en_GB, etc. translations is a trivial
matter.

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: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

On Sat, 22 Apr 2006, Simon Huggins wrote:
> On Fri, Apr 21, 2006 at 03:46:36PM +0200, Raphael Hertzog wrote:
> > On Fri, 21 Apr 2006, Simon Huggins wrote:
> > > I'll go look at adding the PTS to pkg-xfce now anyway.
> > Thanks!
> 
> Except as discussed on IRC in #alioth it sends to the first package
> affected if many packages are so I've not added this in yet.
> 
> We're sending to our list (as we have been for ages) for now.

Please send to both the PTS and the list. You can use separate group for
the PTS and for the commit list to be sure to miss absolutely nothing.

[bysource]
for_repos = (.*/|)svn/(?P[^/]+)$
for_paths = (desktop/trunk|goodies)/(?P[^/]+)/
bcc_addr = %(package)[EMAIL PROTECTED]
to_fake = %(package)[EMAIL PROTECTED]
show_nonmatching_paths = ignore

[mailinglist]
for_repos = (.*/|)svn/(?P[^/]+)$
for_paths = .*
to_addr = [EMAIL PROTECTED]

This way the PTS may miss some commits done over several packages but the
mailing list will not.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge

[Manoj Srivastava]

On 21 Apr 2006, Loïc Minier spake thusly:

> Hi,
>
> On Fri, Apr 21, 2006, Manoj Srivastava wrote:
>> Here is my solution for using vim + script as a pager; similar
>> mechanisms can be used to use plain vim as PAGER as well.
>
> Nice, I suggest filing a new bug against vim to propose this as a
> contrib script, or to ship it as "vim-pager" wrapper.
>
> #363250 is more about documenting the semantics of $PAGER (whether
> it can uses sh syntax, or whether it's a command with parameters
> separated with spaces), to be documented in man man, and/or policy.


Err, we should define how it behaves, not what is inside
 it. As long as one can pipe things to $PAGER or use $PAGER on a file,
 what it contains should not matter.

The safe bet would be for $PAGER to be a script or executable
 which can handle reading from file or STDIN, like proper UNIX
 programs.

To make life easier for people writing programs which deal
 with $PAGER, and  are using the POSIX exce* set of calls, one may
 constrain $PAGER to "path [arg [arg ..]]", with no pipes or other
 shell meta-characters.

manoj
-- 
"'Tis not too late to seek a newer world." Alfred, Lord Tennyson
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: Guidelines for packaging projects on Alioth

[Mike Hommey]

On Sat, Apr 22, 2006 at 09:38:53AM +0200, Raphael Hertzog
<[EMAIL PROTECTED]> wrote:
> On Fri, 21 Apr 2006, Mike Hommey wrote:
> > > - when the maintainer changes, we logically need to unsubcribe the
> > > previous.  So this must be recorded somewhere. (it's not a
> > > subscription like the others)
> > 
> > Isn't that a non issue if you subscribe @p.d.o ?
> 
> I didn't thought of subscribing this email. In this case, yes it's a
> non issue but you have different issue: if the first maintainer
> changes the default keyword he chooses to receive, then the second
> maintainer won't know it and may not receive everything that he expect
> to receive.
> 
> We would still need a way to reset the set of keyword of this email
> when the maintainer changes.

Or have simpler rules: you can't change the set of keyword for
@p.d.o.

If a maintainer wants some special set of keyword, he can still
subscribe with his own address.

Mike


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

Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge

[Loïc Minier]

On Sat, Apr 22, 2006, Manoj Srivastava wrote:
> > #363250 is more about documenting the semantics of $PAGER (whether
> > it can uses sh syntax, or whether it's a command with parameters
> > separated with spaces), to be documented in man man, and/or policy.
> Err, we should define how it behaves, not what is inside
>  it. As long as one can pipe things to $PAGER or use $PAGER on a file,
>  what it contains should not matter.

 Please read again the original report, the submitter wanted to have a
 pipe of commands in $PAGER, he said this worked in the past, and works
 on other distros.  He did not want to simply be able to use $PAGER on a
 file or to pipe stuff to $PAGER, he wanted $PAGER to be parsed as a
 pipeline, as in sh syntax.

> The safe bet would be for $PAGER to be a script or executable
>  which can handle reading from file or STDIN, like proper UNIX
>  programs.

 This is an independent problem  First, we already have one layer of sh
 scripting with the sensible-pager program, and it would be a good
 enough place to handle the cases you mention, would people and programs
 use sensible-pager as the default pager.  Second, this doesn't define
 what should happen when someone redefines $PAGER: what if one user
 wants $PAGER to be a pipeline?

> To make life easier for people writing programs which deal
>  with $PAGER, and  are using the POSIX exce* set of calls, one may
>  constrain $PAGER to "path [arg [arg ..]]", with no pipes or other
>  shell meta-characters.

 Yes, I think this is safe, but I'd go even further and propose the
 following:
 A/ handling of pager in programs
 1/ programs should default to sensible-pager
 2/ programs should offer a way to override the default pager in some
way, for example via an environment variable called _PAGER,
or a configuration setting -- it might even be better for them to
avoid handling $PAGER, see 1/

 B/ user configuration of the pager
 When defined, $PAGER is a sh pipeline which reads its data from stdin.


 This is with the intent of moving any logic for deciding of the best
 pager to run out of each individual program requiring a pager, exactly
 as in the sensible-browser case, which can consider $BROWSER, $DISPLAY,
 x-www-browser, and www-browser to find a sensible browser.

 Manoj, how would this fit in policy?

-- 
Loïc Minier <[EMAIL PROTECTED]>
"You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04


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

Bug#364258: ITP: lzma -- Default and general compression method of 7z format in 7-Zip program

[Mohammed Adnène Trojette]

Package: wnpp
Severity: wishlist
Owner: "Mohammed Adnène Trojette" <[EMAIL PROTECTED]>


* Package name: lzma
  Version : 4.39
  Upstream Author : Igor Pavlov
* URL : http://www.7-zip.org/sdk.html
* License : LGPL
  Programming Lang: C
  Description : Default and general compression method of 7z format in 
7-Zip program

 LZMA is a compression algorithm, based on the famous Lempel Ziff
 compression method.
 .
 The main characteristics of the algorithm are very good compression,
 fast decompression, use of lot of RAM for compressio and low usage of
 RAM for decompression.
 .
 LZMA provides high compression ratio and very fast decompression, so it
 is very suitable for embedded applications. For example, it can be used
 for ROM (firmware) compressing.

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

Bug#364266: ITP: libclass-delegator-perl -- Perl module for a simple and fast object-oriented delegation

[Nacho Barrientos Arias]

Package: wnpp
Severity: wishlist
Owner: Nacho Barrientos Arias <[EMAIL PROTECTED]>

* Package name: libclass-delegator-perl
  Version : 0.06
  Upstream Author : David Wheeler <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~dwheeler/Class-Delegator-0.06/
* License : Perl
  Programming Lang: Perl
  Description : Perl module for a simple and fast object-oriented delegation

 This module provides a subset of the functionality of Damian Conway's lovely
 Class::Delegation module.
 .
 However the specification semantics of Class::Delegator differ slightly
 from those of Class::Delegation, so this module isn't a drop-in
 replacement for Class::Delegation. Read on for details.
 .
 Homepage: http://search.cpan.org/~dwheeler/

Greetings,
Nacho

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.9
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: nasty libgnutls11 bug still present (affects exim4 and libnss-ldap)

[Martijn van Oosterhout]

On 4/19/06, Daniel Hermann <[EMAIL PROTECTED]> wrote:
> At the very least, could you please reopen bug #325971 so that people
> can find out what's wrong with their server.

AIUI, anybody can reopen a bug report. It's not considered nice if the
maintainer disagrees, but as a rule, for a real bug you can just do
it.
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

Re: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

On Sat, 22 Apr 2006, Mike Hommey wrote:
> > We would still need a way to reset the set of keyword of this email
> > when the maintainer changes.
> 
> Or have simpler rules: you can't change the set of keyword for
> @p.d.o.
> 
> If a maintainer wants some special set of keyword, he can still
> subscribe with his own address.

But then he will get the mail twice. :-|

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Bug#358695: ITP: latex-utils -- utilities for LaTeX/xfig

[Nikolaus Schulz]

Hello Vincent, 

In linux.debian.devel, you wrote:
> I retry:
>
> Package name : latex-compile

Hmm, IMO the package does not actually compile latex sources; providing
Makefile snippets (and LaTeX macros for easy inclusion of xfig images)
is a different thing.  

Now I guess that xfig images are more special, while the Makefile
will probably be useful to many or most users and could thus be
considered the main service of the package.  So I'd suggest a name
expressing its linkage to Makefiles, something like latex-maker. 

> Description  : easy compiling of complexe (and simple) LaTeX documents

I'd drop that "complex (and simple)", since it's essentially a no-op,
cluttering the short description.  The ability to handle complex input
is detailed in the long description, that's fine.

If you choose to rename the package as I suggested above, it might
be appropriate to adjust the short description accordingly, to something
like "LaTeX Makefile snippets and easy xfig integration".

>  This package provides several tools that aim to simplify the
>  compilation of LaTeX documents :
>  .
>  LaTeX.mk: a make(1) snippets to help compiling LaTeX documents in

It's not providing snippets of make(1), the binary, but Makefile snippets. 

>  DVI, PDF, PS, ... format. Dependencies are automatically tracked : one
   ^
Drop that space here and in general before colons, as Frank has already
pointed it out.

Just my 2 Cent,
Nikolaus 


PS: Note that I'm not subscribed to debian-devel, but read it per
Mail-to-News-Gateway.


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

Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge

[Manoj Srivastava]

On 22 Apr 2006, Loïc Minier spake thusly:

> On Sat, Apr 22, 2006, Manoj Srivastava wrote:
 363250 is more about documenting the semantics of $PAGER (whether
>>> it can uses sh syntax, or whether it's a command with parameters
>>> separated with spaces), to be documented in man man, and/or
>>> policy.
>> Err, we should define how it behaves, not what is inside it. As
>> long as one can pipe things to $PAGER or use $PAGER on a file, what
>> it contains should not matter.
>
> Please read again the original report, the submitter wanted to have
> a pipe of commands in $PAGER, he said this worked in the past, and
> works on other distros.  He did not want to simply be able to use
> $PAGER on a file or to pipe stuff to $PAGER, he wanted $PAGER to be
> parsed as a pipeline, as in sh syntax.

I read it. I still think that my answer suffices: Put your
 pipeline in a script, and set that to PAGER.  If I have a file that I
 want the users to see, as opposed to output I create, how can I
 figure out how to use the example in the initial bug report?


There are two use cases that any pager directive must address:

1) The program is going to generate output which must be piped to
   a pager
2) The program want to send a file to the user.


>> The safe bet would be for $PAGER to be a script or executable
>> which can handle reading from file or STDIN, like proper UNIX
>> programs.
>
> This is an independent problem First, we already have one layer of
> sh scripting with the sensible-pager program, and it would be a good
> enough place to handle the cases you mention, would people and
> programs use sensible-pager as the default pager.  Second, this
> doesn't define what should happen when someone redefines $PAGER:
> what if one user wants $PAGER to be a pipeline?

If the PAGER semantics are defined to state that whatever you
 change it to must work in the two use cases, then programs that use
 PAGER directly would not have an issue.

But perhaps the policy for Debian should be for programs to
 ignore PAGER and just use sensible pager, where all the logic for
 dealing with pager goes in. I still don't see how sensible pager can
 handle the pipeline vs the non-pipeline case, though.

Barring that, policy would have to be that programs can' t
 user PAGER to work with use case 2, and must be guilty of an "useless
 use of cat" to pipe data to STDIN for PAGER.

Neither one of these is a happy prospect.

>> To make life easier for people writing programs which deal
>> with $PAGER, and  are using the POSIX exce* set of calls, one may
>> constrain $PAGER to "path [arg [arg ..]]", with no pipes or other
>> shell meta-characters.
>
> Yes, I think this is safe, but I'd go even further and propose the
> following:
> A/ handling of pager in programs
> 1/ programs should default to sensible-pager
> 2/ programs should offer a way to override the default pager in some
> way, for example via an environment variable called _PAGER,
> or a configuration setting -- it might even be better for them to
> avoid handling $PAGER, see 1/

PAGER has the benefit of being long standardized, and if we do
 not use PAGER, we are breaking user expectations.

What is the benefit of creating a PAGER clone?

> B/ user configuration of the pager When defined, $PAGER is a sh
> pipeline which reads its data from stdin.

How do programs present a text file to the user using a PAGER,
 then? cat file.txt | $PAGER?

> This is with the intent of moving any logic for deciding of the best
> pager to run out of each individual program requiring a pager,
> exactly as in the sensible-browser case, which can consider
> $BROWSER, $DISPLAY, x-www-browser, and www-browser to find a
> sensible browser.

In other words, ignore $PAGER, use sensible-pager all over,
 and let that handle it?

> Manoj, how would this fit in policy?

Not, unless these questions are answered, and we actually have
 a working implementation.

manoj
-- 
Liberty don't work as good in practice as it does in speeches. The
Best of Will Rogers
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: Guidelines for packaging projects on Alioth

[Henning Makholm]

Scripsit Raphael Hertzog <[EMAIL PROTECTED]>

> I would be in favor of a tighter integration between the PTS and the
> @packages.debian.org email address too for example.
>
> I could implement a default subscription to the PTS for package
> maintainers but you first need to solve several problems:
> - decide which keywords they will receive by default (all except bts,
>   bts-control and upload-binary is my choice, and maybe katie-other)

Perhaps we could start by only auto-subscribing the maintainer to a
currently unused keyword, say "pdo". The next step would be to start
redirecting [EMAIL PROTECTED] to that keyword.

Subsequently, services that currently send mail directly to
maintainers could be migrated one by one to send only to the PTS, and
at the same time the relevant keyword could be added to the
auto-subscribe-the-maintainer set.

(I would dearly love to do this with the testing migration notices I
send out from my "trille" cronjob. There are a handful of maintainers
who have asked for a way to opt out, which I have not got around to
hack my own implementation for).

The ideal, I think, would be to centralize in the PTS *all* automatic
emailing to maintainers, such that all everyting be opted into or out
of by a common interface.

(Hm, one may need except Katie mail that gets sent as a result of the
upload that changes the maintainer, but before the PTS gets a chance
to take note of the change. Some thought will be needed here. Perhaps
Katie ought to piggyback a "by the way, the latest maintainer is NNN"
header onto such mail it sends to the PTS - which would also allow the
PTS to take note immediately).

> - when the maintainer changes, we logically need to unsubcribe the previous.
>   So this must be recorded somewhere. (it's not a subscription like the
>   others)

This would appear to be main implementation challenge, yes, but I'm
not sure I agree with your premise.  I think I would find it tedious
to distinguish between "keywords I subscribe to as maintainer" and
"keywords I subscribe to as myself", so I would prefer a solution
where this distinction does not exist, even if it means that I have to
explicitly unsubscribe from packages I let go of.

How about a crude strategy: Whenever the maintainer of the package
changes, the new maintainer automatically gets subscribed to the
default keywords *under his own address* and *iff he has no
subscription at all to the package already*.

The old maintainer does not get unsubscribed (the may still want to
follow the package) but is sent a notice reminding him to unsubscribe
manually if he wants to get rid of the PTS mail.

This would have the advantage of simplicity, both for the implementor
_and_ for the maintainers.

> - in many cases, the maintainer doesn't want the "diff" since there's a
>   dedicated mailing list for that on alioth ... is it OK if we leave the
>   problem up to the maintainer to change the set of keyword accepted ?

That would be the point, wouldn't it? Off the top of my head, I don't
think that version diffs should be a maintainer-default keyword, for
the reason you cite. (But I'm not personally affected by the choice
either way, so my opinion may not be important).

-- 
Henning Makholm   "Larry wants to replicate all the time ... ah, no,
   all I meant was that he likes to have a bang everywhere."


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

Re: Installation is FANTASTIC!!!

[Henning Makholm]

Scripsit Wolfgang Lonien <[EMAIL PROTECTED]>

> And for those who still are complaining about the installer not being
> graphical: please, guys, there's more than your x86 machines. Keep that
> in mind. And where is the difference between a mouse click and a return
> key (yes, it's - mostly - that easy!)?

I don't care much for mouse clicks, but "80x25 characters and a 8-bit
font" is a very low common denominator for the amount of text one can
show on the screen when selecting packages or answering complex
debconf questions. The 8-bit-ness of the font is not a problem for
people installing in English, but being able to see more lines at a
time should benefit everybody who want or need more control than just
accepting all of the defaults.

-- 
Henning Makholm "The practical reason for continuing our
  system is the same as the practical reason
  for continuing anything: It works satisfactorily."


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

Re: Installation is FANTASTIC!!!

[Frans Pop]

On Saturday 22 April 2006 01:27, Henning Makholm wrote:
> I don't care much for mouse clicks, but "80x25 characters and a 8-bit
> font" is a very low common denominator for the amount of text one can
> show on the screen when selecting packages or answering complex
> debconf questions. The 8-bit-ness of the font is not a problem for
> people installing in English, but being able to see more lines at a
> time should benefit everybody who want or need more control than just
> accepting all of the defaults.

You can boot the installer with a vga=... boot option to use a higher 
resolution console. When I install on my sparc with framebuffer enabled I 
get something like 40 lines and 132 columns.


pgpz8rgiNMZkU.pgp
Description: PGP signature

Bug#364317: ITP: weather-util -- command-line tool to obtain weather conditions and forecasts

[The Fungi]

Package: wnpp
Severity: wishlist
Owner: Jeremy Stanley <[EMAIL PROTECTED]>


* Package name: weather-util
  Version : 1.1-1
  Upstream Author : Jeremy Stanley <[EMAIL PROTECTED]>
* URL : http://fungi.yuggoth.org/weather/
* License : BSD
  Programming Lang: Python
  Description : command-line tool to obtain weather conditions and forecasts

This utility is intended to provide quick access to current weather
conditions and forecasts. Presently, it is capable of providing data for
localities throughout the United States of America by retrieving and
processing METAR data from the National Oceanic and Atmospheric
Administration and forecasts from the National Weather Service.

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


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

Re: Bug#364317: ITP: weather-util -- command-line tool to obtain weather conditions and forecasts

[gregor herrmann]

On Sat, Apr 22, 2006 at 05:36:29PM +, The Fungi wrote:

> * Package name: weather-util
>   Description : command-line tool to obtain weather conditions and 
> forecasts
> 
> This utility is intended to provide quick access to current weather
> conditions and forecasts. Presently, it is capable of providing data for
> localities throughout the United States of America by retrieving and
> processing METAR data from the National Oceanic and Atmospheric
> Administration and forecasts from the National Weather Service.

You might (with your upstream hat on) take a look at (python-)pymetar,
a nice python module that can retrieve METAR data from all around the
world.

http://www.schwarzvogel.de/software-pymetar.shtml
http://packages.debian.org/python-pymetar

HTH,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  infos zur usenet-hierarchie at.*: http://www.usenet.at/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: aimee mann: Mr. Harris


signature.asc
Description: Digital signature

Re: Bug#4222: dig in the wrong package?

[Derek]

I just apt-get 
installed dnsutils on Sarge 3.1 and dig was included,
 
but I am using a NZ 
deb mirror
 
- 
derek

Re: Installation is FANTASTIC!!!

[Joey Hess]

Henning Makholm wrote:
> I don't care much for mouse clicks, but "80x25 characters and a 8-bit
> font"

The debian installer uses a unicode font on systems where the kernel
supports it (which for i386 systems, is most of them).

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#361418: [Proposal] new Debian menu structure

[Jeff Stevens]

On Fri, 2006-04-14 at 09:57 -0500, Manoj Srivastava wrote:
> Amateur radio is the dumb name, for people who are confused by
>  what the practioners call it -- HAM radio.

Perhaps, as others have suggested, this is a locale specific issue.  In
the US, you won't find "ham" in the FCC rules [1].  It's the "Amateur
Radio Service".  FEMA publications rarely use the term "ham" with the
exception of an occasional press release that uses both terms.  I often
find it necessary to to describe our activities as "amateur" *and* "ham"
radio, however "Amateur Radio" is the more formal and widely recognized.
We receive an "Amateur Radio" license from the FCC as reflected on the
actual paper and the Universal Licensing System [2].

1. http://www.arrl.org/FandES/field/regulations/news/part97/Part97.txt
2. http://wireless2.fcc.gov/UlsApp/UlsSearch/searchLicense.jsp

> > First of all, "Ham" is not a word, neither it is an acronym. It
> > roughly stands for "[H]andheld [a][m]ateur". So what does that make?
> > "Amateur (handheld amateur) radio". Makes no sense, does it?
> 
> Rubbish. This is revisionism -- HAM radio existed long before
>  the equipment could be called hand held. HAM radio operators
>  existed before WW II -- and the equipment was huge.

Yes, this is revisionism.  According to the ARRL [3] public relations
folks, the word ham predates radio itself meaning a poor (unskilled)
telegraph operator.  In the days of spark gap transmitters, commercial
radio operators would call an amateur causing interference a "ham"
meaning "a poor operator" [4].  Amateurs seized the opportunity at a new
label and the original definition is now somewhat archaic.  Amateur
Radio, however, is the more formal and widely accepted term.

3. http://www.arrl.org/
4. http://www.arrl.org/pio/bwhatis.html -- See Section 5

-Jeff
KE7FRJ






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

Re: Guidelines for packaging projects on Alioth

[Mike Hommey]

On Sat, Apr 22, 2006 at 03:29:06PM +0200, Raphael Hertzog
<[EMAIL PROTECTED]> wrote:
> On Sat, 22 Apr 2006, Mike Hommey wrote:
> > > We would still need a way to reset the set of keyword of this
> > > email when the maintainer changes.
> > 
> > Or have simpler rules: you can't change the set of keyword for
> > @p.d.o.
> > 
> > If a maintainer wants some special set of keyword, he can still
> > subscribe with his own address.
> 
> But then he will get the mail twice. :-|

He still can choose those keywords he's not subscribed to with the
@p.d.o.

Mike


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

Re: Bug#364317: ITP: weather-util -- command-line tool to obtain weather conditions and forecasts

[Jeremy Stanley]

On Sat, Apr 22, 2006 at 08:02:20PM +0200, gregor herrmann wrote:
> You might (with your upstream hat on) take a look at (python-)pymetar,
> a nice python module that can retrieve METAR data from all around the
> world.

Thanks! I actually looked at it before I started writing my util,
and it looks like a great module for doing flexible things with
METARs. All I needed was a way to display decoded equivalents in a
user-friendly format, which NOAA already provides, and needed to
retrieve the forecast data anyway. It seemed logical to just use a
consistent interface to deal with both, but if I were trying to do
something significantly more complicated, I would of course
integrate pymetar (or a similar module if others exist).
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }


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

Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge

[Loïc Minier]

Hi,

On Sat, Apr 22, 2006, Manoj Srivastava wrote:
> > Please read again the original report, the submitter wanted to have
> > a pipe of commands in $PAGER, he said this worked in the past, and
> > works on other distros.  He did not want to simply be able to use
> > $PAGER on a file or to pipe stuff to $PAGER, he wanted $PAGER to be
> > parsed as a pipeline, as in sh syntax.
> I read it. I still think that my answer suffices: Put your
>  pipeline in a script, and set that to PAGER.  If I have a file that I
>  want the users to see, as opposed to output I create, how can I
>  figure out how to use the example in the initial bug report?

 The point is that it used to work with a pipeline, as explained by the
 submitter, in the past and now it doesn't work, I later replied that it
 was never said that the content of $PAGER was following sh syntax.

 You propose a (valid) workaround, I propose to fix the policy, and to
 even actually support sh syntax (as this is trivial to do from
 sensible-pager).

> There are two use cases that any pager directive must address:
> 1) The program is going to generate output which must be piped to
>a pager
> 2) The program want to send a file to the user.

 I agree that these use cases need to be supported.

> If the PAGER semantics are defined to state that whatever you
>  change it to must work in the two use cases, then programs that use
>  PAGER directly would not have an issue.

 But, if I follow you, this would prevent pipelines.

> But perhaps the policy for Debian should be for programs to
>  ignore PAGER and just use sensible pager, where all the logic for
>  dealing with pager goes in. I still don't see how sensible pager can
>  handle the pipeline vs the non-pipeline case, though.

 Yes, I believe the policy should be changed in this way, and as I
 proposed.

 Look at the code of sensible-pager, it will call "$PAGER" if
 sensible-pager is called without any argument, and "$PAGER "
 if it's called as "sensible-pager ".  This seems good enough
 for me; if people set $PAGER to a pipeline, they might suffer from
 problems for the second case, but we can work on that.

> Barring that, policy would have to be that programs can' t
>  user PAGER to work with use case 2, and must be guilty of an "useless
>  use of cat" to pipe data to STDIN for PAGER.

 Yes, if you mean that permitting pipelines forbids programs to call
 "$PAGER $file", I agree with you.  There are multiple ways to solve
 this, but I think that whatever way is chosen should be implemented in
 sensible-pager, and we can even change our mind later, and fix only
 sensible-pager.  The contract of sensible-pager with respect to Debian
 programs should be to offer two modes of operation, the pipe of data on
 stdin mode, and the pass a file on the command line mode (matching your
 use cases 1 and 2).

> PAGER has the benefit of being long standardized, and if we do
>  not use PAGER, we are breaking user expectations.
> What is the benefit of creating a PAGER clone?

 sensible-pager is not a PAGER clone, it permits us to enhance the
 handling of $PAGER in a single place instead of changing every program
 in Debian that wants to send something to $PAGER.

 Have a look at the sensible-browser code, and at #351901 to convince
 you that there are useful things that can be done in such a nice place
 as sensible-pager.  Eg, we might send data to "yelp" if running under
 GNOME.

> > B/ user configuration of the pager When defined, $PAGER is a sh
> > pipeline which reads its data from stdin.
> How do programs present a text file to the user using a PAGER,
>  then? cat file.txt | $PAGER?

 That's a question for sensible-pager to solve, but one way is to use
 cat "$@" | $PAGER indeed.

> > This is with the intent of moving any logic for deciding of the best
> > pager to run out of each individual program requiring a pager,
> > exactly as in the sensible-browser case, which can consider
> > $BROWSER, $DISPLAY, x-www-browser, and www-browser to find a
> > sensible browser.
> In other words, ignore $PAGER, use sensible-pager all over,
>  and let that handle it?

 Yes.

> Not, unless these questions are answered, and we actually have
>  a working implementation.

 Well the current implementation works, except for pipelines.  :)

   Bye,
-- 
Loïc Minier <[EMAIL PROTECTED]>
"You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04


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

Re: libglew1: Newer upstream version is available

[Arnaud Quette]

2006/4/22, Marcelo E. Magallón <[EMAIL PROTECTED]>:
> On 4/22/06, Joost Yervante Damad <[EMAIL PROTECTED]> wrote:
>
> > An 1.3.4 package is about to be uploaded by Marcello.
>
> Actually I did upload it on Friday morning... didn't it make to the
> archive? *sigh*

seems not!

I've quickly done some work yesterday on 1.3.4. If you whish to take a
look at the diff, tell me so and I'll send you privatly.

Arnaud
--
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/

[Help] Versioning of a library

[Andreas Tille]

Hi,

I'm the maintainer of libgtkdatabox-0.2.3.0-0.  Until now there
was no request for an update of the upstream version and I had
personal reasons to stay with an outdated version.  Now I was
asked to package the latest version and the library is probably
not important enough to keep different versions and thus I will
package version 0.5.2.0 that is the latest version avialable from
http://www.eudoxos.de/gtk/gtkdatabox/ . My guess is that there
is an ABI change involved and thus I have to rename the package
to libgtkdatabox-0.5.2.0-X .  My question is: What is the right
choice for 'X' if I skipped several upstream versions inbetween?

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: [Help] Versioning of a library

[Joe Smith]

"Andreas Tille" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Hi,

I'm the maintainer of libgtkdatabox-0.2.3.0-0.  Until now there
was no request for an update of the upstream version and I had
personal reasons to stay with an outdated version.  Now I was
asked to package the latest version and the library is probably
not important enough to keep different versions and thus I will
package version 0.5.2.0 that is the latest version avialable from
http://www.eudoxos.de/gtk/gtkdatabox/ . My guess is that there
is an ABI change involved and thus I have to rename the package
to libgtkdatabox-0.5.2.0-X .  My question is: What is the right
choice for 'X' if I skipped several upstream versions inbetween?



If this is your first upload of that version then X=1.
The correct list for these types of questions is
debian-mentors. 




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

Bug#364360: ITP: kwin-style-crystal -- semi transperant window decoration

[Sune Vuorela]

Package: wnpp
Severity: wishlist
Owner: Sune Vuorela <[EMAIL PROTECTED]>


* Package name: kwin-style-crystal
  Version : 1.0.0
  Upstream Author : Sascha Hlusiak spam84 (at) gmx.de
* URL : http://www.kde-look.org/content/show.php?content=13969
* License : GPL, LGPL
  Programming Lang: QT/C++
  Description : semi transperant window decoration

Makes your top bar and rest of the window decorations of your kde
transperant, so you can see more of your lovely background image
..
And it is of course nice to look at

-- System Information:
Debian Release: unstable/experimental
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (200, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-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]

Re: [Help] Versioning of a library

[Roberto C. Sanchez]

Joe Smith wrote:
> 
> "Andreas Tille" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> 
>> Hi,
>>
>> I'm the maintainer of libgtkdatabox-0.2.3.0-0.  Until now there
>> was no request for an update of the upstream version and I had
>> personal reasons to stay with an outdated version.  Now I was
>> asked to package the latest version and the library is probably
>> not important enough to keep different versions and thus I will
>> package version 0.5.2.0 that is the latest version avialable from
>> http://www.eudoxos.de/gtk/gtkdatabox/ . My guess is that there
>> is an ABI change involved and thus I have to rename the package
>> to libgtkdatabox-0.5.2.0-X .  My question is: What is the right
>> choice for 'X' if I skipped several upstream versions inbetween?
>>
> 
> If this is your first upload of that version then X=1.
> The correct list for these types of questions is
> debian-mentors.
> 
> 

I *think* that he has enough experience with Debian to know the correct
list on which to ask a question:

http://qa.debian.org/[EMAIL PROTECTED]

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


signature.asc
Description: OpenPGP digital signature

Re: [Help] Versioning of a library

[Kurt Roeckx]

On Sat, Apr 22, 2006 at 11:10:35PM +0200, Andreas Tille wrote:
> Hi,
> 
> I'm the maintainer of libgtkdatabox-0.2.3.0-0.  Until now there
> was no request for an update of the upstream version and I had
> personal reasons to stay with an outdated version.  Now I was
> asked to package the latest version and the library is probably
> not important enough to keep different versions and thus I will
> package version 0.5.2.0 that is the latest version avialable from
> http://www.eudoxos.de/gtk/gtkdatabox/ . My guess is that there
> is an ABI change involved and thus I have to rename the package
> to libgtkdatabox-0.5.2.0-X .  My question is: What is the right
> choice for 'X' if I skipped several upstream versions inbetween?

The current library in the archive seems to be
libgtkdatabox-0.2.4.7-0, and not libgtkdatabox-0.2.3.0-0.

The currently library seems to be libgtkdatabox-0.2.4.so.7.0.0
and has an soname of libgtkdatabox-0.2.4.so.7.  I guess the the
new one will have something like libgtkdatabox-0.5.2.so.0?

I don't see what you feel the need to add this extra -X to your
library name, libgtkdatabox-0.5.2.0 should be good enough.  As
long as he changes the soname when he breaks the ABI.  And it
seems upstream even seems to change soname for every release, so
I don't see that as a problem.

However, it would be better if upstream actually didn't change
soname every release.  He seems to be using the soname as a
version, which isn't how it should get used.


Kurt


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

Re: [Help] Versioning of a library

[Henning Makholm]

Scripsit Andreas Tille <[EMAIL PROTECTED]>

> I'm the maintainer of libgtkdatabox-0.2.3.0-0.
[...]
> My guess is that there is an ABI change involved and thus I have to
> rename the package to libgtkdatabox-0.5.2.0-X .  My question is:
> What is the right choice for 'X' if I skipped several upstream
> versions inbetween?

Why do you have an -X component in the package name, if the 0.5.2.0 is
the full upstream version number? Seems superfluous to me.

-- 
Henning Makholm   "The great secret, known to internists and
 learned early in marriage by internists' wives, but
   still hidden from the general public, is that most things get
 better by themselves. Most things, in fact, are better by morning."


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

bug reopen

[Andrew Donnellan]

reopen 142164
thanks

Spammers. Mess it up for everyone,
--
Andrew Donnellan
http://andrewdonnellan.com
http://ajdlinux.blogspot.com
Jabber - [EMAIL PROTECTED]
---
Member of Linux Australia - http://linux.org.au
Debian user - http://debian.org
Get free rewards - http://ezyrewards.com/?id=23484
OpenNIC user - http://www.opennic.unrated.net

Soliciting keys for the debconf6 keysigning party in Oaxtepec

[Aníbal Monsalve Salazar]

Hello,

This is the second call for keys for the debconf6 keysigning party
in Oaxtepec.

In less than two weeks is the last date to send your key(s).

If you intend to participate in the debconf6 keysigning party in
Oaxtepec, please send your ascii armored public key as explained at
[0] or, alternatively at [2] by Saturday, 6th of May, 2006.

If you sent your key(s) and haven't received an acknowledment yet,
please look up your name at [1] or [3]. If your name is listed,
send me an email to resend you the acknowledment. If your name is
not listed, please resend your key(s).

[0] http://debconf.org/ksp/ksp-dc6.html
[1] http://debconf.org/ksp/ksp-dc6-names.html
[2] http://people.debian.org/~anibal/ksp-dc6/ksp-dc6.html
[3] http://people.debian.org/~anibal/ksp-dc6/ksp-dc6-names.html

Best Regards,

Aníbal Monsalve Salazar
-- 
http://v7w.com/anibal


signature.asc
Description: Digital signature

Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge

[Manoj Srivastava]

On 22 Apr 2006, Loïc Minier outgrape:

> On Sat, Apr 22, 2006, Manoj Srivastava wrote:
>> There are two use cases that any pager directive must address:
>> 1) The program is going to generate output which must be piped to
>> a pager
>> 2) The program want to send a file to the user.

> I agree that these use cases need to be supported.

>> But perhaps the policy for Debian should be for programs to ignore
>> PAGER and just use sensible pager, where all the logic for dealing
>> with pager goes in. I still don't see how sensible pager can handle
>> the pipeline vs the non-pipeline case, though.

> Yes, I believe the policy should be changed in this way, and as I
> proposed.

Hmm.  This could be a potentially disruptive change -- since a
 lot of programs may need to be changed in non-trivial ways.

> Look at the code of sensible-pager, it will call "$PAGER" if
> sensible-pager is called without any argument, and "$PAGER
> " if it's called as "sensible-pager ".  This
> seems good enough for me; if people set $PAGER to a pipeline, they
> might suffer from problems for the second case, but we can work on
> that.

Err, so we can't make this policy (allowing $PAGER to be a
 pipeline) until we have a solution for this, given that we have
 agreed that the two use cases for $PAGER must be  feasible.


>> Barring that, policy would have to be that programs can' t user
>> PAGER to work with use case 2, and must be guilty of an "useless
>> use of cat" to pipe data to STDIN for PAGER.

> Yes, if you mean that permitting pipelines forbids programs to call
> "$PAGER $file", I agree with you.  There are multiple ways to solve
> this, but I think that whatever way is chosen should be implemented
> in sensible-pager, and we can even change our mind later, and fix
> only sensible-pager.  The contract of sensible-pager with respect to
> Debian programs should be to offer two modes of operation, the pipe
> of data on stdin mode, and the pass a file on the command line mode
> (matching your use cases 1 and 2).

>> PAGER has the benefit of being long standardized, and if we do
>> not use PAGER, we are breaking user expectations.
>> What is the benefit of creating a PAGER clone?

> sensible-pager is not a PAGER clone, it permits us to enhance the
> handling of $PAGER in a single place instead of changing every
> program in Debian that wants to send something to $PAGER.

The point is that lots of programs already respect $PAGER,
 with varying semantics (most support $PAGER being less or more or
 something, but not all support arbitary pipelines.


>>> B/ user configuration of the pager When defined, $PAGER is a sh
>>> pipeline which reads its data from stdin.
>> How do programs present a text file to the user using a PAGER,
>> then? cat file.txt | $PAGER?

> That's a question for sensible-pager to solve, but one way is to use
> cat "$@" | $PAGER indeed.

Umm. If we are talking about making policy, we can't just make
 policy and say things are a problem for some package or the other to
 solve.

>> In other words, ignore $PAGER, use sensible-pager all over,
>> and let that handle it?
>
> Yes.
>
>> Not, unless these questions are answered, and we actually have
>> a working implementation.
>
> Well the current implementation works, except for pipelines.  :)

Since allowing pipelines seems to be the motivating factor
 here, we do need to solve that, I think.

manoj
-- 
I am here by the will of the people and I won't leave until I get my
raincoat back.- a slogan of the anarchists in Richard Kadrey's
"Metrophage"
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]

Processed: bug reopen

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reopen 142164
Bug#142164: Packages files should be in UTF-8
Bug reopened, originator not changed.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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