Bug#894660: qmidinet: excessive debug output on stderr

[John Belmonte]

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/debian/rules/#L17

qmidinet uses ac_debug for verbose debug output:

https://github.com/rncbc/qmidinet/blob/6777a3b2714ad8ab8db7ab519554e41cd9ca242c/configure.ac#L83

https://github.com/rncbc/qmidinet/blob/1309774269c5b88ae021e248f6734f2c6e6182a5/src/qmidinetAlsaMidiDevice.cpp#L291

Thank you

Bug#891815: qmidinet should not have jackd server dependency

[John Belmonte]

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/debian/control/#L25

Regards,
--John

Bug#891709: rtaudio library writes debug info to stderr

[John Belmonte]

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
  FORMAT:  S16_LE S24_LE
  SUBFORMAT:  STD
  SAMPLE_BITS: [16 32]
  FRAME_BITS: [16 96]
  ...

Clients using the rtaudio library should have control over
what's emitted on stdio.  If the info is important for some use
cases, please ask upstream to put the logging under runtime
control.

Regards,
--John

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

[John Belmonte]

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 lowering umask of
the server or client, and furthermore supports group permissions.
So there's finally a sane way to run a shared jackd daemon from the
init service and let users of a particular group connect to it.

I'm a DD-- happy to assist if I can assuming there's some will to
get this in.

Regards,
--John

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

[John Belmonte]

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 as a co-maintainer.

Regards,
--John


On Fri, Jun 23, 2017 at 2:58 AM, Rene Engelhard  wrote:

> Hi,
>
> On Thu, Jun 22, 2017 at 11:09:43PM +0200, Rene Engelhard wrote:
> > It basically boils down just to
> >
> > $ cat debdiff | filterdiff -i '*debian*'
> > diff -Nru xmlsec1-1.2.23/debian/changelog xmlsec1-1.2.24/debian/
> changelog
> > --- xmlsec1-1.2.23/debian/changelog   2016-12-15 21:09:18.0
> +0100
> > +++ xmlsec1-1.2.24/debian/changelog   2017-06-22 18:54:56.0
> +0200
> > @@ -1,3 +1,10 @@
> > +xmlsec1 (1.2.24-0.1) unstable; urgency=medium
> > +
> > +  * Non-maintainer upload
> > +  * New upstream release (closes: #865539)
> > +
> > + -- Rene Engelhard   Thu, 22 Jun 2017 18:54:56 +0200
> > +
> >  xmlsec1 (1.2.23-0.1) unstable; urgency=medium
> >
> >* Non-maintainer upload.
> >
> > OK, one might want to run the tests (see #774631) but that also can be
> done
> > later...
> >
> > Used ratt to rebuild the 3 r-deps against 1.2.24 and they succeeded.
>
> It occurred to me that you probably can't upload anyway since your key is
> 1024 and probably
> removed from the keyring.
>
> What do you think of putting xmlsec1 under the umbrealla of the Debian
> XML/SGML Group
> which also maintains other XML related packages:
>
> https://qa.debian.org/developer.php?login=debian-
> xml-sgml-p...@lists.alioth.debian.org
>
> If you agree I would change Maintainer:, and add you and me to Uploaders:
> (if you still
> want to be co-maintainer)
>
> Otherwise I probably would NMU it relatively quickly, since LO 5.4.0 will
> be released end
> of July and we have waited so long to be able to ditch the internal copy
> of libxmlsec
> that it would be a pity to not (be able to) just do it :)
>
> Regards,
>
> Rene
>

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

[John Belmonte]

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 DELAYED/4. Please feel free to tell me if I
> should delay it longer.
> I replaced the orig tar archive from 1.2.20 to 1.2.23 and dropped the
> patches since they are applied upstream. The OpenSSL 1.1.0 support is
> already part of this release so this comes for free.
>
> Regards.
> Sebastian
>

Bug#828606: xmlsec1: FTBFS with openssl 1.1.0

[John Belmonte]

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 rebuild of all packages using
> OpenSSL this package fail to build.  A log of that build can be found at:
>
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/xmlsec1_1.2.20-2_amd64-20160529-1555
>
> On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various
> of the
> reasons why it might fail.  There are also updated man pages at
> https://www.openssl.org/docs/manmaster/ that should contain useful
> information.
>
> There is a libssl-dev package available in experimental that contains a
> recent
> snapshot, I suggest you try building against that to see if everything
> works.
>
> If you have problems making things work, feel free to contact us.
>
>
> Kurt
>

Bug#682827: nmu: libgeier0_0.13-1

[John Belmonte]

On Thu, Jul 26, 2012 at 3:58 AM, Philipp Kern pk...@debian.org 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 around xmlsec issue (bug 
 #675513)

 Where's the proposed patch to xmlsec?

I've just uploaded xmlsec1_1.2.18-2 which has the fix.

If we can't get that xmlsec1 update into wheezy, for now I think it's
sufficient to rebuild libgeier against the existing version 1.2.18-1.
The issue would only come up again if wheezy somehow got a newer
upstream version of xmlsec1.

Regards,
--John


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[John Belmonte]

On Wed, Jul 25, 2012 at 2:45 AM, Evgeni Golov evg...@debian.org 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 get a patch uploaded in the next week.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[John Belmonte]

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 library that
uses this function, and the problem has been reported by various
people for over a year.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[John Belmonte]

On Sat, May 26, 2012 at 12:40 PM, Guillem Jover guil...@debian.org 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 carry how many old versions, and when
 developers are supposed to migrate (if it's feasible at all). I guess I
 could have formulated that explicitly in the report, because I don't know
 your policies about switching the archive to new versions and such, or
 when you usually remove old versions when the archive does not need
 them anymore. Or after how many new upstream releases (seeing packages
 are now starting to switch to Lua 5.2).

If you look at the Lua version timeline, you'll see the duration
between major versions increasing exponentially (the last was 6
years).

  http://www.lua.org/versions.html

Each major version is self-contained and bug free.  I think the old
versions should stay in the archive as long as there are users.

Think of the dozens of crappy scripting and extension engines the
Debian repo would have to house if Lua didn't exist ;)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[John Belmonte]

On Fri, May 25, 2012 at 9:28 PM, Guillem Jover guil...@debian.org wrote:
 There's currently only two packages Build-Depending on lua50, elinks
 and fillets-ng, for which I've filed bugs with patches to switch to
 Lua 5.1. I'll mark them as blocking this one.

It's not necessarily in the software developer's control to upgrade
the Lua version.  The Lua library is used to extend and configure
applications, and the language itself is incompatible between major
versions.  I don't know anything about the two packages you mentioned,
but for example one could have thousands of users who wrote their own
scripts for the application, and those scripts might break if Lua is
upgraded.

This is explained under Need to maintain old Lua releases in
README.Debian of the Lua packages.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[John Belmonte]

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

[John Belmonte]

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


-- System Information:
Debian Release: squeeze/sid
  APT prefers lucid-updates
  APT policy: (600, 'lucid-updates'), (600, 'lucid-security'), (600, 'lucid'), 
(400, 'lucid-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38.8-gg621 (SMP w/12 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages sudo depends on:
ii  libc6  2.11.1-0ubuntu7.8 Embedded GNU C Library: Shared lib
ii  libpam-modules 1.1.1-2ubuntu5.4  Pluggable Authentication Modules f
ii  libpam0g   1.1.1-2ubuntu5.4  Pluggable Authentication Modules l

sudo recommends no packages.

sudo suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[John Belmonte]

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

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

[John Belmonte]

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#498416: Lua library-names

[John Belmonte]

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
berbe...@fmi.uni-passau.de wrote:
 Hello,

 The library-names of lua are totaly wrong.

 To be consistent with standards the libraries name should be
 p.e. “liblua.so.5.1.0” instead of “liblua5.1.so.0.0.0”. The
 pkg-config-name should be “lua”. There should be packages
 liblua50-dev, liblua51-dev, etc. which provide liblua-dev.



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

[John Belmonte]

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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[John Belmonte]

close 559831
stop

On Sat, Dec 12, 2009 at 6:52 PM, Michael Gilbert
michael.s.gilb...@gmail.com 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 dynamic crypto module
loading (--enable-crypto_dl).

Thanks for your attention.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[John Belmonte]

Previously referenced upstream issue turns out not to be relevant,
however I think this one is:

http://sourceforge.net/tracker/index.php?func=detailaid=1793961group_id=64033atid=506056



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[John Belmonte]

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 proposed alternative of making 'arg' a userdata which would proxy
 to the operating system's strings sounds small code, efficient and in
 every way preferable to me.

 Maybe that should be made into a patch and proposed to the authors,
 then?

 There are some issues, though.

 - If 'arg' is being phased out at some point (it no longer is needed
 for anything, really) how to give the unlimited functionality to
 '...' at the chunk level?

 - If 'arg' remains, it could work unlimited whereas the '...' way
 would carry the limits.

To me the solution is simple-- the command line arguments should be
available as a list via select(1, ...).  In other words the standard
Lua interpreter passes command line args to the chunk as a list
argument-- no magic involved.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[John Belmonte]

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
 reference manual.

I'm not suggesting we depart from upstream.  This is an upstream
misdesign which they need to correct.  If function/chunk arguments are
a constrained resource (like CPU registers, stack size, etc.) then the
lua interpreter has no business mapping command line arguments to
them.  What if some OS had virtually unlimited command line length?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[John Belmonte]

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 fairly fuzzy (see http://tinyurl.com/nn8yd for a good
 discussion of the issues), but the current default of 2048 is
 unreasonably small for a stock Debian system.  ARG_MAX is 131072 on
 this system, so supposing we assume each argument is an 8.3 pathname
 with a trailing null, even leaving room for some environment this is
 space for about ten thousand arguments.  I suggest that when Lua is
 built for Debian that line 445 of luaconf.h be changed so that 
 LUAI_MAXCSTACK is more in that range.
 
 Citing luaconf.h:
 
This limit is arbitrary; its only purpose is to stop C
functions to consume unlimited stack space.
 
 So it seems safe to increase this parameter. The only thing that bothers
 me is that you may end up writing a lua script that works pretty well on
 Debian, but won't run on Fedora/Gentoo/Windows/OSX or any other platform on
 which lua has been compiled with *default* options.
 
 I suggest you to make your script accept a path (root directory) and
 iterate on its contents with lfs.dir (liblua5.1-filesystem0 in debian).
 This should work even for extremely populated directories and is pretty
 portable too. lfs also supports a function to check if a given path is a
 directory (thus the current semantics of your script can be preserved).
 Your command line should then be changed using '.' instead of '*'.
 
 Since the workaround seems easy and the patch could compromise
 portability of .lua scripts written on Debian, I'm reluctant to the
 proposed change.
 
 Do you agree? 

If I understand correctly, I think this is a misdesign of the Lua
standard intepreter.  It should not be mapping command line argument
words to Lua arguments precisely because there is an arbitrary (and
relatively low) limit on chunk args.  Instead, lua should assemble the
command line arguments into a Lua list, and pass that list to the script
chunk as a single argument.  Since Lua list length is virtually
unlimited, there will be no such issue with command line length.

--John



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#430272: Maybe a false positive

[John Belmonte]

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.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#430272: Maybe a false positive

[John Belmonte]

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

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.

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.

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.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[John Belmonte]

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 between /bin/env and lua)?

magic priority=50
  match value=/bin/lua type=string offset=1:16/
  match value=/bin/env lua type=string offset=1:16/
/magic


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[John Belmonte]

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 (= 1.0.0)
 
 Why?
 
 Have you actually tested that libxmlsec1-gnutls linked against current
 sid (libxml2 2.6.26.dfsg-2, libgnutls13 1.4.1-1, libxslt1.1 1.1.17-2)
 actually works with the old versions you specified? Are you willing to
 repeat this testing whenever a new version of these packages is
 uploaded to sid? Why don't you rely on Debian's shlibs system?
 
 cu andreas

Hi Andreas,

The minimum version numbers I call out in shlibs.local, at least for
xslt and xml2, are defined by upstream.  If someone can show that xmlsec
doesn't work in those version ranges, that's an upstream bug.  I don't
think the burden of proof in this case should rest on the packager.
Calling out actual minimum versions can simplify backports.

--John


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379390: fixed in xmlsec1 1.2.9-4

[John Belmonte]

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 suggested?

Sorry, you found the serious bug Links agains libgutls13, depends on
libgnutls11 in 1.2.9-4?

If you make a good argument I may consider dropping shlibs.local, but
that is not this bug.

--John

Bug#335771: Please use gnutls13 instead of gnutls11

[John Belmonte]

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 easier in that you don't have to
rely on dependent packages to change their BD, but will create other
problems.  If there is a major API change in the future that takes
upstream packages a few years to migrate to, Debian will be stuck
because we can't support build depends for two versions in the same archive.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#335771: Please use gnutls13 instead of gnutls11

[John Belmonte]

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, 
 libxslt1-dev, libssl-dev (= 0.9.7), libgnutls11-dev, libnss3-dev
 +Build-Depends: debhelper ( 4.0.0), autotools-dev, pkg-config, libxml2-dev, 
 libxslt1-dev, libssl-dev (= 0.9.7), libgnutls-dev, libnss3-dev

This violates best practice given by the Debian Library Packaging Guide:

http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id4732200
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id4732240

In any case, I will fix this bug once proper runtime testing has been
done against the new gnutls version.

--John


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#364382: no update?

[John Belmonte]

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, no functional testing of the
package with this change has been done.  Something is wrong with the nss
examples build in libxmlsec1-dev.  Although I don't think it's related
to the patch, I'm not prepared to do an upload without getting this
basic regression test to work again.  I'm on vacation through the U.S.
holiday weekend and have some other obligations so it may be a week or
so before I can investigate this.

--John


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[John Belmonte]

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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[John Belmonte]

Daniel Silverstone wrote:
 Some are aware and do:
 
 #include lua.h and have -I/usr/include/lua50

If software using Lua's C API wants to be portable, it should use the
lua.h 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
system without pkg-config, they can make the one line change to the
makefile.  Hacks such as the symlink only encourage further
obliviousness to best practice.

--John


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[John Belmonte]

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, etc.).  Unfortunately the
5.0 Debian package is not well organized and doesn't isolate that patch.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[John Belmonte]

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 the problem went away.

I think this bug should be higher severity than normal.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#360634: lua5.1: Please add bin2c

[John Belmonte]

 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 API code.  Not /usr/bin
material in my opinion.

As suggested by Luiz, please consider using xxd:

  $ apt-get install vim-common  # provides xxd
  $ echo print('hi')  test.lua
  $ xxd -i test.lua  test_lua.c

Then in your C program (quite easy to make a macro of this):

  int do_test_lua(lua_State* L)
  {
  #include test_lua.c
  return luaL_loadbuffer(L, (void*)test_lua, test_lua_len,
  test.lua) || lua_pcall(L, 0, 0, 0);
  }


--John


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#354962: pysvn: version 1.4.0 available

[John Belmonte]

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 into experimental along with
it.  This will enable systems requiring both svn and pysvn to assist in
testing the experimental version, and reduce unnecessary delay once 1.3
is deemed ready.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[John Belmonte]

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
 libtool: link: specify a tag with `--tag'
 
 Adding a --tag=CC fixes my problem:
 $libtool --mode=link --tag=CC gcc-4.0 tst.c -o tst
 gcc-4.0 tst.c -o tst
 
 Normally using gcc also fixes the problem:
 $libtool --mode=link gcc tst.c -o tst
 gcc tst.c -o tst

As gcc-4.0 is the default compiler in sid, that would seem to be
triggering the problem.  I'm using gcc on the command line.  The
--tag option doesn't seem to be documented in info libtool so I
can't comment on that workaround.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[John Belmonte]

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. Trouble? Contact [EMAIL PROTECTED]

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

[John Belmonte]

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 /var/lib/dpkg/status | egrep
'^(Package|Status|Version):' | awk '/^Package: / {pkg=$2}  /^Status:
/ {s1=$2;s2=$3;s3=$4} /^Version: / {print pkg,$2,s1,s2,s3}' | grep
'ok installed' | awk '{print $1,$2}' | sort  
/home/john/.wajig/pelochan/tmpZWAGNN
Performing: apt-get build-dep 'swig1.3'
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  autoconf automake1.4 autotools-dev bison chicken chicken-dev gcj
gcj-4.0 gij
  gij-4.0 guile-1.6 guile-1.6-dev guile-1.6-libs java-common libgcj-common
  libgcj6 libgcj6-common libgmp3c2 libguile-ltdl-1 libice-dev
libncurses5-dev
  libnettle2 libpcre3-dev libperl-dev libqthreads-12 libreadline5-dev
  libruby1.8 libsm-dev libssl-dev libtool libttf2 libx11-dev libxext-dev
  libxi-dev libxkbfile-dev libxt-dev libzzip-0-12 m4 mime-support ocaml
  ocaml-base ocaml-base-nox ocaml-interp ocaml-nox php4-cgi php4-common
  php4-dev pike7.6 pike7.6-core pike7.6-dev pike7.6-gdbm pike7.6-image
  python-dev ruby1.8 ruby1.8-dev shtool tcl8.4 tcl8.4-dev tk8.4 tk8.4-dev
  x-dev
0 upgraded, 61 newly installed, 0 to remove and 1 not upgraded.
Need to get 48.9MB of archives.
After unpacking 160MB of additional disk space will be used.
Do you want to continue [Y/n]?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#319807: libxmlsec 1.2.9

[John Belmonte]

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 said, I want OOo to dynamically link against system-xmlsec and not
 ship an own (patched, but that patch isn't needed with 1.2.8 anymore)
 libxmlsec.
 
 So I wonder why libxmlsec1 didn't get updated yet? No time? Some other
 reason? If you simply don't have time, may I NMU?
 
 Regards,
 
 Rene


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[John Belmonte]

pysvn 1.2 series does not support the Subversion 1.2 series API (see
http://pysvn.tigris.org/issues/show_bug.cgi?id=36).  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 fixed in the upcoming pysvn 1.3 series.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[John Belmonte]

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 xmlSecEncCtxDecrypt() function
 and xmlFreeDoc() done by the example itself. It goes too deep inside
 libxml2 for me to debug.

As part of my release process for the xmlsec1 package I run the examples
check (make check), and at the time I published 1.2.6-1 this problem
didn't exist.  There may be a problem with one of the package's
dependencies.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]