Bug#606528: sympy: please run tests at build time
On Fri, Dec 10, 2010 at 10:57 AM, Jakub Wilk jw...@debian.org wrote: * Ondrej Certik ond...@certik.cz, 2010-12-09, 15:23: Sympy comes with a test suite, so it would be nice if it could be run at build time, preferably with all supported Python versions. It takes several minutes to run. Are you sure it's a good idea? Absolutely sure. What happens if some little test fails? Somebody fixes either the test, or the offending code, or temporarily disables the test. Easy. Is it better to have 99% working package, or not a package at all? It's not like anybody is going to kick a package out of archive just because it FTBFS. :) Think of running tests at build time like an investment in quality assurance. Sounds good to me. Let's do that. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606528: sympy: please run tests at build time
On Thu, Dec 9, 2010 at 2:53 PM, Jakub Wilk jw...@debian.org wrote: Source: sympy Version: 0.6.7-1.1 Sympy comes with a test suite, so it would be nice if it could be run at build time, preferably with all supported Python versions. It takes several minutes to run. Are you sure it's a good idea? What happens if some little test fails? Is it better to have 99% working package, or not a package at all? Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606528: sympy: please run tests at build time
On Thu, Dec 9, 2010 at 3:23 PM, Ondrej Certik ond...@certik.cz wrote: On Thu, Dec 9, 2010 at 2:53 PM, Jakub Wilk jw...@debian.org wrote: Source: sympy Version: 0.6.7-1.1 Sympy comes with a test suite, so it would be nice if it could be run at build time, preferably with all supported Python versions. It takes several minutes to run. Are you sure it's a good idea? What happens if some little test fails? Is it better to have 99% working package, or not a package at all? But I think at least the core tests should be run, it only takes 3s: $ bin/test sympy/core/ = test process starts == executable: /usr/bin/python (2.6.5-final-0) sympy/core/tests/test_arit.py[45] ...ff [OK] sympy/core/tests/test_assumptions.py[28] f... [OK] sympy/core/tests/test_basic.py[8] [OK] sympy/core/tests/test_cache.py[1] . [OK] sympy/core/tests/test_complex.py[12] [OK] sympy/core/tests/test_containers.py[2] .. [OK] sympy/core/tests/test_count_ops.py[1] . [OK] sympy/core/tests/test_diff.py[5] . [OK] sympy/core/tests/test_equal.py[5] . [OK] sympy/core/tests/test_eval.py[8] .f.. [OK] sympy/core/tests/test_eval_power.py[11] ... [OK] sympy/core/tests/test_evalf.py[21] .[OK] sympy/core/tests/test_expand.py[5] .[OK] sympy/core/tests/test_expr.py[49] .. ... [OK] sympy/core/tests/test_facts.py[11] ... [OK] sympy/core/tests/test_functions.py[30] ...ff. [OK] sympy/core/tests/test_logic.py[10] .. [OK] sympy/core/tests/test_match.py[26] ...f.. [OK] sympy/core/tests/test_multidimensional.py[4] [OK] sympy/core/tests/test_numbers.py[37] . [OK] sympy/core/tests/test_operations.py[4] [OK] sympy/core/tests/test_priority.py[5] . [OK] sympy/core/tests/test_relational.py[7] ... [OK] sympy/core/tests/test_sets.py[14] ..[OK] sympy/core/tests/test_subs.py[27] ... [OK] sympy/core/tests/test_symbol.py[7] ... [OK] sympy/core/tests/test_sympify.py[23] ...[OK] sympy/core/tests/test_truediv.py[3] ... [OK] sympy/core/tests/test_var.py[4] [OK] === tests finished: 406 passed, 7 expected to fail, in 2.95 seconds And if all of them pass, then the package is usable. It would for example catch the python2.7 problem. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606528: [Python-modules-team] Bug#606528: sympy: please run tests at build time
On Thu, Dec 9, 2010 at 3:36 PM, Sandro Tosi matrixh...@gmail.com wrote: Hi Ondrej, On 2010-12-10, Ondrej Certik ond...@certik.cz wrote: On Thu, Dec 9, 2010 at 2:53 PM, Jakub Wilk jw...@debian.org wrote: Source: sympy Version: 0.6.7-1.1 Sympy comes with a test suite, so it would be nice if it could be run at build time, preferably with all supported Python versions. It takes several minutes to run. Are you sure it's a good idea? IMO yes. What happens if some little test fails? for the first run you can ignore errors, but this way you'll have the tests executed on the buildds and see what's going on, and then you'll be able to work to fix what's broken. Is it better to have 99% working package, or not a package at all? I'd rather have a 100% working package :) Sure, me too, but that's not what I was asking. :) Or a package where tests failures are ignored (temporarily) to have the time to work on the code to fix it. Let's ignore the result then, that seems to me like a good solution. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597848: [Python-apps-team] Bug#597848: (cython: fresh upstream is available (0.13)) -- evas, ecore, djvu FTBFS
Hi Yarik, On Sat, Oct 9, 2010 at 5:13 PM, Yaroslav Halchenko deb...@onerussian.com wrote: uploaded 0.13 to experimental since all fixes/workarounds for depending packages are known now and there is a demand for 0.13 to be available Thanks for this! Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559916: [Python-modules-team] Bug#559916: Lots of code duplication because this is still unresolved
On Thu, Sep 30, 2010 at 3:46 PM, Michael Hanke michael.ha...@gmail.com wrote: On Thu, Sep 30, 2010 at 11:56:03PM +0200, Sandro Tosi wrote: Thanks for your interest in this bug; are you also going a bit further and propose a patch to fix it (this would actually help to resolve this bug)? I might. However, proposing a patch is probably not an adequate first action. What is your general attitude towards the problem? Should there be a separate package as suggested in the initial report? Or should it simply be installed along the rest of numpy (I guess all packages using numpydoc also imploy/depend on numpy)? Was this bug ever discussed with upstream? Or try to get this accepted into sphinx upstream? I think that's the best solution. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597848: (cython: fresh upstream is available (0.13)) -- evas, ecore, djvu FTBFS
On Tue, Sep 28, 2010 at 4:03 PM, Jakub Wilk jw...@debian.org wrote: * Yaroslav Halchenko y...@debian.org, 2010-09-27, 10:21: *$ PYTHONPATH=/home/yoh/deb/debs/build-area/cython-test-bdepeds/python-djvulibre-0.1.18/build/lib.linux-x86_64-2.6 python -c 'from djvu.const import *' Traceback (most recent call last): File string, line 1, in module File /home/yoh/deb/debs/build-area/cython-test-bdepeds/python-djvulibre-0.1.18/build/lib.linux-x86_64-2.6/djvu/const.py, line 15, in module import djvu.sexpr File sexpr.pyx, line 1, in init djvu.sexpr (djvu/sexpr.c:10615) AttributeError: 'module' object has no attribute 'Symbol__new__' That's an interesting regression! The minimal test-case is: def foo(): '''bar''' return 42 del foo This code works well with Python and old Cython but fails with Cython 0.13. A work-around is to just remove the docstring. Thanks, I can also reproduce this and I have just reported it upstream here: http://groups.google.com/group/cython-users/browse_thread/thread/63f8d80d74409aca please follow it up there. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597848: [Python-apps-team] Bug#597848: Acknowledgement (cython: fresh upstream is available (0.13))
On Fri, Sep 24, 2010 at 2:09 PM, Sandro Tosi mo...@debian.org wrote: Hello Yaroslav, On Fri, Sep 24, 2010 at 23:01, Yaroslav Halchenko deb...@onerussian.com wrote: FWIW -- 0.13 uupdates and seems to build and function just fine (didn't check in clean pbuilder though) I know Ondrej is quite busy with his RL, and given you're interested in cython, you might want to co-maintain it with Ondrej under the PAPT umbrella: Ondrej, what do you think? Absolutely. Let me know if any action is needed on my part. Yaroslav, feel free to take over the maintenance of cython. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592563: sympy.galgebra.latex_ex.xdvi() creates a file named NUL on non-Linux architectures
Hi Jakub, On Tue, Aug 10, 2010 at 3:29 PM, Jakub Wilk jw...@debian.org wrote: Package: python-sympy Version: 0.6.7-1.1 Severity: normal User: debian-...@lists.debian.org Usertags: kfreebsd Tags: patch $ ls -l NUL ls: cannot access NUL: No such file or directory $ python sympy-NUL.py $ ls -l NUL -rw-r--r-- 1 jwilk jwilk 1666 Aug 11 00:22 NUL The attached patch fixes this bug. Thanks for the patch. I'll also apply it upstream. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589592: numpy.get_include() returns the wrong string
On Tue, Jul 20, 2010 at 4:16 AM, David Ham david@imperial.ac.uk wrote: I think this error is similar to one I am seeing and it appears to be caused by numpy.get_include() returning the wrong string. python -c 'import numpy; print numpy.get_include()' produces: /usr/lib/pymodules/python2.6/numpy/core/include but _numpyconfig.h and indeed all other header files under that path are actually in: /usr/lib/pymodules/python2.6/numpy/core/include/numpy Well, but for example if you use the numpy support in Cython, the autogenerated .c files include the headers like this: #include numpy/arrayobject.h so I think the get_include() function is correct. I mean it depends on the convention of course. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585334: python-sympy: Python string exceptions no more allowed in Python 2.6
On Wed, Jun 9, 2010 at 3:19 PM, Sandro Tosi mo...@ravel.debian.org wrote: Package: python-sympy Version: 0.6.7-1.1 Severity: minor User: debian-pyt...@lists.debian.org Usertags: python2.6 Hello, One of the changes brought by Python 2.6 is the removal of string exceptions, so they won't work in Python 2.6 (just a side note: they were also buggy before, since they were not guaranteed to work reliable even in 2.6); as an example: $ python2.5 -c raise 'eggs' -c:1: DeprecationWarning: raising a string exception is deprecated Traceback (most recent call last): File string, line 1, in module eggs $ python2.6 -c raise 'eggs' Traceback (most recent call last): File string, line 1, in module TypeError: exceptions must be old-style classes or derived from BaseException, not str Since 2.6 is the planned default version for the upcoming new Debian stable release, there are chances your package may be affected by this change. We are not sure your package is impacted, since the exception raise can be in a dead or very rare branch of the code, and so simply never being executed. We would like to leverage your package maintainer status and the relationship with upstream authors to inspect more deeply the issue and act accordingly (that includes: making this bug release critical, closing it as irrelevant, tagging it 'wontfix', or whatever is appropriate). Jakub Wilk made the discovery of the problem and kindly prepared a list [1] of all identified packages (downloaded on 2010-06-09) along with files lines that triggered the pattern search. [1] http://people.debian.org/~morph/strexp/string-exceptions.lintian This mass-bug filing was announced at 2010-06-06 on [2] (see the thread and the references there). [2] http://lists.debian.org/debian-devel/2010/06/msg00097.html We do not consider the whole situation a stopper for the Python transition to 2.6, except (of course) for those single bugs where severity will be increased. Thanks for reporting it. I just fixed the package upstream and all should be ok in the next release of SymPy. The bug would only occur on the Mac, which means it doesn't affect Debian anyway. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541314: necessity for cython-dbg
On Wed, May 5, 2010 at 10:00 AM, Yaroslav Halchenko deb...@onerussian.com wrote: severity 541314 important retitle 541314 cython-dbg is needed to avoid FTBFS for any python*-dbg using cython thanks Growing number of packages use cython and require it for building: $ build-rdeps --distribution sid cython Reverse Build-depends in main: -- pywavelets python-edje agtl python-edbus python-djvulibre python-elementary zhone python-phoneutils python-jswebkit fso-frameworkd scikit-learn python-evas sagemath python-ecore Found a total of 14 reverse build-depend(s) for cython. Not all of those yet package -dbg packages, which are of extreme importance while debugging generated dynamic libraries using python*-dbg and recent additions to gdb (via gdbinit tricks or Tools/gdb/libpython.py). Unfortunately that requires cython to have its own _d.so's built using python*-dbg as well (previous showstopper was scipy but thanks to Luca Falavigna, #525329 was resolved): $ python2.5-dbg -c 'import Cython.Compiler.Scanning' Traceback (most recent call last): File string, line 1, in module ImportError: /usr/lib/pymodules/python2.5/Cython/Compiler/Scanning.so: undefined symbol: Py_InitModule4_64 [9099 refs] $ python2.6-dbg -c 'import Cython.Compiler.Scanning' Traceback (most recent call last): File string, line 1, in module ImportError: /usr/lib/pymodules/python2.6/Cython/Compiler/Scanning.so: undefined symbol: Py_InitModule4_64 [16729 refs] Having no cython-dbg precludes me from finishing packaging of fresh NiPy code (src package nipy), which could be considered FTBFS, thus I am raising the severity. Thank you very much in advance! I don't have time to work on this. However, if you can submit a patch fixing the cython package to produce the dbg, I am sure someone can upload it (I am only a DM, so I can't upload to the NEW queue, which will be required due to the new binary dbg package). Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541314: necessity for cython-dbg
On Wed, May 5, 2010 at 12:39 PM, Yaroslav Halchenko deb...@onerussian.com wrote: oki doki -- see patch attached. Seems to build fine (pbuilder-ed it), doesn't introduce new lintian warnings, tested the effect of having -dbg on building nipy -- works like a charm. So it seems to be ok. If you review and Ok it I could upload it to Debian. Very nice! The patch is ok from me. Thanks for the work. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560298: Please package cython 0.12
On Fri, Feb 12, 2010 at 10:10 AM, Kirill Smelkov k...@mns.spb.ru wrote: On Sun, Feb 07, 2010 at 05:33:53PM -0800, Ondrej Certik wrote: On Wed, Feb 3, 2010 at 3:14 PM, Dave Beckett d...@dajobe.org wrote: One more vote for a new version - some software I want to use needs this. Could someone please provide a patch for the new version? I'll upload it. Something like this? Thanks you, that was it. Doing final tests in pbuilder, if all is fine, I'll upload now. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85b5c3131002131834i6376c4a3weaa799b7c594b...@mail.gmail.com
Bug#560298: Please package cython 0.12
On Wed, Feb 3, 2010 at 3:14 PM, Dave Beckett d...@dajobe.org wrote: One more vote for a new version - some software I want to use needs this. Could someone please provide a patch for the new version? I'll upload it. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#459716: time to close this bug? ;)
Hey Yaroslav! On Wed, Dec 23, 2009 at 3:17 AM, Yaroslav Halchenko deb...@onerussian.com wrote: Hi Ondrej, It seems to be good time to have this bug finally resolved and closed since you, Ondrej, seems have packaged pyglet long ago and it still alive in Debian ;) Yes, you are right. :) It is especially good timing since you've released sympy 0.6.6 so fresh Debian package is due anyways ;-P (I will not file a wishlist bugreport for another 2 days) I am uploading sympy 0.6.6 now, first with pyglet, and if all works, then I'll upload -2 without pyglet. It's been some time since I uploaded anything to Debian, so I want to go with slow steps to refresh myself with packaging skills. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541746: mpmath is bundled
On Sat, Aug 15, 2009 at 9:38 PM, Seo Sanghyeontinuv...@sparcs.kaist.ac.kr wrote: Package: python-sympy Version: 0.6.4-1 Severity: wishlist python-sympy bundles mpmath. It should use python-mpmath package instead. /usr/share/python-support/python-sympy/sympy/mpmath/__init__.py claims its version is 0.11, but source code does not match with mpmath 0.11 release. It seems to be an intermediate version between 0.11 and 0.12. For example, sympy.mpmath includes Riemann-Siegel Z-function which does not exist in mpmath 0.11, while it lacks twin prime constant which is included in mpmath 0.12. Also, the rest of sympy imports mpmath from sympy.mpmath. Rather than fixing all imports, maybe symlink to mpmath should be shipped. Currently this is not possible, as the mpmath api is changing too often and it would break sympy. However, hopefully it will settle in the future, so then we can just use mpmath in Debian. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#457967: update - fixed by using a different network card
Hi Moritz, On Thu, Jul 30, 2009 at 3:49 PM, Moritz Muehlenhoffj...@inutil.org wrote: On Sun, Feb 03, 2008 at 07:20:24PM +0100, Ondrej Certik wrote: Here is my latest update on this bug: http://bugzilla.kernel.org/show_bug.cgi?id=9648#c10 Either the sky2 driver or my hardware is broken. So I put there a different network card and now the 64 bit Debian works perfectly. More info above. Ondrey, in the upstream you reported that you've switched the network adaptor. Is that still the case? If so, we would Yes, I have switched my hardware, now everything works. close the bug like the upstream bug. It's an upstream bug, but it is still a bug (in Debian too then) imho. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537169: wrong paraview plugin path
Hi Oliver, On Wed, Jul 15, 2009 at 11:51 AM, Oliver Bormoli.b...@web.de wrote: Package: paraview Version: 3.4.0-4 Severity: normal The default plugin path, where additional plugins should be located, is set at the moment to /usr/bin/plugins, but I think it should set to /usr/lib/paraview/plugins. You can check this via Tools - Manage Plugins/Extensions... Please change this in further debian packages, so that additional plugins can be loaded at startup. Thanks for the bug report. If you have time, could you please send us a patch to the Debian packaging, that fixes it? That would help a lot. Thanks, Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521525: python-numpy: FTBFS: Fails to install f2py wrapper
On Fri, Jul 3, 2009 at 3:27 AM, Cyril Bruleboisk...@debian.org wrote: tag 521525 patch pending thanks Daniel Schepler schep...@math.berkeley.edu (27/03/2009): ... : # Adding links to manpages mkdir -p debian/python-numpy/usr/share/man/man1 for v in 2.5 2.4; do \ ln -sf f2py.1 debian/python-numpy/usr/share/man/man1/f2py$v.1; \ ln -sf f2py.1 debian/python-numpy/usr/share/man/man1/f2py$v-dbg.1; \ done : # Add unversioned numpy script mv /tmp/buildd/python-numpy-1.2.1/debian/tmp//usr/bin/f2py /tmp/buildd/python- numpy-1.2.1/debian/tmp//usr/bin/f2py2.5 mv: cannot stat `/tmp/buildd/python-numpy-1.2.1/debian/tmp//usr/bin/f2py': No such file or directory make: *** [install/python-numpy] Error 1 dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2 I'm not quite sure why it was previously building fine, but since I can reproduce it on the kfreebsd-* buildds as well as on amd64 sid chroots. So instead of using a conditional mv (based on whether the file exists or not), I'm deleting that line entirely. If the old behaviour shows up again, I guess it'll be time to investigate. I'd bet for some possible python-central change or whatever, and I'm not keen on spending time on that instead of the maintainer(s?) who didn't reply in 3 months to an RC bug. Also, debdiffing the old binaries and the rebuilt ones show no changes at all, so I'm quite confident I'm not obviously breaking something here. Many thanks for fixing it! I apologize for not having time for this. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527869: [D-m-team] Bug#527869: debian-maintainers: Annual ping for Ondrej Certik
2009/5/20 Aníbal Monsalve Salazar ani...@debian.org: On Fri, May 08, 2009 at 08:09:12PM -0700, Ondrej Certik wrote: Package: debian-maintainers Version: 1.58 Severity: normal Please consider this my annual ping as required here: http://wiki.debian.org/Maintainers#Annualping I am still actively working on my packages. I didn't know I have to annually ping. I'll be doing that from now on. Thanks, Ondrej Certik Thank you. Your next ping anniversary will be on the following date: Fri Nov 27 04:32:03 EST 2009 Thanks you too! Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527869: debian-maintainers: Annual ping for Ondrej Certik
Package: debian-maintainers Version: 1.58 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please consider this my annual ping as required here: http://wiki.debian.org/Maintainers#Annualping I am still actively working on my packages. I didn't know I have to annually ping. I'll be doing that from now on. Thanks, Ondrej Certik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoE86sACgkQKQ++Uu6gdgmhHQCfRLgaZHmoy6rfGRW64bVwrBL4 Nb8An1atolgJ7/NJ4Y6rA9PQUOmq3fLs =0/M5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526422: [Pkg-scicomp-devel] Bug#526422: linking of the dynamic libraries
at the end of the build, but also (after installing python-sparse) python -c import pysparse.umfpack might benefit. for the record, this is what is happening right now: $ python -c import pysparse.umfpack Traceback (most recent call last): File string, line 1, in module ImportError: /usr/lib/libumfpack.so.3.2.0: undefined symbol: amd_printf Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524073: python-numpy: please split atlas support into an optional package
On Tue, Apr 14, 2009 at 10:09 AM, Neil Williams codeh...@debian.org wrote: Package: python-numpy Version: 1:1.2.1-1 Severity: normal In #489253, ATLAS support was re-enabled. In #519233, python-gtk2 was made to depend on python-numpy. The net result is that something as small and simple as wicd now depends on libgfortran and libblas in unstable. I ran my own systems for some time without python-numpy, it was only that one issue in the sodoku game. I don't think that is sufficient justification for adding such a huge dependency chain like ATLAS. I was going to recommend wicd as the wireless network support tool for Emdebian Grip but I cannot do that if that means installing fortran! Making fortran essential for all GUI python support isn't going to help developments like openmoko or other embedded / small machine purposes. Yes, I agree, that this should be resolved. I always thought you can install python-numpy without atlas. At least it used to be that way, if this is not the case, it's a bug to be fixed. As to fortran, python-numpy needs gfortran to build (it contains some fortran files). If all you need is just the binary package, I think it could work without having gfortran installed. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524073: python-numpy: please split atlas support into an optional package
On Tue, Apr 14, 2009 at 2:51 PM, Neil Williams codeh...@debian.org wrote: On Tue, 14 Apr 2009 10:23:11 -0700 Ondrej Certik ond...@certik.cz wrote: On Tue, Apr 14, 2009 at 10:09 AM, Neil Williams codeh...@debian.org wrote: Package: python-numpy Version: 1:1.2.1-1 Severity: normal In #489253, ATLAS support was re-enabled. In #519233, python-gtk2 was made to depend on python-numpy. The net result is that something as small and simple as wicd now depends on libgfortran and libblas in unstable. I ran my own systems for some time without python-numpy, it was only that one issue in the sodoku game. I don't think that is sufficient justification for adding such a huge dependency chain like ATLAS. I was going to recommend wicd as the wireless network support tool for Emdebian Grip but I cannot do that if that means installing fortran! Making fortran essential for all GUI python support isn't going to help developments like openmoko or other embedded / small machine purposes. Yes, I agree, that this should be resolved. I always thought you can install python-numpy without atlas. At least it used to be that way, if this is not the case, it's a bug to be fixed. I think it's a result of the fix for #489253 - the option was re-enabled but the package was not split. As to fortran, python-numpy needs gfortran to build (it contains some fortran files). If all you need is just the binary package, I think it could work without having gfortran installed. The particular dependencies I need to have as optional are those related to ATLAS and Lapack : libblas.so.3gf , liblapack.so.3gf and libgfortran3 . The following packages have unmet dependencies: python-numpy: Depends: libblas3gf but it is not going to be installed or libblas.so.3gf or libatlas3gf-base but it is not installable Depends: libgfortran3 (= 4.3) but it is not installable Depends: liblapack3gf but it is not installable or liblapack.so.3gf but it is not installable or libatlas3gf-base but it is not installable E: Broken packages (This comes from the Emdebian Grip repository which is a filtered repository and does not include all packages in Debian, just the ones most suitable for embedded devices. These particular packages are large and undesirable for embedded targets.) I agree that this needs to be fixed. So your suggestion is to split numpy into several packages? How exactly? I am currently too busy to work on this, but if you know how to fix it and do the work, I'll upload your changes, or let you upload it. Thanks, Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522771: python-petsc4py: import ctypes
On Mon, Apr 6, 2009 at 4:16 AM, LUK ShunTim shuntim@polyu.edu.hk wrote: Package: python-petsc4py Version: 0.7.5-5 Severity: wishlist Hi, Please upgrade package to use petsc 3.0 which is now in sid. I won't have time to do it soon. If you send me patches, I can upload anytime though. Thanks for any work you do, Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519440: python-scipy: take care about deprecation warnings from numpy
On Fri, Mar 13, 2009 at 9:55 AM, Yaroslav Halchenko deb...@onerussian.com wrote: only later on I mentioned that scipy 0.7.0 is in unstable already. Thanks! and it seems that it became more compliant to numpy 1.2.1 -- all those warnings are gone. Since probably 0.7.0 will enter testing some time soon, and there will be no 1.2.1 numpy + 0.6.0 broken tandem, there is no reason to keep this bug open ;) closing it now (to take away the burden of closing it whenever scipy 0.7.0 is in testing) Ok, excellent. Thanks again for all the work you did. If you find any problems in the future, please report them. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519440: python-scipy: take care about deprecation warnings from numpy
On Thu, Mar 12, 2009 at 10:17 AM, Yaroslav Halchenko deb...@onerussian.com wrote: Package: python-scipy Version: 0.6.0-12 Severity: normal Any code which uses scipy and numpy on debian sid now provokes a flood of deprecation warnings like: In [1]:import scipy /usr/lib/python2.5/site-packages/scipy/misc/__init__.py:25: DeprecationWarning: NumpyTest will be removed in the next release; please update your code to use nose or unittest test = NumpyTest().test In [4]:mimport scipy.linalg /usr/lib/python2.5/site-packages/scipy/linalg/__init__.py:32: DeprecationWarning: NumpyTest will be removed in the next release; please update your code to use nose or unittest test = NumpyTest().test and more of scipy you import more you get of those... why should I care about receiving these ones if I don't use NumpyTest per se? If you are aware of this issue I would humbly appreciate if some action is taken... my little mind finds only a cruel suggestion to wrap those test instantiations within Thanks for the bug report, indeed, this is extremely annoying. I am aware of this, but I don't have time to fix it. I would appreciate if you could help us with it. We just need to patch numpy so that it doesn't emmit those warnings. Or patch scipy. Thanks for any work you do, Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519483: python-numpy: Warning - DeprecationWarning in numpy.histogram
On Thu, Mar 12, 2009 at 11:27 AM, Yaroslav Halchenko deb...@onerussian.com wrote: Package: python-numpy Version: 1:1.2.1-1 Severity: minor Just trying to come up with more or less clean solution to suppress deprecation warnings kindly puking on me from different corners of numpy ;) Yes, it's very annoying. Thanks for reporting it! Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514648: [sagemath] x+x produces EOF: End Of File (EOF) in read_nonblocking().
Package: sagemath
Version: 3.0.5dfsg-2
Severity: important
--- Please enter the report below this line. ---
Hi,
when I enter x+x, I get the following exception:
$ sage
--
| SAGE Version 3.0.5, Release Date: 2008-07-11 |
| Type notebook() for the GUI, and license() for information.|
--
sage: x+x
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (805, 0))
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (785, 0))
---
EOF Traceback (most recent call last)
/home/ondra/ipython console in module()
/home/ondra/lib/lib/python/IPython/Prompts.pyc in __call__(self, arg)
549
550 # and now call a possibly user-defined print mechanism
-- 551 manipulated_val = self.display(arg)
552
553 # user display hooks can change the variable to be stored in
/home/ondra/lib/lib/python/IPython/Prompts.pyc in _display(self, arg)
575 return IPython.generics.result_display(arg)
576 except TryNext:
-- 577 return self.shell.hooks.result_display(arg)
578
579 # Assign the default display method:
/home/ondra/lib/lib/python/IPython/hooks.pyc in __call__(self, *args, **kw)
139 #print prio,prio,cmd,cmd #dbg
140 try:
-- 141 ret = cmd(*args, **kw)
142 return ret
143 except ipapi.TryNext, exc:
/home/ondra/lib/lib/python/IPython/hooks.pyc in result_display(self, arg)
169
170 if self.rc.pprint:
-- 171 out = pformat(arg)
172 if '\n' in out:
173 # So that multi-line strings line up with the left column of
/usr/lib/python2.5/pprint.pyc in pformat(self, object)
109 def pformat(self, object):
110 sio = _StringIO()
-- 111 self._format(object, sio, 0, 0, {}, 0)
112 return sio.getvalue()
113
/usr/lib/python2.5/pprint.pyc in _format(self, object, stream, indent,
allowance, context, level)
127 self._readable = False
128 return
-- 129 rep = self._repr(object, context, level - 1)
130 typ = _type(object)
131 sepLines = _len(rep) (self._width - 1 - indent - allowance)
/usr/lib/python2.5/pprint.pyc in _repr(self, object, context, level)
193 def _repr(self, object, context, level):
194 repr, readable, recursive = self.format(object, context.copy(),
-- 195 self._depth, level)
196 if not readable:
197 self._readable = False
/usr/lib/python2.5/pprint.pyc in format(self, object, context, maxlevels, level)
205 and whether the object represents a recursive construct.
206
-- 207 return _safe_repr(object, context, maxlevels, level)
208
209
/usr/lib/python2.5/pprint.pyc in _safe_repr(object, context, maxlevels, level)
290 return format % _commajoin(components), readable, recursive
291
-- 292 rep = repr(object)
293 return rep, (rep and not rep.startswith('')), False
294
/usr/lib/python2.5/site-packages/sage/structure/sage_object.so in
sage.structure.sage_object.SageObject.__repr__
(sage/structure/sage_object.c:795)()
/usr/lib/python2.5/site-packages/sage/calculus/calculus.pyc in _repr_(self,
simplify)
4911 return self._simp._repr_(simplify=False)
4912 else:
- 4913 return self.simplify()._repr_(simplify=False)
4914
4915 ops = self._operands
/usr/lib/python2.5/site-packages/sage/calculus/calculus.pyc in simplify(self)
3224 return self._simp
3225 except AttributeError:
- 3226 S =
evaled_symbolic_expression_from_maxima_string(self._maxima_init_())
3227 S._simp = None
3228 self._simp = S
/usr/lib/python2.5/site-packages/sage/calculus/calculus.pyc in
evaled_symbolic_expression_from_maxima_string(x)
8317 x^e + I + e^pi
8318
- 8319 return symbolic_expression_from_maxima_string(maxima.eval(x))
8320
8321 def first_var(expr):
/usr/lib/python2.5/site-packages/sage/interfaces/expect.pyc in eval(self, code,
strip, synchronize, **kwds)
915 try:
916 with gc_disabled():
-- 917 return '\n'.join([self._eval_line(L, **kwds) for L in
code.split('\n') if L != ''])
918 except KeyboardInterrupt:
919
Bug#514569: [python-sphinx] sphinx-build prints UserWarning
Package: python-sphinx Version: 0.5.1-2 Severity: normal --- Please enter the report below this line. --- $ sphinx-build --help /var/lib/python-support/python2.5/pygments/plugin.py:39: UserWarning: Module sphinx was already imported from /usr/lib/python2.5/site-packages/sphinx/__init__.py, but /usr/lib/python2.5/site-packages is being added to sys.path import pkg_resources Sphinx v0.5.1 Usage: /usr/bin/sphinx-build [options] sourcedir outdir [filenames...] [...] I think that should not print the UserWarning, should it? Ondrej --- System information. --- Architecture: i386 Kernel: Linux 2.6.26-1-686 Debian Release: 5.0 500 unstablemirrors1.kernel.org --- Package information. --- Depends (Version) | Installed ==-+-=== python(= 2.4) | 2.5.2-3 python-central (= 0.6.7) | 0.6.8 python-docutils| 0.5-2 python-pygments (= 0.8) | 0.10-1 python-jinja (= 1.1) | 1.2-2 libjs-jquery | 1.2.6-2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514328: OpenFOAM-1.5 patch for paraview-3.4.0
On Sat, Feb 7, 2009 at 5:55 AM, Oliver Borm oli.b...@web.de wrote: Unfortunately, the package doesn't build. If you have time, any help is very appreciated. See the debian scientific computing team and the svn repository. Then we can apply this patch. Well basically I got the debian directory from http://svn.debian.org/wsvn/pkg-scicomp/paraview/trunk/debian ~6 weeks ago and applied the following patches: install.patch vtkFFMPEGWriter.patch paraview-3.4.0-OpenFOAM-48.patch And then I was able to build it on ubuntu 8.04 and 8.10. on x86 and amd64 machines each. I don't have a debian machine running at the time, so I can't test it under debian. But maybe you can get my debian source package from launchpad and test it under debian as well. Excellent, thanks for the work. Do you have a link somewhere to the .dsc and the patches? Is it this link? https://launchpad.net/%7Eoli-borm/+archive/ppa/+files/paraview_3.4.0-2~ppa3~intrepid1.dsc Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514328: OpenFOAM-1.5 patch for paraview-3.4.0
On Fri, Feb 6, 2009 at 2:35 AM, Oliver Borm oli.b...@web.de wrote: Package: paraview Version: 3.4.0-2~ppa3~intrepid1 Severity: wishlist *** Please type your report below this line *** Hello, the actual implementation of the OpenFOAM reader in paraview-3.4.0 is deprecated. Takuya OSHIMA has implemented a new version of the OpenFOAM reader, see for example (http://openfoam.cfd-online.com/cgi-bin/forum/show.cgi?tpc=1post=17466 and http://openfoamwiki.net/index.php/Tip_Building_ParaView3_With_OpenFOAM_Native_Reader). Is it possible to apply this patch directly to the paraview debian package? Gentoo linux has already done this, so you can get a patch which is known to work for example from (http://distfiles.gentoo.org/distfiles/paraview-3.4.0-OpenFOAM-48.patch.bz2). You can get an actual result of the patched paraview-3.4.0 with OpenFOAM-1.5 reader from my ubuntu ppa: https://launchpad.net/~oli-borm/+archive/ppa It should also be possible to compile the paraview-3.4.0 source package on debian. Unfortunately, the package doesn't build. If you have time, any help is very appreciated. See the debian scientific computing team and the svn repository. Then we can apply this patch. Thanks for any help, Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514328: [Pkg-scicomp-devel] Bug#514328: OpenFOAM-1.5 patch for paraview-3.4.0
On Fri, Feb 6, 2009 at 5:54 AM, Jordi Gutiérrez Hermoso jord...@gmail.com wrote: 2009/2/6 Oliver Borm oli.b...@web.de: the actual implementation of the OpenFOAM reader in paraview-3.4.0 is deprecated. Did you mean to submit this bug report to Ubuntu instead of Debian? Debian doesn't have paraview-3.4.0 packaged yet. Furthermore, all of your packages are from Ubuntu, not Debian. We might be able to coordinate packaging paraview jointly between Debian and Ubuntu, but right now it seems that each distro is doing its own thing, and until we are able to coordinate joint work, you might be better served by asking the Ubuntu developers directly. Oops, I didn't know Ubuntu is doing its own thing. I am one of the developers of the Debian package and I am very interested in collaboration. What is the best channel to do such a collaboration? For example we have a debian scientific computing team, would you be interested in joining it? http://wiki.debian.org/Teams/DebianScientificComputingTeam Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513853: [sagemath] the i386 sage segfaults
Package: sagemath Version: 3.0.5dfsg-1 Severity: grave --- Please enter the report below this line. --- Hi, Tim, first let me congratulate you for getting sagemath to Debian, great job! Currently the i386 package segfaults on my system: $ sage -- | SAGE Version 3.0.5, Release Date: 2008-07-11 | | Type notebook() for the GUI, and license() for information.| -- Unhandled SIGSEGV: A segmentation fault occured in SAGE. This probably occured because a *compiled* component of SAGE has a bug in it (typically accessing invalid memory) or is not properly wrapped with _sig_on, _sig_off. You might want to run SAGE under gdb with 'sage -gdb' to debug this. SAGE will now terminate (sorry). /usr/lib/sagemath/local/bin/sage-sage: line 216: 5137 Segmentation fault sage-ipython $@ -i -c $SAGE_STARTUP_COMMAND; But I suspect it's just because the sagemath in Debian is old, so packaging new upstream should fix it. Ondrej --- System information. --- Architecture: i386 Kernel: Linux 2.6.26-1-686 Debian Release: 5.0 500 unstablemirrors1.kernel.org --- Package information. --- Depends (Version) | Installed =-+-= libatlas3gf-base | 3.6.0-22 OR libatlas.so.3gf | libc6 (= 2.7-1) | 2.7-18 libecm0 | 6.2-1 libflint-1.011| 1.011-2 libfplll0 | 2.1.6+20071129-2 libgcc1 (= 1:4.1.1) | 1:4.3.3-2 libgivaro0| 3.2.10-1 libgmp3c2 | 2:4.2.2+dfsg-3 libgmpxx4ldbl | 2:4.2.2+dfsg-3 libgsl0ldbl (= 1.9) | 1.12+dfsg-1 libiml0 | 1.0.3-3 liblinbox0| 1.1.6~rc0-3 libm4ri-0.0.20080521 | 0.0.20080521-2 libmpfi0 | 1.3.4~rc4~cvs20080519-1 libmpfr1ldbl | 2.3.2.dfsg.1-1 libntl-5.4.2 | 5.4.2-4 libpari2-gmp (= 2.3.4-1) | 2.3.4-1 libpolybori-0.5.0-0 | 0.5~rc1-1 libqd2c2a | 2.3.7-1 libreadline5 (= 5.2) | 5.2-3.1 libsingular-3-0-4-3 | 3-0-4-3.dfsg-2 libstdc++6 (= 4.2.1) | 4.3.3-2 libsymmetrica-2.0 | 2.0-1 libzn-poly-0.8| 0.8-1 python ( 2.6) | 2.5.2-3 python (= 2.5) | 2.5.2-3 python-central (= 0.6.7) | 0.6.8 python2.5 | 2.5.2-15 gap | 4r4p10-2 singular | 3-0-4-3.dfsg-2 maxima| 5.17.0-1 genus2reduction | 0.3-2 lcalc | 0.0.20080205-1 sympow| 1.019-4 python-matplotlib | 0.98.3-5 gfan | 0.3dfsg-1 python-gd | 0.52debian-3.1 mercurial | 1.1.2-2 python-twisted| 8.1.0-4 python-numpy | 1:1.1.1-2 python-crypto | 2.0.1+dfsg1-2.3 python-moinmoin | 1.8.1-1.1 sqlite3 | 3.5.9-6 palp | 1.1-1 ipython | 0.8.4-1 python-gnutls | 1.1.6-1 python-scipy | 0.6.0-12 python-cvxopt | 1.1-1 scons | 1.0.0-1 r-base| 2.8.1-2 gfortran | 4:4.3.2-2 python-sqlalchemy | 0.4.8-1 gmp-ecm | 6.2-1 python-sympy | 0.6.3-1 python-networkx | 0.36-2 python-pexpect| 2.3-1 cython| 0.10.2-1 python-twisted-web2 | 8.1.0-1 pari-gp | 2.3.4-1 pari-extra| 2.1-1 tachyon | 0.98~beta.dfsg-1 python-rpy| 1.0.3-6 gap-guava | 3.6-2 python-processing | 0.52-1 python-polybori | 0.5~rc1-1 libcdd-test | 094b.dfsg-4 libjs-jquery | 1.2.6-2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Bug#513074: [paraview] paraview FTBFS in pbuilder
On Wed, Jan 28, 2009 at 3:43 AM, Christophe Prud'homme prudh...@debian.org wrote: Yup i am travelling a lot these days. I may not be able to make the upload before next week let me know if that's ok with you No, that is not ok. :) So I'll make the upload, but what should I do about the svn, which already contains the new upstream version? Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513074: [paraview] paraview FTBFS in pbuilder
Hi Gunnar, On Tue, Jan 27, 2009 at 10:49 AM, Gunnar Wolf gw...@iiec.unam.mx wrote: tags 513074 + unreproducible thanks Hi, I just built this package under a freshly updated cowbuilder on amd64. It failed to fail to build from source. I am _not_ attaching a build log, as -as I'm sure you are aware- the paraview build is a _very_ lengthy one, and I didn't request it at the beginning of the process. Still, if it is in some way useful to you, I can trigger it again. I am tagging this bug as unreproducible - If it fails to reproduce under any other systems, please do close it. If you still have the log, please attach it. I know that the build fails on amd64 in pbuilder. But it just built on i386 for me. So any information to reproduce this bug is useful. Ondrej P.S. Any help with fixing it is appreciated. :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513074: [paraview] paraview FTBFS in pbuilder
On Tue, Jan 27, 2009 at 1:49 PM, Gunnar Wolf gw...@iiec.unam.mx wrote: Find the build log attached to this mail - Amazing, almost two hours under a quite-decent system! :-} Yep. But the build you attached actually builds the package. Where is the problem? FWIW, I used cowbuilder (not pbuilder) as a build environment, in case it makes any difference... Although it should not. In my experience cowbuilder is slower than pbuilder (only the initial unpacking phase is a lot faster with cowbuilder). Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513074: [paraview] paraview FTBFS in pbuilder
On Tue, Jan 27, 2009 at 2:42 PM, Gunnar Wolf gw...@gwolf.org wrote: Yep. But the build you attached actually builds the package. Where is the problem? I fail to see a problem :) I started the build with high expectations on trying to fix an RC bug. But the bug is not there. The package is at least buildable on your i386 and on my AMD64, under (supposedly) identical environments. I'd suggest you to recreate your pbuilder and try again... maybe there is no bug? Ok, I'll try to rebuild my pbuilder and try again. Christophe, let's upload the new binary revision, so that it fixes the other RC bug (#513060)? Thanks, Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513060: [Pkg-scicomp-devel] solution
On Mon, Jan 26, 2009 at 11:33 AM, Christophe Prud'homme prudh...@debian.org wrote: On Mon, Jan 26, 2009 at 7:50 AM, Ondrej Certik ond...@certik.cz wrote: The solution is to rebuild paraview. I tried that on i386 in pbuilder and it seems it fixed the problem. which version of paraview ? if this is 3.2 I am fine with uploading it, 3.4 still fails with pbuilder. Otherwise with svn-buildpackage it works like a charm. It's the version that is currently in unstable. Could you please upload it? Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513060: [paraview] paraview doesn't start, missing symbols
Package: paraview Version: 3.2.3-4 Severity: grave --- Please enter the report below this line. --- Hi, after today's sid update, I can't start paraview anymore: $ paraview paraview: symbol lookup error: /usr/lib/paraview/libXdmf.so: undefined symbol: _ZN3MPI3Win14Set_errhandlerERKNS_10ErrhandlerE Christphe, I noticed you prepared a new upstream version. Did you upload it somewhere already? If not, let's upload it? Ondrej --- System information. --- Architecture: i386 Kernel: Linux 2.6.26-1-686 Debian Release: 5.0 500 unstablemirrors1.kernel.org --- Package information. --- Depends (Version) | Installed ===-+-== qt4-dev-tools | 4.4.3-2 libavcodec51 (= 0.svn20080206-8) | 0.svn20080206-15 OR libavcodec-unstripped-51 (= 0.svn20080206-8) | libavformat52 (= 0.svn20080206-8) | 0.svn20080206-15 OR libavformat-unstripped-52 (= 0.svn20080206-8) | libavutil49 (= 0.svn20080206-8) | 0.svn20080206-15 OR libavutil-unstripped-49(= 0.svn20080206-8) | libc6(= 2.7-1) | 2.7-18 libgcc1(= 1:4.1.1) | 1:4.3.3-1 libgl1-mesa-glx | 7.0.3-7 OR libgl1 | libglu1-mesa| 7.0.3-7 OR libglu1 | libhdf5-openmpi-1.6.6-0 | 1.6.6-4 libice6(= 1:1.0.0) | 2:1.0.4-1 libopenmpi1 | 1.3-1 libqt4-assistant (= 4.4.0) | 4.4.3-2 libqt4-network (= 4.4.0) | 4.4.3-2 libqt4-xml (= 4.4.0) | 4.4.3-2 libqtcore4 (= 4.4.0) | 4.4.3-2 libqtgui4(= 4.4.0) | 4.4.3-2 libreadline5 (= 5.2) | 5.2-3.1 libsm6 | 2:1.0.3-2 libstdc++6 (= 4.2.1) | 4.3.3-1 libx11-6| 2:1.1.5-2 libxext6| 2:1.0.4-1 libxt6 | 1:1.0.5-3 python2.5 (= 2.5) | 2.5.2-15 xlibmesa-gl | OR libgl1 | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513074: [paraview] paraview FTBFS in pbuilder
Package: paraview Version: 3.2.3-4 Severity: serious --- Please enter the report below this line. --- Hi, paraview fails to build in my freshly updated pbuilder on amd64. (I am sending the email from i386). I think this is a serious bug. [ 57%] Built target Cone6 make[6]: Entering directory `/tmp/buildd/paraview-3.2.3/obj-x86_64-linux-gnu/VTK/Examples/All' Scanning dependencies of target TreeLayout make[6]: Leaving directory `/tmp/buildd/paraview-3.2.3/obj-x86_64-linux-gnu/VTK/Examples/All' make[6]: Entering directory `/tmp/buildd/paraview-3.2.3/obj-x86_64-linux-gnu/VTK/Examples/All' [ 60%] Building CXX object Infovis/Cxx/CMakeFiles/TreeLayout.dir/TreeLayout.o Linking CXX executable /tmp/buildd/paraview-3.2.3/obj-x86_64-linux-gnu/bin/TreeLayout /usr/bin/ld: cannot find -lvtkInfovis collect2: ld returned 1 exit status make[6]: *** [/tmp/buildd/paraview-3.2.3/obj-x86_64-linux-gnu/bin/TreeLayout] Error 1 make[6]: Leaving directory `/tmp/buildd/paraview-3.2.3/obj-x86_64-linux-gnu/VTK/Examples/All' make[5]: *** [Infovis/Cxx/CMakeFiles/TreeLayout.dir/all] Error 2 Ondrej --- System information. --- Architecture: i386 Kernel: Linux 2.6.26-1-686 Debian Release: 5.0 500 unstablemirrors1.kernel.org --- Package information. --- Depends (Version) | Installed ===-+-== qt4-dev-tools | 4.4.3-2 libavcodec51 (= 0.svn20080206-8) | 0.svn20080206-15 OR libavcodec-unstripped-51 (= 0.svn20080206-8) | libavformat52 (= 0.svn20080206-8) | 0.svn20080206-15 OR libavformat-unstripped-52 (= 0.svn20080206-8) | libavutil49 (= 0.svn20080206-8) | 0.svn20080206-15 OR libavutil-unstripped-49(= 0.svn20080206-8) | libc6(= 2.7-1) | 2.7-18 libgcc1(= 1:4.1.1) | 1:4.3.3-1 libgl1-mesa-glx | 7.0.3-7 OR libgl1 | libglu1-mesa| 7.0.3-7 OR libglu1 | libhdf5-openmpi-1.6.6-0 | 1.6.6-4 libice6(= 1:1.0.0) | 2:1.0.4-1 libopenmpi1 | 1.3-1 libqt4-assistant (= 4.4.0) | 4.4.3-2 libqt4-network (= 4.4.0) | 4.4.3-2 libqt4-xml (= 4.4.0) | 4.4.3-2 libqtcore4 (= 4.4.0) | 4.4.3-2 libqtgui4(= 4.4.0) | 4.4.3-2 libreadline5 (= 5.2) | 5.2-3.1 libsm6 | 2:1.0.3-2 libstdc++6 (= 4.2.1) | 4.3.3-1 libx11-6| 2:1.1.5-2 libxext6| 2:1.0.4-1 libxt6 | 1:1.0.5-3 python2.5 (= 2.5) | 2.5.2-15 xlibmesa-gl | OR libgl1 | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513074: works in i386
I just checked, that if I compile it in pbuilder on i386, then everything works. So it seems amd64 related. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513060: solution
The solution is to rebuild paraview. I tried that on i386 in pbuilder and it seems it fixed the problem. Christophe --- we need to do binary only upload (or what it is called). However, the build will fail on amd64 and also the svn packaging is prepared for a new upstream release (but that unfortunately also fails to build). So what should we do? Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510237: [Python-apps-team] Bug#510237: [mayavi2] error creating view control
On Sat, Jan 3, 2009 at 6:03 PM, Varun Hiremath varunhirem...@gmail.com wrote: Hi Ondrej, On Tue, 30 Dec, 2008 at 10:29:18AM -0800, Ondrej Certik wrote: Package: mayavi2 Version: 3.1.0-1 Severity: important --- Please enter the report below this line. --- When upgraded to 3.1.0, when I start mayavi2, I get an error: ERROR|2008-12-30 10:25:14,086|error creating view control enthought.plugins.python_shell_view and the gui was messed up (however, on the second run, the gui seems ok, but the error stay). Besides that, I get this error to console: $ mayavi2 ERROR|2008-12-30 10:25:14,086|error creating view control enthought.plugins.python_shell_view Traceback (most recent call last): File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/workbench/workbench_window_layout.py, line 107, in add_view self._wx_add_view(view, position, relative_to, size) File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/workbench/workbench_window_layout.py, line 358, in _wx_add_view dock_control = self._wx_create_view_dock_control(view) File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/workbench/workbench_window_layout.py, line 464, in _wx_create_view_dock_control control = self._wx_get_view_control(view) File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/workbench/workbench_window_layout.py, line 557, in _wx_get_view_control view.control = view.create_control(parent) File /usr/lib/python2.5/site-packages/enthought/plugins/ipython_shell/view/ipython_shell_view.py, line 88, in create_control self.shell = IPythonWidget(parent, interp=self.interpreter) File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/ipython_widget.py, line 142, in __init__ self.control = self._create_control(parent) File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/ipython_widget.py, line 160, in _create_control shell = IPythonController(parent, -1, shell=self.interp) File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/ipython_widget.py, line 67, in __init__ func.__doc__ = '' AttributeError: attribute '__doc__' of 'instancemethod' objects is not writable (python:17617): Gtk-CRITICAL **: gtk_widget_set_colormap: assertion `!GTK_WIDGET_REALIZED (widget)' failed I am unable to reproduce this bug on either i386 or amd64. Could you please try a fresh install on some other machine and check if you can reproduce this? Also you might want to move/remove .enthought folder and check if it helps. I can't reproduce it anymore either. :( So feel free to close the bug. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510237: [mayavi2] error creating view control
Package: mayavi2 Version: 3.1.0-1 Severity: important --- Please enter the report below this line. --- When upgraded to 3.1.0, when I start mayavi2, I get an error: ERROR|2008-12-30 10:25:14,086|error creating view control enthought.plugins.python_shell_view and the gui was messed up (however, on the second run, the gui seems ok, but the error stay). Besides that, I get this error to console: $ mayavi2 ERROR|2008-12-30 10:25:14,086|error creating view control enthought.plugins.python_shell_view Traceback (most recent call last): File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/workbench/workbench_window_layout.py, line 107, in add_view self._wx_add_view(view, position, relative_to, size) File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/workbench/workbench_window_layout.py, line 358, in _wx_add_view dock_control = self._wx_create_view_dock_control(view) File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/workbench/workbench_window_layout.py, line 464, in _wx_create_view_dock_control control = self._wx_get_view_control(view) File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/workbench/workbench_window_layout.py, line 557, in _wx_get_view_control view.control = view.create_control(parent) File /usr/lib/python2.5/site-packages/enthought/plugins/ipython_shell/view/ipython_shell_view.py, line 88, in create_control self.shell = IPythonWidget(parent, interp=self.interpreter) File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/ipython_widget.py, line 142, in __init__ self.control = self._create_control(parent) File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/ipython_widget.py, line 160, in _create_control shell = IPythonController(parent, -1, shell=self.interp) File /usr/lib/python2.5/site-packages/enthought/pyface/ui/wx/ipython_widget.py, line 67, in __init__ func.__doc__ = '' AttributeError: attribute '__doc__' of 'instancemethod' objects is not writable (python:17617): Gtk-CRITICAL **: gtk_widget_set_colormap: assertion `!GTK_WIDGET_REALIZED (widget)' failed Ondrej --- System information. --- Architecture: i386 Kernel: Linux 2.6.26-1-686 Debian Release: 5.0 500 unstablemirrors1.kernel.org --- Package information. --- Depends (Version) | Installed =-+-=== libc6 (= 2.7-1) | 2.7-16 python ( 2.6) | 2.5.2-3 python (= 2.5) | 2.5.2-3 python-central (= 0.6.7) | 0.6.8 python-traits | 3.0.3-1 python-traitsgui | 3.0.3-1 python-wxgtk2.8 | 2.8.7.1-1.1 python-numpy | 1:1.1.1-2 python-vtk| 5.0.4-1.1 python-pkg-resources | 0.6c8-4 python-envisagecore | 3.0.1-1 python-envisageplugins| 3.0.1-1 python-apptools | 3.1.0-1 libjs-jquery | 1.2.6-1 python-configobj | 4.5.2-2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508113: python-numpy-doc is missing documentation
On Sun, Dec 7, 2008 at 4:36 PM, Joel j.o.e.l.pub...@gmail.com wrote: Package: python-numpy-doc Version: 1:1.1.0-3 /usr/share/docs/python-numpy-doc/index.html contains output from an epydoc sample but no doco related to numpy. Indeed, thanks for noticing. The upstream documentation has changed to sphinx, we only need to fix the package to generate that. If you'd like to help, follow this thread: http://lists.debian.org/debian-python/2008/12/msg0.html Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509742: patch fixing the bug
The attached patch fixes it.
Ondrej
From 91e4168bb3326c304d945fb794641ae5f1da504c Mon Sep 17 00:00:00 2001
From: Ondrej Certik ond...@certik.cz
Date: Thu, 25 Dec 2008 18:35:35 +0100
Subject: [PATCH] Fixing all paths to /usr/sbin/etckeeper.
---
apt.conf |8
pacman-g2.hook |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/apt.conf b/apt.conf
index b2e0f9b..bd6afc5 100644
--- a/apt.conf
+++ b/apt.conf
@@ -1,5 +1,5 @@
-DPkg::Pre-Install-Pkgs { if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi; };
-DPkg::Post-Invoke { if [ -x /usr/bin/etckeeper ]; then etckeeper post-install; fi; };
+DPkg::Pre-Install-Pkgs { if [ -x /usr/sbin/etckeeper ]; then etckeeper pre-install; fi; };
+DPkg::Post-Invoke { if [ -x /usr/sbin/etckeeper ]; then etckeeper post-install; fi; };
-RPM::Pre-Install-Pkgs { if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi; };
-RPM::Post-Invoke { if [ -x /usr/bin/etckeeper ]; then etckeeper post-install; fi; };
+RPM::Pre-Install-Pkgs { if [ -x /usr/sbin/etckeeper ]; then etckeeper pre-install; fi; };
+RPM::Post-Invoke { if [ -x /usr/sbin/etckeeper ]; then etckeeper post-install; fi; };
diff --git a/pacman-g2.hook b/pacman-g2.hook
index ac2e099..bd93d73 100644
--- a/pacman-g2.hook
+++ b/pacman-g2.hook
@@ -1,13 +1,13 @@
#!/bin/sh
pre_sysupgrade() {
- if [ -x /usr/bin/etckeeper ]; then
+ if [ -x /usr/sbin/etckeeper ]; then
etckeeper pre-install
fi
}
post_sysupgrade() {
- if [ -x /usr/bin/etckeeper ]; then
+ if [ -x /usr/sbin/etckeeper ]; then
etckeeper post-install
fi
}
--
1.5.6.5
Bug#509742: [etckeeper] please fix the apt/apt.conf.d/05etckeeper
Package: etckeeper
Version: 0.22
Severity: important
--- Please enter the report below this line. ---
Hi,
since etckeeper moved to /sbin, the 05etckeeper needs to be updated:
diff --git a/apt/apt.conf.d/05etckeeper b/apt/apt.conf.d/05etckeeper
index b2e0f9b..bd6afc5 100644
--- a/apt/apt.conf.d/05etckeeper
+++ b/apt/apt.conf.d/05etckeeper
@@ -1,5 +1,5 @@
-DPkg::Pre-Install-Pkgs { if [ -x /usr/bin/etckeeper ]; then etckeeper pre-inst
-DPkg::Post-Invoke { if [ -x /usr/bin/etckeeper ]; then etckeeper post-ins
+DPkg::Pre-Install-Pkgs { if [ -x /usr/sbin/etckeeper ]; then etckeeper pre-ins
+DPkg::Post-Invoke { if [ -x /usr/sbin/etckeeper ]; then etckeeper post-in
-RPM::Pre-Install-Pkgs { if [ -x /usr/bin/etckeeper ]; then etckeeper pre-insta
-RPM::Post-Invoke { if [ -x /usr/bin/etckeeper ]; then etckeeper post-inst
+RPM::Pre-Install-Pkgs { if [ -x /usr/sbin/etckeeper ]; then etckeeper pre-inst
+RPM::Post-Invoke { if [ -x /usr/sbin/etckeeper ]; then etckeeper post-ins
Otherwise etckeeper doesn't run. I think this is important. :)
Ondrej
--- System information. ---
Architecture: i386
Kernel: Linux 2.6.26-1-686
Debian Release: 5.0
500 unstableftp.cz.debian.org
--- Package information. ---
Depends (Version) | Installed
=-+-==
git-core(= 1:1.5.4) | 1:1.5.6.5-2
OR mercurial | 1.0.1-5.1
OR bzr (= 1.4~) | 1.5-1.1
debconf (= 0.5) | 1.5.24
OR debconf-2.0 |
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499504: Verified
Hi Scott, what can be done so that this bug can be closed? Shall I get the fixed version to be uploaded to backports for etch? Thanks, Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509045: fix
Hi Scott and Thomas, the attached patch fixes it. In fact, can I NMU upload the package as part of my NM process? :) Thanks, Ondrej From 3cafc70d5f0acce563585ead447fa11a38b44df5 Mon Sep 17 00:00:00 2001 From: Ondrej Certik ond...@certik.cz Date: Fri, 19 Dec 2008 17:25:43 +0100 Subject: [PATCH] Renames dkimverify to dkimproxy-verify and manpage as well --- debian/man/dkimproxy-verify.1 | 10 ++ debian/man/dkimverify.1 | 10 -- debian/manpages |2 +- debian/rules |2 +- 4 files changed, 12 insertions(+), 12 deletions(-) create mode 100644 debian/man/dkimproxy-verify.1 delete mode 100644 debian/man/dkimverify.1 diff --git a/debian/man/dkimproxy-verify.1 b/debian/man/dkimproxy-verify.1 new file mode 100644 index 000..4a48016 --- /dev/null +++ b/debian/man/dkimproxy-verify.1 @@ -0,0 +1,10 @@ +.TH dkimproxy-verify 1 + +.SH NAME +dkimproxy-verify \- insert here a description + +.SH DESCRIPTION +This man page is a stub, please contribute + +.SH SEE ALSO +dkimproxy.in(8), dkimproxy.out(8), dkimsign(1), dkim_responder(1) diff --git a/debian/man/dkimverify.1 b/debian/man/dkimverify.1 deleted file mode 100644 index af4a2dc..000 --- a/debian/man/dkimverify.1 +++ /dev/null @@ -1,10 +0,0 @@ -.TH dkimverify 1 - -.SH NAME -dkimverify \- insert here a description - -.SH DESCRIPTION -This man page is a stub, please contribute - -.SH SEE ALSO -dkimproxy.in(8), dkimproxy.out(8), dkimsign(1), dkim_responder(1) diff --git a/debian/manpages b/debian/manpages index 1dd233c..bc6eb6c 100644 --- a/debian/manpages +++ b/debian/manpages @@ -2,4 +2,4 @@ debian/man/dkimproxy.in.8 debian/man/dkimproxy.out.8 debian/man/dkim_responder.1 debian/man/dkimsign.1 -debian/man/dkimverify.1 +debian/man/dkimproxy-verify.1 diff --git a/debian/rules b/debian/rules index aae5207..3dac9f1 100755 --- a/debian/rules +++ b/debian/rules @@ -41,7 +41,7 @@ install: config.status mv $(CURDIR)/debian/$(DK_PKGNAME)/usr/lib/* $(CURDIR)/debian/$(DK_PKGNAME)/usr/share/perl5 rmdir $(CURDIR)/debian/$(DK_PKGNAME)/usr/lib mv $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkim_responder.pl $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkim_responder - mv $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimverify.pl $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimverify + mv $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimverify.pl $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimproxy-verify mv $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimsign.pl $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimsign # These are deamons, they have nothing to do in /usr/bin !!! mv $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimproxy.in $(CURDIR)/debian/$(DK_PKGNAME)/usr/sbin -- 1.6.0.4
Bug#470579: cython: python setup.py sdist doesn't include *.pxd
Hi Greg! On Sat, Mar 22, 2008 at 12:10 AM, Ondrej Certik ond...@certik.cz wrote: On Wed, Mar 12, 2008 at 2:49 AM, Greg Kochanski g...@kochanski.org wrote: Package: cython Version: 0.9.6.12-1 Severity: normal I have a project in a directory with .../lib/muscle.pyx .../lib/muscle.pxd et cetera My setup.py is attached below.When I make a source distribution, it is created without the .pxd files: $ python setup.py sdist $ tar tvzf build/.tar.gz | fgrep pxd yields nothing. Could you please try the new cython package in Debian if it works better? If not, could you please send me your full project, so that I can reproduce the bug? That'd help us a lot. Thanks, Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#469848: reported upstream
reassign 469848 python2.5 On Thu, Mar 20, 2008 at 9:40 AM, Ondrej Certik ond...@certik.cz wrote: Thanks for the bug report. I reported it upstream: http://code.google.com/p/sympy/issues/detail?id=752 as a workaround, use: $ pydoc2.4 -k foobarqux $ I am now getting: on...@pc232:~$ pydoc2.5 -k foobarqux Traceback (most recent call last): File /usr/bin/pydoc2.5, line 5, in module pydoc.cli() File /usr/lib/python2.5/pydoc.py, line 2195, in cli apropos(val) File /usr/lib/python2.5/pydoc.py, line 1890, in apropos ModuleScanner().run(callback, key) File /usr/lib/python2.5/pydoc.py, line 1855, in run for importer, modname, ispkg in pkgutil.walk_packages(): File /usr/lib/python2.5/pkgutil.py, line 125, in walk_packages for item in walk_packages(path, name+'.', onerror): File /usr/lib/python2.5/pkgutil.py, line 110, in walk_packages __import__(name) File /home/ondra/lib/lib/python/debexpo-0.0.0dev-py2.5.egg/debexpo/tests/__init__.py, line 66, in module cmd.run([test_file]) File /home/ondra/lib/lib/python/PasteScript-1.3.6-py2.5.egg/paste/script/appinstall.py, line 68, in run return super(AbstractInstallCommand, self).run(new_args) File /home/ondra/lib/lib/python/PasteScript-1.3.6-py2.5.egg/paste/script/command.py, line 212, in run result = self.command() File /home/ondra/lib/lib/python/PasteScript-1.3.6-py2.5.egg/paste/script/appinstall.py, line 447, in command conf = appconfig(config_spec, relative_to=os.getcwd()) File /home/ondra/lib/lib/python/PasteDeploy-1.3.1-py2.5.egg/paste/deploy/loadwsgi.py, line 204, in appconfig global_conf=global_conf) File /home/ondra/lib/lib/python/PasteDeploy-1.3.1-py2.5.egg/paste/deploy/loadwsgi.py, line 237, in loadcontext global_conf=global_conf) File /home/ondra/lib/lib/python/PasteDeploy-1.3.1-py2.5.egg/paste/deploy/loadwsgi.py, line 264, in _loadconfig loader = ConfigLoader(path) File /home/ondra/lib/lib/python/PasteDeploy-1.3.1-py2.5.egg/paste/deploy/loadwsgi.py, line 328, in __init__ File %r not found % filename) OSError: File '/home/ondra/lib/lib/python/debexpo-0.0.0dev-py2.5.egg/test.ini' not found so I think this is not a bug in sympy, but in pydoc2.5, that should handle cases when modules cannot be imported more sanely. Reassigning to python2.5. Thanks, Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503148: histogram
Reported upstream: http://sourceforge.net/mailarchive/forum.php?thread_name=85b5c3130812190918n33ab982dv2c06c9e98d9cd758%40mail.gmail.comforum_name=matplotlib-users Ondrej -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491855: Reproducable
Hi Jan! On Wed, Dec 17, 2008 at 1:46 AM, Eddy Petrișor eddy.petri...@gmail.com wrote: Jan Hauke Rahm a scris: tags 491855 +confirmed tags 491855 +wontfix thanks Hi Ondrej, I was able to kind of reproduce this bug with the package from testing. Unfortunately this is probably a wontfix. It seems to me that the list of files (which is in this case about 20k lines) to inject is passed to various commands which all could fail. This is not to be solved in a short way, I'm afraid, unless we're doing a major rewrite of a lot of code. Indeed that analysis is correct. svn-bp is limited by the fact that is uses external tools and passes that through the shell, so it is really hard not ot hit a shell limit for packages which contain many files. PS: Comments from co-maintainers welcome! When the time is ripe and svn-bp will use SVN::Client while avoiding the shell this issue might be gone by itself. I agree with your analysis -- only please CC me together with the bugs, I haven't noticed that you have commented on that bug report, until today. The atlas packaging should be fixed, but at that time I thought that svn could help us a bit. We solve the problem by some other means. Ondrej
Bug#507746: python-numpy: link to cfunc.h missing in /usr/lib/python2.5/site-packages/numpy/core/include/numpy
On Mon, Dec 8, 2008 at 1:49 AM, Janis Hagelberg [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 12:32 AM, Janis Hagelberg [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 2:36 AM, Janis Hagelberg [EMAIL PROTECTED] wrote: Package: python-numpy Version: 1:1.1.1-1 Severity: normal There seem to be a missing link to cfunc.h in usr/lib/python2.5/site-packages/numpy/core/include/numpy This bug seems to be somehow related to bug #499613, but using the solution of #499613 didn't help compiling C code that includes numpy/libnumarray.h. Is this head file for old code that uses numarray? With the additional link to cfunc.h in usr/lib/python2.5/site-packages/numpy/core/include/numpy it worked. If you could send us a patch to our packaging that fixes that, I'll apply, test it and upload. Thanks, Ondrej Maybe this would look more like a patch (still haven't found any useful doc) @@ -0,0 +1,7 @@ +usr/share/pyshared/numpy/numarray/numpy/cfunc.h usr/share/pyshared/numpy/core/include/numpy/cfunc.h Which file is it? Just apply it to the checketout file and send the output of svn di. Is it debian/python-numpy.links? Still not sure how to apply the patch --- but if you send the output of svn di, I'll just use apply. Thanks, Ondrej Hi! Below is the output of svn di, with the patch: Index: python-numpy.links === --- python-numpy.links (revision 7084) +++ python-numpy.links (working copy) @@ -4,4 +4,5 @@ usr/share/pyshared/numpy/numarray/numpy/ieeespecial.h usr/share/pyshared/numpy/core/include/numpy/ieeespecial.h usr/share/pyshared/numpy/numarray/numpy/libnumarray.h usr/share/pyshared/numpy/core/include/numpy/libnumarray.h usr/share/pyshared/numpy/numarray/numpy/arraybase.h usr/share/pyshared/numpy/core/include/numpy/arraybase.h +usr/share/pyshared/numpy/numarray/numpy/cfunc.h usr/share/pyshared/numpy/core/include/numpy/cfunc.h usr/share/pyshared/numpy/core/include/numpy usr/include/numpy I see -- in fact, this line is already in that file, only it was not uploaded. So I just did that, could you please check, if it works now? You can get the binary package from: http://incoming.debian.org/ Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507746: python-numpy: link to cfunc.h missing in /usr/lib/python2.5/site-packages/numpy/core/include/numpy
On Thu, Dec 4, 2008 at 2:36 AM, Janis Hagelberg [EMAIL PROTECTED] wrote: Package: python-numpy Version: 1:1.1.1-1 Severity: normal There seem to be a missing link to cfunc.h in usr/lib/python2.5/site-packages/numpy/core/include/numpy This bug seems to be somehow related to bug #499613, but using the solution of #499613 didn't help compiling C code that includes numpy/libnumarray.h. Is this head file for old code that uses numarray? With the additional link to cfunc.h in usr/lib/python2.5/site-packages/numpy/core/include/numpy it worked. If you could send us a patch to our packaging that fixes that, I'll apply, test it and upload. Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507746: python-numpy: link to cfunc.h missing in /usr/lib/python2.5/site-packages/numpy/core/include/numpy
On Thu, Dec 4, 2008 at 11:45 PM, Janis Hagelberg [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 2:36 AM, Janis Hagelberg [EMAIL PROTECTED] wrote: Package: python-numpy Version: 1:1.1.1-1 Severity: normal There seem to be a missing link to cfunc.h in usr/lib/python2.5/site-packages/numpy/core/include/numpy This bug seems to be somehow related to bug #499613, but using the solution of #499613 didn't help compiling C code that includes numpy/libnumarray.h. Is this head file for old code that uses numarray? The code comes from stsci_python_2.7 which is needed by pyraf. The code may not be up to date, even though the 2.7 release is from November 2008. With the additional link to cfunc.h in usr/lib/python2.5/site-packages/numpy/core/include/numpy it worked. If you could send us a patch to our packaging that fixes that, I'll apply, test it and upload. This is my first bug-report, and I am not quite sure how to make patch. I just unpacked data.tar.gz, added the missing link, and then repacked it. If this is not the way it should be done, just send me a link with a howto, and I will do it. Thanks, Ondrej Tanks to you for the package! Thanks for the patch. Please CC the bug, so that other people know what is happening. The way to do create a patch is this: $ apt-get install devscripts $ debcheckout python-numpy $ cd python-numpy patch the files and $ svn di See here for more info: http://wiki.debian.org/PAPT_Howto our main page is here: http://wiki.debian.org/Teams/PythonModulesTeam Please ask if you have problems building the package. Thanks a lot for any work you do. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505999: python-numpy: memory leak in exponentiation
On Mon, Nov 17, 2008 at 5:47 PM, Jiri Baum [EMAIL PROTECTED] wrote: Package: python-numpy Version: 1:1.1.0-3 Severity: minor Raising zero to a negative power sometimes leaks memory, depending on the types involved. While this is easy to work around (check for zero and deal with it separately), it shouldn't happen. Thanks, I reported that upstream: http://projects.scipy.org/pipermail/numpy-discussion/2008-November/038682.html Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505726: the bug is not fixed
reopen 505726 thanks Hi Matthias! I do not consider this bug as fixed, because the symlink (in alternatives) is still missing. See my original report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505726#5 also, could you please reply to my question here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505726#20 I cannot find the bug you are referring to. Thanks a lot, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505726: [icedtea6-plugin] doesn't work with iceweasel
Package: icedtea6-plugin Version: 6b12-1~exp1 Severity: normal --- Please enter the report below this line. --- Hi, the first problem is that this plugin doesn't install the .so for iceweasel, so the java applets don't work at all. This command fixes that: $ sudo update-alternatives --install /usr/lib/iceweasel/plugins/libjavaplugin.so iceweasel-javaplugin.so /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so 100 Now applets work. However, the javascript - applet communication doesn't. This package from experimental is supposed to fix that, right? I am not an expert in java/javascript, but if you tell me how to debug it, I'll do it. Thanks, Ondrej --- System information. --- Architecture: i386 Kernel: Linux 2.6.26-1-686 Debian Release: lenny/sid 500 unstableftp.cz.debian.org 500 unstabledebian.certik.cz 1 experimentalftp.cz.debian.org --- Package information. --- Depends (Version) | Installed =-+- openjdk-6-jre (= 6b12-1~exp1) | 6b12-1~exp1 libatk1.0-0 (= 1.20.0) | 1.22.0-1 libc6 (= 2.7-1) | 2.7-16 libcairo2 (= 1.2.4) | 1.6.4-6.1 libgcc1 (= 1:4.1.1) | 1:4.3.2-1 libglib2.0-0 (= 2.12.0) | 2.16.6-1 libgtk2.0-0 (= 2.12.0) | 2.12.11-4 libmozjs1d(= 1.9~b4) | 1.9.0.3-1 libnspr4-0d (= 1.8.0.10) | 4.7.1-4 libpango1.0-0 (= 1.20.3) | 1.20.5-3 libstdc++6 (= 4.1.1) | 4.3.2-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505726: communication started to work
Hi, after couple restarts, the js - applet communication started to work. :) If you go to this page: http://developer.apple.com/internet/safari/samples/ColorBlockApplet.html then clicking the buttons change the applet color. The reverse communication doesn't work, e.g. clicking on the applet does nothing. So just the link needs to be fixed. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505726: [Openjdk] Bug#505726: communication started to work
Hi Matthias, On Fri, Nov 14, 2008 at 8:16 PM, Matthias Klose [EMAIL PROTECTED] wrote: Ondrej Certik schrieb: Hi, after couple restarts, the js - applet communication started to work. :) If you go to this page: http://developer.apple.com/internet/safari/samples/ColorBlockApplet.html then clicking the buttons change the applet color. The reverse communication doesn't work, e.g. clicking on the applet does nothing. no, the applet is wrong. there's a closed icedtea bug report about this. Could you please point me to it? I looked at the only two packages that have the word icedtea in their name and I didn't find any closed bugs: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=icedtea6-plugin http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=icedtea-gcjwebplugin Well, except this one. :) Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501501: status
Hi Patricio, Angus and Helmut, thanks for reporting this annoying bug. Unfortunately I cannot reproduce it, it works just fine on my sid. If I find time, I'll try to install etch and upgrade to lenny if it shows up. This bug needs to be solved, it's a showstopper. So any help with this is appreciated. In the meantime, just install python-matplotlib from unstable and let us know if it fixes the problem. Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501618: applied
Thanks Thiemo for the patch! It is applied to matplotlib svn. Sandro, can the package be uploaded now? The upload fixes an RC bug. I noticed in the changelog: * Release in collaboration with Benjamin Drung, from Ubuntu So please upload or let me know and I'll upload. Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501215: reportbug: report bug crashes when hitting ctrl-down in common issues
Package: reportbug Version: 3.44 Severity: normal When hitting ctrl-down in the dialog after clicking continue right after starting reportbug, reportbug crashes with the following stacktrace: Traceback (most recent call last): File /usr/bin/reportbug, line 1827, in module main() File /usr/bin/reportbug, line 850, in main return iface.user_interface() File /usr/bin/reportbug, line 1506, in user_interface Don't send your debconf settings., nowrap=True)): File /usr/share/reportbug/reportbuglib/reportbug_ui_urwid.py, line 348, in yes_no result = box.main(ui) File /usr/share/reportbug/reportbuglib/reportbug_ui_urwid.py, line 202, in main return self.ui.run_wrapper(self.run) File /var/lib/python-support/python2.5/urwid/raw_display.py, line 231, in run_wrapper return fn() File /usr/share/reportbug/reportbuglib/reportbug_ui_urwid.py, line 153, in run canvas = self.view.render( size, focus=True ) File /var/lib/python-support/python2.5/urwid/widget.py, line 85, in cached_render canv = fn(self, size, focus=focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 2112, in render canv = self.w.render(size, focus=focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 85, in cached_render canv = fn(self, size, focus=focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 1454, in render canv = self.body.render( (maxcol,maxrow-top-bottom),focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 85, in cached_render canv = fn(self, size, focus=focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 1276, in render canv = self.w.render((maxcol,)+size[1:], focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 85, in cached_render canv = fn(self, size, focus=focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 1976, in render focus and self.focus_part == 'body') File /var/lib/python-support/python2.5/urwid/widget.py, line 85, in cached_render canv = fn(self, size, focus=focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 2639, in render focus = focus and self.focus_col == i) File /var/lib/python-support/python2.5/urwid/widget.py, line 85, in cached_render canv = fn(self, size, focus=focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 1976, in render focus and self.focus_part == 'body') File /var/lib/python-support/python2.5/urwid/widget.py, line 85, in cached_render canv = fn(self, size, focus=focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 2112, in render canv = self.w.render(size, focus=focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 85, in cached_render canv = fn(self, size, focus=focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 1454, in render canv = self.body.render( (maxcol,maxrow-top-bottom),focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 85, in cached_render canv = fn(self, size, focus=focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 1276, in render canv = self.w.render((maxcol,)+size[1:], focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 85, in cached_render canv = fn(self, size, focus=focus) File /var/lib/python-support/python2.5/urwid/widget.py, line 1976, in render focus and self.focus_part == 'body') File /var/lib/python-support/python2.5/urwid/widget.py, line 121, in finalize_render canv = fn(self, size, focus=focus) File /var/lib/python-support/python2.5/urwid/listbox.py, line 363, in render assert rows = maxrow, Listbox contents too long! Probably urwid's fault (please report): %s % `top,middle,bottom` AssertionError: Listbox contents too long! Probably urwid's fault (please report): ((9, []), (-24, reportbuglib.reportbug_ui_urwid.SelectableText object at 0x84c6bec, 0, 37, (0, 27)), (0, [])) Ondrej -- Package-specific info: ** Environment settings: DEBEMAIL=[EMAIL PROTECTED] INTERFACE=urwid ** /home/ondra/.reportbugrc: reportbug_version 3.38 mode advanced ui urwid email [EMAIL PROTECTED] no-cc header X-Debbugs-CC: [EMAIL PROTECTED] smtphost bugs.debian.org -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages reportbug depends on: ii apt 0.7.14+b1 Advanced front-end for dpkg ii python2.5.2-2An interactive high-level object-o ii python-central0.6.8 register and build utility for Pyt reportbug recommends no packages. Versions of packages reportbug suggests: pn debconf-utils none (no description available) ii debsums 2.0.36
Bug#500847: [cython] Does not accept Unicode docstrings
On Thu, Oct 2, 2008 at 1:28 AM, P M [EMAIL PROTECTED] wrote: Package: cython Version: 0.9.8-1 Severity: normal Cython does not accept Unicode docstrings in .pyx files. I have attached a sample session with a .pyx file, where I define a function with a docstring containing Greek characters. The file's contents are in UTF-8. What is more, instead of an error message, I got a python traceback! This problem does not show up with comments in Unicode or other string literals. $ cat bug.pyx def hello(): '''Γειά σου, κόσμε!''' print 'Hello, world!' $ cython bug.pyx Traceback (most recent call last): File /usr/bin/cython, line 8, in module main(command_line = 1) File /var/lib/python-support/python2.5/Cython/Compiler/Main.py, line 527, in main result = compile(sources, options) File /var/lib/python-support/python2.5/Cython/Compiler/Main.py, line 505, in compile return compile_multiple(source, options) File /var/lib/python-support/python2.5/Cython/Compiler/Main.py, line 472, in compile_multiple result = context.compile(source, options) File /var/lib/python-support/python2.5/Cython/Compiler/Main.py, line 327, in compile tree.process_implementation(scope, options, result) File /var/lib/python-support/python2.5/Cython/Compiler/ModuleNode.py, line 59, in process_implementation self.generate_c_code(env, options, result) File /var/lib/python-support/python2.5/Cython/Compiler/ModuleNode.py, line 243, in generate_c_code self.body.generate_function_definitions(env, code, options.transforms) File /var/lib/python-support/python2.5/Cython/Compiler/Nodes.py, line 839, in generate_function_definitions with_pymethdef = env.is_py_class_scope) File /var/lib/python-support/python2.5/Cython/Compiler/Nodes.py, line 1442, in generate_function_header self.entry.doc)) File /var/lib/python-support/python2.5/Cython/Compiler/Code.py, line 52, in putln self.put(code) File /var/lib/python-support/python2.5/Cython/Compiler/Code.py, line 69, in put self._write(code) UnicodeEncodeError: 'ascii' codec can't encode characters in position 38-41: ordinal not in range(128) $ Thank you for your time. Thanks, I reported it upstream. Ondrej
Bug#500847: [Python-apps-team] Bug#500847: [cython] Does not accept Unicode docstrings
2008/10/2 Piotr Ożarowski [EMAIL PROTECTED]: [P M, 2008-10-02 01:34] $ cat bug.pyx def hello(): '''Γειά σου, κόσμε!''' print 'Hello, world!' there's a missing: # -*- coding: utf-8 -*- but it doesn't work with this line either Please follow the thread Does not accept Unicode docstrings here: http://codespeak.net/pipermail/cython-dev/2008-October/thread.html#2506 and provide more info. Preferably speak with upstream directly. Thanks, Ondrej
Bug#500815: /usr/share/pyshared/scipy/weave/inline_tools.py: printing of anything should be conditional on verbose level
Hi Yaroslav! On Wed, Oct 1, 2008 at 7:13 PM, Yaroslav Halchenko [EMAIL PROTECTED] wrote: Package: python-scipy Version: 0.6.0-12 Severity: normal File: /usr/share/pyshared/scipy/weave/inline_tools.py # it's nice to let the users know when anything gets compiled, as the # slowdown is very noticeable. print 'weave: compiling' should be preceeded with condition if verbose 0: otherwise there is no native way to make weave less 'nice' Thanks so much for both the patches! Could you please sign in the DPMT: http://wiki.debian.org/Teams/PythonModulesTeam and commit your changes as patches to the scipy package? I'll then check it and if all is ok, upload (unfortunately I am too busy now to do the patches myself). If you find anything else that isn't working, please report it as well. We welcome any help with the scipy package. Also I suggest you report it to upstream directly so that they can fix it there as well. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500660: [Pkg-scicomp-devel] Bug#500660: Bug#500660: liblapack-doc: failed to upgrade when libblas-doc is installed
On Tue, Sep 30, 2008 at 11:19 PM, Sylvestre Ledru [EMAIL PROTECTED] wrote: (Reading database ... 169935 files and directories currently installed.) Preparing to replace liblapack-doc 3.1.1-3 (using .../liblapack-doc_3.1.1-4_all.deb) ... Unpacking replacement liblapack-doc ... dpkg: error processing /var/cache/apt/archives/liblapack-doc_3.1.1-4_all.deb (--unpack): trying to overwrite `/usr/share/man/man3/xerbla.3.gz', which is also in package libblas-doc Interesting bug. By default, blas official tarball doesn't have any manpage. They have been included in our .orig.tar.gz lapack blas have some common functions. For example, the routine xerbla (which is causing your issue here). There is only cosmetic changes here. Any way, only 2 manpages seems to be duplicate with blas: lsame.f xerbla.f I am going to try to rename lsame to lsame-lapack xerbla to xerbla-lapack to see how it goes. Thanks for looking into this Sylvestre. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499613: misnamed symlink in python-numpy
Hi Sergio! On Mon, Sep 22, 2008 at 12:07 PM, Sergio Gelato [EMAIL PROTECTED] wrote: On Sat, Sep 20, 2008 at 4:09 PM, Sergio Gelato [EMAIL PROTECTED] wrote: usr/share/pyshared/numpy/numarray/numpy/cfunc.h usr/share/pyshared/numpy/core/include/numpy/numpy/cfunc.h Oops. Right problem, wrong fix. Should be usr/share/pyshared/numpy/numarray/numpy/cfunc.h usr/share/pyshared/numpy/core/include/numpy/cfunc.h (i.e., drop one of the two consecutive numpy/ on the right-hand side). This time I've had the time to test the change and verify that my dependent package now finds the cfunc.h header. Thanks for the spot, I corrected that. Do you think you could please test it? Also, if you could register at alioth and send us your login, so that you can edit things in our svn yourself, it'd be great, so that the next time you can make the correct fix right from the beginning. Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499613: misnamed symlink in python-numpy
On Sat, Sep 20, 2008 at 4:09 PM, Sergio Gelato [EMAIL PROTECTED] wrote: Package: python-numpy Version: 1:1.1.1-1 The bug is also present in earlier versions (including Ubuntu's 1:1.0.4-6ubuntu3 where I originally noticed it). In debian/python-numpy.links, the line usr/share/pyshared/numpy/numarray/numpy/cfunc.h usr/share/pyshared/numpy/core/include/numpy/numpycfunc.h is missing a /; it should read usr/share/pyshared/numpy/numarray/numpy/cfunc.h usr/share/pyshared/numpy/core/include/numpy/numpy/cfunc.h As a consequence, C code that includes numpy/libnumarray.h fails to compile. (That header has an #include cfunc.h.) Thanks for the bug report and a solution. I've committed the change to the DPMT svn repo, now someone needs to test the package and upload, unfortunately I am too busy now to do that. Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497786: import of numpy fails for python2.5
On Fri, Sep 5, 2008 at 2:29 AM, tony mancill [EMAIL PROTECTED] wrote: Ondrej Certik wrote: On Fri, Sep 5, 2008 at 12:12 AM, tony mancill [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI, I'm able to reproduce this bug on 3 separate systems i386: On a lenny system that was installed from a jigdo DVD created on 7/21 that has been updated daily, on a lenny system that was freshly installed today (using the 9/1 jigdo DVD), and on my sid system. Things were working fine with numpy on the 7/21 install and on my unstable system until very recently, so I'm trying to track it back to what might have changed. Please let me know what additional information I can provide. I'm kind of new to numpy, but am motivated since I can't continue my research until I get it working again. Thanks for the additional information. Try to remove python-numpy and install it again. If it doesn't work, please send the the info I asked for here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497786#10 Just try to figure out where the problem is, we'll then figure out how to fix it. Ondrej Thank you for taking a look at it. I think, not surprisingly, I'm unable to reproduce the problem with numpy alone, but the output is attached. It is being used as part of python-matplotlib in my application, so I will try to narrow it down to the smallest example possible. Regards, Tony Script started on Thu 04 Sep 2008 05:22:25 PM PDT $ python2.5 -c import numpy $ dpkg -L python-numpy ^^^ So where is the problem? numpy seems to import fine for you. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497786: python-numpy: import numpy fails for python 2.5
On Thu, Sep 4, 2008 at 11:42 AM, Juha Jäykkä [EMAIL PROTECTED] wrote: Package: python-numpy Version: 1:1.1.0-3 Severity: grave Justification: renders package unusable Python-numpy seems to be unusable for python 2.5 in lenny. This is a fresh upgrade from etch, just aptitude install python-numpy after the upgrade. [EMAIL PROTECTED] 11:21:57 ~ python2.5 -c 'import numpy' Traceback (most recent call last): File string, line 1, in module ImportError: No module named numpy [EMAIL PROTECTED] 11:22:22 ~ python2.4 -c 'import numpy' [EMAIL PROTECTED] 11:22:25 ~ reportbug python-numpy Indeed, that would be a serious problem. However, I cannot reproduce it: $ python2.5 -c import numpy $ could you please create somewhere an environment, or something, so that we can reproduce it? Could you for example reinstall python+python-numpy? Also send the output of: $ dpkg -L python-numpy and $ python -c import sys;print sys.path Thanks, Ondrej
Bug#497786: python-numpy: import numpy fails for python 2.5
Thanks for the update, Juha. Now, I just took some time and did the following: 1. Use debootstrap to make a Lenny chroot with python-numpy. I chrooted and ran the tests, and discovered that all tests ran successfully. This is with the Lenny version. 2. Repeated the same process with a 32-bit chroot. All tests run fine again. So, Ondrej, I guess we really can't trace the bug again unless someone else encounters it. So, in the mean while, I would request you to consider closing this bug. Well, that's definitely the easy way and since I am very busy now, I am +1. :) But what we could (and imho should) do is to install etch chroot, install python-numpy and then upgrade to lenny. If that works, close this bug. If it doesn't work, fix it, because it is still imho a problem. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497786: python-numpy: import numpy fails for python 2.5
On Thu, Sep 4, 2008 at 9:42 PM, Kumar Appaiah [EMAIL PROTECTED] wrote: On Thu, Sep 04, 2008 at 10:16:43PM +0300, Juha Jäykkä wrote: Oh! I neglected to be specific: numpy was installed *after* the upgrade to lenny. It really looks like numpy != lenny's current version creates some symlink, directory or file, which is required and which is not deleted on up- or downgrade. So, I went and purged numpy: still cannot reproduce it any more. Please tell me if I can do anything else to help spot the bug. Otherwise, I think it would be best to close this bug and reopen it the next time you spot it. I think this is ok. I can always work around it now that I know how and if it is very limited in scope, it's better to reopen when its scope increases. Well, I am closing this bug. But please do reopen the bug the moment ou spot it again, so that we can work on preventing others from facing the problem you faced. Thanks a lot for the report and updates! Thanks Kumar for handling it! Ondrej
Bug#497786: import of numpy fails for python2.5
On Fri, Sep 5, 2008 at 12:12 AM, tony mancill [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI, I'm able to reproduce this bug on 3 separate systems i386: On a lenny system that was installed from a jigdo DVD created on 7/21 that has been updated daily, on a lenny system that was freshly installed today (using the 9/1 jigdo DVD), and on my sid system. Things were working fine with numpy on the 7/21 install and on my unstable system until very recently, so I'm trying to track it back to what might have changed. Please let me know what additional information I can provide. I'm kind of new to numpy, but am motivated since I can't continue my research until I get it working again. Thanks for the additional information. Try to remove python-numpy and install it again. If it doesn't work, please send the the info I asked for here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497786#10 Just try to figure out where the problem is, we'll then figure out how to fix it. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494031: Non-deterministic build failures
Hi Jurij! On Sat, Aug 30, 2008 at 8:17 AM, Jurij Smakov [EMAIL PROTECTED] wrote: Hi, I've now tried to build paraview 5 times with the proposed patch on sparc. 2 times package build succeeded, 3 other times it failed with different errors in different places. At this point I have no idea what makes the build non-deterministic. I don't think it's hardware issue, because I did not see any problems while building other packages. First, thanks very much for figuring out the patch. I myself am finishing my thesis now, so I cannot get to it in the next couple days. Could anyone try it too please? I hope it's a hardware failure. So maybe let's apply the patch, upload and see? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496796: [paraview] Saving an animation to .avi fails
Package: paraview Version: 3.2.3-2 Severity: normal --- Please enter the report below this line. --- When I create several .vtk files, paraview allows them to load at once and then one can click the play button and it shows the animation. This works fine. However, when doing save animation and then to avi, paraview shows a console with this error: Codec not found. ERROR: In /scratch/debian/build-area/paraview-3.2.3/VTK/IO/vtkFFMPEGWriter.cxx, line 451 vtkFFMPEGWriter (0x97460f0): Error initializing video stream. How can I make paraview to save the animation at least in some codec in Debian sid? Ondrej --- System information. --- Architecture: i386 Kernel: Linux 2.6.26-1-686 Debian Release: lenny/sid 500 unstableftp.cz.debian.org --- Package information. --- Depends (Version) | Installed ===-+-== libavcodec51 (= 0.svn20080206-8) | 0.svn20080206-12 OR libavcodec-unstripped-51 (= 0.svn20080206-8) | libavformat52 (= 0.svn20080206-8) | 0.svn20080206-12 OR libavformat-unstripped-52 (= 0.svn20080206-8) | libavutil49 (= 0.svn20080206-8) | 0.svn20080206-12 OR libavutil-unstripped-49(= 0.svn20080206-8) | libc6(= 2.7-1) | 2.7-13 libgcc1(= 1:4.1.1) | 1:4.3.1-9 libgl1-mesa-glx | 7.0.3-5 OR libgl1 | libglu1-mesa| 7.0.3-5 OR libglu1 | libice6(= 1:1.0.0) | 2:1.0.4-1 libopenmpi1 | 1.2.7~rc2-1 libqt4-assistant (= 4.4.0) | 4.4.0-4 libqt4-network (= 4.4.0) | 4.4.0-4 libqt4-xml (= 4.4.0) | 4.4.0-4 libqtcore4 (= 4.4.0) | 4.4.0-4 libqtgui4(= 4.4.0) | 4.4.0-4 libreadline5 (= 5.2) | 5.2-3 libsm6 | 2:1.0.3-2 libstdc++6 (= 4.2.1) | 4.3.1-9 libx11-6| 2:1.1.4-2 libxext6| 2:1.0.4-1 libxt6 | 1:1.0.5-3 python2.5 (= 2.5) | 2.5.2-11 xlibmesa-gl | OR libgl1 | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494031: [Pkg-scicomp-devel] Bug#494031: Bug#494031: Bug#494031: paraview_3.2.3-2(sparc/unstable): FTBFS on sparc, bus error
On Mon, Aug 18, 2008 at 7:55 PM, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, the problem on sparc is this: (sid)[EMAIL PROTECTED]:~/paraview-3.2.2/obj-sparc-linux-gnu/bin$ ./H5detect /* Generated automatically by H5detect -- do not edit */ [...] Bus error (sid)[EMAIL PROTECTED]:~/paraview-3.2.2/obj-sparc-linux-gnu/bin$ So this should not happen. Now we need to debug this program to figure out what went wrong. Ok, here is how to reproduce it on sparc with upstream hdf5-1.8.1: $ wget ftp://ftp.hdfgroup.org/HDF5/current/src/hdf5-1.8.1.tar.gz $ tar xzf hdf5-1.8.1.tar.gz $ cd hdf5-1.8.1 $ ./configure $ make [wait a while, then it compiles H5detect and calls it and it fails] $ cd src $ ./H5detect [...] Bus error So the problem is just getting hdf5 run on sparc. Looking at the Debian package hdf5, it does't have any sparc specific patches. Looking at the sparc buildlog for the hdf5 package, the H5detect works just fine in it (search for it): http://buildd.debian.org/fetch.cgi?pkg=hdf5;ver=1.6.6-4;arch=sparc;stamp=1207153381 So we just need to use this (older) hdf5 in Debian from paraview and it would solve all problems, because we will leave the portability of hdf5 to the hdf5 guys. :) Any volunteers to try to compile paraview with Debian hdf5, instead of the one in Utilities/hdf5? That would help a lot, since I am very busy with my thesis now. Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494031: [Pkg-scicomp-devel] Bug#494031: Bug#494031: Bug#494031: paraview_3.2.3-2(sparc/unstable): FTBFS on sparc, bus error
Ok, here is how to reproduce it on sparc with upstream hdf5-1.8.1: $ wget ftp://ftp.hdfgroup.org/HDF5/current/src/hdf5-1.8.1.tar.gz $ tar xzf hdf5-1.8.1.tar.gz $ cd hdf5-1.8.1 $ ./configure $ make [wait a while, then it compiles H5detect and calls it and it fails] $ cd src $ ./H5detect [...] Bus error So the problem is just getting hdf5 run on sparc. Looking at the Debian package hdf5, it does't have any sparc specific patches. I just confirmed, that taking the source package of hdf5 in Debian and doing: $ ./configure $ make $ cd src $ ./H5detect will not break, it works nicely. So we just need to take those sources and be done with it. Any volunteers? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496648: [git-core] git svn fetch fails: libexpat.so.0: cannot open shared object file: No such file or directory
Package: git-core Version: 1:1.5.6.5-1 Severity: important --- Please enter the report below this line. --- Hi, this is what I am getting: $ git svn fetch svnserve: error while loading shared libraries: libexpat.so.0: cannot open shared object file: No such file or directory Network connection closed unexpectedly: Connection closed unexpectedly at /usr/bin/git-svn line 1385 any ideas how to fix this? libexpat.so.0 doesn't seem to be in Debian anymore, I only have: $ ls /usr/lib/libexpat.so* /usr/lib/libexpat.so /usr/lib/libexpat.so.1 /usr/lib/libexpat.so.1.5.2 [EMAIL PROTECTED]:~$ ls -l /usr/lib/libexpat.so* lrwxrwxrwx 1 root root 17 2008-06-12 12:20 /usr/lib/libexpat.so - libexpat.so.1.5.2 lrwxrwxrwx 1 root root 17 2008-06-12 12:20 /usr/lib/libexpat.so.1 - libexpat.so.1.5.2 -rw-r--r-- 1 root root 151468 2008-06-09 20:52 /usr/lib/libexpat.so.1.5.2 Ondrej --- System information. --- Architecture: i386 Kernel: Linux 2.6.26-1-686 Debian Release: lenny/sid 500 unstableftp.cz.debian.org --- Package information. --- Depends (Version) | Installed =-+-== libc6 (= 2.7-1) | 2.7-13 libcurl3-gnutls (= 7.16.2-1) | 7.18.2-7 libexpat1 (= 1.95.8) | 2.0.1-4 zlib1g (= 1:1.2.0) | 1:1.2.3.3.dfsg-12 perl-modules | 5.10.0-13 liberror-perl | 0.17-1 libdigest-sha1-perl | 2.11-2+b1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494031: Signal handlers not working?
Hi Jurij!
On Tue, Aug 26, 2008 at 10:50 PM, Jurij Smakov [EMAIL PROTECTED] wrote:
Hi,
I dug a little bit into the code and it seems that the problem is
caused by this macro defined in Utilities/hdf5/H5detect.c:
#if defined(H5_HAVE_LONGJMP) defined(H5_HAVE_SIGNAL)
#define ALIGNMENT(TYPE,INFO) { \
char*volatile _buf=NULL; \
volatile TYPE _val=1; \
volatile TYPE _val2; \
volatile size_t _ano=0; \
void(*_handler)(int) = signal(SIGBUS, sigbus_handler);\
void(*_handler2)(int) = signal(SIGSEGV, sigsegv_handler); \
\
_buf = (char*)malloc(sizeof(TYPE)+align_g[NELMTS(align_g)-1]); \
if (setjmp(jbuf_g)) _ano++; \
if (_anoNELMTS(align_g)) { \
*((TYPE*)(_buf+align_g[_ano])) = _val; /*possible SIGBUS or SEGSEGV*/ \
_val2 = *((TYPE*)(_buf+align_g[_ano])); /*possible SIGBUS or SEGSEGV*/ \
[...]
It tries to set the signal handlers for SIGBUS and SIGSEGV and then
try various casts in an attempt to detect the alignment requirements.
So, SIGBUS/SIGSEGV appears to be intentional, except that they are
supposed to be caught by signal handlers, and not terminate the build.
The signal(2) man page includes the following information:
The only portable use of signal() is to set a signal's disposition to
SIG_DFL or
SIG_IGN. The semantics when using signal() to establish a signal
handler vary
across systems (and POSIX.1 explicitly permits this variation); do not
use it
for this purpose.
Current theory is that setting signal handlers via signal() does not
work in Debian for some reason. I'll try to rewrite this code using
sigaction interface to see if it helps.
This is awesome, thanks for the work you are doing!
Let us know how it went.
Ondrej
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452268: Bug#451791: xserver-xorg-video-intel: Fonts and many other items fail to render legibly
On Sun, Aug 24, 2008 at 8:48 PM, Julien Cristau [EMAIL PROTECTED] wrote: Hi, you all reported font corruption in X using the intel driver with EXA acceleration enabled, on i965 chipsets. Are you using a framebuffer kernel driver? If /proc/fb is non-empty, please send its contents to the bug you reported. If it's empty, please report that also :) It is empty in my case. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468372: confirmed
This is really an annoying problem. Any ideas how to fix it? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468372: confirmed
On Sun, Aug 24, 2008 at 11:47 PM, Ondrej Certik [EMAIL PROTECTED] wrote: This is really an annoying problem. Any ideas how to fix it? Ah, when using xterm, which has a black background, it works. Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495822: [Pkg-scicomp-devel] Bug#495822: paraview: Needs specific version of ffmpeg
On Thu, Aug 21, 2008 at 3:15 PM, Tom Parker [EMAIL PROTECTED] wrote: 2008/8/20 Ondrej Certik [EMAIL PROTECTED]: Could you please tell us which version of ffmpeg do you have? I just built paraview in Debian couple days ago and cannot reproduce this. The Ubuntu package appears to be an CVS snapshot from 20060823 (probably very similar to the same dated version in etch). More bizarrely, I've been looking at ffmpeg SVN for the relevant header (http://svn.mplayerhq.hu/ffmpeg/trunk/libavformat/avio.h?view=annotate) and it looks like it's had that function signature from the beginning! I did also find another bug report upstream to paraview (http://www.paraview.org/pipermail/paraview/2008-July/008852.html) which seems to indicate that there are other people having issues with this (and that was on a Debian Etch machine). Thanks for the info. Is there something we can do with this in Debian unstable? I understand that there are problems in other systems, but unless we can reproduce it in Debian sid, we cannot help much. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457075: Status of Salomé packaging
On Thu, Aug 21, 2008 at 2:02 PM, Adam C Powell IV [EMAIL PROTECTED] wrote: On Thu, 2008-08-21 at 13:19 +0200, Jordi Mallach wrote: Hi Adam rest of list, I've been checking the archives for progress on Salomé's ITP, which seemed quite promising back in March. However, after the success with the OpenCASCADE effort, I see no more references to Salomé. Is the ITP stalled for some licensing reason, or do the compile problems still apply and have not been resolved yet? I have resolved the compile problems, but at runtime, none of the modules load. (As noted in this bug, you can get the latest at http://lyre.mit.edu/~powell/salome/ .) I've solved this problem before, and could solve it again. But upstream practices are really frustrating me. They released a new binary 3.2.9 Salomé-MECA back in -- forgot, March? -- but with no source code. So any new effort I make is already obsolete. Furthermore, they have never released the source of the MECA extensions, even though this is supposed to be an open source project. To add insult to injury, they have *never* replied to ANY of my emails or website inquiries. (I even took the time to write to specific developers in French, but with no reply.) I have put a *TON* of effort into this, on the order of 100 hours, as you can see from the nearly 50 patches, and really feel blown off and disrespected by upstream. At some point I'll give up on upstream and go ahead and fix the 3.2.6 package, essentially maintaining a Debian fork until upstream releases more source. But this is a very low priority for the above reasons. While ranting about upstream, I should thank Sylvestre Ledru for participating in the discussion with upstream, including using some of his contacts to try to move this along. I hear there will be a meeting in September to try to resolve some of these issues, and will return to packaging work if something comes out of this process. This is really frustrating. Sorry to hear that! That's why I prefer small tools, or tools that are simple in nature, so that in the worse case one can maintain it alone if upstream decides to close the source. Ondrej
Bug#495822: [Pkg-scicomp-devel] Bug#495822: paraview: Needs specific version of ffmpeg
On Thu, Aug 21, 2008 at 5:27 PM, Tom Parker [EMAIL PROTECTED] wrote: 2008/8/21 Ondrej Certik [EMAIL PROTECTED]: Thanks for the info. Is there something we can do with this in Debian unstable? I understand that there are problems in other systems, but unless we can reproduce it in Debian sid, we cannot help much. Tried doing this on a Debian machine (mix of various stable/testing/unstable) and couldn't initially reproduce it. However, I've manage to notice that the particular data structure being used is actually an FFMPEG one, and that this data structure format gets changed at http://svn.mplayerhq.hu/ffmpeg/trunk/libavformat/avformat.h?view=diffr1=11070r2=11071 which is on 2007-11-21 and this allowed me to narrow things down. Specifically, paraview will FTBFS on versions of libavformat-dev before that (e.g. the 0.cvs20060823-8 in etch and the version I had earlier in Ubuntu) but should be ok (certainly won't fail in this way) with later versions. This isn't critical for Debian testing or unstable systems, but something noting this would be of use to backporters like myself. Great job! Should we add a dependency =0.cvs20060823-8 then? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495822: [Pkg-scicomp-devel] Bug#495822: paraview: Needs specific version of ffmpeg
On Thu, Aug 21, 2008 at 5:51 PM, Tom Parker [EMAIL PROTECTED] wrote: 2008/8/21 Ondrej Certik [EMAIL PROTECTED]: Great job! Should we add a dependency =0.cvs20060823-8 then? Pretty much, although that will need to be a not a = (as 0.cvs20060823-8 will bork). Also, as http://snapshot.debian.net/package/libavformat-dev indicates that there was released versions of libavformat-dev up to 0.cvs20071007-4 that will probably still fail, that's probably the version you want to do a on (or a = on 0.svn20080206-1 as that's apparently the first released version that should work) Thanks, I just committed the following patch to our svn. The bug will be fixed when we upload the next revision. $ svn di Index: debian/control === --- debian/control (revision 3858) +++ debian/control (working copy) @@ -3,7 +3,7 @@ Priority: extra Maintainer: Debian Scientific Computing Team [EMAIL PROTECTED] Uploaders: Christophe Prud'homme [EMAIL PROTECTED], Ondrej Certik [EMAIL PROTECTED] -Build-Depends: cdbs (= 0.4.51), debhelper (= 5), autotools-dev, quilt (= 0.46-4), cmake (= 2.4.8), libqt4-dev (= 4.3.3-2), libopenmpi-dev, ffmpeg, libavformat-dev, libavutil-dev, libavcodec-dev, python-dev, chrpath, libglu1-mesa-dev, libxt-dev, libxext-dev, doxygen, graphviz, gnuplot +Build-Depends: cdbs (= 0.4.51), debhelper (= 5), autotools-dev, quilt (= 0.46-4), cmake (= 2.4.8), libqt4-dev (= 4.3.3-2), libopenmpi-dev, ffmpeg, libavformat-dev (= 0.svn20080206-1), libavutil-dev, libavcodec-dev, python-dev, chrpath, libglu1-mesa-dev, libxt-dev, libxext-dev, doxygen, graphviz, gnuplot Standards-Version: 3.8.0 XS-DM-Upload-Allowed: yes Homepage: http://www.paraview.org/ Index: debian/changelog === --- debian/changelog(revision 3858) +++ debian/changelog(working copy) @@ -1,3 +1,10 @@ +paraview (3.2.3-3) UNRELEASED; urgency=low + + [ Ondrej Certik ] + * Build-Depend on libavformat-dev (= 0.svn20080206-1). (Closes: #495822) + + -- Ondrej Certik [EMAIL PROTECTED] Thu, 21 Aug 2008 20:06:22 +0200 + paraview (3.2.3-2) unstable; urgency=low [Christophe Prud'homme] Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495822: [Pkg-scicomp-devel] Bug#495822: paraview: Needs specific version of ffmpeg
On Thu, Aug 21, 2008 at 5:36 PM, Tom Parker [EMAIL PROTECTED] wrote: 2008/8/21 Tom Parker [EMAIL PROTECTED]: Specifically, paraview will FTBFS on versions of libavformat-dev before that (e.g. the 0.cvs20060823-8 in etch and the version I had earlier in Ubuntu) but should be ok (certainly won't fail in this way) with later versions. Oh, and I've reported this to upstream at http://www.vtk.org/Bug/view.php?id=7522 Nice catch! Please report all similar bugs if you encounter in the future. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495822: [Pkg-scicomp-devel] Bug#495822: paraview: Needs specific version of ffmpeg
On Wed, Aug 20, 2008 at 7:35 PM, Tom Parker [EMAIL PROTECTED] wrote: Package: paraview Version: 3.2.3-2 Severity: important Justification: fails to build from source Fragment from my buildlog [ 16%] Building CXX object VTK/IO/CMakeFiles/vtkIO.dir/vtkFFMPEGWriter.o /data/tparker/builder/sources/paraview_3.2.3-2/VTK/IO/vtkFFMPEGWriter.cxx: In member function 'void vtkFFMPEGWriterInternal::End()': /data/tparker/builder/sources/paraview_3.2.3-2/VTK/IO/vtkFFMPEGWriter.cxx:339: error: cannot convert 'ByteIOContext' to 'ByteIOContext*' for argument '1' to 'int url_fclose(ByteIOContext*)' make[3]: *** [VTK/IO/CMakeFiles/vtkIO.dir/vtkFFMPEGWriter.o] Error 1 Admittedly this is with version 3:0.cvs20060823-3.1ubuntu4+medibuntu2 attempting to be built on a Ubuntu system, but given ffmpeg's tendancy to break API on a moments notice, I'd bet on paraview having a tighter dependancy on ffmpeg than the current unversioned dep would otherwise indicate. Actually.. url_fclose turns out to be part of libavformat-dev, but the same notes apply as it's a subpart of ffmpeg and paraview has an unversioned dep on it right now. Could you please tell us which version of ffmpeg do you have? I just built paraview in Debian couple days ago and cannot reproduce this. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495457: python-numpy: Error while loading a library
On Sun, Aug 17, 2008 at 6:13 PM, Christophe Combelles [EMAIL PROTECTED] wrote: This is actually fixed in numpy 1.1.1, and the diff is attached. I just uploaded the new numpy 1.1.1, let me know if this is fixed and if it is ok to close this issue. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494031: [Pkg-scicomp-devel] Bug#494031: Bug#494031: paraview_3.2.3-2(sparc/unstable): FTBFS on sparc, bus error
Hi, the problem on sparc is this: (sid)[EMAIL PROTECTED]:~/paraview-3.2.2/obj-sparc-linux-gnu/bin$ ./H5detect /* Generated automatically by H5detect -- do not edit */ /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Copyright by the Board of Trustees of the University of Illinois. * * All rights reserved. * * * * This file is part of HDF5. The full HDF5 copyright notice, including * * terms governing use, modification, and redistribution, is contained in* * the files COPYING and Copyright.html. COPYING can be found at the root * * of the source code distribution tree; Copyright.html can be found at the * * root level of an installed copy of the electronic HDF5 document set and * * is linked from the top-level documents page. It can also be found at * * http://hdf.ncsa.uiuc.edu/HDF5/doc/Copyright.html. If you do not have * * access to either file, you may request a copy from [EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Created: Aug 18, 2008 * Ondrej Certik [EMAIL PROTECTED] * * Purpose: This machine-generated source code contains * information about the various integer and * floating point numeric formats found on this * architecture. The parameters below should be * checked carefully and errors reported to the * HDF5 maintainer. * * Each of the numeric formats listed below are * printed from most significant bit to least * significant bit even though the actual bytes * might be stored in a different order in * memory. The integers above each binary byte * indicate the relative order of the bytes in * memory; little-endian machines have * decreasing numbers while big-endian machines * have increasing numbers. * * The fields of the numbers are printed as * letters with `S' for the mantissa sign bit, * `M' for the mantissa magnitude, and `E' for * the exponent. The exponent has an associated * bias which can be subtracted to find the * true exponent. The radix point is assumed * to be before the first `M' bit. Any bit * of a floating-point value not falling into one * of these categories is printed as a question * mark. Bits of integer types are printed as * `I' for 2's complement and `U' for magnitude. * * If the most significant bit of the normalized * mantissa (always a `1' except for `0.0') is * not stored then an `implicit=yes' appears * under the field description. In thie case, * the radix point is still assumed to be * before the first `M' but after the implicit * bit. * * Modifications: * * DO NOT MAKE MODIFICATIONS TO THIS FILE! * It was generated by code in `H5detect.c'. * *- */ Bus error (sid)[EMAIL PROTECTED]:~/paraview-3.2.2/obj-sparc-linux-gnu/bin$ So this should not happen. Now we need to debug this program to figure out what went wrong. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495426: [Pkg-scicomp-devel] Bug#495426: paraview: Please used packaged vtk
On Sun, Aug 17, 2008 at 2:31 PM, Christophe Prud'homme [EMAIL PROTECTED] wrote: Thomas, Thank you for your input, On Sun, Aug 17, 2008 at 11:44 AM, Thomas Weber [EMAIL PROTECTED] wrote: Package: paraview Version: 3.2.2-1 Severity: wishlist Hi, I just removed vtk and was surprsied that paraview wasn't removed by dependencies. It seems paraview uses its own internal copy of VTK. Any chance of using the packaged vtk package instead? I don't think so no Both, paraview and vtk are developed by kitware. They ship their own version of vtk with paraview to ensure compatibility and avoid nightmares when developing both software. Sorry for the inconvenience Yes, as Christophe said, unfortunately even Kitware ships their own vtk with paraview, so unless there is enough manpower in Debian to maintain paraview with our vtk version, it won't happen, becuase neither me or Christophe has time for this. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495457: python-numpy: Error while loading a library
On Sun, Aug 17, 2008 at 5:07 PM, Christophe Combelles [EMAIL PROTECTED] wrote:
Package: python-numpy
Version: 1:1.1.0-3
Severity: normal
I get an error while trying to 'import svm'.
libsvm is installed from source:
http://scipy.org/svn/scikits/trunk/scikits/learn/scikits/learn/machine/svm/
import svm
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.5/site-packages/svm/__init__.py, line 62, in module
from classification import *
File /usr/lib/python2.5/site-packages/svm/classification.py, line 5, in
module
from model import Model
File /usr/lib/python2.5/site-packages/svm/model.py, line 3, in module
from dataset import PrecomputedDataSet
File /usr/lib/python2.5/site-packages/svm/dataset.py, line 3, in module
import libsvm
File /usr/lib/python2.5/site-packages/svm/libsvm.py, line 15, in module
_libsvm = N.ctypeslib.load_library('libsvm_%s' % so_ext, __file__)
File /usr/lib/python2.5/site-packages/numpy/ctypeslib.py, line 48, in
load_library
for ln in libname_ext:
UnboundLocalError: local variable 'libname_ext' referenced before assignment
In numpy/ctypeslib.py, libname_ext is defined in a within a 'if' statement:
if '.' not in libname
If the condition is not satisfied, libname_ext is not defined although it is
used on line 48, thus leading to the error.
In my case, the name of the lib is 'libsvm_.so'.
Thanks for the bug report. Could you please report it to the upstream
mailinglist? This seems like something they should fix in numpy.
Alternatively, you can also send a patch to python-numpy package in
Debian fixing this problem and I'll reupload. But send the patch to
upstream anyway please.
Ondrej
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494348: [epiphany-browser] edit-personal data-Passwords - crash
On Fri, Aug 15, 2008 at 4:21 PM, Sam Morris [EMAIL PROTECTED] wrote: tag 494348 + moreinfo thanks Please can you provide the stack trace gathered by bug-buddy when Epiphany crashes? You will need to install gnome-dbg and xulrunner-1.9-dbg and epiphany-browser-dbg for this data to be useful. Unfortunately, I cannot reproduce this bug anymore. Yes, I know that my bug report is useless without a stack trace. But I just wanted to report it anyways, because these segfaults are a reason why I switched back to iceweasel. It's rock stable, hasn't crashed not even once for a week. Epiphany was crashing several times a day. Feel free to close it, sorry I wasn't more helpful. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494348: [epiphany-browser] edit-personal data-Passwords - crash
On Fri, Aug 15, 2008 at 5:48 PM, Sam Morris [EMAIL PROTECTED] wrote: On Fri, 2008-08-15 at 17:38 +0200, Ondrej Certik wrote: Please can you provide the stack trace gathered by bug-buddy when Epiphany crashes? You will need to install gnome-dbg and xulrunner-1.9-dbg and epiphany-browser-dbg for this data to be useful. Unfortunately, I cannot reproduce this bug anymore. Yes, I know that my bug report is useless without a stack trace. But I just wanted to report it anyways, because these segfaults are a reason why I switched back to iceweasel. It's rock stable, hasn't crashed not even once for a week. Epiphany was crashing several times a day. That's certainly no problem, it is definately useful to know about crashes even if they don't come with backtraces. :) I too believe this bug is fixed, or at least, does not occur any more--as I used to hit crashes in the cookie/password manager quite often, but don't any more. Right. But why do you think epiphany is so unstable after so many years of development? Is it because we screwed something up in Debian (like we use some different versions of libraries that just segfault with epiphany) or is epiphany just unstable everywhere? I think production programs should not just segfault. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494348: [epiphany-browser] edit-personal data-Passwords - crash
On Fri, Aug 15, 2008 at 6:21 PM, Sam Morris [EMAIL PROTECTED] wrote: On Fri, 2008-08-15 at 18:15 +0200, Ondrej Certik wrote: On Fri, Aug 15, 2008 at 5:48 PM, Sam Morris [EMAIL PROTECTED] wrote: On Fri, 2008-08-15 at 17:38 +0200, Ondrej Certik wrote: Please can you provide the stack trace gathered by bug-buddy when Epiphany crashes? You will need to install gnome-dbg and xulrunner-1.9-dbg and epiphany-browser-dbg for this data to be useful. Unfortunately, I cannot reproduce this bug anymore. Yes, I know that my bug report is useless without a stack trace. But I just wanted to report it anyways, because these segfaults are a reason why I switched back to iceweasel. It's rock stable, hasn't crashed not even once for a week. Epiphany was crashing several times a day. That's certainly no problem, it is definately useful to know about crashes even if they don't come with backtraces. :) I too believe this bug is fixed, or at least, does not occur any more--as I used to hit crashes in the cookie/password manager quite often, but don't any more. Right. But why do you think epiphany is so unstable after so many years of development? Is it because we screwed something up in Debian (like we use some different versions of libraries that just segfault with epiphany) or is epiphany just unstable everywhere? I think production programs should not just segfault. Most of the bugs I run into seem to be tricky corner cases caused by the horrific gecko embedding API, or bugs in gecko itself. But maybe are in epiphany itself. Many more are caused by plugins (Flash or the Totem plugin). At the end of the day, the software shouldn't crash, but the developers need more manpower to identify crashes and fix them. This is even harder if the developers can't reproduce the bug because we use a different version of xulrunner than they do, or we patch it with some odd patches that they don't use, or we use a different architecture to them, etc, etc. I see. So things should improve after moving to webkit. Yes, it's true that sometimes it crashes due to my flash plugin, but this password crash seems unrelated. Ok, thanks for enlightening me the issues and I'll keep reporting bugs, preferably with a stacktrace. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494367: pyglet 1.1 packages
On Tue, Aug 12, 2008 at 8:39 AM, Carlos Laviola [EMAIL PROTECTED] wrote: severity 494367 wishlist thanks Hi guys, I updated python-pyglet to 1.1. You can see the package at: http://people.debian.org/~claviola/pyglet/ Very simple stuff, just uupdate'd based on a tarball created as if the get-orig-sources target was ran (wiping out the doc directory), though I haven't checked if the licensing on that has changed. This upload would also close #494367 and allow me to upload a memory game called Brain Workshop (http://brainworkshop.sourceforge.net) which depends on this version. Do any of you guys have the time to do it yourselves, or would it be okay for me to upload it? As to me feel free to go ahead. Only please put the patch into the DPMT, e.g. here: svn+ssh://svn.debian.org/svn/python-modules/packages/pyglet/trunk if you don't have an access (you should create yourself one), send me the patch and I'll apply it. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
