Bug#894660: qmidinet: excessive debug output on stderr

Package: qmidinet Severity: important Dear Maintainer, Please disable debug flag (passed to dh_auto_configure) in package build. It's causing qmidinet to emit debug messages to stderr on *every* MIDI event. offending config in Debian rules: https://sources.debian.org/src/qmidinet/0.5.0-1/de

Bug#891815: qmidinet should not have jackd server dependency

Package: qmidinet Severity: important Dear Maintainer, Please remove the jackd dependency from qmidinet. While the libjack dependency is needed to support integration with jack midi, qmidinet in no way requires running jackd server to operate. https://sources.debian.org/src/qmidinet/0.5.0-1/d

Bug#891709: rtaudio library writes debug info to stderr

Package: rtaudio Severity: important Dear Maintainer, Please remove --enable-debug compilation from the rtaudio build. It causes debug info to be written to stderr, such as ALSA device details: RtApiAlsa: dump hardware params just after device open: ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED

Bug#891223: jackd2: consider v1.9.12 and new JACK_PROMISCUOUS_SERVER behavior

Package: jackd2 Severity: wishlist Dear Maintainer, Please consider packaging the latest jackd2 upstream, v1.9.12. It includes an enhancement to make JACK_PROMISCUOUS_SERVER more usable and secure (see https://github.com/jackaudio/jack2/pull/257). JACK_PROMISCUOUS_SERVER can now be used without

Bug#865539: src:xmlsec1: please update to 1.2.24

Hi Rene, Thank you for your efforts on this package. I did update my key recently so expect I can still upload. Nonetheless it would be good for the distribution to have this under debian-xml-sgml given my slow response times-- thank you for suggesting. I'm happy to see that change and continue

Bug#828606: xmlsec1: diff for NMU version 1.2.23-0.1

Looks good, thank you Sebastian. On Thu, Dec 15, 2016 at 12:27 PM, Sebastian Andrzej Siewior < sebast...@breakpoint.cc> wrote: > Control: tags 828606 + patch > Control: tags 828606 + pending > > Dear maintainer, > > I've prepared an NMU for xmlsec1 (versioned as 1.2.23-0.1) and > uploaded it to D

Bug#828606: xmlsec1: FTBFS with openssl 1.1.0

I'll have to upgrade to a newer upstream version. Looks like this was addressed in 1.2.21. On Sun, Jun 26, 2016 at 3:24 AM, Kurt Roeckx wrote: > Source: xmlsec1 > Version: 1.2.20-2 > Severity: important > Control: block 827061 by -1 > > Hi, > > OpenSSL 1.1.0 is about to released. During a rebu

Bug#682827: nmu: libgeier0_0.13-1

On Thu, Jul 26, 2012 at 3:58 AM, Philipp Kern wrote: > On Wed, Jul 25, 2012 at 08:41:57PM -0400, John V. Belmonte wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: binnmu >> >> nmu libgeier0_0.13-1 . ALL . -m "rebuild to work aro

Bug#675513: libgeier0: loaded xmlsec library version is not compatible

On Wed, Jul 25, 2012 at 2:45 AM, Evgeni Golov wrote: > Can you make sure the fix lands in wheezy? Its kinda RC tbh ;) I'm wondering, is it straightforward to trigger a rebuild of libgeier0 in wheezy as a short term fix and to reduce risk of me not getting the patch into that release? I'll try to

Bug#675513: libgeier0: loaded xmlsec library version is not compatible

Yes this is an xmlsec bug. I've let the library author know about it and he's already submitted a fix, so this would appear in the next xmlsec release. http://git.gnome.org/browse/xmlsec/commit/?id=0c1e4203812ceb36beb730e86860946d9c6afa03 >From a few searches it seems like libgeier is the only l

Bug#674623: lua50: Possibility to remove the package from the archive

On Sat, May 26, 2012 at 12:40 PM, Guillem Jover wrote: > Certainly, I know for example ResidualVM (a fork of ScummVM) which > uses an embedded and modified Lua 3.1 because that's what the original > Grim Fandango scripts need. The question I guess is to what extent is > the archive supposed to car

Bug#674623: lua50: Possibility to remove the package from the archive

On Fri, May 25, 2012 at 9:28 PM, Guillem Jover 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 contr

Bug#647453: xmlsec1: examples don't build with ld --as-needed

tags 647453 + upstream forwarded 647453 http://bugzilla.gnome.org/674561 stop I've opened upstream bug, but in the meantime will apply the patch to next package release. Thanks for the report.

Bug#648104: sudoers.d/README should mention use of visudo

Package: sudo Version: 1.7.2p1-1ubuntu5.3 Severity: normal sudoers.d/README should mention recommended way of adding/editing config files in this directory. This will save user headaches with getting wedged due to file permissions, syntax errors, etc. $ visudo -f /etc/sudoers.d/my_config

Bug#524403: ITP: iguanair -- IguanaWorks Infrared Tranceiver support tools

May I suggest leaving the Python binding as a package TODO for now? What's blocking everyone (including Ubuntu downstream) is the static header file. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.o

Bug#604828: libxmlsec1-dev: corrupt .pc files

forwarded 604828 http://bugzilla.gnome.org/631258 tags 604828 fixed-upstream stop Upstream already has a fix in-- will be in their next release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#587304: lua5.1: pkg-config-file lua.pc is in wrong place and wrong package

The file used by Debian is lua5.1.pc (corresponding to the library name), and it's correctly in the -dev package. The lua.pc you refer to is upstream's example in the doc tree. Again, see README.Debian.gz for why the library name includes the version number. -- To UNSUBSCRIBE, email to debian

Bug#498416: Lua library-names

The naming is intentional. Please review the README.Debian.gz doc file on any of the packages, which explains the rationale. On Sun, Jun 27, 2010 at 5:33 AM, M G Berberich wrote: > Hello, > > The library-names of lua are totaly wrong. > > To be consistent with standards the libraries name should

Bug#559831: closed by (John V. Belmonte) (Bug#559831: fixed in xmlsec1 1.2.14-1)

close 559831 stop On Sat, Dec 12, 2009 at 6:52 PM, Michael Gilbert wrote: > i don't think that this has been resolved since there are no depends on > libtool in your control file. On closer investigation It turns out that Debian xmlsec1 is not affected by CVE-2009-3736 since we don't enable dyna

Bug#525559: Acknowledgement (libjline-java: terminal problem with wrapped lines)

Previously referenced upstream issue turns out not to be relevant, however I think this one is: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". T

Bug#457121: lua5.1: Lua stack is too small for a script that takes over 2048 arguments

On Dec 22, 2007 4:15 AM, Asko Kauppi <[EMAIL PROTECTED]> wrote: > > Hi, guys. > > I think it would be good to bring this up with the authors. Being > able to follow the native restrictions is helpful for using Lua in > system scripting, and generally in line with Lua's scalable attitude. > The prop

Bug#457121: lua5.1: Lua stack is too small for a script that takes over 2048 arguments

On Dec 21, 2007 3:47 PM, Norman Ramsey <[EMAIL PROTECTED]> wrote: > > The patch (not setting '...') is easy and even discused on the lua mailing > > list, but is clearly a drift from the upstream I'd like not to perform. > > It would be a clear violation of the semantics as stated in the > refere

Bug#457121: lua5.1: Lua stack is too small for a script that takes over 2048 arguments

Enrico Tassi wrote: > On Wed, Dec 19, 2007 at 07:03:46PM -0500, Norman Ramsey wrote: >> Package: lua5.1 >> Version: 5.1.2-4 >> Severity: normal >> >> It seems to me that the Lua interpreter should accept as many >> arguments as the local operating system is willing to provide. This >> number is fa

Bug#430272: Maybe a false positive

Enrico Tassi wrote: > 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

Bug#430272: Maybe a false positive

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. > *

Bug#394527: lua5.1: Please add shared-mime-info package file (supplied)

Hi Reuben, Isn't the following going to fail when a major version of Lua is called out (e.g. /bin/env lua5.1)? I would look at Python as an example, since it's often invoked as a similar way. Perhaps it's better not to attempt this at all since it's so fragile (e.g. what if I put two spaces be

Bug#379390: fixed in xmlsec1 1.2.9-4

Adeodato Simó wrote: > found 379390 1.2.9-4 > thanks > > Hi John, > >> xmlsec1 (1.2.9-4) unstable; urgency=low >> . >>* Fix gnutls dependency in shlibs.local (Closes: #379390) > > I'm afraid this is not really a good fix. Could you please drop your > shlibs.local file instead, as Andreas sugg

Bug#379445: libxmlsec1-gnutls: Overrides package provided shlibs in debian/shlibs.local

Andreas Metzler wrote: > Package: libxmlsec1-gnutls > Version: 1.2.9-4 > Severity: important > > Thanks for acting quickly on #379390. > > 1.2.9-4 still contains debian/shlibs.local with these contents: > libxslt 1 libxslt1.1 (>= 1.0.20) > libxml2 2 libxml2 (>= 2.6.12) > libgnutls 13 libgnutls13

Bug#335771: Please use gnutls13 instead of gnutls11

Andreas Metzler wrote: > However for gnutls libgnutls-dev is no virtual package but a real one, > there is no libgnutls13-dev. So it would not be xmlsec1 not implementing > DLP but gnutls. I see. So why has gnutls removed the sonumber from the -dev package? It may make your transitions appear eas

Bug#335771: Please use gnutls13 instead of gnutls11

James Westby wrote: > tags 335771 patch > thanks > > Hi, > > I rebuilt xmlsec1 with the attatched (trivial) patch and it seemed to > build fine. I didn't test the resulting package however. > > James > ... > -Build-Depends: debhelper (>> 4.0.0), autotools-dev, pkg-config, libxml2-dev, > libxsl

Bug#364382: no update?

Marcos Pinto wrote: > i don't understand why this bug hasnt been closed yet with the > previously submitted patch. quite a few different programs are in > limbo because xmlsec1 has not been updated. please, get this going so > the other developers may move on As the submitter of the patch stated

Bug#359172: libgtk2.0-0: scrolling much slower in gtk 2.8

This bug still exists in 2.8.17, and is still a serious problem. I investigated further and, at least in my case, this only shows up with a remote X server. Perhaps that explains why more people haven't noticed the problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsub

Bug#361740: liblua50-dev: symlink pointing to .

Daniel Silverstone wrote: > Some are aware and do: > > #include and have -I/usr/include/lua50 If software using Lua's C API wants to be portable, it should use the form and get the include path from pkg-config. That should be the end of it. Should someone want to use such software on a tiny s

Bug#361736: lua5.1: Quitting a Lua process blocked on I/O requires two ^C's

Reuben Thomas wrote: > Running a Lua script which blocks on I/O from stdin, it takes two > Ctrl-C's to quit it. I think this is an old problem, and requires > Linux-specific code (using sigsetaction) to solve, which is present in > the 5.0 packages. I need more info on this (mailing list links, e

Bug#360634: lua5.1: Please add bin2c

> Please add bin2c to the -dev package; it's most useful. LuaBinaries > packages already include it. Hi Reuben, I think bin2c is best avoided (the Lua authors have the right idea). At the least, it's terribly named: "bin2c" sounds general, yet this tool has the specific job of generating Lua C A

Bug#359172: libgtk2.0-0: scrolling much slower in gtk 2.8

I confirm this. Recently when upgrading my scite editor from sid I pulled in gtk 2.8, and painting generally feels an order of magnitude slower, which is especially noticeable in scrolling. When I did a custom build of the same scite version for sarge and downgraded libgtk back to sarge version t

Bug#354962: pysvn: version 1.4.0 available

Matthias Klose wrote: > no, this doesn't work. subversion-1.3.0 needs to hit unstable first, > so that libsvn0-dev becomes installable again, rapidsvn can be built, > and then pysvn. The point is that subversion 1.3 is already officially packaged. Please package pysvn and rapidsvn and place them

Bug#345607: libtool: "line 606: --: command not found" message for --mode=link

Kurt Roeckx wrote: > Please show the whole command line. I can reproduce this if for > instance I use "gcc-4.0" instead of gcc or cc. I then get: > $ libtool --mode=link gcc-4.0 tst.c -o tst > /usr/bin/libtool: line 606: --: command not found > libtool: link: unable to infer tagged configuration

Bug#337587: bad behavior after Ctrl-C at "wajig source" continue prompt

Graham, since you removed the implicit apt-get build-dep, this is likely no longer an issue for "wajig source". However, it may be worth investigating if other commands such as "wajig build" have a similar issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Tro

Bug#337587: bad behavior after Ctrl-C at "wajig source" continue prompt

Graham Williams wrote: > Hi John, > > Thanks for the bug report. > > Could you show me the output of "wajig -t source ..." so I might > see where the question is being asked. I don;t get this question. > > Regards, > Graham Hi Graham, here you go: $ wajig -t source swig1.3 Performing: cat

Bug#319807: libxmlsec 1.2.9

Hi Rene, I appreciate the kick in the rear. I'll get the update submitted within a week. --John Rene Engelhard wrote: > Hi, > > I filed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319807 49 days > ago and there still was no reaction? Was there a reason? Did you just > oversee it? > > As

Bug#325194: Acknowledgement (python-svn: pysvn.checkout segfault)

pysvn 1.2 series does not support the Subversion 1.2 series API (see ). That means when Subversion 1.2 was pulled into sid it broke the pysvn package. The pysvn Depends should be updated to not include Subversion 1.2 and later. The issue will be

Bug#321373: xmlsec1: 2 examples (decrypt2 and decrypt3) generate core dumps

Erwann Abalea wrote: > Go to the examples directory, compile decrypt2 and decrypt3, and run > either one with the good parameters. For example: > [...] > If you don't set MALLOC_CHECK_, you get a core dump. > > The error lies somewhere between the calls to > xmlSecReplaceNodeBuffer() made by the