Debian Bug report logs - #560139
liblua5.1-0-dev: C++ version of LUA libraries

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Erich Schubert <erich@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: liblua5.1-0-dev: C++ version of LUA libraries

Date: Wed, 09 Dec 2009 09:42:18 +0100

Package: liblua5.1-0-dev
Version: 5.1.4-5
Severity: wishlist

Hi,
I'm the maintainer of Enigma, which currently ships an own copy of Lua.
As far as I know (from discussion with upstream and on #debian-devel) it
is currently impossible for me to re-use the Debian lua packages for building
Enigma. The main reason is that C++ exceptions and lua compiled for C use
will break badly.

Quoting from the LUA unofficial FAQs:

By default if lua 5.1 or later is compiled as C++, it will use C++ exceptions
to unwind the stack rather than longjmp/setjmp, though this is configurable (at
compile time). See luaconf.h near LUAI_THROW/LUAI_TRY for a discussion of this. 


As far as I know, Enigma Lua also comes with some patches that e.g. add an
assertion facility that isn't yet in main lua. Still another lua user in
#debian-devel expressed the wish that there were a C++-built lua version in
Debian to re-use in his own projects.

Enigma also uses "tolua++" instead of "tolua".
from http://www.codenix.com/~tolua/


I am aware that lua upstream considers embedding a custom lua version in the
application the proper way instead of using a shared library, and I do not
want to reopen this discussion. The debian policy usually is to avoid
duplicated code to make security maintenance easier.

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

Kernel: Linux 2.6.32-rc8-686 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages liblua5.1-0-dev depends on:
ii  libc6-dev [libc-dev]          2.10.2-2   GNU C Library: Development Librari
ii  liblua5.1-0                   5.1.4-5    Simple, extensible, embeddable pro
ii  libreadline-dev               6.0-5      GNU readline and history libraries

Versions of packages liblua5.1-0-dev recommends:
ii  libtool                       2.2.6a-4   Generic library support script
ii  pkg-config                    0.22-1     manage compile and link flags for 

liblua5.1-0-dev suggests no packages.

-- no debconf information

Message #10 received at 560139@bugs.debian.org (full text, mbox, reply):

From: Enrico Tassi <gareuselesinge@debian.org>

To: Erich Schubert <erich@debian.org>, 560139@bugs.debian.org

Subject: Re: Bug#560139: liblua5.1-0-dev: C++ version of LUA libraries

Date: Wed, 9 Dec 2009 10:48:43 +0100

On Wed, Dec 09, 2009 at 09:42:18AM +0100, Erich Schubert wrote:
> As far as I know (from discussion with upstream and on #debian-devel) it
> is currently impossible for me to re-use the Debian lua packages for building
> Enigma. The main reason is that C++ exceptions and lua compiled for C use
> will break badly.

I would be happy to provide a C++ version of the runtime, and would be
easy. What refrains me is that from the C++ interpreter you will be
allowed to load C modules (shipped in liblua5.1-* packages) but there
you will face the same problem I believe. 

Any ideas on how to get around this problem? 

Cheers
-- 
Enrico Tassi

Message #15 received at 560139@bugs.debian.org (full text, mbox, reply):

From: Kalle Olavi Niemitalo <kon@iki.fi>

To: Enrico Tassi <gareuselesinge@debian.org>

Cc: Erich Schubert <erich@debian.org>, 560139@bugs.debian.org

Subject: Re: Bug#560139: liblua5.1-0-dev: C++ version of LUA libraries

Date: Sun, 18 Dec 2011 09:57:07 +0200

[Message part 1 (text/plain, inline)]

Enrico Tassi <gareuselesinge@debian.org> writes:

> On Wed, Dec 09, 2009 at 09:42:18AM +0100, Erich Schubert wrote:
>> As far as I know (from discussion with upstream and on #debian-devel) it
>> is currently impossible for me to re-use the Debian lua packages for building
>> Enigma. The main reason is that C++ exceptions and lua compiled for C use
>> will break badly.
>
> I would be happy to provide a C++ version of the runtime, and would be
> easy. What refrains me is that from the C++ interpreter you will be
> allowed to load C modules (shipped in liblua5.1-* packages) but there
> you will face the same problem I believe. 

I'm looking at this wishlist bug because of Bos Wars, which is
written in C++ and uses Lua and tolua++ (but no Lua modules from
separate packages).  Currently, the exception handling in Bos
Wars is a mess; C++ code very often calls Lua functions, and if
they throw errors (e.g. type mismatch, out of memory), then Bos
Wars typically leaks std::string and other objects.  Although C++
permits that longjmp might call destructors, I have verified that
it does not call them on Debian.  Fixing the leaks with the
current liblua5.1.so seems possible but very cumbersome and
error-prone.  Furthermore, tolua++ would also have to be changed,
because it nowadays generates code that assumes strings will be
destroyed on exceptions.

I don't see why Lua modules compiled as C would have a problem
with liblua5.1 using C++ exceptions.

Although LUAI_THROW and LUAI_TRY are defined in luaconf.h, which
is installed in liblua5.1-0-dev, modules and applications cannot
use these macros.  The macros require struct lua_jmpbuf and
struct lua_State from lstate.h, which is not installed.  Even in
lua5.1 itself, only the luaD_throw function uses LUAI_THROW, and
only the luaD_rawrunprotected function uses LUAI_TRY.  Everything
that needs to throw or handle errors then uses these functions.

Throwing an exception from luaD_throw in liblua5.1.so, correctly
propagating it through a module, and catching it in
luaD_rawrunprotected in liblua5.1.so may require that the module
has been compiled with some kind of exception handling data, so
that the unwinder can find the calling function and check whether
it wanted to catch the exception.  However, it looks like GCC
always generates .cfi_startproc and related pseudo-ops nowadays,
and these then become an .eh_frame section in the binary.  I got
those even when compiling C for x86 with both -fno-exceptions and
-fno-unwind-tables.

Just setting CC=g++ in lua5.1-5.1.4/src/Makefile causes the
function names in the shared library to become mangled, making
the library binary-incompatible with current modules and
applications.  Because applications written in C will not be able
to use the mangled names, the C and C++ variants of the library
would have to be installed side by side, or some extern "C" would
have to be added.  If there are no other incompatibilities, then
I think extern "C" would be best, because it does not require
twice the disk space.

When built as C++, LUAI_TRY catches all C++ exceptions, even ones
like std::bad_alloc that were not thrown by LUAI_THROW.  This
makes sense because the Lua stack should be unwound even in that
case.  However, it looks like Lua will then not set an error
message on the Lua stack and will leave some other object there
instead.  This situation is fortunately easy to avoid, by
catching all C++ exceptions in C++ functions called from Lua, and
translating them to lua_error calls.  This requires only one
try...catch per function, so it is much easier than catching all
Lua errors in C++ code that calls Lua.

[Message part 2 (application/pgp-signature, inline)]

Message #20 received at 560139@bugs.debian.org (full text, mbox, reply):

From: Enrico Tassi <gareuselesinge@debian.org>

To: Kalle Olavi Niemitalo <kon@iki.fi>, 560139@bugs.debian.org

Cc: Erich Schubert <erich@debian.org>

Subject: Re: Bug#560139: liblua5.1-0-dev: C++ version of LUA libraries

Date: Sun, 18 Dec 2011 11:35:46 +0100

[Message part 1 (text/plain, inline)]

On Sun, Dec 18, 2011 at 09:57:07AM +0200, Kalle Olavi Niemitalo wrote:
> Enrico Tassi <gareuselesinge@debian.org> writes:
> > On Wed, Dec 09, 2009 at 09:42:18AM +0100, Erich Schubert wrote:
> >> As far as I know (from discussion with upstream and on #debian-devel) it
> >> is currently impossible for me to re-use the Debian lua packages for building
> >> Enigma. The main reason is that C++ exceptions and lua compiled for C use
> >> will break badly.
> >
> > I would be happy to provide a C++ version of the runtime, and would be
> > easy. What refrains me is that from the C++ interpreter you will be
> > allowed to load C modules (shipped in liblua5.1-* packages) but there
> > you will face the same problem I believe. 
> 
> I'm looking at this wishlist bug because of Bos Wars, which is
> written in C++ and uses Lua and tolua++ (but no Lua modules from

Many thanks for your analysis. To make it short, would it work for you
if the packages would ship something like liblua5.1-c++.so and
lua5.1-c++.pc the former being compiled with C++ (extern "C" is already
there IIRC) and the latter spitting out -llua5.1-c++?

I've prepared that patch a while ago (so it may not apply 100% clean).
I'm attaching it, it is for the lua5.1 package of course. 
Could you please test it?

Cheers
-- 
Enrico Tassi

[patch-c++.patch (text/x-diff, attachment)]

Message #25 received at 560139@bugs.debian.org (full text, mbox, reply):

From: Kalle Olavi Niemitalo <kon@iki.fi>

To: Enrico Tassi <gareuselesinge@debian.org>

Cc: 560139@bugs.debian.org, Erich Schubert <erich@debian.org>

Subject: Re: Bug#560139: liblua5.1-0-dev: C++ version of LUA libraries

Date: Sun, 18 Dec 2011 20:04:41 +0200

[Message part 1 (text/plain, inline)]

Enrico Tassi <gareuselesinge@debian.org> writes:

> I've prepared that patch a while ago (so it may not apply 100% clean).
> I'm attaching it, it is for the lua5.1 package of course. 
> Could you please test it?

Thank you.  The patch conflicted in debian/changelog only.
I had some difficulty getting the Makefile changes applied, due
to unfamiliarity with quilt.  After that, the package compiled
OK, and the resulting shared object does call destructors when
unwinding from an error.  I am attaching my test program.
Compile with:
g++ lua_error.cc $(pkg-config --cflags --libs lua5.1-c++) -o lua_error

Because you made the C++ variant a separate library with mangled
names, it is not compatible with previously compiled modules.
For example, liblua5.1-curl.so.0.0.0 in liblua5.1-curl0 0.3.0-5
wants to call lua_type rather than _Z8lua_typeP9lua_Statei.
This will not be a problem for Bos Wars, which does not use such
modules anyway; but perhaps you should change LUA_CPATH_DEFAULT
in liblua5.1-c++, to support installing C++ variants of modules
as well.

(I wonder why liblua5.1-curl.so.0.0.0 does not declare a
dependency on liblua5.1.so.0 even though it uses functions from
that.)

[lua_error.cc (text/x-c++src, attachment)]

[Message part 3 (application/pgp-signature, inline)]

Message #30 received at 560139@bugs.debian.org (full text, mbox, reply):

From: Enrico Tassi <gareuselesinge@debian.org>

To: Kalle Olavi Niemitalo <kon@iki.fi>

Cc: 560139@bugs.debian.org, Erich Schubert <erich@debian.org>

Subject: Re: Bug#560139: liblua5.1-0-dev: C++ version of LUA libraries

Date: Sun, 18 Dec 2011 21:53:13 +0100

On Sun, Dec 18, 2011 at 08:04:41PM +0200, Kalle Olavi Niemitalo wrote:
> Enrico Tassi <gareuselesinge@debian.org> writes:
> Because you made the C++ variant a separate library with mangled
> names, it is not compatible with previously compiled modules.

You are right, I should fix that. Or if you did that already, just drop
me a patch.

> (I wonder why liblua5.1-curl.so.0.0.0 does not declare a
> dependency on liblua5.1.so.0 even though it uses functions from
> that.)

This is intended since you don't need the shared library to use the lua
module. The lua interpreter is statically linked for performance reasons
and exports the same symbols. Any other software statically linked with
lua could do the same. This is reasonably common in the Lua world.

Cheers
-- 
Enrico Tassi

Message #35 received at 560139@bugs.debian.org (full text, mbox, reply):

From: Kalle Olavi Niemitalo <kon@iki.fi>

To: Enrico Tassi <gareuselesinge@debian.org>

Cc: 560139@bugs.debian.org, Erich Schubert <erich@debian.org>

Subject: Re: Bug#560139: liblua5.1-0-dev: C++ version of LUA libraries

Date: Sat, 24 Dec 2011 09:26:13 +0200

[Message part 1 (text/plain, inline)]

I investigated the possibility of just putting the C++ code in
liblua5.1.so: keeping the ABI compatible but adding exception
support.  I think this is feasible for liblua5.1.so but
unfortunately not for liblua5.1.a, because the C++ support needs
several symbols from libsupc++.a and we cannot expect C programs
using liblua5.1.a to link with that.

(This could perhapss be fixed by turning liblua5.1.a into a
linker script like libc.so and libncurses.so are.  It would point
to the real static Lua library and to libsupc++.a from the
version of G++ that was used to compile Lua.  Then, the
liblua5.1-0-dev package would also have to depend on the
corresponding libstdc++6-4.*-dev package.  I think this would
work initially but have rather many steps that can fail later.)

Because supporting exceptions only in liblua5.1.so and not in
liblua5.1.a seems too risky (what happens when someone links with
-static), I guess there should be separate C++ variants of both,
like you already implemented, except with unmangled public symbols.

[Message part 2 (application/pgp-signature, inline)]

Message #40 received at 560139@bugs.debian.org (full text, mbox, reply):

From: Enrico Tassi <gareuselesinge@debian.org>

To: Kalle Olavi Niemitalo <kon@iki.fi>

Cc: 560139@bugs.debian.org, Erich Schubert <erich@debian.org>

Subject: Re: Bug#560139: liblua5.1-0-dev: C++ version of LUA libraries

Date: Sat, 24 Dec 2011 16:29:02 +0100

[Message part 1 (text/plain, inline)]

On Sat, Dec 24, 2011 at 09:26:13AM +0200, Kalle Olavi Niemitalo wrote:
> Because supporting exceptions only in liblua5.1.so and not in
> liblua5.1.a seems too risky (what happens when someone links with
> -static), I guess there should be separate C++ variants of both,
> like you already implemented, except with unmangled public symbols.

Please try the attached patch, I'm planning to upload this to unstable
as soon as possible. I've also added one more test to your test file,
and now it seems to be able to require C modules. Also note the include
<lua.hpp> that adds extern "C" and includes also auxiliary lua headers.

cheers
-- 
Enrico Tassi

[lua5.1_5.1.4-12.debian.tar.gz (application/octet-stream, attachment)]

[lua5.1_5.1.4-12.dsc (text/plain, attachment)]

[lua_error.cc (text/x-c++src, attachment)]

Message #45 received at 560139@bugs.debian.org (full text, mbox, reply):

From: Kalle Olavi Niemitalo <kon@iki.fi>

To: Enrico Tassi <gareuselesinge@debian.org>

Cc: 560139@bugs.debian.org, Erich Schubert <erich@debian.org>

Subject: Re: Bug#560139: liblua5.1-0-dev: C++ version of LUA libraries

Date: Sun, 25 Dec 2011 13:40:18 +0200

[Message part 1 (text/plain, inline)]

Enrico Tassi <gareuselesinge@debian.org> writes:

> Please try the attached patch, I'm planning to upload this to unstable
> as soon as possible.

In the liblua5.1-0 package built from your 5.1.4-12 patch, the
shlibs file contains:

liblua5.1-c++ 0 liblua5.1-0
liblua5.1 0 liblua5.1-0

Because liblua5.1-c++.so.0 did not exist in earlier binary
packages, I think you should add (>= 5.1.4-12) to that line.

Differences between the dynamic symbols of liblua5.1.so and
liblua5.1-c++.so:

- OK: liblua5.1-c++.so has typeinfo objects for lua_longjmp and
  lua_longjmp*.
- OK: liblua5.1-c++.so has references to libstdc++.so.6 and
  libgcc_s.so.1, and to some symbols of those.
- OK: liblua5.1-c++.so uses fscanf; liblua5.1.so uses __isoc99_fscanf.
  This happens because some GNU extensions conflict with C99 additions
  and are therefore disabled for C by default.
- OK: liblua5.1-c++.so uses isalnum et al; liblua5.1.so uses
  __ctype_b_loc.  This is because <ctype.h> does not define
  isalnum as a macro when compiled as C++.
- OK: liblua5.1.so has references to _setjmp and _longjmp.
- OK: liblua5.1-c++.so defines lua_ident; liblua5.1.so does not.
  This is because lapi.c defines lua_ident as const char[], which
  implies static in C++.  Applications should not use lua_ident,
  because it is neither declared in any header nor documented the
  Lua 5.1 Reference Manual.

> I've also added one more test to your test file, and now it
> seems to be able to require C modules.

I see you also corrected the exit code.

> Also note the include <lua.hpp> that adds extern "C" and
> includes also auxiliary lua headers.

That is somewhat redundant now that you have extern "C" in
LUA_API.  Originally, I thought the extern "C" should only be
visible when Lua itself is being compiled; for applications, the
header should behave as in previous versions.  Now though, I
think you made the right choice.  Having extern "C" in LUA_API
lets application programmers use e.g. "lua.h" without wrapping it
in extern "C" { ... } in the application source; and an
application doing that is also portable to Lua installations
built in C++ from unmodified upstream sources.  Such an
application is not portable to Lua installations built in C from
unmodified upstream sources, but that combination would probably
suffer from memory leaks or worse at runtime anyway.

I have not tried liblua5.1-c++.so.0 with Bos Wars yet.  Bos Wars
has a Python-based build system that may take some time for me to
figure out.

Thank you for your effort.

[Message part 2 (application/pgp-signature, inline)]

Message #50 received at 560139@bugs.debian.org (full text, mbox, reply):

From: Enrico Tassi <gareuselesinge@debian.org>

To: Kalle Olavi Niemitalo <kon@iki.fi>, 560139@bugs.debian.org

Subject: Re: Bug#560139: liblua5.1-0-dev: C++ version of LUA libraries

Date: Sun, 25 Dec 2011 20:14:42 +0100

[Message part 1 (text/plain, inline)]

On Sun, Dec 25, 2011 at 01:40:18PM +0200, Kalle Olavi Niemitalo wrote:
> I have not tried liblua5.1-c++.so.0 with Bos Wars yet.  Bos Wars
> has a Python-based build system that may take some time for me to
> figure out.

Yes, Scons sucks badly as all other make replacements. But today It's
christmas, I feel nice even to Scons. Gift attached, works for me.

Ciao
-- 
Enrico Tassi

[lua_cpp (text/plain, attachment)]

Message #55 received at 560139-close@bugs.debian.org (full text, mbox, reply):

From: Enrico Tassi <gareuselesinge@debian.org>

To: 560139-close@bugs.debian.org

Subject: Bug#560139: fixed in lua5.1 5.1.4-12

Date: Sun, 25 Dec 2011 19:32:21 +0000

Source: lua5.1
Source-Version: 5.1.4-12

We believe that the bug you reported is fixed in the latest version of
lua5.1, which is due to be installed in the Debian FTP archive:

liblua5.1-0-dbg_5.1.4-12_amd64.deb
  to main/l/lua5.1/liblua5.1-0-dbg_5.1.4-12_amd64.deb
liblua5.1-0-dev_5.1.4-12_amd64.deb
  to main/l/lua5.1/liblua5.1-0-dev_5.1.4-12_amd64.deb
liblua5.1-0_5.1.4-12_amd64.deb
  to main/l/lua5.1/liblua5.1-0_5.1.4-12_amd64.deb
lua5.1-doc_5.1.4-12_all.deb
  to main/l/lua5.1/lua5.1-doc_5.1.4-12_all.deb
lua5.1_5.1.4-12.debian.tar.gz
  to main/l/lua5.1/lua5.1_5.1.4-12.debian.tar.gz
lua5.1_5.1.4-12.dsc
  to main/l/lua5.1/lua5.1_5.1.4-12.dsc
lua5.1_5.1.4-12_amd64.deb
  to main/l/lua5.1/lua5.1_5.1.4-12_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 560139@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Enrico Tassi <gareuselesinge@debian.org> (supplier of updated lua5.1 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


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

Format: 1.8
Date: Sun, 25 Dec 2011 20:15:03 +0100
Source: lua5.1
Binary: lua5.1-doc lua5.1 liblua5.1-0-dev liblua5.1-0 liblua5.1-0-dbg
Architecture: source all amd64
Version: 5.1.4-12
Distribution: unstable
Urgency: low
Maintainer: John V. Belmonte <jbelmonte@debian.org>
Changed-By: Enrico Tassi <gareuselesinge@debian.org>
Description: 
 liblua5.1-0 - Shared library for the Lua interpreter version 5.1
 liblua5.1-0-dbg - Debug symbols for the Lua shared library interpreter
 liblua5.1-0-dev - Development files for the Lua language version 5.1
 lua5.1     - Simple, extensible, embeddable programming language
 lua5.1-doc - Documentation for the Lua language version 5.1
Closes: 560139
Changes: 
 lua5.1 (5.1.4-12) unstable; urgency=low
 .
   * Provide liblua5.1-c++.so and lua5.1-c++.pc to make it possible to C++
     programs to link against Lua and use the C++ exception mecanism.
     (Closes: #560139)
   * Add lua patch 5.1.4-4 fixing all known bugs of lua 5.1.4
Checksums-Sha1: 
 3040e64c136be9dc204b35a14e6079f44b03102b 1466 lua5.1_5.1.4-12.dsc
 a9ae08041479a92e3baf15b5963770481283af66 16103 lua5.1_5.1.4-12.debian.tar.gz
 92f635de223069094a270925c0376400bc35e5f7 106528 lua5.1-doc_5.1.4-12_all.deb
 1c06ad516000b5e90bd29a9b4ffc47b8740b65ea 145702 lua5.1_5.1.4-12_amd64.deb
 a8571f42733aab03261bbb3795c724c5c4976d16 226424 liblua5.1-0-dev_5.1.4-12_amd64.deb
 9024d3fece05e06c0003bf0bde117847e91073d8 169966 liblua5.1-0_5.1.4-12_amd64.deb
 cd4ec723dc8fbd5edcaeb3a188d50c4ec51b6da2 55418 liblua5.1-0-dbg_5.1.4-12_amd64.deb
Checksums-Sha256: 
 252401a9a98f5f942d60c56aee05156d78329fd41de14fadd381b2df74b848c7 1466 lua5.1_5.1.4-12.dsc
 200ac8dfd3989704ef1bf80ef27b5f92bdcf3087290aa547277ead2dd675ab32 16103 lua5.1_5.1.4-12.debian.tar.gz
 b45275d6d261069aa0a8ab4b9a29add511719ac4e30896155a70cea29fc469c7 106528 lua5.1-doc_5.1.4-12_all.deb
 496aa3aac13e005f692fa2c92a36b4ae671c640205f4fa898ec2144fb102f227 145702 lua5.1_5.1.4-12_amd64.deb
 6615187559c09c082dfca85f5cc5e7cb6108fc7e0992fc1c3e1a3843955065bd 226424 liblua5.1-0-dev_5.1.4-12_amd64.deb
 9c4ec66435fabf5aeff9f37867f381b32ce95cf6ede5d1ee43aae1bc9bc9f61c 169966 liblua5.1-0_5.1.4-12_amd64.deb
 3f8ced3f4e82d956cc1dec645f6741ccd23496357d6389f02503124078f97924 55418 liblua5.1-0-dbg_5.1.4-12_amd64.deb
Files: 
 53445a52c1e041ca24c2b76f4660d8c0 1466 interpreters optional lua5.1_5.1.4-12.dsc
 c98ab36ae006fcd6cbef81254677d5eb 16103 interpreters optional lua5.1_5.1.4-12.debian.tar.gz
 550d2908862a43681ab318e5ef4ff105 106528 doc optional lua5.1-doc_5.1.4-12_all.deb
 542dcdc6c7bd316ed131bc64eb97a730 145702 interpreters optional lua5.1_5.1.4-12_amd64.deb
 9e9dda83e5361745736ef8b8065f7f98 226424 libdevel optional liblua5.1-0-dev_5.1.4-12_amd64.deb
 2e882ef01aea5b00219a379921a0170e 169966 libs optional liblua5.1-0_5.1.4-12_amd64.deb
 4b15ee8bfb9ec251ec499985dabb729c 55418 debug extra liblua5.1-0-dbg_5.1.4-12_amd64.deb

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

iEYEARECAAYFAk73dyUACgkQ7kkcPgEj8vJ88wCfbWmNvnRn8GgfaBIkpagt1owG
rL8AnRz93OCbkgHIRUf/UEDyiQ7gqFEi
=c+tr
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.