Bug#1052201: fftw3: baseline violation: Unconditionally enabled NEON for armhf

[Julian Taylor]

On 19.09.23 02:17, Boyuan Yang wrote:



According to https://wiki.debian.org/ArchitectureSpecificsMemo#armhf , NEON 
instructions
are not guaranteed on armhf platform. However, your debian/rules explicitly 
enabled NEON
support in armhf build. This should be a violation to architecture baseline.

Please consider fixing this issue. Ubuntu is providing an example patch for it, 
and it
can be used as a reference (patch attached).



fftw3 uses runtime feature detection, neon instructions are only used 
when the hardware supports it.

Bug#1001449: array indexing broken

[Julian Taylor]

Package: bpftrace
Version: 0.11.3-5
Tags: patch fixed-upstream

array indexing in bpftrace in debian stable is broken it always indexes 
with 0:

Example:

#!/usr/bin/env bpftrace
#include 
#include 
kprobe:tcp_connect
{
  $sk = ((struct sock *) arg0);
  if ($sk->__sk_common.skc_family == AF_INET6) {
  $d0 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[0];
  $d1 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[1];
  $d2 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[2];
  $d3 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[3];
  printf("%X %X %X %X\n", $d0, $d1, $d2, $d3);
  }
}

$ bpftrace tcpconnect.bt
$ curl -v http://[:::127.0.0.1]

output:
Attaching 1 probe...
0 0 0 0


expected:
0 0  17F


This has been fixed upstream with this patch:
https://github.com/iovisor/bpftrace/pull/1457

Bug#990220: wrong code generation for bpftrace

[Julian Taylor]

Package: llvm-toolchain-11
Version: 1:11.0.1-2
Tags: patch

bpftrace in debian testing suffers from a code generation bug in llvm11:

https://github.com/iovisor/bpftrace/issues/1305  


To reproduce run:
apt-get install bpftrace
/usr/sbin/tcpconnect.bt

connect to a https site.
the DPORT column will contain wrong values (13429)

This was fixed in llvm12, see
https://reviews.llvm.org/D88525
https://bugs.llvm.org/show_bug.cgi?id=47591

A patch is available here: https://reviews.llvm.org/D91833

Bug#968599: ca-certificates: update-ca-certificates breaks on custom certs in folder starting with 1 or 2

[Julian Taylor]

Package: ca-certificates
Version: 20200601
Severity: normal

Dear Maintainer,

when installing certificates into /usr/share/ca-certificates with a
folder starting with a 1 the postinst
script mangles and disables the custom certificates.

The problem is this sed in the postinst

  (echo $CERTS_ENABLED | tr ',' '\n'; \
   echo $CERTS_AVAILABLE | tr ',' '\n') | \
    sed -e 's/^[[:space:]]*//' | \
    sort | uniq -c | \
    sed -e 's/^[[:space:]]*2[[:space:]]*//' \
    -e 's/^[[:space:]]*1[[:space:]]*/!/' \
    >> /etc/ca-certificates.conf

-e 's/^[[:space:]]*1[[:space:]]*/!/' matches the 1and1 folder and thus
converts it to
!and1/cert.crt e.g.:

$ echo -e "1and1/ca.crt\n1and1/ca.crt" | uniq -c | sed -e
's/^[[:space:]]*//' | sed -e 's/^[[:space:]]*2[[:space:]]*//' -e
's/^[[:space:]]*1[[:space:]]*/!/'
!and1/ca.crt

Probably the sed should use -e 's/^[[:space:]]*1[[:space:]]\+/!/' or
even better use better ways to create the difference e.g.
https://stackoverflow.com/a/13038235

-- System Information:
Debian Release: bullseye/sid

-- 
Julian Taylor

System Administrator
Automation Services

1&1 Mail & Media Development & Technology GmbH | Brauerstraße 48 | 76135 
Karlsruhe | Germany
Phone: +49 721 91374 6334
E-Mail: julian.tay...@1und1.de | Web: www.1und1.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452

Geschäftsführer: Alexander Charles, Thomas Ludwig, Jan Oetjen, Sascha Vollmer


Member of United Internet

Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen 
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten 
Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, 
diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise 
auch immer zu verwenden.
This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient of this e-mail, you are hereby notified that saving, 
distribution or use of the content of this e-mail in any way is prohibited. If 
you have received this e-mail in error, please notify the sender and delete the 
e-mail.

Bug#885212: libmatheval: please migrate to guile-2.2

[Julian Taylor]

On 28.04.20 01:14, Rob Browning wrote:
> 
> I think we probaly either need to address this soon, or consider
> removing libmatheval from Debian.
> 
> Sometimes it's sufficient to just update the build dependency from say
> guile-2.0-dev to guile-3.0-dev and adjust some of the related versions
> in configure.ac (or configure.in), but in this case it looks like more
> might be required.
> 
> When I make those adjutments to 3.0 with the current package I see some
> SCM related type errors which I suspect are problems with the
> types/prototypes in the library, i.e. int is (and was) not
> (transparently) interchangable with SCM.
> 
> I may investigate further myself if I have time, but please don't rely
> on that.
> 
> Thanks
> 

I had checked it briefly a while ago and it is not a simple build
dependency update. There were to many api changes that need to be
adapted and at the time I didn't find a good migration guide.
Unfortunately upstream also seems to be dead. I can try to have another
look this weekend, but I may likely not find the time to port it myself
in which case I would favor removal assuming dependencies can be
migrated to something else.

Bug#951152: new archmage version breaks keepass2 documentation build

[Julian Taylor]

On 11.02.20 22:13, Mikhail Gusarov wrote:
> Hi Julian,
> 
> On 11 Feb 2020, at 21:25, Julian Taylor wrote:
> 
>> For keepass I only need to be able to build html files from the chm
>> source directory, the package has no compiled chm file one can use the
>> current cli functions on.
> 
> Please try
> https://github.com/dottedmag/archmage/commit/c8f186dff0c8da56590e900cc2a32b39e19bf08b
> 
> 
> - if it works, then I'll cut a new release and a package.
> 

it is working great, thanks



signature.asc
Description: OpenPGP digital signature

Bug#951152: new archmage version breaks keepass2 documentation build

[Julian Taylor]

On 11.02.20 21:20, Mikhail Gusarov wrote:
> Hello Julian,
> 
> On 11 Feb 2020, at 20:23, Julian Taylor wrote:
> 
>> The new archmage version breaks the documentation build of the keepass2
>> package. This is due to the (maybe accidental) removal of the availity
>> to render html files from chm sources.
> 
> Fun. While reworking pychm I had a careful look of all dependencies to see
> what subsets of API do they use, but it never occurred to me that there
> might be programs out there that use (never guaranteed to be stable) innards
> of Archmage.
> 
> Keepass packaging definitely needs to stop doing this. What's missing from
> Archmage CLI if I reimplement HTML generation from unpacked CHM files tree?
> 

I'll gladly remove the usage of the module functions when the cli
provides this functionality. Currently (and in the past) it requires a
compiled chm to extract from.

For keepass I only need to be able to build html files from the chm
source directory, the package has no compiled chm file one can use the
current cli functions on.

Bug#951152: new archmage version breaks keepass2 documentation build

[Julian Taylor]

Package: archmage
Version:  1:0.4.1-2
Severity: important
Tags: patch

The new archmage version breaks the documentation build of the keepass2
package.
This is due to the (maybe accidental) removal of the availity to render
html files from chm sources.

I have filed patch upstream to restore that ability:
https://github.com/dottedmag/archmage/pull/17

As it is required to update keepass2 and remove its python2 dependency,
could it be considered to add it to the package if upstream does not
react soon?

From 7591fd2427ebef2585347c7c567aa038a1fcab66 Mon Sep 17 00:00:00 2001
From: Julian Taylor 
Date: Sun, 9 Feb 2020 19:31:45 +0100
Subject: [PATCH] restore ability to render html from chm templates

add back the ability to export htlm files from chm templates via:

python3 -c 'import archmage.CHM; archmage.CHM.CHMFile("chmdir").process_templates("output")'

Closes gh-16
---
 archmage/CHM.py | 45 -
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/archmage/CHM.py b/archmage/CHM.py
index 93b0591..fbd37c4 100644
--- a/archmage/CHM.py
+++ b/archmage/CHM.py
@@ -82,16 +82,24 @@ class CHMFile:
 return self.cache['entries']
 
 def _entries(self):
-def get_name(chmfile, ui, out):
-path = ui.path.decode('utf-8')
-if path != '/':
-out.append(path)
-return chmlib.CHM_ENUMERATOR_CONTINUE
+if self._chm is None:
+entries = []
+for root, dirs, files in os.walk(self.sourcename):
+for f in files:
+fn = '/'.join((root.lstrip(self.sourcename), f))
+entries.append(fn)
+return entries
+else:
+def get_name(chmfile, ui, out):
+path = ui.path.decode('utf-8')
+if path != '/':
+out.append(path)
+return chmlib.CHM_ENUMERATOR_CONTINUE
 
-out = []
-if chmlib.chm_enumerate(self._chm, chmlib.CHM_ENUMERATE_ALL, get_name, out) == 0:
-sys.exit('UnknownError: CHMLIB or PyCHM bug?')
-return out
+out = []
+if chmlib.chm_enumerate(self._chm, chmlib.CHM_ENUMERATE_ALL, get_name, out) == 0:
+sys.exit('UnknownError: CHMLIB or PyCHM bug?')
+return out
 
 # retrieves the list of HTML files contained into the CHM file, **in order**
 # (that's the important bit).
@@ -327,14 +335,17 @@ class CHMEntry(object):
 
 def read(self):
 """Read CHM entry content"""
-result, ui = chmlib.chm_resolve_object(self.parent._chm, self.name.encode('utf-8'))
-if result != chmlib.CHM_RESOLVE_SUCCESS:
-return None
-
-size, content = chmlib.chm_retrieve_object(self.parent._chm, ui, 0, ui.length)
-if size == 0:
-return None
-return content
+if self.parent._chm:
+result, ui = chmlib.chm_resolve_object(self.parent._chm, self.name.encode('utf-8'))
+if result != chmlib.CHM_RESOLVE_SUCCESS:
+return None
+
+size, content = chmlib.chm_retrieve_object(self.parent._chm, ui, 0, ui.length)
+if size == 0:
+return None
+return content
+else:
+return open(self.parent.sourcename + self.name).read()
 
 def lower_links(self, text):
 """Links to lower case"""
-- 
2.20.1




signature.asc
Description: OpenPGP digital signature

Bug#943144: keepass2: Python2 removal in sid/bullseye

[Julian Taylor]

On 23.10.19 04:33, mo...@debian.org wrote:
> Source: keepass2
> Version: 2.43+dfsg-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html


The python2 dependency cannot be removed right now as the documentation
build with the python3 compatible archmage tool does not support
building html sources from chm sources anymore.

But I have filed a patch upstream to restore the functionality.
https://github.com/dottedmag/archmage/pull/17

I'll wait a bit for an upstream answer before proceeding further.

Bug#949536: New upstream version 2.44 - please package

[Julian Taylor]

On 21.01.20 20:24, Marc Meledandri wrote:
> Package: keepass2
> Version: 2.43+dfsg-1
> 
> Dear Maintainer,
> 
> Please package KeePass 2.44. List of fixes and improvements:
> https://keepass.info/news/n200120_2.44.html
> 
> Thanks!
> 

It appears the new python3 compatible archmage tool does not allow
creating html files from chm source files anymore [0].

So the documentation cannot be built anymore. I'll wait a bit for an
upstream reply and if this does not work probably remove the
documentation from keepass until a fix is available.

[0] https://github.com/dottedmag/archmage/issues/16

Bug#842541: Why keepass2 opens TCP ports

[Julian Taylor]

On 27.01.20 07:30, Felix Dörre wrote:
> Hi,
> 
> I found out, why keepass2 opens TCP ports. However on my system, keepass
> opens two TCP ports:
> 
> The older one (that is already reported in this bug report) comes from
> strange behavior in mono itself. I opened a pull request against mono to
> fix it: https://github.com/mono/mono/pull/18583
> 
> The newer one that presumable got added in the meantime is an IPC
> implementation that does things like keeping keepass single-instance and
> sending other events to a currently running instance (e.g. triggering
> auto-typing). I consider this feature a security risk and would rather
> not have it in my password manager. I've added a pull request to the
> debian repository to deactivate this feature:
> https://salsa.debian.org/dotnet-team/keepass2/merge_requests/1
> 
> With these two changes, keepass2 seems tame now and does not open TCP
> ports anymore on my system.
> 


I agree a tcp port for this rather simple usecase is overkill, it could
be replaced with a unix domain socket/fifo in $XDG_RUNTIME_DIR or some
other ipc method.

I would prefer to not hard disable it by commenting the code, but rather
either make it configurable or replace it with a unix domain socket/fifo.

I am sure upstream would also accept such a patch.

Bug#942359: Please provide libfftw3-long3 on all platforms

[Julian Taylor]

On 15.10.19 08:47, Ole Streicher wrote:
> Package:libfftw3-long3
> Version: 3.3.8-2
> Severity: wishlist
> 
> Hi,
> 
> I have a package (cubature) that generates an include file (clencurt.h)
> with a small helper program during build. This helper program uses the
> "long double" version of libfftw (libfftw3-long3).
> 
> Unfortunately, libfftw3-long3 is only available on some architectures
> and is missing on armel, armhf, mipsel and some ports. It seems that
> these are the architectures where sizeof(long double) == sizeof(long),
> which make the a separate "long double" version redundant.
> 
> However, the missing "long double" version breaks programs that use the
> "long" version of the API. I could in principle rewrite the helper
> program to support both; however this requires a lot of renaming and is
> not really suitable for a Debian patch.
> 
> Therefore, I would ask to provide a "long double" version on all
> machines which support the "long double" C data type.
> 

This would require disabling the testsuite on these architectures as
with no real long doubles they will likely fail (which I think is the
original reason the package is not built, but I'd have to look it up).

Imo it is also dangerous to provide a long double numerical library on
platforms that do not really support it. You likely will just get wrong
results.

I think it would be better to just not build cubature on these platforms
depending on how significant the long double support is.
Have you engaged with upstream to check if they want to make long double
support optional?



signature.asc
Description: OpenPGP digital signature

Bug#919929: blis breaks python-scipy autopkgtest

[Julian Taylor]

On 29.01.19 12:01, Graham Inggs wrote:
> Hi Paul
> 
> On 2019/01/20 21:09, Paul Gevers wrote:
>> With a recent upload of blis the autopkgtest of python-scipy fails in
>> testing when that autopkgtest is run with the binary packages of blis
>> from unstable. It passes when run with only packages from testing. In
>> tabular form:
>>     pass    fail
>> blis   from testing    0.5.1-5
>> python-scipy   from testing    1.1.0-2
>> all others from testing    from testing
> 
> From testing's test logs [1], python-scipy 1.1.0-2 passed with
> blis/0.5.1-5 on 2019-01-21 05:22:48 UTC.  It then passed with
> blis/0.5.1-6 and blis/0.5.1-7, but failed with blis/0.5.1-7 on
> 2019-01-27 17:55:32 UTC.
> 
> From unstable's test logs [2], python-scipy 1.1.0-2 seems to have many
> intermittent failures since 2018-12-02.
> 
> I'm unsure what to do with this bug, perhaps re-assign to python-scipy
> only?

I am confused, scipy does not use blis.
It tests libblas, openblas and atlas but blis was so far I know never
configured as a blas source in the tests.
Unless something has changed with those packages that they pull blis
this might be a false positive.

If blis is ready enough to be used prime time, let me know we can add it
to numpy's and scipy's testsuites.

Bug#915738: rules workaround

[Julian Taylor]

this rules change should disable unrolling for fortran on s390x.
I'm currently checking if we can upload a new upstream without breaking
rdeps, if not I'll add this to 1.11.0

build-python%:
ifeq ($(DEB_HOST_ARCH),s390x)
# gcc bug 906198
NPY_DISTUTILS_APPEND_FLAGS=1 FOPT="-fno-unroll-loops" python$*
setup.py config_fc --noarch build;
NPY_DISTUTILS_APPEND_FLAGS=1 FOPT="-fno-unroll-loops"
python$*-dbg setup.py config_fc
else
python$* setup.py config_fc --noarch build;
python$*-dbg setup.py config_fc
endif



signature.asc
Description: OpenPGP digital signature

Bug#907335: similar issue

[Julian Taylor]

this problem probably has the same python change as cause as this issue:

https://github.com/PyCQA/pycodestyle/issues/786
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908700

Bug#897496: python-pathlib: diff for NMU version 1.0.1-2.1

[Julian Taylor]

Control: tags 897496 + pending
Control: tags 897496 + patch
Control: user debian-rele...@lists.debian.org
Control: usertags 897496 + bsp-2018-10-de-karlsruhe

Dear maintainer,

I've prepared an NMU for python-pathlib (versioned as 1.0.1-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
diff -Nru python-pathlib-1.0.1/debian/changelog
python-pathlib-1.0.1/debian/changelog
--- python-pathlib-1.0.1/debian/changelog   2015-06-25 10:02:25.0
+0200
+++ python-pathlib-1.0.1/debian/changelog   2018-10-27 19:02:33.0
+0200
@@ -1,3 +1,11 @@
+python-pathlib (1.0.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * socket-test-fix.patch:
+Adapt testcase to work with python2 exception type (Closes: #897496)
+
+ -- Julian Taylor   Sat, 27 Oct 2018
19:02:33 +0200
+
 python-pathlib (1.0.1-2) unstable; urgency=medium

   * Enable reproducible build py patching generation of manpage
diff -Nru python-pathlib-1.0.1/debian/patches/series
python-pathlib-1.0.1/debian/patches/series
--- python-pathlib-1.0.1/debian/patches/series  1970-01-01
01:00:00.0 +0100
+++ python-pathlib-1.0.1/debian/patches/series  2018-10-27
18:59:43.0 +0200
@@ -0,0 +1 @@
+socket-test-fix.patch
diff -Nru python-pathlib-1.0.1/debian/patches/socket-test-fix.patch
python-pathlib-1.0.1/debian/patches/socket-test-fix.patch
--- python-pathlib-1.0.1/debian/patches/socket-test-fix.patch   1970-01-01
01:00:00.0 +0100
+++ python-pathlib-1.0.1/debian/patches/socket-test-fix.patch   2018-10-27
19:02:33.0 +0200
@@ -0,0 +1,18 @@
+Description: adapt test exception to python2
+Author: Julian Taylor 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897496
+Bug: https://bitbucket.org/pitrou/pathlib/issues/32
+
+Index: python-pathlib-1.0.1/test_pathlib.py
+===
+--- python-pathlib-1.0.1.orig/test_pathlib.py
 python-pathlib-1.0.1/test_pathlib.py
+@@ -1687,7 +1687,7 @@ class _BasePathTest(object):
+ self.addCleanup(sock.close)
+ try:
+ sock.bind(str(P))
+-except OSError as e:
++except (OSError, socket.error) as e:
+ if "AF_UNIX path too long" in str(e):
+ self.skipTest("cannot bind Unix socket: " + str(e))
+ self.assertTrue(P.is_socket())

Bug#880245: New version of statsmodels is out possibly fixing important bug - any volunteer

[Julian Taylor]

On 10/26/18 11:33 PM, Andreas Tille wrote:
> Hi Yaroslav,
> 
> On Fri, Oct 26, 2018 at 08:59:57AM -0400, Yaroslav Halchenko wrote:
>>
>>> I guess this went out of your focus.  I tried my best to update Git[1] to
>>> version 0.9.0.  The package build process stumbles about doc creation:
>>
>> THANKS!
> 
> You (and all other Uploaders) are welcome.
>  
>>> #../tools/examples_rst.py
>>> ../tools/fold_toc.py build/html/index.html
>>> Traceback (most recent call last):
>>>   File "../tools/fold_toc.py", line 12, in 
>>> doc = open(filename, encoding='utf8').read()
>>
>> so the script now is python3. adjust shebang?
> 
> Only adjusting shebang is not sufficient.  The file tools/fold_toc.py
> is definitely Python2.  I tried:
> 
> $ 2to3 -w fold_toc.py 
> RefactoringTool: Skipping optional fixer: buffer
> RefactoringTool: Skipping optional fixer: idioms
> RefactoringTool: Skipping optional fixer: set_literal
> RefactoringTool: Skipping optional fixer: ws_comma
> RefactoringTool: No changes to fold_toc.py
> RefactoringTool: Files that need to be modified:
> RefactoringTool: fold_toc.py
> 
> 
> But for whatever reason it is not changed automatically.  Am I missing
> something?
> 
> 
>> alternative might work to patch it with smth like
>>
>>   from io import open
> 
> I have not tried this yet.
> 
> Any further hint (preferably somebody else taking over)?
> 
> Kind regards
> 
> Andreas.
> 


I have pushed an update to git that fixes the build for me and filed
https://github.com/statsmodels/statsmodels/pull/5348 for the problem.

Bug#880245: New version of statsmodels is out possibly fixing important bug - any volunteer

[Julian Taylor]

On 10/26/18 11:33 PM, Andreas Tille wrote:
> Hi Yaroslav,
> 
> On Fri, Oct 26, 2018 at 08:59:57AM -0400, Yaroslav Halchenko wrote:
>>
>>> I guess this went out of your focus.  I tried my best to update Git[1] to
>>> version 0.9.0.  The package build process stumbles about doc creation:
>>
>> THANKS!
> 
> You (and all other Uploaders) are welcome.
>  
>>> #../tools/examples_rst.py
>>> ../tools/fold_toc.py build/html/index.html
>>> Traceback (most recent call last):
>>>   File "../tools/fold_toc.py", line 12, in 
>>> doc = open(filename, encoding='utf8').read()
>>
>> so the script now is python3. adjust shebang?
> 
> Only adjusting shebang is not sufficient.  The file tools/fold_toc.py
> is definitely Python2.  I tried:
> 
> $ 2to3 -w fold_toc.py 
> RefactoringTool: Skipping optional fixer: buffer
> RefactoringTool: Skipping optional fixer: idioms
> RefactoringTool: Skipping optional fixer: set_literal
> RefactoringTool: Skipping optional fixer: ws_comma
> RefactoringTool: No changes to fold_toc.py
> RefactoringTool: Files that need to be modified:
> RefactoringTool: fold_toc.py
> 
> 
> But for whatever reason it is not changed automatically.  Am I missing
> something?
> 
> 
>> alternative might work to patch it with smth like
>>
>>   from io import open
> 
> I have not tried this yet.
> 
> Any further hint (preferably somebody else taking over)?
> 
> Kind regards
> 
> Andreas.
> 

I'll have a look at the issue now.

Bug#903579: cythonize at build patch

[Julian Taylor]

tags -1 + patch
forwarded -1 https://github.com/matplotlib/basemap/issues/436
user debian-rele...@lists.debian.org
usertags -1 + bsp-2018-10-de-karlsruhe
thanks

Attached a patch which cythonizes the files during the package build and
fixes the README issue.
I have also filed an upstream bug.
diff --git a/debian/control b/debian/control
index 06cb00d..c8982f1 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Maintainer: Sandro Tosi 
 Uploaders:
  Debian Python Modules Team ,
 Build-Depends:
+ cython3,
  debhelper (>= 8.0.0),
  dh-python,
  libgeos-dev,
diff --git a/debian/docs b/debian/docs
index 45b0503..e502992 100644
--- a/debian/docs
+++ b/debian/docs
@@ -1,2 +1,2 @@
 FAQ
-README
+README.md
diff --git a/debian/rules b/debian/rules
index 392e96f..118d944 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,11 +10,13 @@ LIB := $$(python -c "from distutils.command.build import build ; from distutils.
 override_dh_auto_install:
 	set -e ; \
 	for python in $(PY2VERS); do \
+		cython3 -2 src/*pyx; \
 		$$python setup.py install --prefix $(CURDIR)/debian/python-mpltoolkits.basemap/usr --install-layout=deb; \
 		$$python-dbg setup.py install --prefix $(CURDIR)/debian/python-mpltoolkits.basemap-dbg/usr --install-layout=deb; \
 	done
 	set -e ; \
 	for python in $(PY3VERS); do \
+		cython3 -3 src/*pyx; \
 		$$python setup.py install --prefix $(CURDIR)/debian/python3-mpltoolkits.basemap/usr --install-layout=deb; \
 		$$python-dbg setup.py install --prefix $(CURDIR)/debian/python3-mpltoolkits.basemap-dbg/usr --install-layout=deb; \
 	done

Bug#912020: keepass2: Exception prevents start : System.Exception: Magic number is wrong: 542

[Julian Taylor]

what is the value  of the $TERM environment variable?

try if this works:

TERM=xterm keepass2

Bug#911988: reintroduce fixed python2 package for rdepends

[Julian Taylor]

tags 911988 + patch
thanks

Ops I forgot to adapt a runtime check, attached a fixed debdiff
diff --git a/debian/changelog b/debian/changelog
index f266461..a94e1bb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+txtorcon (18.0.2-3) unstable; urgency=medium
+
+  * reintroduce fixed Python 2 package needed by reverse dependencies
+do not install python3 files to avoid failure during installation
+add fix-controller-py3check.patch to correct the python3 runtime check
+Closes: #911271
+
+ -- Julian Taylor   Fri, 26 Oct 2018 22:30:43 
+0200
+
 txtorcon (18.0.2-2) unstable; urgency=medium
 
   * No longer builds a Python 2 package (Closes: #905253)
diff --git a/debian/control b/debian/control
index 0eac5fa..a20741c 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,14 @@ Build-Depends: debhelper (>= 9),
dh-python,
graphviz,
lsof,
+   python-all,
+   python-geoip,
+   python-ipaddress,
+   python-mock,
+   python-repoze.sphinx.autointerface,
+   python-setuptools,
+   python-sphinx,
+   python-twisted,
python3-all,
python3-geoip,
python3-mock,
@@ -21,6 +29,29 @@ Vcs-Browser: 
https://salsa.debian.org/pkg-privacy-team/txtorcon
 Vcs-Git: https://salsa.debian.org/pkg-privacy-team/txtorcon.git
 Homepage: https://github.com/meejah/txtorcon
 
+Package: python-txtorcon
+Architecture: all
+Depends: python-geoip,
+ python-ipaddress,
+ python-twisted,
+ python-zope.interface,
+ ${misc:Depends},
+ ${python:Depends}
+Suggests: tor
+Provides: ${python:Provides}
+Description: Twisted-based asynchronous Tor control protocol implementation 
(Python 2)
+ txtorcon main feature is to present an asynchronous API to speak the Tor
+ client protocol in Python. It also provides abstractions to track and get
+ updates about Tor's state and current configuration (including writing it to
+ Tor or disk), along with helpers to asynchronously launch slave instances of
+ Tor including Twisted endpoint support.
+ .
+ Twisted is an event-driven networking engine written in Python and Tor is an
+ onion-routing network designed to improve people's privacy and anonymity on 
the
+ Internet.
+ .
+ This package contains the Python 2 module.
+
 Package: python3-txtorcon
 Architecture: all
 Depends: python3-geoip,
diff --git a/debian/patches/fix-controller-py3check.patch 
b/debian/patches/fix-controller-py3check.patch
new file mode 100644
index 000..3e38df3
--- /dev/null
+++ b/debian/patches/fix-controller-py3check.patch
@@ -0,0 +1,20 @@
+Description: adapt python3 check for missing file
+Author: Julian Taylor 
+
+The file is not installed in python2 to avoid pycompile trying to compile it
+with python2.
+For this the runtime check needs to be adapted.
+
+Index: txtorcon/txtorcon/controller.py
+===
+--- txtorcon.orig/txtorcon/controller.py
 txtorcon/txtorcon/controller.py
+@@ -42,7 +42,7 @@ from .interface import ITor
+ try:
+ from .controller_py3 import _AsyncOnionAuthContext
+ HAVE_ASYNC = True
+-except SyntaxError:
++except Exception:
+ HAVE_ASYNC = False
+ 
+ if sys.platform in ('linux', 'linux2', 'darwin'):
diff --git a/debian/patches/series b/debian/patches/series
index ed80250..6bfd16d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+fix-controller-py3check.patch
 disable_test_for_invalid_geoip.patch
 remove-privacy-infringing-buttons.patch
 remove-privacy-infringing-JS.patch
diff --git a/debian/rules b/debian/rules
index a334f92..aa0b193 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,7 @@
 export PYBUILD_NAME=txtorcon
 
 %:
-   dh $@ --with=python3,sphinxdoc --buildsystem=pybuild
+   dh $@ --with=python2,python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_build:
PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N -bhtml docs/ 
docs/_build/html # HTML generator
@@ -11,17 +11,28 @@ override_dh_auto_build:
 
 override_dh_auto_install:
dh_auto_install -O--buildsystem=pybuild
+   # don't install py3 files in py2 as they don't compile during 
installation
+   find debian/python-txtorcon/ -name controller_py3.py -delete
+   mkdir -p debian/python-txtorcon/usr/share/doc/python-txtorcon
mkdir -p debian/python3-txtorcon/usr/share/doc/python3-txtorcon
set -e && \
+   for data_src in README.rst TODO examples; do \
+   mv debian/python-txtorcon/usr/share/txtorcon/$$data_src \
+   debian/python-txtorcon/usr/share/doc/python-txtorcon; \
+   done
+   set -e && \
for data_src in README.rst TODO examples; do \
mv debian/python3-txtorcon/usr/share/txtorcon/$$data_src \
debian/python3-txtorcon/us

Bug#911271: txtorcon patch submitted

[Julian Taylor]

I have submitted a patch to reintroduce the patch in txtorcon:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911988

Bug#911988: reintroduce fixed python2 package for rdepends

[Julian Taylor]

Package: txtorcon
Version:  18.0.2-2
Severity: important

The removal of the python2 package in #905253 due to a packaging bug
made its reverse dependencies RC buggy.
As upstream still supports python2 [0], it is tested in the package
build and its rdepends and buster will still ship with python2 please
reintroduce the python2 package.

Attached a debdiff that fixes the installation of the python3 only file
in the python2 package.


[0] https://github.com/meejah/txtorcon
diff --git a/debian/changelog b/debian/changelog
index f266461..b644918 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+txtorcon (18.0.2-3) unstable; urgency=medium
+
+  * reintroduce fixed Python 2 package needed by reverse dependencies
+Closes: #911271
+
+ -- Julian Taylor   Fri, 26 Oct 2018 22:30:43 
+0200
+
 txtorcon (18.0.2-2) unstable; urgency=medium
 
   * No longer builds a Python 2 package (Closes: #905253)
diff --git a/debian/control b/debian/control
index 0eac5fa..a20741c 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,14 @@ Build-Depends: debhelper (>= 9),
dh-python,
graphviz,
lsof,
+   python-all,
+   python-geoip,
+   python-ipaddress,
+   python-mock,
+   python-repoze.sphinx.autointerface,
+   python-setuptools,
+   python-sphinx,
+   python-twisted,
python3-all,
python3-geoip,
python3-mock,
@@ -21,6 +29,29 @@ Vcs-Browser: 
https://salsa.debian.org/pkg-privacy-team/txtorcon
 Vcs-Git: https://salsa.debian.org/pkg-privacy-team/txtorcon.git
 Homepage: https://github.com/meejah/txtorcon
 
+Package: python-txtorcon
+Architecture: all
+Depends: python-geoip,
+ python-ipaddress,
+ python-twisted,
+ python-zope.interface,
+ ${misc:Depends},
+ ${python:Depends}
+Suggests: tor
+Provides: ${python:Provides}
+Description: Twisted-based asynchronous Tor control protocol implementation 
(Python 2)
+ txtorcon main feature is to present an asynchronous API to speak the Tor
+ client protocol in Python. It also provides abstractions to track and get
+ updates about Tor's state and current configuration (including writing it to
+ Tor or disk), along with helpers to asynchronously launch slave instances of
+ Tor including Twisted endpoint support.
+ .
+ Twisted is an event-driven networking engine written in Python and Tor is an
+ onion-routing network designed to improve people's privacy and anonymity on 
the
+ Internet.
+ .
+ This package contains the Python 2 module.
+
 Package: python3-txtorcon
 Architecture: all
 Depends: python3-geoip,
diff --git a/debian/rules b/debian/rules
index a334f92..aa0b193 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,7 @@
 export PYBUILD_NAME=txtorcon
 
 %:
-   dh $@ --with=python3,sphinxdoc --buildsystem=pybuild
+   dh $@ --with=python2,python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_build:
PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N -bhtml docs/ 
docs/_build/html # HTML generator
@@ -11,17 +11,28 @@ override_dh_auto_build:
 
 override_dh_auto_install:
dh_auto_install -O--buildsystem=pybuild
+   # don't install py3 files in py2 as they don't compile during 
installation
+   find debian/python-txtorcon/ -name controller_py3.py -delete
+   mkdir -p debian/python-txtorcon/usr/share/doc/python-txtorcon
mkdir -p debian/python3-txtorcon/usr/share/doc/python3-txtorcon
set -e && \
+   for data_src in README.rst TODO examples; do \
+   mv debian/python-txtorcon/usr/share/txtorcon/$$data_src \
+   debian/python-txtorcon/usr/share/doc/python-txtorcon; \
+   done
+   set -e && \
for data_src in README.rst TODO examples; do \
mv debian/python3-txtorcon/usr/share/txtorcon/$$data_src \
debian/python3-txtorcon/usr/share/doc/python3-txtorcon; 
\
done
+   chmod 644 
debian/python-txtorcon/usr/share/doc/python-txtorcon/examples/*.py
chmod 644 
debian/python3-txtorcon/usr/share/doc/python3-txtorcon/examples/*.py
+   rm -r debian/python-txtorcon/usr/share/txtorcon
rm -r debian/python3-txtorcon/usr/share/txtorcon
 
 override_dh_compress:
dh_compress -Xlaunch_tor_with_simplehttpd.py -O--buildsystem=pybuild
 
 override_dh_auto_test:
+   PYTHONPATH=. trial --reporter=text test
PYTHONPATH=. trial3 --reporter=text test

Bug#906215: further issues

[Julian Taylor]

Also with this patch foolscap is still currently failing a test.
I have filed an issue upstream:
https://github.com/warner/foolscap/issues/42

Bug#911271: [Pkg-privacy-maintainers] Bug#911271: foolscap: (Build) Depends on non existing python-txtorcon

[Julian Taylor]

On 18.10.18 14:31, Julian Taylor wrote:
> On 18.10.18 14:28, Antoine Beaupré wrote:
>> On 2018-10-18 13:26:28, Julian Taylor wrote:
>>> On 18.10.18 01:07, Antoine Beaupré wrote:
>>>> On 2018-10-18 00:16:15, Sebastian Andrzej Siewior wrote:
>>>>> Package: foolscap
>>>>> Version: 0.13.1-1
>>>>> Severity: serious
>>>>>
>>>>> txtorcon does not build the Python2 variant (python-txtorcon) since its
>>>>> last upload, only the python3 one (python3-txtorcon) remains.
>>>>>
>>>>> As of now the package can't be built due to missing packages.
>>>>
>>>> Seems to me foolscap should be ported to python rather than to force
>>>> txtorcon to support a (soon to be) obsolete version of python. :)
>>>>
>>>
>>> foolscap is based on twisted which seems to have gotten python3 support
>>> recently. First one has to check if foolscap can work with python3 twisted.
>>>
>>> Please do not remove python2 packages from the bottom up, start from the
>>> dependency leaves and work down instead of just breaking everything above.
>>> txtorcon still supports python2 according to their github page.
>>
>> If you look at the txtorcon removal, you'll see it fixed RC bugs about
>> the py2 version, so it was not just a gratitious change...
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905253
>>
>> A.
>>
> 
> that bug looks more like a packaging error or fixable installation error
> than a bug in the py2 version.
> removing the py2 package making other packages rc buggy looks like
> overkill without prior consultation of reverse dependencies.
> 

sorry I may have been a bit brief. The bug you are referencing is the
error output of the pycompile step during package installation. The
python2 package installs a python3 only file (not the py3.py ending) so
it fails.
This can be caused by either upstreams installer incorrectly installing
py3 files in the py2 variant (as upstream installation usually does not
have this pycompile step a stray py3 file does not harm much) or less
likely the package installs the file in the wrong package.
In any case the fix should be simple, the package can take care to not
install py3 files in the py2 package. I can help by providing a patch if
this solution is acceptable.

Regardless we should check if foolscap can also use python3.
But even if that is possible I still would like to keep the python2
version as foolscap and twisted only so recently got py3 support users
will still need the python2 versions for a while until those that had to
wait for migration can migrate.

Bug#911271: [Pkg-privacy-maintainers] Bug#911271: foolscap: (Build) Depends on non existing python-txtorcon

[Julian Taylor]

On 18.10.18 14:28, Antoine Beaupré wrote:
> On 2018-10-18 13:26:28, Julian Taylor wrote:
>> On 18.10.18 01:07, Antoine Beaupré wrote:
>>> On 2018-10-18 00:16:15, Sebastian Andrzej Siewior wrote:
>>>> Package: foolscap
>>>> Version: 0.13.1-1
>>>> Severity: serious
>>>>
>>>> txtorcon does not build the Python2 variant (python-txtorcon) since its
>>>> last upload, only the python3 one (python3-txtorcon) remains.
>>>>
>>>> As of now the package can't be built due to missing packages.
>>>
>>> Seems to me foolscap should be ported to python rather than to force
>>> txtorcon to support a (soon to be) obsolete version of python. :)
>>>
>>
>> foolscap is based on twisted which seems to have gotten python3 support
>> recently. First one has to check if foolscap can work with python3 twisted.
>>
>> Please do not remove python2 packages from the bottom up, start from the
>> dependency leaves and work down instead of just breaking everything above.
>> txtorcon still supports python2 according to their github page.
> 
> If you look at the txtorcon removal, you'll see it fixed RC bugs about
> the py2 version, so it was not just a gratitious change...
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905253
> 
> A.
> 

that bug looks more like a packaging error or fixable installation error
than a bug in the py2 version.
removing the py2 package making other packages rc buggy looks like
overkill without prior consultation of reverse dependencies.

Bug#911271: [Pkg-privacy-maintainers] Bug#911271: foolscap: (Build) Depends on non existing python-txtorcon

[Julian Taylor]

On 18.10.18 01:07, Antoine Beaupré wrote:
> On 2018-10-18 00:16:15, Sebastian Andrzej Siewior wrote:
>> Package: foolscap
>> Version: 0.13.1-1
>> Severity: serious
>>
>> txtorcon does not build the Python2 variant (python-txtorcon) since its
>> last upload, only the python3 one (python3-txtorcon) remains.
>>
>> As of now the package can't be built due to missing packages.
> 
> Seems to me foolscap should be ported to python rather than to force
> txtorcon to support a (soon to be) obsolete version of python. :)
> 
> A.
> 

foolscap is based on twisted which seems to have gotten python3 support
recently. First one has to check if foolscap can work with python3 twisted.

Please do not remove python2 packages from the bottom up, start from the
dependency leaves and work down instead of just breaking everything above.
txtorcon still supports python2 according to their github page.

Bug#896060: python3-scipy: New upstream version available

[Julian Taylor]

On 19.04.2018 02:22, Jan Medlock wrote:
> Package: python3-scipy
> Version: 0.19.1-2
> Severity: minor
> 
> Dear Maintainer,
> Upstream released version 1.0.0 on 25 October 2017.
> 
> In particular, new differential-equation and optimization solvers have
> been added.
> 
> Please let me know if I can help.
> 


Unfortunately scipy.weave needs to be packaged first or all reverse
dependencies removed as it has been removed from scipy itself.
https://github.com/scipy/weave

Bug#892055: ITP: keepass2-plugin-keepasshttp -- KeePass plugin to expose password entries securely over HTTP

[Julian Taylor]

Package: wnpp
Severity: wishlist
Owner: Julian Taylor <jtaylor.deb...@googlemail.com>

* Package name: keepass2-plugin-keepasshttp
  Version : 1.8.4.2
  Upstream Author : Perry Nguyen <pfngu...@hanhuy.com>
* URL : https://github.com/pfn/keepass
* License : GPL3
  Programming Lang: C#
  Description : KeePass plugin to expose password entries securely over HTTP

 KeePassHttp is a plugin for KeePass 2.x and provides a secure means of
 exposing KeePass entries via HTTP for clients to consume.
 Features:
  - returns all matching entries for a given URL 
  - updates entries
  - secure exchange of entries
  - notifies user if entries are delivered
  - user can allow or deny access to single entries
  - works only if the database is unlocked
  - request for unlocking the database if it is locked while connecting
  - searches in all opened databases (if user activates this feature)
  - Whenever events occur, the user is prompted either by tray notification or
requesting interaction (allow/deny/remember).



signature.asc
Description: OpenPGP digital signature

Bug#863672: performance critical libyuv built with Os

[Julian Taylor]

Package: firefox
Version:  53.0.is.52.0.2-1
Severity: normal


libyuv which is a performance critical library for firefix is built with
-Os which is horrible for performance for it.
In particular row_common.cc which contains the generic parts of the
color transformation code:

See:
https://buildd.debian.org/status/fetch.php?pkg=firefox=amd64=53.0.is.52.0.2-1=1492644908=0

/usr/bin/g++ -std=gnu++11 -o row_common.o -c  ...   -fPIC
-DMOZILLA_CLIENT -include
/PKGBUILDDIR/build-browser/mozilla-config.h -MD -MP -MF
.deps/row_common.o.pp -Wdate-time -D_FORTIFY_SOURCE=2 -Wall
-Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual
-Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code
-Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat
-Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations
-Wno-error=array-bounds -fno-lifetime-dse -fstack-protector-strong
-Wformat -Werror=format-security -fno-schedule-insns2 -fno-lifetime-dse
-fno-delete-null-pointer-checks -fno-exceptions -fno-strict-aliasing
-fno-rtti -ffunction-sections -fdata-sections -fno-exceptions
-fno-math-errno -pthread -pipe  -g -freorder-blocks -Os
-fomit-frame-pointer
/PKGBUILDDIR/media/libyuv/source/row_common.cc


The problematic part is the YuvPixel function which is called in loops
and in turn calls tiny clamp functions.
Os disables inlining so this causes massive overhead.
This is the top cpu profile on sites which e.g. display videos.
  17.25%  libxul.so   [.] YuvPixel▒
   6.58%  libxul.so   [.] Clamp   ▒
   6.46%  libxul.so   [.] clamp255

The problem is not as bad as it looks as this generic code is only
executed on machines that do not have SSSE3, AVX2 or NEON (see
convert_argb.cc)
But there are still plenty useful cpus that do not have these
instruction sets and are crippled by the compiler flags used.

Is it possible to compile this library with O3 to allow the compiler to
vectorize it with the best available generic instruction set (e.g. SSE2
on x64).

cheers,
Julian Taylor



signature.asc
Description: OpenPGP digital signature

Bug#860063: fsolve docs should state that it cannot solve over- or under-determined problems

[Julian Taylor]

On 11.04.2017 03:07, James Van Zandt wrote:
> Package: python-scipy
> Version: 0.18.1
> 
> 
> I have a MATLAB program that uses fsolve() from the optimization
> toolbox.  I found that scipy offers a similar function.  I spent a fair
> amount of time translating my program into Python, only to discover that
> the scipy implementation (unlike the MATLAB one) requires that the
> number of functions and the number of variables be equal.  The
> documentation for the underlying minpack programs (hybrd and hybrj)
> makes this clear, but the scipy documentation does not.  It should.  I
> suggest the attached patch. 
> 
> (It might also be a good idea to add a mention of leastsq, which can
> handle an over- or under-determined problem.)
> 
> - Jim Van Zandt
> 

hi,
this is an upstream issue.
Please report it here:
https://github.com/scipy/scipy/

cheers,
Julian

Bug#859019: your mail

[Julian Taylor]

On 04.04.2017 20:18, Ivo De Decker wrote:
> Control: severity -1 normal
> 
> Hi,
> 
> On Sat, Apr 01, 2017 at 01:18:08PM +0200, Julian Taylor wrote:
>> severity 859019 serious
>> thanks
>>
>> the issues are very much RC, stretch should not be stuck with a .0 numpy
>> release.
> 
> Just stating that won't make it RC. If you want your upload unblocked, the
> proper way to do that is to file an unblock request with an explanation, not
> by filing random RC bugs for stuff that is not RC. Do not inflate the severity
> of this bug again.

do you prefer separate bugs for each issue?
Imo thats just a waste of time.
The unblock request will be filed when it's passed its unstable cooking
time.

Bug#859019: (no subject)

[Julian Taylor]

severity 859019 serious
thanks

the issues are very much RC, stretch should not be stuck with a .0 numpy
release.

Bug#859019: new bugfix release available

[Julian Taylor]

Package: python-numpy
Version:  1:1.12.0-2
Severity: serious

hi,
A new bug release is available for numpy. It is almost exclusively regression 
fixes in 1.12.0 and should be included in stretch.
In case you want to go with backports I have marked the issues I consider 
important.

* `#8483 `__: BUG: Fix wrong future 
nat warning and equiv type logic error...

important (already in debian package)
* `#8489 `__: BUG: Fix wrong masked 
median for some special cases

* `#8490 `__: DOC: Place np.average 
in inline code
* `#8491 `__: TST: Work around 
isfinite inconsistency on i386

important
* `#8494 `__: BUG: Guard against 
replacing constants without '_' spec in f2py.
* `#8524 `__: BUG: Fix mean for float 
16 non-array inputs for 1.12
* `#8571 `__: BUG: Fix calling python 
api with error set and minor leaks for...

important
* `#8602 `__: BUG: Make iscomplexobj 
compatible with custom dtypes again
* `#8618 `__: BUG: Fix undefined 
behaviour induced by bad __array_wrap__

important
* `#8648 `__: BUG: Fix 
MaskedArray.__setitem__
* `#8659 `__: BUG: PPC64el machines 
are POWER for Fortran in f2py
* `#8665 `__: BUG: Look up methods on 
MaskedArray in `_frommethod`
* `#8674 `__: BUG: Remove extra digit 
in binary_repr at limit

important
* `#8704 `__: BUG: Fix deepcopy 
regression for empty arrays.

important
* `#8707 `__: BUG: Fix ma.median for 
empty ndarrays

cheers,
Julian



signature.asc
Description: OpenPGP digital signature

Bug#849593: libfftw3-single3: dependencies in shlibs file not tight enough (Was: Bug#849589: ardour: undefined symbol: fftwf_make_planner_thread_safe)

[Julian Taylor]

On 30.12.2016 18:17, Ghislain Vaillant wrote:
>> The goal is for dpkg-shlibdeps to generate a dependency like
>> "libfftw3-single3 (>= 3.3.5)" for any package which uses
>> fftwf_make_planner_thread_safe. This is needed otherwise you may get a
>> linker error like ardour does, and it's is done by using the symbols or
>> shlibs systems as described in policy 8.6.
> 
> I am personally not familiar with the symbols stuff, so it would be up
> to somewhat from the team or yourself to provide a patch for this issue.
> 

A symbol file for fftw3 would be good, I never did it as it a fair bit
of work as the symbols are arch specific. At the time it wasn't really
necessary as fftw did not add new public symbols in ages, this was not
the case for the last update which I did not do.

Stricter shlibs is simple, though it may make some backward installs a
bit more tedious as you need to pull fftw3 too, but not a really big
deal. I may be able to look into it soon.

Note the majority of symbols fftw3 exports are private, a patch I made a
while back to only export the real public ones (FFTW_EXTERN marked ones)
was rejected upstream.

cheers,
Julian

Bug#844479: zeromq3: zeromq 4.2.0 breaks tango

[Julian Taylor]

On 04.12.2016 14:14, Luca Boccassi wrote:
> 
>> But on how to fix this. Given [0] you seem to be just passing out the
>> pointer to your internal buffer written without padding out to the user
>> via zmq_msg_data (?)
>>
>> The documentation of that function states that you must not access
>> zmq_msg_t directly, so if nobody actual does do so regardless zmq can
>> change this structure and stay compatible?
>> If so can zmq insert alignment padding between the message headers and
>> the payload so zmq_msg_data returns aligned data?
> 
> This is an interesting suggestion so I had a look, but unfortunately I
> don't think it can be done.
> 
> The pointer returned points directly to the buffer as it was written by
> the TCP/IPC socket read. Since it's being written as it is received,
> there is no way at that stage to know what's header and what's payload,
> and insert padding. The actual decoding of the data is done at a later
> stage, when it's too late to get away with just adjusting pointers.
> 

Thanks for the explanation. It is probably better to focus on fixing
tango then.

> 
>> This would be very good for compatibility, on non-x86 arches it might
>> even be better for performance. Unaligned access can be very slow on
>> some of the less powerful cpus.
>>
>> (Also even on x86 you can get into alignment issues due to these
>> buffers, in particular with numerical applications where
>> auto-vectorization by the compilers is involved)
>>
>> [0] http://lists.zeromq.org/pipermail/zeromq-dev/2016-November/031096.html
> 
> Ultimately, performance-wise, this change from Jens allow one less
> malloc and copy per message (it became effectively a zero-copy receive
> from the point of view of userspace), and I'd be extremely surprised if
> the cost of unalignment would out-weight the gains.
> 

You have to consider that when the payload consists of a lot of data
that has alignment requirements e.g. lots of integers or floats every
access to the payload buffer is unaligned. With expensive unaligned
access you might be better of copying to an aligned buffer than working
on this buffer directly.
But then on x86 unaligned access is almost free, so it most likely is a
net plus in performance on the majority of systems.
A benchmark on e.g. ARM, should this platform be relevant to ZMQ, would
be interesting to see if adjusting payload alignment for a potential ZMQ
3.1 is worthwhile to look at.

cheers,
Julian Taylor

Bug#844479: RE:Bug#844479: zeromq3: zeromq 4.2.0 breaks tango

[Julian Taylor]

On Thu, 24 Nov 2016 11:56:15 + Luca Boccassi
 wrote:
> On Thu, 2016-11-24 at 09:58 +, PICCA Frederic-Emmanuel wrote:
> > Hello,
> > 
> > I just opened a bug for tango
> > 
> > https://github.com/tango-controls/cppTango/issues/312
> > 
> > 
> > what is the deadline where we can take the decision to upload or not zeromq 
> > 4.2.0 into Debian testing ?
> > 
> > This will let also some time in order to check if this 4.2.0 do not have 
> > other size effect of dependeings softwares.
> > 
> > Thanks
> > 
> > Fred
> 
> Hi,
> 
> Thanks for opening a bug upstream.
> 
> There is no ABI breakage so there is time for the migration until at
> least the 5th of February.
> 
> I see 3 alternatives here:
> 
> 1) Upstream fixes it
> 2) A patch to revert the internal buffer alignment is added here
> 3) Ship stretch with 4.1.x
> 
> 1 - is of course the preferred way. 2 - is also feasible, but I think
> the consensus upstream is that we don't want to commit to any specific
> guarantee about internal implementation, as it ties down development too
> much. So it would have to be an out-of-tree patch, and I can provide
> that if needed.
> 
> The zeromq mailing list is the right place to discuss this if anyone
> strongly disagrees, we are open to have a discussion about anything and
> everything of course. There are differing opinions about these issues
> that range the whole spectrum, from "if users depend on it it's not a
> bug, it's a feature" to "let's break everything everytime", and anywhere
> in between.
> 
> I'm doing my best to commit to semantic versioning and API/ABI
> compatibility guarantees, going beyond that is very difficult.
> 
> The third option is the worst case scenario. Note that we haven't
> deprecated 4.1.x yet. I wanted to, given it's ABI compatible with 4.2.x,
> but if push came to shove I guess it will have to stay around.
> 

Nitpick, alignment is part of the ABI so it is not compatible.

But on how to fix this. Given [0] you seem to be just passing out the
pointer to your internal buffer written without padding out to the user
via zmq_msg_data (?)

The documentation of that function states that you must not access
zmq_msg_t directly, so if nobody actual does do so regardless zmq can
change this structure and stay compatible?
If so can zmq insert alignment padding between the message headers and
the payload so zmq_msg_data returns aligned data?

This would be very good for compatibility, on non-x86 arches it might
even be better for performance. Unaligned access can be very slow on
some of the less powerful cpus.

(Also even on x86 you can get into alignment issues due to these
buffers, in particular with numerical applications where
auto-vectorization by the compilers is involved)

[0] http://lists.zeromq.org/pipermail/zeromq-dev/2016-November/031096.html

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

[Julian Taylor]

On 29.11.2016 15:10, Tobias Hansen wrote:
> On Thu, 3 Nov 2016 20:25:23 +0100 Julian Taylor
> <jtaylor.deb...@googlemail.com> wrote:
>> On 03.11.2016 20:17, Sandro Tosi wrote:
>>>> Looks like your last upload fixed the build on most architectures. However 
>>>> the
>>>> package still failed to build on arm64.
>>>>
>>>> https://buildd.debian.org/status/package.php?p=pyzmq
>>>
>>> Hey Julian, do you have time to look at the failures in the
>>> https://buildd.debian.org/status/package.php?p=pyzmq ? it looks like
>>> upstream released 16.0.0 so it might worth a shot packaging it to see
>>> if that solves them. thanks!!
>>>
>>
>> I have packaged it though the tests are also unreliable on x86, still
>> needs to be looked at.
>>
> 
> Could it be that zeromq3 4.2.0 (which is now in unstable) helps?
> 
> It would be nice if this could be fixed before the soft freeze on
> January 5. We are trying to get sagemath (currently not uploaded yet) to
> migrate to testing before that date and it could become a problem to
> have different versions of pyzmq (and zeromq3) in unstable and testing.
> 


No luck still hangs sometimes and I still had no time to properly look
into it :/
Also the decision to not provide aligned even 4 byte aligned payload
buffers in zmq 4.2 as indicated in #844479 is going to be a minefield in
our arches without unaligned access ...

Bug#846237: ITP: ondir -- Automate tasks specific to certain directories in the shell

[Julian Taylor]

On 11/29/2016 03:41 PM, Christian Seiler wrote:

(Forwarding because I forgot to Cc debian-devel@.)

ondir is a small program to automate tasks specific to certain
directories. It works by executing scripts in directories when
you enter and leave them. It may be used to set environment
variables or change the umask depending on the current working
directory.


hi,

Seems very similar to the direnv package except that direnv does not 
have an unload hook by design (e.g. what is done when the terminal is 
closed? I guess its up to the users script to handle that?)

Are there any other notable differences?

From the descriptions it seems that direnv might be the better choice 
is what you need is only environment setup and teardown and not 
execution of arbitrary commands, possibly that should be noted in the 
description so the user can decide.


cheers,
Julian

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

[Julian Taylor]

On 03.11.2016 20:17, Sandro Tosi wrote:
>> Looks like your last upload fixed the build on most architectures. However 
>> the
>> package still failed to build on arm64.
>>
>> https://buildd.debian.org/status/package.php?p=pyzmq
> 
> Hey Julian, do you have time to look at the failures in the
> https://buildd.debian.org/status/package.php?p=pyzmq ? it looks like
> upstream released 16.0.0 so it might worth a shot packaging it to see
> if that solves them. thanks!!
> 

I have packaged it though the tests are also unreliable on x86, still
needs to be looked at.

Bug#806867: python-scipy: FTBFS when built with dpkg-buildpackage -A (No module named scipy)

[Julian Taylor]

On 04.10.2016 19:02, Sebastian Humenda wrote:
> Hi
> 
> Julian Taylor schrieb am 03.10.2016, 14:53 +0200:
>> where did you get the tarball from that you pushed to git?
>> its different from what uscan pulls and is missing all the documentation.
> Good question, I went to
> <https://github.com/scipy/scipy/releases>, more specifically
> <http://github.com/scipy/scipy/releases/download/v0.18.1/scipy-0.18.1.tar.gz>.
> 
> If that's different from what's in the git repo, I might have made a mistake. 
> In
> this case, please be so kind to correct it.
> 
> Thanks
> 

hi,
you must be careful with tarballs from github tags, these are straight
dumps from git and do not include submodules.
Also they are missing postprocessing which e.g. make dist or setup.py
sdist do.

I will correct the git repository, please do not commit to it for now.
You also broke the binary-arch build in your changes (dpkg-buildpackage
-B), I will fix that too.

Bug#839746: pyfits-utils: missing python3-pkg-resources dependency

[Julian Taylor]

Package: pyfits-utils
Version: 1:3.4-3
Severity: normal

hi,
fitsdiff included in pyfits-utils will not run in a clean chroot as it 
is missing a dependency on python3-pkg-resources.


$ fitsdiff
from pkg_resources import load_entry_point
Import error: No Module name 'pkg_resources'

also the interpreter directive is set to python3.5, according to debian 
python policy 4.1 and 2.4.1 this should be rewritten to python3.


cheers,
Julian

Bug#806867: python-scipy: FTBFS when built with dpkg-buildpackage -A (No module named scipy)

[Julian Taylor]

On 24.09.2016 23:26, Julian Taylor wrote:
> On 24.09.2016 23:14, Sebastian Humenda wrote:
>> Just to let people know: I'm working on it and hope to upload a new package
>> shortly.
>>
> 
> hm I wanted to do it tomorrow, but if you have it done go ahead.
> note there is a new upstream version that should be uploaded to fix
> other issues.
> 

where did you get the tarball from that you pushed to git?
its different from what uscan pulls and is missing all the documentation.



signature.asc
Description: OpenPGP digital signature

Bug#806867: python-scipy: FTBFS when built with dpkg-buildpackage -A (No module named scipy)

[Julian Taylor]

On 24.09.2016 23:14, Sebastian Humenda wrote:
> Just to let people know: I'm working on it and hope to upload a new package
> shortly.
> 

hm I wanted to do it tomorrow, but if you have it done go ahead.
note there is a new upstream version that should be uploaded to fix
other issues.

Bug#832578: cpl-plugin-visir: does not work with packaged swarp

[Julian Taylor]

I agree that the patches should be more easily extractable, this was 
originally planned but time constrains did not allow this for the last 
two releases, hopefully next time the changes will be included as 
separate patch files.


The patches are for the most part incomplete and not upstreamable as 
they fix the bugs only for the configuration used by visir or add a 
feature only in points visir needs it. There has not been time to 
generalize and test them for the many ways swarp can be used. The last 
time this was done it was promptly broken again in the next code dump so 
motivation is low to do so again.

Bug#832578: cpl-plugin-visir: does not work with packaged swarp

[Julian Taylor]

Package: cpl-plugin-visir
Version: 4.3.0+dfsg-1
Severity: serious

I have already told you in the past that visir does not work with the 
packaged swarp. The swarp included in visir is patched to behave as the 
pipeline needs it. There are also feature patches which go beyond the 
bugfix patches I have already told you about.

To test this run esorex visir_img_reduce sof
with sof:
img/drs/burst-NEII/IRAS21032-0024-NEII-182_0245.fits BURST
img/drs/burst-NEII/IRAS21032-0024-NEII-182_0246.fits BURST
from the demo data.

To my big surprise it does not crash but the results are still wrong.
Check the error extension of the visir_util_join_bCOMBINED.fits, it has 
an average 200 while it should be around 10.


So I repeat, please use the bundled swarp or remove the package from the 
archive.


cheers,
Julian

Bug#830555: new Foolscap release available

[Julian Taylor]

On 21.07.2016 05:00, Brian Warner wrote:

I've just released foolscap-0.12.0 to PyPI, which should fix this. We've
deprecated a function that talks to the root nameservers, and this
release removes the test that used to exercise that function. I think
that was the only place which should be doing off-box network access
(there's plenty of localhost access, of course, this being a networking
package).

I hope that will resolve the issue. Please let me know if there's
anything I can do to help get this packaged and (most importantly) the
auto-removal of Foolscap and Tahoe-LAFS resolved.




hi,
thanks for the quick release, the network access appears to be fixed in 
this release.

I have pushed it to the debian git.

Ramakrishnan, as there are a couple changes can you verify that 
tahoelafs still works correctly?
I tried building the tahoe package but to my surprise it doesn't run any 
tests. Does tahoe have none or are they not run in the package build?


cheers,
Julian

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

[Julian Taylor]

On 13.04.2016 15:39, Julian Taylor wrote:

On 04/13/2016 03:24 PM, Emilio Pozuelo Monfort wrote:

On 29/03/16 19:10, László Böszörményi (GCS) wrote:

Hi Julian,

On Sun, Mar 20, 2016 at 12:27 PM, Julian Taylor
<jtaylor.deb...@googlemail.com> wrote:

On 20.03.2016 11:11, László Böszörményi (GCS) wrote:

  Sorry, my life was chaotic. Yes and no, checked it. First, there's a
new upstream version of pyzmq (15.2) for two months. It seems to be
security related according to the release log[1]:
- FIX: unicode/bytes bug in password prompt in zmq.ssh on Python 3
- workaround overflow bug in libzmq preventing receiving messages
larger than MAX_INT

[...]

The latest version does unfortunately not fix the problem. It is also
not security related, it just could not send large data due to bugs in zmq.
I guess a good approach would be to bisect zmq to see what they changed
to cause it.

  Just a friendly ping; could you test the latest Git master if that
fixes the hang and/or could you ask upstream for advice? Should I do
it? It seems it constantly get fixes that may be relevant.


The package is team maintained, so I would say go ahead and do a team upload.



I see nothing in git that might be related and I'm not a fan of just
doing a guess upload but if you like go ahead.
Note that you have to disable the new large send test as it will fail on
32 bit and possibly swap on 64 bit.
I still need to get porterbox access before I can look at it, but if
someone can bisect libzmq before that happens for me would be great.



here is what I have been able to figure out on powerpc, not much 
unfortunately.

https://github.com/zeromq/pyzmq/issues/838

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

[Julian Taylor]

On 04/13/2016 03:24 PM, Emilio Pozuelo Monfort wrote:
> On 29/03/16 19:10, László Böszörményi (GCS) wrote:
>> Hi Julian,
>>
>> On Sun, Mar 20, 2016 at 12:27 PM, Julian Taylor
>> <jtaylor.deb...@googlemail.com> wrote:
>>> On 20.03.2016 11:11, László Böszörményi (GCS) wrote:
>>>>  Sorry, my life was chaotic. Yes and no, checked it. First, there's a
>>>> new upstream version of pyzmq (15.2) for two months. It seems to be
>>>> security related according to the release log[1]:
>>>> - FIX: unicode/bytes bug in password prompt in zmq.ssh on Python 3
>>>> - workaround overflow bug in libzmq preventing receiving messages
>>>> larger than MAX_INT
>> [...]
>>> The latest version does unfortunately not fix the problem. It is also
>>> not security related, it just could not send large data due to bugs in zmq.
>>> I guess a good approach would be to bisect zmq to see what they changed
>>> to cause it.
>>  Just a friendly ping; could you test the latest Git master if that
>> fixes the hang and/or could you ask upstream for advice? Should I do
>> it? It seems it constantly get fixes that may be relevant.
> 
> The package is team maintained, so I would say go ahead and do a team upload.
> 

I see nothing in git that might be related and I'm not a fan of just
doing a guess upload but if you like go ahead.
Note that you have to disable the new large send test as it will fail on
32 bit and possibly swap on 64 bit.
I still need to get porterbox access before I can look at it, but if
someone can bisect libzmq before that happens for me would be great.

Bug#809314: btrfs-tools in jessie-backports does not provide warning

[Julian Taylor]

> >
>> So if Debian provides very new btrfsprogs for very old kernels, that
>> could cause troubles.

> I've tagged btrfs-tools-4.4-1~bpo8+1 (not my package!) as affected by
> this bug because it does not even provide a warning of this issue.
> Would a NEWS file be enough to close this bug?  There doesn't seem
> mechanism to depend on all linux-image versions greater than a
> particular value, so I'm not really sure.


btrfs-tools does not need to have the same version as the kernel, you
can use any newer version of it with older kernels.
See this faq and the one following:

https://btrfs.wiki.kernel.org/index.php/FAQ#What_version_of_btrfs-progs_should_I_use_for_my_kernel.3F

worst issue you should see is possibly creating a new filesystem that
can't be mounted with the old kernel, but by now it would have to be
very old for that too happen.

Bug#818745: SIGILL on mips in cephes_igam leading to FTBFS of pymvpa2

[Julian Taylor]

On 20.03.2016 12:04, Yaroslav Halchenko wrote:
> Package: python-scipy
> Version: 0.17.0-1
> Severity: important
> 
> pymvpa2 package FTBFS on mips atm
> https://buildd.debian.org/status/fetch.php?pkg=pymvpa2=mips=2.4.3-1=1458051582
> due to 
> Program received signal SIGILL, Illegal instruction
> which if ran under gdb provides following detail:
> 
> 
> Program received signal SIGILL, Illegal instruction.
> 0x75de5d44 in cephes_igam (a=5.3023991505199126e-315, 
> x=5.2998088236266445e-315) at scipy/special/cephes/igam.c:199
> 199 scipy/special/cephes/igam.c: No such file or directory.
> 
> and dissassemble at that point leads to
> 
> 0x75de5d44 <+228>:   add.d   $f6,$f6,$f10
> 
> scipy package itself seems to ignore failing tests ATM so it doesn't
> FTBFS itself although leads to similar illegal instruction crashes in 
> https://buildd.debian.org/status/fetch.php?pkg=python-scipy=mips=0.17.0-1%2Bb1=1457480429
> thus hiding the problem and delivering broken scipy on those platforms
> 

igam.c is as I recall regular C code, I don't know what would cause a
sigill so my guess is once again a compiler or hardware bug.
Unless a porter wants to look at it I'll remove mips from scipy in the
next upload, that platform is to fragile for software like scipy and not
worth the trouble.

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

[Julian Taylor]

On 20.03.2016 11:11, László Böszörményi (GCS) wrote:
> On Sun, Mar 20, 2016 at 10:56 AM, Emilio Pozuelo Monfort
> <po...@debian.org> wrote:
>> On Tue, 15 Mar 2016 23:37:26 +0100
>> =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= <g...@debian.org> wrote:
>>> On Tue, Mar 15, 2016 at 11:24 PM, Julian Taylor
>>> <jtaylor.deb...@googlemail.com> wrote:
>>>> On 15.03.2016 22:48, László Böszörményi (GCS) wrote:
>>>  While I was checking the failing build logs, I see:
>>> build/temp.linux-armv7l-2.7/scratch/tmp/timer_createOfMQXG.o: In
>>> function `main':
>>> timer_createOfMQXG.c:(.text+0x14): undefined reference to `timer_create'
>>> collect2: error: ld returned 1 exit status
>>>
>>> It's not just the implicit declaration, but a linker error later. I
>>> can be wrong, but it seems it _may_ cause the test hang as there's no
>>> timer to look for / to wait its expiration. Sorry if it happens in
>>> normal logs as well; will check it tomorrow morning as it's almost
>>> midnight here. :(
>  Checked, it happens in normal build logs as well.
> 
>> Got a chance to look at this?
>  Sorry, my life was chaotic. Yes and no, checked it. First, there's a
> new upstream version of pyzmq (15.2) for two months. It seems to be
> security related according to the release log[1]:
> - FIX: unicode/bytes bug in password prompt in zmq.ssh on Python 3
> - workaround overflow bug in libzmq preventing receiving messages
> larger than MAX_INT
> 
> My computer is old and has problems; even the archive version hangs
> during self-tests. Still, it may help if Julian update the package to
> the latest version. With my Python Modules team member hat on, should
> I do it myself?
> Just for the record, upstream Git tree has even more fixes that not
> yet released as a new version.
> 

The latest version does unfortunately not fix the problem. It is also
not security related, it just could not send large data due to bugs in zmq.
I guess a good approach would be to bisect zmq to see what they changed
to cause it.

Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

[Julian Taylor]

On 15.03.2016 22:48, László Böszörményi (GCS) wrote:
> On Tue, Mar 15, 2016 at 10:26 AM, Emilio Pozuelo Monfort
>  wrote:
>> On 14/03/16 22:03, Emilio Pozuelo Monfort wrote:
>>> Looks good. No problem and thanks for reacting that fast!
>>
>> I scheduled the binNMUs last night and things are going well. The only issue
>> seems to be pyzmq, see #818265.
>  This is known to pyzmq upstream[1] for about three years. It happens
> on Ubuntu, Red Hat, CentOS and with ZeroMQ 4.0.x as well. While
> timer_create() [4] is in librt, the standard GNU C library, it seems
> pyzmq miss to link with it on the failing architectures. User reports
> says that 'pip install pyzmq --install-option="--zmq=/usr/lib"' forces
> the linking. I don't know how pass it to setup.py (not using pip
> directly) and the path should be multiarch aware for us.
> 
> Hope this helps,
> Laszlo/GCS
> [1] https://github.com/zeromq/pyzmq/issues/391
> [2] https://github.com/zeromq/pyzmq/issues/468
> [3] https://github.com/zeromq/pyzmq/issues/658
> [4] http://man7.org/linux/man-pages/man2/timer_create.2.html
> 

Are you saying linking against -lrt will fix the tests deadlocking?

I don't quite see the relation between the hanging tests and the linked
issues.
The implicit declaration errors have always been there I think but only
in a configure check so harmless (until now?).

Bug#811392: foolscap problem

[Julian Taylor]

reassign 811392 foolscap 0.10.1-1
thanks

This is a problem in foolscap packaging, caused by a change in twisted
packaging. It will get fixed today.

It can be worked around by replacing the twisted-* dependencies with
just twisted in
/usr/lib/python2.7/dist-packages/foolscap-0.10.1.egg-info/requires.txt

Bug#812504: swarp: breaks when coadding many overlapping files

[Julian Taylor]

Package: swarp
Version: 2.38.0+dfsg-2
Severity: important

when coadding more than the openfile limit (normally 1024) overlapping
files swarp aborts due to too many open files.
To reproduce create some files with overlapping wcs coordinates, set
ulimit -n to a low enough number and just run SWarp 
This was fixed a while ago but apparently in 2.38 the original patch has
been mangled into not working anymore.

1. a in my opinion not useful NOPENFILES_MAX variable was added, and
when you go over the limit it just warns instead of capping the number
of files swarp uses (src/prefs.c:536). The original patch capped the
usage and did not require user configuration or having the process abort
after hours of resampling because the warning was not read.
The fix is simple, set the cap in src/prefs.c, as the actual meat of the
original patch is still in place.
2. the cfitsio based opening leaks open file descriptors somewhere. The
code is kind of convoluted so I could not figure out a good fix. This
half backed attempt works for the visir pipeline but is likely not
appropriate for upstream:

--- a/swarp/src/fits/fitscat.c
+++ b/swarp/src/fits/fitscat.c
@@ -161,6 +161,7 @@ int close_cat(catstruct *cat)
 }

   cat->file = NULL;
+  close_cfitsio(cat);

   return RETURN_OK;
   }
diff --git a/swarp/src/fits/fitstab.c b/swarp/src/fits/fitstab.c
index 5919b2a..95bb2c4 100644
--- a/swarp/src/fits/fitstab.c
+++ b/swarp/src/fits/fitstab.c
@@ -285,6 +285,9 @@ voidcopy_tab_fromptr(tabstruct *tabin,
catstruct *catout, int pos)
 /* First, allocate memory and copy data */
QCALLOC(tabout, tabstruct, 1);
*tabout = *tabin;
+   /* set fits handle to NULL to avoid double close and hope its not needed
+* anymore */
+   tabout->infptr = NULL;
if (tabin->naxis)
  QMEMCPY(tabin->naxisn, tabout->naxisn, int, tabin->naxis);
if (tabin->headbuf)

Bug#811500: cpl-plugin-visir: does not work

[Julian Taylor]

On 01/19/2016 04:50 PM, Ole Streicher wrote:

Hi Julian,

thank you for the bug report. To check the packaging, I run the unit
tests that come with the package (hoping that they cover a good part of
the code), and I think this is a reasonable "minimal effort" to ensure a
package is working.


no running the unittests is not minimal effort for Debian, at least not 
without knowing that the unittests represent a sufficient test coverage 
to guarantee some usability.
For pretty much all pipelines this is not the case. If a pipeline works 
is done via esorex and test datasets. Those are not part of the source 
tarballs, though the demo datasets sometimes contain a subset of the 
test data.
This may not be ideal for third party redistribution, but this is also 
not something upstream needs to necessarily care about.


If you want to package something it is your job to make sure it actually 
works and not only that it builds. And if you don't know the package 
well enough to ensure that, then don't package it. Debian is better of 
without some software than with software that doesn't work.


Fwiw. the easiest way to test at least a subset of the shipped recipes 
is to run the demo datasets via the upstream provided Reflex package, 
ideally you just have to load the workflows and press play.
You can collect the raw esorex calls and sofs from its temporary folders 
printed in the workflow.




Could I ask you to provide a minimal test case that could be used? "Any"
is a bit vague... Can you make a small test case, maybe using your demo
data set

ftp://ftp.eso.org/pub/dfs/pipelines/visir/visir-demo-reflex-0.1.tar.gz

which I could use? Just the parameters, the SOF, and the expected output
would be probably enough


cat data.sof

demoroot/img/aqu/VISIR.2015-07-21T07:09:09.829.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T07:09:56.706.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T07:10:33.128.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T07:11:17.722.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T08:13:14.577.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T08:14:48.712.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T08:16:14.751.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T08:17:48.743.fits BURST

esorex visir_img_reduce --delete-temp=false data.sof

It will fail on all three points. When adding the config and adapting 
the swarp executable name it will fail with a division by zero due to 
the weight maps from swarp being wrongly just zeros (in the tmp folder 
tmp_coadd_wgt_*.fits)
The recipe should work with swarp 2.19 but that version has other issues 
which will cause failures with other data.


The patches to swarp in visir do not fix that, they just work around it 
by reverting some stuff, so they are not much use to the package as is. 
I contacted upstream about the issues when they were discovered (quite a 
long time ago) though never received an answer, though I should retry 
contacting if time allows for it.

Bug#811500: cpl-plugin-visir: does not work

[Julian Taylor]

Package: cpl-plugin-visir
Version: 4.1.0+dfsg-1
Severity: serious

the packaged recipe does not work at all for several reasons:

1. removed patched copy of swarp, visir does not work with 2.38, it 
needs 2.19 or the embedded convinience copy. To see run the 
visir_img_reduce recipe on any data and look at the garbage weight map 
it produces
2. does not work with packaged swarp even if that one would work because 
it is name SWarp not swarp as the pipeline expects.

3. the required swarp configuration visir_default.swarp is not installed.

Please spend at least at least the minimal effort to see if what you are 
packaging even works or don't bother at all. Note that in future the 
embedded swarp might receive more visir specific patches.


As upstream does not want this pipeline packaged in distributions I 
would recommend removing it completely.

Bug#795848: FTBTS: foolscap

[Julian Taylor]

On 13.01.2016 06:54, Ramakrishnan Muthukrishnan wrote:
> On Wed, Jan 13, 2016, at 11:17 AM, Ramakrishnan Muthukrishnan wrote:
>>
>> I applied two patches below after which it passes the tests (python
>> setup.py trial). Both the changes have been submitted into the upstream
>> for review.
> 
> I just wanted to say that the two patches are on top of the new release
> (0.9.1).
> 

thanks,
I'll give it a try soon, hopefully still this week.

Bug#795848: errors with 0.9.1

[Julian Taylor]

hi,
I just updated the package to 0.9.1 and there still seem to be test failures 
with the twisted version in debian (15.5.0)

===
[ERROR]
Traceback from remote host -- Traceback (most recent call last):
  File "/tmp/buildd/foolscap-0.9.1/foolscap/eventual.py", line 26, in _turn
cb(*args, **kwargs)
  File "/tmp/buildd/foolscap-0.9.1/foolscap/broker.py", line 553, in doNextCall
d.addCallback(self._callFinished, delivery)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 317, 
in addCallback
callbackKeywords=kw)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 306, 
in addCallbacks
self._runCallbacks()
---  ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 588, 
in _runCallbacks
current.result = callback(current.result, *args, **kw)
  File "/tmp/buildd/foolscap-0.9.1/foolscap/broker.py", line 600, in 
_callFinished
methodSchema.checkResults(res, False) # may raise Violation
  File "/tmp/buildd/foolscap-0.9.1/foolscap/remoteinterface.py", line 297, in 
checkResults
self.responseConstraint.checkObject(results, inbound)
  File "/tmp/buildd/foolscap-0.9.1/foolscap/slicers/dict.py", line 147, in 
checkObject
self.valueConstraint.checkObject(value, inbound)
  File "/tmp/buildd/foolscap-0.9.1/foolscap/constraint.py", line 220, in 
checkObject
raise Violation("'%r' is not a bytestring" % (obj,))
foolscap.tokens.Violation: Violation (in return value of 
.get_versions): 
("'u'0.9.1'' is not a bytestring",)

foolscap.test.test_logging.Publish.test_logpublisher
===
[ERROR]
Traceback from remote host -- Traceback (most recent call last):
  File "/tmp/buildd/foolscap-0.9.1/foolscap/eventual.py", line 26, in _turn
cb(*args, **kwargs)
  File "/tmp/buildd/foolscap-0.9.1/foolscap/broker.py", line 553, in doNextCall
d.addCallback(self._callFinished, delivery)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 317, 
in addCallback
callbackKeywords=kw)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 306, 
in addCallbacks
self._runCallbacks()
---  ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 588, 
in _runCallbacks
current.result = callback(current.result, *args, **kw)
  File "/tmp/buildd/foolscap-0.9.1/foolscap/broker.py", line 600, in 
_callFinished
methodSchema.checkResults(res, False) # may raise Violation
  File "/tmp/buildd/foolscap-0.9.1/foolscap/remoteinterface.py", line 297, in 
checkResults
self.responseConstraint.checkObject(results, inbound)
  File "/tmp/buildd/foolscap-0.9.1/foolscap/slicers/dict.py", line 147, in 
checkObject
self.valueConstraint.checkObject(value, inbound)
  File "/tmp/buildd/foolscap-0.9.1/foolscap/constraint.py", line 220, in 
checkObject
raise Violation("'%r' is not a bytestring" % (obj,))
foolscap.tokens.Violation: Violation (in return value of 
.get_versions): 
("'u'0.9.1'' is not a bytestring",)

foolscap.test.test_logging.Publish.test_logpublisher_catchup
===
[ERROR]
Traceback (most recent call last):

Bug#800392: [Python-modules-team] Bug#800392: Bug#800392: Bug#800392: python-numpy: FTBFS on powerpc due to test failure

[Julian Taylor]

On 01.10.2015 00:41, Sandro Tosi wrote:
> On Wed, Sep 30, 2015 at 11:19 PM, Julian Taylor
> <jtaylor.deb...@googlemail.com> wrote:
>> hm is __POWERPC__ not the right macro for that platform? that should
>> have worked
> 
> in numpy/core/include/numpy/npy_cpu.h i can find
> 
> #elif defined(__ppc__) || defined(__powerpc__) || defined(_ARCH_PPC)
> /*
>  * __ppc__ is defined by gcc, I remember having seen __powerpc__ once,
>  * but can't find it ATM
>  * _ARCH_PPC is used by at least gcc on AIX
>  */
> #define NPY_CPU_PPC
> 
> so maybe that's the one to use?
> 

those certainly should work, forgot about them.
you should be able to login to a powerpc porterbox and check.
cat test.c
__POWERPC__
gcc -E test.c

Bug#800392: [Python-modules-team] Bug#800392: Bug#800392: python-numpy: FTBFS on powerpc due to test failure

[Julian Taylor]

On 01.10.2015 00:17, Sandro Tosi wrote:
> control: reopen -1
> 
>>> it would probably be best to disable the assert in
>>> lowlevel_strided_loops.c.src on powerpc depending cpp macros, that way
>>> it will also continue to work when users would want to use python-dbg on
>>> ppc if softfaulting is enabled.
>>>
>>
>> attached a patch
> 
> Sadly it didnt have the expected impact (actually the failure is in
> the same test):
> https://buildd.debian.org/status/fetch.php?pkg=python-numpy=powerpc=1%3A1.9.2-3=1443649824
> 
> Do you any other idea how to address it?
> 

hm is __POWERPC__ not the right macro for that platform? that should
have worked

Bug#800392: [Python-modules-team] Bug#800392: python-numpy: FTBFS on powerpc due to test failure

[Julian Taylor]

On 28.09.2015 20:58, Scott Kitterman wrote:
> 
> Seems like this may be related to #702169.
> 

no, powerpc is the arch with the broken malloc:
https://sourceware.org/bugzilla/show_bug.cgi?id=6527

the test should probably just be ignored (as it has been in the past) it
has always been broken and nobody ever cared.

Bug#800392: [Python-modules-team] Bug#800392: Bug#800392: python-numpy: FTBFS on powerpc due to test failure

[Julian Taylor]

On 30.09.2015 01:01, Sandro Tosi wrote:
> On Tue, Sep 29, 2015 at 8:05 AM, Julian Taylor
> <jtaylor.deb...@googlemail.com> wrote:
>> On 28.09.2015 20:58, Scott Kitterman wrote:
>>>
>>> Seems like this may be related to #702169.
>>>
>>
>> no, powerpc is the arch with the broken malloc:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=6527
>>
>> the test should probably just be ignored (as it has been in the past) it
>> has always been broken and nobody ever cared.
> 
> Is there an elegant way to instruct numpy testsuite to just ignore
> errors on powerpc? I would really love to keep the test failures as
> blocking on all Debian archs. I cant think of any smart way to keep
> the 'set -e' for all archs except powerpc
> 
> on way would be to just skip that test (in the last failure it was
> always test_multiarray.TestClip.test_basic) but of course that doesnt
> guarantee that other tests might fail after that (and we dont know
> now) or that other test starts failing (because of the broken malloc
> acting up).
> 

it would probably be best to disable the assert in
lowlevel_strided_loops.c.src on powerpc depending cpp macros, that way
it will also continue to work when users would want to use python-dbg on
ppc if softfaulting is enabled.

Bug#800392: [Python-modules-team] Bug#800392: Bug#800392: python-numpy: FTBFS on powerpc due to test failure

[Julian Taylor]

On 30.09.2015 01:14, Julian Taylor wrote:
> On 30.09.2015 01:01, Sandro Tosi wrote:
>> On Tue, Sep 29, 2015 at 8:05 AM, Julian Taylor

>> Is there an elegant way to instruct numpy testsuite to just ignore
>> errors on powerpc? I would really love to keep the test failures as
>> blocking on all Debian archs. I cant think of any smart way to keep
>> the 'set -e' for all archs except powerpc
>>
>> on way would be to just skip that test (in the last failure it was
>> always test_multiarray.TestClip.test_basic) but of course that doesnt
>> guarantee that other tests might fail after that (and we dont know
>> now) or that other test starts failing (because of the broken malloc
>> acting up).
>>
> 
> it would probably be best to disable the assert in
> lowlevel_strided_loops.c.src on powerpc depending cpp macros, that way
> it will also continue to work when users would want to use python-dbg on
> ppc if softfaulting is enabled.
> 

attached a patch
Description: disable asserts on ppc with broken malloc
 only longdouble affected will still work with softfaults
Author: Julian Taylor <jtaylor.deb...@googlemail.com>
--- a/numpy/core/src/multiarray/lowlevel_strided_loops.c.src
+++ b/numpy/core/src/multiarray/lowlevel_strided_loops.c.src
@@ -7,6 +7,13 @@
  *
  * See LICENSE.txt for the license.
  */
+#ifdef __POWERPC__
+#ifndef NDEBUG
+// disable asserts malloc broken
+// https://sourceware.org/bugzilla/show_bug.cgi?id=6527
+#define NDEBUG
+#endif
+#endif
 
 #define PY_SSIZE_T_CLEAN
 #include "Python.h"

Bug#783543: Acknowledgement (miscompile of _mm256_permutevar8x32_epi32)

[Julian Taylor]

the issue has been fixed upstream in r232085, 3.6 backport commit on
release_6 branch is r232118


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

Bug#783543: miscompile of _mm256_permutevar8x32_epi32

[Julian Taylor]

Package: llvm-toolchain-3.6
Version: 1:3.6-2
Severity: serious

clang 3.6 in debian miscompiles _mm256_permutevar8x32_epi32
it swaps the two first arguments:


$ apt-cache policy clang-3.6
clang-3.6:
  Installed: 1:3.6-2
  Candidate: 1:3.6-2
  Version table:
 *** 1:3.6-2 0
500 http://ftp.de.debian.org/debian/ unstable/main amd64

$ cat test.c
#include immintrin.h

__m256i fun (__m256i a, __m256i o) {
return _mm256_permutevar8x32_epi32(a, o);
}


$ clang-3.6 test.c -mavx2 -c -O2
$ objdump -d test.o

test.o: file format elf64-x86-64


Disassembly of section .text:

 fun:
   0:   c4 e2 7d 36 c1  vpermd %ymm1,%ymm0,%ymm0
   5:   c3  retq


the correct result is:
vpermd %ymm0,%ymm1,%ymm0

clang 3.5 seems to produce the right result so this is a 3.6 regression


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

Bug#783090: python3.5: missing modules

[Julian Taylor]

Package: python3.5
Version: 3.5.0~a4-1
Severity: important

following modules are missing in the package:
cmath, mmap, resource

also GzipFile does not have an offset anymore, not sure if thats a
packaging error or an upstream api break.


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

Bug#674610:

[Julian Taylor]

hi,
thanks for working on the package
please also incorporate the other changes applied in ubuntu, those
include multiarchification but also some other changes.


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

Bug#776036: new version buggy

[Julian Taylor]

the latest version of swarp has introduced regressions related to file
descriptors and weight maps. I would advise against updating before
having them fixed.

Do you have contact with the author?
I forwarded my issues to him but never got a reply.


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

Bug#734505: Can we close twitter-recess bug #734505?

[Julian Taylor]

still doesn't work for me in current unstable. The less version is still
the same.

Bug#734505: Can we close twitter-recess bug #734505?

[Julian Taylor]

The package not working for one of its main purposes does qualify as
severe to me.
I spent significant time tracking this done when using an upstream
system using recess to compile less file.

I can accept lowering the severity when the compile option is removed
from the debian package with a helpful error message.


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

Bug#767138: libfftw3 SIGILL on armhf

[Julian Taylor]

sorry for the lack of reply, I have been traveling for the last 1.5 weeks.
I'll try to look at this weekend. Feel free to NMU if you need a faster
solution.


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

Bug#761509: fix for jessie?

[Julian Taylor]

It would be good to have this fixed for jessie.
Correct handling of denormals which are controlled via this register is
very important for the performance of e.g. audio applications.


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

Bug#767439: python-zmq FTBFS on official arm64 arm-arm autobuilders.

[Julian Taylor]

 
 Anyone have any thoughts?

the same issue occurs on mips, though the porterbox is so slow I do not
have a big urge to try and debug anything on it.
When there is a arm porterbox which is faster I may have a look at it again.

(On mips I'm ignoring the testfailure, though I should probably request
removing the binaries instead, I don't really want to extend ignoring
failures to more arches that just causes pain downstream)


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

Bug#767138: fftw3: runtime detection of NEON is perhaps broken

[Julian Taylor]

On 29.10.2014 13:06, Gert Wollny wrote:
 
 Regarding the use of intrinsics: AFAICS in configure.ac --with-neon
 always sets HAVE_NEON as define and adds the flag -mfpu=neon. 
 

the flags are only added to files which do the computations, the rest of
the program should not have this flag, this should include the file that
has the neon runtime check.

btw neon is still disabled on arm64 because it crashed the compiler, is
this fixed?


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

Bug#767138: fftw3: runtime detection of NEON is perhaps broken

[Julian Taylor]

On 28.10.2014 18:13, Edmund Grimley Evans wrote:

 Is this signal-handling approach the best way of detecting NEON? The
 following blog suggests using HWCAP, but I don't know if that would
 work with the freebsd kernels:

looks like a better way to do it, freebsd doesn't matter for us as we
don't have a arm port of that.
I don't know arm much nor can I test so I would need a patch ideally
something that can be upstreamed (so it would need proper guards against
kernels not supporting it)

Though for Debian wouldn't it be enough to change the encoding to what
we are using?
possibly that could be automated by compiling a vand snipped and getting
the code with objdump during configure time.


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

Bug#767138: fftw3: runtime detection of NEON is perhaps broken

[Julian Taylor]

On 29.10.2014 00:18, Edmund Grimley Evans wrote:
 Though for Debian wouldn't it be enough to change the encoding to what
 we are using?
 possibly that could be automated by compiling a vand snipped and getting
 the code with objdump during configure time.
 
 That sounds as if it could be fragile and cause problems for Debian
 ports and derivatives that might target a different ARM variant.

thus the configure check. That allows different variants automatically,
but its still not really an elegant solution.

 
 Alternatively, you could perhaps use the current signal-catching
 mechanism but run something based on the actual FFT code as a test
 instead of a VAND instruction. By the looks of it the actual code uses
 intrinsics such as vaddq_f32. Is there any reason why one couldn't use
 one of the same intrinsics to see if NEON is working? Well, I can
 think of a couple of issues:

intrinsics need the -mfpu=neon flag to work (assuming its similar to
x86). You can't do that for the whole file as the unsupported
instruction set might be used in other places of the file.
One could use a separate file with with only a test function using
intrinsics.


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

Bug#744969: sodium available now

[Julian Taylor]

libsodium is now almost available in unstable, please build a zeromq
with it enabled.


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

Bug#746013: libmatheval: diff for NMU version 1.1.11+dfsg-1.2

[Julian Taylor]

On 07.10.2014 16:21, Neil Williams wrote:
 Control: tags 746013 + pending
 
 Dear maintainer,
 
 I've prepared an NMU for libmatheval (versioned as 1.1.11+dfsg-1.2) and
 uploaded it to unstable with a fix for the compiler optimisation effects.
 
 This diff extends the previous diff for i386 support.
 
 Regards.
 

please upload such hacky patches to delayed so I can override it with
something proper if I find the time...

the rounding issue can be solved much simpler by using appropriate C
types or putting an error on the tests.
Also you shouldn't just add a new debian specific symbol to a library
... (or was this forwarded upstream?)

but still thanks for handling the issue which I have been neglecting for
too long.


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

Bug#746013: Investigating i386 issues with libmatheval

[Julian Taylor]

On 06.10.2014 23:34, Neil Williams wrote:
 Something odd with the *386 builds, i386, kfreebsd-i386 and hurd-i386:
 
 i386 chroot:
 -1.3130352854993315
 +1.3130352854993312
 
 Other 32bit architectures don't have a problem. 
 

thats very expected, i386 numerical precision depends on compiler
optimizations as the fpu has 80 bit width while double has 64.
You need to bump the error bounds or use special flags like
-ffloat-store or -fpmath=sse to avoid it.


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

Bug#761509: sse control word not inherited in pthreads

[Julian Taylor]

Package: libc0.1
Version: 2.19-11
X-Debbugs-CC: debian-...@lists.debian.org

very similar to bug 761175 about the x87 control word.
but the same issue affects the sse control word mxcsr.
It was not fixed in -11 that fixed the x87 fpu.

(sid_kfreebsd-amd64-dchroot)jtaylor@falla:~$ cat test2.c
#include pthread.h
#include xmmintrin.h
#include stdio.h
#include fpu_control.h
#include fenv.h

void *thread_fun(void *x_void_ptr)
{
   fenv_t env;
   fegetenv(env);
   printf(thread mxcsr %x\n, env.__mxcsr);
   return NULL;
}

int main()
{
   pthread_t thread;
   fenv_t env;
   fegetenv(env);
   printf(main mxcsr pre %x\n, env.__mxcsr);
   _MM_SET_FLUSH_ZERO_MODE (_MM_FLUSH_ZERO_ON);
   fegetenv(env);
   printf(main mxcsr %x\n, env.__mxcsr);

   if(pthread_create(thread, NULL, thread_fun, NULL)) {
   fprintf(stderr, Error creating thread\n);
   return 1;
   }
   if(pthread_join(thread, NULL)) {
   fprintf(stderr, Error joining thread\n);
   return 2;
   }
   return 0;
} 
$ ./a.out
main mxcsr pre 1f80
main mxcsr 9f80
thread mxcsr 1f80

$ apt-cache  policy libc0.1
libc0.1:
  Installed: 2.19-11
  Candidate: 2.19-11
  Version table:
 *** 2.19-11 0


on linux the control word is inherited as per SysV abi section 3.4.2.


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

Bug#761392: python-astropy: tests fail with numpy 1.9

[Julian Taylor]

Package: python-astropy
Version: 0.4.1+dfsg-1
Severity: important

astropy fails its test with numpy 1.9 available in experimental. A patch
is available upstream:
https://github.com/astropy/astropy/pull/2927

I want to upload numpy to unstable soon, please include the fix in your
next upload. But as it won't break the actual astropy runtime its not
super urgent.


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

Bug#761175: kfreebsd i386 changing x87 precision mode in pthreads

[Julian Taylor]

On 11.09.2014 13:42, Petr Salinger wrote:
 Package: libc0.1
 Version: 2.13-38+deb7u2
 X-Debbugs-CC: jtaylor.deb...@googlemail.com , debian-...@lists.debian.org
 
 On Sat, 6 Sep 2014, Julian Taylor wrote:
...
 
 The thread started in kernel have different default precision
 in FreeBSD compared to Linux.
 
 The initial value of precision is set-up before main() starts,
 but not in each thread.
 
 We should think about how it should be fixed.
 The new thread should either inherit FPU control word from parent, or it
 should be created with the same value as original main().
 
 Julian, please, could you verify behaviour of linux-i386 ?

i386 seems to inherit the parent control word.
gcc test.c -g -pthread  ./a.out
main starts with 37F
set main to 7F
thread starts with 7F
set thread to 27F
main after join 7F

(on fisher main starts with 137F and thread starts with 127F)

This also matches what  System V Application Binary Interface for amd64
states in section 3.4.2:

3.4.2 Thread State
New threads inherit the floating-point state of the parent thread and
the state is private to the thread thereafter.


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

Bug#756403: [Python-modules-team] Bug#756403: python-numpy: fix FTBFS on ppc64el (patch available)

[Julian Taylor]

On 25.08.2014 12:49, Mauricio Faria de Oliveira wrote:
 Hi Andi,
 
 On 08/23/2014 06:12 PM, Andreas Barth wrote:
 If useful I'd be willing to upload this fix as an NMU. As this is a
 blocker for cython it has some priority, so I would do that tomorrow
 unless there is a reason not to.
 
 Thanks, that would be great. :)

I have committed the patch to svn, would need sponsoring.


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

Bug#756403: [Python-modules-team] Bug#756403: python-numpy: fix FTBFS on ppc64el (patch available)

[Julian Taylor]

On 25.08.2014 21:44, Andreas Barth wrote:
 * Mauricio Faria de Oliveira (mauri...@linux.vnet.ibm.com) [140825 20:34]:
 Hi Andi,

 On 08/25/2014 02:43 PM, Andreas Barth wrote:
 * Julian Taylor (jtaylor.deb...@googlemail.com) [140825 18:37]:
 I have committed the patch to svn, would need sponsoring.
 Where could I pull the package from?

 It's on SVN r30233 [1]. I can get with 'debcheckout python-numpy'.

 Interesting that, although the patch is there, it is not applied
 by default.  I had to run 'quilt push -a' to get it applied.
 
 I'll upload it as soon as I can build it on ppc64el, that is after
 matplotlib is built (which I assume will happen in the next 1-2 days).
 
 

you can build matplotlib without numpy? I think it uses the numpy C-api
which would require at least numpy headers.

You can build numpy without matplotlib for bootstraping, its just used
for the documentation. A binary arch only build might even work with
current packaging but I haven't tried.


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

Bug#751296: debdiff for upgrade

[Julian Taylor]

tags 751296 + patch
thanks

attached a debdiff with the update.
should fix the RC bugs, though I can't reproduce the freebsd issue.
--- skimage-0.9.3/debian/changelog  2014-01-23 21:07:58.0 +0100
+++ skimage-0.10.1/debian/changelog 2014-08-24 15:23:20.0 +0200
@@ -1,3 +1,21 @@
+skimage (0.10.1-1) unstable; urgency=medium
+
+  * New upstream release
+  * depend on and use libjs-twitter-bootstrap (Closes: #736785)
+  * doc-privacy.patch: use system font for documentation
+  * build depend on python-six (= 1.3.0) python-numpy (= 1.6.0) and
+cython (= 0.17)
+  * slicing-error.patch: fix error revealed by numpy 1.9
+  * bump standard to 3.9.5
+
+ -- Julian Taylor jtaylor.deb...@googlemail.com  Sun, 24 Aug 2014 11:38:12 
+0200
+
+skimage (0.9.3-4build1) trusty; urgency=medium
+
+  * No change rebuild to drop python3.3 compiled extension.
+
+ -- Dimitri John Ledkov x...@ubuntu.com  Mon, 31 Mar 2014 19:36:34 +0100
+
 skimage (0.9.3-4) unstable; urgency=low
 
   * debian/rules
--- skimage-0.9.3/debian/control2014-01-23 21:07:58.0 +0100
+++ skimage-0.10.1/debian/control   2014-08-24 15:23:20.0 +0200
@@ -3,26 +3,31 @@
 Priority: optional
 Maintainer: Stefan van der Walt ste...@sun.ac.za
 Uploaders: Yaroslav Halchenko deb...@onerussian.com
-Build-Depends: cython (= 0.15),
-   cython3 (= 0.15),
+Build-Depends: cython (= 0.17),
+   cython3 (= 0.17),
debhelper (= 9~),
libfreeimage3,
+   libjs-twitter-bootstrap,
python-all-dev (= 2.6.6-3~),
-   python-pil | python-imaging,
python-matplotlib (= 1.0),
python-nose,
-   python-numpy,
+   python-numpy (= 1.6.0),
+   python-pil | python-imaging,
python-scipy (= 0.10),
python-setuptools,
+   python-six (= 1.3.0),
python-sphinx (= 1.0.7+dfsg-1~),
python3-all-dev,
-   python3-pil | python3-imaging,
python3-matplotlib | python-matplotlib ( 1.2.0~),
python3-nose,
python3-numpy,
+   python3-pil | python3-imaging,
python3-scipy,
-   python3-setuptools
-Standards-Version: 3.9.4
+   python3-setuptools,
+   python3-six (= 1.3.0),
+   xauth,
+   xvfb
+Standards-Version: 3.9.5
 Homepage: http://scikit-image.org
 Vcs-Browser: https://github.com/scikit-image/scikit-image
 Vcs-Git: git://github.com/scikit-image/scikit-image.git
@@ -35,10 +40,15 @@
 Depends: libfreeimage3,
  python-numpy,
  python-scipy (= 0.10),
+ python-six (= 1.3.0),
  python-skimage-lib (= ${source:Version}),
  ${misc:Depends},
  ${python:Depends}
-Recommends: python-pil, python-imaging, python-matplotlib (= 1.0), 
python-nose, python-qt4
+Recommends: python-imaging,
+python-matplotlib (= 1.0),
+python-nose,
+python-pil,
+python-qt4
 Suggests: python-opencv, python-skimage-doc
 Description: Python modules for image processing
  scikit-image is a collection of image processing algorithms for
@@ -52,10 +62,14 @@
 Depends: libfreeimage3,
  python3-numpy,
  python3-scipy (= 0.10),
+ python3-six (= 1.3.0),
  python3-skimage-lib (= ${source:Version}),
  ${misc:Depends},
  ${python3:Depends}
-Recommends: python3-pil,python3-imaging,  python3-matplotlib (= 1.0), 
python3-nose
+Recommends: python3-imaging,
+python3-matplotlib (= 1.0),
+python3-nose,
+python3-pil
 Suggests: python-skimage-doc
 Description: Python 3 modules for image processing
  scikit-image is a collection of image processing algorithms for
--- skimage-0.9.3/debian/patches/doc-privacy.patch  1970-01-01 
01:00:00.0 +0100
+++ skimage-0.10.1/debian/patches/doc-privacy.patch 2014-08-24 
15:23:20.0 +0200
@@ -0,0 +1,21 @@
+Description:  avoid privacy breach
+ use standard fonts instead of loading something from google
+ use local jquery from sphinx
+--- a/doc/source/themes/scikit-image/layout.html
 b/doc/source/themes/scikit-image/layout.html
+@@ -17,7 +17,6 @@
+ {%- endif %}
+ 
+ {%- macro script() %}
+-script src=http://code.jquery.com/jquery-latest.js;/script
+ script src={{ pathto('_static/', 1) }}js/bootstrap.min.js/script
+ script type=text/javascript
+   var DOCUMENTATION_OPTIONS = {
+@@ -37,7 +36,6 @@
+ link rel=stylesheet href={{ pathto('_static/pygments.css', 1) }} 
type=text/css /
+ link href={{ pathto('_static/', 1) }}css/bootstrap.min.css 
rel=stylesheet type=text/css
+ link href={{ pathto('_static/', 1) }}css/custom.css rel=stylesheet 
type=text/css
+-link href=http://fonts.googleapis.com/css?family=Raleway; 
rel=stylesheet type=text/css
+ {%- for cssfile in css_files

Bug#758209: wxpython3.0: cannot import 2.8 anymore

[Julian Taylor]

Package: wxpython3.0
Version: 3.0.0.0+dfsg-3
Severity: serious

the change of wxversion to 3.0 prevents importing wx if only 2.8 is
installed.
This breaks for example matplotlib which still depends on wxgtk2.8.
See e.g. the autopkgtest in ubuntu:

https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-matplotlib/60/?

Or in an unstable chroot:

apt-get install python-wxgtk2.8
python -c import wx
Traceback (most recent call last):
  File string, line 1, in module
ImportError: No module named wx


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

Bug#758055: libfftw3-3: fftw-wisdom-to-conf wisdom conf.c : invalid wisdom

[Julian Taylor]

fixed 758055 3.3.3-6
thx

this issue is fixed in package version 3.3.3-6 available in testing.
the fix is quite simple:

--- a/fftw-wisdom-to-conf
+++ b/fftw-wisdom-to-conf
@@ -39,7 +39,7 @@ fi
 read preamble fftw_wisdom

 case $preamble $fftw_wisdom in
-   \(@PACKAGE@-@VERSION@\ *_wisdom)
+   \(@PACKAGE@-@VERSION@\ *_wisdom*)
prefix=`echo $fftw_wisdom | cut -d_ -f1`_
;;
*)


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

Bug#756905: gfortran miscompilation on mips.

[Julian Taylor]

On 07.08.2014 09:10, YunQiang Su wrote:
 On Sun, 03 Aug 2014 13:34:24 +0200 Matthias Klose d...@debian.org wrote:
 Package: python-scipy
 Version: 0.14.0-1
 Severity: serious
 Tags: sid jessie

 the package fails to build on mips, but did build before.
 see
 https://buildd.debian.org/status/fetch.php?pkg=python-scipyarch=mipsver=0.14.0-1stamp=1406905822
 
 Yes, I met the same problem on mips64el
 http://mips64el.debian.net/debian/buildlog/p/python-scipy_0.14.0-1/python-scipy_0.14.0-1_mips64el-20140716-1434.build
 

 the autopkg tests fail, see
 http://ci.debian.net/#package/python-scipy

 please fix these, or disable them.


 

I'm blaming gfortran:

  program add
  implicit none
  real a,b,s
  read *, a
  print *, ' is ' , int(a)
  stop
  end


(sid_mips-dchroot)jtaylor@gabrielli:~$ ./a.out
-1e99
  is   2147483647

according to https://gcc.gnu.org/onlinedocs/gfortran/INT.html this
should be -2147483648


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

Bug#757492: gfortran-4.9: miscompiles int() on mips

[Julian Taylor]

Package: gfortran-4.9
Version: 4:4.9.1-1
Severity: important

gfortran miscompiles int() for negative overflows leading to a build
timeout of python-scipy, see #756905
below a testcase, according to
https://gcc.gnu.org/onlinedocs/gfortran/INT.html the result should be
-2147483648

(sid_mips-dchroot)jtaylor@gabrielli:~$ apt-cache  policy gfortran
gfortran:
  Installed: 4:4.9.1-1
  Candidate: 4:4.9.1-1
  Version table:
 *** 4:4.9.1-1 0
500 http://mirror-ubc.debian.org/debian/ sid/main mips Packages
100 /var/lib/dpkg/status
(sid_mips-dchroot)jtaylor@gabrielli:~$ cat test.f90
  program add
  implicit none
  real a,b,s
  read *, a
  print *, ' is ' , int(a)
  stop
  end
(sid_mips-dchroot)jtaylor@gabrielli:~$ gfortran test.f90
(sid_mips-dchroot)jtaylor@gabrielli:~$ ./a.out
-1e99
  is   2147483647
Note: The following floating-point exceptions are signalling:
IEEE_INVALID_FLAG IEEE_OVERFLOW_FLAG


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

Bug#755339: Please make sure you file an upstream bug in future

[Julian Taylor]

On 04.08.2014 19:57, Daira Hopwood wrote:
 The foolscap bug tracker is easy to find: http://foolscap.lothar.com/trac
 

the issue was already fixed upstream before this bug was filed:
https://github.com/warner/foolscap/commit/2eeabc61c2573652d7482d039644d62d782c2e3a


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

Bug#728498: libnetcdfc++4 does not include C++ NetCDF library!

[Julian Taylor]

according to:
https://packages.debian.org/wheezy/amd64/libnetcdfc++4/filelist
and
https://packages.debian.org/wheezy/amd64/libnetcdf-dev/filelist
the library /usr/lib/libnetcdf_c++.so.4.1.0 is there.

Can you elaborate on what is missing?



signature.asc
Description: OpenPGP digital signature

Bug#755485: python-astropy: too low wcslib version in build-depends

[Julian Taylor]

Package: python-astropy
Severity: minor
Version: 0.4-3

python-astropy does not build with the version 4.20 stated in the build depends:

astropy/wcs/src/wcslib_wrap.c: In function ‘PyWcsprm_compare’:
astropy/wcs/src/wcslib_wrap.c:754:3: warning: implicit declaration of
function ‘wcscompare’ [-Wimplicit-function-declaration]
   status = wcscompare(cmp, self-x, other-x, equal);
   ^
astropy/wcs/src/wcslib_wrap.c: In function ‘PyWcsprm_richcompare’:
astropy/wcs/src/wcslib_wrap.c:1700:9: error: ‘WCSCOMPARE_ANCILLARY’
undeclared (first use in this function)
 WCSCOMPARE_ANCILLARY,


updating to current unstable 4.23 seems to fix the build.
Please correct the version requirements to aid backports of the package.

Thanks,
Julian Taylor


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

Bug#755263: wheezy-pu: package ipython/0.13.1-2+deb7u1

[Julian Taylor]

Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu

Hi release team

I would like to update ipython in wheezy to fix CVE-2014-3429
It is a remote execution flaw via cross origin websockets, but one
requires a uuid from the process in order to make use of it so it was
decided by the security team that its severe enough for a DSA.
But it should stil be fixed in stable just in case.

See this page for details of the issue:
http://lambdaops.com/cross-origin-websocket-hijacking-of-ipython
diff -Nru ipython-0.13.1/debian/changelog ipython-0.13.1/debian/changelog
--- ipython-0.13.1/debian/changelog	2012-11-25 20:04:22.0 +0100
+++ ipython-0.13.1/debian/changelog	2014-07-16 20:29:04.0 +0200
@@ -1,3 +1,9 @@
+ipython (0.13.1-2+deb7u1) stable-security; urgency=medium
+
+  * Fix CVE-2014-3429: remote execution via cross origin websocket
+
+ -- Julian Taylor jtaylor.deb...@googlemail.com  Wed, 16 Jul 2014 20:27:50 +0200
+
 ipython (0.13.1-2) unstable; urgency=low
 
   * update watch file to use github directly
diff -Nru ipython-0.13.1/debian/patches/CVE-2014-3429.patch ipython-0.13.1/debian/patches/CVE-2014-3429.patch
--- ipython-0.13.1/debian/patches/CVE-2014-3429.patch	1970-01-01 01:00:00.0 +0100
+++ ipython-0.13.1/debian/patches/CVE-2014-3429.patch	2014-07-16 20:27:40.0 +0200
@@ -0,0 +1,60 @@
+Description: check origin of websocket connection CVE-2014-3429
+Origin: https://github.com/ipython/ipython/pull/4845
+
+--- a/IPython/frontend/html/notebook/handlers.py
 b/IPython/frontend/html/notebook/handlers.py
+@@ -16,6 +16,11 @@ Authors:
+ # Imports
+ #-
+ 
++try:
++from urllib.parse import urlparse # Py 3
++except ImportError:
++from urlparse import urlparse # Py 2
++
+ import logging
+ import Cookie
+ import time
+@@ -368,6 +373,30 @@ class KernelActionHandler(AuthenticatedH
+ 
+ class ZMQStreamHandler(websocket.WebSocketHandler):
+ 
++def same_origin(self):
++Check to see that origin and host match in the headers.
++
++# The difference between version 8 and 13 is that in 8 the
++# client sends a Sec-Websocket-Origin header and in 13 it's
++# simply Origin.
++if self.request.headers.get(Sec-WebSocket-Version) in (7, 8):
++origin_header = self.request.headers.get(Sec-Websocket-Origin)
++else:
++origin_header = self.request.headers.get(Origin)
++
++host = self.request.headers.get(Host)
++
++# If no header is provided, assume we can't verify origin
++if(origin_header is None or host is None):
++return False
++
++parsed_origin = urlparse(origin_header)
++origin = parsed_origin.netloc
++
++# Check to see that origin matches host directly, including ports
++return origin == host
++
++
+ def _reserialize_reply(self, msg_list):
+ Reserialize a reply message using JSON.
+ 
+@@ -409,6 +438,11 @@ class ZMQStreamHandler(websocket.WebSock
+ class AuthenticatedZMQStreamHandler(ZMQStreamHandler):
+ 
+ def open(self, kernel_id):
++# Check to see that origin matches host directly, including ports
++if not self.same_origin():
++self.log.warn(Cross Origin WebSocket Attempt.)
++raise web.HTTPError(404)
++
+ self.kernel_id = kernel_id.decode('ascii')
+ try:
+ cfg = self.application.ipython_app.config
diff -Nru ipython-0.13.1/debian/patches/series ipython-0.13.1/debian/patches/series
--- ipython-0.13.1/debian/patches/series	2012-11-25 20:04:22.0 +0100
+++ ipython-0.13.1/debian/patches/series	2014-07-16 20:26:58.0 +0200
@@ -5,3 +5,4 @@
 use-system-mathjax-if-available.patch
 parallel-2to3.patch
 shared-static-path.patch
+CVE-2014-3429.patch

Bug#755263: wheezy-pu: package ipython/0.13.1-2+deb7u1

[Julian Taylor]

On 19.07.2014 17:19, Julien Cristau wrote:
 Control: tags -1 confirmed
 
 On Sat, Jul 19, 2014 at 13:51:46 +0200, Julian Taylor wrote:...
 I would like to update ipython in wheezy to fix CVE-2014-3429
 It is a remote execution flaw via cross origin websockets, but one
 requires a uuid from the process in order to make use of it so it was
 decided by the security team that its severe enough for a DSA.
 
 Missing not?

yes, its not severe enough.

 
 But it should stil be fixed in stable just in case.

 See this page for details of the issue:
 http://lambdaops.com/cross-origin-websocket-hijacking-of-ipython
 
 With one comment below, and assuming this has been tested in a wheezy
 environment, feel free to upload.

thanks fixed and uploaded with a slightly better changelog message.


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

Bug#753121: gnulib test failure caused by compiler bug

[Julian Taylor]

the test failure is due to a compiler bug in gcc-4.9:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61725


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

Bug#753307: broken by tcl/tk 8.6

[Julian Taylor]

Package: skycat
Version: 3.1.2+starlink1~b-6
Severity: serious

blt now uses tcl/tk 8.6 while skycat is linked against 8.5 which leads
to startup failures of skycat:

Error in startup script: couldn't load file
/usr/lib/skycat/libskycat3.1.2.so: libBLT.2.4.so.8.5:

on the ubuntu-motu mailing list (search skycat) there is a patch that
fixes this issue but it will still segfault on start due to itcl3
needing tcl 8.5. I have no fix for that.
A workaround would be to reintroduce a new blt linked against 8.5.
This is possible as blt versions its library by the tcl name.


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

Bug#752696: ITP: soci -- C++ database access library

[Julian Taylor]

hi, nice to hear someone wants to add soci back.
I have packaged it  for personal use a while back. The packaging hasn't
been updated in a while but it might still be useful if you aren't
finished yet.
It is available here:
https://github.com/SOCI/soci-pkg/pull/3


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

Bug#751343: [Python-modules-team] Bug#751343: python-tornado: FTBFS on mips due to test failure

[Julian Taylor]

in svn I have disabled all performance relevant tests which includes
this one. Upstream has a convinient switch for that for the CI. its
currently waiting for sponsoring.


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

Bug#751008:

[Julian Taylor]

if you remove nodejs and install pandoc it should work.
I'll check out how to fix the nodejs version for the next package update.


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