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#824944: [jwollr...@web.de: Re: Update lua-discount]
-- Enrico Tassi --- Begin Message --- Am Thu, 30 Jun 2016 15:19:54 +0200 schrieb Enrico Tassi : > 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 > 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#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#796443: closing 796443
close 796443 thanks Closed with 2.2.0+dfsg-2 -- Enrico Tassi
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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-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 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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668670: closing 668670
close 668670 thanks -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636084: FTBFS with lua 5.1.4-10
On Fri, Sep 02, 2011 at 05:37:24PM +0200, Julien Danjou wrote: > On Sat, Jul 30 2011, Enrico Tassi wrote: > This is mainly a note to myself. :) > > I've tried the patch, there just one last thing that is not good: this > link is broken: > > lrwxrwxrwx 1 root root 22 Sep 2 17:26 > /usr/lib/x86_64-linux-gnu/lua/5.1/oopango.so -> ../../../liboopango.so I'm not an auto* expert, and in fact I hate that cruft. My guessing is that in Makefile.am when you do $(LN_S) the variable $(libdir) will expand to /usr/lib and not /usr/lib/x86_64-linux-gnu. If there is an auto* variable for the multiarch path, use it, otherwise you can append a $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) to it. But that is really Debian dependent, so you may want to redo the link in your debian/rules file. Have a nice auto* day. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573087: Is luajit unsuitable for testing/newstable (wheezy)?
On Sun, Aug 07, 2011 at 05:26:03AM +0300, Leonid Borisenko wrote: > Hi, > > Squeeze is already released and this Debian bug just prevents luajit > from entering into testing (wheezy). The upstream promptly agreed to let the package enter testing. Cheers and enjoy the jitter! -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573087: Is luajit unsuitable for testing/newstable (wheezy)?
On Sun, Aug 07, 2011 at 05:26:03AM +0300, Leonid Borisenko wrote: > Hi, > > So I'm curious when this release-critical bug of luajit package will > be resolved? When "-beta" suffix will be dropped by upstream or earlier? Well, the bug was opened because the upstream asked for it. Clearly having a -beta version frozen in a stable release is not desirable. Nevertheless, luajit is in a good state and I'm pretty sure the -beta will be removed before debian releases weezy. The best thing is to ask Mike, the author of luajit. I'm on VAC, I'll do it when I'll be back. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636359: closing 636359
close 636359 thanks Fixed in lua5.1 version 5.1.4-10 -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636359: lua5.1 version 5.1.4-10 will sove the problem
On Wed, Aug 03, 2011 at 03:25:46PM +0200, Bernd Zeimetz wrote: > On 08/03/2011 03:18 PM, Enrico Tassi wrote: > > As already pointed out, the problem is not prosody, but the version of > > the lua interpreter that is too old. Pick lua5.1 version 5.1.4-10 from > > unstable or wait 2 days (it will move to testing). > > If that is the case, then there is a dependency missing somewhere. Yes and now. The interpreter, for example, does not depend on liblua5.1-0 because it is statically linked against it but exports the relevant symbols to the libraries it loads. And even if a dependency over "lua5.1 | liblua5.1-0" is partially broken, because any package could do what lua5.1 does. Maybe a virtual package lua5.1-runtime or something, but these deps cannot be versioned. So in my opinion, lua libraries have not to depend on the interpreter. In this particular case, I installed the libraries in a path the interpreter in testing does not know. IMO it is really borderline, and the fault is just that I didn't wait the interpreter to move to testing before uploading the libs. For backporting, this may be an issue, but I've no good solution, even if I'm open to suggestions. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636359: lua5.1 version 5.1.4-10 will sove the problem
As already pointed out, the problem is not prosody, but the version of the lua interpreter that is too old. Pick lua5.1 version 5.1.4-10 from unstable or wait 2 days (it will move to testing). Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636060: I sould not write patches during debconf talks
Package: oocairo
Followup-For: Bug #636060
Even the second patch is wrong, because the lua5.1/oocairo.so symlink is
pointing nowhere. Nevertheless the package in the archive is wrong too
since the symlink points to liboocairo.so and not liboocairo.so.0.0.0
and this makes 'require "oocairo"' from the lua interpreter to fail if
the -dev package is not installed. The attached patch fixed all issues.
diff -Nru oocairo-1.3/debian/changelog oocairo-1.3/debian/changelog
--- oocairo-1.3/debian/changelog2011-07-01 19:58:22.0 +0200
+++ oocairo-1.3/debian/changelog2011-07-30 18:55:03.0 +0200
@@ -1,3 +1,13 @@
+oocairo (1.3-2.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Multi-Arch support
+ * Tight dependency of the -dev on the lib package
+ * oocairo.so symlink to the .so.0.0.0 file, and not the .so, so that the
+-dev package is not needed to require oocairo from the lua interpreter
+
+ -- Enrico Tassi Sat, 30 Jul 2011 18:54:23 +0200
+
oocairo (1.3-2.1) unstable; urgency=low
* Non-maintainer upload.
diff -Nru oocairo-1.3/debian/control oocairo-1.3/debian/control
--- oocairo-1.3/debian/control 2011-05-09 14:55:17.0 +0200
+++ oocairo-1.3/debian/control 2011-07-30 18:23:35.0 +0200
@@ -10,6 +10,8 @@
Package: liblua5.1-oocairo0
Architecture: any
+Multi-Arch: same
+Pre-Depends: multiarch-support
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: provides Lua with full access to the Cairo vector graphics API
Provides Lua with full access to the Cairo vector graphics API. It can be
@@ -20,7 +22,8 @@
Package: liblua5.1-oocairo-dev
Architecture: any
Section: libdevel
-Depends: ${misc:Depends}, liblua5.1-oocairo0
+Multi-Arch: same
+Depends: ${misc:Depends}, liblua5.1-oocairo0 (= ${binary:Version})
Description: Cairo vector graphics API for Lua - development files
Provides Lua with full access to the Cairo vector graphics API. It can be
used for drawing onto bitmap images and saving the resulting files in PNG
diff -Nru oocairo-1.3/debian/liblua5.1-oocairo0.install
oocairo-1.3/debian/liblua5.1-oocairo0.install
--- oocairo-1.3/debian/liblua5.1-oocairo0.install 2010-11-04
11:32:54.0 +0100
+++ oocairo-1.3/debian/liblua5.1-oocairo0.install 2011-07-30
18:15:09.0 +0200
@@ -1,4 +1,4 @@
-usr/lib/liboocairo.so.0.0.0
-usr/lib/liboocairo.so.0
-usr/lib/lua
-usr/share/man
\ No newline at end of file
+usr/lib/*/liboocairo.so.0.0.0
+usr/lib/*/liboocairo.so.0
+usr/lib/*/lua
+usr/share/man
diff -Nru oocairo-1.3/debian/liblua5.1-oocairo-dev.install
oocairo-1.3/debian/liblua5.1-oocairo-dev.install
--- oocairo-1.3/debian/liblua5.1-oocairo-dev.install2011-07-01
19:52:56.0 +0200
+++ oocairo-1.3/debian/liblua5.1-oocairo-dev.install2011-07-30
18:41:54.0 +0200
@@ -1,3 +1,3 @@
usr/include
usr/lib/pkgconfig
-usr/lib/liboocairo.so
+usr/lib/*/liboocairo.so
diff -Nru oocairo-1.3/debian/patches/debian-changes-1.3-2.2
oocairo-1.3/debian/patches/debian-changes-1.3-2.2
--- oocairo-1.3/debian/patches/debian-changes-1.3-2.2 1970-01-01
01:00:00.0 +0100
+++ oocairo-1.3/debian/patches/debian-changes-1.3-2.2 2011-07-30
18:55:10.0 +0200
@@ -0,0 +1,115 @@
+Description: Upstream changes introduced in version 1.3-2.2
+ This patch has been created by dpkg-source during the package build.
+ Here's the last changelog entry, hopefully it gives details on why
+ those changes were made:
+ .
+ oocairo (1.3-2.2) unstable; urgency=low
+ .
+ * Non-maintainer upload.
+ * Multi-Arch support
+ * Tight dependency of the -dev on the lib package
+ * oocairo.so symlink to the .so.0.0.0 file, and not the .so, so that the
+ -dev package is not needed to require oocairo from the lua interpreter
+ .
+ The person named in the Author field signed this changelog entry.
+Author: Enrico Tassi
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: ,
+Bug:
+Bug-Debian: http://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded:
+Reviewed-By:
+Last-Update:
+
+--- oocairo-1.3.orig/Makefile.am
oocairo-1.3/Makefile.am
+@@ -51,7 +51,7 @@ MOSTLYCLEANFILES = $(manpages)
+ install-exec-hook:
+ $(MKDIR_P) $(DESTDIR)$(lualibdir)
+ -rm -f $(DESTDIR)$(lualibdir)/oocairo.so
+- $(LN_S) $(libdir)/liboocairo.so $(DESTDIR)$(lualibdir)/oocairo.so
++ $(LN_S) ../../liboocairo.so.0.0.0 $(DESTDIR)$(lualibdir)/oocairo.so
+ uninstall-local:
+ -rm -f $(DESTDIR)$(lualibdir)/oocairo.so
+
diff -Nru oocairo-1.3/debian/rules oocairo-1.3/debian/rules
--- oocairo-1.3/debian/rules2010-11-04 11:32:54.0 +0100
+++ oocairo-1.3/debian/rules2011-07-30 18:40:46.0 +0200
@@ -15,3 +15,7 @@
override_dh_auto_configure:
autoreconf --install
Bug#636084: FTBFS with lua 5.1.4-10
Package: oopango
Severity: serious
Tags: patch
The package fails to build from source with the lua5.1.pc shipped in
lua5.1 version 5.1.4-10. This patch fixes that issue, makes the library
multi-arch compliant and removes the .la file from the -dev package.
diff -Nru oopango-1.0/debian/changelog oopango-1.0/debian/changelog
--- oopango-1.0/debian/changelog2011-05-09 14:23:09.0 +0200
+++ oopango-1.0/debian/changelog2011-07-30 19:11:48.0 +0200
@@ -1,3 +1,14 @@
+oopango (1.0-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Multi-Arch support
+ * lua5.1/oopango.so symlink to liboocairo.so.0.0.0 and not liboopango.so
+so that the -dev package is not required to run 'require "oopango"'
+from the lua interpreter
+ * kill .la file (Closes: #633243)
+
+ -- Enrico Tassi Sat, 30 Jul 2011 19:11:03 +0200
+
oopango (1.0-1) unstable; urgency=low
* Initial release (Closes: #595037)
diff -Nru oopango-1.0/debian/control oopango-1.0/debian/control
--- oopango-1.0/debian/control 2011-05-09 14:37:17.0 +0200
+++ oopango-1.0/debian/control 2011-07-30 18:48:15.0 +0200
@@ -12,6 +12,8 @@
Package: liblua5.1-oopango0
Architecture: any
+Multi-Arch: same
+Pre-Depends: multiarch-support
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: provides Lua with full access to the Pango text rendering API
Provides Lua with full access to the Pango text rendering API. It can be
@@ -20,6 +22,7 @@
Package: liblua5.1-oopango-dev
Architecture: any
+Multi-Arch: same
Section: libdevel
Depends: ${misc:Depends}, liblua5.1-oopango0 (= ${binary:Version})
Description: Pango API for Lua - development files
diff -Nru oopango-1.0/debian/liblua5.1-oopango0.install
oopango-1.0/debian/liblua5.1-oopango0.install
--- oopango-1.0/debian/liblua5.1-oopango0.install 2011-05-09
14:34:28.0 +0200
+++ oopango-1.0/debian/liblua5.1-oopango0.install 2011-07-30
18:47:39.0 +0200
@@ -1,3 +1,3 @@
-usr/lib/liboopango.so.0.0.0
-usr/lib/liboopango.so.0
-usr/lib/lua
+usr/lib/*/liboopango.so.0.0.0
+usr/lib/*/liboopango.so.0
+usr/lib/*/lua
diff -Nru oopango-1.0/debian/liblua5.1-oopango-dev.install
oopango-1.0/debian/liblua5.1-oopango-dev.install
--- oopango-1.0/debian/liblua5.1-oopango-dev.install2011-05-09
14:27:10.0 +0200
+++ oopango-1.0/debian/liblua5.1-oopango-dev.install2011-07-30
18:47:27.0 +0200
@@ -1,4 +1,3 @@
usr/include
usr/lib/pkgconfig
-usr/lib/liboopango.so
-usr/lib/liboopango.la
\ No newline at end of file
+usr/lib/*/liboopango.so
diff -Nru oopango-1.0/debian/patches/debian-changes-1.0-1.1
oopango-1.0/debian/patches/debian-changes-1.0-1.1
--- oopango-1.0/debian/patches/debian-changes-1.0-1.1 1970-01-01
01:00:00.0 +0100
+++ oopango-1.0/debian/patches/debian-changes-1.0-1.1 2011-07-30
19:11:52.0 +0200
@@ -0,0 +1,31 @@
+Description: Upstream changes introduced in version 1.0-1.1
+ This patch has been created by dpkg-source during the package build.
+ Here's the last changelog entry, hopefully it gives details on why
+ those changes were made:
+ .
+ oopango (1.0-1.1) unstable; urgency=low
+ .
+ * Non-maintainer upload.
+ * Multi-Arch support
+ * lua5.1/oopango.so symlink to liboocairo.so.0.0.0 and not liboopango.so
+ so that the -dev package is not required to run 'require "oopango"'
+ from the lua interpreter
+ * kill .la file (Closes: #633243)
+ .
+ The person named in the Author field signed this changelog entry.
+Author: Enrico Tassi
+Bug-Debian: http://bugs.debian.org/633243
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: ,
+Bug:
+Bug-Debian: http://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded:
+Reviewed-By:
+Last-Update:
+
diff -Nru oopango-1.0/debian/patches/series oopango-1.0/debian/patches/series
--- oopango-1.0/debian/patches/series 2011-05-09 14:30:49.0 +0200
+++ oopango-1.0/debian/patches/series 2011-07-30 18:42:32.0 +0200
@@ -1 +1,2 @@
debian-changes-1.0-1
+debian-changes-1.0-1.1
diff -Nru oopango-1.0/debian/rules oopango-1.0/debian/rules
--- oopango-1.0/debian/rules2010-11-04 11:32:54.0 +0100
+++ oopango-1.0/debian/rules2011-07-30 19:01:52.0 +0200
@@ -15,3 +15,7 @@
override_dh_auto_configure:
autoreconf --install
dh_auto_configure
+
+override_dh_install:
+ cp -a debian/tmp/usr/lib/*.so* debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/
+ dh_install
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_U
Bug#636060: Fix to the previous patch
Package: oocairo
Version: 1.3-2.1
Followup-For: Bug #636060
The previous patch does not fix the -dev package content.
Please consider the following one.
diff -Nru oocairo-1.3/debian/changelog oocairo-1.3/debian/changelog
--- oocairo-1.3/debian/changelog2011-07-01 19:58:22.0 +0200
+++ oocairo-1.3/debian/changelog2011-07-30 18:24:16.0 +0200
@@ -1,3 +1,11 @@
+oocairo (1.3-2.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Multi-Arch support
+ * Tight dependency of the -dev on the lib package
+
+ -- Enrico Tassi Sat, 30 Jul 2011 18:23:39 +0200
+
oocairo (1.3-2.1) unstable; urgency=low
* Non-maintainer upload.
diff -Nru oocairo-1.3/debian/control oocairo-1.3/debian/control
--- oocairo-1.3/debian/control 2011-05-09 14:55:17.0 +0200
+++ oocairo-1.3/debian/control 2011-07-30 18:23:35.0 +0200
@@ -10,6 +10,8 @@
Package: liblua5.1-oocairo0
Architecture: any
+Multi-Arch: same
+Pre-Depends: multiarch-support
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: provides Lua with full access to the Cairo vector graphics API
Provides Lua with full access to the Cairo vector graphics API. It can be
@@ -20,7 +22,8 @@
Package: liblua5.1-oocairo-dev
Architecture: any
Section: libdevel
-Depends: ${misc:Depends}, liblua5.1-oocairo0
+Multi-Arch: same
+Depends: ${misc:Depends}, liblua5.1-oocairo0 (= ${binary:Version})
Description: Cairo vector graphics API for Lua - development files
Provides Lua with full access to the Cairo vector graphics API. It can be
used for drawing onto bitmap images and saving the resulting files in PNG
diff -Nru oocairo-1.3/debian/liblua5.1-oocairo0.install
oocairo-1.3/debian/liblua5.1-oocairo0.install
--- oocairo-1.3/debian/liblua5.1-oocairo0.install 2010-11-04
11:32:54.0 +0100
+++ oocairo-1.3/debian/liblua5.1-oocairo0.install 2011-07-30
18:15:09.0 +0200
@@ -1,4 +1,4 @@
-usr/lib/liboocairo.so.0.0.0
-usr/lib/liboocairo.so.0
-usr/lib/lua
-usr/share/man
\ No newline at end of file
+usr/lib/*/liboocairo.so.0.0.0
+usr/lib/*/liboocairo.so.0
+usr/lib/*/lua
+usr/share/man
diff -Nru oocairo-1.3/debian/liblua5.1-oocairo-dev.install
oocairo-1.3/debian/liblua5.1-oocairo-dev.install
--- oocairo-1.3/debian/liblua5.1-oocairo-dev.install2011-07-01
19:52:56.0 +0200
+++ oocairo-1.3/debian/liblua5.1-oocairo-dev.install2011-07-30
18:41:54.0 +0200
@@ -1,3 +1,3 @@
usr/include
usr/lib/pkgconfig
-usr/lib/liboocairo.so
+usr/lib/*/liboocairo.so
diff -Nru oocairo-1.3/debian/patches/debian-changes-1.3-2.2
oocairo-1.3/debian/patches/debian-changes-1.3-2.2
diff -Nru oocairo-1.3/debian/rules oocairo-1.3/debian/rules
--- oocairo-1.3/debian/rules2010-11-04 11:32:54.0 +0100
+++ oocairo-1.3/debian/rules2011-07-30 18:40:46.0 +0200
@@ -15,3 +15,7 @@
override_dh_auto_configure:
autoreconf --install
dh_auto_configure
+
+override_dh_install:
+ cp -a debian/tmp/usr/lib/*.so* debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/
+ dh_install
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
Enrico Tassi
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636060: FTBFS with lua 5.1.4-10
Package: oocairo
Version: 1.3-2.1
Severity: serious
The lua5.1.pc file now suggests multi-arch aware paths, and the .install
file needs fixing. Patch attached.
Cheers
diff -Nru oocairo-1.3/debian/changelog oocairo-1.3/debian/changelog
--- oocairo-1.3/debian/changelog2011-07-01 19:58:22.0 +0200
+++ oocairo-1.3/debian/changelog2011-07-30 18:24:16.0 +0200
@@ -1,3 +1,11 @@
+oocairo (1.3-2.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Multi-Arch support
+ * Tight dependency of the -dev on the lib package
+
+ -- Enrico Tassi Sat, 30 Jul 2011 18:23:39 +0200
+
oocairo (1.3-2.1) unstable; urgency=low
* Non-maintainer upload.
diff -Nru oocairo-1.3/debian/control oocairo-1.3/debian/control
--- oocairo-1.3/debian/control 2011-05-09 14:55:17.0 +0200
+++ oocairo-1.3/debian/control 2011-07-30 18:23:35.0 +0200
@@ -10,6 +10,8 @@
Package: liblua5.1-oocairo0
Architecture: any
+Multi-Arch: same
+Pre-Depends: multiarch-support
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: provides Lua with full access to the Cairo vector graphics API
Provides Lua with full access to the Cairo vector graphics API. It can be
@@ -20,7 +22,8 @@
Package: liblua5.1-oocairo-dev
Architecture: any
Section: libdevel
-Depends: ${misc:Depends}, liblua5.1-oocairo0
+Multi-Arch: same
+Depends: ${misc:Depends}, liblua5.1-oocairo0 (= ${binary:Version})
Description: Cairo vector graphics API for Lua - development files
Provides Lua with full access to the Cairo vector graphics API. It can be
used for drawing onto bitmap images and saving the resulting files in PNG
diff -Nru oocairo-1.3/debian/liblua5.1-oocairo0.install
oocairo-1.3/debian/liblua5.1-oocairo0.install
--- oocairo-1.3/debian/liblua5.1-oocairo0.install 2010-11-04
11:32:54.0 +0100
+++ oocairo-1.3/debian/liblua5.1-oocairo0.install 2011-07-30
18:15:09.0 +0200
@@ -1,4 +1,4 @@
-usr/lib/liboocairo.so.0.0.0
-usr/lib/liboocairo.so.0
-usr/lib/lua
-usr/share/man
\ No newline at end of file
+usr/lib/*/liboocairo.so.0.0.0
+usr/lib/*/liboocairo.so.0
+usr/lib/*/lua
+usr/share/man
diff -Nru oocairo-1.3/debian/rules oocairo-1.3/debian/rules
--- oocairo-1.3/debian/rules2010-11-04 11:32:54.0 +0100
+++ oocairo-1.3/debian/rules2011-07-30 18:22:42.0 +0200
@@ -15,3 +15,7 @@
override_dh_auto_configure:
autoreconf --install
dh_auto_configure
+
+override_dh_install:
+ cp -a debian/tmp/usr/lib/*.so.*
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/
+ dh_install
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
Enrico Tassi
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#632859: random testsuite failures
On Wed, Jul 13, 2011 at 10:33:55AM +0200, Julian Taylor wrote: > > While I'll investigate more, I don't think the severity is appropriate. > > > the testsuite fails in a clean up to date unstable pbuilder environment. > attached a log with pbuilder --build I tried to reproduce the bug, but here it always works. I've a week old pbuilder image (I've a weak internet connection here). I'll try again at debconf (next week) with an up to date chroot, but that looks very weird and fishy. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#632859: random testsuite failures
On Wed, Jul 06, 2011 at 04:10:43PM +0200, Julian Taylor wrote: > Package: lua-svn > Version: 0.4.0-2 > Severity: serious > Justification: FTBS > > the testsuite fails sometimes when building the package. While I'll investigate more, I don't think the severity is appropriate. Moreover, do you run the tests inside the pbuilder environment (--login) or you run them in your real system? Maybe there is something broken there. I mean, FTBFS means it fails to build in a clean build environment, so please confirm the problem occurrs in the pbuilder chroot too. Cheers -- Enrico Tassi signature.asc Description: Digital signature
Bug#565073: closing 565073
close 565073 thanks -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#588418: giving up
Well, it's not the right place for a rant, but this software and it's build system are not exactly something I'd like to spend more time on. Good luck -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#588418: progress on this bug
> ta...@birba:~/work-area/BSP/atlas-3.8.3/debian$ cat libatlas-test.install > usr/lib/libatlas-test/x* no, this did not help. The binaries that used to be part of the -test package are not even compiled now. Still investigating. -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590463: Diff to fix this bug in testing
Hi Piotr, while I share with you the disappointment for a non properly announced freeze date, I want Debian to succeed in making a nice release. I gave a look to the diff, to see if it was possible to backport a minimal patch fixing this issue in squeeze. Unfortunately the diff from 0.11 and 0.12 is huge, and It's unclear to me how to trim it down. Could you help me in identifying the problem so that I can propose a reasonable patch for squeeze? Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#588418: progress on this bug
It seems that the package moved from the ancient dh_movefiles to the "new" dh_install helper. Nevertheless the old libatlas-test.files was dropped and no libatlas-test.install is provided. I'm currently trying to recompile the package with the following addition. ta...@birba:~/work-area/BSP/atlas-3.8.3/debian$ cat libatlas-test.install usr/lib/libatlas-test/x* What do you think? Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595327: FTBFS after libclutter-1.0 upgrade
On Fri, Sep 03, 2010 at 03:38:40PM +0100, Steven Chamberlain wrote: > Hi, > > On 03/09/10 14:06, Enrico Tassi wrote: > >I've attached the patch for the libclutter issue, please test it on arm. > > However, the libraries I built on armel don't seem to work, but this > is really a separate issue; please see attached. Maybe I ought to > create a separate bug item for that? Yes, I'll close this bug with the next upload (that won't be compiled on armel). So please, open a new bug about the armel port not working and I'll let the upstream know. Cheers. -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595327: FTBFS after libclutter-1.0 upgrade
On Fri, Sep 03, 2010 at 03:54:27AM +0100, Steven Chamberlain wrote:
> Source: lua-gtk
> Severity: serious
> Justification: FTBFS
>
> Hi,
>
> Unfortunately this package won't build any more on amd64. The same
> problem occurred when I was trying to compile on armel. I guess
> it's the same on i386 too.
I've attached the patch for the libclutter issue, please test it on arm.
Cheers.
--
Enrico Tassi
#! /bin/sh /usr/share/dpatch/dpatch-run
## clutter-1.0.dpatch by Enrico Tassi
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: No description.
@DPATCH@
diff -urNad '--exclude=CVS' '--exclude=.svn' '--exclude=.git' '--exclude=.arch'
'--exclude=.hg' '--exclude=_darcs' '--exclude=.bzr'
trunk~/src/clutter/override.c trunk/src/clutter/override.c
--- trunk~/src/clutter/override.c 2009-03-27 15:45:34.0 +0100
+++ trunk/src/clutter/override.c2010-09-03 14:51:28.0 +0200
@@ -2,7 +2,7 @@
* Lua/Gnome binding: overrides for Clutter functions.
*/
-#include
+#include
#include "module.h"
#include "override.h"
#include // strchr, strlen
diff -urNad '--exclude=CVS' '--exclude=.svn' '--exclude=.git' '--exclude=.arch'
'--exclude=.hg' '--exclude=_darcs' '--exclude=.bzr' trunk~/src/clutter/spec.lua
trunk/src/clutter/spec.lua
--- trunk~/src/clutter/spec.lua 2009-12-23 11:02:24.0 +0100
+++ trunk/src/clutter/spec.lua 2010-09-03 14:51:08.0 +0200
@@ -13,9 +13,8 @@
includes = {}
includes.all = {
-"",
-"",
-"",
+"",
+"",
--"", -- optional
--"",-- optional
--"", -- optional
Bug#573640: liblua5.1-gtk-0: library is not loadable
severity 573640 important thanks On Sat, Mar 13, 2010 at 05:23:24AM +0100, Martin wrote: > Package: liblua5.1-gtk-0 > Version: 0.8+20080510+dash-1 > Severity: grave > Justification: renders package unusable > > When I run the loadlib.lua program I get error as indicated > below. > Shouldn't this package depend on liblua5.1 and some of gtk package? It should depend over gtk libraries, and in fact newer versions do. http://packages.debian.org/squeeze/liblua5.1-gnome-0 Nevertheless, the package is not unusable if you install those libraries, thus I lower the priority. As a documentation for this bug, I add to the bugreport the list of packages you should install to workaround the issue (note that you really need the -dev version of these packages due to another issue of lua-gtk, again solved in newer versions) apt-get install libgtk2.0-dev libgtkhtml2-dev Thanks for bug reporting. -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573087: unsuitable for squeeze
Package: luajit Version: 2.0.0~beta2+dfsg2-3 Severity: serious Luajit is still in beta stage, and thus, according with the upstream, unsuitable to be released with Debian squeeze. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.33-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages luajit depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.3-3 GCC support library ii libluajit-5.1-common 2.0.0~beta3+dfsg-2 Just in time compiler for Lua - co luajit recommends no packages. luajit suggests no packages. -- no debconf information -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561131: require 'csnd' fails, missing extern "C"
Package: liblua5.1-csnd Version: 1:5.11.1~dfsg-2 Severity: grave ta...@birba:/tmp$ lua Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio > require 'csnd' error loading module 'csnd' from file '/usr/lib/lua/5.1/csnd.so': /usr/lib/lua/5.1/csnd.so: undefined symbol: luaopen_csnd stack traceback: [C]: ? [C]: in function 'require' stdin:1: in main chunk [C]: ? > If we look at objdump: ta...@birba:/tmp$ objdump -T /usr/lib/lua/5.1/csnd.so | grep luaopen 00017880 gDF .text 00b7 Base _Z20luaopen_luaCsnd_userP9lua_State 002a0a60 gDO .data 0008 Base luaopen_luaCsnd_luacode 00019560 gDF .text 0dc4 Baseluaopen_luaCsnd It seems some extern "C" directives are missing, since symbols names are mangled according to C++ conventions, while Lua expects the entrypoint to be called luaopen_csnd. Cheers -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages liblua5.1-csnd depends on: ii libc62.10.2-2GNU C Library: Shared libraries ii libcsnd5.2 1:5.11.1~dfsg-2 C++ bindings for the Csound API ii libcsound64-5.2 1:5.11.1~dfsg-2 main library for Csound ii libgcc1 1:4.4.2-5 GCC support library ii liblua5.1-0 5.1.4-6 Simple, extensible, embeddable pro ii libstdc++6 4.4.2-5 The GNU Standard C++ Library v3 liblua5.1-csnd recommends no packages. liblua5.1-csnd suggests no packages. -- no debconf information -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548048: dvipsk-ja: diff for NMU version 5.96+jp1.7a-3.1
Dear maintainer,
I've prepared an NMU for dvipsk-ja (versioned as 5.96+jp1.7a-3.1) and
uploaded it to DELAYED/2 accoording to developer reference 5.11.1, since
the bug is RC and older than 7 days.
The upload simply adds the patch already attached to the bugreport, that
renaming getline to get_line avoids the name clash with the getline
function defined in stdio.h.
Regards.
--
Enrico Tassi
diff -u dvipsk-ja-5.96+jp1.7a/config.guess dvipsk-ja-5.96+jp1.7a/config.guess
--- dvipsk-ja-5.96+jp1.7a/config.guess
+++ dvipsk-ja-5.96+jp1.7a/config.guess
@@ -1,10 +1,10 @@
#! /bin/sh
# Attempt to guess a canonical system name.
# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-# 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation,
-# Inc.
+# 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
+# Free Software Foundation, Inc.
-timestamp='2007-07-22'
+timestamp='2009-06-10'
# This file is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
@@ -56,8 +56,8 @@
GNU config.guess ($timestamp)
Originally written by Per Bothner.
-Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
-Free Software Foundation, Inc.
+Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
+2002, 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
@@ -170,7 +170,7 @@
arm*|i386|m68k|ns32k|sh3*|sparc|vax)
eval $set_cc_for_build
if echo __ELF__ | $CC_FOR_BUILD -E - 2>/dev/null \
- | grep __ELF__ >/dev/null
+ | grep -q __ELF__
then
# Once all utilities can be ECOFF (netbsdecoff) or a.out (netbsdaout).
# Return netbsd for either. FIX?
@@ -324,6 +324,9 @@
case `/usr/bin/uname -p` in
sparc) echo sparc-icl-nx7; exit ;;
esac ;;
+s390x:SunOS:*:*)
+ echo ${UNAME_MACHINE}-ibm-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+ exit ;;
sun4H:SunOS:5.*:*)
echo sparc-hal-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
exit ;;
@@ -331,7 +334,20 @@
echo sparc-sun-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
exit ;;
i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*)
- echo i386-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+ eval $set_cc_for_build
+ SUN_ARCH="i386"
+ # If there is a compiler, see if it is configured for 64-bit objects.
+ # Note that the Sun cc does not turn __LP64__ into 1 like gcc does.
+ # This test works for both compilers.
+ if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then
+ if (echo '#ifdef __amd64'; echo IS_64BIT_ARCH; echo '#endif') | \
+ (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \
+ grep IS_64BIT_ARCH >/dev/null
+ then
+ SUN_ARCH="x86_64"
+ fi
+ fi
+ echo ${SUN_ARCH}-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
exit ;;
sun4*:SunOS:6*:*)
# According to config.sub, this is the proper way to canonicalize
@@ -532,7 +548,7 @@
echo rs6000-ibm-aix3.2
fi
exit ;;
-*:AIX:*:[45])
+*:AIX:*:[456])
IBM_CPU_ID=`/usr/sbin/lsdev -C -c processor -S available | sed 1q | awk '{ print $1 }'`
if /usr/sbin/lsattr -El ${IBM_CPU_ID} | grep ' POWER' >/dev/null 2>&1; then
IBM_ARCH=rs6000
@@ -640,7 +656,7 @@
# => hppa64-hp-hpux11.23
if echo __LP64__ | (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) |
- grep __LP64__ >/dev/null
+ grep -q __LP64__
then
HP_ARCH="hppa2.0w"
else
@@ -796,13 +812,19 @@
x86)
echo i586-pc-interix${UNAME_RELEASE}
exit ;;
- EM64T | authenticamd)
+ EM64T | authenticamd | genuineintel)
echo x86_64-unknown-interix${UNAME_RELEASE}
exit ;;
+ IA64)
+ echo ia64-unknown-interix${UNAME_RELEASE}
+ exit ;;
esac ;;
[345]86:Windows_95:* | [345]86:Windows_98:* | [345]86:Windows_NT:*)
echo i${UNAME_MACHINE}-pc-mks
exit ;;
+8664:Windows_NT:*)
+ echo x86_64-pc-mks
+ exit ;;
i*:Windows_NT*:* | Pentium*:Windows_NT*:*)
# How do we know it's Interix rather than the generic POSIX subsystem?
# It also conflicts with pre-2.0 versions of AT&T UWIN. Should we
@@ -833,7 +855,14 @@
echo ${UNAME_MACHINE}-pc-minix
exit ;;
arm*:Linux:*:*)
- echo ${UNAME_MACHINE}-unknown-linux-gnu
+ eval $set_cc_for_build
+ if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2>/dev/null \
+ | grep -q __ARM_EABI__
+ then
+ echo ${UNAME_MACHINE}-unknown-linux-gnu
+ else
+ echo ${UNAME_MACHINE}-unknown-linux-gnueabi
+ fi
exit ;;
avr32*:Linux:*:*)
echo ${UNAME_MACHINE}-unknown-linux-gnu
@@ -856,40 +885,17 @@
m68*:Linux:*:*)
echo ${UNAME_MACHINE}-unknown-linux-gnu
exit ;;
-mips:Linux
Bug#531971: liblua5.1-wsapi1: doesn't load due to missing module 'lfs'
On Fri, Jun 05, 2009 at 06:19:50AM -0500, Drake Wilson wrote: > Package: liblua5.1-wsapi1 > Version: 1.1.0-3 > Severity: grave > Justification: renders package unusable > > Based on the information in > /usr/share/doc/liblua5.1-wsapi-doc/doc/us/manual.html, I infer that a > Lua process should, from startup, be able to require 'wsapi.fastcgi'. > However, this doesn't seem to work: > > Reporting against liblua5.1-wsapi1 since the requirement for lfs seems > to be from wsapi/common.lua. Severity grave because the probability > that this bug is system-specific seems rather low. apt-cache search > doesn't report anything obvious in the Debian archive that looks like > a Lua library that would provide 'lfs'. The package misses a dependency over liblua5.1-filesystem0 Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#507408: liblua5.1-posix-dev: fails to build from source
On Sun, Nov 30, 2008 at 06:06:46PM -0500, Norman Ramsey wrote:
> ** lua dynamic **
> HOME=/home/nr/net/lua-posix-5.1.4/debian lua5.1 -l posix test.lua
> posix library for Lua 5.1 / Nov 2003
For some reasons the test loads an old version of posix.so that does not
support un-setenv (aka setenv("name",nil)).
On my system, the version is `posix library for Lua 5.1 / Jan 2008`.
Did you have a custom LUA_INIT variable set? in that case could you
plase unset it before attempting the build process. If it is the case I
should run my tests prefixing them with `LUA_INIT=`, but I need a
confirmation that the bug is this one.
Moreover, I tested a build on my almost clean environment and it worked...
Cheers
--
Enrico Tassi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501486: [Linux-wlan-ng-devel] Bug#501486: kernel version in testing is 2.6.26(+16) while linux-wlan-ng-source only supports < 2.6.24.x
tags 501486 +moreinfo stop On Tue, Oct 07, 2008 at 08:37:45PM +0200, folkert wrote: > Package: linux-wlan-ng-source > Version: 0.2.9+dfsg-2 > Severity: grave > Justification: renders package unusable > > > During compilation (via module-assistant) the message comes up that the > package only supports 2.6.24.x and older. Compilation then fails. > Kernel-version in testing is 2.6.26(+16). Are you sure you are using version 0.2.9+dfsg-2? I just successfully run m-a a-i linux-wlan-ng on my sid box, and revision -2 added a specific patch to fix build against 2.6.26. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489081: lua-curl FTBFS?
On Sun, Sep 07, 2008 at 03:33:41PM +0200, Marc 'HE' Brockschmidt wrote: > Enrico Tassi <[EMAIL PROTECTED]> writes: > > On Sat, Sep 06, 2008 at 09:49:17PM +0200, Marc 'HE' Brockschmidt wrote: > >> I can't reproduce the FTBFS (in pbuilder) on i386 reported for lua-curl > >> in #489081 right now. The bug was closed with a lua-svn upload, which > > IIRC I closed the bug with a wrong upload, but I've also solved the bug > > with an upload of the lua-curl package. > > I don't believe that. lua-curl 0.2.1-3 (the most recent version) was Sorry, I read the bts entry after sending that email. The bug has been closed by mistake, but the bug has been transient, due to a bug in libcurl. I should have reopened the bug after closing it by mistake and then close it again with a meaningful message. Anyway, the bug is not there anymore, even if the package has not been rebuilt. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489081: lua-curl FTBFS?
On Sat, Sep 06, 2008 at 09:49:17PM +0200, Marc 'HE' Brockschmidt wrote: > Heya, > > I can't reproduce the FTBFS (in pbuilder) on i386 reported for lua-curl > in #489081 right now. The bug was closed with a lua-svn upload, which > seems, eh, wrong. Lucas, are you still seeing this problem? If not, I > would suggest to just close this bug. Now that I remember, the bug was transient I think, due to a broken version of libcurl. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489081: lua-curl FTBFS?
On Sat, Sep 06, 2008 at 09:49:17PM +0200, Marc 'HE' Brockschmidt wrote: > Heya, > > I can't reproduce the FTBFS (in pbuilder) on i386 reported for lua-curl > in #489081 right now. The bug was closed with a lua-svn upload, which IIRC I closed the bug with a wrong upload, but I've also solved the bug with an upload of the lua-curl package. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475964: [liblua5.1-coxpcall0, xavante] xavante 2.0 will depend on coxpcall
Thanks for the report, and sorry for the mistake. Xavante 2.0 (upcoming) will depend on lua-coxpcall, that now is a separate module. I'll apload a new xavante package fixing the issue as soon as 2.0 is released (that should be very soon...). Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471317: No networks and other issues
Package: network-manager Version: 0.6.5-5 --- Please enter the report below this line. --- I'm experiencing the same problem. In addition to that, also wired network does not work, It seems the link change event is not detected. If I start NM with the ethernet cable in, it tries to set up the network but loops forver. this is the last part of NM output when I start it with the eth cable in. NetworkManager: Activation (eth1) Stage 2 of 5 (Device Configure) complete. NetworkManager: Activation (eth1) Stage 3 of 5 (IP Configure Start) started... process 17197: arguments to dbus_message_get_args() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-message.c line 1667. This is normally a bug in some application using the D-Bus library. NetworkManager: Error getting killswitch power arguments: - NetworkManager: Wireless now enabled by radio killswitch Note that the next to last list sometimes prints a random utf8 character after '-', suggesting a memory corruption... With NM in that state, nm-tool prints: NetworkManager Tool get_nm_state(): didn't get a reply from NetworkManager. NetworkManager appears not to be running (could not get its state). The same happens even if there is no eth cable in (NM in that case does nothing, and the gnome interface shows no detected neworks). I've tried downgrading to glib 2.16-1 (from -2) and now it works!! (the .diff is still available since some buildds are very slow...) --- System information. --- Architecture: amd64 Kernel: Linux 2.6.24-1-amd64 Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.it.debian.org --- Package information. --- Depends (Version) | Installed ===-+-=== adduser | 3.106 dbus (>= 0.60) | 1.1.20-1 dhcdbd (>= 1.12-2) | 3.0-2 hal(>= 0.5.7.1) | 0.5.10+git20080301-1 ifupdown| 0.6.8 iproute | 20080108-1 iputils-arping | 3:20071127-1 libc6(>= 2.7-1) | 2.7-9 libdbus-1-3 (>= 1.1.1) | 1.1.20-1 libdbus-glib-1-2 (>= 0.74) | 0.74-1 libgcrypt11 (>= 1.4.0) | 1.4.0-3 libglib2.0-0(>= 2.14.0) | 2.16.1-2 libgpg-error0 (>= 1.4) | 1.4-2 libhal1 (>= 0.5.10) | 0.5.10+git20080301-1 libiw29 (>= 28+29pre7) | 29-1 libnl1 | 1.1-2 libnm-util0 | 0.6.5-5 lsb-base (>= 3.0-6) | 3.2-4 wpasupplicant(>= 0.4.8) | 0.6.3-1 -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#467422: tries to overwrite file owned by liblua5.1-posix-dev
On Mon, Feb 25, 2008 at 11:04:52AM +0100, Stefano Zacchiroli wrote: > Package: liblua5.1-posix1 > Version: 5.1.2-2 > Severity: serious > > During today's upgrade of unstable: > > dpkg: dependency problems prevent configuration of liblua5.1-posix-dev: >liblua5.1-posix-dev depends on liblua5.1-posix1 (= 5.1.2-2); however: > Package liblua5.1-posix1 is not installed. > dpkg: error processing liblua5.1-posix-dev (--configure): >dependency problems - leaving unconfigured Sorry, Conflicts/Replaces are missing for liblua5.1-posix0 > > PS for the maintainer and the Italian cabal: e non so nemmeno perché ho > installato 'sto cavolo di pacchetto :-) Che bagaglio Beh, se lo tieni installato mica mi arrabbio, e soprattutto mi aiuti a trovare i bug! > Cheers -- Enrico Tassi
Bug#461377: lua-zip: FTBFS (bus error) in testsuite on ia64/sparc
On Fri, Jan 18, 2008 at 08:29:44AM +0100, Philipp Kern wrote: > Package: lua-zip > Version: 1.2.3-4 > Severity: serious > > Your package fails to build from source due to some problem in the > testsuite on ia64 and on sparc (the latter being not so important because it > never succeeded there), with the same log output: > make[2]: *** [test-lua-dynamic-real] Bus error The bug is in the library zzip library, see 443880 Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459754: missing libt1x on amd64
Package: libt1-5 Version: 5.1.1-1.1 Severity: grave --- Please enter the report below this line. --- dpkg -c libt1-5_5.1.1-2_amd64.deb | grep /usr/lib drwxr-xr-x root/root 0 2007-12-21 23:52 ./usr/lib/ -rw-r--r-- root/root 16880 2007-12-21 23:52 ./usr/lib/libt1x.so.5.1.1 -rw-r--r-- root/root280320 2007-12-21 23:52 ./usr/lib/libt1.so.5.1.1 lrwxrwxrwx root/root 0 2007-12-21 23:52 ./usr/lib/libt1x.so.5 -> libt1x.so.5.1.1 lrwxrwxrwx root/root 0 2007-12-21 23:52 ./usr/lib/libt1.so.5 -> libt1.so.5.1.1 dpkg -c libt1-5_5.1.1-2_amd64.deb | grep /usr/lib drwxr-xr-x root/root 0 2008-01-06 22:04 ./usr/lib/ -rw-r--r-- root/root280768 2008-01-06 22:04 ./usr/lib/libt1.so.5.1.1 lrwxrwxrwx root/root 0 2008-01-06 22:04 ./usr/lib/libt1.so.5 -> libt1.so.5.1.1 Note that the list of files on package.d.o is wrong, and reports the missing file is still there, but it is not. Cheers --- System information. --- Architecture: amd64 Kernel: Linux 2.6.23-1-amd64 Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.it.debian.org 500 testing security.debian.org --- Package information. --- Depends (Version) | Installed =-+-= libc6(>= 2.6.1-1) | 2.7-5 libice6 (>= 1:1.0.0) | 2:1.0.4-1 libsm6| 2:1.0.3-1+b1 libx11-6 | 2:1.0.3-7 libxext6 | 1:1.0.3-2 libxpm4 | 1:3.5.7-1 -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457984: Many tests are failed
Package: lua-bit Version: 24-2 Severity: grave --- Please enter the report below this line. --- Since the testing engine is broken, may tests ahve failed but the building process has not failed. This package is unsuitable for testing --- System information. --- Architecture: amd64 Kernel: Linux 2.6.22-3-amd64 Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.it.debian.org 500 testing security.debian.org 1 experimentalftp.it.debian.org --- Package information. --- Depends (Version) | Installed ===-+-=== | -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457786: returns 0 even on failures
Package: shake Version: 1.0.1-1 Severity: grave --- Please enter the report below this line. --- This bts entry is a reminder to not let shake and consequently any other lua packages using it to migrate to testing until this bad behaviour is fixed. Since the always return 0 all tests seem to have sucess, that is clearly not what you want. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.22-3-amd64 Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.it.debian.org 500 testing security.debian.org 1 experimentalftp.it.debian.org --- Package information. --- Depends(Version) | Installed -+-=== liblua5.1-filesystem0| 1.3.0-1 liblua5.1-leg0 | 0.1.2-2 -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#452104: Pleare rebuild against liblablgtk2-ocaml 2.10.0-2
Package: lablgtkmathview Severity: grave --- Please enter the report below this line. --- This is a mostly a reminder: please, rebuild the package against the new version of gtk2 bindings. and /usr/lib/ocaml/3.10.0/lablgtkmathview/gMathViewAux.cmi make inconsistent assumptions over interface Gtk cheers. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.22-1-amd64 Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.it.debian.org 500 testing security.debian.org --- Package information. --- Depends (Version) | Installed ===-+-=== | -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443880: fixed in zziplib 0.13.49-3
reopen 443880 thanks It seems the patch did not work as expected, since the test still fails: http://buildd.debian.org/fetch.cgi?pkg=lua-zip;ver=1.2.3-4;arch=ia64;stamp=1195299518 I'll try to test again the code snippet later, since the chroots I've tried are not up to date and still provide 0.13.49-2 Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442026: FTBFS on archs without the native-compilers
Package: liblablgtksourceview-ocaml-dev Version: 0.2.1-2 Severity: grave --- Please enter the report below this line. --- The .install.in file reports: debian/tmp/lablgtksourceview/*.cma usr/lib/ocaml/@OCamlABI@/lablgtksourceview/ debian/tmp/lablgtksourceview/*.cmi usr/lib/ocaml/@OCamlABI@/lablgtksourceview/ debian/tmp/lablgtksourceview/*.cmxa usr/lib/ocaml/@OCamlABI@/lablgtksourceview/ That is wrong on archs without the native compiler. I suggest a single line like the one that follows: debian/tmp/lablgtksourceview/*.cm* usr/lib/ocaml/@OCamlABI@/lablgtksourceview/ that is less constraining but works for both native and non native builds. Cheers --- System information. --- Architecture: amd64 Kernel: Linux 2.6.22-1-amd64 Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.it.debian.org 500 testing security.debian.org --- Package information. --- Depends (Version) | Installed ===-+-= ocaml-nox-3.09.2| ocaml-findlib | 1.1.2pl1-1 liblablgtksourceview-ocaml (= 0.2.1-2) | 0.2.1-2 liblablgtk2-ocaml-dev (>= 2.6.0-2) | 2.6.0-7 libgtksourceview-dev (>= 1.2.0) | 1.8.5-1 -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439868: BinNMUs request for libzzip-0-{12,13} transition
On Tue, Aug 28, 2007 at 05:43:28AM +0200, Cyril Brulebois wrote: > lua-zip_1.2.3-2, 1, Rebuild against libzzip-0-13, alpha amd64 arm hppa > i386 ia64 mips mipsel powerpc s390 sparc lua-zip_1.2.3-2 build-depends over libzzip-dev (>= 0.13.49-2) and is already uploaded to unistable (but not built yet on many arches): 1.2.3-2: alpha amd64 arm i386 s390 1.2.3-1: armel hppa ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc Cheers. -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430272: False positive
After some testing on bruckner and raptor it really seems that there is no need to tweak the LUAI_USER_ALIGNMENT_T macro, so I'm closing this bug as a false positive. -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430272: Maybe a false positive
On Mon, Jun 25, 2007 at 08:03:26PM -0400, John Belmonte wrote: > Lua does not use long double. I think LUAI_USER_ALIGNMENT_T affects > memory allocated for userdata (i.e. alignment of pointer returned by > lua_newuserdata). If userdata is going to be a struct which includes a > long double, updating the macro may be significant. sure > We know this bug is a false positive and can be closed. The question > raised is what happens when some Linux distributions start "fixing" that > macro-- does it affect binary compatibility of the Lua core library or > compiled Lua code? Hopefully not, but we'd have to check with the code > or Lua authors to confirm. sure, I will prepare a mail for the mailing list as soon as the following point is clear to me. > Regarding your #2, a complex test of architecture and glibc version is > not necessary. It's enough to always put long double in the struct if > the compiler supports the type. Since gcc does, and the Lua "linux" > target uses gcc, I propose that it be enabled for that target. But I > want it to happen upstream so there is consistency between distros. Right, but what still needs to be dig is *if* the architectures for which libc 2.5 increases the size of long doubles do need long double alignement. I did an exam about architectures and assembly many years ago, but IIRC it really depends if these archs have a one shot instruction that fetches 128 bit at once or not in combination with their bus. If a long double fetch is compiled into two 64 bit fetches, you really need to be aligned only on doubles. If you are allowed to fetch 128 bit at once and the bus needs them to be aligned, LUAI_USER_ALIGNMENT_T needs some tweaking. So, I was hoping in a reply by the bugreporter saying if these arch need 128 bit alignement or not. Cheers. -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430272: Maybe a false positive
On Sun, Jun 24, 2007 at 12:25:06PM -0400, John Belmonte wrote:
> Enrico Tassi wrote:
> > There is not API using long double, but there is some interesting
> > message in the header file (the configuration one).
> >
> > You probably know more than me about alignment in these archs...
> >
> > /*
> > @@ LUAI_USER_ALIGNMENT_T is a type that requires maximum alignment.
> > ** CHANGE it if your system requires alignments larger than double. (For
> > ** instance, if your system supports long doubles and they must be
> > ** aligned in 16-byte boundaries, then you should add long double in the
> > ** union.) Probably you do not need to change this.
> > */
> > #define LUAI_USER_ALIGNMENT_T union { double u; void *s; long l; }
>
> I don't think the macro should be changed because it will create a
> binary incompatibility on those archs.
>
> It seems like upstream should control use of long double in this struct
> with a define, and set it for the linux build target. Without this
> standardization there will be a binary compatibility confusion mess in
> the future.
What is not clear to me is:
1) Do plain lua (with no LUA_NUMBER redefinition) use long double?
For sure not in the interface, didn't check the internals but I guess
no.
2) Do these archs need long double (128 bit) to be "aligned"?
If they need alignement of 16 bytes, and lua uses long doubles, then
I'll ping the upstreams for such a macro to be active if the specific
arch and glibc version is met.
In any case, since there are no long double in the lua C interface,
there should be no ABI change and no package rename. If both the
previous points are met, the problem is that lua may crash due to a bus
error, and in this case we should work with the upstreams.
Am I wrong?
Cheers.
--
Enrico Tassi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430272: Maybe a false positive
Package: liblua5.1-0-dev
Version: 5.1.2-1
--- Please enter the report below this line. ---
There is not API using long double, but there is some interesting
message in the header file (the configuration one).
You probably know more than me about alignment in these archs...
/*
@@ LUAI_USER_ALIGNMENT_T is a type that requires maximum alignment.
** CHANGE it if your system requires alignments larger than double. (For
** instance, if your system supports long doubles and they must be
** aligned in 16-byte boundaries, then you should add long double in the
** union.) Probably you do not need to change this.
*/
#define LUAI_USER_ALIGNMENT_T union { double u; void *s; long l; }
Cheers
--- System information. ---
Architecture: amd64
Kernel: Linux 2.6.21.1-mactel
Debian Release: lenny/sid
500 unstablewww.debian-multimedia.org
500 unstableftp.it.debian.org
500 testing security.debian.org
--- Package information. ---
Depends(Version) | Installed
-+-
liblua5.1-0 (= 5.1.2-1) | 5.1.2-1
libc6-dev| 2.5-11
OR libc-dev |
libreadline5-dev | 5.2-3
--
Enrico Tassi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409448: lua-posix: FTBFS: unmet build dep lua5.1-policy-dev(inst 6 ! >= wanted 7)
On Sat, Feb 03, 2007 at 11:48:10AM +0100, Lucas Nussbaum wrote: > Package: lua-posix > Version: 1.0-4 > Severity: serious > Usertags: grid5000 rebuild > > After installing, the following source dependencies are still > unsatisfied: > lua5.1-policy-dev(inst 6 ! >= wanted 7) > Source-dependencies not satisfied; skipping lua-posix I know that, and I've already pointed this out here: http://lists.debian.org/debian-release/2007/01/msg01287.html I can t-p-u the previous version (the one that was in testing and compiles against policy version 6) that divvers essentially in 3 lines: the build dependency and a one line patch for the test file. I'm waiting news from the RM team. Cheers. -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406782: tag
tags 406782 +sid stop -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406782: reopen
tags +sid stop -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406782: reopen
reopen 406782 tag +sid stop The bug is fixed in version 0.2.7+dfsg-1 erroneously uploaded for experimental. Will be re-uploaded to unstable ASAP. -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367790: This bug is probably important and not critical
severity 367790 important stop This bug fits better as important, since it is a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. Moreover some fixes upstream will never reach testing users, that I supposed will be happier with an updated version of the driver (and I'm sure the version in testing has already this bug). I'll mention explicitly this bug in the documentation, warning about using monitor mode and kismet (using the root account). regards -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367790: linux-wlan-ng-source: Setting USB adapter to monitor mode triggers memory leak in kernel
On Sun, Jun 11, 2006 at 11:50:56AM +0200, Christian Aichinger wrote: > On Sat, Jun 10, 2006 at 08:54:13PM +0200, Christian Aichinger wrote: > > I think I've found a leak in the -usb monitor code. If I get this > > right it leaks a few bytes on every received packet, since it copies > > the device name, but doesn't free the string again. > > Urgh, scratch that. It doesn't work, and afaics it doesn't even leak > memory. > > I should have probably slept more before looking into this ;). I'll > take a look again later today or tomorrow. > > Sorry, > Christian Aichinger By personal communication, Christian Aichinger reported that the patch doesn't work. -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368857: [Linux-wlan-ng-devel] Bug#368857: linux-wlan-ng-firmware: Should be in contrib
On Thu, May 25, 2006 at 09:25:11AM -0400, Dylan Thurston wrote: > As I understand it, the sole purpose of this package is to download > non-free firmware. This fits into 'contrib', not 'main', since it > depends on non-free software for its ultimate operation. Packages > like this are given as an example of packages for contrib. From > Policy 2.2.2: > > > Examples of packages which would be included in _contrib_ are: > ... > * wrapper packages or other sorts of free accessories for non-free > programs. > Maybe you are right, but before doing the split (see later) I would like to be sure. The driver and the orig.tgz is DFSG clean. It works with no firmware on most adapters. We removed from the orig.tgz the firmware files (included in the upstream tgz, a project founded by the chip/firmware producer IIRC) since there was no license saying: "yes, you can redistribute these files". This package includes a 10 lines shell script that uses svn to checkout the firmware files from the upstream svn repository. For convenience we put this shell script in the same source package (actually in the diff.gz). This driver does not need the maybe-non-free stuff, but some users may be interested in using the firmware files. We could split the source package in two, one for main and one for contrib, but since I'm not sure this borderline situation is a real policy violation, I've not done it jet. In case it is, we will split. But I'm not that sure that this is a clear policy violation. This is not a wrapper package, nor a package that depends on a non free external software. Any idea if a similar package exists in main/contrib? Regards -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361236: gajim: pysql problem
On Wed, Apr 12, 2006 at 01:14:09PM +0200, Le Boulanger Yann wrote: > Could you confirm it works now? yes, it works. -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362627: freepops: exposure of confidential information in world-readable logs
On Fri, Apr 14, 2006 at 02:05:40PM -0300, Rogério Brito wrote: > Hi, I have been using freepops for a while for accessing some of my > accounts and I just discovered that the hotmail plugin seems to have a > *very* nasty side-effect: it creates a world-readable file named > log_raw.txt right under the root directory and it contains sensitive > information (the whole transaction/contents of the emails): It is already fixed upstream. there is a debug variable set to true in the hotmail.lua file. local ENABLE_LOGRAW = true ------> false -- Enrico Tassi
Bug#361236: gajim: pysql problem
Package: gajim
Version: 0.9.1-3
Severity: grave
Justification: renders package unusable
starting gajim gives (both the one in debian and the one in the upstream svn
repo):
Traceback (most recent call last):
File "gajim.py", line 65, in ?
from common import check_paths
File "/usr/share/gajim/src/common/check_paths.py", line 29, in ?
from common import gajim
File "/usr/share/gajim/src/common/gajim.py", line 47, in ?
logger = logger.Logger() # init the logger
File "/usr/share/gajim/src/common/logger.py", line 91, in __init__
self.init_vars()
File "/usr/share/gajim/src/common/logger.py", line 100, in init_vars
self.get_jids_already_in_db()
File "/usr/share/gajim/src/common/logger.py", line 103, in
get_jids_already_in_db
self.cur.execute('SELECT jid FROM jids')
pysqlite2.dbapi2.Warning: You can only execute one statement at a time.
ciao
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-amd64-k8
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages gajim depends on:
ii libaspell15 0.60.4-3 GNU Aspell spell-checker runtime l
ii libatk1.0-0 1.11.4-1 The ATK accessibility toolkit
ii libc6 2.3.6-5GNU C Library: Shared libraries an
ii libcairo2 1.0.2-3The Cairo 2D vector graphics libra
ii libfontconfig12.3.2-5.1 generic font configuration library
ii libglib2.0-0 2.10.1-2 The GLib library of C routines
ii libgtk2.0-0 2.8.16-1 The GTK+ graphical user interface
ii libgtkspell0 2.0.10-3 a spell-checking addon for GTK's T
ii libpango1.0-0 1.12.0-2 Layout and rendering of internatio
ii libx11-6 6.9.0.dfsg.1-6 X Window System protocol client li
ii libxcursor1 1.1.3-1X cursor management library
ii libxext6 6.9.0.dfsg.1-6 X Window System miscellaneous exte
ii libxi66.9.0.dfsg.1-6 X Window System Input extension li
ii libxinerama1 6.9.0.dfsg.1-6 X Window System multi-head display
ii libxrandr26.9.0.dfsg.1-6 X Window System Resize, Rotate and
ii libxrender1 1:0.9.0.2-1X Rendering Extension client libra
ii libxss1 6.9.0.dfsg.1-6 X Screen Saver client-side library
ii python2.3.5-5An interactive high-level object-o
ii python-glade2 2.8.2-3GTK+ bindings: Glade support
ii python-gtk2 2.8.2-3Python bindings for the GTK+ widge
ii python-pysqlite2 2.0.5-1python interface to SQLite 3
Versions of packages gajim recommends:
ii notification-daemon 0.3.4-4a daemon that displays passive pop
ii python-dns2.3.0-5pydns - DNS client module for Pyth
ii python2.4-dbus 0.61-5 simple interprocess messaging syst
-- no debconf information
--
Enrico Tassi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#360363: [Linux-wlan-ng-devel] Bug#360363: fails to build modules with module-assistant
On Sat, Apr 01, 2006 at 05:13:51PM +0200, Bastian Venthur wrote: > Package: linux-wlan-ng-source > Version: 0.2.4+svn20060306-1 > Severity: grave > > Hi, > > the current modules are unbuildable with module-assistant: It quits with > the following error: > > dh_testdir: cannot read debian/control: [Translated from German] File > not found > > renaming debian/control.modules.in to debian/control solves the problem. could you please try to hack a bit the rules file? I but it is cause not all toplevel targets depend on prepare_all-stamp on which target does it fail? ciao -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
