Dear Debian maintainer,

The wacom-tools Debian package, which you are the maintainer of, has
pending bug report(s) which include translation updates or fixes
for po-debconf, namely bug number 491415 (and maybe other similar bugs).

Even though this bug is quite recent, the release of Debian is now
getting closer and an opportunity should be taken to not only fix
that l10n bug, but also get more translations for your package.
Even after the freeze, updates that only contain l10n are allowed. NOW is th emoment to fix this.

In case you can't update your package, I have the intention, as part
of a more general action of the Debian i18n Task Force to build and
possibly upload a non-maintainer upload for wacom-tools in order to fix
this as well as all pending translations for the debconf templates.

Of course, as you seem pretty active on that package, an upload by you
would also be OK...as long as it allows a round of translation
updates.

Such changes are always harmless, which explains why I safely consider
building NMU's for such issues even though they're obviously non critical.

The schedule for the NMU (in case it happens, that is if you agree with it
or if I don't receive any answer in 10 days) is roughly the following:

Dear Debian maintainer,

The foomatic-filters Debian package, which you are the maintainer of, has
pending bug report(s) which include translation updates or fixes
for po-debconf, namely bug number 491416 (and maybe other similar bugs).

We're now getting very close to the release and fixing l10n bugs should be done now. Letting such bugs sleep in the BTS is simply lowering
the chances that your package interaction with its users may be done
in something else than the English language. It is also not
encouraging for translators.

I have the intention, as part of a more general action of the Debian
i18n Task Force to build and possibly upload a non-maintainer upload
for foomatic-filters in order to fix this as well as all pending translations
for the debconf templates.

Of course, an upload made by you would even be better...:-)

Such changes are always harmless, which explains why I safely consider
building NMU's for such issues even though they're obviously non critical.

The schedule for the NMU (in case it happens, that is if you agree with it
or if I don't receive any answer in 10 days) is roughly the following:

It looks as in postinst
it should be

install-info --section Development -- libidn11-dev

in spite of

install-info --section libidn11-dev Development

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

I think it's the wireless drivers, but they've worked on 2.6.24 and
earlier. Here's a list of the modules I've tried, that I built with
module-assistant:
madwifi-modules-2.6.18-4-amd64_0.9.3-2+2.6.18.dfsg.1-12_amd64.deb
madwifi-modules-2.6.21-2-amd64_0.9.3-3+2.6.21-10.00.Custom_amd64.deb
madwifi-modules-2.6.21-2-amd64_0.9.3-3+2.6.21-6_amd64.deb
madwifi-modules-2.6.22-1-amd64_0.9.3-3+2.6.22-3_amd64.deb
madwifi-modules-2.6.22-3-amd64_0.9.3.2-2+2.6.22-6.lenny1_amd64.deb
madwifi-modules-2.6.22-hrt6_0.9.3.2-1+2.6.22-hrt6-10.00.Custom_amd64.deb
madwifi-modules-2.6.24-1-amd64_0.9.4~rc2-1+2.6.24-4_amd64.deb
madwifi-modules-2.6.25-2-amd64_0.9.4~rc2-1+2.6.25-5_amd64.deb
madwifi-modules-2.6.25-2-amd64_0.9.4~rc2-1+2.6.25-6_amd64.deb
madwifi-modules-2.6.26-1-amd64_0.9.4+r3772.20080716-1+2.6.26-3_amd64...

Package: irssi
Version: 0.8.12-5
Severity: normal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have both the OTR and XMPP plugins for irssi installed on my system
(see below for versions).

irssi will reliably segfault if i do the following (using a real
account on a real XMPP server, of course):

/load xmpp
/xmppconnect -ssl foo@example.org ABC123
/load otr
/quit

If the connection to the XMPP server is not made, the segfault does
not seem to happen.

I get what i think is a SIGABRT (return code 134) if i do a different
sequence:

Zack Weinberg wrote:

Package: linux-image-2.6.26-1-amd64
Version: 2.6.26-4
Severity: normal

Booting into linux-image-2.6.26 kills my HDA ATI SB sound card
(integrated into Gigabyte GA-MA69GM-S2H motherboard).  When I boot back
into linux-image-2.6.25 the sound works fine.  In 2.6.26 KMix lists the
card but doesn't show any volume bars.

-- Package-specific info:

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

Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Zack Weinberg wrote:

Package: konqueror
Version: 4:3.5.9.dfsg.1-5
Severity: normal

If I log into my http://www.blogspot.com/ account, I can edit the title
and the tag list, but neither the main contents of the blog post nor the
cursor display in the main edit box. Cannot edit, cannot add content.

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

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

Versions of packages konqueror depends on:
ii kcontrol 4:3.5.9.dfsg.1-5 control center for KDE
ii kdebase-kio-plugins 4:3.5.9.dfsg.1-5 core I/O slaves for KDE
ii kdelibs4c2a ...

Package: debhelper
Version: 7.0.15
Severity: wishlist

waf is a configure/build infrastructure inspired by scons. It is
currently used by the midori and xmms2 upstreams (and possibly
others). It would be nice if the dh_auto_* scripts detected and used
the waf. Note that Midori provides both waf and a deprecated
autotools build infrastructure, so I'd prefer dh to prioritize waf
higher than autotools when choosing which one to run.

I guess the test for "is this upstream using waf?" should be

-f "waf" and -f "wscript"

According to ./waf --help, it has the following targets:

configure build install clean dist distclean uninstall distcheck

The first few map straight onto dh_auto_* rules; I don't know if
distcheck = dh_auto_test. Possibly dh_auto_test should do nothing if
it finds a ./waf file.