Re: LSB-ize daemon without pidfile handling

2007-11-17 Thread Marc Haber
On Fri, 16 Nov 2007 14:53:47 +0100, Marc Haber
<[EMAIL PROTECTED]> wrote:
>On Wed, 14 Nov 2007 17:57:56 + (UTC), Robert Edmonds
><[EMAIL PROTECTED]> wrote:
>>Anyway, here's a (compile-tested only) patch:
>
>Which I have submitted upstream (Debian #451472). Thanks!

And which Upstream has alreay accepted and released a new version.

Greetings
Marc

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



Re: Opinions sought: mlocate appropriate for Priority: standard?

2007-11-17 Thread Andreas Metzler
Adeodato Simó <[EMAIL PROTECTED]> wrote:
> * Andreas Metzler [Thu, 15 Nov 2007 19:43:57 +0100]:
>> I would propose to simply have the GNU locate package
>> use find-daily.defaults instead of /etc/updatedb.conf.

> Sounds good. How will you handle the migration from /etc/updatedb.conf?
> How about rm'ing from findutils postinst if the md5sum matches, and
> moving it to find-daily.defaults if it doesn't? (Since dpkg will not
> remove disappeared conffiles itself.)

> And, for the same reason, remove /etc/cron.daily/find?

Hello,
I ended up doing it a little bit differently. locate's cronjob is
configured directly in /etc/cron.daily/find, findutils removes the
orphaned conffiles using
.
cu andreas
http://svn.debian.org/wsvn/pkg-findutils/branches/branch-4.3.x-exp/
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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



Re: Opinions sought: mlocate appropriate for Priority: standard?

2007-11-17 Thread Andreas Metzler
Ivan Shmakov <[EMAIL PROTECTED]> wrote:
[...]
> $ cat /usr/bin/update-locate.findutils
[...]
> $ cat /etc/cron.daily/update-locate
> #!/bin/sh
> if [ -x /usr/sbin/update-locate ]; then
>/usr/sbin/update-locate
> fi

>Or am I missing something?

The fact that people might want to change with which options the
respective updatedb is invoked.
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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



Contents-source.gz

2007-11-17 Thread Cyril Brulebois
Hi,

I'm wondering whether having a Contents-source.gz file on the mirrors
would be interesting. p.d.o could also be updated so as to support the
search through the “Source” architecture. apt-file could also use such
data.

Use case: when discovering a bug in a given file (e.g. a header, an m4
or a pkg-config file), one could easily search for other source packages
including it, to spot possible bogus packages (e.g. FTBFSing in some
circumstances).

That might be particularly useful when working on security issues: given
a work-needing file, one could search for possible copies in other
source packages, which might not been known as embedding a copy of the
responsible library/file.

Another application could be searching the source packages for files
matching a given pattern, so as to determine which source packages
contain a given library, or files written in a given language (if one
can trust the extension enough).

Comment welcome.

Cheers,

-- 
Cyril Brulebois


pgpeyOszEcdcI.pgp
Description: PGP signature


Re: MTA comparison (postfix, exim4, ...)

2007-11-17 Thread Florian Weimer
* MJ Ray:

>> I believe http://www.postfix.org/ADDRESS_VERIFICATION_README.html
>> details the facility you're looking for.
>
> I don't believe it does.  I don't want to verify the recipient address
> - I want to try delivering the redirected mail and avoid being left
> holding the baby if the destination MX doesn't want it or is MIA.

I didn't know that Exim 4 supports cut-through forwarding.  How do you
enable this feature?


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



Mass bug filing: non-UTF8 debian/{control.changelog}

2007-11-17 Thread Bas Zoetekouw
Hi!

I'm planning to file bugs for packages that use non-UTF-8 encodings in
debian/control and/or debian/copyright.

Fixing this is a release goal for Lenny [1], so the bugs will be filed
with severity important.  They will be tracked by the "utf8-control" BTS
tag.

Below is a list of packages that are currently affected (83, with some
overlap), along with bugs that are already present in the bts.  

Best regards,
Bas.

[1] http://release.debian.org/lenny-goals.txt

control   #xx doc-linux-html-pt  Gleydson_Mazioli_da_Silva
control   #xx doc-linux-text-pt  Gleydson_Mazioli_da_Silva
control   #356825 elmo   Jacek__liwerski__rzyjontko
control   #338837 fcmp   David_Mart_nez_Moreno
control   #338838 glade-perl R_mi_Perrot
control   #242690 itcl3  Chris_Waters
control   #xx libroxen-linkifTurbo_Fredriksson
control   #xx libroxen-mail  Turbo_Fredriksson
control   #xx libroxen-presentit Turbo_Fredriksson
control   #xx pyca   Lars_Bahner
control   #xx tetex-src  teTeX_maintainers
control   #xx xorp   Jose_Calhariz
changelog #xx ashGerrit_Pape
changelog #xx baz-load-dirs  John_Goerzen
changelog #xx cfingerd   Martin_Schulze
changelog #xx darcs-load-dirsJohn_Goerzen
changelog #xx dash   Gerrit_Pape
changelog #xx debian-el  Peter_S_Galbraith
changelog #xx debian-keyring James_Troup
changelog #xx devscripts-el  Peter_S_Galbraith
changelog #451080 distcc Carsten_Wolff
changelog #xx distccmon-gnomeCarsten_Wolff
changelog #xx dpkg-dev-elPeter_S_Galbraith
changelog #356825 elmo   Jacek__liwerski__rzyjontko
changelog #xx emacs-goodies-el   Peter_S_Galbraith
changelog #338837 fcmp   David_Mart_nez_Moreno
changelog #xx git-load-dirs  John_Goerzen
changelog #xx gkrellmms  Sjoerd_Simons
changelog #338838 glade-perl R_mi_Perrot
changelog #xx gmanedit   Sergio_Rua
changelog #xx gnus-bonus-el  Peter_S_Galbraith
changelog #xx gprolog-docSalvador_Abreu
changelog #xx gprologSalvador_Abreu
changelog #xx gtk-engines-geramik-data   Stefan_Schimanski
changelog #xx gtk-engines-geramikStefan_Schimanski
changelog #xx gtk-engines-thingeramik-data   Stefan_Schimanski
changelog #xx gtk-engines-thingeramikStefan_Schimanski
changelog #xx gtk2-engines-geramik   Stefan_Schimanski
changelog #xx gtk2-engines-thingeramik   Stefan_Schimanski
changelog #xx harden-doc Javier_Fernandez_Sanguino_Pen_a
changelog #xx hg-load-dirs   John_Goerzen
changelog #xx irqbalance Kyle_McMartin
changelog #xx klogd  Martin_Schulze
changelog #xx kover  Rene_Engelhard
changelog #xx libglade-perl  R_mi_Perrot
changelog #xx libradius1-dev Turbo_Fredriksson
changelog #xx libradius1 Turbo_Fredriksson
changelog #xx libroxen-calendar  Turbo_Fredriksson
changelog #xx libroxen-diary Turbo_Fredriksson
changelog #xx libroxen-expires   Turbo_Fredriksson
changelog #xx libroxen-imho  Turbo_Fredriksson
changelog #xx libroxen-logsqlTurbo_Fredriksson
changelog #xx libroxen-mailitTurbo_Fredriksson
changelog #xx libroxen-pressrelease  Turbo_Fredriksson
changelog #xx libroxen-xmlrpc-caudiumTurbo_Fredriksson
changelog #xx libroxen-xmlrpc-common Turbo_Fredriksson
changelog #xx libroxen-xmlrpc-roxen  Turbo_Fredriksson
changelog #xx load-dirs-common   John_Goerzen
changelog #xx manpages   Martin_Schulze
changelog #xx pcd2html   Andreas_Tille
changelog #xx pencam Andrew_James_Grafham
changelog #xx perl   Brendan_O_Dea
changelog #xx ppmtofbChris_Lawrence
changelog #xx radiusclient1  Turbo_Fredriksson
changelog #xx roxen-fonts-iso8859-1  Turbo_Fredriksson
changelog #xx roxen-fonts-iso8859-2  Turbo_Fredriksson
changelog #xx sgmltexi   Gaetano_Paolone__bigpaul
changelog #xx slashem-common Peter_Makholm
changelog #xx slashem-gtk 

Re: XS-Vcs-*, XS-X-Vcs-* and friends

2007-11-17 Thread Thomas Girard
Hello,

Le mardi 30 octobre 2007 à 19:39 +0100, Romain Francoise a écrit :
[...]
> BUT! you may be interested in the following packages, which use
> XS-X-Vcs-* headers and are also easy to catch:

[...]
> Thomas Girard <[EMAIL PROTECTED]>
>stlport5.1 (U)

Fixed in svn, thanks!

Regards,
Thomas



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



FW: Re: distro specific kernels vs vanilla kernel and how to compare among each other

2007-11-17 Thread devzero
hi !

i`m thinking of starting a small project to compare distro-specific kernel 
changes (see below)

before starting i wanted to take a first look at how different distro`s 
kernel-source looks like and how patches being handled there.

it was easy for me to get suse/fedora kernel and both have a patch collection 
within the source-rpm. 

as an example, for suse/fedora each patch has a specific name like

-rw-r--r--  1  659   50   921 27. Aug 21:42 acpi_force-fan-active.patch
-rw-r--r--  1  659   50  3275 18. Sep 10:36 aux-at_vector_size.patch
-rw-r--r--  1  659   50 14495 27. Aug 21:42 cpufreq_move_policy_init.patch
-rw-r--r--  1  659   50  9371 27. Aug 21:42 cpufreq_ondemand_as_default.patch
-rw-r--r--  1  659   50  2204 27. Aug 21:42 
dm-add-ratelimit-logging-macros.patch
-rw-r--r--  1  659   50   919 27. Aug 21:42 dm-bio_list-prefetch-removal.patch
-rw-r--r--  1  659   50  1541 27. Aug 21:42 dm-delay-cleanup.patch
-rw-r--r--  1  659   50  7899 27. Aug 21:42 dm-mpath-hp-sw.patch
-rw-r--r--  1  659   50 19648 27. Aug 21:42 dm-mpath-rdac.patch

and they are applied to vanilla source when you build the binary rpm.

i don`t know how debian build system works - but is this handled differently 
there?

i searched for some time and all i found was some large diff which i can turn 
into a broken-out version, but a patch-collection with logical patch-names 
would give a better overview.

unfortunately i`m not deep enough into debian and maybe you can point me to the 
relevant patch files/archives/repositories or tell me if it`s different in 
debian ?

thank you!

regards
roland


> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> Gesendet: 17.11.07 13:32:28
> An: "Andi Kleen" <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> Betreff: Re: distro specific kernels vs vanilla kernel and how to compare 
> among each other

> 
> besides a web-browseable directory structure with all the single broken-out 
> patches (which are typically part of src.rpm or similar) , i assume it would 
> be good to put those patched and unpatched kernel sources online via lxr ? ( 
> http://lxr.linux.no/ )
>   
> > -Ursprüngliche Nachricht-
> > Von: "Andi Kleen" <[EMAIL PROTECTED]>
> > Gesendet: 16.11.07 23:25:29
> > An: [EMAIL PROTECTED]
> > CC: [EMAIL PROTECTED]
> > Betreff: Re: distro specific kernels vs vanilla kernel and how to compare 
> > among each other
> 
> 
> > 
> > [EMAIL PROTECTED] writes:
> > 
> > > does somebody know if there is a website or a project for giving 
> > > comfortable and deeper insight into what`s specific to distro`s kernels 
> > > and what`s their difference to vanilla kernel ?
> > >
> > > i mean some way to have some transparancy to what different distro 
> > > vendors add to vanilla kernel sources and thus turning it into their own 
> > > specific version. 
> > 
> > There used to be such a page at kernelnewbies, but at some point it 
> > disappeared.
> > 
> > I agree it would be a useful resource.
> > 
> > -Andi
> > 
> 
> 


__
Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit 
Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134



ITP: liblocale-us-perl -- Module for United States state identification

2007-11-17 Thread Ernesto Hernandez-Novich
Package: wnpp

* Package name: liblocale-us-perl
  Version: 1.02
  Upstream Author: T. M. Brannon <[EMAIL PROTECTED]>
* URL: http://search.cpan.org/dist/Locale-US/
* License: GPL or Perl Artistic

Description:

This Perl module provides methods allowing United States' two-letter
state identification parsing from state code to state name and vice
versa.
-- 
Ernesto Hernández-Novich - Linux 2.6.18 i686 - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3


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



Re: buildds: "Authentication warning overridden."

2007-11-17 Thread Ian Jackson
Florian Weimer writes ("Re: buildds: "Authentication warning overridden.""):
> In this case, HTTPS should be used to download the packages, together
> with proper certificate validation.  This has got the added benefit that
> passwords aren't sent in the clear (well, unless an error occurs, but
> this is a separate issue).

https is a pretty poor protocol because it usually suffers from
dreadful key management.  In this case it might be workable but for
this specialised application it's probably not worth the effort to add
https support to apt (indeed, I would suggest that apt ought _not_ get
gain https support because that would lead people to use https in the
usual way - ie inappropriately).

Better would be to arrange for apt's usual signature checking
mechanisms to work.  I understand that the incoming directory
can't be signed with any of the usual keys because that would require
a human to make the key available and authorise the signature.

But it would perhaps be possible to generate a dedicated key which is
used to sign incoming only for the benefit of the buildds, and to
install the corresponding public half in the buildds' configs.

That would involve providing a Release file for incoming of course.

The key could even be automatically changed on a regular basis, with
the public half distributed via ssh.

Ian.


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



Re: can Breaks be used already? (was Re: Opinions sought: mlocate appropriate for Priority: standard?)

2007-11-17 Thread Ian Jackson
Steve Langasek writes ("Re: can Breaks be used already? (was Re: Opinions 
sought: mlocate appropriate for Priority: standard?)"):
> I think you mean that Ian Jackson always recommends upgrading apt and
> aptitude prior to performing dist-upgrade. :)  The release notes haven't
> always recommended this, because in the past there have been occasions where
> doing so ran into problems related to glibc/kernel circular deps.

No, I don't make any such recommendation, at least to users :-).

But yes, I do think it would be a better state of affairs if we
decided that users ought to do the upgrade with the new package
installation toolstack, and supported that properly.

For the deployment of Breaks we do ideally need to either wait a
release cycle or to upgrade apt, aptitude and dpkg first.

If there are glibc/kernel circular dependencies which prevent us doing
this then we should arrange to build the packaging machinery using the
previous release.  That's what we did in previous transitions and it
worked well.

Ian.


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



Bug#451636: ITP: telepathy-qt -- base classes for telepathy in qt

2007-11-17 Thread Sune Vuorela
Package: wnpp
Severity: wishlist
Owner: Sune Vuorela <[EMAIL PROTECTED]>


* Package name: telepathy-qt
  Version : svn snapshot
  Upstream Author : various authors
* URL : 
https://tapioca-voip.svn.sourceforge.net/svnroot/tapioca-voip/trunk/telepathy-qt
* License : (LGPL
  Programming Lang: C++
  Description : base classes for telepathy in qt


telepathy-qt is a Qt4 package containing base classes for use in
connection managers, and proxy classes for use in clients. It's used in
at least TapiocaQt.

This package is used as a prerequisite for decibel, one of the new smart
thingies available in kde4.

If the telepathy people wants to take over this package, they are most
welcome.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (200, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.20-1-vserver-k7 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash



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



Re: dpkg-shlibdeps and private libraries

2007-11-17 Thread Ian Jackson
Steve Langasek writes ("Re: dpkg-shlibdeps and private libraries"):
> On Tue, Nov 06, 2007 at 08:51:05AM +0100, Andreas Tille wrote:
> FWIW, I don't agree that this is a fix.  In one sense it makes /usr/lib
> "cleaner" by moving private libs into a private directory; however:

There is at least one significant difference between libraries in
/usr/lib and ones in a private application directory: LD_PRELOAD
cannot be used to force the loading of the latter by set-id programs.

For example, authbind contains /usr/lib/authbind/libauthbind.so.1
which is there for that reason.  If I make a symlink into /usr/lib I
get this behaviour:

-anarres:~> ll -uL --full-time /usr/lib/libauthbind.so.1 
-rw-r--r-- 1 root root 5944 2007-11-17 16:18:32.0 + 
/usr/lib/libauthbind.so.1
-anarres:~> date
Sat Nov 17 16:19:06 GMT 2007
-anarres:~> LD_PRELOAD=/usr/lib/libauthbind.so.1 really id
uid=0(root) gid=100(ian) 
groups=0(root),4(adm),6(disk),7(lp),8(mail),9(news),24(cdrom),25(floppy),26(tape),29(audio),33(www-data),35(dos),37(operator),40(src),42(shadow),50(staff),60(games),100(ian),200(ian-p),300(exim),500(house),1143(mirror),5063(anarubun)
-anarres:~> ll -uL --full-time /usr/lib/libauthbind.so.1 
-rw-r--r-- 1 root root 5944 2007-11-17 16:19:10.0 + 
/usr/lib/libauthbind.so.1
-anarres:~> id
uid=100(ian) gid=100(ian) 
groups=0(root),4(adm),6(disk),7(lp),8(mail),9(news),24(cdrom),25(floppy),26(tape),29(audio),33(www-data),35(dos),37(operator),40(src),42(shadow),50(staff),60(games),100(ian),200(ian-p),300(exim),500(house),1143(mirror),5063(anarubun)
-anarres:~>

This is not desirable.

There are other reasons or kinds of library for which /usr/lib is not
appropriate, for example application plugins.  For example, Tcl
extensions are moving into a separate directory.

> - By moving the libs out of the default search path, you introduce the
>   possibility that an unrelated library will have the same name in /usr/lib;
>   this is a potential source of user confusion, as well as
>   difficult-to-diagnose corner-case bugs

Obviously one still needs to avoid name clashes.

> So I think it's better to leave these libraries in /usr/lib instead of using
> rpath.

My arguments and examples above don't apply to libraries that ought to
_only_ be autoloaded via rpath.  But not all uses of rpath are wrong.

For example the Tcl extension modules in chiark-tcl will be moving out
of /usr/lib and because they have interdependencies, rpath will be
needed to find them.  This can't feasibly be done `by hand' in the
Tcl-called initialisation function but there is no application which
needs to load the top of the library stack other than Tcl.

Ian.


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



Re: debian archive integrity check tool?

2007-11-17 Thread Ian Jackson
=?iso-8859-2?Q?V=E1clav_Ovs=EDk?= writes ("debian archive integrity check 
tool?"):
> please, is there any utility/script, that can verify integrity of Debian
> archive?  A maintainer of the ftp mirror ftp.linux.cz asks for this in
> a national mailling list about Linux systems. He needs this for non
> Debian system.

Is there some problem with feeding indices/md5sums.gz to md5sum -c ?

Ian.


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



Re: Mass bug filing: non-UTF8 debian/{control.changelog}

2007-11-17 Thread Christian Perrier
Quoting Bas Zoetekouw ([EMAIL PROTECTED]):
> Hi!
> 
> I'm planning to file bugs for packages that use non-UTF-8 encodings in
> debian/control and/or debian/copyright.


copyright or changelog? Or both?



signature.asc
Description: Digital signature


Re: ITP: liblocale-us-perl -- Module for United States state identification

2007-11-17 Thread Ron Johnson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/17/07 09:56, Ernesto Hernandez-Novich wrote:
> Package: wnpp
> 
> * Package name: liblocale-us-perl
>   Version: 1.02
>   Upstream Author: T. M. Brannon <[EMAIL PROTECTED]>
> * URL: http://search.cpan.org/dist/Locale-US/
> * License: GPL or Perl Artistic
> 
> Description:
> 
> This Perl module provides methods allowing United States' two-letter
> state identification parsing from state code to state name and vice
> versa.

Is a package really needed for something this simple?

- --
Ron Johnson, Jr.
Jefferson LA  USA

%SYSTEM-F-FISH, my hovercraft is full of eels
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHPzRAS9HxQb37XmcRAr2aAJ4qlXj4Vb2yzdTbtKTjiNyu33e2OgCfTchc
hU/HjV3QuQZO2OmQ44nvxiY=
=Otmb
-END PGP SIGNATURE-


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



Bug#451651: ITP: tapioca-qt -- tapioca qt library

2007-11-17 Thread Sune Vuorela
Package: wnpp
Severity: wishlist
Owner: Sune Vuorela <[EMAIL PROTECTED]>


* Package name: tapioca-qt
  Version : svn snapshot
  Upstream Author : various authors
* URL : 
https://tapioca-voip.svn.sourceforge.net/svnroot/tapioca-voip/trunk/tapioca-qt
* License : LGPL
  Programming Lang: C++
  Description : tapioca qt library

(Include the long description here.)



-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (200, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.20-1-vserver-k7 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash



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



Bug#451664: ITP: decibel -- real time communication framework

2007-11-17 Thread Sune Vuorela
Package: wnpp
Severity: wishlist
Owner: Sune Vuorela <[EMAIL PROTECTED]>


* Package name: decibel
  Version : svn snapshot
  Upstream Author : Tobias Hunger
* URL : http://decibel.kde.org
* License : LGPL
  Programming Lang: C++
  Description : real time communication framework

Decibel is a realtime communications framework, integrating services
like CTI (Computer Telephone Integration), VoIP (Voice over IP), text
based chat and instant messaging. 

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (200, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.20-1-vserver-k7 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash



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



Re: ITP: liblocale-us-perl -- Module for United States state identification

2007-11-17 Thread Matt Brown
On 11/17/07, Ron Johnson <[EMAIL PROTECTED]> wrote:
> > This Perl module provides methods allowing United States' two-letter
> > state identification parsing from state code to state name and vice
> > versa.
>
> Is a package really needed for something this simple?

It might be obvious to a US native, but it's hardly simple or obvious
to those of us outside America.

MI is a prime example, does it refer to Michigan, Missouri,
Mississippi or Minesota? The first two letters match all four.

If you come across this every day you probably know the answer, but I
just had to look it up again (Michigan) despite being caught out by
this just the other week!

-- 
Matt Brown
[EMAIL PROTECTED]
Mob +353 86 608 7117 www.mattb.net.nz


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



Re: FW: Re: distro specific kernels vs vanilla kernel and how to compare among each other

2007-11-17 Thread Francesco P. Lovergine
On Sat, Nov 17, 2007 at 04:08:17PM +0100, [EMAIL PROTECTED] wrote:
> 
> i don`t know how debian build system works - but is this handled differently 
> there?
> 
> i searched for some time and all i found was some large diff which i can turn 
> into a broken-out version, but a patch-collection with logical patch-names 
> would give a better overview.
> 
> unfortunately i`m not deep enough into debian and maybe you can point me to 
> the relevant patch files/archives/repositories or tell me if it`s different 
> in debian ?
> 

Start from here: http://wiki.debian.org/DebianKernelCustomCompilation

-- 
Francesco P. Lovergine


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



Re: dpkg-shlibdeps and private libraries

2007-11-17 Thread Steve Langasek
On Sat, Nov 17, 2007 at 04:24:18PM +, Ian Jackson wrote:
> Steve Langasek writes ("Re: dpkg-shlibdeps and private libraries"):
> > On Tue, Nov 06, 2007 at 08:51:05AM +0100, Andreas Tille wrote:
> > FWIW, I don't agree that this is a fix.  In one sense it makes /usr/lib
> > "cleaner" by moving private libs into a private directory; however:

> There is at least one significant difference between libraries in
> /usr/lib and ones in a private application directory: LD_PRELOAD
> cannot be used to force the loading of the latter by set-id programs.

> For example, authbind contains /usr/lib/authbind/libauthbind.so.1
> which is there for that reason.  If I make a symlink into /usr/lib I
> get this behaviour:

If it's intended to only be used for LD_PRELOAD, why give it an soname at
all (i.e., why regard it as a "library")?

> -anarres:~> ll -uL --full-time /usr/lib/libauthbind.so.1 
> -rw-r--r-- 1 root root 5944 2007-11-17 16:18:32.0 + 
> /usr/lib/libauthbind.so.1
> -anarres:~> date
> Sat Nov 17 16:19:06 GMT 2007
> -anarres:~> LD_PRELOAD=/usr/lib/libauthbind.so.1 really id
> uid=0(root) gid=100(ian) 
> groups=0(root),4(adm),6(disk),7(lp),8(mail),9(news),24(cdrom),25(floppy),26(tape),29(audio),33(www-data),35(dos),37(operator),40(src),42(shadow),50(staff),60(games),100(ian),200(ian-p),300(exim),500(house),1143(mirror),5063(anarubun)
> -anarres:~> ll -uL --full-time /usr/lib/libauthbind.so.1 
> -rw-r--r-- 1 root root 5944 2007-11-17 16:19:10.0 + 
> /usr/lib/libauthbind.so.1
> -anarres:~> id
> uid=100(ian) gid=100(ian) 
> groups=0(root),4(adm),6(disk),7(lp),8(mail),9(news),24(cdrom),25(floppy),26(tape),29(audio),33(www-data),35(dos),37(operator),40(src),42(shadow),50(staff),60(games),100(ian),200(ian-p),300(exim),500(house),1143(mirror),5063(anarubun)
> -anarres:~>

> This is not desirable.

Er, no, it's not.  That looks fairly special, I wasn't aware that ld.so
would happily permit LD_PRELOAD values pointing to /usr/lib when running
setuid apps.

> There are other reasons or kinds of library for which /usr/lib is not
> appropriate, for example application plugins.  For example, Tcl
> extensions are moving into a separate directory.

An application plugin isn't a library, it's an application plugin.

> > - By moving the libs out of the default search path, you introduce the
> >   possibility that an unrelated library will have the same name in /usr/lib;
> >   this is a potential source of user confusion, as well as
> >   difficult-to-diagnose corner-case bugs

> Obviously one still needs to avoid name clashes.

Which we have no mechanism for ensuring if the libraries are scattered among
multiple directories.  File conflict detection is the one means we have of
finding out about name clashes.

> > So I think it's better to leave these libraries in /usr/lib instead of using
> > rpath.

> My arguments and examples above don't apply to libraries that ought to
> _only_ be autoloaded via rpath.  But not all uses of rpath are wrong.

> For example the Tcl extension modules in chiark-tcl will be moving out
> of /usr/lib and because they have interdependencies, rpath will be
> needed to find them.  This can't feasibly be done `by hand' in the
> Tcl-called initialisation function but there is no application which
> needs to load the top of the library stack other than Tcl.

Tcl seems to be a special case in this regard.  All other languages I know
of that support loadable modules have defined search paths that are used for
this sort of thing, as well as policies governing packages' use of the
paths.

Cheers,
-- 
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]



Is Lars Bahner MIA?

2007-11-17 Thread Fabio Tranchitella
Dear fellow developers,

I'm trying to get in touch with Lars Bahner: he is the maintainer of
varnish, but the last upload is from February 2007 and several new upstream
releases were available since then.

I offered help for the packaging several times by e-mail, but I haven't
received any answer so far. Do anybody know how to contact him?

Thanks in advance,

-- 
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http://www.tranchitella.it
_
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564


signature.asc
Description: Digital signature


Re: FW: Re: distro specific kernels vs vanilla kernel and how to

2007-11-17 Thread devzero
thanks - i have found linux-2.6_2.6.18.dfsg.1-13etch4.diff.gz via your link - 
seems this is what i was looking for.

regards
roland


List:   debian-devel
Subject:Re: FW: Re: distro specific kernels vs vanilla kernel and how to
From:   "Francesco P. Lovergine" 
Date:   2007-11-17 19:24:41
Message-ID: 20071117192440.GA30941 () ba ! issia ! cnr ! it
[Download message RAW]

On Sat, Nov 17, 2007 at 04:08:17PM +0100, [EMAIL PROTECTED] wrote:
> 
> i don`t know how debian build system works - but is this handled differently 
> there?
> 
> i searched for some time and all i found was some large diff which i can turn 
> into \
> a broken-out version, but a patch-collection with logical patch-names would 
> give a \
> better overview. 
> unfortunately i`m not deep enough into debian and maybe you can point me to 
> the \
> relevant patch files/archives/repositories or tell me if it`s different in 
> debian ? \
> 

Start from here: http://wiki.debian.org/DebianKernelCustomCompilation

-- 
Francesco P. Lovergine


___
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00



Re: dpkg-shlibdeps and private libraries

2007-11-17 Thread Steve Langasek
On Tue, Nov 13, 2007 at 08:59:32PM +0100, Josselin Mouette wrote:

> Le mardi 13 novembre 2007 à 11:01 -0800, Steve Langasek a écrit :
> > > The current packages install the dynamic libraries simply to /usr/lib
> > > which I want to fix now.  They should go to

> > >  ${ARB_HOME}/lib

> > FWIW, I don't agree that this is a fix.  In one sense it makes /usr/lib
> > "cleaner" by moving private libs into a private directory; however:

> > - Because Debian uses ldconfig, the runtime cost of having additional
> >   libraries in the search path for other apps is negligible
> > - By moving the libs out of the default search path, you introduce the
> >   possibility that an unrelated library will have the same name in /usr/lib;
> >   this is a potential source of user confusion, as well as
> >   difficult-to-diagnose corner-case bugs

> But when you keep private libraries without a stable ABI nor proper
> soname versioning, you increase the chance that other packages start
> using them without thinking.

If that's really the case here, then moving the lib out of /usr/lib is a
reasonable option.  I think other reasonable options are to not ship a -dev
package for the library, or (depending on how big the library is and how
much the privately-cooperating binaries benefit from using a shared library)
only making the lib available as a static lib.

> > - When multiarch matures (or we have some other reason to move library
> >   directories around...), your package will require specific handling to
> >   update the library paths, rather than a simple change to libdir that will
> >   be handled automatically by the ld.so search path.

> Given the number of specific binaries and libraries in this case, I hope
> we will have some generic tools to make them support multiarch.

That's not really possible when you're dealing with packages which
individually have their own way of hard-coding their private search paths.

-- 
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: ITP: liblocale-us-perl -- Module for United States state identification

2007-11-17 Thread Ron Johnson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/17/07 18:51, Matt Brown wrote:
> On 11/17/07, Ron Johnson <[EMAIL PROTECTED]> wrote:
>>> This Perl module provides methods allowing United States' two-letter
>>> state identification parsing from state code to state name and vice
>>> versa.
>> Is a package really needed for something this simple?
> 
> It might be obvious to a US native, but it's hardly simple or obvious
> to those of us outside America.

It's not the *need* for a lookup table, it's the need for such a
small package.  See below.

> MI is a prime example, does it refer to Michigan, Missouri,
> Mississippi or Minesota? The first two letters match all four.

Don't forget the Marshall Islands!

AL - Alaska or Alabama?
AR - Arizona or Arkansas?
CO - Colorado or Connecticut?
MA - Maine, Marshall Islands, Maryland, Massachusetts?
NE - Nebraska or Nevada?

> If you come across this every day you probably know the answer, but I
> just had to look it up again (Michigan) despite being caught out by
> this just the other week!

But it's just (or should be) a couple of 65-element (50 states, DC,
Puerto Rico, Virgin Islands, and various Pacific islands) hash
tables wrapped around a couple of simple functions.

http://www.usps.com/ncsc/lookups/abbr_state.txt

What would be much more useful (still simple, but with much more
data) is a world-wide hash table of countries and states/provinces.

And wouldn't you know it... there's already a CPAN module to do just
that: Locale::SubCountry.

http://search.cpan.org/~kimryan/Locale-SubCountry-1.38/lib/Locale/SubCountry.pm

- --
Ron Johnson, Jr.
Jefferson LA  USA

%SYSTEM-F-FISH, my hovercraft is full of eels
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHP0R8S9HxQb37XmcRAiA2AJ9yhYepslZJCedRRxeLtverXuP2RQCggl/G
jffLA1E9WM2wK00R4LZehYw=
=UNmC
-END PGP SIGNATURE-


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



pbuilder build with passing -sa option

2007-11-17 Thread Piotr Roszatycki
I give up. I really don't know how to pass "-sa" option to
dpkg-buildpackage when I use

pbuilder build *.dsc

command. I'm trying:

sudo pbuilder build --debbuildopts="-sa" *.dsc

and it doesn't work. Could you help me, please?

-- 
 .''`.Piotr Roszatycki
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-


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



Re: ITP: liblocale-us-perl -- Module for United States state identification

2007-11-17 Thread Roberto C . Sánchez
On Sat, Nov 17, 2007 at 06:51:03PM +, Matt Brown wrote:
> On 11/17/07, Ron Johnson <[EMAIL PROTECTED]> wrote:
> > > This Perl module provides methods allowing United States' two-letter
> > > state identification parsing from state code to state name and vice
> > > versa.
> >
> > Is a package really needed for something this simple?
> 
> It might be obvious to a US native, but it's hardly simple or obvious
> to those of us outside America.
> 
> MI is a prime example, does it refer to Michigan, Missouri,
> Mississippi or Minesota? The first two letters match all four.
> 
> If you come across this every day you probably know the answer, but I
> just had to look it up again (Michigan) despite being caught out by
> this just the other week!
> 
That got me thinking.  I figure that since MI -> Michigan, it meant that
MI was the first state to start with those letters.  Logically, I would
think, always use the first two letters, unless another state already
had them.  Arbitrate in order granting of statehood.  But both
Mississippi (MS) and Missouri (MO) were states before Michigan (MI).

Curious.

Regards,

-Roberto
-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature


Re: pbuilder build with passing -sa option

2007-11-17 Thread Roberto C . Sánchez
On Sat, Nov 17, 2007 at 09:15:20PM +0100, Piotr Roszatycki wrote:
> I give up. I really don't know how to pass "-sa" option to
> dpkg-buildpackage when I use
> 
> pbuilder build *.dsc
> 
> command. I'm trying:
> 
> sudo pbuilder build --debbuildopts="-sa" *.dsc
> 
> and it doesn't work. Could you help me, please?
> 
I had the same problem previously.  Don Armstrong explained why it
happens and how to solve it:

http://lists.debian.org/debian-devel/2007/09/msg00546.html

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature


Re: pbuilder build with passing -sa option

2007-11-17 Thread Erik Schanze
Hi Piotr,

"Piotr Roszatycki" <[EMAIL PROTECTED]>:
> sudo pbuilder build --debbuildopts="-sa" *.dsc

use:
sudo pbuilder build --debbuildopts "-sa" *.dsc


Kindly regards,

Erik


-- 
 www.ErikSchanze.de *
 Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB *
- Linux-Info-Tag in Dresden, 3. November 2007   *
 Info: http://www.linux-info-tag.de/*


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



[help] brltty: Java behaves strangely on different archs?

2007-11-17 Thread Mario Lang
Hi.

One of my packages (brltty) recently gained Java bindings for its API.
Now since I added the usage of gcj to brltty, I see that the java toolchain
seems to be quite out of sync on different archs in different ways.

At first everything worked here on amd64, but when I uploaded I saw
the i386 build failing[1], the builddeps were all there but the java bindings
are somehow not built and therefore dh_install fails.
Then I noticed in the same run that on arm, the build-deps couldn't be
satisfied[2].
Later on, the problem on i386 vanished magically[3] and it just autobuilds
fine there now.  But the same problem as I saw on i386 originally
now seems to persist at least on alpha[4].  arm still can't install
the build-deps.  This is about 2 months later since I first uploaded
the java-using version of brltty...  I was originally hoping
this would all just sort out by itself.  Now that I'd actually need
brltty to go to testing for other reasons, I am sort of lost.

This is a call for help.  If you have any idea or can shed a little
light on the whole issue, please let me know what I can do to fix this
and get brltty in testing.  I *know* I could remove the java support again,
but I'd like to make sure there is no other way before doing so.

[1] 
http://buildd.debian.org/fetch.cgi?&pkg=brltty&ver=3.8-6&arch=i386&stamp=1188733192&file=log
[2] 
http://buildd.debian.org/fetch.cgi?&pkg=brltty&ver=3.8-6&arch=arm&stamp=1188732968&file=log
[3] 
http://buildd.debian.org/fetch.cgi?&pkg=brltty&ver=3.8-7&arch=i386&stamp=1189354533&file=log
[4] 
http://buildd.debian.org/fetch.cgi?&pkg=brltty&ver=3.9-2&arch=alpha&stamp=1195173383&file=log

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
  .''`. | Get my public key via finger [EMAIL PROTECTED]
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-  http://delysid.org/>  http://www.staff.tugraz.at/mlang/>


pgpCvLvuWmVp6.pgp
Description: PGP signature


Re: ITP: liblocale-us-perl -- Module for United States state identification

2007-11-17 Thread Darren Salt
I demand that Ron Johnson may or may not have written...

[snip]
> What would be much more useful (still simple, but with much more
> data) is a world-wide hash table of countries and states/provinces.

Are you equating states with provinces there? If so, think again... :-)

[snip]
-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Travel less. Share transport more.   PRODUCE LESS CARBON DIOXIDE.

You will pass away very quickly.


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



Re: Bug#377392: Bug#450432: ... and even more bugs like this?

2007-11-17 Thread Colin Watson
On Fri, Nov 16, 2007 at 12:32:26AM +0600, Ivan Shmakov wrote:
>   In a recent thread in debian-devel, it was suggested that
>   lintian could call man(1) in such a way that the groff(1),
>   called by `man', will emit warnings for every undefined macro,
>   which is useful in catching the bugs like this:
> 
> .B foo
> .  Note: ...
> 
>   Below is the patch that implements the suggestion.  Since `man'
>   doesn't allow the `-wmac' option to be passed to `groff' by any
>   other means, I've had to introduce two new files -- `mdoc.local'
>   and `man.local' (to override the files in groff/site-tmac/), and
>   the ${LINTIAN_ROOT}/groff-hack directory to hold them.

While I haven't reviewed the code in detail, the general approach seems
largely reasonable to me. However, the error the developer sees will
just be "manpage-has-errors-from-man", which in fact is no longer really
true in this case; you're specifically enabling warnings that man
doesn't show. Perhaps it would be best to turn these warnings from groff
into a different lintian warning which can have a more informative
description, and ideally a way for the developer to reproduce the
problem.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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



Re: Is Lars Bahner MIA?

2007-11-17 Thread Josselin Mouette
Le samedi 17 novembre 2007 à 21:13 +0100, Fabio Tranchitella a écrit :
> I'm trying to get in touch with Lars Bahner: he is the maintainer of
> varnish, but the last upload is from February 2007 and several new upstream
> releases were available since then.

I guess he should maintain "vanish" instead.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


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


Re: Bug#450432: ... and even more bugs like this?

2007-11-17 Thread Colin Watson
On Fri, Nov 16, 2007 at 12:05:39AM +0600, Ivan Shmakov wrote:
> $ lintian --root="$PWD"/../lintian-root-2007-11-15 \
>   *.deb \
>   | grep -F has-errors
> W: libdirectfb-dev: manpage-has-errors-from-man 
> usr/share/man/man1/directfb-config.1.gz 24: warning: `l' not defined
> W: dvidvi: manpage-has-errors-from-man usr/share/man/man1/a5booklet.1.gz 9: 
> warning: `IX' not defined
> 
>   The lines like this seems to me somewhat bogus.  I guess, `.IX'
>   allows one to specify an index item, and since `man' doesn't
>   provide any indices, this macro is left undefined, and thus
>   ignored by `man' (and it's okay.)

Perhaps some of these should be explicitly ignored by lintian, as
they're problems with popular generator tools and it really doesn't do
anyone any good to report them in lintian; they should be filed as bugs
against the generators instead. (Unfortunately, you might have to parse
groff's warning text in order to ignore particular cases.)

.IX is probably from pod2man, which does:

  .\" If the F register is turned on, we'll generate index entries on stderr for
  .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
  .\" entries marked with X<> in POD.  Of course, you'll have to process the
  .\" output yourself in some meaningful fashion.
  .if \nF \{\
  .de IX
  .tm Index:\\$1\t\\n%\t"\\$2"
  ..
  .nr % 0
  .rr F
  .\}

Russ, perhaps this should be something like this instead to suppress the
warning?

  .\" If the F register is turned on, we'll generate index entries on stderr for
  .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
  .\" entries marked with X<> in POD.  Of course, you'll have to process the
  .\" output yourself in some meaningful fashion.
  .ie \nF \{\
  .de IX
  .tm Index:\\$1\t\\n%\t"\\$2"
  ..
  .nr % 0
  .rr F
  .\}
  .el \{\
  .de IX
  ..
  .\}

>   A simple-minded approach to suppress these warnings would be
>   something like:
> 
> .de IX
> .end
> 
>   but I believe that such a definition belongs to the macro
>   package `man' uses.

man doesn't use any macro package of its own; it's all in groff. I'd
like to keep it that way if possible. Anyhow, since this is a macro
defined by a particular man page generator, it's not appropriate to
handle it in either man or groff.

> W: dvgrab: manpage-has-errors-from-man usr/share/man/de/man1/dvgrab.1.gz 308: 
> warning: `..' not defined

Looks like a botched attempt to define a macro. (.. is what you use to
terminate a macro definition.)

> W: dput: manpage-has-errors-from-man usr/share/man/man1/dput.1.gz 92: 
> warning: `P.SH' not defined

An obvious typo.

> W: dpkg-dev: manpage-has-errors-from-man 
> usr/share/man/man1/dpkg-checkbuilddeps.1.gz 27: warning: `UR' not defined

.UR used to be what you used to mark up URLs; man(7) recommended it
until not that long ago.

> W: dpkg-dev: manpage-has-errors-from-man 
> usr/share/man/man1/dpkg-architecture.1.gz 104: warning: `C`' not defined

I'm not entirely sure what all this line noise is trying to achieve.
Looks to me like stuff like \f(CW\*(C`\-c\*(C' should just be \-c; aside
from the undefined strings, why should just the option be constant-width
and not the rest of the example command line?

> W: dpkg: manpage-has-errors-from-man usr/share/man/man1/dpkg-query.1.gz 51: 
> warning: `T' not defined

I think .T was perhaps meant to be .TP.

> W: docbook-utils: manpage-has-errors-from-man 
> usr/share/man/man7/frontend-spec.7.gz 37: warning: `..)' not defined

groff usage error; the line should read:

  \&...)

... or else the "...)" should be wrapped onto the previous line.

> W: docbook-to-man: manpage-has-errors-from-man 
> usr/share/man/man1/instant.1.gz 81: warning: `E' not defined

Firstly, I think \*EM was probably supposed to be \*(EM. Secondly,
there's no such string defined, and perhaps \(em is what they really
meant.

> W: docbook-to-man: manpage-has-errors-from-man 
> usr/share/man/man5/transpec.5.gz 467: warning: `DS' not defined

Err. This looks like an attempt to use ms macros, maybe? .RS and .RE
would be the appropriate equivalents in the man macros, if I understand
the intention correctly.

> W: docbook-to-man: manpage-has-errors-from-man usr/share/man/man3/regexp.3.gz 
> 2: warning: `DA' not defined

Perhaps this is how you specify dates in some old version of the man
macros? The date is conventionally the third argument to .TH nowadays.

At any rate, docbook-to-man has no business shipping this manual page at
all, and it should simply be removed.

> W: dirmngr: manpage-has-errors-from-man usr/share/man/man1/dirmngr.1.gz 245: 
> warning: `#'' not defined
> W: dirmngr: manpage-has-errors-from-man 
> usr/share/man/man1/dirmngr-client.1.gz 86: warning: `-vv'' not defined

I don't have this installed, but they look like typos.

> W: dialog: manpage-has-errors-from-man usr/share/man/man3/dialog.3.gz 1494: 
> warning: `..' not defined

Maybe another bo

Re: Bug#377392: Bug#450432: ... and even more bugs like this?

2007-11-17 Thread Russ Allbery
Colin Watson <[EMAIL PROTECTED]> writes:

> .IX is probably from pod2man, which does:

>   .\" If the F register is turned on, we'll generate index entries on stderr 
> for
>   .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
>   .\" entries marked with X<> in POD.  Of course, you'll have to process the
>   .\" output yourself in some meaningful fashion.
>   .if \nF \{\
>   .de IX
>   .tm Index:\\$1\t\\n%\t"\\$2"
>   ..
>   .nr % 0
>   .rr F
>   .\}

> Russ, perhaps this should be something like this instead to suppress the
> warning?

>   .\" If the F register is turned on, we'll generate index entries on stderr 
> for
>   .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
>   .\" entries marked with X<> in POD.  Of course, you'll have to process the
>   .\" output yourself in some meaningful fashion.
>   .ie \nF \{\
>   .de IX
>   .tm Index:\\$1\t\\n%\t"\\$2"
>   ..
>   .nr % 0
>   .rr F
>   .\}
>   .el \{\
>   .de IX
>   ..
>   .\}

Sure, that seems reasonable.

>> W: dpkg-dev: manpage-has-errors-from-man 
>> usr/share/man/man1/dpkg-architecture.1.gz 104: warning: `C`' not defined

> I'm not entirely sure what all this line noise is trying to achieve.
> Looks to me like stuff like \f(CW\*(C`\-c\*(C' should just be \-c;

It's intentional in general.  I don't know why it's not defined, though.
\f(CW sets a fixed-width font, and \*(C` and \*(C' add "" when fonts
aren't supported but suppress the quotes when fonts are supported.
pod2man has done this for eons.

I haven't looked at this particular usage, but there are places where this
is exactly the desired markup.

Maybe there's some missing logic for defining empty strings?

-- 
Russ Allbery ([EMAIL PROTECTED])   


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



Re: ITP: liblocale-us-perl -- Module for United States state identification

2007-11-17 Thread Ron Johnson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/17/07 20:33, Roberto C. Sánchez wrote:
> On Sat, Nov 17, 2007 at 06:51:03PM +, Matt Brown wrote:
>> On 11/17/07, Ron Johnson <[EMAIL PROTECTED]> wrote:
 This Perl module provides methods allowing United States' two-letter
 state identification parsing from state code to state name and vice
 versa.
>>> Is a package really needed for something this simple?
>> It might be obvious to a US native, but it's hardly simple or obvious
>> to those of us outside America.
>>
>> MI is a prime example, does it refer to Michigan, Missouri,
>> Mississippi or Minesota? The first two letters match all four.
>>
>> If you come across this every day you probably know the answer, but I
>> just had to look it up again (Michigan) despite being caught out by
>> this just the other week!
>>
> That got me thinking.  I figure that since MI -> Michigan, it meant that
> MI was the first state to start with those letters.  Logically, I would
> think, always use the first two letters, unless another state already
> had them.  Arbitrate in order granting of statehood.  But both
> Mississippi (MS) and Missouri (MO) were states before Michigan (MI).

The USPS doesn't care about entry into the union.  It cares about
collating and routing.

In alphabetical order:
Michigan MI  first 2 letters of name
MinnesotaMN  first two non-MI letters of name
Mississippi  MS  first two non-MI letters of name
Missouri MO  first two non-MS letters of name

- --
Ron Johnson, Jr.
Jefferson LA  USA

%SYSTEM-F-FISH, my hovercraft is full of eels
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHP78PS9HxQb37XmcRAhoAAJ9EdjvARhzDuFf6SIPrZlsK8zvh8wCg65/o
6nU3UhDAJz/QO1KQaTzwOlY=
=kZoB
-END PGP SIGNATURE-


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



Re: ITP: liblocale-us-perl -- Module for United States state identification

2007-11-17 Thread Roberto C . Sánchez
On Sun, Nov 18, 2007 at 04:26:55AM +, Ron Johnson wrote:
> On 11/17/07 20:33, Roberto C. S�nchez wrote:
> >>
> > That got me thinking.  I figure that since MI -> Michigan, it meant that
> > MI was the first state to start with those letters.  Logically, I would
> > think, always use the first two letters, unless another state already
> > had them.  Arbitrate in order granting of statehood.  But both
> > Mississippi (MS) and Missouri (MO) were states before Michigan (MI).
> 
> The USPS doesn't care about entry into the union.  It cares about
> collating and routing.
> 
> In alphabetical order:
> Michigan MI  first 2 letters of name
> MinnesotaMN  first two non-MI letters of name
> Mississippi  MS  first two non-MI letters of name
> Missouri MO  first two non-MS letters of name
> 
Interesting.  I had not considered that.

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature


Re: Opinions sought: mlocate appropriate for Priority: standard?

2007-11-17 Thread Ivan Shmakov
> Andreas Metzler <[EMAIL PROTECTED]> writes:

 >> $ cat /usr/bin/update-locate.findutils

 > [...]

 >> $ cat /etc/cron.daily/update-locate
 >> #!/bin/sh
 >> if [ -x /usr/sbin/update-locate ]; then
 >>/usr/sbin/update-locate
 >> fi

 >> Or am I missing something?

 > The fact that people might want to change with which options the
 > respective updatedb is invoked.

Indeed.  Though I'd prefer for code to stay in /usr.  Combining
both the configuration and the code in one /etc-script doesn't
seem to me like a very bright idea.

Having separate update-locate handle has an additional benefit
of allowing one to start database update by hand ``in a clean
way'' (compare, e. g., # /etc/init.d/foo start vs. # invoke-rc.d
foo start.)

Whoever does the work does the decision, though.


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