Re: List of packages which should probably be Architecture: all

[Michal Čihař]

Hi

On Wed, 02 Jan 2008 13:58:24 -0600
Raphael Geissert <[EMAIL PROTECTED]> wrote:

> Michal Čihař <[EMAIL PROTECTED]>
>libgammu3

Eh?

$ apt-cache show libgammu3 | grep ^Dep
Depends: libbluetooth2 (>= 3.0), libc6 (>= 2.7-1), libgammu-common (>=
1.17.0-1)

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

[Theodore Tso]

On Sun, Jan 06, 2008 at 10:37:03AM +0100, Julien Cristau wrote:
> 
> the libuuid1 postinst contains:
> groupadd -f -K GID_MIN=1 -K GID_MAX=999 libuuid
> if ! grep -q libuuid /etc/passwd; then
>useradd -d /var/lib/libuuid -K UID_MIN=1 -K UID_MAX=499 -g libuuid libuuid
> fi
> mkdir -p /var/lib/libuuid
> chown libuuid:libuuid /var/lib/libuuid
> chmod 2775 /var/lib/libuuid
> 
> The groupadd and useradd commands come from passwd, which is not
> Essential: yes, so a Depends is needed.
> 
> Moreover, the postinst succeeds even if any of these commands fail,
> because 'set -e' is missing at the top of the script.

So e2fsprogs which is "Essential: yes" depends on libuuid1, so
libuuid1 is effectively "Essential: yes", right?  So if I add a
dependency on passwd, it will effectively make passwd "Essential:
yes", as well, and according to policy I should bring it up for
comment on debian-policy.  So, I am doing so now.  Any objections if I
add a dependency on passwd for libuuid1?  The aternative would be to
roll-my-own useradd/adduser functionality, but that would be a real
PITA

Thanks, regards,

- Ted


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

Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

[Steve Langasek]

On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:
> On Sun, Jan 06, 2008 at 10:37:03AM +0100, Julien Cristau wrote:

> So e2fsprogs which is "Essential: yes" depends on libuuid1, so
> libuuid1 is effectively "Essential: yes", right?  So if I add a
> dependency on passwd, it will effectively make passwd "Essential:
> yes", as well, and according to policy I should bring it up for
> comment on debian-policy.  So, I am doing so now.

My mail headers disagree. :)  Is this really meant to be on debian-policy
rather than debian-devel?

> Any objections if I add a dependency on passwd for libuuid1?  The
> aternative would be to roll-my-own useradd/adduser functionality, but that
> would be a real PITA

I think rolling your own would be wrong no matter what.  If there are
specific reasons why libuuid1 can't depend on passwd, we should address
those instead.

But let's have a look:

Package: passwd
Version: 1:4.0.18.2-1
Depends: libc6 (>= 2.6.1-1), libpam0g (>= 0.99.7.1), libselinux1 (>= 2.0.15), 
login (>= 970502-1), libpam-modules (>= 0.72-5), debianutils (>= 2.15.2)

$ grep-dctrl -n -FEssential yes -sPre-Depends /var/lib/apt/lists/*sid*Packages \
  | tr ',' '\n' |sed -e's/^ //' | sort -u

coreutils (>= 5.93-1)
e2fslibs (= 1.40.3-1)
initscripts
libacl1 (>= 2.2.11-1)
libblkid1 (>= 1.34-1)
libc6 (>= 2.3.6-6)
libc6 (>= 2.5)
libc6 (>= 2.6-1)
libc6 (>= 2.6.1-1)
libc6 (>= 2.7-1)
libcomerr2 (>= 1.34-1)
libncurses5 (>= 5.4-5)
libncurses5 (>= 5.6+20071006-3)
libpam0g (>= 0.99.7.1)
libpam-runtime (>= 0.76-14)
libselinux1 (>= 2.0.15)
libslang2 (>= 2.0.7-1)
libss2 (>= 1.34-1)
libuuid1
libuuid1 (>= 1.34-1)
sysvinit-utils
sysv-rc (>= 2.86.ds1-1.2) | file-rc (>> 0.7.0)
zlib1g (>= 1:1.2.3.3.dfsg-1)
$

So libc6, libpam0g, and libselinux1 are already Pre-Depends of some
essential package or other, and don't pose a problem here.

login is also Essential: yes, so is only in the list because it's a
versioned dep; but it's a versioned dep on a version older than oldstable,
so we can probably prune that dep from passwd to make the essential set just
a little less tangled.  Anyway, nothing in essential currently depends on
passwd so we know there's no problematic loop here.

debianutils is likewise essential, and the versioned dep is likewise
satisfied by the version in stable (though not in oldstable).  Again the dep
could probably be pruned.

That leaves libpam-modules being pulled in, which is not currently essential
or a pre-dep of any other essential packages.  This is not a spurious
dependency on the part of passwd; actually, I'm left wondering why login has
it as a Depends instead of as a Pre-Depends, since the stock login PAM
config isn't going to work very well without those modules, so login seems
to be failing the requirement to be minimally functional while unpacked but
not configured.

But anyway, let's have a look at what promoting libpam-modules entails.

Package: libpam-modules
Version: 0.99.7.1-5
Depends: libc6 (>= 2.6.1-1), libdb4.6, libpam0g (>= 0.99.7.1), libselinux1 (>= 
2.0.15)

Three familiar libraries again, along with libdb4.6.  libdb4.6 itself has no
dependencies other than libc6.

So promoting passwd to a Pre-Depends of an Essential package doesn't
introduce any pre-dependency loops, and the only new packages pulled into
the transitively-Essential set are ones that arguably are supposed to be
there already.

As long as none of the maintainers of other Essential packages have plans to
introduce a dependency on libuuid1 that would turn this into a loop, this
looks ok to me.

(BTW, does anyone want to write an essential-checker to check for those
loops automatically? :)

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.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

[Bastian Blank]

On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:
>So, I am doing so now.  Any objections if I
> add a dependency on passwd for libuuid1?  The aternative would be to
> roll-my-own useradd/adduser functionality, but that would be a real
> PITA

There are several other possibilities:
- Move the user creation. It is necessary for uuid-runtime (uuidd), not
  libuuid.
- Drop e2fsprogs from essential. The only critical part, aka non ext2/3
  specific, it provides is /sbin/fsck IMHO.

What is the reason for this deamon anyway? It linearises the requests
and limits the amount of available uuids.

Bastian

-- 
"We have the right to survive!"
"Not by killing others."
-- Deela and Kirk, "Wink of An Eye", stardate 5710.5


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

Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

[Bill Allombert]

On Mon, Jan 07, 2008 at 01:16:59AM -0800, Steve Langasek wrote:
> On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:
> > On Sun, Jan 06, 2008 at 10:37:03AM +0100, Julien Cristau wrote:
> 
> > So e2fsprogs which is "Essential: yes" depends on libuuid1, so
> > libuuid1 is effectively "Essential: yes", right?  So if I add a
> > dependency on passwd, it will effectively make passwd "Essential:
> > yes", as well, and according to policy I should bring it up for
> > comment on debian-policy.  So, I am doing so now.
> 
> My mail headers disagree. :)  Is this really meant to be on debian-policy
> rather than debian-devel?
> 
> > Any objections if I add a dependency on passwd for libuuid1?  The
> > aternative would be to roll-my-own useradd/adduser functionality, but that
> > would be a real PITA

AFAICS libuuid1 just needs groupadd/useradd to create a user and group
'libuuid'.

Since libuuid1 is essential, every system will end up with a libuuid
user/group, so why not just add it to base-passwd instead of creating it
dynamically ?

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]

About Debian BTS

[PoayHua]

Hi, I am a student from the University Putra Malaysia. Now i am doing a
study about Debian in my final year project. i am interested about Debian's
bugs tracking system.

http://www.debian.org/doc/developers-reference/ch-resources

after i have go through above page, i think is better i ask if there have
any statistical analysis or anything related to Debian's bugs?
if there has any of it, it maybe a big help for my project.


poayhua

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Gabor Gombas]

On Sun, Jan 06, 2008 at 10:10:03AM +0100, Tollef Fog Heen wrote:

> Taking this argument a bit further, do you think that the sshd init
> script should wait until all users have saved their work and logged
> out before it gives control back to the init sequence?

On a multi-user system that would be a trivial DoS so no. Just think
what happens if someone opens a file in an editor, leaves it open and
then goes on vacation...

It's the responsibility of the sysadmin to use the '-t' option of
shutdown properly and to check that users have really logged out.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

testing migration/autobuilding postgresql-filedump-8.2

[Michael Meskes]

Could someone please explain the following to me?

According to
http://qa.debian.org/excuses.php?package=postgresql-filedump-8.2 the
package does not migrate because it is out of date on hppa. However,
http://buildd.debian.org/build.php?pkg=postgresql-filedump-8.2 says it
has been build on Dec 23 23:53 with the result maybe-successful. The
build log for this action is here:
http://buildd.debian.org/fetch.cgi?&pkg=postgresql-filedump-8.2&ver=8.2-4&arch=hppa&stamp=1198472013&file=log
This one also does not show any error.

Now the question ariss, what went wrong? And also of course could
someone please reschedule this package or do whatever is needed to get
this version into the archive.

Thanks.

Michael

-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


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

Bug#459593: RFA: dmraid

[Joachim Breitner]

Package: wnpp
Severity: normal

Hi everyone,

the utnubu team maintains a few packages, but it turned out be not a
good maintance team, so are want to give our packages away.

One of the more important packages maintained by us is dmraid, with very
few open bugs, a new version to be packaged and probably curcial to some
users. This needs a real maintainer, or a proper maintenance team, so if
you want to do it, please step up.

http://packages.qa.debian.org/d/dmraid.html

Greetings,
Joachim


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

Kernel: Linux 2.6.23-1-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: reporting BTS spam easily from Mutt

[Amaya]

Hamish Moffatt wrote:
> In case it's useful to anyone, here's a quick hack I put together for
> easy BTS spam reporting from mutt.

That is incredibly useful, is tehre any similar tool to report spam
delivered through the Debian Mailing Lists?

Sorry if this has been answered before, I am just starting to keep up
with mail backlog.

Thanks, Hamish!

-- 
  ·''`. Cheap beer & cheap chocolate - The real deal
 : :' :   
 `. `'   Proudly running Debian GNU/Linux (unstable)
   `- www.amayita.com  www.malapecora.com  www.chicasduras.com


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

Re: testing migration/autobuilding postgresql-filedump-8.2

[Cyril Brulebois]

On 07/01/2008, Michael Meskes wrote:
> Now the question ariss, what went wrong? And also of course could
> someone please reschedule this package or do whatever is needed to get
> this version into the archive.

Being built is insufficient, it has to be uploaded as well. If you want
to contact the buildd admins, [EMAIL PROTECTED]

A different status view is available at:
  http://buildd.debian.org/~jeroen/status/package.php?p=postgresql-filedump-8.2

Cheers,

-- 
Cyril Brulebois


pgpMI7vYoB8RG.pgp
Description: PGP signature

Re: About Debian BTS

[Cyril Brulebois]

On 07/01/2008, PoayHua wrote:
> after i have go through above page, i think is better i ask if there
> have any statistical analysis or anything related to Debian's bugs?
> if there has any of it, it maybe a big help for my project.

Christian Perrier posted some figures [1,2] on [3] yesterday. Some stats
about release-critical bugs are available at [4], and a bit differently
at [5] (which might be out of sync from what I've read some days ago).

 1. http://www.perrier.eu.org/weblog/2008/01/06#bugs-per-year
 2. http://www.perrier.eu.org/weblog/2008/01/06#oldest-bugs
 3. http://planet.debian.org/
 4. http://bugs.debian.org/release-critical/
 5. http://bts.turmzimmer.net/

Cheers,

-- 
Cyril Brulebois


pgpfW6KZKLhiX.pgp
Description: PGP signature

Bug#459596: RFA: gtimelog

[Joachim Breitner]

Package: wnpp
Severity: normal

Hi everyone,

the utnubu team maintains a few packages, but it turned out be not a
good maintance team, so are want to give our packages away.

One of these packages is gtimelog. gtimelog provides a time tracking
application to allow the user to track what they work on during the day
and how long they spend doing it. It has some active users according to
popcon, and no bad open bugs. It would be nice if this package could
have a proper maintainer.

http://packages.qa.debian.org/g/gtimelog.html

Greetings and thanks,
Joachim

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

Kernel: Linux 2.6.23-1-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#459597: RFA: timer-applet -- timer applet - a countdown timer applet for the GNOME panel

[Joachim Breitner]

Package: wnpp
Severity: normal


Hi everyone,

the utnubu team maintains a few packages, but it turned out be not a
good maintance team, so are want to give our packages away.

One of these packages is timer-applet

The package description is:
 Features include:
 .
  * Quickly set a time and the applet will notify you when time is up
  * Create presets for quick access to frequently-used times
  * Small and unobtrusive. Choose to either view the remaining time right in
the panel or hide it so you don't get distracted by the countdown.
  * Add multiple Timer Applets to the panel to have multiple timers running
simultaneously
  * User interface follows the GNOME Human Interface Guidelines

It has a few minor open bugs, and there is a new upstream version
waiting. According to popcon, about 200 people have it installed, but no
use numbers were generated. It would be nice if this finds a real
maintainer. It is probably suiteable for beginner maintainers as well.

Greetings and thanks,
Joachim

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

Kernel: Linux 2.6.23-1-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: Availability of wanna-build sources

[Aurelien Jarno]

Marc 'HE' Brockschmidt a écrit :
> Luk Claes <[EMAIL PROTECTED]> writes:
>> Roger Leigh wrote:
>>> Does anyone know where the sources for the current version of
>>> wanna-build in use on our buildds may be found?
>> The current version is the one of the repository you mentioned. If you
>> mean the experimental version, well I suppose that's on one of Ryan's
>> machines.
> 
> Well, the version of buildd/sbuild on some buildds is the one from
> repository, but at least wanna-build has been heavily changed since the
> last commit:
> 
> [EMAIL PROTECTED]:/tmp$ wget 
> http://svn.cyberhqz.com/svn/wanna-build/wanna-build; diff -u wanna-build 
> /org/wanna-build/bin/wanna-build | diffstat
> --10:17:33--  http://svn.cyberhqz.com/svn/wanna-build/wanna-build
>=> `wanna-build'
> Resolving svn.cyberhqz.com... 24.85.128.235
> Connecting to svn.cyberhqz.com[24.85.128.235]:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 70,851 [text/x-perl]
> 
> 100%[=>]
>  70,851   103.98K/s 
> 
> 10:17:34 (103.66 KB/s) - `wanna-build' saved [70851/70851]
> 
>  wanna-build |  624 
> +++-
>  1 files changed, 327 insertions(+), 297 deletions(-)

>From what I have observed, the wanna-build version running on buildd.d.o
correctly detects the upload of a binNMU and marks the package as
"Installed". The version from cyberhqz (the one running on
debian-ports.org) keeps the packages as "Uploaded", so the wanna-build
maintainer has to clean packages that have been binNMUed from time to time.

That's a pitty to see that the problem has been fixed, but other users
can't have the fix.

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


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

Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

[Kurt Roeckx]

On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:
> 
> So e2fsprogs which is "Essential: yes" depends on libuuid1, so
> libuuid1 is effectively "Essential: yes", right?  So if I add a
> dependency on passwd, it will effectively make passwd "Essential:
> yes", as well

It's not because an essential package Depends on something that that
should also be set to essential.  The clasical example is libc6.  Alot
of the essential package Depend on it but libc6 is not, and should not,
be essential itself.

But I think that packages which are essential that need a user/group
should get a static one in base-passwd which is essential.


Kurt


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

Bug#459625: ITP: libdmtx -- shared libraries for Data Matrix barcodes

[Todd A. Jacobs]

Package: wnpp
Severity: wishlist
Owner: "Todd A. Jacobs" <[EMAIL PROTECTED]>


* Package name: libdmtx
  Version : 0.4.0-codegnome.3
  Upstream Author : Mike Laughton <[EMAIL PROTECTED]>
* URL : http://www.libdmtx.org/
* License : LGPL
  Programming Lang: C
  Description : shared libraries for Data Matrix barcodes

Shared libraries for creating/reading Data Matrix 2D barcode symbols.
The dmtxwrite and dmtxread utilities support .png graphics for easy
integration into web-enabled applications.

NOTE: The packages are already available from the following repository:

deb http://www2.codegnome.org:59321/codegnome-debs/ sid contrib non-free
deb-src http://www2.codegnome.org:59321/codegnome-debs/ sid contrib non-free

and are just in need of a sponsor.

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

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash



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

Bug#459628: ITP: libdmtx-utils -- utilities for reading/writing Data Matrix barcodes with libdmtx

[Todd A. Jacobs]

Package: wnpp
Severity: wishlist
Owner: "Todd A. Jacobs" <[EMAIL PROTECTED]>


* Package name: libdmtx-utils
  Version : 0.4.0-codegnome.3
  Upstream Author : Mike Laughton <[EMAIL PROTECTED]>
* URL : http://www.libdmtx.org/
* License : LGPL
  Programming Lang: C
  Description : utilities for reading/writing Data Matrix barcodes with 
libdmtx

Command-line utilities for creating/reading Data Matrix 2D barcode
symbols. The dmtxwrite and dmtxread utilities support .png graphics for
easy integration into web-enabled applications.

NOTE: The packages are already available from the following repository:

deb http://www2.codegnome.org:59321/codegnome-debs/ sid contrib non-free
deb-src http://www2.codegnome.org:59321/codegnome-debs/ sid contrib non-free

and are just in need of a sponsor.

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

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash



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

Bug#459627: ITP: libdmtx-dev -- header files for libdmtx

[Todd A. Jacobs]

Package: wnpp
Severity: wishlist
Owner: "Todd A. Jacobs" <[EMAIL PROTECTED]>


* Package name: libdmtx-dev
  Version : 0.4.0-codegnome.3
  Upstream Author : Mike Laughton <[EMAIL PROTECTED]>
* URL : http://www.libdmtx.org/
* License : LGPL
  Programming Lang: C
  Description : header files for libdmtx

The libdmtx package contains the shared libraries and command-line
utilities for creating/reading Data Matrix 2D barcode symbols. Install
this package if you need the C header files to include in your source
code.

NOTE: The packages are already available from the following repository:

deb http://www2.codegnome.org:59321/codegnome-debs/ sid contrib non-free
deb-src http://www2.codegnome.org:59321/codegnome-debs/ sid contrib non-free

and are just in need of a sponsor.

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

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash



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

Re: Re: Bug#458819: ITP: nettee -- a network "tee" program

[Joe Smith]

"Joel Franco" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

- simplicity: like you already said, the simple command, without complex
 pipe setups like showed in your example comments. You have to agree
 with me that that netcat + tee pipe commands are not trivial. If I
 had known about that commands, i will not have searched for somenthing
 like nettee in Google.


Good point. However, while it did take me a few minutes to cook that up, was 
still
reasonably simple piping. The biggest trick was the '>(...)' syntax, and 
knowing the arguments to use for netcat. The rest was simple pipes and 
input/output redirection.
Definately not trivial, but not too terrible either. Command line plumbing 
can be much more complicated (although very complicated plumbing is honestly 
rarely ever useful).
But you said something very important, that I somewhat hoped you would say. 
You did seach for a utility because you did not know how to do it manually. 
That there is an important advantage to a package. In particular, having the 
manpage to document things.





- multiple target: you can specify multiple targets to send the stream
 and not only one. Use the -next hostlist1(,hostlist2(,hostlist3(...)))
 Ok.. ok.. you can make it with a complex pipe; i just can say that
 i will say again the previous argument.


You can indeed do that with complex piping, although it definately begins to 
get very large and hard to deal with. This is a useful advantage of such a 
package.




- error check in the stream data: there is a check for transmission
 errors in the code. This is util when there are failed nodes.


Yes it is indeed a useful benefit that definatly difficult to do with just 
tee and netcat.




- error handling while data is being transmited: there is a lot of
 options to the chain not die if there is a single node failure. In
 your pipe commands, if one node die, the full chain is lost.


Yes, indeed. That is a real downside to chaining like that. And something 
that a dedicated program can handle much better.


Your defense of the program here was quite good, as it does clearly show the 
benefits of such a program. A useful skill to have as a package maintainer. 
Futher, I now know to look for that utility if I ever have such a need. :D



In short, simplicity and error check.

If you liked, can you be my sponsor? :)


Unfortunately, I cannot, as IANADD.



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

Bug#459637: ITP: mustang -- multiple structural alignment of proteins

[Morten Kjeldgaard]

Package: wnpp
Severity: wishlist
Owner: Morten Kjeldgaard <[EMAIL PROTECTED]>


* Package name: mustang
  Version : 3.0
  Upstream Author : Arun S. Konagurthu <[EMAIL PROTECTED]>
* URL : http://www.cs.mu.oz.au/~arun/mustang/
  License : 3 clause BSD
  Programming Lang: C++
  Description : multiple structural alignment of proteins
   Mustang is an algorithm for structural alignment of multiple
   protein structures. Given a set of PDB files, the program uses the 
   spatial information in the Calpha atoms of the set to produce a sequence 
   alignment. Based on a progressive pairwise heuristic the algorithm 
   then proceeds through a number of refinement passes. Mustang 
   reports the multiple sequence alignment and the corresponding 
   superposition of structures.

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

Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

[Michael Biebl]

Bastian Blank wrote:

On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:

   So, I am doing so now.  Any objections if I
add a dependency on passwd for libuuid1?  The aternative would be to
roll-my-own useradd/adduser functionality, but that would be a real
PITA


There are several other possibilities:
- Move the user creation. It is necessary for uuid-runtime (uuidd), not
  libuuid.


Actually the user is created twice currently: in libuuid1.postinst and 
uuid-runtime.postinst.


Ted, could you please eloborate why you need the useradd in 
libuuid1.postinst at all?


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



signature.asc
Description: OpenPGP digital signature

Re: Proposed consensus: reporting lintian overrides

[Marc Haber]

On Sat, 05 Jan 2008 11:12:32 -0800, Russ Allbery <[EMAIL PROTECTED]>
wrote:
>For those who really don't want to see this line at all, I'll add a -q
>option to lintian that suppresses this line (and anything else like this
>that comes up later, if we have anything).

How about a configuration file and/or an environment variable to set a
local default?

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: pkg-$GROUP on Alioth: please whitelist messages from BTS

[Stephen Gran]

This one time, at band camp, Stephen Gran said:
> This one time, at band camp, Tollef Fog Heen said:
> > * Stephen Gran 
> > 
> > | The only reason is that I can't see how to do it in mailman.  AFAICT it's
> > | not easy to set that as a blanket default for all lists.  If you can se
> > | how, feel free to ping me on #alioth or off list and I'll set it up.
> > 
> > Something like:
> > 
> > add 
> > 
> > GLOBAL_PIPELINE.insert(1, 'Debian') 
> > 
> > to mm_cfg.py.
> > 
> 
> Sweet!  Thanks,

Thanks to Tolleff, Ganneff, mhy, and a combination of malted barly, hops
and water, this is now a reality on alioth.  We're using the mailman
method get_senders, which may or may not behave in exactly the way I
hope.  Please let me know if people are having problems or if other role
addresses should be added to the whitelist.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Bug#458819: ITP: nettee -- a network "tee" program

[Giovanni Mascellani]

All'incirca Mon, 7 Jan 2008 14:10:08 -0500,  "Joe Smith"
<[EMAIL PROTECTED]> sembrerebbe aver scritto:

> >- error check in the stream data: there is a check for transmission
> >  errors in the code. This is util when there are failed nodes.
> 
> Yes it is indeed a useful benefit that definatly difficult to do with
> just tee and netcat.

FYI: I maintain netrw, a small utility like netcat, but capable to
calculate checksum of the content being transferred.

Anyway, it seems that nettee makes things much simpler, so I can't see
why don't package it. Of course, IANADD and my opinion is not much
relevant!

Happy Debian!
Giovanni.
-- 
Giovanni Mascellani <[EMAIL PROTECTED]>
Pisa, Italy

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



signature.asc
Description: PGP signature

RFH: How to debug FTBFS of erlang on sparc (UltraSPARC III)?

[Sergei Golovan]

Hi!

After lebrun (which run on UltraSPARC III) became a sparc buildd host,
erlang package started to FTBFS on sparc. Logs are available at
http://buildd.debian.org/build.php?pkg=erlang but thay aren't very
informative. They show "bus error" which can't help to fix the bug.

I'd be happy to find the bug but I don't have an access to UltraSPARC
III hardware. The only available to me Debian developer sparc machine
(sperger) runs UltraSPARC II which doesn't reveal the bug.

Is there a way to debug this bug?

-- 
Sergei Golovan


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

Re: RFH: How to debug FTBFS of erlang on sparc (UltraSPARC III)?

[brian m. carlson]

On Tue, Jan 08, 2008 at 12:53:36AM +0300, Sergei Golovan wrote:

Hi!

After lebrun (which run on UltraSPARC III) became a sparc buildd host,
erlang package started to FTBFS on sparc. Logs are available at
http://buildd.debian.org/build.php?pkg=erlang but thay aren't very
informative. They show "bus error" which can't help to fix the bug.


A bus error is usually an unaligned access.


I'd be happy to find the bug but I don't have an access to UltraSPARC
III hardware. The only available to me Debian developer sparc machine
(sperger) runs UltraSPARC II which doesn't reveal the bug.

Is there a way to debug this bug?


You should probably ask [EMAIL PROTECTED] if there's a 
machine meeting those requirements that someone will let you use.


You might also determine whether the bug occurs when you build on 
UltraSPARC III, but run on UltraSPARC II; IOW, whether the problem is 
the build or execution environment.  I can assist with that, if you send 
me a gpg-signed binary.


HTH.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Bug#459656: ITP: gigedit -- foo

[Free Ekanayaka]

Package: wnpp
Severity: wishlist
Owner: Free Ekanayaka <[EMAIL PROTECTED]>


* Package name: gigedit
  Version : 0.1.1
  Upstream Author : Anreas Persson
* URL : http://www.linuxsampler.org/
* License : GPL
  Programming Lang: C++
  Description : instrument editor for Gigasampler files

 gigedit is an instrument editor allowing to modify existing Gigasampler
 files, as well as creating new ones from scratch. The GUI is based on
 the GTK+ (gtkmm) toolkit. Even though it is created as a subproject of
 the LinuxSampler project, it is currently a completely independent
 stand-alone editor.
 .
 For more information visit
 http://www.linuxsampler.org

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (1001, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)



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

Re: RFH: How to debug FTBFS of erlang on sparc (UltraSPARC III)?

[Sergei Golovan]

On 1/8/08, brian m. carlson <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 08, 2008 at 12:53:36AM +0300, Sergei Golovan wrote:
> >Hi!
> >
> >After lebrun (which run on UltraSPARC III) became a sparc buildd host,
> >erlang package started to FTBFS on sparc. Logs are available at
> >http://buildd.debian.org/build.php?pkg=erlang but thay aren't very
> >informative. They show "bus error" which can't help to fix the bug.
>
> A bus error is usually an unaligned access.

I understand that.

>
> >I'd be happy to find the bug but I don't have an access to UltraSPARC
> >III hardware. The only available to me Debian developer sparc machine
> >(sperger) runs UltraSPARC II which doesn't reveal the bug.
> >
> >Is there a way to debug this bug?
>
> You should probably ask [EMAIL PROTECTED] if there's a
> machine meeting those requirements that someone will let you use.

The initial message was crossposted to [EMAIL PROTECTED] too.

>
> You might also determine whether the bug occurs when you build on
> UltraSPARC III, but run on UltraSPARC II; IOW, whether the problem is
> the build or execution environment.  I can assist with that, if you send
> me a gpg-signed binary.

I can't build it on UltraSPARC III because I don't have an access to
it. The binaries that are built on UltraSPARC II don't work on
UltraSPARC III (It can be concluded from FTBFS of erlang-based
packages (e.g. ejabberd which FTBFS too currently).

I guess you might start building erlang on UltraSPARC III and after
virtual machine is built (executables beam*) you could simply replace
existing binaries from erlang-base (version 11.b.5-8) and try it on
UltraSPARC II. But I'm afraid it's too complicated.

-- 
Sergei Golovan


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

Re: Proposed consensus: reporting lintian overrides

[Russ Allbery]

Marc Haber <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> wrote:

>> For those who really don't want to see this line at all, I'll add a -q
>> option to lintian that suppresses this line (and anything else like
>> this that comes up later, if we have anything).

> How about a configuration file and/or an environment variable to set a
> local default?

It's probably easiest at the moment to use an alias.  Lintian's
configuration handling is very odd at the moment, and I haven't had a
chance to take a deep look at it and try to figure out how I want to
rework it.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: RFH: How to debug FTBFS of erlang on sparc (UltraSPARC III)?

[Emanuele Rocca]

Hello Sergei,

* Sergei Golovan <[EMAIL PROTECTED]>, [2008-01-08  0:53 +0300]:
>  I'd be happy to find the bug but I don't have an access to UltraSPARC
>  III hardware. 

I do have access to an Ultrasparc III+ workstation, I can try to
reproduce the bug tomorrow. 

ciao,
ema


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

Re: Re: Bug#458819: ITP: nettee -- a network "tee" program

[Joel Franco]

On Mon Jan 07 08 14:10, Joe Smith wrote:
>
> "Joel Franco" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
>> - simplicity: like you already said, the simple command, without complex
>>  pipe setups like showed in your example comments. You have to agree
>>  with me that that netcat + tee pipe commands are not trivial. If I
>>  had known about that commands, i will not have searched for somenthing
>>  like nettee in Google.
>
> Good point. However, while it did take me a few minutes to cook that up, 
> was still
> reasonably simple piping. The biggest trick was the '>(...)' syntax, and 
> knowing the arguments to use for netcat. The rest was simple pipes and 
> input/output redirection.

Exact. I didn't how to make it works, and have never seen a pipe
sequence like the yours.

> Definately not trivial, but not too terrible either. Command line plumbing 
> can be much more complicated (although very complicated plumbing is 
> honestly rarely ever useful).
> But you said something very important, that I somewhat hoped you would say. 
> You did seach for a utility because you did not know how to do it manually. 
> That there is an important advantage to a package. In particular, having 
> the manpage to document things.

I'm happy that you agree. :)

>
>
>
>> - multiple target: you can specify multiple targets to send the stream
>>  and not only one. Use the -next hostlist1(,hostlist2(,hostlist3(...)))
>>  Ok.. ok.. you can make it with a complex pipe; i just can say that
>>  i will say again the previous argument.
>
> You can indeed do that with complex piping, although it definately begins 
> to get very large and hard to deal with. This is a useful advantage of such 
> a package.
>
>
>> - error check in the stream data: there is a check for transmission
>>  errors in the code. This is util when there are failed nodes.
>
> Yes it is indeed a useful benefit that definatly difficult to do with just 
> tee and netcat.
>
>
>> - error handling while data is being transmited: there is a lot of
>>  options to the chain not die if there is a single node failure. In
>>  your pipe commands, if one node die, the full chain is lost.
>
> Yes, indeed. That is a real downside to chaining like that. And something 
> that a dedicated program can handle much better.
>
> Your defense of the program here was quite good, as it does clearly show 
> the benefits of such a program. A useful skill to have as a package 
> maintainer. Futher, I now know to look for that utility if I ever have such 
> a need. :D

I'm happy again that you approve the nettee in the Debian dist.

>
>> In short, simplicity and error check.
>>
>> If you liked, can you be my sponsor? :)
>
> Unfortunately, I cannot, as IANADD.

:( Ok.

Thank you by your positive words.

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

-- 
|
| Joel Franco Guzmán  .''`.
|  self-powered by   : :' :
|   Debian Linux `. `' 
|  `- 


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

Re: Bug#458819: ITP: nettee -- a network "tee" program

[Joel Franco]

On Mon Jan 07 08 22:08, Giovanni Mascellani wrote:
>All'incirca Mon, 7 Jan 2008 14:10:08 -0500,  "Joe Smith"
><[EMAIL PROTECTED]> sembrerebbe aver scritto:
>
>> >- error check in the stream data: there is a check for transmission
>> >  errors in the code. This is util when there are failed nodes.
>> 
>> Yes it is indeed a useful benefit that definatly difficult to do with
>> just tee and netcat.
>
>FYI: I maintain netrw, a small utility like netcat, but capable to
>calculate checksum of the content being transferred.

Hi Giovanni,

It appears to be a life easier too :)

>
>Anyway, it seems that nettee makes things much simpler, so I can't see
>why don't package it. Of course, IANADD and my opinion is not much
>relevant!

Ooowww.. sorry.. but your oppinion is really important to vote the
software that you want in Debian.

Your email is positive, especially for me that wants nettee in the
official tree.

HEY SPONSORS.. PLEASE LOOK NETTEE :)

Regards.

>
>Happy Debian!
>Giovanni.
>-- 
>Giovanni Mascellani <[EMAIL PROTECTED]>
>Pisa, Italy
>
>Web: http://giomasce.altervista.org
>SIP: [EMAIL PROTECTED]
>Jabber: [EMAIL PROTECTED] / [EMAIL PROTECTED]
>GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD  003F FCB0 BB5C 5F1F BF70)
>



-- 
|
| Joel Franco Guzmán  .''`.
|  self-powered by   : :' :
|   Debian Linux `. `' 
|  `- 


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

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

Michal Čihař wrote:
> Hi
> 
> On Wed, 02 Jan 2008 13:58:24 -0600
> Raphael Geissert <[EMAIL PROTECTED]> wrote:
> 
>> Michal Čihař <[EMAIL PROTECTED]>
>>libgammu3
> 
> Eh?

Seems like it is one of the very few false positives of the old script.
The fresh reports using grep-ctrl instead of a lot of grep's (which seem to
have caused some false positives) can be found at:

http://alioth.debian.org/~atomo64-guest/should-be-arch-all.txt
http://alioth.debian.org/~atomo64-guest/should-be-arch-all.by-maint.txt

Both updated weekly

> 
> $ apt-cache show libgammu3 | grep ^Dep
> Depends: libbluetooth2 (>= 3.0), libc6 (>= 2.7-1), libgammu-common (>=
> 1.17.0-1)
> 

Cheers,
Raphael Geissert


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

Correct spelling/capitalisation of project names

[Raphael Geissert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello everybody,

Some weeks ago I noticed that some package descriptions incorrectly spell
some project names, mainly because of capitalisation.
For example GNOME is being spelt in some packages as Gnome, or simply gnome,
when its right spelling: GNOME. Other project names such as Debian, KDE and
Linux aren't being correctly capitalised.

Neil Williams has requested me on #456495 to seek a concensus on this
subject, hence the reason of this message.

Starting with lintian v1.23.42 the spelling check also looks for the correct
spelling of the above mentioned project names (requested at #456582).
Because I made an archive wide lintian check (except for arch all packages)
with the latest lintian version here are some lists of packages spelling
some project names incorrectly.

Feedback, as usually, is welcome.

Kind regards,
Raphael Geissert

- 

### KDE ###

Michael Ablassmeier <[EMAIL PROTECTED]>
   kstreamripper

Luca Bedogni <[EMAIL PROTECTED]>
   krecordmydesktop

Fathi Boudra <[EMAIL PROTECTED]>
   kasablanca (U)
   klibido (U)
   knetworkconf (U)

Fathi Boudra <[EMAIL PROTECTED]>
   kdmtheme (U)

Emmanuel Bouthenot <[EMAIL PROTECTED]>
   kwin-style-knifty

Debian KDE Extras Team <[EMAIL PROTECTED]>
   kasablanca
   kdmtheme
   klibido

Debian Qt/KDE Maintainers <[EMAIL PROTECTED]>
   knetworkconf

Debian X Strike Force <[EMAIL PROTECTED]>
   compizconfig-backend-kconfig

Sean Finney <[EMAIL PROTECTED]>
   compizconfig-backend-kconfig (U)

Ana Beatriz Guerrero Lopez <[EMAIL PROTECTED]>
   knetworkconf (U)

Christopher Martin <[EMAIL PROTECTED]>
   knetworkconf (U)

Martin Maurer <[EMAIL PROTECTED]>
   fireflier-client-kde

Kel Modderman <[EMAIL PROTECTED]>
   kdmtheme (U)

Mark Purcell <[EMAIL PROTECTED]>
   kasablanca (U)
   kdmtheme (U)
   klibido (U)

Riccardo Stagni <[EMAIL PROTECTED]>
   qingy

Modestas Vainius <[EMAIL PROTECTED]>
   knetworkconf (U)

Sune Vuorela <[EMAIL PROTECTED]>
   knetworkconf (U)
   kommando
   kwin-style-dekorator
   kwin-style-powder

### Debian ###

Bill Allombert <[EMAIL PROTECTED]>
   menu

Adam D. Barratt <[EMAIL PROTECTED]>
   devscripts (U)

Dave Beckett <[EMAIL PROTECTED]>
   libcairo-directfb2-dev

Christoph Berg <[EMAIL PROTECTED]>
   devscripts (U)

Edward Betts <[EMAIL PROTECTED]>
   gcal

A. Maitland Bottoms <[EMAIL PROTECTED]>
   predict

Ben Burton <[EMAIL PROTECTED]>
   libreadline-java

Luk Claes <[EMAIL PROTECTED]>
   devscripts (U)

Julien Danjou <[EMAIL PROTECTED]>
   libirman-dev (U)

Debian-Med Packaging Team <[EMAIL PROTECTED]>
   clustalw

Devscripts Devel Team <[EMAIL PROTECTED]>
   devscripts

Robert S. Edmonds <[EMAIL PROTECTED]>
   python-pypcap

Exim4 Maintainers <[EMAIL PROTECTED]>
   exim4-base

Bdale Garbee <[EMAIL PROTECTED]>
   predict (U)

Hector Garcia <[EMAIL PROTECTED]>
   libirman-dev (U)

Julian Gilbey <[EMAIL PROTECTED]>
   devscripts (U)

Filippo Giunchedi <[EMAIL PROTECTED]>
   devscripts (U)

Marc Haber <[EMAIL PROTECTED]>
   exim4-base (U)

Joey Hess <[EMAIL PROTECTED]>
   devscripts (U)

Robert D. Hilliard <[EMAIL PROTECTED]>
   dictd (U)

Kirk Hilliard <[EMAIL PROTECTED]>
   dictd

Matthias Klose <[EMAIL PROTECTED]>
   isdnvbox (U)
   isdnvboxclient (U)
   isdnvboxserver (U)

Carlos Laviola <[EMAIL PROTECTED]>
   bplay

Bernhard R. Link <[EMAIL PROTECTED]>
   reprepro

lirc Maintainer Team <[EMAIL PROTECTED]>
   libirman-dev

Jan Luebbe <[EMAIL PROTECTED]>
   kvm

Andreas Metzler <[EMAIL PROTECTED]>
   exim4-base (U)

Loic Minier <[EMAIL PROTECTED]>
   libirman-dev (U)

Steffen Moeller <[EMAIL PROTECTED]>
   clustalw (U)

Jan Niehusmann <[EMAIL PROTECTED]>
   qca-tls

Niv Altivanik (Debian Packages) <[EMAIL PROTECTED]>
   skippy

Charles Plessy <[EMAIL PROTECTED]>
   clustalw (U)

Roland Marcus Rutschmann <[EMAIL PROTECTED]>
   libmdc2
   libmdc2-dev
   medcon
   xmedcon

Anibal Monsalve Salazar <[EMAIL PROTECTED]>
   xtranslate

Amaya Rodrigo Sastre <[EMAIL PROTECTED]>
   libirman-dev (U)

Martin Schulze <[EMAIL PROTECTED]>
   dhcpdump
   dhcping

Paul Slootman <[EMAIL PROTECTED]>
   isdnvbox
   isdnvbox (U)
   isdnvboxclient
   isdnvboxclient (U)
   isdnvboxserver
   isdnvboxserver (U)

Ralf Treinen <[EMAIL PROTECTED]>
   edos-debcheck

Mohammed Adnène Trojette <[EMAIL PROTECTED]>
   devscripts (U)

James Vega <[EMAIL PROTECTED]>
   devscripts (U)

Paul Wise <[EMAIL PROTECTED]>
   nsis

Stefano Zacchiroli <[EMAIL PROTECTED]>
   devscripts (U)

Martin Zobel-Helas <[EMAIL PROTECTED]>
   devscripts (U)

### GNOME ###

Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]>
   gwc

Adam Cécile (Le_Vert) <[EMAIL PROTECTED]>
   deluge-torrent
   libmcs-backend-gconf

Masayuki Hatta (mhatta) <[EMAIL PROTECTED]>
   abiword-plugins-gnome

J.H.M. Dassen (Ray) <[EMAIL PROTECTED]>
   gnome-spell (U)
   gweled (U)

Jari Aalto <[EMAIL PROTECTED]>
   fspanel

Moray Allan <[EMAIL PROTECTED]>
   gpe-ap

Re: Correct spelling/capitalisation of project names

[Russ Allbery]

Raphael Geissert <[EMAIL PROTECTED]> writes:

> Starting with lintian v1.23.42 the spelling check also looks for the
> correct spelling of the above mentioned project names (requested at
> #456582).  Because I made an archive wide lintian check (except for arch
> all packages) with the latest lintian version here are some lists of
> packages spelling some project names incorrectly.

For folks who think this is annoyingly picky, well, it sort of is, but I
decided to add the check to lintian anyway only for package descriptions
(and doc-base titles and abstracts).  It doesn't try to check other files,
in part because it doesn't matter as much elsewhere and in part because
there are too many false positives from configuration file fragments and
similar things.

But descriptions have a fairly limited content and aren't that subject to
false positives, and they're also the main thing that users see for our
packages.  I think it's worth being a little picky about spelling,
punctuation, wording, and so forth with package descriptions in order to
create a consistent impression as much as we can.  Lintian can't help with
checking most of that, but it can at least check for common capitalization
and spelling errors.

Note that if you want to refer to a specific package, you can quote the
word to indicate that it's a literal value, although that should be a
fairly rare problem.

If you see false positives that Lintian can avoid, please feel free to
file bugs against Lintian so that we can tweak things.

This joins the capitalization checks that Lintian has been doing for a
while for language names.  (And note that Lintian no longer applies the
language name capitalization check to other files such as changelog, since
there were too many false positives.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Raphael Geissert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello all,

Some time ago I noticed some packages were defining a RPATH on non i386
architectures, notably amd64. This seems to be caused by an old auto* file,
but there might be other reasons as well.

I've run an archive wide lintian check on all the Arch: amd64 packages in
sid in order to detect those packages and surprisingly I've found _409_ of
them.

Of course some packages do need to define the rpath in some cases, reason
why in the next list I'm only including those which were defining an rpath
matching this regexp /usr/lib(64)?$ 
And yes, the number 409 applies to only those matching that regexp, of
course there might be other paths which could be checked too.

The archive wide results are available[1] for download in case anyone wants
to take a look at them (the only package with partial results is
libwine-dev which I killed after four hours checking the man pages) or
whatever. The files are called just like the binary file because of
simplicity, e.g. devscripts_2.10.12_amd64.deb

For those who might not be aware of it, lintian.d.o only shows the results
of the package checks performed on source and i386 binary packages. This is
the reason why a package may not appear on the
binary-or-shlib-defines-rpath report page and being listed here.

I hope some great progress can be done on this subject before lenny is
released.

And of course, the lintian results on which the next list of binary packages
is based can also be downloaded[3] so there's no need to download
the .tar.gz and search for each and every single package ;-).

Any kind of feedback, as usually, is welcome.

[1] http://alioth.debian.org/~atomo64-guest/lintian-v1.23.42-amd64.tar.gz
[2] http://lintian.debian.org/reports/Tbinary-or-shlib-defines-rpath.html
[3] http://alioth.debian.org/~atomo64-guest/rpath_amd64.raw.list.gz

Kind regards,
Raphael Geissert

- -

Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]>
   jack-rack
   ladcca-bin
   ladccad
   lash-bin
   lashd
   rezound
   swami
   xmms-jackasyn (U)

Davide Puricelli (evo) <[EMAIL PROTECTED]>
   xchat

Anibal Avelar (Fixxxer) <[EMAIL PROTECTED]>
   libbio2jack0

Laszlo Boszormenyi (GCS) <[EMAIL PROTECTED]>
   libneon25
   libneon26
   libneon26-gnutls
   libneon27
   libneon27-gnutls
   xsidplay

Ying-Chun Liu (PaulLiu) <[EMAIL PROTECTED]>
   macopix-gtk2

Stefan Hornburg (Racke) <[EMAIL PROTECTED]>
   courier-authlib
   courier-base
   courier-maildrop
   courier-mlm
   courier-mta

J.H.M. Dassen (Ray) <[EMAIL PROTECTED]>
   gdesklets (U)
   gnome-keyring-manager (U)
   gnome-netstatus-applet (U)
   libgnetwork1.0-0 (U)
   libgnomeprintui2.2-0 (U)
   netspeed (U)
   python-gnome2-extras (U)

Jari Aalto <[EMAIL PROTECTED]>
   fbdesk

Russ Allbery <[EMAIL PROTECTED]>
   libapache2-mod-shib
   libsaml5

Micah Anderson <[EMAIL PROTECTED]>
   silc (U)
   util-vserver

Nacho Barrientos Arias <[EMAIL PROTECTED]>
   libakode2 (U)

Sebastien Bacher <[EMAIL PROTECTED]>
   easytag
   gdesklets (U)
   gnome-netstatus-applet (U)
   libgnetwork1.0-0 (U)
   libgnomesu0
   netspeed
   python-glade2
   python-gnome2
   python-gnome2-extras
   python-gobject (U)
   python-gobject-dbg (U)
   python-gtk2
   python-pyorbit
   rubrica

Alan Baghumian <[EMAIL PROTECTED]>
   sabayon (U)

Artem Baguinski <[EMAIL PROTECTED]>
   drscheme (U)
   mzscheme (U)

Michael Banck <[EMAIL PROTECTED]>
   gamin
   libsyncml-utils
   python-gamin

Mirco Bauer <[EMAIL PROTECTED]>
   libevolution3.0-cil (U)

Daniel Baumann <[EMAIL PROTECTED]>
   giflib-tools
   grip
   librpcsecgss3 (U)
   open-vm-tools

Florent Bayle <[EMAIL PROTECTED]>
   klamav
   libpano12-0
   libpano12-bin

Dave Beckett <[EMAIL PROTECTED]>
   python-cairo
   python-cairo-dbg

Bradley Bell <[EMAIL PROTECTED]>
   libbakery-2.4-1
   libgtkextra-1.0-0
   libpanelappletmm-2.6-1c2

John V. Belmonte <[EMAIL PROTECTED]>
   libxmlsec1
   libxmlsec1-gnutls
   libxmlsec1-nss
   libxmlsec1-openssl
   xmlsec1

CJ van den Berg <[EMAIL PROTECTED]>
   pulseaudio-module-jack

Chris Vanden Berghe <[EMAIL PROTECTED]>
   libmeanwhile1

Michael Biebl <[EMAIL PROTECTED]>
   consolekit (U)
   dbus (U)
   gnome-device-manager (U)
   gnome-mount
   hal (U)
   libgnome-device-manager0 (U)
   libhal-storage1 (U)
   libhal1 (U)
   libnm-glib0 (U)
   libnm-util0 (U)
   libpam-ck-connector (U)
   network-manager (U)
   network-manager-gnome (U)
   rsyslog-mysql

Jérémy Bobbio <[EMAIL PROTECTED]>
   silc (U)

Ed Boraas <[EMAIL PROTECTED]>
   gtk2-engines
   netspeed (U)

Fathi Boudra <[EMAIL PROTECTED]>
   kasablanca (U)
   keep (U)
   kmymoney2 (U)
   ksplash-engine-moodin (U)
   ksynaptics (U)
   libarts1c2a (U)

John Bovey <[EMAIL PROTECTED]>
   libnjb-examples
   libnjb5

Rob Bradford <[EMAIL PROTECTED]>
   netspeed (U)

Marc 'HE' Brockschmidt <[EMAIL PROTECTED]>
   eog (U)
   gdesklets (U)
   gnome-netstatus-applet (U)
   libbonobo2-0 (U)
   libbonobo2-common (U)
   libbonoboui2-0 (U)
   libbonoboui2-dev (U)
   libgnetwork1.0

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Michal Čihař]

Hi

On Mon, 07 Jan 2008 22:02:17 -0600
Raphael Geissert <[EMAIL PROTECTED]> wrote:

> Michal Čihař <[EMAIL PROTECTED]>
>enca

Fixed in svn.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Russ Allbery]

Raphael Geissert <[EMAIL PROTECTED]> writes:

> Some time ago I noticed some packages were defining a RPATH on non i386
> architectures, notably amd64. This seems to be caused by an old auto*
> file, but there might be other reasons as well.

The problem is with the following code in libtool.m4:

  # Append ld.so.conf contents to the search path
  if test -f /etc/ld.so.conf; then
lt_ld_extra=`$SED -e 's/[:,\t]/ /g;s/=[^=]*$//;s/=[^= ]* / /g' 
/etc/ld.so.conf | tr '\n' ' '`
sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff} $lt_ld_extra"
  fi

(Taken from the OpenSAML package, which has "serial 47" as the version
number.)

${libsuff} is defined to 64 on 64-bit Linux in the libtool logic, and
therefore libtool thinks that the only normal library search paths are
/lib64 and /usr/lib64.  Then, when libtool is invoked to install a library
in /usr/lib, it thinks that's a non-standard library and adds an rpath.

Note that this problematic code is not present in the current Debian
version of libtool.  The equivalent part of Debian's libtool has:

  # Append ld.so.conf contents to the search path
  if test -f /etc/ld.so.conf; then
lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s", \[$]2)); 
skip = 1; } { if (!skip) print \[$]0; skip = 0; }' < /etc/ld.so.conf | $SED -e 
's/#.*//;s/[:,]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d' | tr '\n' ' '`
sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
  fi

Therefore, rerunning libtoolize before compilation will fix this problem
for most packages.  The latest upstream libtool release also fixes this
problem (with slightly different code that the current Debian package), so
if upstream upgrades their version of libtool before their next release,
that should also stop libtool from adding an rpath.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Russ Allbery]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Therefore, rerunning libtoolize before compilation will fix this problem
> for most packages.

Hm, actually, since it's in the .m4 file and not in ltmain.sh, you may
have to do more than that.  I'd have to experiment.  I'm not completely
sure what libtoolize will do and whether it will mangae to upgrade the .m4
file in all circumstances.  aclocal may actually be more helpful, but if
upstream copied libtool.m4 into their package, you may have to actually
overwrite it.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Michal Čihař]

Hi

On Mon, 07 Jan 2008 20:24:35 -0800
Russ Allbery <[EMAIL PROTECTED]> wrote:

> Russ Allbery <[EMAIL PROTECTED]> writes:
> 
> > Therefore, rerunning libtoolize before compilation will fix this problem
> > for most packages.
> 
> Hm, actually, since it's in the .m4 file and not in ltmain.sh, you may
> have to do more than that.  I'd have to experiment.  I'm not completely
> sure what libtoolize will do and whether it will mangae to upgrade the .m4
> file in all circumstances.  aclocal may actually be more helpful, but if
> upstream copied libtool.m4 into their package, you may have to actually
> overwrite it.

Adding --disable-rpath to configure might be easier solution for this
problem.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Russ Allbery]

Michal Čihař <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> wrote:

>> Hm, actually, since it's in the .m4 file and not in ltmain.sh, you may
>> have to do more than that.  I'd have to experiment.  I'm not completely
>> sure what libtoolize will do and whether it will mangae to upgrade the
>> .m4 file in all circumstances.  aclocal may actually be more helpful,
>> but if upstream copied libtool.m4 into their package, you may have to
>> actually overwrite it.

> Adding --disable-rpath to configure might be easier solution for this
> problem.

Unfortunately, if the upstream libtool macros are old enough to have this
problem, they may not have --disable-rpath either.  OpenSAML doesn't.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Raphael Geissert]

Hi,

Michal Čihař wrote:
> 
> Adding --disable-rpath to configure might be easier solution for this
> problem.
> 

I've found packages that even when the --disable-rpath flag is set the
binaries have a defined rpath.
This is actually how I noticed the whole rpath problem on non i386 archs the
first time.

Cheers,
Raphael Geissert


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

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Cyril Brulebois]

On 08/01/2008, Michal Čihař wrote:
> Adding --disable-rpath to configure might be easier solution for this
> problem.

Another workaround is chrpath.

-- 
Cyril Brulebois


pgp0znAJnoiDS.pgp
Description: PGP signature

Re: Correct spelling/capitalisation of project names

[Yves-Alexis Perez]

On lun, 2008-01-07 at 20:06 -0600, Raphael Geissert wrote:
> Some weeks ago I noticed that some package descriptions incorrectly
> spell
> some project names, mainly because of capitalisation.
> For example GNOME is being spelt in some packages as Gnome, or simply
> gnome,
> when its right spelling: GNOME. Other project names such as Debian,
> KDE and
> Linux aren't being correctly capitalised.
> 
Could you add Xfce to the list? This is the correct spelling, not XFce
nor XFCE.

Thanks :)
-- 
Yves-Alexis


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

Re: Correct spelling/capitalisation of project names

[Christian Perrier]

Quoting Raphael Geissert ([EMAIL PROTECTED]):

> For example GNOME is being spelt in some packages as Gnome, or simply gnome,
> when its right spelling: GNOME. Other project names such as Debian, KDE and
> Linux aren't being correctly capitalised.
> 
> Neil Williams has requested me on #456495 to seek a concensus on this
> subject, hence the reason of this message.


Note that this is something we enforce when reviewing packages'
descriptions in the Smith reviews for English (but that project is
awfully slow given the low resources we have and we're still currently
focused on packages with debconf templates, which were the first
target).

May I suggest adding some other project names which capitalization is
not always obvious. Others can probably add more of these, but at
least, coming to my mind right now:

Python
MySQL
PostgreSQL




signature.asc
Description: Digital signature

Re: Correct spelling/capitalisation of project names

[Russ Allbery]

Yves-Alexis Perez <[EMAIL PROTECTED]> writes:

> Could you add Xfce to the list? This is the correct spelling, not XFce
> nor XFCE.

Added to Lintian.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Correct spelling/capitalisation of project names

[Russ Allbery]

Christian Perrier <[EMAIL PROTECTED]> writes:

> May I suggest adding some other project names which capitalization is
> not always obvious. Others can probably add more of these, but at
> least, coming to my mind right now:
>
> Python
> MySQL
> PostgreSQL

Added to Lintian, along with the postgressql misspelling.

BTW, the way that the Lintian spell-checking works is that it looks for
errors rather than looking for each word in a dictionary.  It has a table
of pairs of error and correct word.  So if you notice any common
misspelled words that Lintian doesn't catch, please let debian-lint-maint
know and we'll add them to the table.  That's how the table was built in
the first place, I believe.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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