Package: libp11-0
Version: 0.2.3-2
Severity: wishlist

As a result of a vulnerability discovered against OpenSC [1], new
releases of the various elements of the project have been published.
Among those is a new version of libp11: 0.2.4. Would it be possible to
release a new version of the package (there is a functionality I am
interested in in the new version).

Thanks for your work,

Cheers,

a+

[1] http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/7365

Package: v86d
Version: 0.1.5.2-1
Severity: normal

Hey,

I tried to use the new v86d from the initramfs so I could have a framebuffer
in early stages, but it doesn't work.

Logs say:

Aug 1 08:11:06 hidalgo kernel: agpgart: Detected an Intel 965GM Chipset.
Aug 1 08:11:06 hidalgo kernel: agpgart: Detected 7676K stolen memory.
Aug 1 08:11:06 hidalgo kernel: agpgart: AGP aperture is 256M @ 0xe0000000
Aug 1 08:11:06 hidalgo kernel: uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
Aug 1 08:11:06 hidalgo kernel: uvesafb: vbe_init() failed with -22
Aug 1 08:11:06 hidalgo kernel: uvesafb: probe of uvesafb.0 failed with error -22

As you may know I run a Thinkpad T61 full intel and can provide other stuff. I didn't specify a mode in the /etc/initramfs-tools/modules line because anyway bios doesn't send 1400x1050 as a valid resolution for my screen.

If you need more info, please ask :)

Cheers,

--
Yves-Alexis

Dear Giridhar,

Could you please consider my patch for limit the used bandwidth for scp
part?

The scp command provides "-l" option which can be used to limit the
bandwidth. The unit is Kbits/sec, not Kbytes/sec.

I'm making a patch for this. Could you please check if it is possible to
included it into the dput package?

Many Thanks,
Paul

--
PaulLiu(劉穎駿)
E-mail address: grandpaul@gmail.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Chris Lamb wrote:

Hi Gerrit,

You marked this bug as "forwarded" but I don't see anything on the mailing
list about it; should I just look harder?

Regards,

--
Chris Lamb, UK chris@chris-lamb.co.uk
GPG: 0x634F9A20

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkiSpmIACgkQ5/8uW2NPmiBXfQCeMwGF4K8v7DHbK2ZyiX1z2/NK
qBgAn1XthW31vZmtQ+Ljm+8afS2HtMVf
=tMEn
-----END PGP SIGNATURE-----

Package: aufs
Version: 0+20080719-1
Severity: serious
Tags: patch

Hi jak,

as you probably already know, there is a quite inconvenient bug in
sid+lenny's aufs, which is blocking renames, caused by deadlocks. That
means that one can't update the apt cache through apt-get/aptitude, at
the very least (it's not like rename() is something very rare anyway),
which IMHO makes it unfit for a stable release.

For more details, initial upstream bugreport:
http://article.gmane.org/gmane.linux.file-systems.aufs.user/1270

The patch as provided by upstream:
http://article.gmane.org/gmane.linux.file-systems.aufs.user/1291

Hi,

it seems my wishlist is already submitted ;-)

For GNU/kFreeBSD, the milestone (upstream) libtool version are

1.5.2-1 - earlier does not support GNU/kFreeBSD at all

1.5.24-1 - fixed anon_versioning bug for GNU/kFreeBSD and hurd (rarely hitted)

Present file "ltconfig" signals really ancient libtool (1.3 series),
for 1.5 series version can be obtained from "ltmain.sh" file
by "grep ^VERSION ltmain.sh"

Please, could you consider adding this check,
it would safe us some porting time.

Petr

Dear Debian maintainer,

The zekr-quran-translations-en 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 475461 (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 zekr-quran-translations-en 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 14 days) is roughly the following:

Dear Debian maintainer,

The pure-ftpd 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 481673 (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 pure-ftpd 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 14 days) is roughly the following:

FWIW, I also had this problem with 2.3.2-2+lenny1 (and not with
2.3.2-2), and the version from
http://people.debian.org/~jcristau/493096/ did fix it for me. I also
got a backtrace of where X was hanging when it was too busy to bring
my windows up:

0xb7b13cfa in i830_crt_detect (output=0x8aaac00) at ../../src/i830_crt.c:285
285 ../../src/i830_crt.c: No such file or directory.
in ../../src/i830_crt.c
(gdb) bt
#0 0xb7b13cfa in i830_crt_detect...

tag 491820 patch
thanks

This problem is caused by a number of unexpected macro expansions:

mailto:mikulas@artax.karlin.mff.cuni.cz[]

is expanded using the mailto macro to

<mikulas@artax.karlin.mff.cuni.cz>

This is expanded using the
(?su)(?:\w])[\\]?(?P\w[\w._-]*@[\w._-]*\w)(?!["<\w.])
pattern and the mailto macro to

<<mikulas@artax.karlin.mff.cuni.cz>>

This is then expanded using the
(?su)[\\]?<<(?P[\w"].*?)>> pattern and the xref2
macro to



It would be best to fix this in AsciiDoc. By changing the former
pattern to
n
(?su)(?:;\w])[\\]?(?P\w[\w._-]*@[\w._-]*\w)(?!["<&\w.])

so it wouldn't re-expand email addresses next to an entity.