Bug#1061392: uploaded NMU to DELAYED/5

[Torsten Landschoff]

Hi Matthias,

Am 2024-01-26 17:14, schrieb Matthias Klose:

uploaded NMU 4.2.0-0.1 to DELAYED/5


I had 4.2.0-1 in work at salsa and tried uploading it now to avoid the 
delay.


Now the queue daemon rejected my upload because the existing uploaded:

--
/swig_4.2.0-1_source.changes is already present on target host:
5-day/swig_4.2.0.orig.tar.gz
Either you already uploaded it, or someone else came first.
Job swig_4.2.0-1_source.changes removed.
--

AFAIR remember, a direct upload should take precedence over a delayed 
one.


I wonder what the best way forward would be here.

* Wait for the delayed upload to get processed
* Prepare a new upload without the orig.tar.gz
* Overwrite 4.2.0-0.1?

I'd like to have the debian/changelog contain all versions ever in 
unstable, but

I have no idea how I would merge those changes.

Maybe just put your changelog entry into debian/master :shrug:

Do you have a better solution?


Greetings, Torsten

Bug#1060801: SWIG 4.2.0 has been released, package needs updating

[Torsten Landschoff]

Package: swig
Version: 4.1.0-0.3

I just noticed that SWIG 4.2.0 has been released on the last day of 
2023:


https://sourceforge.net/p/swig/news/2023/12/swig-420-released/

The package needs to be updated from the new upstream.

Bug#965481: ddclient: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Torsten Landschoff]

Am 2020-07-22 07:49, schrieb Torsten Landschoff:

I will upload today after work. Great work, Richard!


Hmm, I uploaded the build on wednesday. dput did not complain but I 
still can't see the package in Debian.


I actually spent quite a while fighting with pbuilder because I wanted 
to include the changelog of all versions that we did not upload to the 
archive (so that the closes: #... entries in changelog are applied).


Greetings, Torsten

Bug#965481: ddclient: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Torsten Landschoff]

I will upload today after work. Great work, Richard!

Am 21. Juli 2020 19:09:17 MESZ schrieb Richard Hansen :
>Changes for debhelper-compat 12 have already been committed:
>https://salsa.debian.org/debian/ddclient/-/blob/c85aa96a6b51386e2f7994fc1ad7ae60f9cda098/debian/control#L5
>but I'm waiting for a sponsor to upload:
>https://bugs.debian.org/962159

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#962159: I'd consider this release fit for Debian unstable

[Torsten Landschoff]

Hi Richard,

I reviewed your ddclient package in depth and consider it great work.

For reference, here are the hashes of the dsc that I checked:

> Checksums-Sha256:
>  e4969e15cc491fc52bdcd649d4c2b0e4b1bf0c9f9dba23471c634871acc52470 63469 
> ddclient_3.9.1.orig.tar.gz
>  1aa53a616911e2149de8adf5c199e75182ae26083c4f1afdfeaa3179d3f6f60b 55004 
> ddclient_3.9.1-1.debian.tar.xz

This appears to match with this commit (I did not validate that guess
though):

https://salsa.debian.org/debian/ddclient/-/commit/67a138aa3d98d70f01766123f58ef40e98693fd4

For a final test I was about to build the package and install it locally
but I noticed that it is targetting the UNRELEASED distribution.

So I guess there are some changes that you still want to apply before
building a release? I'll gladly sign and upload the package, in the
current state already...

Greetings, Torsten




signature.asc
Description: OpenPGP digital signature

Bug#951839: swig4.0 segfaults building ltt-control

[Torsten Landschoff]

Hi Adrian,

On 2/22/20 11:49 AM, Adrian Bunk wrote:
> Package: swig4.0
> Version: 4.0.1-4
> Severity: serious
> Tags: ftbfs
> Control: affects -1 ltt-control
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ltt-control.html
>
> ...
> /usr/bin/swig -python -I. -I../../../../src/common/sessiond-comm lttng.i
> make[2]: *** [Makefile:896: lttng_wrap.c] Segmentation fault
>
>
>
> Backtrace:
>
> #0  PYTHON::build_combined_docstring (this=this@entry=0x55c023c3fc80, 
> n=n@entry=0x7f7cd7c9f970, ad_type=AUTODOC_FUNC, 
> indent=indent@entry=0x55c02212c0b0, low_level=low_level@entry=true)
> at ../../Source/Modules/python.cxx:1490
> #1  0x55c0220a05ce in PYTHON::cdocstring (low_level=true, 
> ad_type=, n=0x7f7cd7c9f970, this=0x55c023c3fc80)
> at ../../Source/Modules/python.cxx:1596

this appear to be this upstream bug:
https://github.com/swig/swig/issues/1648

I'll incorporate the upstream fix and release a new version.


Greetings, Torsten





signature.asc
Description: OpenPGP digital signature

Bug#928375: Announce - swig-4.0.0

[Torsten Landschoff]

On 1/16/20 10:23 PM, Torsten Landschoff wrote:
> I'm astonished that the release announcement of swig 4.0 is dated april
> 2019 :-(
>
>
> Working on it now but it's already late for today.

Update: I just prepared an upload to experimental. Still some lintian
stuff to do and I really need to update the Standards-Version before
uploading for unstable.

The package corresponds to this tag:
https://salsa.debian.org/debian/swig/-/tags/debian%2F4.0.1-1


Greetings, Torsten

Bug#928375: Announce - swig-4.0.0

[Torsten Landschoff]

On 1/1/20 5:13 PM, Alan Woodland wrote:
> On Mon, 2 Sep 2019 23:02:32 +0200 Torsten Landschoff <
> tors...@landschoff.net> wrote:
>> On 5/3/19 10:37 AM, Mathieu Malaterre wrote:
>>> Would be super nice to have swig 4 in Debian.
>> absolutely. And I did not notice for months. I'll have a go - maybe
> this
>> weekend, but no guarantees!
> How did it go? Is there anything you'd like some extra effort from
> another person on? I'm pretty invested in SWIG these days, so it'd be
> great to see this release in Debian.

The late reply is probably answer enough. I took today and tomorrow of
to finally have some time to spare on stuff I want to get done.

I'm astonished that the release announcement of swig 4.0 is dated april
2019 :-(


Working on it now but it's already late for today.

Greetings, Torsten

Bug#679592: swig: missing depends on pike7.6 but refers on rules

[Torsten Landschoff]

On 10/24/19 2:03 AM, Olly Betts wrote:
> Upstream release SWIG 4.0.0 disabled support for Pike:
>
> 2019-02-04: wsfulton
>   [Pike] #1447 Pike has been disabled as a target language in 
> SWIG as part of a
>   clean up to remove target languages that have been 
> neglected/not functional.
>
> And now:
>
> $ swig -pike
> Target language option -pike (Pike) is no longer supported.
>
> So this bug can be closed once upstream version 4.0.x is packaged.

Yeah :-)

Who is using pike these days anyways?

Bug#727005: switch python bindings to python3

[Torsten Landschoff]

On 10/27/19 7:03 PM, Boruch Baum wrote:
> Hi Andreas,
>
> I don't foresee this working, because the package depends on swig to
> perform the heavy lifting for the python bindings, and debian currently
> packages only version 3 of swig, which as far as I can tell, does not
> support python3...

Actually, SWIG supports Python 3 for quite some time: Support was
introduced in SWIG 1.3.37

Source: https://github.com/swig/swig/blob/master/RELEASENOTES#L260

AFAICT, only some Python 3.8 specific changes are missing in SWIG 3.

> Version 4 of swig does seem to support python3, using a new command-line
> option `-py3`.

This option is only for type annocation support.

See http://swig.org/Doc3.0/SWIGDocumentation.html#Python_nn74

> @Torsten - Am I correct about python3 support in swig3? Is debian
> planning on soon updating the package to version 4 (ie. before debian
> drops support for python2)? Do you have any suggestions or pointers for
> us?

See above for Pointers wrt. Python 3 support. Matthias Klose uploaded an
NMU to add even Python 3.8 support to swig3.

I intend to upload swig4 soonish.

Greetings, Torsten

Bug#928375: Announce - swig-4.0.0

[Torsten Landschoff]

On 5/3/19 10:37 AM, Mathieu Malaterre wrote:
> Would be super nice to have swig 4 in Debian.

absolutely. And I did not notice for months. I'll have a go - maybe this
weekend, but no guarantees!

Greetings, Torsten

Bug#924487: swig3.0-examples: Install all examples

[Torsten Landschoff]

Am 2019-03-13 14:32, schrieb Hilko Bengen:

Replacing debian/swig3.0-examples.examples with the single line
,
| Examples/*
`

will lead to the Go examples being installed along with a bunch of 
other

missing examples.


I actually wonder why on earth I listed the subfolders in the .examples 
dh file. :facepalm:


Will change as suggested.

Greetings, Torsten

Bug#920734: swig FTCBFS: does not pass --host to ./configure

[Torsten Landschoff]

Am 2019-01-28 17:26, schrieb Helmut Grohne:


swig fails to cross build from source, because it does not pass --host
to ./configure. The easiest way of doing so is letting 
dh_auto_configure

do it. That is sufficient to make swig cross buildable. Please consider
applying the attached patch.



That makes sense. Thanks for the patch! I will merge it for the next 
upload.


Greetings, Torsten

Bug#901504: generated bindings incompatible with octave 4.4

[Torsten Landschoff]

Feel free to NMU an updated package with those commits if this is urgent to you.

I'll not get around to do this for at least a week...

Greetings, Torsten 

Am 14. Juni 2018 10:36:40 MESZ schrieb "Sébastien Villemot" 
:
>Package: swig3.0
>Version: 3.0.12-1
>Severity: important
>Tags: upstream
>Control: block 901155 by -1
>Control: affects -1 plplot
>X-Debbugs-Cc: debian-oct...@lists.debian.org
>
>Dear Maintainer,
>
>Octave 4.4 has been uploaded to unstable, and swig needs to be updated
>in order
>to generate compatible bindings.
>
>The most urgent issue is to fix plplot, which now FTBFS, and is
>blocking the
>Octave 4.4 transition:
>
>https://buildd.debian.org/status/fetch.php?pkg=plplot=amd64=5.13.0%2Bdfsg-7%2Bb1=1528654000=0
>
>Upstream has already a series of commits for Octave 4.4, see:
>
>git log
>ee17f8d04f40bfc25ecaf146a6ebe667eabcffb6..a2ab3d7b20feec5f46100d98712dd92cf4f9bc52
>
>If you don't have the time to backport these, I can do the work
>(possibly
>limiting myself to the commit(s) needed to fix plplot) and then NMU.
>Please
>advise.
>
>Best,
>
>-- 
>⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
>⣾⠁⢠⠒⠀⣿⡁  Debian Developer
>⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
>⠈⠳⣄  http://www.debian.org

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Bug#880546: Packaging Isabelle was requested before but the plan was dropped

[Torsten Landschoff]

Have a look at this bug:

https://bugs.debian.org/494491

It looks for me like upstream would prefer not to have a Isabelle Debian
package. :-(

Bug#868748: swig3.0: Cherry-pick upstream fix for R wrappers generation

[Torsten Landschoff]

Am 2017-07-18 10:49, schrieb Ghislain Antony Vaillant:

As part of my current effort to package SimpleITK, I discovered that 
our
version of swig is affected by a bug which prevents the correct 
generation

of R wrappers [1]. The corresponding fix was merged upstream and has
been released since version 3.0.11.

[1] https://github.com/swig/swig/pull/839

Please consider either upgrading swig to the latest upstream release
(3.0.12 at the time of writing), or cherry-pick the patch on top of the
current version.


Thanks, will do!

Greetings, Torsten

Bug#863848: swig: New upstream release

[Torsten Landschoff]

On 05/31/2017 11:17 PM, Sylvestre Ledru wrote:
> Could you please package 3.0.11, or, better 3.0.12 ?
> This is now mandatory for some packages like lldb.

Still have to find some spare time... But I am sure I will.

Greetings, Torsten

Bug#858085: swig: Separate binary package for ccache-swig, with /usr/lib/ccache/ symlink

[Torsten Landschoff]

On 03/18/2017 06:18 AM, Karl Wette wrote:
> Package: swig
> Version: 3.0.8-0ubuntu3
> Severity: wishlist
>
> At the moment /usr/bin/ccache-swig is installed in the same package as 
> /usr/bin/swig.
> This package however does not provide a symlink in /usr/lib/ccache, as is the 
> case
> for gcc and other compilers. The user must therefore either create their own 
> symlink
> somewhere, or change the name of the SWIG binary used from "swig" to 
> "ccache-swig swig",
> which may be be easy to do if one is building a package owned by someone else.
>
> It would be useful if a separate ccache-swig binary package could be 
> provided, containing
>
> /usr/bin/ccache-swig
> /usr/lib/ccache/swig -> ../bin/ccache-swig
>
> Anyone who wants to use ccache-swig could then simply install this package, 
> and append
> /usr/lib/ccache to their PATH, as one does when using ccache with gcc, etc.
Thanks for the suggestions. I have to admit that I never used
ccache-swig because the bindings I compile are mostly small enough that
I don't care for caching during compilation.

Greetings, Torsten

Bug#811418: fixed in swig 3.0.8-0

[Torsten Landschoff]

On 10/30/2016 08:35 PM, Laurent Bigonville wrote:
> Le 30/10/16 à 13:29, Laurent Bigonville a écrit :
>> On Sat, 7 May 2016 11:59:07 +0200 Laurent Bigonville
>>  wrote:
>> > Hi,
>> >
>> > [...]
>> > > swig (3.0.8-0) experimental; urgency=medium
>> > [...]
>> >
>> > Could you please upload 3.0.8 to unstable?
>> >
>> > I've binding for python3.5 being broken with 3.0.7, rebuilding them
>> with
>> > 3.0.8 fix the issue.
>> >
>> > Python 3.5 is now the default version now
>>
>> Hi,
>>
>> Any plans to do this before the freeze?
> I've uploaded 3.0.8 to the deferred/15 queue, it means that it will
> hit unstable in 15days.
>
> Tell me if I should cancel this upload. 
hmm, I uploaded 3.0.10 to unstable, see attached email.

No idea why it is not yet processed.

Greetings, Torsten

--- Begin Message ---
swig_3.0.10-1_amd64.changes uploaded successfully to localhost
along with the files:
  swig_3.0.10-1.dsc
  swig_3.0.10.orig.tar.gz
  swig_3.0.10-1.debian.tar.xz
  swig-doc_3.0.10-1_all.deb
  swig-examples_3.0.10-1_all.deb
  swig3.0-dbgsym_3.0.10-1_amd64.deb
  swig3.0-doc_3.0.10-1_all.deb
  swig3.0-examples_3.0.10-1_all.deb
  swig3.0_3.0.10-1_amd64.deb
  swig_3.0.10-1_amd64.deb

Greetings,

Your Debian queue daemon (running on host franck.debian.org)
--- End Message ---

Bug#832395: ddclient: Reset $ipv6 per host instead of per service

[Torsten Landschoff]

Hi,

On 07/25/2016 03:16 AM, micror...@gmail.com wrote:
> Setting 'usev6' for a host in ddclient.conf poisons subsequent hosts.
>
> http://sources.debian.net/src/ddclient/3.8.3-1.1/ddclient/#L867

good catch!

> This part of the code turns on the $ivp6 flag and leaves it on for the
> rest of the hosts associated with the same service. It's not until it
> gets to the next service that it resets $ipv6 on line 860.
>
> I have an IPv4 hostname that comes alphabetically after an IPv6
> hostname, so could you move the `my $ipv6 = 0` down to, say, line 866?

that sounds like you are able to change that locally on your system. If
you did, did that fix the problem?
If not, I can build an experimental package for you to evaluate that
change. Unfortunately, I don't currently have a testing system with iPv6
connectivity...

Greetings, Torsten

Bug#821715: PHP 7.0 transition - PHP bindings removed and uploaded to DELAYED/2

[Torsten Landschoff]

On 06/16/2016 08:36 AM, Ondřej Surý wrote:
> Hi Torsten,
>
> attached are patches on top of latest unstable swig.
>
> TL;DR it's the php5-* in d/control that prevents the transition;
>
*blush* Dumb me. I was sure that the build depends had php-dev or
similiar (like libperl-dev, python-dev, ...).
No idea why I hardwired php5.

Greetings, Torsten

Bug#821715: PHP 7.0 transition - PHP bindings removed and uploaded to DELAYED/2

[Torsten Landschoff]

Hi Ondrej,

On 06/15/2016 10:24 AM, Ondřej Surý wrote:
> in an effort to finally finish PHP 7.0 transition started in April, I
> removed PHP bindings from swig as it doesn't look like swig will support
> PHP 7.0 anytime soon and also from the remaining packages using swig to
> build PHP bindings.
not sure if there is a misunderstanding: SWIG can generate bindings for
all supported languages (which does not currently include PHP7)
regardless of configure arguments.
AFAICT you just passed --without-php to configure in the new SWIG
release. The resulting binary will still allow creating PHP bindings
(albeit broken).

So I don't see how this helps in the transition - looks like I am
missing something!?

tracker.debian.org states
> This package is part of the ongoing testing transition known as php7.0
> . Please
> avoid uploads unrelated to this transition
which is why I uploaded 3.0.8 to experimental only to not disturb the
php7.0 transition hoping that upstream will update the PHP generation.
So, sorry. Just uploading swig dropping the php dependencies is
something I should have done to help I guess...

Greetings, Torsten

Bug#824972: RM: gmt-doc-ps -- ROM; superseded by PDF files in gmt-doc package

[Torsten Landschoff]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: ftp.debian.org
Severity: normal

Hi,

please remove the gmt-doc-ps package. It somehow was abandoned when GMT
maintainership was taken over by the Debian GIS Project.

It probably should never have existed as PDF is a much better format for
viewing and printing than Postscript.

Greetings, Torsten
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJXQPNYAAoJEB5flaeGO3x3n8UQAIFqz8W+mUXXfCGsYMSKWL/h
Qi6BCnEc5cDUmHLlD7SafpQYrbs57DLX+uRTJ2Irci9dwZntiZLKjZ3FW1aEF3zx
RLCW+4Cxr0JN/lMMUg2EZrOlhphtoQSlu+KpgQ20Ag4fGrqWoxHZdp7aXeLT6l8q
vJKIDxcXBsxviQxWx+cP8BFqXwgTIlTWqoDhf2l7GPCh0Jth8heuqIxKfU053IsM
Et5CkOd/b8DT4bia7zbMDbfdgLDg7G7Sh7FV39PQENLqBZaHaeG/Hz9FJM12+UuZ
5FZ2v8ATuRr7Fa+P1JvHEOpDrT/VgkOOVEzLQpfmi2mrf1IpD4WRKkiXIkX296Dr
hWa7QLv9oXg1+HtlyzU0uau+Xr3aWYQKIrFEpxGBN756mLH6wsy3eH0+i4BUEwax
241QGDnah2CvKUwUyBhrsfOdNi4lDi4oGRiq9DeRkpSs8yF0Huf7beGHYDIl3ugH
3NABCRTiKx3LrGAtHfwTTBpYF4uW7I5lAPmn/NHuKLqGx/YxNm1OyxFCbwFs+GEO
sxPXvctSW5JwFB9HKkyIRUl53UmESKWwP+QsrZmofH+14vO4e/LfjVKnqhD4v03X
c2aSPd+ONpszM10fyY+qcZ2P7sekBMHu3zjpNhLYYRRhoSDMx8Lr+8gxZ3JQ4kZd
GXOFN2GZjIkM8WmR8dW8
=cTty
-END PGP SIGNATURE-

Bug#786517: Remove swig 2.0 for Strech (python 3.5, octave 4.0 unsupported)

[Torsten Landschoff]

On 11/01/2015 07:08 AM, James McCoy wrote:
> On Sat, Oct 24, 2015 at 11:48:24PM +0200, Matthias Klose wrote:
>> As seen in #802906, this now becomes an RC issue, as Python 3.5 is a
>> supported Python version, and is not anymore supported by swig 2.0.
>>
>> Same for octave 4.0, and maybe other languages.
> Not everything that worked with swig2.0 works with swig3.0 (e.g.,
> subversion's swig bindings).  Why can't both be shipped?
I think they could be shipped but shouldn't.

For one swig 2.0 it not maintained upstream anymore.
The other thing is that swig 3.0 should be usable to build subversion,
so I have to get this fixed instead of using swig 2.0 as the way out.

Greetings, Torsten

Bug#807707: ddclient exit hook for dhclient breaks network configuration

[Torsten Landschoff]

Hi Doug,

On 12/11/2015 09:42 PM, Doug Kingston wrote:
> The Problem:  When I looked at the ddclient hook, I noticed it was
> calling exit(0),
> which exited the entire dhclient-script prematurely.  This is very
> bad, since none
> of the other exits was given an opportuntity to run.  Exits must not
> call exit!
> Returning of error status should be through the "exit_status" shell
> variable
> instead - as documented (poorly) in the manual page for
> dhclient-script(8).
Ouch, good catch. I wasn't aware of this and did not see anything wrong
when the dhclient script was added.
> I changed the ddclient exit hook to not call exit, but instead to
> return control
> to the dhclient-script as is the "API" for these hooks.
>
> What was the outcome of this action?
>
> The system now boots properly.  :-)
I am wondering how nobody else reported this.

Thanks for the report, I'll try to update the package soon.

Greetings, Torsten

Bug#799587: Same here...

[Torsten Landschoff]

Quoting Christian Ohm:

Googling those messages finally lead me to openjdk, and after upgrading 
to version 8 all those problems are gone.


I did the same and PyCharm can be used again without wrecking the whole 
system.


Greetings, Torsten

Bug#803369: swig: Please provide a symlink to the stable swig executable

[Torsten Landschoff]

Hi Gianfranco,

On 10/29/2015 04:03 PM, Gianfranco Costamagna wrote:
> > Indeed, that's how it is supposed to be. I have to check why it is
> > not in included anymore.
>
>
> because between 3.0.2 [1] and 3.0.7 [2] you took over the swig package
> from swig2.0, without adding the links file [3]
>
>
> [1] https://sources.debian.net/src/swig/3.0.2-1/debian/control/
> [2] https://sources.debian.net/src/swig/3.0.7-1/debian/control/
> [3] https://sources.debian.net/src/swig2.0/2.0.12-1/debian/links/
>
> HTH

Thanks, that's actually what I expected to find. I am sure that I did
copy the links control file to the new swig sources.
Sometimes the difference between a working and a broken package is
running svn add :-)

I just fixed it in Subversion and will release shortly, after checking
for more low-hanging fruit.

Greetings, Torsten





signature.asc
Description: OpenPGP digital signature

Bug#803369: swig: Please provide a symlink to the stable swig executable

[Torsten Landschoff]

On 10/29/2015 11:33 AM, Laurent Bigonville wrote:
> Shouldn't the swig package provides a symlink to the executable of the
> stable release?
>
> swig -> swig3.0
Indeed, that's how it is supposed to be. I have to check why it is not
in included anymore.

Thanks for the Feedback,

Torsten

Bug#790102: subversion fails to build with -Wdate-time in CPPFLAGS

[Torsten Landschoff]

Hi Mattia,

On 06/27/2015 05:59 AM, Mattia Rizzolo wrote:
 Hi subversion, unbound and swig maintainers,
 we in the Reproducible Builds effort use a non default dpkg which export
 -Wdate-time through dpkg-buildflags.
thanks for that great effort. I think this is urgently needed and I
often wonder if it is a good idea to install a given binary.
Most of the time I do not think much about using apt-get install
something and more about installers from github that are not packaged,
but this project really gives me a reason to trust Debian more. Thanks! :-)
 There are package that pass CPPFLAGS (for example) quite unchanged to swig.
I already noticed that before and was wondering if it is a good idea.
SWIG should mostly care for defines for the preprocessor and include
paths, but of course the easy way is to just pass everything on.
 Sadly swig does not recognize -Wdate-time and choke and fail on it badly, e.g.

 /usr/bin/swig -I. -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/python2.7 
 -I/usr/include/python2.7 -o pythonmod/interface.h -python 
 ./pythonmod/interface.i
 swig error : Unrecognized option -Wdate-time
 Use 'swig -help' for available options.
 Makefile:369: recipe for target 'pythonmod/interface.h' failed
 make[1]: *** [pythonmod/interface.h] Error 1
A link to the documentation would have been helpful:
https://gcc.gnu.org/gcc-4.9/changes.html#languages (changelog, seems not
to be in the docs yet).

warns when the |__DATE__|, |__TIME__|or |__TIMESTAMP__|macros are used.

Seriously, I did not even know about this macros. Wouldn't it make more
sense to just fill those from a common constant? I bet this will often
be used for library build information.
 a. swig stops failing so badly on unrecognized options. If you really want to
validate the options at least stop failing on unrecognized -W? Seems quite
logical to pass CPPFLAGS to swig to me, and as such sounds sane
IMO just skipping over all -W options in the swig command line parser
would be sane. I will take this upstream though as I'd rather not have
this as special Debian feature as it might make matters better for
Debian and worse for other distributions in case upstream relies on this
feature.
 b. people stop passing CPPFLAGS to swig. I've already saw a CPPFLAGS cleaner
on subversion's configure script. Please I don't want to see another
Given that the goal is to pass gcc (more generally c compiler options)
to swig I don't think this is a wrong as it sounds. The original reason
is that swig command line mixes options native to swig with C compiler
options which should IMHO really be passed separately. Something like
-W,l passing to the linker in gcc could be used to pass preprocessor
options to swig.
 Even if I do have preference I don't have a strong opinion on this, so if you
 agree this is not a bug in swig (which I could even accept, given that the
 accepted flags are well documented), I'll just clone+reassign this bug around.
I will reword this slightly (linking to this original text) and take it
upstream.

Greetings, Torsten

Bug#780320: nslcd group queries not working in jessie

[Torsten Landschoff]

Hi Arthur,

On 05/23/2015 06:03 PM, Arthur de Jong wrote:
 Could you provide the relevant bits of nslcd.conf (leave out any
 passwords) and output from nslcd -d when the error occurs? 
Bad news for me (and to a lesser extent to you): I just spent hours
trying to reproduce the problem with a small docker setup.
I could not reproduce the error using Debian squeeze as the server
(oldest for maximum incompatibility) and Debian squeeze, wheezy or
jessie as client. It just works...

Therefore I connected to the system that I upgraded to jessie on friday
only to notice that it is now fully working. My workaround was
ineffective in that puppet recreated the original nslcd.conf, but it was
just working.

Factoring in that the host machine of the ldap virtual machine had a
disk failure today it seems that this error was actually on the server
side. Probably slapd just stopped sending because of a slow disk (a disk
in the RAID had gone bad but was still active with read rates in the
two-digit kb/s range...).

So in our case this was not a problem with nslcd but just a symptom of
the breaking LDAP server.
 Also, can you provide more information on which LDAP server is used?
 Thanks, 
FWIW, the ldap server has Debian wheezy installed with the current
2.4.31-2 slapd package.

So sorry that I could not help with the original problem, our problem
was at a different spot.


For reference, I attached a tar archive of my Docker based testbed.
Maybe it is of use to somebody else... If you have docker installed and
permission to run it via sudo docker ..., just run the demo.sh script.
This will set up an LDAP server and client container and try to query
groups from the client container.

Greetings, Torsten



test-780320.tar.gz
Description: application/gzip

Bug#780320: nslcd group queries not working in jessie

[Torsten Landschoff]

Hi Arthur,

I just upgraded one of our local systems to jessie and hit this bug. 
This is the installed version of nslcd:


root@smithers:/etc# dpkg -s nslcd
Package: nslcd
Status: install ok installed
Priority: extra
Section: admin
Installed-Size: 423
Maintainer: Arthur de Jong adej...@debian.org
Architecture: amd64
Multi-Arch: foreign
Source: nss-pam-ldapd
Version: 0.9.4-3
Replaces: libnss-ldapd ( 0.7.0), nslcd-2
Provides: nslcd-2
[...]

Unfortunately, we are using group membership to restrict access to a 
number of services on that machine (namely the ability to control the 
KVM virtual machines).


I applied this work around:


If you are not using the member attribute in group searches you could
set
  map group member 
as a workaround in nslcd.conf to disable member attribute expansion
altogether.


However, this way all LDAP groups are now empty. The groups are still 
reported via getent group, but they don't have any members:



root@smithers:~# getent group|grep smithers
login.servers.smithers.login:*:10503:



torsten@horatio:~$ getent group|grep smithers
login.servers.smithers.login:*:10503:martin.muster,first.surname,torsten.landschoff,...


Any hint how this can be fixed? I'd be up to patch the source and build 
a new package for our local systems.


Greetings, Torsten


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

Bug#783559: swig2.0: Swig does not support alternatives

[Torsten Landschoff]

Hello Heinrich,

Am 2015-04-28 00:56, schrieb Heinrich Schuchardt:


Packages swig2.0 and swig3.0 provide alternative versions of swig.


No, the swig2.0 is an older version that must be removed. Now that 
jessie is out of the door, that will be the next step in SWIG packaging: 
drop swig2.0 and have swig point to swig3.0.


Installing any of these should provide an alternative in 
/etc/alternatives.


swig2.0 only made it into jessie because I expected that swig3.0 would 
(as a new major release) cause some problems. So far I did not see any 
and we are past the .0 release...


I agree that the current state is not as it should be. :-)

Greetings, Torsten


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

Bug#754935: I'd like to adopt the scala package

[Torsten Landschoff]

D'oh, forgot to sign my last email. Here it is again with a signature,
if anybody cares. :-)

~~~

I'd really like to adopt this package, given that I am currently
learning Scala and I think it would be a pity not to have a current
version in Debian.

I'll go and try to build the 2.11 version based on the last Debian
release by Mehdi.

Greetings, Torsten




signature.asc
Description: OpenPGP digital signature

Bug#754935: I'd like to adopt the scala package

[Torsten Landschoff]

I'd really like to adopt this package, given that I am currently
learning Scala and I think it would be a pity not to have a current
version in Debian.

I'll go and try to build the 2.11 version based on the last Debian
release by Mehdi.

Greetings, Torsten


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

Bug#768280: it breaks because of the out-of-tree build

[Torsten Landschoff]

It took a while, but I finally figured it out. Actually, it's not that 
patch that is broken but the build system.


Running the test suite after debian/rules build (with applied patch) 
gives us this:


torsten@defiant:~/debwork/swig/builddir$ make check-python-test-suite
checking python test-suite
checking python testcase argcargvtest (with run test)
/home/torsten/debwork/swig/Lib/swig.swg:425: Error: Syntax error in 
input(1).

[...]

This can be fixed as follows:

torsten@defiant:~/debwork/swig/builddir$ cp Source/CParse/parser.h  
../Source/CParse/

torsten@defiant:~/debwork/swig/builddir$ make
[...]
torsten@defiant:~/debwork/swig/builddir$ make check-python-test-suite
checking python test-suite
checking python testcase argcargvtest (with run test)
checking python testcase callback (with run test)
checking python testcase complextest (with run test)
[...]

Obviously, this is wrong. Interestingly, the build uses the right 
parser.c but the wrong parser.h.
I consider building the whole thing inline as this is not the first 
problem with the out of tree build. However, I don't think this is a 
good idea for a proposed-updates upload. So I'll try to find a way to 
fix this in the build system.


Greetings, Torsten


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

Bug#768280: Recipe to reproduce the crash

[Torsten Landschoff]

Hi Michael,

thanks for the report. I initially could not reproduce as this seems not 
to happen when generating Python bindings.


Here is a Dockerfile to check if this is fixed:

-
FROM debian:sid
MAINTAINER Torsten Landschoff tors...@debian.org

RUN adduser maint --disabled-password --gecos SWIG maintenance

RUN apt-get update
RUN apt-get -yy install swig3.0

ADD 
https://raw.githubusercontent.com/swig/swig/8bc38dc0070740d1a4b1ec522f80c7e292a74850/Examples/test-suite/nested_scope.i 
/home/maint/

RUN chown maint:maint /home/maint/*

USER maint
WORKDIR /home/maint

# For some reason this works fine
RUN swig3.0 -c++ -python nested_scope.i

# But using Tcl or Ruby as target language leads to the crash
RUN swig3.0 -version
RUN swig3.0 -c++ -ruby nested_scope.i
RUN swig3.0 -c++ -tcl nested_scope.i

ENTRYPOINT [/bin/bash, -i]
-

Running this through docker build, I get the following output:

torsten@horatio:~/debwork/swig-768280$ sudo docker build .
[...]
Removing intermediate container 0751a6438b2d
Step 10 : RUN swig3.0 -version
 --- Running in 5c17530272ae

SWIG Version 3.0.2

Compiled with g++ [x86_64-unknown-linux-gnu]

Configured options: +pcre

Please see http://www.swig.org for reporting bugs and further 
information

 --- 75497219552a
Removing intermediate container 5c17530272ae
Step 11 : RUN swig3.0 -c++ -ruby nested_scope.i
 --- Running in 9d98770ffe45
Segmentation fault (core dumped)
INFO[0004] The command [/bin/sh -c swig3.0 -c++ -ruby nested_scope.i] 
returned a non-zero code: 139


So I can confirm this happens when generating Ruby or Tcl bindings. I 
did not check others apart from Python (which does not crash).


So far about that, now I have to get access to Subversion again. I moved 
my ssh key to a hardware token and currently my setup refuses to use it 
for SSH login.


Greetings, Torsten


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

Bug#768280: Completely broken after applying the patch...

[Torsten Landschoff]

I just applied the patch from upstream. This makes matters much worse, 
all tests are immediately failing:


torsten@2c4e58b051c5:~/swig/swig3.0/builddir$ make 
check-python-test-suite

checking python test-suite
checking python testcase argcargvtest (with run test)
/home/torsten/swig/swig3.0/Lib/swig.swg:425: Error: Syntax error in 
input(1).

../../../Examples/Makefile:337: recipe for target 'python_cpp' failed
make[2]: *** [python_cpp] Error 1
Makefile:111: recipe for target 'argcargvtest.cpptest' failed
make[1]: *** [argcargvtest.cpptest] Error 2
checking python testcase callback (with run test)
/home/torsten/swig/swig3.0/Lib/swig.swg:425: Error: Syntax error in 
input(1).

../../../Examples/Makefile:337: recipe for target 'python_cpp' failed
make[2]: *** [python_cpp] Error 1
Makefile:111: recipe for target 'callback.cpptest' failed
make[1]: *** [callback.cpptest] Error 2

Seems like the patch has some dependency on another change. As the patch 
is not quite obvious to me, I don't think I can fix this today.


Greetings, Torsten


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

Bug#704467: Updated patch

[Torsten Landschoff]

Am 2015-01-18 14:07, schrieb Michael Meskes:
Here's an updated patch against the current version. Torsten is there 
any

reason why this is not applied?


No specific reason. Sorry, this should be fixed for a long time.
I just applied the patch to a local git repository only to notice that I 
can't push it to git.debian.org because I can't access my private key as 
my desktop system is offline due to renovation in our flat. :-(


Let me see if I can rebuild my ccid drivers to work with my card reader 
again. I unfortunately bought a reader that needs this patch:


http://archives.neohapsis.com/archives/dev/muscle/2010-q1/0074.html

Greetings, Torsten


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

Bug#721521: Short notice from a former gsfonts maintainer

[Torsten Landschoff]

Hi Fabian,

just a quick note to attach to this ticket. I am happy to have gsfonts 
replaced, but I am not the maintainer anymore so I guess it is not up to 
me to decide this. The fun with gsfonts is that it feels like warez in 
that it is not even easy to find a download location. I guess that is 
intentional, so that they can still sell those fonts. :-)


I am mostly writing to suggest that you contact the current maintainer 
Masayuki Hatta directly via the email address listed in the package. 
Your original mail had a spelling error for packages.debian.org but I am 
also unsure if that is a reliable way to contact a maintainer. I did not 
see any email of this conversation (but I guess the @packages alias only 
forwards to the official maintainer).


Looking forward to find out about the metrics...

Greetings, Torsten


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

Bug#775016: ITP: hovercraft -- impress.js presentations by reStructuredText

[Torsten Landschoff]

Hi Daniel,

Am 2015-01-10 03:54, schrieb Daniel Stender:

Package: wnpp
Severity: wishlist
Owner: Daniel Stender deb...@danielstender.com

* Package name: hovercraft
  Version : 2.0b1
  Upstream Author : Lennart Regebro rege...@gmail.com
* URL : https://github.com/regebro/hovercraft


Wow! That looks like a tool that I was searching for. Thanks for posting 
it here and looking forward for the package :-)


Greetings, Torsten


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

Bug#751159: Inclusion of German debconf template translation possible?

[Torsten Landschoff]

Am 2014-10-06 19:47, schrieb Helge Kreutzmann:


Any ETA for an upload? Or should I arrange for an NMU?


I did the upload but it was rejected for invalid orig.tar.gz checksum. 
Hard to say when I will have time to check into this as our daughter is 
currently sick and we hardly have the time for the basics.


Greetings, Torsten


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

Bug#762984: Another affected user

[Torsten Landschoff]

Just to add another data point, I ran into the same problem.

Booting stops with


ALERT! /dev/mapper/vgsys-sid--usr does not exist. Dropping to a shell.


In busybox I can fix the problem by activating the volume groups:


(initramfs) vgchange -a y
  30 logical volume(s) in volumgroup vgsys now active


Hitting Ctrl-D afterwards resumes the boot. For some odd reason, it 
notices that /usr has been mounted 922 times without being checked and 
forces the fsck. I never checked (nor do I really care, /usr can be 
recovered from ftp.debian.org).


The version of initramfs-tools on my system is 0.117 as well. I would 
consider this as serious since that system booted just fine since its 
installation in 2009, not counting the systemd transition which made it 
unbootable two times.



I attached the trace.log from running mkinitramfs.

Greetings, Torsten


trace.log.xz
Description: Binary data

Bug#751159: Inclusion of German debconf template translation possible?

[Torsten Landschoff]

On 09/15/2014 12:18 PM, Helge Kreutzmann wrote:
 a German translation of the Debconf template was prepared and filed as
 751159. Would it be possible to do a maintainer upload targetting
 jessi with the translation included?
Sure.
 If not, would it be ok for an NMU including this template translation
 (and possibly others)?

That's also fine with me.
I just pulled all the translations from the BTS and updated the source.
As last step I used debconf-updatepo, which seems to notice a lot of
fuzzy translations.

Seems like I often missed the podebconf-report-po step while updating
debconf templates. :-(

I will clean up the mess for the german translation tomorrow morning.
Not sure I reporting the po files is a good idea, because the templates
are in dire need of some adjustments.

Greetings, Torsten



signature.asc
Description: OpenPGP digital signature

Bug#761505: ddclient: Using /etc/init.d/ddclient restart makes ddclient run multiple instances

[Torsten Landschoff]

Hi Christoph,

On 09/14/2014 02:37 PM, Christoph Haas wrote:
 apparently when restarting ddclient after a configuration change
 using /etc/init.d/ddclient restart the old process is not killed.

 Example:

 root@torf:/etc/shorewall# ps ax | grep ddclient - sleeping
  8700 pts/1S  0:00 ddclient - sleeping for 50 seconds
 root@torf:/etc/shorewall# /etc/init.d/ddclient restart  
 [ ok ] Restarting Dynamic DNS service update utility: ddclient.
 root@torf:/etc/shorewall# ps ax | grep ddclient - sleeping
  8700 pts/1S  0:00 ddclient - sleeping for 40 seconds
  9182 pts/1S  0:00 ddclient - sleeping for 60 seconds
Good report, thanks. I think this is a duplicate of the bug here:

https://bugs.debian.org/652298

If you agree I would merge the two bugs. The problem was fixed for
Debian unstable leading up to the jessie release.

Greetings, Torsten


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

Bug#728096: [buildd-tools-devel] Bug#728096: schroot fails if shm tmpfs is mounted on /dev/shm

[Torsten Landschoff]

Hi Roger,

I am running into the same problem here, trying to setup a wheezy build
environment.
 Note that the -v option will make schroot log all mount operations
 during session creation, and umount operations during cleanup.  I'd
 recommend running with this to debug what's going on.
Here you go:

torsten@pulsar:~$ schroot -v -c wheezy-amd64
I: Executing ‘00check setup-start ok’
I: 00check: STAGE=setup-start
I: 00check: STATUS=ok
I: 00check: AUTH_GID=1000
I: 00check: AUTH_HOME=/home/torsten
I: 00check: AUTH_RGID=1000
I: 00check: AUTH_RGROUP=torsten
I: 00check: AUTH_RUID=1000
I: 00check: AUTH_RUSER=torsten
I: 00check: AUTH_SHELL=/bin/bash
I: 00check: AUTH_UID=1000
I: 00check: AUTH_USER=torsten
I: 00check: CHROOT_ALIAS=wheezy-amd64
I: 00check: CHROOT_DESCRIPTION=wheezy-amd64 (session chroot)
I: 00check: CHROOT_DEVICE=/dev/vgsys/wheezy_amd64_chroot
I: 00check:
CHROOT_LVM_SNAPSHOT_DEVICE=/dev/vgsys/wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315
I: 00check:
CHROOT_LVM_SNAPSHOT_NAME=wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315
I: 00check: CHROOT_LVM_SNAPSHOT_OPTIONS=--size 4G
I: 00check:
CHROOT_MOUNT_DEVICE=/dev/vgsys/wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315
I: 00check:
CHROOT_MOUNT_LOCATION=/var/lib/schroot/mount/wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315
I: 00check: CHROOT_MOUNT_OPTIONS=-o noatime
I: 00check: CHROOT_NAME=wheezy-amd64
I: 00check:
CHROOT_PATH=/var/lib/schroot/mount/wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315
I: 00check: CHROOT_PROFILE=sbuild
I: 00check: CHROOT_PROFILE_DIR=/etc/schroot/sbuild
I: 00check: CHROOT_SESSION_CLONE=false
I: 00check: CHROOT_SESSION_CREATE=false
I: 00check: CHROOT_SESSION_PURGE=true
I: 00check: CHROOT_TYPE=lvm-snapshot
I: 00check: DATA_DIR=/usr/share/schroot
I: 00check: LIBEXEC_DIR=/usr/lib/x86_64-linux-gnu/schroot
I: 00check: MOUNT_DIR=/var/lib/schroot/mount
I: 00check:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
I: 00check: PID=18402
I: 00check: PLATFORM=linux
I: 00check: PWD=/
I: 00check: SESSION_ID=wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315
I: 00check: SETUP_CONFIG=/etc/schroot/sbuild/config
I: 00check: SETUP_COPYFILES=/etc/schroot/sbuild/copyfiles
I: 00check: SETUP_DATA_DIR=/usr/share/schroot/setup
I: 00check: SETUP_FSTAB=/etc/schroot/sbuild/fstab
I: 00check: SETUP_NSSDATABASES=/etc/schroot/sbuild/nssdatabases
I: 00check: SYSCONF_DIR=/etc/schroot
I: 00check: VERBOSE=verbose
I: Executing ‘05btrfs setup-start ok’
I: Executing ‘05file setup-start ok’
I: Executing ‘05lvm setup-start ok’
E: 05lvm: Setting logging type to disk
E: 05lvm: Setting chunksize to 4.00 KiB.
E: 05lvm: Finding volume group vgsys
E: 05lvm: Archiving volume group vgsys metadata (seqno 290).
E: 05lvm: Creating logical volume
wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315
E: 05lvm: Creating volume group backup /etc/lvm/backup/vgsys
(seqno 291).
E: 05lvm: activation/volume_list configuration setting not defined:
Checking only host tags for
vgsys/wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315
E: 05lvm: Creating
vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315
E: 05lvm: Loading
vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315 table (253:30)
E: 05lvm: Resuming
vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315 (253:30)
E: 05lvm: Initializing 4.00 KiB of logical volume
vgsys/wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315 with value 0.
E: 05lvm: Creating logical volume snapshot0
E: 05lvm: Creating vgsys-wheezy_amd64_chroot-real
E: 05lvm: Loading vgsys-wheezy_amd64_chroot-real table (253:31)
E: 05lvm: Loading vgsys-wheezy_amd64_chroot table (253:29)
E: 05lvm: Creating
vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315-cow
E: 05lvm: Loading
vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315-cow table
(253:32)
E: 05lvm: Resuming
vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315-cow (253:32)
E: 05lvm: Loading
vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315 table (253:30)
E: 05lvm: Suspending vgsys-wheezy_amd64_chroot (253:29) with
filesystem sync with device flush
E: 05lvm: Suspending vgsys-wheezy_amd64_chroot-real (253:31) with
filesystem sync with device flush
E: 05lvm: Loading
vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315-cow table
(253:32)
E: 05lvm: Suppressed
vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315-cow
(253:32) identical table reload.
E: 05lvm: Resuming vgsys-wheezy_amd64_chroot-real (253:31)
E: 05lvm: Resuming
vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315 (253:30)
E: 05lvm: Resuming vgsys-wheezy_amd64_chroot (253:29)
E: 05lvm: Creating volume group backup /etc/lvm/backup/vgsys
(seqno 292).
I: 05lvm:   Logical volume
wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315 created
I: Executing ‘05union setup-start ok’
I: Executing ‘10mount setup-start ok’
I: 10mount: Mounting

Bug#752938: swig2.0: drop the unused default-jdk build dependency

[Torsten Landschoff]

Hi Peter,

Am 2014-06-28 01:09, schrieb Peter Pentchev:

To my great surprise, when I tried building the swig2.0 packages with
B-D: default-jdk removed and with_java set to something else in the
rules file, it turned out that SWIG builds just fine, and that there 
are

absolutely no differences, none at all, in the generated binary
packages.  As it happens, the SWIG configure script checks for Java, 
but
then nothing ever uses the values, nothing builds anything 
Java-related,

nothing even writes the values to installed files.


Most of the build dependencies of SWIG are only required for running the 
test suite. Unfortunately, the configure script configures all stuff for 
the test suite as well and there is no way to run the test suite out of 
the source tree.


It would make sense to drop most of the build dependencies for the 
target languages, including python, ruby, guile, chicken, racket, etc.


To have the test suite run automatically it would be preferable to use 
adt-run with only the test-suite, which is included in the swig-examples 
package. However, this requires changes to the upstream build which I 
did not get around to do so far.


Let's see when I can get some Debian time...

Greetings, Torsten


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

Bug#750621: swig3.0 required

[Torsten Landschoff]

Am 2014-06-05 06:10, schrieb Soeren Sonnenburg:

Package: swig
Version: 2.0.7-3
Severity: serious

Please package swig3.0.2 ASAP.


See https://ftp-master.debian.org/new/swig_3.0.0-0.html

Greetings, Torsten


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

Bug#690568: Duplicate / related bugs

[Torsten Landschoff]

On 03/03/2014 01:20 AM, Trevor Nonce wrote:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708036 is duplicate
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734661 fixes #690568.

Thanks. Looks like it is really time to update to 3.8.2

Greetings, Torsten

Bug#680065: Can not reproduce

[Torsten Landschoff]

Hi Frank,

thanks for the good bug report. Sorry for letting it languish for the
long while.

I tried to reproduce the issue with the configuration you posted (I have
no account at noip.com, but it looks like it fails during the connect
and before authentication anyway).
With ddclient 3.8.1 the problem does not seem to exist:

UPDATE:   updating rubbish.no-ip.org
here...my-user -- geheim
CONNECT:  no-ip.com
CONNECTED:  using SSL
SENDING:  GET
/nic/update?system=noiphostname=rubbish.no-ip.orgmyip=37.211.15.182
HTTP/1.0
SENDING:   Host: no-ip.com
SENDING:   Authorization: Basic bXktdXNlcjpnZWhlaW0=
SENDING:   User-Agent: ddclient/3.8.1
SENDING:   Connection: close
SENDING:  
RECEIVE:  HTTP/1.1 301 Moved Permanently

Maybe this was an issue in the perl ssl library?! Can you still
reproduce this problem?

In wheezy it seems to work just as fine. I stripped your configuration a
bit and used this ddclient.conf:

mail=root
mail-failure=root
use=web, web=checkip.dyndns.com, web-skip='IP Address'

ssl=yes
protocol=noip
server=no-ip.com
login=my-user
password=geheim
rubbish.no-ip.org


Greetings, Torsten


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

Bug#488107: Still no support for SMC7904bra2

[Torsten Landschoff]

FYI, there is still no support for your router in ddclient. I wonder if
anybody still cares about it.

With a bit of feedback I could add support, but I don't have the router
model and don't want to spend the time if nobody needs it anyway.

Greetings, Torsten


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

Bug#640014: Fixed in git repository

[Torsten Landschoff]

tags 640014 + pending
thanks

For your information, I just committed a patch to the repository to verify the 
password:

http://anonscm.debian.org/gitweb/?p=collab-maint/ddclient.git;a=commit;h=38e40ad683fd278e7d7865cdeff700fc6608ea49

Greetings, Torsten


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

Bug#730570: swig: -includeall options fails to parse /usr/include/bits/wchar.h

[Torsten Landschoff]

Hi,

This must be the least verbose bug report I have ever seen.

On 11/26/2013 05:44 PM, Stephen Crowley wrote:
 Language subdirectory: java
 Search paths:
./
   /usr/include/
  ./swig_lib/java/
   /usr/share/swig2.0/java/
  ./swig_lib/
 /usr/share/swig2.0/
 Preprocessing...
 /usr/include/bits/wchar.h:35: Warning 202: Could not
 evaluate expression 'L'\0' - 1  0'
 /usr/include/bits/wchar.h:35: Warning 202: Error: 'Syntax error:
 expected operator'
 /usr/include/bits/wchar.h:43: Warning 202: Could not evaluate
 expression 'L'\0' - 1  0'
 /usr/include/bits/wchar.h:43: Warning 202: Error: 'Syntax error:
 expected operator'
 retroshare/rsdht.h:30: Error: Unable to find 'string'
 retroshare/rsdht.h:31: Error: Unable to find 'list'

I wonder why anybody would want to use the -includeall option. This only
leads to wrapping all stuff that accidently get included by the library
one wants to wrap.

Anyway, I tried to reproduce this and it seems to work here:

(sid)torsten@sharokan:~/debbug_730570$ cat wchar.i
%module wchar

#include bits/wchar.h

(sid)torsten@sharokan:~/debbug_730570$ swig2.0 -java -v -includeall
-I/usr/include/x86_64-linux-gnu wchar.i
Language subdirectory: java
Search paths:
   ./
   /usr/include/x86_64-linux-gnu/
   ./swig_lib/java/
   /usr/share/swig2.0/java/
   ./swig_lib/
   /usr/share/swig2.0/
Preprocessing...
Starting language-specific parse...
Processing types...
C++ analysis...
Generating wrappers...

At least it does not fail with a syntax error. The wrapper does include
neither __WCHAR_MAX nor __WCHAR_MIN, which are defined around the
wchar.h lines causing the error for you:

(sid)torsten@sharokan:~/debbug_730570$ sed -n -e 35,36p -e 43,44p
/usr/include/x86_64-linux-gnu/bits/wchar.h
#elif L'\0' - 1  0
# define __WCHAR_MAX(0xu + L'\0')
#elif L'\0' - 1  0
# define __WCHAR_MIN(L'\0' + 0)

So it seems like SWIG does not support wide character constants. I tried
to SWIG the following definitions:

#define WIDE_CHAR  L'T'
#define WIDE_STR   LHello there

They generate nothing...
There is an upstream bug about non-support of wide character strings
here: http://sourceforge.net/p/swig/bugs/971/

Greetings, Torsten


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

Bug#703119: Isn't this fixed already?

[Torsten Landschoff]

Looking at bugs.debian.org I see avatar images now.

However, I have no idea where those are pulled from. Where is this 
documented?


Cheers, Torsten


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

Bug#627972: ddclient: Ping!

[Torsten Landschoff]

On 06/22/2012 12:49 PM, Reuben Thomas wrote:

Package: ddclient
Followup-For: Bug #627972

ddclient 3.8.1 has been out for nearly a year now. Is there some
problem with packaging it? I would love to be able to use ddclient
with afraid.org again!

Thanks for the reminder. I'll see if I can find the time to package it 
this weekend.


Greetings, Torsten




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

Bug#675911: swig2.0: Wrong configuration for Java

[Torsten Landschoff]

Hi Mathieu,

On 06/12/2012 08:23 AM, Mathieu Malaterre wrote:
 On Mon, Jun 11, 2012 at 10:00 PM, Torsten Landschoff
 t.landsch...@gmx.net wrote:
 On 06/04/2012 08:26 AM, Mathieu Malaterre wrote:
 swig2.0 should be configured with default Java (default-jdk package). It
 currently uses gcj-jdk
 You are right. However, I fail to see how this renders the package unusable
 as the SWIG generated code should be portable among different Java version.

 I think severity grave is a bit exaggerated here.
 I thought this was a clear requirement, re-reading it:

 http://www.debian.org/doc/packaging-manuals/java-policy/c208.html

 Java packages should be built with default-jdk if possible.

 So there is a should and if possible, how do you understand the statement ?
Does ist matter? Quoting http://www.debian.org/Bugs/Developer#severities:

|grave|
makes the package in question unusable or mostly so, or causes data
loss, or introduces a security hole allowing access to the accounts
of users who use the package. I don't see how this applies to this bug.

I did not consider java-policy to apply to SWIG. Maybe I should. But
quoting http://www.debian.org/doc/packaging-manuals/java-policy/:

The policy covers java virtual machines, java compilers, java
programs and java libraries.

Anyway, the bug should be fixed now.

Greetings, Torsten

Bug#675911: swig2.0: Wrong configuration for Java

[Torsten Landschoff]

On 06/04/2012 08:26 AM, Mathieu Malaterre wrote:

swig2.0 should be configured with default Java (default-jdk package). It 
currently uses gcj-jdk
You are right. However, I fail to see how this renders the package 
unusable as the SWIG generated code should be portable among different 
Java version.


I think severity grave is a bit exaggerated here.

Greetings, Torsten




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

Bug#672035: [Swig-devel] Debian Bug #672035: SWIG fails on pairstring, string

[Torsten Landschoff]

On 05/29/2012 08:41 AM, William S Fulton wrote:


There are some problems with 'using' statements in SWIG and so the
commit you highlighted might have exposed these problems. I'll take a
closer look later, but in the meantime, could you please consider the
following workaround for ZNC where you explicitly qualify std::pair.

%includestl.i
%template(StrPair) std::pairstd::string, std::string;

The attached patch does just that and fixes the build for me. I 
forwarded the patch to the upstream issue as well.


Please consider applying until SWIG gets fixed.

Greetings, Torsten

Description: Qualify access to pair with std:: for SWIG.
 SWIG seems to have problems with access to imported C++ namespaces.
 William S. Fulton suggested to work around this by qualifying std::pair
 in this email:
 http://article.gmane.org/gmane.comp.programming.swig.devel/21772
 .
 This patch does just that and seems to fix building with SWIG 2.0.7.
 In the long run this should of course be fixed in SWIG.
Author: Torsten Landschoff tors...@debian.org
Bug-Debian: http://bugs.debian.org/672035
Forwarded: https://github.com/znc/znc/issues/174

--- znc-0.206.orig/modules/modpython/modpython.i
+++ znc-0.206/modules/modpython/modpython.i
@@ -174,10 +174,10 @@ public:
 
 /* Web */
 
-%template(StrPair) pairCString, CString;
-%template(VPair) vectorpairCString, CString ;
-typedef vectorpairCString, CString  VPair;
-%template(VWebSubPages) vectorTWebSubPage;
+%template(StrPair) std::pairCString, CString;
+%template(VPair) std::vectorstd::pairCString, CString ;
+typedef std::vectorstd::pairCString, CString  VPair;
+%template(VWebSubPages) std::vectorTWebSubPage;
 
 %inline %{
 	void VPair_Add2Str_(VPair* self, const CString a, const CString b) {

Bug#672035: git bisect results

[Torsten Landschoff]

Hi all,

I used the test case provided by Alexey Sokolov to run git bisect on 
this problem. The results are:


/home/torsten/mirror/swig-svn.fetch/Lib/std/std_pair.i:31: Error: Can't copy typemap 
(directorout) std::pair  std::string,std::string  = std::pair  
std::string,std::string  DIRECTOROUT
/home/torsten/mirror/swig-svn.fetch/Lib/std/std_pair.i:31: Error: Can't copy typemap (in) 
std::pair  std::string,std::string  *INPUT = std::pair  
std::string,std::string  *INOUT
/home/torsten/mirror/swig-svn.fetch/Lib/std/std_pair.i:31: Error: Can't copy typemap (in) 
std::pair  std::string,std::string  INPUT = std::pair  std::string,std::string 
 INOUT
/home/torsten/mirror/swig-svn.fetch/Lib/std/std_pair.i:31: Error: Can't copy typemap 
(typecheck) std::pair  std::string,std::string  *INPUT = std::pair  
std::string,std::string  *INOUT
/home/torsten/mirror/swig-svn.fetch/Lib/std/std_pair.i:31: Error: Can't copy typemap (typecheck) 
std::pair  std::string,std::string  INPUT = std::pair  std::string,std::string 
 INOUT
/home/torsten/mirror/swig-svn.fetch/Lib/std/std_pair.i:31: Error: Can't copy typemap 
(argout) std::pair  std::string,std::string  *OUTPUT = std::pair  
std::string,std::string  *INOUT
/home/torsten/mirror/swig-svn.fetch/Lib/std/std_pair.i:31: Error: Can't copy typemap (argout) 
std::pair  std::string,std::string  OUTPUT = std::pair  
std::string,std::string  INOUT
/home/torsten/mirror/swig-svn.fetch/Lib/std/std_pair.i:31: Error: Can't copy typemap 
(typecheck) std::pair  std::string,std::string  *INPUT = std::pair  
std::string,std::string  *INOUT
/home/torsten/mirror/swig-svn.fetch/Lib/std/std_pair.i:31: Error: Can't copy typemap (typecheck) 
std::pair  std::string,std::string  INPUT = std::pair  std::string,std::string 
 INOUT
/home/torsten/mirror/swig-svn.fetch/Lib/std/std_pair.i:31: Error: Can't copy typemap 
(freearg) std::pair  std::string,std::string  *INPUT = std::pair  
std::string,std::string  *INOUT
/home/torsten/mirror/swig-svn.fetch/Lib/std/std_pair.i:31: Error: Can't copy typemap (freearg) 
std::pair  std::string,std::string  INPUT = std::pair  std::string,std::string 
 INOUT
0e98f757746c34cea62f4b291be9ce7214ab37b9 is the first bad commit
commit 0e98f757746c34cea62f4b291be9ce7214ab37b9
Author: wsfultonwsfulton@626c5289-ae23-0410-ae9c-e8d60b6d4f22
Date:   Tue Jul 26 19:34:23 2011 +

Fix scoping of forward class declarations nested within a class (for C++). 
Also fix %template and resolution of template parameters that are typedefs.

git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@12764 
626c5289-ae23-0410-ae9c-e8d60b6d4f22

:100644 100644 f7bdb9dae4505decb6053344d2a33fc7f27f7976 
d6bbc6ba5791992949d83eb23f98aec54c127f9a M  CHANGES.current
:04 04 7e90d6631984536e7c626044128f91c156bc7ada 
fd70ba118f16a5de032ec51d6174a8e4d637cba4 M  Examples
:04 04 34ebbc6c025e308e3fc0e81913eb9f61407dd8c6 
526b2ea7ead4326f9fcbbba1b3f0ebefa6e1cd0c M  Source
bisect run success


So this problem was introduced in Subversion commit 12764. Hopefully 
this is of some help to fix this problem.


Greetings, Torsten




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

Bug#672035: [PATCH] Addition to test suite

[Torsten Landschoff]

Here is a patch that adds Alexeys test to the test suite.

I am unsure though if this is really the issue that building znc runs 
into. It seems to happen only with using std::pair, which the znc 
sources do not do.


From dec5e7f1ed1cba136ed534ca82a7bf947351d089 Mon Sep 17 00:00:00 2001
From: Torsten Landschoff tors...@landschoff.net
Date: Tue, 29 May 2012 06:40:21 +0200
Subject: [PATCH] Added a test case checking that pairstring, string can be swigged.

---
 Examples/test-suite/common.mk |1 +
 Examples/test-suite/string_pair.i |9 +
 2 files changed, 10 insertions(+), 0 deletions(-)
 create mode 100644 Examples/test-suite/string_pair.i

diff --git a/Examples/test-suite/common.mk b/Examples/test-suite/common.mk
index 0f80230..9028408 100644
--- a/Examples/test-suite/common.mk
+++ b/Examples/test-suite/common.mk
@@ -325,6 +325,7 @@ CPP_TEST_CASES += \
 	static_array_member \
 	static_const_member \
 	static_const_member_2 \
+	string_pair \
 	struct_initialization_cpp \
 	struct_value \
 	symbol_clash \
diff --git a/Examples/test-suite/string_pair.i b/Examples/test-suite/string_pair.i
new file mode 100644
index 000..1c1f3f7
--- /dev/null
+++ b/Examples/test-suite/string_pair.i
@@ -0,0 +1,9 @@
+%module string_pair
+
+%include stl.i
+%{
+using std::pair;
+%}
+using std::pair;
+
+%template(StrPair) pairstd::string, std::string;
-- 
1.7.1.rc2.dirty

Bug#674263: swig2.0: swig 2.0.7 for wheezy

[Torsten Landschoff]

On 05/24/2012 09:23 AM, Mathieu Malaterre wrote:

Package: swig2.0
Version: 2.0.6-1
Severity: important


Due to the recent regression in 2.0.5 and 2.0.6, I suggest that 2.0.7 be 
available for Wheezy.

ref:
http://sourceforge.net/mailarchive/message.php?msg_id=29305946

...
That very much depends on your code. I wouldn't suggest anything else
other than rebuild everything. Also there is another serious typemap bug
in 2.0.5 which will be addressed in 2.0.7. I hope that Debian upgrade
directly to 2.0.7 which will be released by end of week.

Sorry, I just uploaded 2.0.6-1 which I forgot to upload after building. 
But I will upgrade the package to 2.0.7 as soon as it comes out.


Greetings, Torsten




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

Bug#672035: Is this really a bug in SWIG?

[Torsten Landschoff]

Hello *,

I looked at this bug because I want to make sure that a fixed SWIG is 
available before freeze.


However, for me this does not look like a direct bug in swig. The 
offending code is in the file modules/modpython/cstring.i which begins 
like this:


/*
   SWIG-generated sources are used here.
*/

//
// String
//

%{
#includestring
%}

%feature(naturalvar) CString;
class CString;

/*@SWIG:/usr/share/swig1.3/typemaps/std_strings.swg,74,%typemaps_std_string@*/

/*@SWIG:/usr/share/swig1.3/typemaps/std_strings.swg,4,%std_string_asptr@*/
%fragment(SWIG_ AsPtr _ 
{CString},header,fragment=SWIG_AsCharPtrAndSize) {
...


The actually seems to cause the error when trying to translate the 
following code in modpython.i:


%template(StrPair) pairCString, CString;
%template(VPair) vectorpairCString, CString  ;



I'll try to find a minimal example which causes this.

Greetings, Torsten




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

Bug#656478: Fixed with swig 2.0.4-5

[Torsten Landschoff]

I just checked that my upload of swig 2.0.4-5 fixes bug #656478.

Building with 2.0.4-4 reproduces the error mentioned in this bug.
Updating swig to 2.0.4-5 made the error go away and wikidiff2 builds 
fine again.






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

Bug#657091: invalid conversion breaks PHP 5.4 support

[Torsten Landschoff]

Hi Lior,

On 01/23/2012 11:59 PM, Lior Kaplan wrote:


Swig has an invalid conversion from 'const char*' to 'char*' problem 
with PHP code built with PHP 5.4 (at experimental at the moment).


Upstream already fixed that here:
http://swig.svn.sourceforge.net/viewvc/swig?view=revisionrevision=12710 
http://swig.svn.sourceforge.net/viewvc/swig?view=revisionrevision=12710


Please consider cherry picking this patch to let the PHP team to work 
on PHP 5.4 support.
I already did a local build to verify the fix actually works, and also 
done here: https://bugzilla.redhat.com/show_bug.cgi?id=770696


I'm willing to NMU if needed.

No need, I just uploaded swig 2.0.4-5 with your patch. Thank you!

Greetings, Torsten




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

Bug#653054: ddclient failed blocking on read

[Torsten Landschoff]

Package: ddclient
Version: 3.8.0-11.3
Severity: normal

ddclient failed me the first time. After I got to the machine, I 
extracted the following from the logs:


daemon.log.3.gz:Nov 27 09:09:17 pluto ddclient[17042]: FAILED:   
updating xxx.dyndns.org: Could not connect to members.dyndns.org.
daemon.log.3.gz:Nov 27 09:14:17 pluto ddclient[17042]: WARNING:  file 
/var/cache/ddclient/ddclient.cache, line 3: Invalid Value for keyword 
'ip' = ''
daemon.log.3.gz:Nov 27 09:14:17 pluto ddclient[17042]: SUCCESS:  
updating .dyndns.org: good: IP address set to 93.218.179.95
daemon.log.3.gz:Nov 28 09:05:57 pluto ddclient[17042]: SUCCESS:  
updating .dyndns.org: good: IP address set to 93.218.164.209
daemon.log.3.gz:Nov 29 03:07:22 pluto ddclient[17042]: WARNING:  cannot 
connect to checkip.dyndns.com:80 socket: IO::Socket::INET: Bad hostname 
'checkip.dyndns.com'
daemon.log.3.gz:Nov 29 03:12:42 pluto ddclient[17042]: WARNING:  cannot 
connect to checkip.dyndns.com:80 socket: IO::Socket::INET: Bad hostname 
'checkip.dyndns.com'
daemon.log.3.gz:Nov 29 03:18:02 pluto ddclient[17042]: WARNING:  cannot 
connect to checkip.dyndns.com:80 socket: IO::Socket::INET: Bad hostname 
'checkip.dyndns.com'
daemon.log.3.gz:Nov 29 03:23:22 pluto ddclient[17042]: WARNING:  cannot 
connect to checkip.dyndns.com:80 socket: IO::Socket::INET: Bad hostname 
'checkip.dyndns.com'
daemon.log.3.gz:Nov 29 04:59:07 pluto ddclient[17042]: FAILED:   
updating .dyndns.org: Could not connect to members.dyndns.org.
daemon.log.3.gz:Nov 29 05:04:07 pluto ddclient[17042]: WARNING:  file 
/var/cache/ddclient/ddclient.cache, line 3: Invalid Value for keyword 
'ip' = ''
daemon.log.3.gz:Nov 29 05:04:07 pluto ddclient[17042]: SUCCESS:  
updating .dyndns.org: good: IP address set to 93.218.159.87
daemon.log.3.gz:Nov 30 04:56:33 pluto ddclient[17042]: WARNING:  cannot 
connect to checkip.dyndns.com:80 socket: IO::Socket::INET: connect: 
Connection timed out
daemon.log.3.gz:Nov 30 05:01:33 pluto ddclient[17042]: FAILED:   
updating .dyndns.org: Could not connect to members.dyndns.org.
daemon.log.3.gz:Nov 30 05:06:33 pluto ddclient[17042]: WARNING:  file 
/var/cache/ddclient/ddclient.cache, line 3: Invalid Value for keyword 
'ip' = ''
daemon.log.3.gz:Nov 30 05:06:34 pluto ddclient[17042]: WARNING:  
skipping update of .dyndns.org from nothing to 87.157.39.126.
daemon.log.3.gz:Nov 30 05:06:34 pluto ddclient[17042]: WARNING:   last 
updated never but last attempt on Wed Nov 30 05:01:33 2011 failed.
daemon.log.3.gz:Nov 30 05:06:34 pluto ddclient[17042]: WARNING:   Wait 
at least 5 minutes between update attempts.
daemon.log.3.gz:Nov 30 05:11:34 pluto ddclient[17042]: SUCCESS:  
updating .dyndns.org: good: IP address set to 87.157.39.126
daemon.log.3.gz:Dec  1 05:02:30 pluto ddclient[17042]: SUCCESS:  
updating .dyndns.org: good: IP address set to 87.157.42.181
daemon.log.3.gz:Dec  2 05:04:11 pluto ddclient[17042]: WARNING:  cannot 
connect to checkip.dyndns.com:80 socket: IO::Socket::INET: Bad hostname 
'checkip.dyndns.com'
daemon.log.3.gz:Dec  2 05:09:11 pluto ddclient[17042]: SUCCESS:  
updating .dyndns.org: good: IP address set to 93.218.177.36
daemon.log.3.gz:Dec  3 05:06:23 pluto ddclient[17042]: WARNING:  cannot 
connect to checkip.dyndns.com:80 socket: IO::Socket::INET: connect: No 
route to host
daemon.log.3.gz:Dec  3 05:11:24 pluto ddclient[17042]: SUCCESS:  
updating .dyndns.org: good: IP address set to 87.157.37.232
daemon.log.3.gz:Dec  4 05:08:42 pluto ddclient[17042]: WARNING:  cannot 
connect to checkip.dyndns.com:80 socket: IO::Socket::INET: connect: 
Connection timed out
daemon.log.3.gz:Dec  4 05:13:43 pluto ddclient[17042]: FAILED:   
updating .dyndns.org: Could not connect to members.dyndns.org.
daemon.log.3.gz:Dec  4 05:18:43 pluto ddclient[17042]: WARNING:  file 
/var/cache/ddclient/ddclient.cache, line 3: Invalid Value for keyword 
'ip' = ''
daemon.log.3.gz:Dec  4 05:18:43 pluto ddclient[17042]: SUCCESS:  
updating .dyndns.org: good: IP address set to 93.218.160.219


After the successful update, nothing further was logged. But:

root@pluto:/var/log# ps axf|grep ddclient
17042 ?S  9:45 ddclient - reading from members.dyndns.org 
port 80


Restarting via init script did not help - invoke-rc.d blocked waiting 
for the script to stop the daemon.

 5546 pts/0S+ 0:00  \_ grep ddclient

root@pluto:/var/log# kill 17042
root@pluto:/var/log# kill 17042
root@pluto:/var/log# kill 17042
root@pluto:/var/log# kill 17042
root@pluto:/var/log# kill 17042
root@pluto:/var/log# kill 17042
root@pluto:/var/log# kill -9 17042
root@pluto:/var/log# kill 17042
-bash: kill: (17042) - No such process

After that, restarting the client worked. Now: Why did it block so long? :-)

There are also some curious log messages I should research.

Greetings, Torsten




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject 

Bug#521750: Should package mocka be orphaned?

[Torsten Landschoff]

On Thu, 2011-12-08 at 19:10 +0100, Martin Eberhard Schauer wrote:

 the package has an open FTBS bug report since march 2009. You did not 
 respond
 until now (at least not in the BTS). How to proceed with your package?

As far as I am concerned, mocka is crap and should be removed from the
archive. It is dead upstream, source code is only partially available
(last I checked - the output of a compiler generator is not to useful
for changes when you don't have the input files), and it makes
assumptions of e.g. the C startup code which is easily broken.

I wanted to have it removed but got opposition at that time from some
telling me that it is still useful and needed for them, so it is rotting
in the archives.

You want to take it? ;-)

Greetings, Torsten





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

Bug#651557: That's a stack overflow in the parser

[Torsten Landschoff]

Hi Alexandre,

I can reproduce the Segmentation Fault. But this is not really a bug, 
it's just a stack overflow in the parser. You can just allow more memory 
for python:


$ ulimit -s unlimited
$ python out.py
142913828922

The default on my system is 8192 kByte, 16384 kByte suffice to make it work.

I would not consider this a bug in python. To fix this, one would need 
another approach for parsing which avoid recursion on the system stack.

That would probably be much slower and error prone.

BTW: The Ruby error message looks like Ruby starts evaluation without 
parsing the code in full.


Greetings, Torsten




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

Bug#648871: [Pkg-fonts-devel] Bug#648871: gsfonts-other: Please drop defoma support

[Torsten Landschoff]

Hi Christian,

On Sat, Nov 19, 2011 at 04:27:33PM +0100, Christian PERRIER wrote:
 
 My former patch was incorrectly running defoma-font in prerm. That
 should be preinst.
 
 New patch attached.

Thanks for the patch. I am currently without decent network access (and
without my Debian key), so I can upload this on 2011-11-28 the earliest.
Feel free to NMU in case you want it earlier.

Greetings, Torsten



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

Bug#496832: Any progress on this one?

[Torsten Landschoff]

Hi Vadim, Wences, ...,

is there any progress on this one? I just noticed that there is still no 
bakefile in Debian an had to install it manually while working with the 
wxPython sources.


The package built fine for me, what is holding it back from Debian? I 
could sponsor an upload if needed...


Greetings, Torsten




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

Bug#638883: Scratch that

[Torsten Landschoff]

I was too fast to hit the send button. In fact, most of these extra
libraries can be disabled using the VTK_USE_SYSTEM_JPEG define and the
likes in CMake.

Greetings, Torsten

-- 
DYNAmore Gesellschaft fuer Ingenieurdienstleistungen mbH
Torsten Landschoff

Office Dresden
Tel: +49-(0)351-4519587
Fax: +49-(0)351-4519561

mailto:torsten.landsch...@dynamore.de
http://www.dynamore.de

Registration court: Mannheim, HRB: 109659, based in Karlsruhe,
Managing director:  Prof. Dr. K. Schweizerhof, Dipl.-Math. U. Franz




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

Bug#638883: Duplication of FTGL inside VTK causes crashes when using both

[Torsten Landschoff]

FYI, we are running into problems with our application because of this
inclusion of FTGL. Basically, we are using VTK for 3D visualization and
also use OpenGL + FTGL to draw a 2D graph.

Of course, the system FTGL is at 2.x but seems to have symbol clashes
with the FTGL in vtk.

In python it seems to suffice to import ftgl first and vtk later for
now, but of course there is no guarantee.

BTW: There are more libraries included in VTK :-(

At least expat, freetype, gl2ps, libjpeg, libpng, libnetcdf, libz and
libtiff are in there as well...

Greetings, Torsten

-- 
DYNAmore Gesellschaft fuer Ingenieurdienstleistungen mbH
Torsten Landschoff

Office Dresden
Tel: +49-(0)351-4519587
Fax: +49-(0)351-4519561

mailto:torsten.landsch...@dynamore.de
http://www.dynamore.de

Registration court: Mannheim, HRB: 109659, based in Karlsruhe,
Managing director:  Prof. Dr. K. Schweizerhof, Dipl.-Math. U. Franz




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

Bug#638883: [PATCH] Enable symbol versioning for libvtkftgl

[Torsten Landschoff]

Hello again,

for our application, I worked around the symbol clashes between libftgl
in VTK and the system ftgl by enabling symbol versioning for the VTK
provided version.

Patch attached in case it is useful for you as well.

Greetings, Torsten

-- 
DYNAmore Gesellschaft fuer Ingenieurdienstleistungen mbH
Torsten Landschoff

Office Dresden
Tel: +49-(0)351-4519587
Fax: +49-(0)351-4519561

mailto:torsten.landsch...@dynamore.de
http://www.dynamore.de

Registration court: Mannheim, HRB: 109659, based in Karlsruhe,
Managing director:  Prof. Dr. K. Schweizerhof, Dipl.-Math. U. Franz
commit 38b915e459190945157d667354000f2c3142fbf3
Author: Torsten Landschoff torsten.landsch...@dynamore.de
Date:   Thu Sep 1 13:11:53 2011 +0200

Build the vtkftgl library with symbol versioning.

This avoids name clashes between vtkftgl and the system ftgl library.

diff --git a/Utilities/ftgl/CMakeLists.txt b/Utilities/ftgl/CMakeLists.txt
index 08e469c..72d4af3 100644
--- a/Utilities/ftgl/CMakeLists.txt
+++ b/Utilities/ftgl/CMakeLists.txt
@@ -1,5 +1,7 @@
 PROJECT (VTKFTGL)
 
+INCLUDE(TestCXXAcceptsFlag)
+
 #
 # Dependency mask
 #
@@ -160,6 +162,39 @@ IF(NOT VTK_INSTALL_NO_LIBRARIES)
 ENDIF(NOT VTK_INSTALL_NO_LIBRARIES)
 
 #
+# To avoid name clashes (and the resulting crashes) between our FTGL and the
+# system FTGL, we configure the linker to add a prefix to all symbols.
+#
+
+if (CMAKE_COMPILER_IS_GNUCXX)
+
+  GET_TARGET_PROPERTY(VTKFTGL_LINK_FLAGS vtkftgl LINK_FLAGS)
+  IF(VTKFTGL_LINK_FLAGS)
+SET(VTKFTGL_LINK_FLAGS ${VTKFTGL_LINK_FLAGS} )
+  ELSE(VTKFTGL_LINK_FLAGS)
+SET(VTKFTGL_LINK_FLAGS)
+  ENDIF(VTKFTGL_LINK_FLAGS)
+
+
+  set(_version_script_content libvtkftgl { *; };)
+  set(_version_script ${CMAKE_CURRENT_BINARY_DIR}/version.script)
+  file(WRITE ${_version_script} ${_version_script_content}\n)
+
+  # Check if the linker supports version script (i.e. is GNU ld)
+  check_cxx_accepts_flag(-Wl,--version-script,${_version_script}
+LD_ACCEPTS_VERSION_SCRIPT)
+  if (LD_ACCEPTS_VERSION_SCRIPT)
+set(_link_flags -Wl,--version-script,'${_version_script}')
+  endif (LD_ACCEPTS_VERSION_SCRIPT)
+
+  if (_link_flags)
+SET_TARGET_PROPERTIES(vtkftgl PROPERTIES
+  LINK_FLAGS ${VTKFTGL_LINK_FLAGS}${_link_flags})
+  endif (_link_flags)
+endif (CMAKE_COMPILER_IS_GNUCXX)
+
+
+#
 # Do not cover this lib
 #
 CONFIGURE_FILE (${VTKFTGL_SOURCE_DIR}/.NoDartCoverage

Bug#640045: [PATCH] SIGSEGV when running mount -a

[Torsten Landschoff]

Package: mount
Version: 2.19.1-5
Tags: patch

Hi LaMont,

on my system I get a segfault in mount on each boot. This seems to be 
due to unchecked access to mnt_opts, which is NULL in my case. Since 
other accesses to that field check it against NULL first, this seems to 
be an allowed value.


The offending line in my fstab looks like this:

//pluto/scans/home/torsten/scanscifs


The attached patch fixes this for me. Please consider applying it.

Greetings, Torsten

From dd5a1c884278dcb007a62148e626fb20e8298432 Mon Sep 17 00:00:00 2001
From: Torsten Landschoff tors...@debian.org
Date: Thu, 1 Sep 2011 20:58:47 +0200
Subject: [PATCH] Check mnt_opts against NULL before accessing it.

On my fstab, mount -a failed with a segfault for the following entry:

  //pluto/scans	/home/torsten/scans	cifs

Backtrace was:

  (gdb) where
  #0  __strstr_sse2 (haystack_start=0x0, needle_start=0x40f6ae loop=) at ../string/strstr.c:63
  #1  0x00407d22 in is_fstab_entry_mounted (verbose=0, mc=0xd9c8c0) at mount.c:2069
  #2  do_mount_all (types=0x0, options=0x0, test_opts=0x0) at mount.c:2141
  #3  0x00403bf9 in main (argc=optimized out, argv=optimized out) at mount.c:2623
  (gdb) p
  $3 = {mnt_fsname = 0xd9c860 //pluto/scans, mnt_dir = 0xd9c880 /home/torsten/scans,
mnt_type = 0xd9c8a0 cifs, mnt_opts = 0x0, mnt_freq = 0, mnt_passno = 0}
---
 debian/changelog |4 
 mount/mount.c|5 +++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 4ba9efc..47c4e1d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -30,6 +30,10 @@ util-linux (2.17-0) experimental; urgency=low
   * po: update fi.po (from translationproject.org) (Lauri Nurmi)
   * po: update eu.po (from translationproject.org) (Mikel Olasagasti)
 
+  [Torsten Landschoff]
+
+  * mount/mount.c: Check mnt_opts against NULL before accessing it.
+
  -- LaMont Jones lam...@debian.org  Mon, 18 Jan 2010 08:01:43 -0700
 
 util-linux (2.17~rc3-1) experimental; urgency=low
diff --git a/mount/mount.c b/mount/mount.c
index 36d1a57..6d481a5 100644
--- a/mount/mount.c
+++ b/mount/mount.c
@@ -1162,7 +1162,7 @@ is_mounted_same_loopfile(const char *node0, const char *loopfile, unsigned long
 			res = loopfile_used_with((char *) mnt-m.mnt_fsname,
 	loopfile, offset);
 
-		else if ((p = strstr(mnt-m.mnt_opts, loop=))) {
+		else if ((mnt-m.mnt_opts  (p = strstr(mnt-m.mnt_opts, loop= {
 			char *dev = xstrdup(p+5);
 			if ((p = strchr(dev, ',')))
 *p = '\0';
@@ -2054,7 +2054,7 @@ is_fstab_entry_mounted(struct mntentchn *mc, int verbose)
 		goto yes;
 
 	/* extra care for loop devices */
-	if ((strstr(mc-m.mnt_opts, loop=) ||
+	if (((mc-m.mnt_opts  strstr(mc-m.mnt_opts, loop=)) ||
 	 (stat(mc-m.mnt_fsname, st) == 0  S_ISREG(st.st_mode {
 
 		char *p = get_option_value(mc-m.mnt_opts, offset=);
@@ -2065,6 +2065,7 @@ is_fstab_entry_mounted(struct mntentchn *mc, int verbose)
 printf(_(mount: ignore %s 
 	(unparsable offset= option)\n),
 	mc-m.mnt_fsname);
+			free(p);
 			return -1;
 		}
 		free(p);
-- 
1.7.1.rc2.dirty

Bug#639346: [PATCH] Crashes in wxVTKRenderWindowInteractor

[Torsten Landschoff]

Package: python-vtk
Version: 5.6.1-6
Tags: patch

Dear Maintainer,

at work I ran into a nasty problem with vtk 5.6: Using the
wxVTKRenderWindowInteractor lead to segmentation faults. I did not use
the Debian package, but it seems this problem is unpatched at
git://git.debian.org/git/collab-maint/vtk.git
fa252a51fff63986d69bcdd6b1c6659353ee47df

The attached patch is from upstream's git repository but was not
included in 5.6 as it seems. Please consider applying it.

Greetings, Torsten

commit 24696342385db581cfcabb79eb90164bdd045267
Author: Prabhu Ramachandran pra...@aero.iitb.ac.in
Date:   Tue May 25 15:12:55 2010 -0700

Fix crashing wxVTKRenderWindowInteractor on Linux

BUG: Fixing a segfault with recent versions of VTK after Feb 5, 2010.
The specific checkin that caused this is
cc83e73b7f0efff98441d8b9640d34c86321578c.  This patch changed the way
swig mangled pointers were checked from Python and that broke the
GetDisplayId method of wxVTKRenderWindowInteractor which caused the
segfault.

diff --git a/Wrapping/Python/vtk/wx/wxVTKRenderWindowInteractor.py b/Wrapping/Python/vtk/wx/wxVTKRenderWindowInteractor.py
index d3807cb..69c1ee7 100644
--- a/Wrapping/Python/vtk/wx/wxVTKRenderWindowInteractor.py
+++ b/Wrapping/Python/vtk/wx/wxVTKRenderWindowInteractor.py
@@ -347,7 +347,7 @@ class wxVTKRenderWindowInteractor(baseClass):
 
 # we now have 0xdeadbeef
 # VTK wants it as: _deadbeef_void_p (pre-SWIG-1.3 style)
-d = '_%s_%s' % (d[2:], 'void_p')
+d = '_%s_%s\0' % (d[2:], 'void_p')
 
 return d
 

Bug#497818: pkg load ftp; clear -all does not crash here

[Torsten Landschoff]

notfound 497818 swig2.0/2.0.4-3
thanks

Hi Francesco,

I just tried to reproduce this problem with current swig on my Debian 
unstable system (amd64):


octave:1  version

ans = 3.2.4

octave:2  pkg load ftp

warning: You have loaded the ftp package.

A call to clear -all from now on will make Octave crash.

You have been warned.

octave:3  clear -all

octave:4


No idea what fixed it seems to be working now...

Greetings, Torsten




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

Bug#446836: Checked the links in Manual/index.html

[Torsten Landschoff]

notfound 446836 2.0.4-3
thanks

Hi Cyril,

4 years after you filed the bug, I finally had another look at it - sorry.

I just checked and all the links in Manual/index.html worked fine.

Therefore I am closing this bug.

Greetings, Torsten




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

Bug#468414: Patch for changing the behaviour for the Lua bindings

[Torsten Landschoff]

Hi Miles,

incredible, that this bug stands for two years now. I spent to hours to 
create a patch which is attached to this email.


I forwarded the patch upstream and hope they will integrate it.

Greetings, Torsten

commit 8f8bd9496bd405cadf8dd499aefe2651f9a5f73f
Author: Torsten Landschoff tors...@landschoff.net
Date:   Thu Aug 18 23:40:20 2011 +0200

Debian Bug #468414: require module should return the module table.

This also adds an option to disable installing the module table as a global
variable which looks like a candidate for some surprises. Also, this ensures
that package.loaded[module] contains the module table.

diff --git a/Examples/test-suite/common.mk b/Examples/test-suite/common.mk
index e86c0fb..28d569f 100644
--- a/Examples/test-suite/common.mk
+++ b/Examples/test-suite/common.mk
@@ -499,6 +499,7 @@ C_TEST_CASES += \
 	li_cpointer \
 	li_math \
 	long_long \
+	lua_no_module_global \
 	memberin_extend_c \
 	name \
 	nested \
diff --git a/Examples/test-suite/lua/Makefile.in b/Examples/test-suite/lua/Makefile.in
index 0ddc86a..0ffdaaf 100644
--- a/Examples/test-suite/lua/Makefile.in
+++ b/Examples/test-suite/lua/Makefile.in
@@ -25,7 +25,7 @@ include $(srcdir)/../common.mk
 LIBS   = -L.
 
 # Custom tests - tests with additional commandline options
-# none!
+lua_no_module_global.ctest: SWIGOPT += -nomoduleglobal
 
 # Rules for the different types of tests
 %.cpptest: 
diff --git a/Examples/test-suite/lua/lua_no_module_global_runme.lua b/Examples/test-suite/lua/lua_no_module_global_runme.lua
new file mode 100644
index 000..9eb436c
--- /dev/null
+++ b/Examples/test-suite/lua/lua_no_module_global_runme.lua
@@ -0,0 +1,24 @@
+-- require is only available in Lua 5.1
+
+if string.sub(_VERSION,1,7)=='Lua 5.1' then
+
+-- Initially the package should not be loaded
+assert(package.loaded[lua_no_module_global] == nil)
+
+-- Load the module
+the_module = require lua_no_module_global
+
+-- require should return the module table
+assert(the_module.hi_mom ~= nil)
+assert(the_module.hi_mom() == hi mom!)
+
+-- But it should not end up in the global table _G, subject to
+-- the -nomoduleglobal swig option.
+assert(_G[lua_no_module_global] == nil)
+
+-- According to the Lua 5.1 reference manual, require should also
+-- store the module table into package.loaded[name]
+assert(package.loaded[lua_no_module_global] == the_module)
+assert(package.loaded[lua_no_module_global].hi_mom() == hi mom!)
+
+end
diff --git a/Examples/test-suite/lua_no_module_global.i b/Examples/test-suite/lua_no_module_global.i
new file mode 100644
index 000..21d2113
--- /dev/null
+++ b/Examples/test-suite/lua_no_module_global.i
@@ -0,0 +1,5 @@
+%module lua_no_module_global
+%{
+char *hi_mom() { return hi mom!; }
+%}
+char *hi_mom();
diff --git a/Lib/lua/luarun.swg b/Lib/lua/luarun.swg
index 89b7626..1810e98 100644
--- a/Lib/lua/luarun.swg
+++ b/Lib/lua/luarun.swg
@@ -237,7 +237,7 @@ SWIGINTERN int SWIG_Lua_module_set(lua_State* L)
   return 0;
 }
 
-/* registering a module in lua */
+/* registering a module in lua. Pushes the module table on the stack. */
 SWIGINTERN void  SWIG_Lua_module_begin(lua_State* L,const char* name)
 {
   assert(lua_istable(L,-1));  /* just in case */
@@ -254,8 +254,16 @@ SWIGINTERN void  SWIG_Lua_module_begin(lua_State* L,const char* name)
   lua_newtable(L);/* the .set table */
   lua_rawset(L,-3);  /* add .set into metatable */
   lua_setmetatable(L,-2);  /* sets meta table in module */
+#ifdef SWIG_LUA_MODULE_GLOBAL
+  /* If requested, install the module directly into the global namespace. */
   lua_rawset(L,-3);/* add module into parent */
   SWIG_Lua_get_table(L,name);   /* get the table back out */
+#else
+  /* Do not install the module table as global name. The stack top has
+ the module table with the name below. We pop the top and replace
+ the name with it. */
+  lua_replace(L,-2);
+#endif
 }
 
 /* ending the register */
diff --git a/Lib/lua/luaruntime.swg b/Lib/lua/luaruntime.swg
index 5823d4f..e286445 100644
--- a/Lib/lua/luaruntime.swg
+++ b/Lib/lua/luaruntime.swg
@@ -59,8 +59,9 @@ SWIGEXPORT int SWIG_init(lua_State* L)
   /* invoke user-specific initialization */
   SWIG_init_user(L);
   /* end module */
-  lua_pop(L,1);  /* tidy stack (remove module table)*/
-  lua_pop(L,1);  /* tidy stack (remove global table)*/
+  /* Note: We do not clean up the stack here (Lua will do this for us). At this
+ point, we have the globals table and out module table on the stack. Returning
+ one value makes the module table the result of the require command. */
   return 1;
 }
 
diff --git a/Source/Modules/lua.cxx b/Source/Modules/lua.cxx
index c38ffda..c6fd114 100644
--- a/Source/Modules/lua.cxx
+++ b/Source/Modules/lua.cxx
@@ -83,10 +83,11 @@ void display_mapping(DOH *d) {
 NEW LANGUAGE NOTE:END

Bug#633736: swig2.0: diff for NMU version 2.0.4-2.1

[Torsten Landschoff]

Hi Luca,

On 08/14/2011 05:36 PM, Luca Falavigna wrote:

I've prepared an NMU for swig2.0 (versioned as 2.0.4-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Thanks for the upload. Fine with me to upload it directly, as the patch 
has been included upstream.


Greetings, Torsten




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

Bug#545933: More information

[Torsten Landschoff]

On 07/23/2011 06:43 PM, Otavio Salvador wrote:

Please provide the output of lsusb with the keyboard connected so we
can identify the required kernel module for inclusion.
I do not remember which keyboard I connected back at the time I 
commented on this bug. I connected my good old Cherry PS/2 keyboard 
after installation was complete, after using a spare keyboard during 
installation.


If needed I can check if the problem still applies today with a random 
USB keyboard. I am quite sure that the kind of keyboard does not really 
make a difference.


It is likely that the keyboard was the one that came with the mouse I am 
currently using, so here is the relevant lsusb output:


Bus 004 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver

I guess the kernel module is hid_logitech.

Greetings, Torsten




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

Bug#630933: Patch and NMU to delayed/14

[Torsten Landschoff]

I just tried to build adonthell with swig 2.0. Since the changes are so 
trivial, I did just upload the resulting package to the delayed queue.


The diff is attached.

Greetings, Torsten

diff -Nru adonthell-0.3.5/debian/changelog adonthell-0.3.5/debian/changelog
--- adonthell-0.3.5/debian/changelog	2011-05-08 22:56:02.0 +0200
+++ adonthell-0.3.5/debian/changelog	2011-06-23 00:00:51.0 +0200
@@ -1,3 +1,11 @@
+adonthell (0.3.5-6.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Build with swig2.0 to allow removal of the obsolete swig1.3 package
+(closes: #630933).
+
+ -- Torsten Landschoff tors...@debian.org  Thu, 23 Jun 2011 00:00:47 +0200
+
 adonthell (0.3.5-6) unstable; urgency=low
 
   * Team upload.
diff -Nru adonthell-0.3.5/debian/control adonthell-0.3.5/debian/control
--- adonthell-0.3.5/debian/control	2011-05-08 22:24:56.0 +0200
+++ adonthell-0.3.5/debian/control	2011-06-22 23:47:03.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org
 Uploaders: Barry deFreese bdefre...@debian.org, Moritz Muehlenhoff j...@debian.org
-Build-Depends: debhelper (= 5.0.37.2), autotools-dev, libsdl1.2-dev, libvorbis-dev, zlib1g-dev, swig1.3, libfreetype6-dev, libaa1-dev, python-dev, python-support, libsdl-ttf2.0-dev, libsdl-mixer1.2-dev, libsdl1.2-dev
+Build-Depends: debhelper (= 5.0.37.2), autotools-dev, libsdl1.2-dev, libvorbis-dev, zlib1g-dev, swig2.0, libfreetype6-dev, libaa1-dev, python-dev, python-support, libsdl-ttf2.0-dev, libsdl-mixer1.2-dev, libsdl1.2-dev
 Standards-Version: 3.8.3
 Homepage: http://adonthell.linuxgames.com/
 Vcs-Svn: svn://svn.debian.org/svn/pkg-games/packages/trunk/adonthell/

Bug#550660: duma command fails to preload libduma.so.0.0.0

[Torsten Landschoff]

found 550660 2.5.15-1.1
thanks


I just tried to use duma for a simple buffer overrun example. However, I was unable to 
use the duma command:

torsten@pulsar:~/strbuf_protect$ duma ./example
ERROR: ld.so: object './libduma.so.0.0.0' from LD_PRELOAD cannot be preloaded: 
ignored.
[program output...]

This still behaves exactly the same.

However, setting LD_PRELOAD manually works:

And still works in 2.5.15-1.1.
The segfault is to be expected of course since this is what DUMA does. I 
expected it to report memory errors like valgrind does.


So it seems it is working when manually LD_PRELOADed. But the duma 
command is still broken.


Greetings, Torsten




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

Bug#612475: swig2.0: zend_error_noreturn should be zend_error

[Torsten Landschoff]

Hi Mathieu,

On 02/08/2011 06:40 PM, Mathieu Malaterre wrote:

Package: swig2.0
Version: 2.0.1-2
Severity: important
Tags: patch


Hi,

   It would be nice if the next upload would contains this patch as it fixes an 
issue in the PHP wrapper.
If I read the upstream ticket (and the source) correctly, this is fixed 
in 2.0.4?!


Greetings, Torsten




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

Bug#630933: adonthell build-depends on obsolete swig1.3

[Torsten Landschoff]

Package: adonthell
Version: 0.3.5-6
Severity: normal

adonthell uses the obsolete swig1.3 package during build. Please use the 
swig2.0 package instead as swig1.3 is not maintained upstream anymore - 
it was the unstable branch leading to swig 2.0. The swig1.3 package will 
be removed from Debian.


Please update your package! Note that some autoconf scripts may 
misinterpret version 2.0.x as smaller than 1.3.x because of a bad 
comparison. You can find a patch at http://savannah.gnu.org/patch/?7187 
(submitted to upstream autoconf-archive, but it seems the package is 
orphaned).


Greetings, Torsten




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

Bug#630934: ibutils build-depends on obsolete swig1.3

[Torsten Landschoff]

Package: ibutils
Version: 1.2-OFED-1.4.2-1
Severity: normal

ibutils uses the obsolete swig1.3 package during build. Please use the 
swig2.0 package instead as swig1.3 is not maintained upstream anymore - 
it was the unstable branch leading to swig 2.0. The swig1.3 package will 
be removed from Debian.


Please update your package! Note that some autoconf scripts may 
misinterpret version 2.0.x as smaller than 1.3.x because of a bad 
comparison. You can find a patch at http://savannah.gnu.org/patch/?7187 
(submitted to upstream autoconf-archive, but it seems the package is 
orphaned).


Greetings, Torsten




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

Bug#630935: python-drizzle build-depends on obsolete swig1.3

[Torsten Landschoff]

Package: python-drizzle
Version: 1.0-2
Severity: normal

python-drizzle uses the obsolete swig1.3 package during build. Please 
use the swig2.0 package instead as swig1.3 is not maintained upstream 
anymore - it was the unstable branch leading to swig 2.0. The swig1.3 
package will be removed from Debian.


Please update your package! Note that some autoconf scripts may 
misinterpret version 2.0.x as smaller than 1.3.x because of a bad 
comparison. You can find a patch at http://savannah.gnu.org/patch/?7187 
(submitted to upstream autoconf-archive, but it seems the package is 
orphaned).


Greetings, Torsten




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

Bug#630936: trilinos build-depends on obsolete swig1.3

[Torsten Landschoff]

Package: trilinos
Version: 10.4.0.dfsg-1
Severity: normal

trilinos uses the obsolete swig1.3 package during build. Please use the 
swig2.0 package instead as swig1.3 is not maintained upstream anymore - 
it was the unstable branch leading to swig 2.0. The swig1.3 package will 
be removed from Debian.


Please update your package! Note that some autoconf scripts may 
misinterpret version 2.0.x as smaller than 1.3.x because of a bad 
comparison. You can find a patch at http://savannah.gnu.org/patch/?7187 
(submitted to upstream autoconf-archive, but it seems the package is 
orphaned).


Greetings, Torsten




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

Bug#630937: RM: swig1.3 -- RoM; replaced by swig2.0

[Torsten Landschoff]

Package: ftp.debian.org
Severity: normal

The development branch SWIG 1.3 led to the stable release of SWIG 2.0, 
built from the swig2.0 source package.


swig, swig-doc and swig-examples packages are taken over with the latest 
upload. The binary packages swig1.3, swig1.3-examples and swig1.3-doc 
should disappear, as they were only transition packages.





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

Bug#629917: code generated for python modules fails to compile with gcc 4.6

[Torsten Landschoff]

Hi Sebastian,

On 06/09/2011 06:10 PM, Sebastian Ramacher wrote:

The code generated for python modules fails to compile with gcc 4.6. This is
due to a missing #includestddef.h. Upstream fixed this issue in [1].

Some packages FTBFS because of this (see #624982 and #625087 for example).

[1] 
http://swig.svn.sourceforge.net/viewvc/swig/trunk/Lib/std/std_common.i?r1=10424r2=12547
Could you please try if the build works when using the swig2.0 package? 
The upstream fix as of r12547 should be included in the 2.0.4 release, 
which is the current swig2.0 version in unstable.


Greetings, Torsten




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

Bug#620591: fox1.6: diff for NMU version 1.6.44-1.1

[Torsten Landschoff]

Hi Luk,

On 05/30/2011 07:54 PM, Luk Claes wrote:

I've prepared an NMU for fox1.6 (versioned as 1.6.44-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Thanks for the patch. I applied it to the Subversion repository for the 
package so it is not lost on my next upload.


Greetings, Torsten




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

Bug#626310: Processed: reassign 626310 to swig

[Torsten Landschoff]

Hi Nico,

On Mon, 2011-05-23 at 17:33 +, Debian Bug Tracking System wrote:
 Processing commands for cont...@bugs.debian.org:
 
  reassign 626310 swig
 Bug #626310 [stfl] stfl: FTBFS when there is no passwd entry for the build 
 user
 Bug reassigned from package 'stfl' to 'swig'.

Interesting bug. But why was this reassigned to swig?

 cd python2.7  python2.7 -c 'import stfl'
 Traceback (most recent call last):
   File /usr/lib/python2.7/site.py, line 562, in module
 main()
   File /usr/lib/python2.7/site.py, line 544, in main
 known_paths = addusersitepackages(known_paths)
   File /usr/lib/python2.7/site.py, line 271, in addusersitepackages
 user_site = getusersitepackages()
   File /usr/lib/python2.7/site.py, line 246, in getusersitepackages
 user_base = getuserbase() # this will also set USER_BASE
   File /usr/lib/python2.7/site.py, line 236, in getuserbase
 USER_BASE = get_config_var('userbase')
   File /usr/lib/python2.7/sysconfig.py, line 558, in get_config_var
 return get_config_vars().get(name)
   File /usr/lib/python2.7/sysconfig.py, line 462, in get_config_vars
 _CONFIG_VARS['userbase'] = _getuserbase()
   File /usr/lib/python2.7/sysconfig.py, line 205, in _getuserbase
 return env_base if env_base else joinuser(~, .local)
   File /usr/lib/python2.7/sysconfig.py, line 192, in joinuser
 return os.path.expanduser(os.path.join(*args))
   File /usr/lib/python2.7/posixpath.py, line 260, in expanduser
 userhome = pwd.getpwuid(os.getuid()).pw_dir
 KeyError: 'getpwuid(): uid not found: 2952'

Nothing in that backtrace has any relation to SWIG. What's going on here
is that python 2.7 is trying to find any user-local package during
initialization of the interpreter. 

The same thing happens when I create a test user, login and remove the
user from passwd while he is still active:

test@pulsar:/home/test$ python2.7 -c 'import sys'
Traceback (most recent call last):
  File /usr/lib/python2.7/site.py, line 562, in module
main()
  File /usr/lib/python2.7/site.py, line 544, in main
known_paths = addusersitepackages(known_paths)
...
  File /usr/lib/python2.7/sysconfig.py, line 192, in joinuser
return os.path.expanduser(os.path.join(*args))
  File /usr/lib/python2.7/posixpath.py, line 260, in expanduser
userhome = pwd.getpwuid(os.getuid()).pw_dir
KeyError: 'getpwuid(): uid not found: 1001'

The same applies to python 2.6:

test@pulsar:/home/test$ python2.6 -c 'import sys'
'import site' failed; use -v for traceback

I am not sure if this can be considered a bug in python. Nobody says
that python should work when the current user does not exist.

OTOH it makes sense for the build of stfl to check if the library can be
imported.

Greetings, Torsten





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

Bug#622980: swig: wrapper does not compile with python 3.2

[Torsten Landschoff]

On Sun, 2011-04-17 at 21:08 +0200, Patrick Matthäi wrote:
  
  Now that squeeze is released I should really start that transition...
  
  Unfortunately, the diff of r12620 does not apply to swig 2.0.3 as it
  depends on a bunch of other changes.
 
 Packaging a VCS snapshot of swig2.0? :)

I just packaged a snapshot of 2.0.4 which should soon be released. The
package has version number 2.0.3-2 which does not match the result of
swig -version. I am too tired to fix this now and it will righten itself
when upstream releases 2.0.4

I was able to build the znc bindings with this SWIG package (after
removing the SSLv2 code).

Greetings, Torsten





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

Bug#622980: swig: wrapper does not compile with python 3.2

[Torsten Landschoff]

On Sat, 2011-04-16 at 16:10 +0200, Patrick Matthäi wrote:

  I am sorry to say that it is non-trivial to merge a fix to this bug.
  Upstream revision 12620 contains the fix according to the upstream bug.
  However, the fix is not released yet and will only make it into SWIG
  2.0.4 which accumulated a lot of changes already.
  
  I don't feel like releasing a package for that before it is released
  upstream.

 And updating the package to 2.0.3 and add the change as patch?

There is actually a package of 2.0.3, please install swig2.0. I did not
move swig to point to swig2.0 yet as that breaks many packages - the
autoconf-archive detection of swig is broken and thinks 2.0 is older
than 1.3.x :-(

Now that squeeze is released I should really start that transition...

Unfortunately, the diff of r12620 does not apply to swig 2.0.3 as it
depends on a bunch of other changes.

Greetings, Torsten






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

Bug#622980: swig: wrapper does not compile with python 3.2

[Torsten Landschoff]

Hi Patrick,

On Sat, 2011-04-16 at 13:03 +0200, Patrick Matthäi wrote:
 Package: swig
 Version: 1.3.40-3
 Severity: critical
 Tags: upstream
 Justification: breaks unrelated software
 
 See upstream bug:
 http://sourceforge.net/tracker/?func=detailatid=101645aid=3057804group_id=1645
 
 This bug prevents me from building e.g. znc (and so on also prevents me from
 fixing another RC bug which also prevents python to migrate).

I am sorry to say that it is non-trivial to merge a fix to this bug.
Upstream revision 12620 contains the fix according to the upstream bug.
However, the fix is not released yet and will only make it into SWIG
2.0.4 which accumulated a lot of changes already.

I don't feel like releasing a package for that before it is released
upstream.

Greetings, Torsten





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

Bug#617443: libsqlite3-tcl broken in 3.7.5-1 (package require fails)

[Torsten Landschoff]

Package: libsqlite3-tcl
Version: 3.7.5-1
Tags: patch

Hi Laszlo,

I ran across the following problem with libsqlite3-tcl:

torsten@pulsar:~$ tclsh
tclsh8.5 [~]package require sqlite3
can't find package sqlite3
while evaluating {package require sqlite3}

This is even though the package is installed. It turns out that no
pkgIndex.tcl is installed with the package:

torsten@pulsar:~$ dpkg -L libsqlite3-tcl|grep pkgIndex
torsten@pulsar:~$ 

The attached patch fixes this problem and adjusts the installation path
of the Tcl module from /usr/lib/sqlite3 (where nobody will look for it)
to /usr/lib/tcltk/sqlite3.

It applies cleanly to the sqlite3 package source of 3.7.5-1 via

torsten@pulsar:~/debian/sqlite3-3.7.5$ patch -p1  ../tcl_module_load.patch 


Please include this patch in the next release of the package.

Thanks, Torsten

commit bbf55df139920030cc9599d2d2fc632d6d6fabd8
Author: Torsten Landschoff tors...@landschoff.net
Date:   Wed Mar 9 00:20:39 2011 +0100

This patch fixes the problem that

  package require sqlite3

did not work with libsqlite3-tcl 3.7.5-1. It fixes the installation location
to /usr/lib/tcltk/sqlite3 as suggested in the Tcl policy (and used by other
packages).

diff --git a/debian/changelog b/debian/changelog
index b8fc974..74ec7bb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+sqlite3 (3.7.5-2) unstable; urgency=low
+
+  * Fix installation of the Tcl module so that is is usable via
+  package require sqlite3
+again.
+
+ -- Torsten Landschoff tors...@debian.org  Wed, 09 Mar 2011 00:19:42 +0100
+
 sqlite3 (3.7.5-1) unstable; urgency=low
 
   * New upstream release.
diff --git a/debian/libsqlite3-tcl.dirs b/debian/libsqlite3-tcl.dirs
index 90645f0..6845771 100644
--- a/debian/libsqlite3-tcl.dirs
+++ b/debian/libsqlite3-tcl.dirs
@@ -1,2 +1 @@
 usr/lib
-usr/lib/sqlite3
diff --git a/debian/libsqlite3-tcl.install b/debian/libsqlite3-tcl.install
index 1ede98d..d14e713 100644
--- a/debian/libsqlite3-tcl.install
+++ b/debian/libsqlite3-tcl.install
@@ -1 +1 @@
-usr/share/tcltk/tcl8.5/sqlite3/libtclsqlite3.so usr/lib/sqlite3/
+usr/lib/tcltk/sqlite3		usr/lib/tcltk/
diff --git a/debian/rules b/debian/rules
index 55d349b..c510692 100755
--- a/debian/rules
+++ b/debian/rules
@@ -29,6 +29,7 @@ configure-stamp:
 	./configure --prefix=/usr --mandir=/usr/share/man \
 	  --with-tcl=/usr/lib/tcl8.5 --enable-threadsafe \
 	  --enable-load-extension \
+	  TCLLIBDIR=/usr/lib/tcltk/sqlite3 \
 	  $(DDEBUG)
 
 	touch $@
@@ -55,9 +56,8 @@ install: build
 
 	$(MAKE) install DESTDIR=$(DESTDIR)
 	chrpath -d $(DESTDIR)/usr/bin/sqlite3
-	chrpath -d $(DESTDIR)/usr/share/tcltk/tcl8.5/sqlite3/libtclsqlite3.so
-	install -d $(DESTDIR)/usr/lib/sqlite3
-	install -m 0664 libtclsqlite3.la $(DESTDIR)/usr/lib/sqlite3/
+	chrpath -d $(DESTDIR)/usr/lib/tcltk/sqlite3/libtclsqlite3.so
+	install -m 0664 libtclsqlite3.la $(DESTDIR)/usr/lib/tcltk/sqlite3/
 	install -d $(DESTDIR)/usr/share/lemon
 	install -m 0664 tool/lempar.c $(DESTDIR)/usr/share/lemon/
 	install -m 0775 lemon $(DESTDIR)/usr/bin
@@ -65,9 +65,9 @@ install: build
 	# Remove *.la files per policy 3.9.1.0
 #	find $(DESTDIR) -name \*.la | xargs rm -f
 
-	sed -e 's/share/lib/' -e 's/tcl[^/]*\///g' \
-	  $(DESTDIR)/usr/share/tcltk/tcl8.5/sqlite3/pkgIndex.tcl \
-	  $(DESTDIR)/usr/lib/sqlite3/pkgIndex.tcl
+	# Create the pkgIndex.tcl file for the Tcl module. This generated file
+	# actually turns out to be relocatable.
+	echo pkg_mkIndex -verbose $(DESTDIR)/usr/lib/tcltk/sqlite3 | tclsh8.5
 
 binary-indep: build install
 

Bug#601628: swig1.3: please do not b-d on java on m68k

[Torsten Landschoff]

Hi Thorsten,

On Wed, 2010-10-27 at 21:43 +, Thorsten Glaser wrote:

 I’m currently in the process of sort-of rebootstrapping Debian/m68k.
 Could you please do me a favour in your next uploads of swig1.3 and
 make m68k a java-less architecture, as I’d like to avoid it this
 early in the process (especially considering gcc build times)?

Will do.

 From reading the swig1.3 changelog, I seem to need a newer one to
 build subversion, even though the latter doesn’t have a versioned
 b-d on it. It’s some dependency hell already anyway…

Subversion upstream comes with prebuilt wrapper source code. I am not
sure if that is usable in the Debian package though.

Generally, the Debian package of SWIG is ahead of the version supported
by Subversion (they usually target a few hand-picked SWIG versions).

Good luck, Torsten





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

Bug#592927: ddclient 3.8.0-11.1 package has not r111 script

[Torsten Landschoff]

Hi Patricio,

On Sat, Aug 14, 2010 at 01:12:37AM -0300, Patricio Latini wrote:
 
 ddclient script on this is wrong. It reports version 3.8.0 r111 however in
 the package contents it is r106

Where does it say it is r111? Seriously, I don't remember the exact Subversion
revision, which is meaningless anyway without the path in the repository.

What makes you believe that ddclient in Debian should use r111 from upstream?
To put it another way: Where does it report version r111?

 
 # $Id: ddclient 106 2008-12-04 18:05:23Z wimpunk $

I did not know that ddclient upstream has Subversion keywords enabled. Wonder
if they still have!?

Greetings, Torsten



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

Bug#585524: Same problem here

[Torsten Landschoff]

I ran into the same problem here, permission denied
on /usr/lib/cups/backend/hp.

As I found this bug I chmod'ed the directory as I was in a hurry. I am
currently upgrading to current sid, so let's see if the problem
resurfaces.

Greetings, Torsten





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

Bug#586129: wxWidgets + wxPython 2.8.11.0 released

[Torsten Landschoff]

Package: python-wxgtk2.8
Version: 2.8.10.1-3
Severity: wishlist

Hi wxWidgets Team,

Lately, wxwidgets upstream released wxWidgets 2.8.11 and wxPython
2.8.11.0. They are said to contain lots of bugfixes.

However, there are also API changes at least in wxPython (some flags are
now passed differently for example) so I am not sure if one would want
to upload a new package right away.

Anyway, I updated the package to 2.8.11.0 out of curiosity. In case you
are interested, my git repository is here:

http://git.debian.org/?p=users/torsten/wx.git;a=summary

Feel free to pull from it, perhaps it spares a few cycles on your side.
Perhaps an upload to experimental? :)

Greetings, Torsten






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

Bug#558784: Isn't this a security problem?

[Torsten Landschoff]

I would consider this to be a critical issue as it could become a security
problem.

Let's assume an archive key is compromised. As an admin reading this on
some information channel (irc, twitter, lwn.net, whatever) I would just
remove the key as shown by Tollef.

Only by reading this bug report I do know now that this plainly would not
work. Instead apt-key will reenable this key given any chance.

That sound to me like reenabling a root account or password authentication
for ssh style, something that should be up to the admin to decide. Having
a system override such a decision against me as the admin sounds like a
nightmare to me, something I would not accept from a trusted Debian system.

So, does this bug still apply?

Greetings, Torsten



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

Bug#580473: Omission in patch

[Torsten Landschoff]

Hi *,

I had a look at the patch attached by Mats Erik. Just a few nitpicks:

| if (getaddrinfo(argv[1], tftp, hints, ai) == 0)

The output of getaddrinfo in ai is never freed. One should call
freeaddrinfo(ai). Of course this should not be a problem since this is
only called once.


| memcpy(data.sa_peer, ai-ai_addr, ai-ai_addrlen);

Not sure about this. ai-ai_addrlen surely should not be bigger than a
struct sockaddr_in, but I'd rather play it safe and check for that before
overwriting random data.

Or at least just pass sizeof(data.sa_peer) as length parameter to memcpy.


Greetings, Torsten



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

Bug#584324: swig: SWIG 2.0 is out

[Torsten Landschoff]

On Thu, Jun 03, 2010 at 10:10:53AM +0200, Mathieu Malaterre wrote:
 
   SWIG 2.0 is officially out ! Please update the debian package.
   SWIG 2.0 is already in experimental, the real big change will be on the 
 LICENSE portion.

?? Did I miss something? I did not notice that the license has changed.

Greetings, Torsten



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