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

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

Bug#915738: rules workaround

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

Bug#907335: similar issue

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

+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; ur

Bug#903579: cythonize at build patch

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

Bug#911271: txtorcon patch submitted

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

Bug#906215: further issues

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

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

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

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

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

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

Bug#866468: marked as pending

53cbd5877418c58cf5d17ad7f8b23049005fa83a Author: Julian Taylor Date: Sun Jan 7 14:39:49 2018 +0100 Replace python-imaging recomments with python-pil (Closes: #866468) diff --git a/debian/changelog b/debian/changelog index 5917604..576adb0 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3

Bug#859619: marked as pending

6b5e307b1ee45a902664b5b4fda1a4efcded7106 Author: Julian Taylor Date: Wed Apr 5 12:28:03 2017 +0200 fix linking manpage in arch-indep build (Closes: #859619) diff --git a/debian/changelog b/debian/changelog index 71221cf..10cec81 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10

Bug#859019: new bugfix release available

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#849593: libfftw3-single3: dependencies in shlibs file not tight enough (Was: Bug#849589: ardour: undefined symbol: fftwf_make_planner_thread_safe)

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 u

Bug#844479: zeromq3: zeromq 4.2.0 breaks tango

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

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 deci

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

On 29.11.2016 15:10, Tobias Hansen wrote: > On Thu, 3 Nov 2016 20:25:23 +0100 Julian Taylor > wrote: >> On 03.11.2016 20:17, Sandro Tosi wrote: >>>> Looks like your last upload fixed the build on most architectures. However >>>> the >>>> package

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

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

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

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

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

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 t

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

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

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

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

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

Bug#830555: new Foolscap release available

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

Bug#830555: marked as pending

6bae4dc17b96e0619e4f5724ac1423521d4d0875 Author: Julian Taylor Date: Thu Jul 21 19:16:43 2016 +0200 New ustream release (Closes: #830555) diff --git a/debian/changelog b/debian/changelog index 338e146..7550a66 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,8 +1,12 @@ -foolscap (0.10.1-3

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

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 wrote: On 20.03.2016 11:11, László Böszörményi (GCS) wrote: Sorry, my life was

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

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 >> wrote: >>> On 20.03.2016 11:11, László Böszörményi (GCS) wrote: >>>>

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

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 > wrote: >> On Tue, 15 Mar 2016 23:37:26 +0100 >> =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: >>> On Tue, Mar 15, 2016 at 11:24 PM, Julian

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

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 w

Bug#811392: marked as pending

f1dc4dadc8e0eebb98e9c1c8a30a7760583a23ad Author: Julian Taylor Date: Tue Feb 2 21:08:40 2016 +0100 release package diff --git a/debian/changelog b/debian/changelog index ea943ed..eea807c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,7 +1,7 @@ -foolscap (0.10.1-2) UNRELEASED; urgency=medium

Bug#811392: foolscap problem

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

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

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 r

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

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 an

Bug#795848: FTBTS: foolscap

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 ju

Bug#795848: errors with 0.9.1

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

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

On 01.10.2015 00:41, Sandro Tosi wrote: > On Wed, Sep 30, 2015 at 11:19 PM, Julian Taylor > 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(_

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

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 e

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

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

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

On 30.09.2015 01:01, Sandro Tosi wrote: > On Tue, Sep 29, 2015 at 8:05 AM, Julian Taylor > wrote: >> On 28.09.2015 20:58, Scott Kitterman wrote: >>> >>> Seems like this may be related to #702169. >>> >> >> no, powerpc is the arch with th

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

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 n

Bug#783543: Acknowledgement (miscompile of _mm256_permutevar8x32_epi32)

the issue has been fixed upstream in r232085, 3.6 backport commit on release_6 branch is r232118 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#783543: miscompile of _mm256_permutevar8x32_epi32

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

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

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 helpf

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

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

Bug#767138: libfftw3 SIGILL on armhf

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

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

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

Bug#746013: Investigating i386 issues with libmatheval

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 compile

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

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

Bug#756905: gfortran miscompilation on mips.

On 07.08.2014 09:10, YunQiang Su wrote: > On Sun, 03 Aug 2014 13:34:24 +0200 Matthias Klose 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

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

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

Bug#753121: gnulib test failure caused by compiler bug

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

Bug#753307: broken by tcl/tk 8.6

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

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

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

Bug#739073: fixed upstream

seems to be fixed upstream by this commit on the 0.20.x branch: commit da2af6e346b9b5afd72b955eb4e3fb7a5bf1cfe2 Author: Stefan Behnel Date: Thu Jan 30 08:22:05 2014 +0100 fix signature embedding test in recent Py3.4 --- tests/run/embedsignatures.pyx | 2 ++ 1 file changed, 2 insertions(+)

Bug#740318: [Python-modules-team] Bug#740318: python3-numpy-dbg shares a file with python3-numpy without conflicts on kfreebsd

hm no not fixed yet in experimental, but will be thanks for the report. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#740318: [Python-modules-team] Bug#740318: python3-numpy-dbg shares a file with python3-numpy without conflicts on kfreebsd

this should be fixed in the experimental version. a new numpy bugfix rc release is due this weekend which will be uploaded to unstable. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#735804: caused by pandas

fixed by this pandas change: https://github.com/pydata/pandas/pull/6256 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#735847: closed by Scott Howard (Bug#735847: fixed in freeimage 3.15.4-3)

On 20.01.2014 22:51, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the freeimage package: > > #735847: freeimage: builds wrong tiff, broken 32 bit > > It has been closed by Scott Howard . > great, using system tiff is t

Bug#735847: freeimage: builds wrong tiff, broken 32 bit

On 20.01.2014 01:46, Scott Howard wrote: > > Before uploading that patch and closing this bug, I'd like to look at > "long is 32 bit on 32 bit arches. it needs to be int64_t or long long. > This occurs several times in the file." LibTIFF4/tiffconf.h is > generated at build time, so it should be OK

Bug#735847: freeimage: builds wrong tiff, broken 32 bit

On 20.01.2014 01:46, Scott Howard wrote: > > Checking over the package, I don't think it's a problem of not > updating the patch. The previous version of the package and patches > didn't touch anything related to TIFF and used freeimage's included > libtiff. The current version also doesn't touche

Bug#735847: tag patch

attached patch from upstream cvs seem to fix the tag issue, thought I'm not so sure about if its save concerning buffer overflows. http://freeimage.cvs.sourceforge.net/viewvc/freeimage/FreeImage/Source/Metadata/XTIFF.cpp?r1=1.23&r2=1.24&view=patch http://sourceforge.net/p/freeimage/discussion/3611

Bug#735847: freeimage: builds wrong tiff, broken 32 bit

Package: freeimage Version: 3.15.4 Severity: serious the recent update to .4 updates the internal tiff to libtiff4 but does not update the debian patch debian/patches/disable_embedded_libraries.patch appropriately. This leads to some internals using the libtiff internals instead of the libtiff4 Th

Bug#735039: spatialindex: adds hardening flags to pkg-config --libs

Package: spatialindex Version: 1.8.1-1 Severity: serious as warned in #679690 exports hardening flags in pkg-config --libs which are now enabled: # pkg-config --libs libspatialindex -fPIE -pie -Wl,-z,relro -Wl,-z,now -lspatialindex -pie must not be exported via pkg-config --libs (no LDFLAGS actu

Bug#734521: pyzmq: FTBFS for s390x: test_timeout AssertionError

On 07.01.2014 21:38, Julian Taylor wrote: > On 07.01.2014 21:23, Alessandro Ghedini wrote: >> On mar, gen 07, 2014 at 09:10:35 +0100, Julian Taylor wrote: >>> On 07.01.2014 21:02, Aaron M. Ucko wrote: >>> caused by a minimum polling timeout of 0.5 seconds due to a bu

Bug#734521: pyzmq: FTBFS for s390x: test_timeout AssertionError

On 07.01.2014 21:23, Alessandro Ghedini wrote: > On mar, gen 07, 2014 at 09:10:35 +0100, Julian Taylor wrote: >> On 07.01.2014 21:02, Aaron M. Ucko wrote: >> caused by a minimum polling timeout of 0.5 seconds due to a bug in >> zeromqs timing src/clock.cpp:123 zmq::clock_t

Bug#734521: pyzmq: FTBFS for s390x: test_timeout AssertionError

On 07.01.2014 21:02, Aaron M. Ucko wrote: > Source: pyzmq > Version: 14.0.1-1 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > The s390x build of pyzmq failed with an AssertionError when trying to > run the unit test under Python 2.7: > >

Bug#734518: pyzmq: FTBFS on i386: pypy build reports ImportError

On 07.01.2014 21:11, Aaron M. Ucko wrote: > Julian Taylor writes: > >> its because pypy 2.2 has not built on i386 yet, a cffi function has a >> different return value in 2.1. > > I see; thanks for the prompt explanation! In that case, I'd recommend > versioning

Bug#734518: pyzmq: FTBFS on i386: pypy build reports ImportError

On 07.01.2014 21:00, Aaron M. Ucko wrote: > Source: pyzmq > Version: 14.0.1-1 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > The i386 build of pyzmq for pypy failed with an ImportError, as detailed at > https://buildd.debian.org/status/fetc

Bug#734505: twitter-recess: broken with less 1.4

Package: twitter-recess Version: 1.1.9-1 Severity: serious recess does not work at all with node-less 1.4 available in jessie. $ cat test.less .border-radius (@radius: 5px) { -webkit-border-radius: @radius; -moz-border-radius: @radius; border-radius: @radius; } /* Implementation */ #s

Bug#729261: libwx_gtk2u_core-2.8.so.0 changed abi without transition

On 10.11.2013 23:38, Joachim Breitner wrote: > Hi, > > thanks for the report, rebuilding xaralx right now. > > Out of curiosity: Are you actually using xaralx? Upstream has stopped > maintaining it and I haven’t heard from users in a long time... > no I'm not using it, I just went through a cou

Bug#729261: libwx_gtk2u_core-2.8.so.0 changed abi without transition

Package: xaralx Version: 0.7r1785-5 Severity: serious libwx_gtk2u_core-2.8.so.0 seemed to have changed abi in unstable, now xaralx fails to start: xaralx: relocation error: xaralx: symbol _ZTV19wxGnomePrintFactory, version WXU_2.8 not defined in file libwx_gtk2u_core-2.8.so.0 with link time refer

Bug#710890: libfftw3-3 transitional package also has to depend on libfftw3-long3

On 27.10.2013 13:46, Hiroyuki Yamamoto wrote: > Control: reopen -1 > > Hi, > > libfftw3-long3 of fftw3 (3.3.3-6) can be built only on > amd64 hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc > powerpcspe s390 s390x sparc. > So, libfftw3-3 cannot be installed on armel, armhf, mips, mips

Bug#726093: python-scipy: CVE-2013-4251: weave /tmp and current directory issues

On 22.10.2013 08:43, Salvatore Bonaccorso wrote: > Hi Julian, > > Cc'ing Julian directly as per short discussion on IRC. > > On IRC you mentioned that you are looking at this issue. Did you had a > chance to prepare the upload for unstable? > I have prepared updates for unstable, wheezy and squ

Bug#719065: [Python-modules-team] Bug#719065: Mnemosyne fails at startup due error in python-matplotlib.

most likely it can be fixed by deleting ~/.matplotlib/fontList.cache but before you do so please make a backup and mail it to the bug, because I can't reproduce the issue locally. On Sun, Aug 11, 2013 at 10:40 AM, darkestkhan wrote: > Dear Maintainer, > I just checked and found that mnemosyne w

Bug#715152: can't reproduce

severity 715152 important thanks I still can't reproduce it, maybe I have something installed you don't. Can you try installing mono-dev or apt-get build-dep keepass2 to pull all the mono stuff and try again? can you also provide the output of this: env | grep -E "LC|LANG" I'm demoting it to impo

Bug#715152: keepass2: Crash when entering numbers in bépo.

On 06.07.2013 11:33, Guillaume Seren wrote: > Package: keepass2 > Version: 2.22+dfsg-1 > Severity: grave > Justification: renders package unusable > > When entering some digit keepass2 on bépo layout, > crash instantly, other text characters seem's to work > as expected. > I can't reproduce th

Bug#710890: libfftw3-3 transitional package also has to depend on libfftw3-long3

On 03.06.2013 19:07, Adrian Bunk wrote: > On Mon, Jun 03, 2013 at 06:58:10PM +0200, Julian Taylor wrote: >> On 03.06.2013 11:34, Adrian Bunk wrote: >>> Package: libfftw3-3 >>> Version: 3.3.3-5 >>> Severity: serious >>> >>> libff

Bug#710890: libfftw3-3 transitional package also has to depend on libfftw3-long3

On 03.06.2013 11:34, Adrian Bunk wrote: > Package: libfftw3-3 > Version: 3.3.3-5 > Severity: serious > > libfftw3-3 in stable also contains the libfftw3l* libraries. > > > Therefore an upgrade to the transitional package has to also pull > in libfftw3-long3. > There is no package depending on

Bug#709168: src:fftw3: FTBFS on ia64: r2cf_8.c:83:1: internal compiler error

On 21.05.2013 19:20, Sébastien Villemot wrote: > > Another possible solution to try is to force compilation with GCC 4.7 on > ia64 (since currently GCC 4.6 is the default on that arch). If you have > a patch, I can try it on a ia64 porterbox. > setting CC=gcc-4.8 works for fftw3, add it e.g. to

Bug#709168: src:fftw3: FTBFS on ia64: r2cf_8.c:83:1: internal compiler error

On 21.05.2013 11:51, Sébastien Villemot wrote: > > libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. > -I../../../kernel -I../../../rdft -I../../../rdft/scalar -D_FORTIFY_SOURCE=2 > -g -O2 -Wformat -Werror=format-security -O2 -MT r2cf_8.lo -MD -MP -MF > .deps/r2cf_8.Tpo -c r2cf_

Bug#702637: matlab-support: fails to install in clean chroot

On 09.03.2013 19:10, Adam D. Barratt wrote: > On Sat, 2013-03-09 at 18:45 +0100, Julian Taylor wrote: >> A problem with failing the installation if matlab is missing is that it >> prevents migration from Ubuntus proposed repository to the main one. >> Migration requires that

Bug#702658: matlab-support: uninteruptable prompt on installation with readline

On 09.03.2013 18:21, Yaroslav Halchenko wrote: > > On Sat, 09 Mar 2013, Michael Hanke wrote: >> entering an empty string does not cancel the prompt. >> Other frontends are probably ok, they offer a cancel option. >>I can't replicate this. I installed the package, the prompt comes up,

Bug#702637: matlab-support: fails to install in clean chroot

On 09.03.2013 18:26, Michael Hanke wrote: > Hi, > > I see the problem, but I am not convinced this change is the solution. > Installing this package is pointless without Matlab, it should not be > pulled in as a dependency unless > a package gets installed that requires matlab. > > If we make thi

Bug#702658: matlab-support: uninteruptable prompt on installation with readline

Package: matlab-support Version: 0.0.18 Severity: serious when you use the readline frontend the matlab-support package installation gets stuck in an uninterruptable question loop asking for the location of matlab: DEBIAN_FRONTEND=readline apt-get install matlab-support Location of MATLAB install

Bug#702637: matlab-support: fails to install in clean chroot

On 09.03.2013 15:19, Yaroslav Halchenko wrote: > But should it exit nicely if no matlab is present??? > Absent matlab == matlab cannot be supported == error in my vision of > how things should be handled in this package. Having it installed > without error should provide some guarantee that Matl

Bug#702637: matlab-support: fails to install in clean chroot

Package: matlab-support Version: 0.0.18 Severity: serious in a clean testing chroot: Setting up matlab-support (0.0.18) ... No matlab found and maybe running in non-interactive mode. No way out -- failing... dpkg: error processing matlab-support (--configure): subprocess installed post-installat

Bug#700525: unblock: sundials/2.5.0-2

On 02/27/2013 06:41 PM, Julian Taylor wrote: > On 02/27/2013 06:31 PM, Julian Taylor wrote: >> On 02/27/2013 04:38 PM, Sébastien Villemot wrote: >>> Le samedi 16 février 2013 à 16:47 +0100, Julian Taylor a écrit : >>> >>>> also there are still undefined r

Bug#700525: unblock: sundials/2.5.0-2

On 02/27/2013 06:31 PM, Julian Taylor wrote: > On 02/27/2013 04:38 PM, Sébastien Villemot wrote: >> Le samedi 16 février 2013 à 16:47 +0100, Julian Taylor a écrit : >> >>> also there are still undefined references remaining in a public library >>> in debian: >&

Bug#700525: unblock: sundials/2.5.0-2

On 02/27/2013 04:38 PM, Sébastien Villemot wrote: > Le samedi 16 février 2013 à 16:47 +0100, Julian Taylor a écrit : > >> also there are still undefined references remaining in a public library >> in debian: >> >> root@ubuntu:/# ldd -r /usr/lib/libsundials_fnve

Bug#701589: python-gevent-dbg: fails to import

Package: python-gevent-dbg Version: 0.13.6-1 Severity: serious apt-get install python-gevent-dbg python-dbg python-dbg -c "import gevent" Traceback (most recent call last): File "", line 1, in File "/usr/lib/pymodules/python2.7/gevent/__init__.py", line 41, in from gevent import core Imp

Bug#701113: Acknowledgement (rpy2: incompatible with python2.6)

if it does not work with 2.6 please don't build for it, adapt the XS-Python-Version appropriately in the source. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#701113: rpy2: incompatible with python2.6

Package: rpy2 Version: 2.3.1-1 Severity: serious only affects unstable, not wheezy # python2.6 -c "import rpy2.rinterface" Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.6/dist-packages/rpy2/rinterface/__init__.py", line 3, in if (sys.version_info.major ==

Bug#700525: unblock: sundials/2.5.0-2

On 02/16/2013 03:46 PM, Julian Taylor wrote: > found 700525 2.5.0-2 > thanks > >> Hello, >> >> Could you unblock sundials version 2.5.0-2 ? It would fix the RC bug >> #700525 (fix by Christophe). >> The change is basically adding -lblas -llapack -lm to

Bug#700525: unblock: sundials/2.5.0-2

found 700525 2.5.0-2 thanks > Hello, > > Could you unblock sundials version 2.5.0-2 ? It would fix the RC bug > #700525 (fix by Christophe). > The change is basically adding -lblas -llapack -lm to LDFLAGS > LDFLAGS is the wrong place for this, it must be placed in LIBS or your build systems eq

Bug#589731: python-scipy: missing source for Cython-generated files

On 01/26/2013 03:41 PM, Jonathan Wiltshire wrote: > I'd like to see this fixed in wheezy but the diff is too large; how much of > this is necessary to get the source into the package and close this bug only? > everything but the regeneration in debian/rules and the interp patch. But it means fixi

Bug#697617: login regression

the fix introduced a very annoying regression: see https://issues.jenkins-ci.org/browse/JENKINS-16278 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#696000: debug logs

debug logs for openblas git e01b3d4b546d8 built with make USE_THREAD=0 NO_LAPACK=1 DEBUG=1 which resulted in the barcelona target the interesting parts are input 221 which loads the two element vector and a nan following it into xmm5 the nan is probably a remnant from the previous run 2: $xmm2.v4

Bug#696000: openblas: breaks numpy linalg.solve and numpy.dot on i386

Package: openblas Version: 0.1.1-6 Severity: serious when using python-numpy with openblas set als libblas.so.3 provider it gives wrong results in some situations on i386. amd64 seems to work. It also works fine with libblas3 and libatlas. It seems to only occur when you change between double and

Bug#589731: missing files again

found 589731 0.10.1+dfsg1-1 thanks $ head debian/changelog python-scipy (0.10.1+dfsg1-4) unstable; urgency=low $ grep -rl 'Generated by Cython' . | sed -e 's,\.c,\.pyx,g' | xargs ls -1 ls: cannot access ./scipy/io/matlab/mio_utils.pyx: No such file or directory ls: cannot access ./scipy/io/matla

Bug#686562: probably broken patch

tags 686562 - patch thanks the patch does not look like a solution, with the chosen hash algorithm collisions are independent of the seed. also mono limits he size of POST requests to 2MB by default which reduces the impact of the issue. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists

  1   2   >