Bug#885677: is rebuilding lablgtk2 without gnomecanvas an option?
On Fri, Mar 23, 2018 at 06:40:18PM +0100, Enrico Tassi wrote: > Dear Jeremy, I'm an upstream of some of the software that depends on > lablgtk2. Porting to GTK+3 is not an easy option, since lablgtk3 does > not exist (and will not exist as far as I know). > > As far as I understand, the main offender here is libgnomecanvas2-0. Sorry, I meant gnomecanvas2 *and* gtksourceview2. -- Enrico Tassi
Bug#885677: is rebuilding lablgtk2 without gnomecanvas an option?
Dear Jeremy, I'm an upstream of some of the software that depends on lablgtk2. Porting to GTK+3 is not an easy option, since lablgtk3 does not exist (and will not exist as far as I know). As far as I understand, the main offender here is libgnomecanvas2-0. I was wandering if we could rebuild lablgtk2 switching off support for some gnome technology: that is get rid of the binary package liblablgtk2-gnome-ocaml but keep the others) Lablgtk2 is made of optional components that can be switched off at configure time. Eg on my system I currently get: LablGTK configuration: GtkGLArea yes libgladeyes librsvg yes libgnomecanvas yes libgnomeui yes libpanelapplet not found gtkspellyes gtksourceview 1 not found gtksourceview 2 yes quartz not found If it is a viable option for you, can you tell me which of the above are going to be a problem for Buster (in addition to libgnomecanvas)? Best -- Enrico Tassi
Bug#886044: syncmaildir: raising severity of gconf dependency bug
On Tue, Mar 13, 2018 at 06:14:53PM +0100, gregor herrmann wrote: > Control: tag -1 + patch > > On Mon, 12 Mar 2018 01:24:02 -0400, Jeremy Bicha wrote: > > > Please try to port your package away from gconf. Otherwise, please > > consider requesting that your package be removed from Debian to help us > > complete this goal. > > Looking at the ChangeLog and the git history, it seems that gconf has > been replaced by gsettings already in 1.2.6. > Grepping through the code shows two leftovers, the build dependency in > debian/control, and a mentioning in PKGS_VALA in Makefile. > > If I remove those two pieces, the package builds and the Depends line > of the syncmaildir-applet binary package loses gconf-service and > libgconf-2-4. > > Patch (git diff against master) attached. > > Enrico, do you have time to work on this? Otherwise I'm happy to > make an upload based on this diff. Many thanks for the work! I was planning to do a new release (I'm also the upstream, and I have a couple of pending fixes) and the do the upload fixing the gconf issue. I'm very busy so can't guarantee I'll manage to do it promptly, so if it helps please do an NMU (and I'll wait the migration to testing before doing my upload, in case I manage to release quickly). Ciao -- Enrico Tassi
Bug#852250: [lua-socket] luasocket was not compiled with UNIX sockets support
On Thu, Feb 02, 2017 at 10:08:48AM +0100, Michael Meskes wrote: > > Sorry, I'm a bit puzzled. The only module with such error is > > sasl_dovecot that AFAICT is not part of the debian package. > > Correct, nobody ever claimed it was. > > > Anyway, I was wrong saying that the incriminated line is fine in 5.1 > > but > > not in 5.2. It is wrong in 5.1 too. Could you try the fix I > > propose? > > I've tried, and the socket.unix module loads fine here. > > > > Could you please try the fix I propose (in sasl_dovecot)? > > Just did, but apparently your patch does not work: > > modulemanager error Error initializing module 'auth_dovecot' on > 'localhost': /usr/local/lib/prosody/modules/sasl_dovecot.lib.lua:60: > attempt to call field 'unix' (a table value) Sorry, my patch was wrong local _, unix = pcall(require, "socket.unix"); if unix then socket.unix = unix.stream or unix.tcp; end Unfortunately I can't really test the patches I propose, so I beg your pardon if they are wrong. And the patches are really for the upstream of prosody-modules, not for Debian. Best, -- Enrico Tassi
Bug#852250: [lua-socket] luasocket was not compiled with UNIX sockets support
On Fri, Jan 27, 2017 at 11:46:26AM +0100, Michael Meskes wrote: > On Wed, Jan 25, 2017 at 10:48:43PM +0100, Mathieu Parent wrote: > The patch does not seem to work. I just installed > lua-socket_3.0~rc1+git+ac3201d-3_amd64.deb manually, re-started prosody and > got 'luasocket was not compiled with UNIX sockets support' again. Sorry, I'm a bit puzzled. The only module with such error is sasl_dovecot that AFAICT is not part of the debian package. Anyway, I was wrong saying that the incriminated line is fine in 5.1 but not in 5.2. It is wrong in 5.1 too. Could you try the fix I propose? I've tried, and the socket.unix module loads fine here. Could you please try the fix I propose (in sasl_dovecot)? Best, -- Enrico Tassi
Bug#852250: [lua-socket] luasocket was not compiled with UNIX sockets support
On Fri, Jan 27, 2017 at 11:46:26AM +0100, Michael Meskes wrote: > On Wed, Jan 25, 2017 at 10:48:43PM +0100, Mathieu Parent wrote: > The patch does not seem to work. I just installed > lua-socket_3.0~rc1+git+ac3201d-3_amd64.deb manually, re-started > prosody and got 'luasocket was not compiled with UNIX sockets support' > again. Could you please confirm you are on lua 5.2? I've the impression that line 29 of sasl_dovecott is 5.1 only, i.e. is expects `pcall(require, "socket.unix");` to inject socket.unix into the global namespace. IMO such line should be replaced by local _, unix = pcall(require, "socket.unix"); socket.unix = unix; Best, -- Enrico Tassi
Bug#852250: [lua-socket] luasocket was not compiled with UNIX sockets support
On Wed, Jan 25, 2017 at 10:24:25AM +0100, Michael Meskes wrote: > > Hopefully somebody is prepared to fix all rdepends. > > Or better reverts the API change. I gave a quick look at the problem. I don't know why Mathieu packaged a new upstream snapshot exactly, I hope it is not for the new unix.tcp/udp feature. If so, reverting the API change is as simple as reverting aa1b8cc9bc35e56de15eeb153c899e4c51de82a8 There is just a trivial conflict on the makefile. Mathieu, does luasandbox need the new unix sockets? Best, -- Enrico Tassi
Bug#852250: [lua-socket] luasocket was not compiled with UNIX sockets support
On Wed, Jan 25, 2017 at 10:24:25AM +0100, Michael Meskes wrote: > > Hopefully somebody is prepared to fix all rdepends. > > Or better reverts the API change. The bug is definitely important. Mathieu can you take care of it? Best, -- Enrico Tassi
Bug#818616: What should I do?
Hum, I'm a bit lost here. 2.0.4 is fine, but does not work on arm64. What about 2.1-beta2 + fix allocator (as in message #35) ? Was it tested? Does it work? Should I upload it? Best, -- Enrico Tassi
Bug#844692: sandbox not versioned
Hello, looks like you use 'sandbox' as the identifier of the Lua version. Note that 5.1 and 5.2, for example, are different, incompatible, languages. Will Lua sandbox stay compatible with 5.1 only? Shouldn't we call it sanbox5.1 or something like that? Also, is it a drop in replacement for 5.1 (with extra features)? Will there be Lua packages working only on sandbox (to motivate the "sanbox" label)? E.g. is the new systemd related package needing sandbox? Best -- Enrico Tassi
Bug#839221: RM: mathcomp -- ROM; superseeded by ssreflect 1.6
Package: ftp.debian.org Severity: normal ssreflect used to be 1 source, then it was split in 2 by the upstream (ssreflect + mathcomp) and now we are back at 1.
Bug#824944: [jwollr...@web.de: Re: Update lua-discount]
-- Enrico Tassi --- Begin Message --- Am Thu, 30 Jun 2016 15:19:54 +0200 schrieb Enrico Tassi <gareuselesi...@debian.org>: > On Mon, Jun 27, 2016 at 09:56:44PM +0200, Julian Wollrath wrote: > > Dear Enrico, > > > > I updated the package (see attached for the new source and Debian > > tarball). I also updated the code in the git repo. > > thanks! Could you please push the tags too? I don't have the une for > upstream/2.8.1 > > Best, There is no real upstream for 2.8.1, since I just updated it locally to incorporate the flags of discount 2.8.1 but sinced upstreams seems unmaintained I thought this might be the easiest way to reflect which discount version this correponds to. Furthermore, the git repo includes the debian folder, so I am not quite sure how to tag a upstream only version. Nevertheless, you can get the orig tarball and the debian ones with the help of gitpkg. Cheers, Julian --- End Message ---
Bug#824166: texlive-bin: FTBFS due to luajit issues
On Wed, May 25, 2016 at 02:12:59PM -0300, Breno Leitao wrote: > On Fri, 13 May 2016 10:56:25 +0200 (CEST) Thorsten Glaser > <t.gla...@tarent.de> wrote: > > With https://buildd.debian.org/status/package.php?p=luajit > > showing the architectures the stand-alone luajit is not > > available for > > In fact we have a ppc64el patch for luajit port, but the upstream > maintainer does not commit or even comment about our patches, so, it > does get accepted. > > https://github.com/LuaJIT/LuaJIT/pull/54 > > We also asked the Debian luajit maintainer (Enrico) to get the patch accepted > in > Debian, until we have any position on upstream. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814255 I can't apply such a patch on the Debian package. It is too complex to maintain. Best -- Enrico Tassi
Bug#818900: [Lua Policy] integrate debian's lua modules into Debian's Luarocks
On Mon, Mar 21, 2016 at 03:06:28PM +, Bas Wijnen wrote: > On Mon, Mar 21, 2016 at 02:37:44PM +, lumin wrote: > > When I'm dealing with one of my ITP's I found that this is > > a noticeable problem to Debian's lua packages. And I think > > this may require some changes to our lua policy, or the dh-lua > > scripts. > > What you describe should be fixed. There is a problem with how your scripts > work, though: if some packages are installed before luarocks, they will not be > indexed. Not unless luarocks scans for installed packages on installation > anyway. If it can do that, it might make more sense to just trigger that > procedure when a new lua module is installed as well. > > Making that part of dh-lua seems like the way to go. Undoubtedly. Each lua package could ship a luarocks manifest, something like /usr/lib/luarocks/5.1/rocks/lua-cjson/2.1.0-1/manifest Such manifest could be generated by some code pretty close to postinst script attached to the bugreport, but at package build time (by dh-lua) and not at package installation time. Lumin, if you have time, please try to patch dh-lua. You could look for the code that generates .pc files, and start from that. Otherwise I'll do it myself, but I'm a bit busy these days. Best, -- Enrico Tassi
Bug#802264: src:matita: FTBFS with OCaml 4.02.3
On Sun, Oct 18, 2015 at 11:03:35PM +0200, Mehdi Dogguy wrote: > Package: src:matita > Version: 0.99.1-3 > Severity: serious > > Dear Maintainer, This bugs is due to camlp5 and fixed in caca3dd0643ec5aae9df4399fa73eb280808ef18 see https://gforge.inria.fr/projects/camlp5/ Best, -- Enrico Tassi
Bug#804607: lua-sec: SSLv3 method
On Sat, Nov 14, 2015 at 02:16:53PM +0100, Kurt Roeckx wrote: > A few use tlsv1 which isn't much better. Thanks for your help, I'm preparing an upload. Can you argument why tlsv1 is not good? See also: https://github.com/brunoos/luasec/issues/58 Best, -- Enrico Tassi
Bug#800872: smd-loop just exists with an error code and no explanation when /tmp is full
On Sun, Oct 04, 2015 at 02:40:06PM +0200, Enrico Zini wrote:
> I wish there was something like an error message in a case like this.
Yep, your request makes a lot of sense.
Most of the tmp files are created in smd-common:
gc_mktemp() {
local tmp=`mktemp -q /tmp/smd.XX`
atexit_rm $tmp
RC="$tmp"
}
Patches are welcome ;-)
Best,
--
Enrico Tassi
Bug#719882: working on that
Hello, together with Victor Seva Lopez, here at debconf 15, we are working on that. Hope you don't mind. Best, -- Enrico Tassi
Bug#795604: ITP: lua-bit32 -- Backport of the Lua 5.2 bit32 library to Lua 5.1
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org --- Please fill out the fields below. --- Package name: lua-bit32 Version: 5.3.0 Upstream Author: Hisham Muhammad URL: https://github.com/keplerproject/lua-compat-5.2 License: MIT/X Description: Backport of the Lua 5.2 bit32 library to Lua 5.1 This is needed in order to package lua-posix = 33 -- Enrico Tassi
Bug#789534: [luaposix] stat fails on large inode (#230)
On Sun, Jul 05, 2015 at 09:46:11PM +0100, Gary V. Vaughan wrote: The bug was filed on the Debian package, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789534 The Debian package is still the old version 31, but looking at the changelog I could not see this particular issue being fixed. Unfortunately, this is a limitation of Lua 5.1 (a 12 year old codebase, albeit maintained with bug fixes until 3 years ago), which has but a single numeric type, where even integers are represented inside Lua itself as a 64bit double; i.e. only 53 bits of precision, which is not large enough to accurately contain any 64bit integers that use the 11 MSB. Thanks for the quick answer! I guess a non-fix would be to detect, on the C side, the overflow and give an accurate error message. Better than nothing. Working around Lua 5.1 limitations is not something we can tackle IMO. Lua 5.3 will eventually land in Debian (I've already a package for it, it needs just some testing). I'll also update lua posix as a consequence. Best, -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775565: Update on the ITP
Lua 5.3 is already packaged here git.debian.org/git/pkg-lua/lua5.3.git Due to lack of time, I did not test it properly and upload it. In particular it versions symbols, something the release team asked me to do for a long time to make the coexistence of many Lua versions less painful. It is a completely new thing for me, hence I want to be cautious. Testing is welcome. I guess I'll find time to upload it during debconf (i.e. mid August). Best, -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787070: prosody: DNS resolution of CNAMEs fails often
On Thu, May 28, 2015 at 12:46:22PM +0300, Sergei Golovan wrote: I think we should fix it for both sid and jessie (through the proposed updates procedure). The fix proposed upstream works well for me (i've patched the 0.9.7-2). Nothing against it, but I'm busy so if you have energy for it... go! Best, -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781762: liblua5.1-0-dev: lua.h and liblua.so not present in include and lib paths
close 781762 thanks On Thu, Apr 02, 2015 at 06:17:33PM +0200, Miguel Rubio-Roy wrote: Package: liblua5.1-0-dev Version: 5.1.5-7.1 Severity: serious Tags: newcomer Justification: Policy 8.4 Dear Maintainer, When trying to compile using the -llua option, the compiler does not found liblua.so on its path. According to the Debian Policy Manual, section 8.4, The development package should contain a symlink for the associated shared library without a version number. I kindly request you to implement this recommendation. Also, I think it is Debian Policy to name the libraries like: liblualiblua.so.5.1.0 instead of liblualiblua5.1.so.0.0.0 You should use `pkg-config --libs lua5.1` to get the correct linker flags. Orelse use -llua5.1. The version number the policy talks about is the 0.0.0 part, not the 5.1 (that is part of the name of the library). There is no such a thing like lua. lua5.1 and lua5.2 are different, incompatible, libraries, not two versions of the same. Best, -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781437: unblock: prosody/0.9.7-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package prosody
(explain the reason for the unblock here)
Security fix related to libidn (CVE-2015-2059)
(include/attach the debdiff against the package in testing)
gares@birba:~$ cat /tmp/debdiff
diff -Nru prosody-0.9.7/debian/changelog prosody-0.9.7/debian/changelog
--- prosody-0.9.7/debian/changelog 2014-10-25 10:42:47.0 +0200
+++ prosody-0.9.7/debian/changelog 2015-03-28 16:20:59.0 +0100
@@ -1,3 +1,10 @@
+prosody (0.9.7-2) unstable; urgency=high
+
+ * Apply upstream patch to validate UTF-8 strings before calling libidn
+(related to CVE-2015-2059)
+
+ -- Enrico Tassi gareuselesi...@debian.org Sat, 28 Mar 2015 16:20:07 +0100
+
prosody (0.9.7-1) unstable; urgency=medium
* New upstream release, really a minor fix over 0.9.6
diff -Nru prosody-0.9.7/debian/patches/0005-Validate-UTF-8-strings-before-
calling-libidn.patch prosody-0.9.7/debian/patches/0005-Validate-UTF-8-strings-
before-calling-libidn.patch
--- prosody-0.9.7/debian/patches/0005-Validate-UTF-8-strings-before-calling-
libidn.patch1970-01-01 01:00:00.0 +0100
+++ prosody-0.9.7/debian/patches/0005-Validate-UTF-8-strings-before-calling-
libidn.patch2015-03-28 16:20:59.0 +0100
@@ -0,0 +1,110 @@
+From: Enrico Tassi ga...@fettunta.org
+Date: Sat, 28 Mar 2015 16:17:35 +0100
+Subject: Validate UTF-8 strings before calling libidn
+
+---
+ util-src/encodings.c | 70
+---
+ 1 file changed, 67 insertions(+), 3 deletions(-)
+
+diff --git a/util-src/encodings.c b/util-src/encodings.c
+index b9b6160..898add1 100644
+--- a/util-src/encodings.c
b/util-src/encodings.c
+@@ -1,6 +1,7 @@
+ /* Prosody IM
+ -- Copyright (C) 2008-2010 Matthew Wild
+ -- Copyright (C) 2008-2010 Waqas Hussain
++-- Copyright (C) 1994-2015 Lua.org, PUC-Rio.
+ --
+ -- This project is MIT/X11 licensed. Please see the
+ -- COPYING file in the source package for more information.
+@@ -116,6 +117,65 @@ static const luaL_Reg Reg_base64[] =
+ { NULL, NULL}
+ };
+
++/*** UTF-8 /
++
++/*
++ * Adapted from Lua 5.3
++ * Needed because libidn does not validate that input is valid UTF-8
++ */
++
++#define MAXUNICODE0x10
++
++/*
++ * Decode one UTF-8 sequence, returning NULL if byte sequence is invalid.
++ */
++static const char *utf8_decode (const char *o, int *val) {
++ static unsigned int limits[] = {0xFF, 0x7F, 0x7FF, 0x};
++ const unsigned char *s = (const unsigned char *)o;
++ unsigned int c = s[0];
++ unsigned int res = 0; /* final result */
++ if (c 0x80) /* ascii? */
++ res = c;
++ else {
++ int count = 0; /* to count number of continuation bytes */
++ while (c 0x40) { /* still have continuation bytes? */
++ int cc = s[++count]; /* read next byte */
++ if ((cc 0xC0) != 0x80) /* not a continuation byte?
*/
++ return NULL; /* invalid byte sequence */
++ res = (res 6) | (cc 0x3F); /* add lower 6 bits
from cont. byte */
++ c = 1; /* to test next bit */
++ }
++ res |= ((c 0x7F) (count * 5)); /* add first byte */
++ if (count 3 || res MAXUNICODE || res = limits[count] ||
(0xd800 = res res = 0xdfff) )
++ return NULL; /* invalid byte sequence */
++ s += count; /* skip continuation bytes read */
++ }
++ if (val) *val = res;
++ return (const char *)s + 1; /* +1 to include first byte */
++}
++
++/*
++ * Check that a string is valid UTF-8
++ * Returns NULL if not
++ */
++const char* check_utf8 (lua_State *L, int idx, size_t *l) {
++ size_t pos, len;
++ const char *s = luaL_checklstring(L, 1, len);
++ pos = 0;
++ while (pos = len) {
++ const char *s1 = utf8_decode(s + pos, NULL);
++ if (s1 == NULL) { /* conversion error? */
++ return NULL;
++ }
++ pos = s1 - s;
++ }
++ if(l != NULL) {
++ *l = len;
++ }
++ return s;
++}
++
++
+ /* STRINGPREP */
+ #ifdef USE_STRINGPREP_ICU
+
+@@ -212,8 +272,8 @@ static int stringprep_prep(lua_State *L, const
Stringprep_profile *profile)
+ lua_pushnil(L);
+ return 1;
+ }
+- s = lua_tolstring(L, 1, len);
+- if (len = 1024) {
++ s = check_utf8(L, 1, len);
++ if (s == NULL || len = 1024 || len != strlen(s)) {
+ lua_pushnil(L);
+ return 1; /* TODO return error message */
+ }
+@@ -320,7 +380,11 @@ static int Lidna_to_unicode(lua_State *L) /**
idna.to_unicode(s) */
+ static int Lidna_to_ascii(lua_State *L) /** idna.to_ascii
Bug#775565: ITP: lua5.3 -- scripting language
On Wed, Jan 28, 2015 at 01:35:11PM +0100, Victor Seva wrote: Hi Enrico, On 01/17/2015 02:07 PM, Enrico Tassi wrote: A git repo pkg-lua/lua5.3 on alioth was created, help is very welcome. I would like to help here, is there any TODO or plan here? NO. I've just started writing the copyright and control file. I guess the next step is to copy the patches to build Lua from 5.2, using libtool. I'd also like to try out symbol versioning this time to make the release team happy. Have ld name symbols like lua_newstate (that exists in other Lua versions) something like lua_newstate@lua5.3 so that if one loads by mistake lua5.2 and lua5.3 in the same address space nothing wrong happens. No progress on that yet, I'm busy :-/ -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776231: unblock: lua-rings/1.3.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package lua-rings
Version 1.3.0-3 fixes FTBFS bug #775622
debdiff:
File lists identical (after any substitutions)
Control files of package lua-rings: lines which differ (wdiff format)
-
Version: [-1.3.0-2-] {+1.3.0-3+}
Control files of package lua-rings-dev: lines which differ (wdiff format)
-
Depends: lua-rings (= [-1.3.0-2)-] {+1.3.0-3)+}
Version: [-1.3.0-2-] {+1.3.0-3+}
gares@birba:~/Projects/pkg-lua/build-area$ debdiff lua-rings_1.3.0-2.dsc lua-
rings_1.3.0-3.dsc
dpkg-source: warning: extracting unsigned source package (/home/gares/Projects
/pkg-lua/build-area/lua-rings_1.3.0-2.dsc)
diff -Nru lua-rings-1.3.0/debian/changelog lua-rings-1.3.0/debian/changelog
--- lua-rings-1.3.0/debian/changelog2013-08-23 15:39:26.0 +0200
+++ lua-rings-1.3.0/debian/changelog2015-01-18 19:59:59.0 +0100
@@ -1,3 +1,9 @@
+lua-rings (1.3.0-3) unstable; urgency=medium
+
+ * Disable a cache related test on 5.2 (Close: #775622)
+
+ -- Enrico Tassi gareuselesi...@debian.org Sun, 18 Jan 2015 19:58:11 +0100
+
lua-rings (1.3.0-2) unstable; urgency=low
* Fix Provides, was still mentioning a transitional package
diff -Nru lua-rings-1.3.0/debian/patches/0002-Disable-cache-test-on-5.2.patch
lua-rings-1.3.0/debian/patches/0002-Disable-cache-test-on-5.2.patch
--- lua-rings-1.3.0/debian/patches/0002-Disable-cache-test-on-5.2.patch
1970-01-01 01:00:00.0 +0100
+++ lua-rings-1.3.0/debian/patches/0002-Disable-cache-test-on-5.2.patch
2015-01-18 19:59:59.0 +0100
@@ -0,0 +1,21 @@
+From: Enrico Tassi gareuselesi...@debian.org
+Date: Sun, 18 Jan 2015 19:57:43 +0100
+Subject: Disable cache test on 5.2
+
+---
+ tests/test.lua | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tests/test.lua b/tests/test.lua
+index 6eb7de7..68dcbbb 100755
+--- a/tests/test.lua
b/tests/test.lua
+@@ -136,7 +136,7 @@ assert (f1 == f2, Cache is not working)
+ assert (f1 ~= f3, Function `dostring' is producing the same function for
different strings)
+ assert (S:dostringcollectgarbage(); collectgarbage())
+ local ok, f4 = S:dostring(chunk)
+-assert (f4 ~= f1, Cache is not being collected)
++assert (f4 ~= f1 or _G._VERSION == Lua 5.2, Cache is not being collected)
+ local ok, f5 = S:dostring(chunk)
+ assert (f4 == f5, Cache is not working)
+
diff -Nru lua-rings-1.3.0/debian/patches/series lua-
rings-1.3.0/debian/patches/series
--- lua-rings-1.3.0/debian/patches/series 2013-08-23 15:39:26.0
+0200
+++ lua-rings-1.3.0/debian/patches/series 2015-01-18 19:59:59.0
+0100
@@ -1 +1,2 @@
0001-Fix-version-number-to-1.3.0.patch
+0002-Disable-cache-test-on-5.2.patch
unblock lua-rings/1.3.0-3
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775565: ITP: lua5.3 -- scripting language
On Sat, Jan 17, 2015 at 02:40:25PM +0100, Alessandro Ghedini wrote: I just tried to build the package, but the repo lacks the debian/changelog file and a Build-Depends on dh-lua. It lacks many things, I've barely started. It will not use dh-lua since it is not a lua library. Also dh-lua should be patched to support 5.3 too. Best, -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775622: lua-rings: FTBFS in jessie: Tests failures
On Sun, Jan 18, 2015 at 01:42:12AM +0100, Lucas Nussbaum wrote: Source: lua-rings Version: 1.3.0-2 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. I've just built a jessie chroot on amd64 and I could not reproduce the failure. Are there any other known false positives with this round of rebuilds? Best, -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775622: lua-rings: FTBFS in jessie: Tests failures
On Sun, Jan 18, 2015 at 06:00:43PM +0100, Lucas Nussbaum wrote: In this specific case, it seems to be a random failure: (jessie-amd64-sbuild)user@ip-172-31-5-2:/tmp/lua-rings-1.3.0$ while true; do dh_auto_test -O--buildsystem=lua /dev/null echo OK || echo FAIL; done OK OK OK FAIL OK OK FAIL FAIL OK FAIL OK FAIL OK FAIL OK FAIL FAIL FAIL OK OK Hum, after a bunch of attempts I managed to reproduce it. To me the test is too strict on Lua 5.2. It tests the behavior of the garbage collector that is not the same for in 5.1 and Lua 5.2. Moreover Lua 5.2 can reuse a closure but the reference manual does not specify when the runtime is able to do so. The test seems to assume it is never able to do so (and it is the case in 5.1). Can you confirm all failures are indeed when running the test on 5.2? I mean, they should all look like this: *** app static (5.2) * Test: cd src/ @@LUA@@ ../tests/test.lua Rings 1.3.0 Hello World! app.c: ../tests/test.lua:139: Cache is not being collected The only thing allowed to change is app static in the first line, but 5.2 should stay there. It is the case here (but it occurs 1 time every 20 runs or so, so validating my theory here is a bit of a PITA). If it is also the case on your vm I can simply make the test optional (run only on 5.1, where it makes sense IMHO). Best, -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775565: ITP: lua5.3 -- scripting language
Package: wnpp Severity: wishlist Owner: Enrico Tassi gareuselesi...@debian.org * Package name: lua5.3 Version : 5.3.0 Upstream Author : t...@lua.org * URL : http://www.lua.org/ * License : MIT/X Programming Lang: C Description : scripting language A git repo pkg-lua/lua5.3 on alioth was created, help is very welcome. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#498416: liblua5.1-0-dev: please use a consistent pkg-config name (lua5.1 or lua-5.1)
On Mon, Aug 18, 2014 at 09:21:41AM +0200, Helmut Grohne wrote: While I do agree that this is a good reason not to rename the .pc file to plain lua (which is the scope of #694671), I do not agree that making Debian's lua compatible with FreeBSDs is unfixable. Can you explain what would break, if a symbolic link lua-5.1.pc targeting lua5.1.pc was added to /usr/share/triplet/pkgconfig? This symlink would make FreeBSD and Debian compatible. What do you mean by making Debian compatible with FreeBSD ? You want to mix and match the ports with Debian's packages? Best, -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746213: lua-curl: no Lua 5.2 support
On Wed, Apr 30, 2014 at 10:22:25PM -0700, Igor Bogomazov wrote: and of course do not hesitate writing to me, if I can do more than just this patch Sorry I've been busy. Your patch is very welcome as well as any other help packaging the software. I will apply it as soon as possible. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746213: lua-curl: no Lua 5.2 support
On Sun, Apr 27, 2014 at 11:22:50PM -0700, Igor Bogomazov wrote: the package cannot be used with Lua 5.2 that is current stable release of the language; also this is the only cURL wrapper Lua library available in Debian repository; does it make sense for you to adopt the package so that it could be used with Lua 5.2? Sorry but I'm not following. What do you mean by adopting here? I could successfully recompile it from sources with only few lines of code fixed. I am ready to attach the patch here if it might be useful, though the modifications are quite straightforward and well documented… Anyway, let me know if I can help with this! Sure! Your patch is welcome, and any help too. Ciao -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744917: luajit: diff for NMU version 2.0.3+dfsg-2.1
On Fri, Apr 25, 2014 at 08:25:16PM +0200, Evgeni Golov wrote: tags 744917 + patch tags 744917 + pending thanks Dear maintainer, I've prepared an NMU for luajit (versioned as 2.0.3+dfsg-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Can't you just call make passing LDCONFIG=/sbin/ldconfig ? I don't like having patches around, expecially for this software. The upstream dislikes it and in this case it does not seem necessary. Ciao -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741925: syncmaildir: Protocol version mismatch for minor releases?!
On Mon, Mar 17, 2014 at 11:33:28AM +0100, Cyril Brulebois wrote: Changelog says: | 14/03/2014 - feature improvement and gui redesign - version 1.2.6 but what it doesn't mention is that it breaks sync against stable (1.2.5): It is written in the Debian changelog and in the NEWS file. It is nowere written that you can combine smd version X with smd version Y when X and Y are different. The upstream (that is me) was an asshole, he did not want to clutter the code with retrocompatibility stuff. The packager (that is me) made a backport to alleviate the pain. Does the protocol version intentionally changes on every release?! Are you really forcing a server + client*s* lockstep upgrade? No, only when there is a difference in the protocol. This time there was a difference. So yes, this time I'm forcing a lockstep upgrade (with both the upstream and maintainer hat on). so adding -backports@ to X-D-Cc since I didn't see a discussion about a possible exception for this package. No exception was asked for or granted. It just happened that the NEW queue of bpo was processed in less than 5 days, that is what it will hopefully take to smd to migrate to jessie. Yes the maintainer (me of course) was a bad ass and speculated about the timing and did the upload to the bpo queue before smd hit testing. So now, the best thing for all of us, is that you lower the severity of the bug and let smd move to jessie, given that the bpo package is already in place. An apt-get update/install on your machine running stable will fix things. Sorry for the inconvenience. -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741535: libssreflect-coq: please Provide: an ABI
Package: libssreflect-coq Version: 1.5-1 Severity: wishlist Dear Maintainer, packages building coq libraries on top of ssreflect will depend on the md5 sum of the .vo files shipped by this package. There checksums change when Coq is updated, OCaml is updated, ssreflect is updated... Adding an ABI will force us to do a binnmu to avoid distributing a package that installs but whose contents cannot be loaded by Coq. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libssreflect-coq depends on: ii coq [coq-8.4pl3+4.01.0] 8.4pl3dfsg-1 ii libssreflect-ocaml 1.5-1 libssreflect-coq recommends no packages. libssreflect-coq suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741345: ITP: mathematical-components -- Mathematical Components library for the Coq proof system
Package: wnpp Severity: wishlist Owner: Enrico Tassi gareuselesi...@debian.org * Package name: mathematical-components Version : 1.4.0 Upstream Author : Mathematical Components team * URL : http://www.msr-inria.fr/projects/mathematical-components/ * License : BSD Programming Lang: Coq Description : Mathematical Components library for the Coq proof system From version 1.5, the ssreflect source package was split in two by the aupstrem: - ssreflect (OCaml plugin for Coq, plus a small set of Coq files) - mathcomp (the rest of the Coq files) While the former is in debian, the latter is not (yet). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734678: Please depend on lua-sec and remove the silly warning
I think we should just fix util/dependencies.lua, there are plenty of outdated instructions there (concerning Debian). And hopefully the patch will be merged upstream. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676710: Which files?
Sorry, but I quite don't follow. There is no test/ and etc/ directory in Lua 5.2 orig tarball. Which files are missing exactly? Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719519: help needed?
Bzed, do you want me to prepare an NMU with the new upstream release? Currently the package is /completely/ unusable because of the incompatibility with lua-lpeg 0.12. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719519: help needed?
On Thu, Nov 14, 2013 at 07:27:47PM +0100, Bernd Zeimetz wrote: Enrico, Please do so if you have the time. Very appreciated! If you add this as a remote you can then just pull master: http://www.fettunta.org/~gares/BZED/lua-json.git I did a bit more than just updating the upstream sources. I've also removed the transitional package and added a test to the build process. Please, take a look at the merge, since it seems 1.3.2 is not a direct descendent of the commit you used for 1.3. The package builds fine, loads, and passes the simple test. I did not test it harder that that. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722890: any progress?
Any progress? Do you want me to prepare an upload and nmu it do a delayed queue? Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727170: RFP: lua-alien -- Pure Lua extensions
On Wed, Oct 23, 2013 at 01:25:23AM +0200, Axel Beckert wrote: I maintain GNU Zile in Debian. Upstream currently works on a reimplementation of Zile in Lua which seems to become Zile 3. It is awesome you package zile 3! I'll put these lua libs in a git repo so that you can tell me if they works soon. -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722890: Debhelpr compatibility and debian/tmp fallback
I managed to solve this bug. It is caused by dh_pyppd that fails to
find the .pdd files and does not generate the /usr/lib/cups/driver/escpr
file that is needed to install a printer.
The problem is that the ppds are in debian/tmp/... while dh_pyppd looks
for them in debian/$pkg/
The attached patch imitates dh_install that falls back to debian/tmp
if the requested file is not found in debian/$pkg.
Cheers
--
Enrico Tassi
From 533d32b96fffc7f13f437257403a0f566a213e3a Mon Sep 17 00:00:00 2001
From: Enrico Tassi gareuselesi...@debian.org
Date: Mon, 7 Oct 2013 23:22:56 +0200
Subject: [PATCH] fallback to debian/tmp if no ppd is found
---
debian/changelog | 7 +++
debian/dh_pyppd | 9 +
2 files changed, 16 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index 71d296c..f1f5a9d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pyppd (1.0.1-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * fallback to debian/tmp if no ppds are found in debian/$pkg
+
+ -- Enrico Tassi gareuselesi...@debian.org Mon, 07 Oct 2013 23:22:14 +0200
+
pyppd (1.0.1-1) unstable; urgency=low
* New 1.0.1 upstream release.
diff --git a/debian/dh_pyppd b/debian/dh_pyppd
index eb10b53..b38b12d 100755
--- a/debian/dh_pyppd
+++ b/debian/dh_pyppd
@@ -39,6 +39,15 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
}
}, $ppd_src);
+ # fall back to debian/tmp as dh_install does
+ if (! compat(6) ! $ppds_presence) {
+ $ppd_src=debian/tmp/usr/share/;
+ find(sub { if(($_ =~ m/\.ppd(\.gz)?$/) ) {
+$ppds_presence++;
+ }
+ }, $ppd_src);
+ }
+
if( $ppds_presence ) {
# verbose_print(PPDs found in $ppd_src.);
--
1.8.4.rc3
Bug#724679: ITP: lua-uri -- pure Lua library to normalize and validate URIs/URLs
On Thu, Sep 26, 2013 at 05:13:46PM +0200, Victor Seva wrote: Package: wnpp Severity: wishlist Owner: Victor Seva linuxman...@torreviejawireless.org * Package name: lua-uri Version : 0.1 Upstream Author : Geoff Richards ge...@geoffrichards.co.uk * URL : http://www.geoffrichards.co.uk/lua/uri/ * License : MIT/X Programming Lang: Lua Description : pure Lua library to normalize and validate URIs/URLs Provides methods for manipulating URIs in various ways. In particular, you can resolve relative URI references to create absolute URIs, and extract parts of URIs. How does this relate to luasocket url module? Is it truly superior? I've no opinion, I'm just asking... Ciao -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724509: luarocks library detection works poorly with Debian
On Tue, Sep 24, 2013 at 11:55:49PM +0900, Miles Bader wrote: I suppose the easy solution is to just hack Debian's version of luarocks to know about Debian's particular library locations. Thanks for reporting the bug. This is what I will do ;-) [Of course a much better solution would be to use some sort of less hacky method of finding libraries, e.g. by using autoconf's probe using the compiler but I suppose that's unlikely to happen.] May I ask why you are using luarocks instead of `apt-get install lua-sec`? Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723766: mudlet: Please use post-wheezy Lua package names in Depends
Package: mudlet
Version: 1:2.1-1
Severity: normal
Dear Maintainer, I'm attaching a patch to use post-wheezy Lua package names in
the Depends field. This amounts to replace liblua5.1-rex-pcre0 and liblua5.1
-sql-sqlite3-2 with lua5.1-rex-pcre and lua5.1-sql-sqlite3.
Given that the lua-rex-pcre binary package provides the virtual package
lua5.1-rex-pcre, if you need to depend on a specific version of lua-rex you can
express it like:
Depends: lua5.1-rex-pcre, lua-rex-pcre (= X)
You can also use lua-rex-pcre directly in the dependencies, but using
lua5.1-rex-pcre is preferred since it tells for which version of Lua you need
the rex-pcre package. The lua-rex-pcre package currently provides it for
both Lua 5.1 and 5.2. The same holds for lua-sql-sqlite3.
Cheers
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
Enrico Tassi
From 198eba0ecf03c6ab5e930781cf2e4b75b2741981 Mon Sep 17 00:00:00 2001
From: Enrico Tassi gareuselesi...@debian.org
Date: Thu, 19 Sep 2013 18:09:07 +0200
Subject: [PATCH] Use post-wheezy lua package names
---
debian/control | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index cff962e..d8d4862 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Homepage: http://www.mudlet.org/
Package: mudlet
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, liblua5.1-rex-pcre0, liblua5.1-sql-sqlite3-2
+Depends: ${shlibs:Depends}, ${misc:Depends}, lua5.1-rex-pcre, lua5.1-sql-sqlite3
Suggests: hunspell-en-us
Description: Graphical MUD client with fast lua scripting support
A completely redesigned MUD (Multi User Dungeon) client that is easy to
--
1.8.4.rc3
Bug#723765: luakit: Please use post-wheezy Lua package names in Depends
Package: luakit
Version: 2012.09.13-r1-2
Severity: normal
Dear Maintainer, I'm attaching a patch to use post-wheezy Lua package names in
the Depends field.
This accounts to replace liblua5.1-filesystem0 with lua5.1-filesystem.
Given that the lua-filesystem binary package provides the virtual package
lua5.1-filesystem,
if you need to depend on a specific version of lua-filesystem you can express
it like:
Depends: lua5.1-filesystem, lua-filesystem (= X)
You can also use lua-filesystem directly in the dependencies, but using
lua5.1-filesystem is preferred since it tells for which version of Lua you need
the filesystem package. The lua-filesystem package currently provides it for
both Lua 5.1 and 5.2.
Cheers
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
Enrico Tassi
From 81bd1b6ae05c67f2a2aec6d3192b380351a587a0 Mon Sep 17 00:00:00 2001
From: Enrico Tassi gareuselesi...@debian.org
Date: Thu, 19 Sep 2013 18:21:57 +0200
Subject: [PATCH] Use post-wheezy Lua package names in Depends
---
debian/changelog | 8
debian/control | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index a98dc97..88b82fd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+luakit (2012.09.13-r1-3) UNRELEASED; urgency=low
+
+ [ Enrico Tassi ]
+ * Use post-wheezy Lua package names in Depends:
+- liblua5.1-filesystem0 - lua5.1-filesystem
+
+ -- Clint Adams cl...@debian.org Thu, 19 Sep 2013 18:20:31 +0200
+
luakit (2012.09.13-r1-2) unstable; urgency=low
* Cherry-pick 105530f1542d568a6cf8d236eb1dc84fa982703b and
diff --git a/debian/control b/debian/control
index 023dedc..7a78b71 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Vcs-Browser: http://git.debian.org/?p=collab-maint/luakit.git;a=summary
Package: luakit
Architecture: any
-Depends: ${shlibs:Depends}, liblua5.1-filesystem0
+Depends: ${shlibs:Depends}, lua5.1-filesystem
Description: fast and small web browser extensible by Lua
Luakit is a highly-configurable browser framework based on WebKitGTK+.
It is very fast and extensible by Lua. It is primarily targeted at power
--
1.8.4.rc3
Bug#723483: lua5.1 link with -L/usr/lib
On Tue, Sep 17, 2013 at 06:48:59PM +0800, YunQiang Su wrote: Package: lua5.1 Version: 5.1.5-5 X-Debbugs-CC: wzss...@gmail.com This package has one or more -L/usr/lib in its build system, True, and the .pc file is also wrong and this percolates to all other lua libraries. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722890: printer-driver-escpr: Driver not shown in the drivers list anymore
Package: printer-driver-escpr Version: 1.2.3-2 Severity: important Dear Maintainer, I used this driver in the past with the same printer and 2 different laptops. The printer is a XP-302. Then I changed one of the laptops and reinstalled Debian sid from scratch. Now, when I try to add the printer on the new laptop the driver does not show up. If I use the gnome control center, it just silently quit. If I use the web interface on port 631 I see the driver is not in the list. The funny thing is that the other laptop, which runs the same version of the package, works fine. My guess is that the driver is functional, but something needed only to add a new printer got screwed up. I don't know how to debug this, but I'm willing to follow instructions and report back. Cheers -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages printer-driver-escpr depends on: ii libc6 2.17-92+b1 ii libcups2 1.6.3-1 ii libcupsimage2 1.6.3-1 Versions of packages printer-driver-escpr recommends: ii cups-ppdc 1.6.3-1 Versions of packages printer-driver-escpr suggests: ii psutils 1.17.dfsg-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721228: notmuch-mutt help opens the wrong manpage
Package: notmuch-mutt Version: 0.16-1 Severity: normal Dear Maintainer, notmuch-mutt in response to the '?' key opens the manpage of notmuch, while the manpage for notmuch-search-terms would be more appropriate. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages notmuch-mutt depends on: ii libfile-which-perl 1.09-1 ii libmail-box-perl 2.108-1 ii libmailtools-perl 2.12-1 ii libstring-shellquote-perl 1.03-1 ii libterm-readline-gnu-perl 1.20-2+b1 ii notmuch0.16-1 Versions of packages notmuch-mutt recommends: ii fdupes 1.50-PR2-4 ii mutt1.5.21-6.3 notmuch-mutt suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721228: notmuch-mutt help opens the wrong manpage
close 721228 thanks On Thu, Aug 29, 2013 at 12:38:59PM +0300, Stefano Zacchiroli wrote: This have been fixed a while ago: Sorry for the noise, I had an old copy of the script in ~/bin and when I looked at the source code, vim `which notmuch-mutt` tricked me. Ciao -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712975: ping
Are you still interested in this patch? Does it also work or it just compiles? Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719795: ITP: lua-lpty -- PTY library for the Lua language
Package: wnpp Severity: wishlist Owner: Enrico Tassi gareuselesi...@debian.org * Package name: lua-lpty Version : 1.0.1 Upstream Author : Gunnar Zötl g...@tset.de * URL : http://www.tset.de/lpty/ * License : MIT/X Programming Lang: C, Lua Description : PTY library for the Lua language This package is needed by the prosody xmpp server to support external authentication plugins -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713117: lua-penlight: FTBFS: build-dependency not installable: lua-ldoc
On Fri, Jul 05, 2013 at 01:36:31PM +0100, Colin Watson wrote: This was probably a transient problem due to lua-ldoc's dependency on the new lua-penlight. However, now that that has cleared, lua-penlight still fails to build in a clean chroot: Right, I will look at that during debconf. Moreover I have a newer version of penlight ready to be uploaded, and it may fix that as well. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707577: Is it still relevant?
Today 3.8.x is not even more in Debian, while 3.9.x in part of testing. This package does not migrate because of this bug. Is this bug still present with linux 3.9? If not its severity should be lowered to let the package migrate. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712975: luajit: support for Hurd
On Fri, Jun 21, 2013 at 01:33:25PM +0200, Pino Toscano wrote: the attached patches provide support for GNU/Hurd in luajit: * hurd.diff: - recognizes Hurd as POSIX OS (I guess it is okay, otherwise a new LUAJIT_OS_HURD could be defined and used if needed) - links to libdl on Hurd (needed for dlopen friends) * debian.diff: adds hurd-i386 to the supported architectures in arch:any binaries (PS: libluajit-5.1-dev lacks powerpcspe) Thanks for the patch. Does luajit work properly on hurd once compiled? cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710286: lua-lgi: Missing Depends on gir1.2-glib-2.0
On Thu, May 30, 2013 at 12:28:54AM +0900, Arnaud Fontaine wrote: After investigating a bit, it appears that gi_require() (lgi/gi.c) calls g_irepository_require() which searches for .typelib files, but GLib and GObject .typelib files are not available because gir1.2-glib-2.0 is not installed on my system (and thus missing in the Depends, but it seems that only GObject and GLib .typelib are required according to the source code). So, could you please add this package to Depends? Thanks for the fix! BTW, is there any reason why lua-lgi does not Depends upon any lua interpreter package? Is it actually useable without it? Yes, if the software is linked with liblua5.1 then it can load and use liblua5.1-lgi too. I tried to exaplain it here: http://pkg-lua.alioth.debian.org/policy.html#ch-notesundef Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704501: lua-lpeg: fails to install with errors from ldconfig
On Tue, Apr 02, 2013 at 11:30:28AM +0900, Miles Bader wrote: Package: lua-lpeg Version: 0.10.2-5 Severity: normal As the subject, it fails to install for me. I've included the error output below. ldconfig doesn't give the location of the cache file that it's barfing on, so I'm not sure what it's trying to do... Do other packages install fine? I quite don't see how this could be a problem of lua-lpeg only. $ LANG=C dinst lua-lpeg Sorry for the ignorance, but what is dinst? ldconfig: Writing of cache data failed: No such file or directory ldconfig is a program you can run by hand (as root). Its config file could also be interesting to look at (/etc/ld.so.conf). The cache file is in /etc/ too, and is generated by ldconfig that scans the paths listed in ld.so.conf for new shared objects. Do you have any weird thing going on in /etc/ ? Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691238: unblock: lua-wsapi/1.5-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package lua-wsapi Fixes #691214 : wsapi.cgi won't run because it has DOS file endings with a sed one liner. diff -Nru lua-wsapi-1.5/debian/changelog lua-wsapi-1.5/debian/changelog --- lua-wsapi-1.5/debian/changelog 2012-04-28 12:50:35.0 +0200 +++ lua-wsapi-1.5/debian/changelog 2012-10-23 13:07:12.0 +0200 @@ -1,3 +1,9 @@ +lua-wsapi (1.5-3) unstable; urgency=low + + * wsapi.cgi lines ending converted to unix (Closes: #691214) + + -- Enrico Tassi gareuselesi...@debian.org Sat, 28 Apr 2012 12:58:38 +0200 + lua-wsapi (1.5-2) unstable; urgency=low * Switch to dh-lua diff -Nru lua-wsapi-1.5/debian/rules lua-wsapi-1.5/debian/rules --- lua-wsapi-1.5/debian/rules 2012-04-28 11:47:12.0 +0200 +++ lua-wsapi-1.5/debian/rules 2012-10-23 13:06:17.0 +0200 @@ -12,6 +12,6 @@ override_dh_auto_install: mkdir -p debian/tmp/usr/bin - cp src/launcher/wsapi.cgi debian/tmp/usr/bin/ + sed 's/\x0D$$//' src/launcher/wsapi.cgi debian/tmp/usr/bin/wsapi.cgi cp src/launcher/wsapi.fcgi debian/tmp/usr/bin/ dh_auto_install unblock lua-wsapi/1.5-3 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685265: syncmaildir: fails on '' in Maildir names in EXCLUDE* ([smd-bug] internal error)
On Mon, Oct 01, 2012 at 06:00:20PM +0200, gregor herrmann wrote: The attached patch brings me over this failure; no idea if it has any side effects, I haven't dared to run smd* without --dry-run :) Good news: smd is running flawlessly for me since a week. I clearly understand your patch, it seems OK to me. And I'm indeed glad it works ;-) I does, and I'm happily using smd since then :) I've been able to reproduce the bug. The bad news is that your fix does not work. The folder you marked for exclusion is probably not excluded at all, since the ' is interpreted as part of the glob expression (at least by smd-pull). The bug is clearly a consequence of the escaping madness of the shell. The bits of smd written in shell script have grown too much, and it is time to rewrite them in a less error prone language. I think that the easiest workaround for you, if you want exclude the folder in question, is to revet your patch and replace with %26 in the EXCLUDE_* glob expression (as you have to do with %20 for spaces). Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685265: syncmaildir: fails on '' in Maildir names in EXCLUDE* ([smd-bug] internal error)
On Thu, Oct 04, 2012 at 12:39:32PM +0200, gregor herrmann wrote: Ah, that might explain why it works (as in: I have the folders locally on the laptop but not on the server -- just checked again, they really are not there). Is there something different for -pull and -push with regard to EXCLUDE(_LOCAL)? Nothing but for the number of time the value is parsed by the shell. When you pull you do something like: ssh host smd-server --exclude $EXCLUDE_REMOTE ... and the remote smd-server passes the flag to mddiff. If you push, you directly call mddiff with the $EXCLUDE_LOCAL flag. For some reasons I did not dig into, one of the two commands asks the shell to parse the argument lists passed around twice. I tried a bit to use `eval` to unifor the things, but I decided it is better to fix the problem in another way ;-) Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685265: syncmaildir: fails on '' in Maildir names in EXCLUDE* ([smd-bug] internal error)
On Sun, Aug 26, 2012 at 03:48:23PM +0200, gregor herrmann wrote: On Sun, 19 Aug 2012 01:56:49 +0200, gregor herrmann wrote: The attached patch brings me over this failure; no idea if it has any side effects, I haven't dared to run smd* without --dry-run :) Good news: smd is running flawlessly for me since a week. Sorry for the late reply. I clearly understand your patch, it seems OK to me. And I'm indeed glad it works ;-) But I was not able to reproduce the bug. Could you tell me more about your setup? Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685001: syncmaildir: duplicate emails for no obvious reasons
On Wed, Aug 15, 2012 at 06:42:11PM +0200, Luca Capello wrote: Hi there! Sorry for the long delay. I took come VAC ;-) However, I get duplicate emails for no obvious reasons. I know that at least one duplicate come from my synced machine because of its filename: Maildir/cur/1345032816.1118_0.mantissa:2, Maildir/cur/1345042069.M833566P8146.gismo,S=3250,W=3324:2, Maildir/cur/1345042092.M850696P3594.mantissa,S=3250:2, Maildir/cur/1345042092.M850697P3594.mantissa,S=3250:2, Can you be more explicit? Here I see 4 messages, 2 of which have a very similar file name. Where is the problem? Are they all the same message? I have not done anything special with the above mailbox except accessing it directly from the server between two smd-pull runs. This is something vital for me: I want to be able to access any copy of my mailbox whenever/wherever I want. It is designed to let you do that, so in principle it is possible. While the above happened on gismo (my main laptop, sid with no fancy DE) with mantissa being the server (with 1.2.5-1~bpo60+1), I experienced the same on a wheezy standard installation (GNOME3, see #682737) where smd-loop was started by the smd-applet: I am sure that at least at the first synchronization I got duplicates. Given that my mailbox is quite big (see #659263), I copied it to the new machine before starting smd-pull: however, this latter took more than 2 hours and I needed different tries to have it finished (the problem was the network connectivity). I would guess that stopping an smd run leaves cruft behind, which results in duplicates. Hum, killling smd on the way should not be a problem. If it leaves cruft, then it is in the tmp/ directory of the maildir, that is not even displayed by MUAs. However, after some thinking, I think I can trick smd to duplicate a mail in the following way: I start a sync from A - B, it copies file m from host A to host B, say a message marked as NEW. I kill smd before it finishes. Then I log on B, I read my email, I mark m as OLD. Then I start the sync again from A - B, m is copied to B again, since it is not there (I moved it from new/ to cur/, possibly altering its header too) and since the premature death of smd prevented it from updating its metadata with the info the m was on B too. So yes, killing smd _while_ changing the mailbox status may lead to duplicates, but you are relly playing against it. Is that what happened? If this is not the case, I've few remarks on the first sync: - If you start copying the mailbox, then no duplicates should pop up. If it does there is a bug, and I need more data to reproduce it. But this is very unlikely. - If you start from 2 similar mailboxes, say kept in sync using offlineimap, then some duplicates may pop up during the first sync, since the _same_ email could be named differently on the two hosts. Indeed in 1.2.5 I've added smd-uniform-names to cope with that. It generates a script to uniform names, to be run before the first sync. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689316: unblock: prosody/0.8.2-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package prosody
This version fixes #681667 : Broken initscript (won't stop prosody)
The debdiff is pretty trivial: the init script starts prosody using
the Lua interpreter called lua5.1, but the passes --name lua to start-stop-
daemon. This is fixed in 0.8.2-4.
diff -Nru prosody-0.8.2/debian/prosody.init prosody-0.8.2/debian/prosody.init
--- prosody-0.8.2/debian/prosody.init 2011-03-02 11:51:28.0 +0100
+++ prosody-0.8.2/debian/prosody.init 2012-09-27 17:59:31.0 +0200
@@ -25,7 +25,7 @@
mkdir -p `dirname $PIDFILE`
chown prosody:adm `dirname $PIDFILE`
if start-stop-daemon --start --quiet --pidfile $PIDFILE \
- --chuid $USER --oknodo --user $USER --name lua \
+ --chuid $USER --oknodo --user $USER --name lua5.1 \
--startas $DAEMON;
then
return 0
@@ -36,7 +36,7 @@
stop_prosody () {
if start-stop-daemon --stop --quiet --retry 30 \
- --oknodo --pidfile $PIDFILE --user $USER --name lua;
+ --oknodo --pidfile $PIDFILE --user $USER --name lua5.1;
then
return 0
else
@@ -46,7 +46,7 @@
signal_prosody () {
if start-stop-daemon --stop --quiet --pidfile $PIDFILE \
- --user $USER --name lua --oknodo --signal $1;
+ --user $USER --name lua5.1 --oknodo --signal $1;
then
return 0
else
unblock prosody/0.8.2-4
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683025: unblock: lua5.1/5.1.5-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package lua5.1
This version of lua5.1 fixes a nasty multiarch related issue (bug #676695)
that makes a macro available in lua.h impossible to use. In particular the
LUA_CPATH_DEFAULT causes a compilation error (it uses an undefined
macro) unless the clfags output by `pkg-config lua5.1 --cflags` are used.
Moreover the extra cflag -DDEB_HOST_MULTIARCH=\triplet\ output
by pkg-config is particularly nasty to escape and users reported various
problems using their build systems in conjunction with this flag.
No package in Debian uses the LUA_CPATH_DEFAULT macro, hence the
fact that it has been broken for almost a year caused no FTBFS, but users
testing the content of the upcoming weezy release on their non-packaged
softwares spotted the error, unfortunately a bit late in the release cycle.
This version of the package does not use a -D flag to set the value of
DEB_HOST_MULTIARCH. Instead it puts the appropriate #define line in the
lua5.1-deb-multiarch.h file that is installed in /usr/include/triplet and
#included in lua.h. In this way no extra flag (but for -I/usr/include/lua5.1)
is needed to compile against Lua and use the LUA_CPATH_MACRO (i.e. the list
of paths in which the Lua interpreter looks for extensions).
Begin Debdiff.
diff -Nru lua5.1-5.1.5/debian/changelog lua5.1-5.1.5/debian/changelog
--- lua5.1-5.1.5/debian/changelog 2012-05-03 15:12:32.0 +0200
+++ lua5.1-5.1.5/debian/changelog 2012-07-23 11:41:06.0 +0200
@@ -1,3 +1,18 @@
+lua5.1 (5.1.5-4) unstable; urgency=low
+
+ * Rename lua-deb-multiarch.h into lua5.1-deb-multiarch.h and install it in
+/usr/include/$DEB_HOST_MULTIARCH/ to make it available with no extra
+-I directive (Closes: #682234, #682183, #682299)
+
+ -- Enrico Tassi gareuselesi...@debian.org Wed, 18 Jul 2012 18:43:50 +0200
+
+lua5.1 (5.1.5-3) unstable; urgency=low
+
+ * Install architecture dependent .h file in /usr/lib and fix .pc files
+accordingly to fix multiarch issues (Closes: #676695)
+
+ -- Enrico Tassi gareuselesi...@debian.org Mon, 16 Jul 2012 12:48:01 +0200
+
lua5.1 (5.1.5-2) unstable; urgency=low
* Put in the pkg-config .pc file -DDEB_HOST_MULTIARCH so that including
diff -Nru lua5.1-5.1.5/debian/lua-c++.pc.in lua5.1-5.1.5/debian/lua-c++.pc.in
--- lua5.1-5.1.5/debian/lua-c++.pc.in 2012-05-03 15:13:13.0 +0200
+++ lua5.1-5.1.5/debian/lua-c++.pc.in 2012-07-23 11:41:06.0 +0200
@@ -22,4 +22,4 @@
Requires:
Libs: -L${libdir} -l${lib_name}
Libs.private: -lm -ldl
-Cflags: -I${includedir}/${lib_name_include}
-DDEB_HOST_MULTIARCH=\${deb_host_multiarch}\
+Cflags: -I${includedir}/${lib_name_include}
diff -Nru lua5.1-5.1.5/debian/lua.pc.in lua5.1-5.1.5/debian/lua.pc.in
--- lua5.1-5.1.5/debian/lua.pc.in 2012-05-03 15:13:28.0 +0200
+++ lua5.1-5.1.5/debian/lua.pc.in 2012-07-23 11:41:06.0 +0200
@@ -22,4 +22,4 @@
Requires:
Libs: -L${libdir} -l${lib_name}
Libs.private: -lm -ldl
-Cflags: -I${includedir}/${lib_name_include}
-DDEB_HOST_MULTIARCH=\${deb_host_multiarch}\
+Cflags: -I${includedir}/${lib_name_include}
diff -Nru lua5.1-5.1.5/debian/patches/debian_make.patch
lua5.1-5.1.5/debian/patches/debian_make.patch
--- lua5.1-5.1.5/debian/patches/debian_make.patch 2011-12-24
15:35:45.0 +0100
+++ lua5.1-5.1.5/debian/patches/debian_make.patch 2012-07-23
11:41:06.0 +0200
@@ -1,9 +1,9 @@
Author: John V. Belmonte jbelmo...@debian.org
Description: Add support for Debian package to makefiles.
-Index: lua5.1-5.1.4/Makefile
+Index: lua5.1-5.1.5/Makefile
===
lua5.1-5.1.4.orig/Makefile 2008-08-12 02:40:48.0 +0200
-+++ lua5.1-5.1.4/Makefile 2011-07-25 22:26:28.0 +0200
+--- lua5.1-5.1.5.orig/Makefile 2012-02-10 10:50:23.0 +0100
lua5.1-5.1.5/Makefile 2012-07-16 12:25:26.0 +0200
@@ -12,7 +12,7 @@
INSTALL_TOP= /usr/local
INSTALL_BIN= $(INSTALL_TOP)/bin
@@ -13,7 +13,7 @@
INSTALL_MAN= $(INSTALL_TOP)/man/man1
#
# You probably want to make INSTALL_LMOD and INSTALL_CMOD consistent with
-@@ -126,3 +126,31 @@
+@@ -126,3 +126,30 @@
.PHONY: all $(PLATS) clean test install local none dummy echo pecho lecho
# (end of Makefile)
@@ -43,12 +43,11 @@
+# ISSUE: MYCFLAGS not honored in the case of a CFLAGS override
+debian_linux:
+ cd src; $(MAKE) debian_all CFLAGS+=-DLUA_USE_LINUX \
-+ CFLAGS+=-DDEB_HOST_MULTIARCH=\\\$(DEB_HOST_MULTIARCH)\\\ \
+ LIB_LIBS=-lm -ldl LUA_LIBS=-lreadline LDFLAGS=$(LDFLAGS)
-Index: lua5.1-5.1.4/src/Makefile
+Index: lua5.1-5.1.5/src/Makefile
===
lua5.1-5.1.4.orig/src/Makefile 2008-01-19 20:37:58.0 +0100
-+++ lua5.1-5.1.4/src/Makefile 2011-07-25 22:25:52.0 +0200
+--- lua5.1-5.1.5.orig/src
Bug#682183: the list of FTBFSes
On Mon, Jul 23, 2012 at 12:44:53PM +0800, Aron Xu wrote: Hi, I'm for Adam's patch, it looks to be the correct approach to resolve the problem as well as fulfill the requirement of being multiarch. In case of doubt I have tried to rebuild all rdepends of liblua5.1-0 in Sid and there is no regression found in the builds. So please apply the patch and make an upload, so we are able to continue to upload other packages depending on lua5.1. For me it's src:fcitx, which an unblock has been granted but I'm unable to upload due to lua5.1... I'm on it right now. I'll change a bit the patch since installing in patch shared by all packages a file called lua-deb-multiarch.h will prevent lua5.1 and 5.2 to cohexist. I rename the file to lua5.1-deb-multirch.h and I dput. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682183: the list of FTBFSes
On Mon, Jul 23, 2012 at 09:19:40PM +0800, Aron Xu wrote: Thank you! We'll need to make sure this version be unblocked by release team so newly built binaries depending on liblua5.1 can migrate to testing without problem. I've already pinged debian-release, but I guess they want to see if it really fixes all the FTBFS before giving the green flag. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682183: liblua5.1-0-dev: lua-deb-multiarch.h not found when compiling source including lua.h
On Fri, Jul 20, 2012 at 09:34:14AM +0200, Sebastien Helleu wrote: Package: liblua5.1-0-dev Version: 5.1.5-3 Severity: normal $ gcc -I/usr/include/lua5.1 -o test-lua test-lua.c The problem is that you added by hand -I/usr/include/lua5.1 while you should get CFLAGS in a more systematic way. Try `pkg-config --cflags lua5.1`. As you will see there is an extra -I flag to be passed to gcc. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682183: the list of FTBFSes
On Fri, Jul 20, 2012 at 04:31:23PM +0200, Adam Borowski wrote: severity 682183 serious kthxbye If you're interested, the logs are at http://angband.pl/tmp/lua-logs/ While one could change every single of these packages, this is not something reasonable at this point of the freeze. Thus, instead of 40+ FTBFS bugs, I'm instead upgrading this one. Looking around, it looks it could be fixed by: * moving lua-deb-multiarch.h to /usr/include/$arch/ * removing /usr/lib/x86_64-linux-gnu/lua5.1/include/ from pkgconfig data I kind of fail to see how lua-deb-multiarch.h is related to lua at all, it's an include that's generally useful. If it's the default search path, you can still cross-compile, but don't have to specify it in a -I stanza. Thanks for the list, I think I should just revert my last change, plus some extra magic for cpp. I'll do it as soon as possible. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682234: liblua5.1-0-dev: Lua5.1 include changes in 5.1.5-3 cause other packages to FTBFS
On Fri, Jul 20, 2012 at 10:41:32AM -0400, Scott Kitterman wrote: This is not a multi-arch package (and won't be for Wheezy). I'm working on that, I'll eventually revert the change. The point is that -I/usr/include/lua5.1 is not enough in -3, you have to add -I/usr/lib/lua5.1/include/. It is added if you ask pkg-config the right flags for lua5.1, but not everybody uses pkg-config. Version -2 of the lua .h files is partially broken in the sense that if you use on the C side of your application the defined macros to know the path in which the interpreter looks for libraries, you have an incomplete path (unless you use the flags given by pkg-config, that adds -DDEB_HOST_MULTIARCH=triplet and then cpp does the rest). I think I made things worse with my last change. I'll try to fix that as soon as possible, probably reverting the change but putting a warning in case you include the .h without passing to cpp the right flags. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676695: pkg-config data of lua packages -- how it should be fixed
On Tue, Jul 10, 2012 at 01:55:22AM +0900, Osamu Aoki wrote: Up to here, I am with you. I'm open to suggestions, but I _need_ to pass that -D option, since it is not just a matter of linking, it is also that the Lua rintime clients, including lua.h and the like, have to find where .so objects are, and this is DEB_HOST_MULTIARCH dependent. Here, I am lost. I thought that *.so objects are in DEB_HOST_MULTIARCH dependent path but that path change is taken care by the patch to the Debian's patched loader. Also, what is lua.h. That is not arch dependent anyway. I do not understand what are you thinking. But I am quite new to this multi-arch thing so I guess you know better. Yep, the loader known about multiarch, but also the Lua runtime has to known. The list of paths it searches for .so files is defined in luaconf.h (or lua.h IIRC). So I have 2 options: 1) install .h in usr/lib as glib does 2) ask the user (or pkg-config) to pass -D flag $ pwd;grep -R -i -e MULTIARCH * Yes, it seems I'm a bit lonely here. I will try to fix that tomorrow, today I've been too busy. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676695: pkg-config data of lua packages -- how it should be fixed
On Sun, Jul 08, 2012 at 10:34:53PM +0900, Osamu Aoki wrote:
This is clearly regression of: lua5.1 (5.1.5-2):
* Put in the pkg-config .pc file -DDEB_HOST_MULTIARCH so that including
lua.h (and consequently luaconf.h) works fine even if one is not using
debhelpers (Closes: #671286, LP: #977813)
-- Enrico Tassi gareuselesi...@debian.org Thu, 03 May 2012 14:34:16 +0200
No, it's just that pkg-config changes its output w.r.t. escaping every
day ;-)
If you set
Cflags: -I${includedir}/${lib_name_include}
-DDEB_HOST_MULTIARCH=${deb_host_multiarch}
instead of
Cflags: -I${includedir}/${lib_name_include}
-DDEB_HOST_MULTIARCH='${deb_host_multiarch}'
i.e. you remove ' around the value of DEB_HOST_MULTIARCH your example
works nicely. I've added these ' just because, say, 1 month ago, a
bugreport made them necessary.
I'm open to suggestions, but I _need_ to pass that -D option, since it
is not just a matter of linking, it is also that the Lua rintime
clients, including lua.h and the like, have to find where .so objects
are, and this is DEB_HOST_MULTIARCH dependent.
This can be fixed by debian/lua*.pc.in (just by above argument)
-Cflags: -I${includedir}/${lib_name_include}
-DDEB_HOST_MULTIARCH=\${deb_host_multiarch}\
+Cflags: -I${includedir}/${lib_name_include}
-DDEB_HOST_MULTIARCH=${deb_host_multiarch}
I know this may be a minimum fix for under freeze situation. But is this fix
the best
way? I do not see any other packages on my system uses this approach.
IIRC the are necessary, since in luaconf.h I have to concatenate this
flag with other strings.
Maybe I should just use the usual CPP trick to stringify a value, and
pass it without any kind of quotes... I'll try that, but not before
tomorrow.
Cheers
--
Enrico Tassi
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679925: error not handled correctly, potential crash
Package: lua-event Version: 0.4.1-1 Severity: grave Tags: upstream When this binding is used with libevent 2.0 some errors are not handled properly. An extract of the personal communication with the maintainer of the binding follows, giving precise details on how this bug affects, for example, the prosody jabber server. -- 8 - From: Matthew Wild The problem is caused by a combination of Lua's exception handling (setjmp+longjmp) and some new re-entrant checks added to libevent. When an error occurs inside an event callback Lua (at the C level) jumps outs of libevent and up to the last set error handler, which in Prosody is before libevent is called. After logging the error Prosody heads back into libevent, but unfortunately libevent2 has an internal flag to prevent entering it twice. Because the error jumped right back, this flag is never unset and libevent immediately returns (thinking it is already running). This triggers a shutdown in Prosody. The consequence is that given any other bug that causes an error to be thrown in Prosody (there aren't many, but they exist) it's possible to remotely shut down a Prosody server that is using libevent, even from an unauthenticated connection. -- 8 - -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lua-event depends on: ii libc6 2.13-33 ii libevent-2.0-5 2.0.19-stable-3 ii lua-socket 2.0.2-8 ii multiarch-support 2.13-33 lua-event recommends no packages. lua-event suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672657: Not suitable for weezy
On Mon, Jul 02, 2012 at 07:12:47PM +0200, Moritz Muehlenhoff wrote: In accordance with the upstream, luajit will not be part of weezy, but rather be made available via backports. What makes luajit not acceptable for Wheezy? That the upstream prefers not to have a beta version of luajit frozen in Debian stable for, say, 2 years. He prefers his software to be distributed using the backports mechanism, and updated regularly until he decides to release 2.0. The reason I'm asking is that there are three reverse deps, which are currently part of testing: Hum, luajit and lua are binary compatible. luajit has some extra things in it, so we should inspect the packages in question. I can take care of that. If, as I suspect, they don't need luajit but just a lua implementation, their depdendencies can be, in accordance to their maintainers, changed to liblua5.1-dev. uwsgi ulatencyd mudlet Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672657: Not suitable for weezy
On Mon, Jul 02, 2012 at 07:12:47PM +0200, Moritz Muehlenhoff wrote: uwsgi ulatencyd mudlet As I suspected all the dependencies are soft, so we can just drop them in favour of liblua5.1-0-dev. But of course these packages have to be uploaded to fix the issue. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679564: misuse of lua-posix API
Package: ulatencyd Severity: normal There is no symbol posix.R_OK, and as far as the upstream can tell, it has never been there. The correct call to the API is access(path, r) and not access(path, posix.R_OK). Since the default for access is mode r, passing nil is fine. Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677739: Acknowledgement (lua-sql-mysql: does not work)
On Mon, Jun 18, 2012 at 10:24:16AM -0300, Tomas Guisasola Gorham wrote: I noted that incompatibility but no one has mentioned any problem until now. I thought that, in fact, the correct way to use LuaSQL was not to assume the global luasql, but I think the example does not follow that principle. Anyway, I think the actual version being compatible with both Lua 5.1 and 5.2 pays off the price of the mentioned incompatibility. But do you think this incompatibility deserves a special conditional compilation that could just assign to the global variable to guarantee backwards compatibility? I think this is easy to do! No, I think it does not deserve an #ifdef. For the Debian side, this bugreport documents the problem and provides the fix. I will also add a note inside the package NEWS file time permitting. I think you should just fix the examples, and maybe add a note in the changelog/readme, so that if one hits the problem and looks at the project homepage he finds the fix as well. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677739: Acknowledgement (lua-sql-mysql: does not work)
On Sat, Jun 16, 2012 at 11:52:53AM -0400, Gedalya wrote: My report is poor in detail, I'd be happy to provide more if someone tells me how :-) No, it is perfect. The point is that the statement require 'foo' sets a global 'foo' table in Lua 5.1, but in Lua 5.2 it does not and the idiom is indeed foo = require 'foo' this release of luasql works for both lua 5.1 and 5.2, so I think the author tried to provide a consistent semantics (he is in CC, in case I'm wrong, please speak up). Now, the fix is rather easy on your side: luasql = require 'luasql.mysql' What I'm missing is if the software that broke is in Debian or not. In case it is, I should reassign the bug I guess. In case it is not I can add a NEWS.Debian to alert users upgrading. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677739: Acknowledgement (lua-sql-mysql: does not work)
On Sat, Jun 16, 2012 at 12:53:57PM -0400, Gedalya wrote: Well, I'm using 5.1, never upgraded to 5.2. I'm a little confused, if I'm using 5.1 and writing legitimate 5.1 code, then the case is that my code was broken by installing a new version of this extension - and presumably I did nothing wrong? I mean, the same luasql sourcecode works for 5.1 _and_ 5.2 The lua code is my own, not a debian package, is that what you meant to ask? OK, so I'm not breaking an existing Debian package. I'm gonna try once again with luasql = require 'luasql.mysql' and see if it indeed works, but the question remains, did I write good code that just broke for no reason. Actually assigning to a local variable the result of require is a good Lua practice. What was wrong was the behaviour of require that was assigning a global variable, a sort of unavoidable side effect that was escaping any form of sandboxing. Lua 5.2 fixed that. But you are right, the upgrate broke legitimate code, so this is a bug. How to deal with it is a bit unclear to me. If Tomas thinks luasql should be fixed, I'll try to upload an updated version of the package before the freeze (that will be really soon!). If the change was intended, I'll just add a note in NEWS.Debian. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675626: [pkg-lua-devel] Bug#675626: ITP: lutok -- Lightweight C++ API library for Lua
On Fri, Jun 15, 2012 at 01:34:36PM +0200, Luca Capello wrote: - based on my experience in previous teams (especially on the Debian Common Lisp one), having a single point of contact for questions related to all $LANGUAGE packages is really useful. Exactly. This software seems to be really tight to Lua, so It would be nice to have it close to it. For example when I change the lua5.1 package I also recompile all the lua packages in the svn repository just to be sure I did not break them. In case the policy for lua packages gets changed, or lua packages get renamed, you may also get a patch for free ;-) Unless you have serious concerns against an svn repository (that will eventually become a git one) I suggest you put your package there. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676437: lua-posix: FTBFS on hurd-i386.
On Wed, Jun 06, 2012 at 10:08:49PM +, Cyril Roelandt wrote:
Package: lua-posix
Severity: normal
Tags: patch
Dear Maintainer,
lua-posix currently fails to build on hurd-i386. The attached patch
fixes this issue. It also checks the return value of sysconf() on
non-GNU systems.
Many thanks for the patch!
+ int error = !!(b==NULL);
+ if (!error)
+ lua_pushstring(L, b);
+ return error ? pusherror(L, .) : 1;
Could you explain why your wrote the code like you did and not in the
following obvious way:
if (b != NULL) {
lua_pushstring(L, b);
return 1;
} else {
return pusherror(L, get_current_dir_name);
}
What is this abundance of !! for?
Why should the error message be .?
Cheers
--
Enrico Tassi
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674623: lua50: Possibility to remove the package from the archive
On Fri, May 25, 2012 at 11:37:06PM -0400, John Belmonte wrote: On Fri, May 25, 2012 at 9:28 PM, Guillem Jover guil...@debian.org wrote: There's currently only two packages Build-Depending on lua50, elinks and fillets-ng, for which I've filed bugs with patches to switch to Lua 5.1. I'll mark them as blocking this one. It's not necessarily in the software developer's control to upgrade the Lua version. The Lua library is used to extend and configure applications, and the language itself is incompatible between major versions. I don't know anything about the two packages you mentioned, but for example one could have thousands of users who wrote their own scripts for the application, and those scripts might break if Lua is upgraded. This is explained under Need to maintain old Lua releases in README.Debian of the Lua packages. Moreover the popcon is 18928, a bit high for a package to be removed. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673955: Please package version 7 (supports lua5.2)
Package: lua-iconv Version: 6-6 Severity: wishlist lua-iconv 7 was released, it seems to support lua5.2 too. Please update the package. If you need help with dh-lua, just ask. Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lua-iconv depends on: ii libc6 2.13-32 ii multiarch-support 2.13-32 Versions of packages lua-iconv recommends: ii lua5.1 5.1.5-2 lua-iconv suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672657: Not suitable for weezy
Package: luajit Version: 2.0.0~beta9+dfsg-2 Severity: grave Tags: upstream In accordance with the upstream, luajit will not be part of weezy, but rather be made available via backports. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages luajit depends on: ii libc6 2.13-32 ii libgcc1 1:4.7.0-8 ii libluajit-5.1-common 2.0.0~beta9+dfsg-2 ii multiarch-support 2.13-32 luajit recommends no packages. luajit suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672346: ITP: lua-penlight -- general purpose library for the Lua language
Package: wnpp Severity: wishlist Owner: Enrico Tassi gareuselesi...@debian.org * Package name: lua-penlight Version : 1.0.2 Upstream Author : Steve Donovan * URL : http://stevedonovan.github.com/Penlight/api/index.html * License : MIT Programming Lang: Lua Description : Collection of general purpose libraries for the Lua language A set of pure Lua libraries focusing on input data handling (such as reading configuration files), functional programming (such as map, reduce, placeholder expressions,etc), and OS path management. Much of the functionality is inspired by the Python standard libraries. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671455: RFA: cmph - C Minimal Perfect Hashing Library
Package: wnpp Severity: normal Description: Minimal perfect hash functions are widely used for memory efficient storage and fast retrieval of items from static sets, such as words in natural languages, reserved words in programming languages or interactive systems, universal resource locations (URLs) in Web search engines, or item sets in data mining techniques. I lost interest in this package. It was packaged as a dependency of lua-gtk, that is not in the archive anylonger. Popcon is low but not zero, so maybe there is still someone interested in maintaining cmph, and packaging a more recent version of it. The package is maintained here: svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/cmph Feel free to take care of it! Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671286: LUA_CPATH_DEFAULT broken when not building with debhelper
On Wed, May 02, 2012 at 08:23:14PM -0400, Evan Wies wrote: The DEB_HOST_MULTIARCH is only set during the Debian build process, or manually through the preprocessor. Since Lua packages are built with debhelper, they include a well-formed LUA_CPATH_DEFAULT. However, this change breaks the compilation of programs outside of debhelper which embed Lua and rely upon LUA_CPATH_DEFAULT: error: expected ')' before 'DEB_HOST_MULTIARCH' A workaround is to set DEB_HOST_MULTIARCH manually (using dpkg-architecture -qDEB_HOST_MULTIARCH), or construct ones own LUA_CPATH_DEFAULT. Since liblua5.1-0dev is architecture-specific, perhaps the build process could insert the architecture into luaconf.h rather than depend on a definition set in the package build process? This will make the package non multiarch capable, since there is no architecture triplet in the path for header files (yet) so all .h files must be architecture neutral. Something I can do it to fix .pc file so that pkg-config --cflags lua5.1 correctly spits out -DDEB_HOST_MULTIARCH=bla What do you think? -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670549: ITP: lua-ldap -- LDAP library for the Lua language
On Thu, Apr 26, 2012 at 06:26:01PM +0200, Luca Capello wrote: Package: wnpp * Package name: lua-ldap * URL or Web page : http://www.keplerproject.org/lualdap/ I Cc:ed Enrico Tassi (the maintainer of most Lua packages in Debian and also the author of dh-lua) and the upstream authors for their information. The package follows the Debian Lua policy: I'd suggest to put the package in the alioth svn repository pkg-lua. If you agree I'll add you to the team members. I had a plan to migrate all of that to git, so if you prefer the latter vcs I'm with you and you should use that. To get started, I think the package should be very very close to lua-zip, that you could use as a template. JFYI: all projects previously hosted on luaforge are now on github: https://github.com/luaforge/lualdap even if the are no tarballs for this project, just tags, that is fine too. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670549: ITP: lua-ldap -- LDAP library for the Lua language
On Thu, Apr 26, 2012 at 06:26:01PM +0200, Luca Capello wrote: * Package name: lua-ldap On another topic, thanks to lua-cyrussasl I think prosody is already able to use LDAP: http://prosody.im/doc/cyrus_sasl But I guess the module you mentioned is simpler/better. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668173: ITP: lua-dbi -- DBI library for the Lua language
Package: wnpp Severity: wishlist Owner: Enrico Tassi gareuselesi...@debian.org * Package name: lua-dbi Version : 0.5 Upstream Author :Neil Richardson (nr...@ii.net) * URL : http://code.google.com/p/luadbi/ * License : MIT/X Programming Lang: C Description : DBI library for the Lua language Lua DBI s a database interface library for Lua. It is designed to provide a RDBMS agnostic API for handling database operations. LuaDBI also provides support for prepared statement handles, placeholders and bind parameters for all database operations. . Lua DBI is a better alternative to lua-sql since it supports prepared statements. lua-dbi is a dependency of the prosody jabber server. unfortunately it is not a drop in replacement for lua-sql, that is still used by other libraries and thus cannot be removed from the archive. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668057: ITP: lua-zlib -- zlib library for the Lua language
Package: wnpp Severity: wishlist Owner: Enrico Tassi gareuselesi...@debian.org * Package name: lua-zlib Version : 0.2 Upstream Author : Brian Maher * URL : http://github.com/brimworks/lua-zlib * License : MIT/X Programming Lang: C Description : zlib library for the Lua language This is a recommended dependency of the Prosody jabber server -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579377: switch to lua-lgi
JFYI, I'm planning to switch to lua-lgi, that is a more modern and functional bridge between Lua and gobject based libraries. You are ancourgaed to try it out. It should work fine on powerpc and armel. Regards -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668072: RM: lua-gtk -- ROM; broken, superseeded by lua-lgi
Package: ftp.debian.org Severity: normal I request the source package lua-gtk (and thus its binary packages liblua5.1-gnome-0 and liblua5.1-gnome-dev) to be removed from unstable (and testing I guess). This software is nowadays outdated, RC buggy and superseeded by the more moder lua-lgi. Even the upstream of lua-gtk discontinued it in favour of lua-lgi. Regards -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667596: gtk_init gives bus error on mipsel
Package: libgtk-3-0
Version: 3.2.3-1
Severity: important
It seems gtk is completely broken on mipsel. lua-lgi FTBFS on mipsel, and
its author (Pavel Holejšovský) figured out that it is enough to call gtk_init
to get a bus error.
Interestingly enough all gtk packages are installed on eder, so maybe someone
is already debugging this. But I could not find an open bug report on the
subject.
$ ssh eder.debian.org
$ dchroot unstable
$ cat a.c
#include gtk/gtk.h
int main (int argc, char **argv)
{
gtk_init (argc, argv);
return 0;
}
$ gcc a.c -o gtktest `pkg-config --cflags --libs gtk+-3.0`
$ ulimit -c unlimited
$ xvfb-run ./gtktest
Bus error (core dumped)
$ gdb ./gtktest
...
bt
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/mipsel-linux-gnu/libthread_db.so.1.
Core was generated by `./gtktest'.
Program terminated with signal 10, Bus error.
#0 0x2bbe6cb0 in copy_classes (to=optimized out, from=optimized out,
nclasses=optimized out) at ../../src/XExtInt.c:1539
1539../../src/XExtInt.c: No such file or directory.
(gdb) bt
#0 0x2bbe6cb0 in copy_classes (to=optimized out, from=optimized out,
nclasses=optimized out) at ../../src/XExtInt.c:1539
#1 0x2bbe845c in XIQueryDevice (dpy=0xb71140, deviceid=optimized out,
ndevices_return=optimized out) at ../../src/XIQueryDevice.c:90
#2 0x2b1511c4 in gdk_x11_device_manager_xi2_constructed (
object=optimized out)
at
/build/buildd-gtk+3.0_3.2.3-1-mipsel-WwT23O/gtk+3.0-3.2.3/./gdk/x11/gdkdevicemanager-xi2.c:414
#3 0x2b62e048 in g_object_newv ()
from /usr/lib/mipsel-linux-gnu/libgobject-2.0.so.0
#4 0x2b62ef88 in g_object_new_valist ()
from /usr/lib/mipsel-linux-gnu/libgobject-2.0.so.0
#5 0x2b62f1dc in g_object_new ()
from /usr/lib/mipsel-linux-gnu/libgobject-2.0.so.0
#6 0x2b14ef10 in _gdk_x11_device_manager_new (display=0xb87800)
at
/build/buildd-gtk+3.0_3.2.3-1-mipsel-WwT23O/gtk+3.0-3.2.3/./gdk/x11/gdkdevicemanager-x11.c:66
#7 0x2b154a6c in _gdk_x11_display_open (display_name=optimized out)
at
/build/buildd-gtk+3.0_3.2.3-1-mipsel-WwT23O/gtk+3.0-3.2.3/./gdk/x11/gdkdisplay-x11.c:1226
#8 0x2b152764 in gdk_x11_display_manager_open_display (manager=0xb60930,
name=optimized out)
at
/build/buildd-gtk+3.0_3.2.3-1-mipsel-WwT23O/gtk+3.0-3.2.3/./gdk/x11/gdkdi---Type
return to continue, or q return to quit---
splaymanager-x11.c:55
#9 0x2adf4cc4 in gtk_init_check (argc=optimized out, argv=optimized out)
at
/build/buildd-gtk+3.0_3.2.3-1-mipsel-WwT23O/gtk+3.0-3.2.3/./gtk/gtkmain.c:1136
#10 0x2adf4cf8 in gtk_init (argc=optimized out, argv=optimized out)
at
/build/buildd-gtk+3.0_3.2.3-1-mipsel-WwT23O/gtk+3.0-3.2.3/./gtk/gtkmain.c:1188
#11 0x004009ac in main ()
cheers
--
Enrico Tassi
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659314: Is it still the case?
Your bug refers to a version that was in experimental and you are building this package from stable. The package really needs to be built using a multiarch aware toolchain. I could update the build dependencies but building a opackage from experimental on a stable machine is not supported anyway. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659263: syncmaildir: should be a bit more verbose
On Wed, Feb 22, 2012 at 06:04:21PM +0100, Luca Capello wrote: Thank you, what scared me the most was that there was no visible sign of activity. A simple computing the SHA1 of all the mails on remote host... would be fine ;-) Well, the user interface is not exactly nice, as you noted. Version 1.2.3 is on its way, and will include a more verbose reporting, that also writes something every 5K emails are processed. Ciao and happy synchronization -- Enrico Tassi signature.asc Description: Digital signature
Bug#659263: syncmaildir: should be a bit more verbose
On Thu, Feb 09, 2012 at 05:47:54PM +0100, Luca Capello wrote: Package: syncmaildir Version: 1.2.2-1 Severity: normal File: /usr/bin/smd-pull Usertags: pca.it-synchronization Hi there! Found lockfile of a dead instance. Ignored. Enter passphrase for key '/home/luca/.ssh/id_rsa': ^C real38m51.588s user0m2.164s sys 0m1.644s Is it the first synchronization? In that case the long time it takes is pretty normal (as per doc). If it is not the first run, then there is something wrong going on. In general it takes few seconds so writing something is not really needed. But yes, I'll put this on my todo list. It should be doable. What is going on actually? It is computing the sha1 sum of all the mails on the remote host. This may take some time, depending on the disk you have. And is needed only the first time... So I suggest you run the first sync at night, and forget about it. Ciao -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660251: ITP: dh-lua -- helper script for building Lua package
Package: wnpp Severity: wishlist Owner: Enrico Tassi gareuselesi...@debian.org * Package name: dh-lua Version : 1 Upstream Author : Enrico Tassi * URL : svn+ssh://svn.debian.org/svn/pkg-lua/packages/dh-lua * License : MIT/X Programming Lang: make, shell Description : helper script for building Lua package This is the successor of lua5.1-policy, it is based on dh instead of CDBS and is able to build packages that contain multiple versions of the same library (i.e. for lua50, lua5.1 and lua5.2). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657968: ITP: lua-lgi -- Lua binding to GObject based libraries
Package: wnpp Severity: wishlist Owner: Enrico Tassi gareuselesi...@debian.org * Package name: lua-lgi Version : 0.4 Upstream Author : Pavel Holejsovsky * URL : https://github.com/pavouk/lgi * License : MIT/X Programming Lang: C, Lua Description : Lua binding to GObject based libraries LGI is gobject-introspection based dynamic Lua binding to GObject based libraries. It allows using GObject-based libraries directly from Lua. It should be a good replacement for lua-gtk, whose development stalled and that supports only gtk2 on few architectures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
