Bug#749567: gkrellm: Crashes with 'BadRRCrtc (invalid Crtc parameter)' X Window System error
Control: severity -1 normal Control: retitle -1 gkrellm: Crashes under ssh -Y with 'BadRRCrtc (invalid Crtc parameter)' X Window System error -=| Wolfgang Denk, 28.05.2014 08:34:42 +0200 |=- Package: gkrellm Version: 2.3.5-6 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Just trying to run gkrellm ... * What exactly did you do (or not do) that was effective (or ineffective)? This is a headless system (serial console only) so I log in using ssh -Y Then I try to run gkrellm. gkrellm works just fine when run locally. Bug retitled and severity adjusted. gkrellm updates its window many times per second, so running it via ssh -X is not such a good idea anyway. I'd run the gkrellmd on the headless system and then use 'gkrellm -s $host' on the desktop. -- dam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751459: vprerex: please allow alternatives to xterm
Source: vprerex Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 vprerex depends on xterm. Please, if possible for that package to work with other terminal emulators, add fallback on those those - or preferrably on the virtual x-terminal-emulator. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJTmqA7XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWSQgIALeGpqzW5fqTRUtUap5tiXn3 DdL9JxHAps5hv++evgniHdM/b0vwN+gRD++cqM5aZO1EDnWHts4AJo2Z0CvqpWcw WvNw3eNZOF2lwCOe+pjZnBc0maOFMdtJVJS6029OlRBkppQLDGsCBr/jCCi5TMXV 7/G4v3cJHukKssiPh3fejDKfJoG8gwDQHBmDAvE5sSmot/2K8DnQhHpHPrdLe2qO 4FTpkwqBkVrTIalSPXYo45zrLEDDfAcPcjve3iBIsdof4QiZ4sb8c0fdqLvQ5M2o I2xkj5gV7qToThQCZCSO/WkBveujzj5p7TcIg+mXqlGE3QUV0r2qQUMotSN/aJM= =o3ig -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#748766: scheme48: Insecure use of temporary file for communication.
Hi CVE-2014-4150 was assigned for this issue. Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747031: fixed in python-debian 0.1.22
Hi Stuart, On Wed, Jun 11, 2014 at 10:12:21PM +1000, Stuart Prescott wrote: Hi John, * python_support: Avoid hashlib dependency, using the built-in _sha or _sha1 module (depending on Python version) instead. That way we don't link in OpenSSL, which has an incompatible license. (Closes: 747031) We should be careful that this particular change is not backwards compatible with wheezy's python: $ PYTHONPATH=. python -c 'import debian.debian_support; debian.debian_support.new_sha1()' Traceback (most recent call last): File string, line 1, in module File debian/debian_support.py, line 50, in new_sha1 Built-in sha1 implementation not found; cannot use hashlib NotImplementedError: Built-in sha1 implementation not found; cannot use hashlib implementation because it depends on OpenSSL, which may not be linked with this library due to license incompatibilities (the test suite does fail which would alert a backporter) Fiddling around with an internal interface like _sha feels quite wrong too. I think it's likely to bring pain back to us in the future. For what it's worth, I don't particularly like this solution either. I couldn't find a better one (at least not a tecnhical one - see below). I'm quite unconvinced by the argument that a GPL'd script can't import hashlib; I think GPLv3 is quite clear that hashlib is a Standard Interface of the Python programming language and that making use of it is fine; the language is less precise for GPLv2 but I still don't think there's a problem there. There are plenty of other GPL'd things in Debian that import hashlib and I don't think anyone's interested in working on this. I actually am convinced by the debian-legal argument that the exception doesn't apply for Debian (because Debian distributes both OpenSSL and python-debian), but the alternative to this hacky crap is to modify our own license to allow linking with OpenSSL. Which honestly is probably not too hard since there were only a handful of contributors to python_support.py. I've taken this particular issue out of the too-hard-basket and put it back in several times already... thanks for taking a crack at it. No problem. Feel free to revert the change if it's causing problems. -- John Wright j...@debian.org signature.asc Description: Digital signature
Bug#750281: aster: FTBFS: No rule to make target 'clean'
Control: tags -1 +patch Patch committed at: http://anonscm.debian.org/gitweb/?p=debian-science/packages/aster.git;a=commitdiff;h=7be3b564181d8635fa1d8a4975a4341a3b40f1f4 -- Denis Laxalde Logilab http://www.logilab.fr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751460: ecdsa/util.py throws ImportException, cannot find next in python-six
Source: python-ecdsa Version: 0.11-1 Severity: important I use duplicity, which uses python-paramiko, which uses python-ecdsa since version 1.14.0-1. After upgrading to testing yesterday, duplicity does not work any longer. This is the exception I get: $ /usr/bin/duplicity list-current-files $BASEPATH/root Traceback (most recent call last): File /usr/bin/duplicity, line 1495, in module with_tempdir(main) File /usr/bin/duplicity, line 1489, in with_tempdir fn() File /usr/bin/duplicity, line 1323, in main action = commandline.ProcessCommandLine(sys.argv[1:]) File /usr/lib/python2.7/dist-packages/duplicity/commandline.py, line 1027, in ProcessCommandLine globals.backend = backend.get_backend(args[0]) File /usr/lib/python2.7/dist-packages/duplicity/backend.py, line 161, in get_backend return _backends[pu.scheme](pu) File /usr/lib/python2.7/dist-packages/duplicity/backends/_ssh_paramiko.py, line 75, in __init__ import paramiko File /usr/lib/python2.7/dist-packages/paramiko/__init__.py, line 31, in module from paramiko.transport import SecurityOptions, Transport File /usr/lib/python2.7/dist-packages/paramiko/transport.py, line 55, in module from paramiko.ecdsakey import ECDSAKey File /usr/lib/python2.7/dist-packages/paramiko/ecdsakey.py, line 26, in module from ecdsa import SigningKey, VerifyingKey, der, curves File /usr/lib/python2.7/dist-packages/ecdsa/__init__.py, line 3, in module from .keys import SigningKey, VerifyingKey, BadSignatureError, BadDigestError File /usr/lib/python2.7/dist-packages/ecdsa/keys.py, line 5, in module from . import rfc6979 File /usr/lib/python2.7/dist-packages/ecdsa/rfc6979.py, line 14, in module from .util import number_to_string, number_to_string_crop File /usr/lib/python2.7/dist-packages/ecdsa/util.py, line 9, in module from six import PY3, int2byte, b, next ImportError: cannot import name next There have not been recent changes in python-six, so I’m not sure how python-ecdsa can ever have worked properly :). Downgrading to python-paramiko 1.10.1-1 fixes the issue, as that version is not using python-ecdsa at all. Can you please take a look? -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armel i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750772: Lost again
I can confirm that it takes a longer time but after about 2 hours I have lost my contacts again (as I wrote: vanilla owncloud in an upgraded debian:testing docker container) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751457: [Pkg-openssl-devel] Bug#751457: libssl-dev: SSL_OP_MSIE_SSLV2_RSA_PADDING missing from /usr/include/openssl/ssl.h which breaks building things
On Fri, Jun 13, 2014 at 12:56:15AM -0400, Tim Shepard wrote: Can this be fixed in wheezy's libssl-dev Yes, this is planned for my next upload. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742921: Test-suite for python-htseq (Was: Bug#742921: python-htseq: python.numpy dtype size error)
Hi Diane, On Thu, Jun 12, 2014 at 03:05:17PM -0700, Diane Trout wrote: I finally managed to fix this bug. Cool. python-numpy provides dh_numpy that will insert a python-numpy-abi$VERSION into the python dependencies to make it more obvious when a package needs to be recompiled for a new change in numpy's abi. Well, I was aware about dh_numpy - sorry for not having a deeper look to tell you earlier. All the fixes necessary to implement that are in debian git. http://anonscm.debian.org/gitweb/?p=debian-med/python-htseq.git Good ... Unfortunately Rather fortunately. ;-) I also figured out how to run upstream's test cases and a few of those test cases are failing. I've gone ahead and emailed upstream to ask about them. I tried to build the package and noticed that the errors look basically like rounding problems caused by different compilers / architectures and all happeningin tss.rst I would recommend asking on debian-science list for some ideas. I passed Henry a current local build of python-htseq for his testing. (We work in the same lab). Sounds good. Please also add autopkgtest to the package (once the test works). Examples are for instance in python-pysam. Thanks for your work on this Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751278: libguestfs: FTBFS on amd64, i386, and mips*
* Scott Kitterman: Source: libguestfs Version: 1:1.26.3-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Yeah, that's likely a compiler and/or linker problem. I suspect that it's related to #750947, I have added some comments there. From the build logs, the X86 and mips* issues seem to be different: I have been able to reproduce the issue on i386 and amd64, too. The golang bindings aren't built on mips*. Cheers, -Hilko -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751216: firebird: /etc/cron.daily/logrotate complains about unknown user 'firebird'
Hi, I have the same error /etc/cron.daily/logrotate: error: firebird2.5:8 unknown user 'firebird' error: found error in /var/log/firebird2.5.log , skipping Running debian/testing
Bug#751332: closed by tony mancill tmanc...@debian.org (Bug#751332: fixed in stealth 2.11.04-2)
Am 13.06.2014 06:24, schrieb Debian Bug Tracking System: This is an automatic notification regarding your Bug report which was filed against the stealth package: #751332: stealth: non-standard gcc/g++ used for build (gcc-4.8) It has been closed by tony mancill tmanc...@debian.org. * Switch explicitly depending on g++-4.8 to g++-4.9. This is only needed because sh4 still defaults to g++-4.6. (Closes: #751332) I see this repeated in many uploads, however this is wrong. sh4 defaults to 4.8 now. This will lead to a new round of bug reports ... why can't you just use the default GCC? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748490: Mongodb 2.6 upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Laszlo How about uploading 2.6.1 to experimental so the proposed upgrade can get some general testing via that route prior to bumping the version in unstable-testing? - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTmq/uAAoJEL/srsug59jDmukQAKFnm5FH1qJoagCFARzvhHMZ mDdfzo42CIi5O16WshI1uwwOyD2pRUkbFWUizi9sHfpqtPh+GMzM8T5hO44i+AFe 0O8ythCL+KJhg0wTftVMXaHBG4STrthLVAmhR+Yrccod1adJLSe+YuyOpbx//Myl Op0Rv7PdG2UArzNIV2eWkD/QOsqrp3JB2Azd16wTIVXikAFBEpbGUWFCg6lyXY/W RFyLIX1cjMUPADf03TKc9DR9sPJ084t6JuRDTzD22EDwpPlcJoLnUmNGg0pQ6qKh 8I2DsY+etdELXGwCzszm35b4CR9+Iii54ZleiQc3z02tM2/XZb+LiIkrtC24dm45 SH786HMpnCI8ZX/5TdVDJefNe/vHXMOpMxYpiL/xDzAW68kBHQQlRjhTRLL6mqs/ Ix4V9nDjdtx8rWXwl7ct06FktJ8QZyuas0kbJGo2ESuScRlJaV4ptrUMSeUSMHbx dZqdMlh7i4lNCcjkJ13Nng+c2uIxpsmcWx38NrWZfbLvQolyt6dLRszyGbIeAZuD gVVTkl92sJ3N8FzqUu3h2dU96QwKJIcigS4+fm3h/Ksmw6Q2t8QSRCKGgbYk2L9g SeAzHKPPECHrKpMmVTBIpa5OK/AGa3LAIDXeXH6ncW8vrT9DT8Y092sZ3Ukws+LK DdXLOb8nMeKyAFZ1XXpg =83gU -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#749592: libreoffice-mysql-connector: doesn't work ignoring server configuration
Hi, installing libreoffice-mysql-connector_1.0.2+LibO4.3.0~beta2-2_i386.deb on
a 4.2.4-4 suite temporary solve the problem (waiting 4.2.5 version ...).
Regards!
Guido
In data venerdì 30 maggio 2014 20:48:58, Rene Engelhard ha scritto:
Hi,
On Thu, May 29, 2014 at 02:24:27PM +0200, Rene Engelhard wrote:
-} else if (!pIter-Name.compareToAscii(LocalSocket)) {
+} else if (pIter-Name.equalsAscii(LocalSocket)) {
OSL_VERIFY( pIter-Value = sUnixSocket );
unixSocketPassed = true;
-} else if (!pIter-Name.compareToAscii(NamedPipe)) {
+} else if (pIter-Name.equalsAscii(NamedPipe)) {
OSL_VERIFY( pIter-Value = sNamedPipe );
namedPipePassed = true;
Wasn't this but the place was correct. Upstream fixed it.
(for 4.4 only for now, but that hopefully will be backported)
I backported the patch[1] and it'll be in the next upload of both the 4.2 and
4.3 branches.
Regards,
Rene
[1]
http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b50e21473e7d2b24b5c609d8a1c31f27644d842
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750703: make-kpkg fails completely to build a current kernel image
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I had again a deeper look into the typescript that I recoded for the failing build. At the very begin there is something like: test -f debian/control || sed -e 's/=V/3.13.11/g' \ -e 's/=D/1.ikki/g' -e 's/=A/amd64/g' \ -e 's/=SA//g' \ -e 's/=I//g'\ -e 's/=CV/3.13/g' \ -e 's/=M/Klaus Ethgen kl...@ethgen.de/g' \ -e 's/=ST/linux/g' -e 's/=B/x86_64/g'\ -e 's/=R/initramfs-tools | linux-initramfs-tool,/g' /usr/share/kernel-package/Control debian/control test -f debian/changelog || sed -e 's/=V/3.13.11/g' \ -e 's/=D/1.ikki/g'-e 's/=A/amd64/g' \ -e 's/=ST/linux/g' -e 's/=B/x86_64/g' \ -e 's/=M/Klaus Ethgen kl...@ethgen.de/g' \ /usr/share/kernel-package/changelog debian/changelog But then, further on I find the following: makeARCH=x86_64 prepare make[2]: Entering directory '/usr/src/linux-3.13.11' SYSHDR arch/x86/syscalls/../include/generated/uapi/asm/unistd_32.h SYSHDR arch/x86/syscalls/../include/generated/uapi/asm/unistd_64.h SYSHDR arch/x86/syscalls/../include/generated/uapi/asm/unistd_x32.h SYSTBL arch/x86/syscalls/../include/generated/asm/syscalls_32.h SYSHDR arch/x86/syscalls/../include/generated/asm/unistd_32_ia32.h SYSHDR arch/x86/syscalls/../include/generated/asm/unistd_64_x32.h SYSTBL arch/x86/syscalls/../include/generated/asm/syscalls_64.h HOSTCC arch/x86/tools/relocs_32.o HOSTCC arch/x86/tools/relocs_64.o HOSTCC arch/x86/tools/relocs_common.o HOSTLD arch/x86/tools/relocs CHK include/config/kernel.release UPD include/config/kernel.release WRAParch/x86/include/generated/asm/clkdev.h CHK include/generated/uapi/linux/version.h UPD include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h CC kernel/bounds.s GEN include/generated/bounds.h CC arch/x86/kernel/asm-offsets.s GEN include/generated/asm-offsets.h CALLscripts/checksyscalls.sh make[2]: Leaving directory '/usr/src/linux-3.13.11' echo done debian/stamp/conf/kernel-conf make[1]: Leaving directory '/usr/src/linux-3.13.11' make -f debian/rules debian/stamp/conf/full-changelog make[1]: Entering directory '/usr/src/linux-3.13.11' == making target debian/stamp/conf/full-changelog [new prereqs: ]== for file in ChangeLog Control Control.bin86 config templates.in rules; do \ cp -f /usr/share/kernel-package/$file ./debian/; \ done cp: der Aufruf von stat für »/usr/share/kernel-package/ChangeLog« ist nicht möglich: Datei oder Verzeichnis nicht gefunden for dir in Config docs examples ruleset scripts pkg po;do \ cp -af /usr/share/kernel-package/$dir ./debian/; \ done install -p -m 755 /usr/share/kernel-package/rules debian/rules sed -e 's/=V/3.13.11/g' \ -e 's/=D/1.ikki/g' -e 's/=A/amd64/g' \ -e 's/=SA//g' \ -e 's/=I//g'\ -e 's/=CV/3.13/g' \ -e 's/=M/Klaus Ethgen kl...@ethgen.de/g' \ -e 's/=ST/linux/g' -e 's/=B/x86_64/g'\ /usr/share/kernel-package/Control debian/control sed -e 's/=V/3.13.11/g' -e 's/=D/1.ikki/g'\ -e 's/=A/amd64/g' -e 's/=M/Klaus Ethgen kl...@ethgen.de/g' \ -e 's/=ST/linux/g' -e 's/=B/x86_64/g' \ /usr/share/kernel-package/changelog debian/changelog chmod 0644 debian/control debian/changelog make -f debian/rules debian/stamp/conf/kernel-conf make[2]: Entering directory '/usr/src/linux-3.13.11' make[2]: 'debian/stamp/conf/kernel-conf' is up to date. make[2]: Leaving directory '/usr/src/linux-3.13.11' make[1]: Leaving directory '/usr/src/linux-3.13.11' echo done debian/stamp/conf/minimal_debian exec debian/rules DEBIAN_REVISION=1.ikki CONFIG_TARGET=menuconfig KPKG_SELECTED_MODULES=nvidia-kernel,oss4 configure == making target debian/stamp/dummy-config-common [new prereqs: ]== As you can see, there is no replace of =R anymore. And I think that is exactly the point where the error happens. There must be more than one place in the script where control is generated. And at least one seems to miss the replacement for =R. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen
Bug#750992: position in build process not clear
Hi Michael, On Thu, Jun 12, 2014 at 09:46:46PM +0200, Michael Stapelberg wrote: dh_systemd_enable installs debian/quotarpc.service just like dh_installinit does. Are you not passing the --name flag to dh_systemd_enable? That’d explain it. The call was: dh_systemd_enable quotarpc.service So that would explain it. However, the way I read the manpage, this call should have worked. It says: dh_systemd_enable [debhelper options] [--no-enable] [unit file ...] So it talks about just using the unit file name as option. And --name is not mentioned at all, not even in man debhelper as debhelper option. Maybe you want to fix that. If you still have trouble, please provide the source package you are using so that I can have a look. I could not find a git repository for the quota packaging. Well there is one, but it's under my user account and thus not accessible by anyone else. Maybe I should move it. :) Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751461: usb ports inaccessible after boot up
Package: vmlinuz Version: 3.2.0-4-686-pae Debian Version:Debian wheezy 7.4.0, i386 Bug summary: USB ports inaccessible after boot up Related bugreport: #500552 - involves exactly the same problem (year 2008) - then solved through CPU replacement - issue archived by now Possibly related : #750445 - describes similar problem with different error code Reporter: Arie Verheul Personal status: new to Linux -- Summary of what has been found so far -- a. The system may work properly and hence the hardware seems OK. b. The issue seems not specific for Debian but rather a general kernel issue. c. Puppy Linux seems less sensitive for the issue. d. The Intel BIOS version affects the issue. e. There are indications that the problem might involve a timing issue. -- Dear sir or madam, I do experience a persistent problem with usb port setup on boot up. The system boots up OK but ends up with non-functioning usb-ports. This renders the system useless. The hardware used is new and recent (see specs below). Initially it was attempted to install Scientific Linux, which uses the Anaconda installer. However, Anaconda boots up OK but with non-functioning usb-ports. No solution was found. Installation was done from an usb stick (no optical drive present). Therefore the issue seems to be a kernel issue which is not specific for Debian. Next it was attempted to install Debian. Just like Anaconda the Debian installer boots up with inaccessible usb ports. This could be solved by repeatedly hotplugging the usb mouse. After the usb ports had become accessible Debian could be installed properly. However, once installed Debian normally always boots up with non functioning usb-ports. Error message as below: [ 20.405006] usb 1-1: device not accepting address 2, error -110 [ 20.516591] usb 1-1: new high-speed USB device number 3 using ehci_hcd [ 36.040241] usb 1-1: device not accepting address 3, error -110 [ 36.152034] usb 1-1: new high-speed USB device number 4 using ehci_hcd [ 46.562305] usb 1-1: device not accepting address 4, error -110 [ 46.674088] usb 1-1: new high-speed USB device number 5 using ehci_hcd [ 57.084282] usb 1-1: device not accepting address 5, error -110 [ 57.084425] hub 1-0:1.0: unable to enumerate USB device on port 1 Instead of usb 1-1 the system may complain about usb 3-1 with exactly the same result. To inspect the hard disk Puppy Linux 5.7.1 was installed on a usb stick. Surprisingly Puppy always booted properly, and did not seem to suffer from the usb issue. However, when the system BIOS was updated in an attempt to solve the issue (see below for version), Puppy randomly failed in about half of the cases. Returning to the previous BIOS version solved this. This was reported to Intel. From experiments it was found that Debian could be made to work with properly functioning usb-ports by simply deleting some log files from the /var/log directory (using Puppy). Deleted were kernel.log and the various dmesg files. Although the effect of this remains unclear it gives gives a 70% chance for a working system. Strange enough the reported errors remain exactly the same, even if the system ends up in a properly working state. The system has been used this way for over 2 month now with consistently the same results. The impression is that the solution found for bug #500552 was rather a workaround than a solution. The random behaviour of both Debian and Puppy (the latter with updated BIOS) could indicate a timing issue. In this respect it might be relevant that the system uses an SSD which is faster than most HDD's. The effect of deleting log files could be just a slight delay in OS loading. I therefore took notes of the time of the first reported usb error, both in cases that ended up with functioning usb ports as in cases with non functioning usb ports. -- Boot up ending with non-functioning usb-ports 20.178 20.178 20.178 20.184 20.200 20.405 Boot up ending with properly functioning usb-ports 20.465 20.477 20.508 20.544 -- These data support the timing issue hypothesis. A first error at 20.405 or earlier would result in non-functioning usb-ports, a first error at 20.465 or later would result in a properly working system. No idea if this could make any sense but it might be worth to look into it. -- SYSTEM DATA
Bug#751462: [l10n:cs] Initial Czech translation of PO debconf template for chef 11.8.2-4
Package: chef Version: 11.8.2-4 Severity: wishlist Tags: l10n, patch In attachment there is initial Czech translation of PO debconf template (cs.po) for package chef, please include it. # Czech PO debconf template translation of chef. # Copyright (C) 2014 Michal Simunek michal.simu...@gmail.com # This file is distributed under the same license as the chef package. # Michal Simunek michal.simu...@gmail.com, 2014. # msgid msgstr Project-Id-Version: chef 11.8.2-4\n Report-Msgid-Bugs-To: c...@packages.debian.org\n POT-Creation-Date: 2014-02-18 07:08+0100\n PO-Revision-Date: 2014-06-13 09:15+0200\n Last-Translator: Michal Simunek michal.simu...@gmail.com\n Language-Team: Czech debian-l10n-cz...@lists.debian.org\n Language: cs\n MIME-Version: 1.0\n Content-Type: text/plain; charset=utf-8\n Content-Transfer-Encoding: 8bit\n #. Type: string #. Description #: ../chef.templates:2001 msgid URL of Chef server msgstr URL Chef serveru #. Type: string #. Description #: ../chef.templates:2001 msgid Please choose the full URI that clients will use to connect to the server (for instance: http://chef.example.com:4000). msgstr Zadejte prosím úplnou URI, kterou budou klienti používat pro připojování k serveru (například: http://chef.example.com:4000). #. Type: string #. Description #: ../chef.templates:2001 msgid This setting will be stored in /etc/chef/client.rb as \chef_server_url\. msgstr Tato nastavení se uloží do /etc/chef/client.rb jako \chef_server_url\.
Bug#751460: [Python-modules-team] Bug#751460: ecdsa/util.py throws ImportException, cannot find next in python-six
Control: tags -1 + moreinfo On 2014-06-13 09:17:02, Michael Stapelberg wrote: Source: python-ecdsa Version: 0.11-1 Severity: important I use duplicity, which uses python-paramiko, which uses python-ecdsa since version 1.14.0-1. After upgrading to testing yesterday, duplicity does not work any longer. This is the exception I get: $ /usr/bin/duplicity list-current-files $BASEPATH/root Traceback (most recent call last): File /usr/bin/duplicity, line 1495, in module with_tempdir(main) File /usr/bin/duplicity, line 1489, in with_tempdir fn() File /usr/bin/duplicity, line 1323, in main action = commandline.ProcessCommandLine(sys.argv[1:]) File /usr/lib/python2.7/dist-packages/duplicity/commandline.py, line 1027, in ProcessCommandLine globals.backend = backend.get_backend(args[0]) File /usr/lib/python2.7/dist-packages/duplicity/backend.py, line 161, in get_backend return _backends[pu.scheme](pu) File /usr/lib/python2.7/dist-packages/duplicity/backends/_ssh_paramiko.py, line 75, in __init__ import paramiko File /usr/lib/python2.7/dist-packages/paramiko/__init__.py, line 31, in module from paramiko.transport import SecurityOptions, Transport File /usr/lib/python2.7/dist-packages/paramiko/transport.py, line 55, in module from paramiko.ecdsakey import ECDSAKey File /usr/lib/python2.7/dist-packages/paramiko/ecdsakey.py, line 26, in module from ecdsa import SigningKey, VerifyingKey, der, curves File /usr/lib/python2.7/dist-packages/ecdsa/__init__.py, line 3, in module from .keys import SigningKey, VerifyingKey, BadSignatureError, BadDigestError File /usr/lib/python2.7/dist-packages/ecdsa/keys.py, line 5, in module from . import rfc6979 File /usr/lib/python2.7/dist-packages/ecdsa/rfc6979.py, line 14, in module from .util import number_to_string, number_to_string_crop File /usr/lib/python2.7/dist-packages/ecdsa/util.py, line 9, in module from six import PY3, int2byte, b, next ImportError: cannot import name next There have not been recent changes in python-six, so I’m not sure how python-ecdsa can ever have worked properly :). Downgrading to python-paramiko 1.10.1-1 fixes the issue, as that version is not using python-ecdsa at all. Can you please take a look? $ python -c from six import PY3, int2byte, b, next $ python -c import paramiko in both unstable and jessie. So, please tell me more about your version of python-six. Do you have an old copy if six somewhere in your PYTHONPATH? Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#751463: poppler: Incorrect rendering of TeX ligatures in some files
Source: poppler Version: 0.24.5-4 Severity: normal Dear Maintainer, TeX ligatures are not rendered correctly in some files. I frequently download papers that are hard to read because all the ff, fi are missing, instead just a blank is shown. An example: http://software.imdea.org/~aleks/papers/reflect/reflect.pdf I am reportiung this against poppler itself because the following viewers, all using poppler, all share this issue: okular, evince, katarakt, atril While the following viewers do not use poppler and do not have the issue: mupdf, imagemagick (display), gv Interesting enough, when printing the file with Okular, the ligatures are rendered correctly. Kind regards Ralf -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15.0 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751464: gmsh: Merge ... + Translate gives wrong mesh
Package: gmsh
Version: 2.8.4+dfsg-1+b1
Severity: normal
Merging a .geo file and then translating the volume in it results in a
wrong mesh.
I've attached an example: the unit cube (0,0,0) to (1,1,1) is
translated along the z-axis. The translated cube is defined by the
corners (0,0,1) and (1,1,2). However the resulting mesh has a node on
the z=0 plane (where z should be 1) and another on the z=1 plane that
belongs on the z=2 plane.
Run gmsh -3 cube1.geo or choose Mesh-3D in the GUI to reproduce the
problem. One has to rotate the cube to see the problem. Or look at
these nodes in the .msh file:
9 0.5 0.5 0
10 0.5 0.5 1
The problem does not happen when using Include instead of Merge or
when including the contents of unit-cube.geo directly.
Ansgar
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages gmsh depends on:
ii libann0 1.1.2+doc-5
ii libblas3 [libblas.so.3] 1.2.20110419-7
ii libc62.19-1
ii libfltk-gl1.31.3.2-5
ii libfltk-images1.31.3.2-5
ii libfltk1.3 1.3.2-5
ii libgcc1 1:4.9.0-5
ii libgl1-mesa-glx [libgl1] 10.1.4-1
ii libgl2ps01.3.8-1
ii libglu1-mesa [libglu1] 9.0.0-2
ii libjpeg8 8d-2
ii liblapack3 [liblapack.so.3] 3.5.0-2
ii libmed1 3.0.6-5
ii liboce-foundation8 0.15-4
ii liboce-modeling8 0.15-4
ii libopenmpi1.61.6.5-8
ii libpng12-0 1.2.50-1
ii libstdc++6 4.9.0-5
ii libtet1.51.5.0-3
ii libx11-6 2:1.6.2-2
ii mpi-default-bin 1.0.2+nmu1
Versions of packages gmsh recommends:
pn gmsh-doc none
gmsh suggests no packages.
-- no debconf information
Merge unit-cube.geo;
Translate{0,0,1}{
Volume{1};
}
Mesh.CharacteristicLengthMin = 1;
Point(1) = {0, 0, 0};
Point(2) = {1, 0, 0};
Point(3) = {1, 1, 0};
Point(4) = {0, 1, 0};
Point(5) = {0, 0, 1};
Point(6) = {1, 0, 1};
Point(7) = {1, 1, 1};
Point(8) = {0, 1, 1};
Line(1) = {1,2};
Line(2) = {2,3};
Line(3) = {3,4};
Line(4) = {4,1};
Line(5) = {5,6};
Line(6) = {6,7};
Line(7) = {7,8};
Line(8) = {8,5};
Line(9) = {1,5};
Line(10) = {2,6};
Line(11) = {3,7};
Line(12) = {4,8};
Line Loop(1) = {1,2,3,4};
Line Loop(2) = {5,6,7,8};
Line Loop(3) = {1,10,-5,-9};
Line Loop(4) = {2,11,-6,-10};
Line Loop(5) = {3,12,-7,-11};
Line Loop(6) = {4,9,-8,-12};
Plane Surface(1) = {1};
Plane Surface(2) = {2};
Plane Surface(3) = {3};
Plane Surface(4) = {4};
Plane Surface(5) = {5};
Plane Surface(6) = {6};
Surface Loop(1) = {1,2,3,4,5,6};
Volume (1) = {1};
$MeshFormat
2.2 0 8
$EndMeshFormat
$Nodes
14
1 0 0 1
2 1 0 1
3 1 1 1
4 0 1 1
5 0 0 2
6 1 0 2
7 1 1 2
8 0 1 2
9 0.5 0.5 0
10 0.5 0.5 1
11 0.5 0 1.5
12 1 0.5 1.5
13 0.5 1 1.5
14 0 0.5 1.5
$EndNodes
$Elements
64
1 15 2 0 1 1
2 15 2 0 2 2
3 15 2 0 3 3
4 15 2 0 4 4
5 15 2 0 5 5
6 15 2 0 6 6
7 15 2 0 7 7
8 15 2 0 8 8
9 1 2 0 1 1 2
10 1 2 0 2 2 3
11 1 2 0 3 3 4
12 1 2 0 4 4 1
13 1 2 0 5 5 6
14 1 2 0 6 6 7
15 1 2 0 7 7 8
16 1 2 0 8 8 5
17 1 2 0 9 1 5
18 1 2 0 10 2 6
19 1 2 0 11 3 7
20 1 2 0 12 4 8
21 2 2 0 1 2 3 9
22 2 2 0 1 1 2 9
23 2 2 0 1 3 4 9
24 2 2 0 1 1 9 4
25 2 2 0 2 6 10 5
26 2 2 0 2 10 8 5
27 2 2 0 2 7 10 6
28 2 2 0 2 8 10 7
29 2 2 0 3 6 11 2
30 2 2 0 3 2 11 1
31 2 2 0 3 11 6 5
32 2 2 0 3 11 5 1
33 2 2 0 4 3 12 2
34 2 2 0 4 12 6 2
35 2 2 0 4 7 12 3
36 2 2 0 4 12 7 6
37 2 2 0 5 4 13 3
38 2 2 0 5 13 7 3
39 2 2 0 5 8 13 4
40 2 2 0 5 13 8 7
41 2 2 0 6 4 14 8
42 2 2 0 6 1 14 4
43 2 2 0 6 5 8 14
44 2 2 0 6 1 5 14
45 4 2 0 1 10 7 12 3
46 4 2 0 1 10 1 5 14
47 4 2 0 1 10 6 2 12
48 4 2 0 1 4 10 8 14
49 4 2 0 1 10 7 3 13
50 4 2 0 1 10 6 11 2
51 4 2 0 1 10 4 8 13
52 4 2 0 1 1 10 5 11
53 4 2 0 1 1 10 2 9
54 4 2 0 1 1 4 10 9
55 4 2 0 1 4 3 10 9
56 4 2 0 1 10 3 2 9
57 4 2 0 1 11 1 10 2
58 4 2 0 1 1 4 14 10
59 4 2 0 1 3 12 10 2
60 4 2 0 1 13 4 3 10
61 4 2 0 1 8 10 13 7
62 4 2 0 1 6 5 10 11
63 4 2 0 1 7 6 10 12
64 4 2 0 1 10 5 8 14
$EndElements
Bug#751465: no such HTML::Form::Input man page
Package: libwww-mechanize-perl Version: 1.73-1 File: /usr/share/man/man3/WWW::Mechanize.3pm.gz We see: controls returned are all descended from HTML::Form::Input. Perhaps say HTML::Form's Inputs. As it seems that is where they are mentioned, and there is no HTML::Form::Input man page. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731754: /usr/bin/xmodmap: Re: xmodmap: Does not honour my .Xmodmap at login + setxkbmap de resets manually loaded .Xmodmap
Package: x11-xserver-utils Version: 7.7+2 Followup-For: Bug #731754 Dear Maintainer, Login to X via lightdm (no others tested) .Xmodmap is not recognised. First approach echo xmodmap .Xmodmap $HOME/Xsession wasn't effective Second approach (got this from here https://debianforum.de/forum/viewtopic.php?f=2t=101362#p636420) # ! /bin/bash # /etc/X11/Xsession.d/40-custuom_load-xmodmap USRMODMAP=$HOME/.Xmodmap if [ -x /usr/bin/X11/xmodmap ]; then if [ -f $USRMODMAP ]; then xmodmap $USRMODMAP fi fi to /etc/X11/Xsession.d/40-custuom_load-xmodmap but even get no effect Starting xmodmap .Xmodmap manually works fine but even stops working if I use setxkbmap de (which is necessary because of an Problem with keepassx to get ⅛ to @). Afterwards setxkbmap de is called .Xmodmap is not loaded anymore. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages x11-xserver-utils depends on: ii cpp 4:4.8.2-4 ii libc62.19-1 ii libice6 2:1.0.8-2 ii libx11-6 2:1.6.2-2 ii libxaw7 2:1.0.12-1 ii libxcursor1 1:1.1.14-1 ii libxext6 2:1.3.2-1 ii libxi6 2:1.7.2-1 ii libxmu6 2:1.1.2-1 ii libxmuu1 2:1.1.2-1 ii libxrandr2 2:1.4.2-1 ii libxrender1 1:0.9.8-1 ii libxt6 1:1.1.4-1 ii libxxf86vm1 1:1.1.3-1 x11-xserver-utils recommends no packages. Versions of packages x11-xserver-utils suggests: pn cairo-5cnone pn nickle none ii xorg-docs-core 1:1.7-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741031: libc6: cannot upgrade from 2.17-97 to 2.18-4
Hallo, I have the same issue but with different version and on a 32bit netbook. apt-get upgrade stops with The following packages have unmet dependencies: libc-bin : Depends: libc6 ( 2.19) but 2.19-1 is installed libc-dev-bin : Depends: libc6 ( 2.19) but 2.19-1 is installed libc6-dev : Depends: libc6 (= 2.18-7) but 2.19-1 is installed libc6-i686 : PreDepends: libc6 (= 2.18-7) but 2.19-1 is installed libnih1 : Depends: libc6 ( 2.19) but 2.19-1 is installed E: Unmet dependencies. Try using -f. Hope the requested output will help to get the problem solved. dpkg -l libc* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++--===-===-= ii libc-bin 2.18-7 i386 Embedded GNU C Library: Binaries un libc-dbg none none (no description available) un libc-dev none none (no description available) ii libc-dev-bin 2.18-7 i386 Embedded GNU C Library: Development binaries un libc0.1 none none (no description available) un libc0.1-dev none none (no description available) un libc0.3 none none (no description available) un libc0.3-dev none none (no description available) ii libc6:i386 2.19-1 i386 Embedded GNU C Library: Shared libraries ii libc6-dev:i386 2.18-7 i386 Embedded GNU C Library: Development Libraries and Header File un libc6-i386 none none (no description available) ii libc6-i686:i386 2.18-7 i386 Embedded GNU C Library: Shared libraries [i686 optimized] un libc6.1 none none (no description available) un libc6.1-dev none none (no description available) ii libcaca0:i3860.99.beta18-1.1 i386 colour ASCII art library ii libcairo-gobject2:i386 1.12.16-2 i386 The Cairo 2D vector graphics library (GObject library) ii libcairo2:i386 1.12.16-2 i386 The Cairo 2D vector graphics library ii libcamel-1.2-49 3.12.2-1i386 Evolution MIME message handling library un libcanberra-gtk0 none none (no description available) ii libcanberra-gtk3-0:i386 0.30-2 i386 GTK+ 3.0 helper for playing widget event sounds with libcanbe ii libcanberra-gtk3-module:i386 0.30-2 i386 translates GTK3 widgets signals to event sounds un libcanberra-pulsenone none (no description available) ii libcanberra0:i3860.30-2 i386 simple abstract interface for playing event sounds un libcap-bin none none (no description available) un libcap-dev none none (no description available) ii libcap-ng0:i386 0.7.3-1.1 i386 An alternate POSIX capabilities library ii libcap2:i386 1:2.22-1.2 i386 support for getting/setting POSIX.1e capabilities ii libcap2-bin 1:2.22-1.2 i386 basic utility programs for using capabilities un libccid none none (no description available) un libcdd-dev none none (no description available) ii libcdio-cdda10.83-4.1i386 library to read and control digital audio CDs ii libcdio-paranoia10.83-4.1i386 library to read digital audio CDs with error correction ii libcdio130.83-4.1i386 library to read and control CD-ROM ii libcdparanoia0:i386 3.10.2+debian-11i386 audio extraction tool for sampling CDs (library) ii libcdr-0.0-0 0.0.15-1i386 library for reading and converting Corel DRAW files un libcgi-pm-perl none none (no description available) ii libchamplain-0.12-0:i386 0.12.7-1+b1 i386 C library providing ClutterActor to display maps ii libchamplain-gtk-0.12-0:i386 0.12.7-1+b1 i386 Gtk+ widget to display maps ii libck-connector0:i3860.4.6-4 i386 ConsoleKit libraries ii libclass-isa-perl0.36-5 all report the search path for a class's ISA tree ii libclass-load-perl 0.21-1 all module for loading modules by name ii libclass-method-modifiers-pe 2.10-1 all Perl module providing method modifiers un libclass-mop-perlnone
Bug#751467: man: warning: /usr/share/man/man1/json_pp.1.bundled.gz: ignoring bogus filename
Package: libjson-pp-perl Version: 2.27203-1 File: /usr/share/man/man1/json_pp.1p.gz man: warning: /usr/share/man/man1/json_pp.1.bundled.gz: ignoring bogus filename -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751237: claws-mail: SEGV when trying to get IMAP mail
Ricardo, On Fri, 13 Jun 2014 00:00:27 +0200 Ricardo Mones mo...@debian.org wrote: On Wed, 11 Jun 2014 22:43:04 +0200 Shane Kerr sh...@blij.tk wrote: On Wed, 11 Jun 2014 16:06:24 +0200 Ricardo Mones mo...@debian.org wrote: You can install claws-mail-dbg package to have debug symbols. That way backtraces are more meaningful. Can you reproduce it that way and post the new backtrace? Be sure to use ‘thread apply all bt’ within gdb (claws-mail is multi-threaded). Sure, here is the pertinent output: [snip] Looking at this is seems the problem may actually be in the GnuTLS library I've uploaded a new version of claws-mail (3.10.1-2) and libetpan (1.5-1) which could improve this. Can you upgrade and check if this still happens? It seems to work perfectly. Thanks for the rapid fix!!! :-D Cheers, -- Shane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751468: nut-server: /lib/systemd/system-shutdown/nutshutdown returns 1 if UPS shutdown is not needed
Package: nut-server Version: 2.7.2-1 Severity: minor Hi, During the shutdown on my machine running systemd, it complains at the very last moment that /lib/systemd/system-shutdown/nutshutdown is returning 1. I guess this is only cosmetic Cheers, Laurent Bigonville -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739261: libhdf5-openmpi-dev: Version in stable (wheezy) does not work with gfortran from stable
On 12/06/14 21:51, Gilles Filippini wrote: fixed 739261 hdf5/1.8.12+docs-1.1 thanks Emilio Pozuelo Monfort a écrit , Le 12/06/2014 20:11: On 04/06/14 01:17, Gilles Filippini wrote: Hi, Frank Loeffler a écrit , Le 03/06/2014 21:01: Being hit by this myself now, I am a bit surprised by the reaction can wait a little longer, for an issue that clearly breaks the Fortran interface and seems to be easily fixable. But this aside - is there a plan to get this into _any_ of the future point releases of stable? I have no plan but getting the binNMU #740561 processed. And it all depends on the good will of the release team. You've requested a binnmu for stable on ALL architectures. Before scheduling that, I'd like to clarify some things: Is this bug affecting testing/unstable? If not, please mark it as fixed as appropriate in #739261. This bug doesn't affect testing nor unstable. Marking it fixed for the related version. Is this bug really affecting all architectures? From what I can see, gfortran in wheezy is 4.6 everywhere except on amd64, i386, kfreebsd-amd64 and kfreebsd-i386: gfortran | 4:4.6.3-8 | stable | armel, armhf, ia64, mips, mipsel, powerpc, s390, s390x, sparc gfortran | 4:4.7.2-1 | stable | amd64, i386, kfreebsd-amd64, kfreebsd-i386 And hdf5 1.8.8-9 was built against 4.6 everywhere, from what I can see on: https://buildd.debian.org/status/logs.php?pkg=hdf5ver=1.8.8-9suite=sid So do we need the binnmu everywhere, or only on those architectures where the default gfortran was bumped to 4.7, i.e. on amd64, i386, kfreebsd-amd64 and kfreebsd-i386? My mistake: I took for granted that gfortran was upgraded to 4.7 on all architectures. nmu hdf5_1.8.8-9 . amd64 i386 kfreebsd-amd64 kfreebsd-i386 . stable . -m Rebuild with current gfortran in wheezy (closes: #739261) Hoping to get it right this time :/ Scheduled. This still needs to be accepted by the SRMs for the next point release. Note that the closes: #739261 doesn't work for binnmus, so you'll have to close that manually. Regards, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751469: python-cobe: cobe irc-client crashes as soon as someone says something
Package: python-cobe Version: 2.1.0-1 Severity: normal Tags: patch When running cobe irc-client, the bot connects fine, but as soon as someone says something on the channel where cobe is as well, it crashes. I've attached a patch that fixes the problem. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-cobe depends on: ii libpython2.7-stdlib [python-argparse] 2.7.7~rc1-1 ii python 2.7.6-2 ii python-irc 8.5.3+dfsg-2 ii python-pkg-resources 3.6-1 ii python-stemmer 1.3.0+dfsg-1+b4 pn python:any none python-cobe recommends no packages. python-cobe suggests no packages. -- no debconf information Description: Fix the irc-client function. Author: Guus Sliepen g...@debian.org Last-Update: 2014-06-13 --- a/cobe/irc.py +++ b/cobe/irc.py @@ -63,9 +63,9 @@ self.connection.join(self.log_channel) def on_pubmsg(self, conn, event): -user = irc.client.NickMask(event.source()).nick +user = irc.client.NickMask(event.source).nick -if event.target() == self.log_channel: +if event.target == self.log_channel: # ignore input in the log channel return @@ -74,10 +74,10 @@ return # only respond on channels -if not irc.client.is_channel(event.target()): +if not irc.client.is_channel(event.target): return -msg = event.arguments()[0] +msg = event.arguments[0] # strip pasted nicks from messages msg = re.sub(\S+\s+, , msg) @@ -105,7 +105,7 @@ if to == self.nick: reply = self.brain.reply(text).encode(utf-8) -conn.privmsg(event.target(), %s: %s % (user, reply)) +conn.privmsg(event.target, %s: %s % (user, reply)) class Runner:
Bug#729781: ITP: subliminal -- Command-line tool to search and download subtitles
unblock 729781 by 698258 thanks Now that the dependencies are in unstable (charade not needed so unblocked), here is the package (WIP) on Alioth: http://anonscm.debian.org/viewvc/python-modules/packages/subliminal/trunk/ -- Etienne Millon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741266: [debian-mysql] Bug#741266: mysql-server-5.5: MySQL replication breaks after a while (weeks) since security release 5.5.33+dfsg-0+wheezy1
Dear Maintainer, still no activity on this one? Meanwhile the servers in question are running mysql-server-5.5 version 5.5.37-0+wheezy1 (since 2014-05-15), and the breakage happened two more times, once on 2014-05-21 (repaired by setting up again on 2014-05-22) and another time on 2014-06-02 (repaired on 2014-06-12). Best Regards Jens Arnold Diese elektronische Nachricht ist vertraulich. Die Information ist nur fuer den Adressaten bestimmt. Falls Sie nicht der Adressat sind, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail sowie alle Kopien und angeschlossenen Anlagen. Bitte beachten Sie, dass es in diesem Fall verboten und gesetzeswidrig ist, diese Nachricht zu kopieren, weiterzuleiten oder zu benutzen. Es wurden alle moeglichen Massnahmen getroffen um eine Virusfreiheit der beigefuegten Dateien zu gewaehrleisten. Wir uebernehmen jedoch keine Verantwortung fuer Schaeden, die aufgrund von Software-Viren entstehen und empfehlen Ihnen vor Benutzung der Dateien eine Ueberpruefung auf Viren durchzufuehren. This electronic message contains information that is confidential. The information is intended for the use of the addressee only. If you are not the addressee please inform the sender immediately and delete this e-mail, its attachments and any copies. Please note that any disclosure, copy, distribution or use of the contents of this message is prohibited and may be unlawful. We have taken every reasonable precaution to ensure that any kind of attachment to this e-mail has been swept for viruses. However, we cannot accept liability for any damage sustained as a result of software viruses and would advise you to carry out your own virus checks before opening any attachment. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751374:
Seems to be a gcc-4.9 specific issue only. I fail to reproduce it with gcc-4.7 on wheezy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751283: Acknowledgement (Segmentation fault on startup)
Dne Wed, 11 Jun 2014 20:01:59 +0200 Michal Čihař ni...@debian.org napsal(a): After looking deeper into this, the bug actually appeared in 3.9.3-2+b3, so it's most likely caused by etpan transition rather than claws itself. The segfault happens with 3.9.3-2+b3, but not with 3.9.3-2+b2. And after upgrading to 3.10.1-2 the issue got fixed for me... -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Bug#751461: usb ports inaccessible after boot up
Control: reassign -1 src:linux 3.2.0-4-686-pae On Vi, 13 iun 14, 10:03:42, A.Verheul wrote: Package: vmlinuz Version: 3.2.0-4-686-pae Debian Version:Debian wheezy 7.4.0, i386 Bug summary: USB ports inaccessible after boot up Related bugreport: #500552 - involves exactly the same problem (year 2008) - then solved through CPU replacement - issue archived by now Possibly related : #750445 - describes similar problem with different error code Reporter: Arie Verheul Personal status: new to Linux -- Summary of what has been found so far -- a. The system may work properly and hence the hardware seems OK. b. The issue seems not specific for Debian but rather a general kernel issue. c. Puppy Linux seems less sensitive for the issue. d. The Intel BIOS version affects the issue. e. There are indications that the problem might involve a timing issue. -- Dear sir or madam, I do experience a persistent problem with usb port setup on boot up. The system boots up OK but ends up with non-functioning usb-ports. This renders the system useless. The hardware used is new and recent (see specs below). Initially it was attempted to install Scientific Linux, which uses the Anaconda installer. However, Anaconda boots up OK but with non-functioning usb-ports. No solution was found. Installation was done from an usb stick (no optical drive present). Therefore the issue seems to be a kernel issue which is not specific for Debian. Next it was attempted to install Debian. Just like Anaconda the Debian installer boots up with inaccessible usb ports. This could be solved by repeatedly hotplugging the usb mouse. After the usb ports had become accessible Debian could be installed properly. However, once installed Debian normally always boots up with non functioning usb-ports. Error message as below: [ 20.405006] usb 1-1: device not accepting address 2, error -110 [ 20.516591] usb 1-1: new high-speed USB device number 3 using ehci_hcd [ 36.040241] usb 1-1: device not accepting address 3, error -110 [ 36.152034] usb 1-1: new high-speed USB device number 4 using ehci_hcd [ 46.562305] usb 1-1: device not accepting address 4, error -110 [ 46.674088] usb 1-1: new high-speed USB device number 5 using ehci_hcd [ 57.084282] usb 1-1: device not accepting address 5, error -110 [ 57.084425] hub 1-0:1.0: unable to enumerate USB device on port 1 Instead of usb 1-1 the system may complain about usb 3-1 with exactly the same result. To inspect the hard disk Puppy Linux 5.7.1 was installed on a usb stick. Surprisingly Puppy always booted properly, and did not seem to suffer from the usb issue. However, when the system BIOS was updated in an attempt to solve the issue (see below for version), Puppy randomly failed in about half of the cases. Returning to the previous BIOS version solved this. This was reported to Intel. From experiments it was found that Debian could be made to work with properly functioning usb-ports by simply deleting some log files from the /var/log directory (using Puppy). Deleted were kernel.log and the various dmesg files. Although the effect of this remains unclear it gives gives a 70% chance for a working system. Strange enough the reported errors remain exactly the same, even if the system ends up in a properly working state. The system has been used this way for over 2 month now with consistently the same results. The impression is that the solution found for bug #500552 was rather a workaround than a solution. The random behaviour of both Debian and Puppy (the latter with updated BIOS) could indicate a timing issue. In this respect it might be relevant that the system uses an SSD which is faster than most HDD's. The effect of deleting log files could be just a slight delay in OS loading. I therefore took notes of the time of the first reported usb error, both in cases that ended up with functioning usb ports as in cases with non functioning usb ports. -- Boot up ending with non-functioning usb-ports 20.178 20.178 20.178 20.184 20.200 20.405 Boot up ending with properly functioning usb-ports 20.465 20.477 20.508 20.544 -- These data support the timing issue hypothesis. A first error at 20.405 or earlier would result in non-functioning usb-ports, a first error at 20.465 or later would result in
Bug#750630: Bug#751385: newer python interfers with matplotlib
the workaround maks suggested works well, but you have to adjust all your scripts. If you want a global solution you can adjust your matplotlibrc (/etc/matplotlibrc or ~/.config/matplotlib/matplotlibrc) with backend : GTK or other backends like GTK3Cairo (which i'm using now). A sample configuration and all possible backends can be found here: http://matplotlib.org/users/customizing.html Best wishes Michael signature.asc Description: OpenPGP digital signature
Bug#751470: [autogen] Allow bootstrapping without texlive
Source: autogen
Version: 1:5.18.3-2
Severity: wishlist
Hi,
Here's another set of patches to break a build dependency loop by moving
TeX Live and friends to Build-Depends-Indep. As with libtasn1-6, this
will break a loop as shown in the versioned package page linked to by
http://bootstrap.debian.net/source/autogen.html - TeX Live depends on
src:gnutls28 through several paths and gnutls28 build-depends on
autogen.
Thanks in advance for your assistance with the bootstrapping bugs and
for your work on Debian in general!
G'luck,
Peter
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
From f07af1fb1802f3d79af5adbd8279c3defa18841b Mon Sep 17 00:00:00 2001
From: Peter Pentchev r...@ringlet.net
Date: Thu, 12 Jun 2014 18:01:48 +0300
Subject: [PATCH 1/2] A new PostScript and HTML documentation package.
Move the PostScript and HTML documentation to a brand new autogen-doc
package so that it may be omitted in binary-only builds, e.g. for
bootstrapping. The new package is architecture-independent, so it shall
only be built once and subsequent binary builds on new architectures
will use the ready-made copy from the Debian archive.
---
debian/autogen-doc.doc-base | 18 ++
debian/autogen-doc.docs | 2 ++
debian/autogen.doc-base | 18 --
debian/autogen.docs | 2 --
debian/control | 11 +++
5 files changed, 31 insertions(+), 20 deletions(-)
create mode 100644 debian/autogen-doc.doc-base
create mode 100644 debian/autogen-doc.docs
delete mode 100644 debian/autogen.doc-base
delete mode 100644 debian/autogen.docs
diff --git a/debian/autogen-doc.doc-base b/debian/autogen-doc.doc-base
new file mode 100644
index 000..7edf053
--- /dev/null
+++ b/debian/autogen-doc.doc-base
@@ -0,0 +1,18 @@
+Document: autogen
+Title: AutoGen - The Automated Program Generator
+Author: Bruce Korb
+Abstract: AutoGen is a tool designed for generating program files that
+ contain repetitive text with varied substitutions. Its goal is to simplify
+ the maintenance of programs that contain large amounts of repetitious text.
+ This is especially valuable if there are several blocks of such text that must
+ be kept synchronized. A common example where this would be useful is in
+ creating and maintaining the code required for processing program options.
+Section: Programming
+
+Format: postscript
+Files: /usr/share/doc/autogen-doc/autogen.ps.gz
+
+Format: HTML
+Index: /usr/share/doc/autogen-doc/html/autogen_toc.html
+Files: /usr/share/doc/autogen-doc/html/*
+
diff --git a/debian/autogen-doc.docs b/debian/autogen-doc.docs
new file mode 100644
index 000..c1ec658
--- /dev/null
+++ b/debian/autogen-doc.docs
@@ -0,0 +1,2 @@
+doc/autogen.ps
+doc/html
diff --git a/debian/autogen.doc-base b/debian/autogen.doc-base
deleted file mode 100644
index ca4a3f6..000
--- a/debian/autogen.doc-base
+++ /dev/null
@@ -1,18 +0,0 @@
-Document: autogen
-Title: AutoGen - The Automated Program Generator
-Author: Bruce Korb
-Abstract: AutoGen is a tool designed for generating program files that
- contain repetitive text with varied substitutions. Its goal is to simplify
- the maintenance of programs that contain large amounts of repetitious text.
- This is especially valuable if there are several blocks of such text that must
- be kept synchronized. A common example where this would be useful is in
- creating and maintaining the code required for processing program options.
-Section: Programming
-
-Format: postscript
-Files: /usr/share/doc/autogen/autogen.ps.gz
-
-Format: HTML
-Index: /usr/share/doc/autogen/html/autogen_toc.html
-Files: /usr/share/doc/autogen/html/*
-
diff --git a/debian/autogen.docs b/debian/autogen.docs
deleted file mode 100644
index c1ec658..000
--- a/debian/autogen.docs
+++ /dev/null
@@ -1,2 +0,0 @@
-doc/autogen.ps
-doc/html
diff --git a/debian/control b/debian/control
index ca5ed0d..bfc3a14 100644
--- a/debian/control
+++ b/debian/control
@@ -14,6 +14,7 @@ Package: autogen
Architecture: any
Depends: ${shlibs:Depends}, libopts25-dev (= ${binary:Version}),
${misc:Depends}
+Recommends: autogen-doc
Multi-Arch: foreign
Description: automated text file generator
AutoGen is a tool designed for generating program files that contain
@@ -28,6 +29,16 @@ Description: automated text file generator
.
This package contains the development tools. libopts25-dev contains the
static libraries and header files. libopts25 contains the shared libraries.
+ autogen-doc contains the PostScript and HTML documentation.
+
Bug#748383: [openstack-dev] Fwd: Fwd: Debian people don't like bash8 as a project name (Bug#748383: ITP: bash8 -- bash script style guide checker)
On 06/13/2014 06:53 AM, Morgan Fainberg wrote: Hi Thomas, I felt a couple sentences here were reasonable to add (more than “don’t care” from before). I understand your concerns here, and I totally get what you’re driving at, but in the packaging world wouldn’t this make sense to call it python-bash8? Yes, this is what will happen. Now the binary, I can agree (for reasons outlined) should probably not be named ‘bash8’, but the name of the “command” could be separate from the packaging / project name. If upstream chooses /usr/bin/bash8, I'll have to follow. I don't want to carry patches which I'd have to maintain. Beyond a relatively minor change to the resulting “binary” name [sure bash-tidy, or whatever we come up with], is there something more that really is awful (rather than just silly) about the naming? Renaming python-bash8 into something else is not possible, because the Debian standard is to use, as Debian name, what is used for the import. So if we have import xyz, then the package will be python-xyz. I just don’t see how if we don’t namespace collide on the executable side, how there can be any real confusion (python-bash8, sure pypi is a little different) over what is being installed. The problem is that bash8 doesn't express anything but bash version 8, unless you know pep8. On 06/13/2014 07:32 AM, Stefano Maffulli wrote: As a user, I hate to have to follow the abstruse reasoning of a random set of developers forcing a packager to pick a name for the package that is different than the executable. A unicorn dies every time `apt-get install sillypackage sillypackage` results in File not found. Dang! that was my favorite unicorn. I agree. Names are important. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751471: therion: xtherion hangs for several minutes with CPU @100% when the 'compile' button is pushed
Package: therion
Version: 5.3.14
Severity: normal
Tags: upstream
As reported by Jenny Black on the therion list:
When I compile files in therion, it appears to compile fine, and the
green button on the right changes to green, and says OK, but then
it will hang. It is still running, and using lots of CPU, but I cant
do anything with it without killing it. This happens either if I
compile by hitting F9, or pressing the compile button. The same
thing happens if I make a mistake and it doesn't compile, but gives me
a red Error button. When I restart therion, and load back in my
files everything works as expected... until I compile it again. I am
running therion from debian (unstable) package 5.3.14-1, but I think
this also happened in the previous version.
then later;
I tested Andrew's Cheddar files on this
linux machine, and therion ran nice and quickly. I then tested my files on
my Windows 7 machine at work. Having seen that it would sometimes hang for
Bruce for a minute, I was patient and left it after it hung. It hung for
10.5 minutes, but then was OK. The same is true on linux. I wasn't patient
enough!
Olly has just had a look (thank you Olly!), and in xtherion he changed:
set rx {\S*[^\]\s]\s+\[\d+\]}
to:
set rx {\s\[\d+\]}
It now no longer hangs, and runs as well as ever.
-- System Information:
Debian Release: 7.5
APT prefers stable
APT policy: (990, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-kvm-i386-20110111 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712920: same problem here
As you suggested, I tried to download the source package (also for quota_4.01-3) and compile it without libtirpc. I tested the rpc.rquotad that was built this way and it looks to be working fine (I tried reading and updating remote quotas, and it worked flawlessy). I briefly tried compiling the latest upstream version and at least don't see any segfaults. Without settin up a full ynfs setup I cannot tell easily if it works completely but evidence suggest this is a libtirpc1 problem. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751321: mpv: non-standard gcc/g++ used for build (gcc-4.7)
Control: tags -1 pending On mer, giu 11, 2014 at 08:07:54 +, Matthias Klose wrote: Package: mpv Version: 0.3.10-2 Severity: important Tags: sid jessie User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-4.7, gcc-4.7-legacy This package builds with a non standard compiler version; please check if this package can be built with the default version of gcc/g++, or with gcc-4.9/g++-4.9. mpv requires at least gcc-4.8 to build, so I made it Build-Depends on it on sparc (and powerpc, but that was fixed a while ago) because it had the wrong default gcc version. I see now that this is not needed anymore, so I removed the Build-Depends for sparc too. Cheers signature.asc Description: Digital signature
Bug#751472: /lib/lsb/init-functions.d/40-systemd: init script integration: set +e; set +u changes behavior of init scripts
Package: systemd
Version: 208-1
Severity: normal
File: /lib/lsb/init-functions.d/40-systemd
/lib/lsb/init-functions.d/40-systemd unconditionally uses set +e; set
+u. This can change the behavior of init scripts that use set -e
and/or set -u.
The systemd integration should not rely on set +e or set +u, but
instead work correctly in all cases:
Instead of set +u, access variables in a way that doesn't trigger an
exception when the variable is not set: ${foo:-} will result in an
empty string when foo is not set.
Instead of set +e, explicitly catch commands that might fail, for example
something-that-might-fail || :
It is still okay to use set +e; set +u in the redirection code when
control is not returned to the init script.
I've attached an *untested* patch implementing what I described
above. Not sure if I missed anything.
Ansgar
diff --git a/debian/init-functions.d/40-systemd b/debian/init-functions.d/40-systemd
index a213afc..809ec7a 100644
--- a/debian/init-functions.d/40-systemd
+++ b/debian/init-functions.d/40-systemd
@@ -1,21 +1,18 @@
# -*-Shell-script-*-
# /lib/lsb/init-functions
+_use_systemctl=0
if [ -d /run/systemd/system ]; then
-# Some init scripts use set -e and set -u, we don't want that
-# here
-set +e
-set +u
-if [ -n $DPKG_MAINTSCRIPT_PACKAGE ]; then
+if [ -n ${DPKG_MAINTSCRIPT_PACKAGE:-} ]; then
# If we are called by a maintainer script, chances are good that a
# new or updated sysv init script was installed. Reload daemon to
# pick up any changes.
-systemctl daemon-reload
+systemctl daemon-reload || :
fi
# Redirect SysV init scripts when executed by the user
-if [ $PPID -ne 1 ] [ -z $init ] [ -z $_SYSTEMCTL_SKIP_REDIRECT ]; then
+if [ $PPID -ne 1 ] [ -z ${init:-} ] [ -z ${_SYSTEMCTL_SKIP_REDIRECT:-} ]; then
case $(readlink -f $0) in
/etc/init.d/*)
_use_systemctl=1
@@ -23,7 +20,7 @@ if [ -d /run/systemd/system ]; then
# but can through the init script.
prog=${0##*/}
service=${prog%.sh}.service
-if [ $(systemctl -p CanReload show $service 2/dev/null) = CanReload=no ] [ $1 = reload ]; then
+if [ $(systemctl -p CanReload show $service 2/dev/null) = CanReload=no ] [ ${1:-} = reload ]; then
_use_systemctl=0
fi
;;
@@ -31,8 +28,6 @@ if [ -d /run/systemd/system ]; then
else
export _SYSTEMCTL_SKIP_REDIRECT=true
fi
-else
-_use_systemctl=0
fi
systemctl_redirect () {
@@ -73,6 +68,11 @@ systemctl_redirect () {
}
if [ $_use_systemctl = 1 ]; then
+# Some init scripts use set -e and set -u, we don't want that
+# here
+set +e
+set +u
+
if [ x$1 = xstart -o \
x$1 = xstop -o \
x$1 = xrestart -o \
Bug#748383: [openstack-dev] Fwd: Fwd: Debian people don't like bash8 as a project name (Bug#748383: ITP: bash8 -- bash script style guide checker)
On 06/13/2014 06:04 AM, Thomas Goirand wrote: On 06/13/2014 06:53 AM, Morgan Fainberg wrote: Hi Thomas, I felt a couple sentences here were reasonable to add (more than “don’t care” from before). I understand your concerns here, and I totally get what you’re driving at, but in the packaging world wouldn’t this make sense to call it python-bash8? Yes, this is what will happen. Now the binary, I can agree (for reasons outlined) should probably not be named ‘bash8’, but the name of the “command” could be separate from the packaging / project name. If upstream chooses /usr/bin/bash8, I'll have to follow. I don't want to carry patches which I'd have to maintain. Beyond a relatively minor change to the resulting “binary” name [sure bash-tidy, or whatever we come up with], is there something more that really is awful (rather than just silly) about the naming? Renaming python-bash8 into something else is not possible, because the Debian standard is to use, as Debian name, what is used for the import. So if we have import xyz, then the package will be python-xyz. I just don’t see how if we don’t namespace collide on the executable side, how there can be any real confusion (python-bash8, sure pypi is a little different) over what is being installed. The problem is that bash8 doesn't express anything but bash version 8, unless you know pep8. Impinging on the bash namespace is something I'll almost buy, except that bash never ships with a version number. I'd be vaguely ameniable to renaming the package/binary to bashate, which is pronounced the same, but doesn't have the same namespacing problem. Will talk with Matt Odden about it today. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature
Bug#751405: libetpan17: Does not initialise gnutls if caller has done so, even if gnutls versions differ
Control: forwarded -1 https://github.com/dinhviethoa/libetpan/issues/145 Hi Steven, On Fri, Jun 13, 2014 at 12:11:06AM +1000, Steven McDonald wrote: Package: libetpan17 Version: 1.5-1 Severity: important Tags: upstream patch Hi there, Claws Mail (all versions since 3.9.3-2+b3, inclusive) reliably segfaults seconds after startup on my system. I have attached a full backtrace taken after such an event. I have tracked the problem down to a corner case in the interaction between claws-mail and libetpan17, which seems simplest to fix in libetpan. The trigger for the bug is that claws-mail links directly against libgnutls26, but also against libetpan17, which links against libgnutls-deb0-28. This has been corrected in claws-mail/3.10.1-2 and libetpan/1.5-1 and should fix the issue without patching. Can you upgrade and check? This problem does not occur with versions of claws-mail prior to 3.9.3-2+b3, which all link against libetpan16 (which links against libgnutls26). claws-mail first calls gnutls_global_init, which initialises libgnutls26, and then calls mailstream_gnutls_init_not_required in libetpan17, which causes libetpan not to initialise libgnutls-deb0-28. The result of this is that libetpan calls gnutls with an uninitialised session handle, resulting in a segfault. However, since gnutls_global_init is reentrant, it is perfectly safe to ignore any calls to mailstream_gnutls_init_not_required and initialise gnutls anyway. In the case where gnutls has already been initialised, doing so will simply increment a counter; and in the case where this bug is triggered, gnutls will be properly initialised before use. OpenSSL's SSL_library_init is not reentrant, and therefore this change can only apply to gnutls. I am attaching a patch which implements this change, and I have confirmed that it fixes the segfaulting behaviour described above. Please let me know if you think it needs to be revised, or if you need any further information. Thanks for the detailed analysis! I'm forwarding this upstream to see if it's worth to add it, although seems good to me :) best regards, -- Ricardo Mones ~ Never send a human to do a machine's job. Agent Smith signature.asc Description: Digital signature
Bug#749808: perlrdf: FTBFS - Base class package Exporter::TypeTiny is empty
Control: tag -1 +unreproducible Hi Michael, Michael Tautschnig wrote: During a rebuild of all packages in a clean sid chroot (and cowbuilder+pbuilder) thanks for the report, but I cannot reproduce this build failure. It builds fine for me inside an amd64 Sid pbuilder (no cowbuilder though). Can you retry if you can still reproduce this issue? Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751473: view3dscene: package should not build depend on castle-game-engine-src
Package: view3dscene Version: 3.14.0-1 Severity: minor Just to serve as a reminder: view3dscene build-depends on castle-game-engine-src which is currently needed, but undesirable and should be unneeded in future versions of view3dscene. I quote e-mail to pkg-pascal-de...@lists.alioth.debian.org (Message-ID: 5394427d.40...@gmail.com) below that describes why. Original Message Subject: Re: [Pkg-pascal-devel] are we waiting on each other? Date: Sun, 08 Jun 2014 13:01:17 +0200 From: Michalis Kamburelis To: Project developers pkg-pascal-de...@lists.alioth.debian.org Message-ID: 5394427d.40...@gmail.com snip As an upstream, I can offer some explanation and simple solution: Explanation: In general, we do *not* advice end programs to use the castleconf.inc include file. castleconf.inc should be internal for the engine, and not used by most applications (like games or view3dscene). The fact that view3dscene *right now* refers to castleconf.inc is a temporary hack: that's because view3dscene does some rendering using direct OpenGL calls (which we discourage, with CGE = 5.0.0 all rendering should go through engine classes, to seamlessly support OpenGL and OpenGLES). These calls are used to display some debug stuff (octree, frustum visualization etc.). Moreover, view3dscene uses CastleGL macro (expanded to OpenGL units: GL, GLU, GLExt for OpenGL, or to CastleGLES20 for OpenGLES), even though most of the debug stuff is just commented out under OpenGLES (see comments //TODO-es near some ifdefs). And castleconf.inc handles expanding the CastleGL macro. The end result is that view3dscene is half-ported to OpenGLES (Android, iOS), i.e. it can be compiled and run using OpenGLES renderer and the primary functions work (GUI, 3D models), although some debug 3D stuff is not rendered. In the long run, view3dscene should not use direct OpenGL/OpenGLES calls at all, it should not use CastleGL macro, so so it also should not use castleconf.inc file. So I would not advice to make elaborate work to handle this in Debian packages --- the problem should disappear in upstream anyway :) snip solution that patches view3dscene to strip opengles calls signature.asc Description: OpenPGP digital signature
Bug#751454: [PKG-Openstack-devel] Bug#751454: keystone: CVE-2014-3476: privilege escalation through trust chained delegation
On 06/13/2014 12:44 PM, Salvatore Bonaccorso wrote: Source: keystone Severity: grave Tags: security upstream patch Justification: user security hole Hi Thomas, As you might know, the following vulnerability was published for keystone. CVE-2014-3476[0]: privilege escalation through trust chained delegation If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2014-3476 [1 ]http://lists.openstack.org/pipermail/openstack-announce/2014-June/000240.html Please adjust the affected versions in the BTS as needed. From the advisory at least all version up to 2013.2.3, and 2014.1 to 2014.1.1 are affected. Regards and thanks for your work, Salvatore Hi Salvatore, Thanks for the update. I received the pre-OSSA, but didn't find the time to address it before now. I just uploaded the fix for Sid with urgency=high. As much as I can tell, the Wheezy version isn't affected. None of the source code patched is present in the Essex version of Keystone. This is also what the OSSA tells. I have updated the BTS, I believe I don't have the credentials for the security-tracker. Please mark Wheezy as unaffected, and sid as fixed in version 2014.1.1-2. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751014: Org-mime spurious alternative
Hi Juliusz, This is now fixed in upstream Org. Thanks for reporting this, PS: I let Sébastien tag this bug accordingly, don't know for sure what's the policy here. -- Bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741031: libc6: cannot upgrade from 2.17-97 to 2.18-4
On Fri, Jun 13, 2014 at 10:35:49AM +0200, Bernard Zijlstra wrote: Hallo, I have the same issue but with different version and on a 32bit netbook. apt-get upgrade stops with The following packages have unmet dependencies: libc-bin : Depends: libc6 ( 2.19) but 2.19-1 is installed libc-dev-bin : Depends: libc6 ( 2.19) but 2.19-1 is installed libc6-dev : Depends: libc6 (= 2.18-7) but 2.19-1 is installed libc6-i686 : PreDepends: libc6 (= 2.18-7) but 2.19-1 is installed libnih1 : Depends: libc6 ( 2.19) but 2.19-1 is installed E: Unmet dependencies. Try using -f. Do you have more details about what caused the apt-get upgrade to fail and to go into the above situation? Hope the requested output will help to get the problem solved. It looks like a different issue to me, as you don't have multiarch nor biarch libraries installed. I guess you can try to continue the installation with apt-get install -f. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751474: thunar: Thunar hangs if unable to cleanly terminate SFTP session
Package: thunar Version: 1.6.3-1 Severity: normal Dear Maintainer, Thunar will hang if an SFTP session is terminated uncleanly. The solution is to kill the SSH proces manually. To reproduce, connect to a remote server via SFTP. After successfully logging in, disable your network adaptor. Once done, now attempt to close the connection by pressing the eject symbol next to the SFTP mount icon. If you press the close icon on the window, then you are given the option to terminate Thunar, however this does not terminate the connection Thunar will hang until the SSH process is killed. Waiting several minutes doesn't seem to cause any timeout or user feedback to trigger. Expected behaviour is that thunar will offer to kill the SSH session after some time, and that in the interim, some information about an upcoming timemout will be displayed to the user. Thanks! -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages thunar depends on: ii desktop-file-utils 0.22-1 ii exo-utils 0.10.2-3 ii libatk1.0-0 2.12.0-1 ii libc6 2.18-4 ii libcairo2 1.12.16-2 ii libdbus-1-3 1.8.0-3 ii libdbus-glib-1-20.102-1 ii libexo-1-0 0.10.2-3 ii libgdk-pixbuf2.0-0 2.30.6-1 ii libglib2.0-02.40.0-2 ii libgtk2.0-0 2.24.23-1 ii libgudev-1.0-0 204-8 ii libice6 2:1.0.8-2 ii libnotify4 0.7.6-2 ii libpango1.0-0 1.36.3-1 ii libsm6 2:1.2.1-2 ii libthunarx-2-0 1.6.3-1 ii libxfce4ui-1-0 4.10.0-5 ii libxfce4util6 4.10.1-1 ii libxfconf-0-2 4.10.0-2 ii shared-mime-info1.2-1 ii thunar-data 1.6.3-1 Versions of packages thunar recommends: ii dbus-x111.8.0-3 ii gvfs1.20.0-1+b1 ii libfontconfig1 2.11.0-2 ii libfreetype62.5.2-1 ii thunar-volman 0.8.0-4 ii tumbler 0.1.30-1 ii xdg-user-dirs 0.15-1 ii xfce4-panel 4.10.1-1 Versions of packages thunar suggests: ii thunar-archive-plugin 0.3.1-2 ii thunar-media-tags-plugin 0.2.1-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751014: Org-mime spurious alternative
On Jun/13, Bastien wrote: PS: I let Sébastien tag this bug accordingly, don't know for sure what's the policy here. I just tagged it pending. Cheers, --Seb -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750817: ITP: x265 -- x265 HEVC Encoder
I made some scripts and stuff a while ago to build proper (I guess, but I could be wrong) Debian packages. If you want to create a package from a current hg snapshot, it automatically patches the cmake file and adds all the version information. https://github.com/darealshinji/Debian/tree/master/x265 The source package builds an additional 10bit version under a different name (libx265-10b) too. It works fine on Ubuntu: https://launchpad.net/~djcj/+archive/x265/+packages https://launchpad.net/%7Edjcj/+archive/x265/+packages Maybe you can use some of the stuff. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751475: new upstream version (moved to a new repository)
Package: drbd8-utils Version: 2:8.4.4-1 Severity: wishlist Upstream provides a new version of drbd8-utils, promised to work with drbd 8.3, 8.4 and 9.0. There is also a new git repository. See the mailing list archives, e.g. http://www.gossamer-threads.com/lists/drbd/users/26441 It would be nice if this version could be included in Jessie. Keep on your good work. Regards Harri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751454: [PKG-Openstack-devel] Bug#751454: keystone: CVE-2014-3476: privilege escalation through trust chained delegation
Hi Thomas, On Fri, Jun 13, 2014 at 06:51:27PM +0800, Thomas Goirand wrote: On 06/13/2014 12:44 PM, Salvatore Bonaccorso wrote: Source: keystone Severity: grave Tags: security upstream patch Justification: user security hole Hi Thomas, As you might know, the following vulnerability was published for keystone. CVE-2014-3476[0]: privilege escalation through trust chained delegation If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2014-3476 [1 ]http://lists.openstack.org/pipermail/openstack-announce/2014-June/000240.html Please adjust the affected versions in the BTS as needed. From the advisory at least all version up to 2013.2.3, and 2014.1 to 2014.1.1 are affected. Regards and thanks for your work, Salvatore Hi Salvatore, Thanks for the update. I received the pre-OSSA, but didn't find the time to address it before now. I just uploaded the fix for Sid with urgency=high. Thanks! As much as I can tell, the Wheezy version isn't affected. None of the source code patched is present in the Essex version of Keystone. This is also what the OSSA tells. I have updated the BTS, I believe I don't have the credentials for the security-tracker. Please mark Wheezy as unaffected, and sid as fixed in version 2014.1.1-2. Ok, thanks for checking here. I just have marked wheezy as not affected in the tracker. Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712754: squid3: occaisonally fails assertion in commHandleRead
Control: fixed -1 squid3/3.3.8-1.1
Control: tags -1 + patch
On Wed, Jun 19, 2013 at 12:36:53PM +0200, Helmut Grohne wrote:
The bug contains a non-invasive patch
http://bugs.squid-cache.org/attachment.cgi?id=2276
I intend to NMU squid3 fixing this bug.
I am testing the attached .debdiff on a wheezy/amd64 production system
and am no longer seeing abortions.
Most likely the unstable package is not affected. Can this issue be
considered for the next stable point release?
The patch is indeed applied in sid, see:
http://sources.debian.net/src/squid3/3.3.8-1.1/src/comm.cc#L1147
Helmut
diff -Nru squid3-3.1.20/debian/changelog squid3-3.1.20/debian/changelog
--- squid3-3.1.20/debian/changelog 2013-02-23 15:07:26.0 +0100
+++ squid3-3.1.20/debian/changelog 2014-06-12 23:21:22.0 +0200
@@ -1,3 +1,11 @@
+squid3 (3.1.20-2.2+deb7u1) stable-proposed-updates; urgency=medium
+
+ * Non-maintainer upload.
+ * Add fix-712754-assertion-failure-commHandleRead.patch. Fix sporadic
+assertion failure under high load. (Closes: #712754)
+
+ -- Helmut Grohne hel...@subdivi.de Thu, 12 Jun 2014 23:02:19 +0200
+
squid3 (3.1.20-2.2) unstable; urgency=low
* Non-maintainer upload.
diff -Nru
squid3-3.1.20/debian/patches/fix-712754-assertion-failure-commHandleRead.patch
squid3-3.1.20/debian/patches/fix-712754-assertion-failure-commHandleRead.patch
---
squid3-3.1.20/debian/patches/fix-712754-assertion-failure-commHandleRead.patch
1970-01-01 01:00:00.0 +0100
+++
squid3-3.1.20/debian/patches/fix-712754-assertion-failure-commHandleRead.patch
2014-06-12 22:59:34.0 +0200
@@ -0,0 +1,36 @@
+Description: fix assertion failure in commHandleRead
+Origin: upstream, http://bugs.squid-cache.org/attachment.cgi?id=2276
+Bug: http://bugs.squid-cache.org/show_bug.cgi?id=3048
+Bug-Debian: http://bugs.debian.org/712754
+Author: Alex Rousskov
+Last-Update: 2014-06-12
+Applied-Upstream: yes
+
+Fix for comm.cc:322 commio_has_callback(fd, IOCB_READ, ccb) assertion
+may also be applicable to a similar IOCB_WITE assertion.
+
+When we start closing a descriptor, we call commio_finish_callback() to remove
+I/O callbacks. If this is not done from commHandleRead or commHandleWrite,
+then select(2) structures may still have our descriptor registration and will
+call Comm back to read or write before the descriptor is closed for good. This
+will trigger a commio_has_callback() assertion.
+
+=== modified file 'src/comm.cc'
+--- a/src/comm.cc 2010-05-06 05:01:14 +
b/src/comm.cc 2010-05-09 21:32:23 +
+@@ -1635,11 +1635,13 @@
+ commStopHalfClosedMonitor(fd);
+ commSetTimeout(fd, -1, NULL, NULL);
+
+-// notify read/write handlers
++// notify read/write handlers after canceling select reservations, if any
+ if (commio_has_callback(fd, IOCB_WRITE, COMMIO_FD_WRITECB(fd))) {
++commSetSelect(fd, COMM_SELECT_WRITE, NULL, NULL, 0);
+ commio_finish_callback(fd, COMMIO_FD_WRITECB(fd), COMM_ERR_CLOSING,
errno);
+ }
+ if (commio_has_callback(fd, IOCB_READ, COMMIO_FD_READCB(fd))) {
++commSetSelect(fd, COMM_SELECT_READ, NULL, NULL, 0);
+ commio_finish_callback(fd, COMMIO_FD_READCB(fd), COMM_ERR_CLOSING,
errno);
+ }
+
+
diff -Nru squid3-3.1.20/debian/patches/series
squid3-3.1.20/debian/patches/series
--- squid3-3.1.20/debian/patches/series 2013-02-23 15:07:26.0 +0100
+++ squid3-3.1.20/debian/patches/series 2014-06-12 22:56:57.0 +0200
@@ -4,3 +4,4 @@
20-ipv6-fix
30-CVE-2012-5643-CVE-2013-0189.patch
fix-701123-regression-in-cachemgr.patch
+fix-712754-assertion-failure-commHandleRead.patch
Bug#751476: mutt: 1.5.22 major performance regression with color regexp matching
Package: mutt Version: 1.5.22-1 Hello, I recently upgraded mutt from 1.5.21-6.4 to 1.5.23-1. Before, switching folders with 'c' took much less than a second (I see Mailbox unchanged for a split second, then the new mail folder appeared. After the upgrade it is annoyingly slow, I see sorting mailbox.. for about 5 seconds during which mutt uses a lot of CPU. I installed the intermediate 1.5.22-1 version and this is also slow, so this is the version that introduced the regression. I'm using Maildir format, have some 10 folders, with 50 mails in each folder, so it shouldn't really take a noticeable time. As a reproducer, I attach a folder with a couple of Debian bugs, so it's all public: cd /tmp tar xf testfolder.tar.gz mutt -f /tmp/testfolder This will sit there for several seconds sorting through the 18 mails for my mutt configuration. That doesn't happen without any ~/.muttrc, so I bisected what's causing this and found that it's the regular expression matching: - .muttrc --- color index default yellow '~b Status: .+ Incomplete' color index yellow default '~b This bug is a duplicate of bug' color index default green '~b Status: .+ Fix Released' color index red green '~b Status: .+ Invalid' color index default red '~b Status: .+Fix Released .' color index default red '~b Status: .+Invalid .' color index default red '~b Status: .+ Expired' I use that for coloring (Launchpad) bug mail based on their state changes, but I don't suppose it's specific to the particular text. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) testfolder.tar.gz Description: application/gzip signature.asc Description: Digital signature
Bug#751477: wheezy-pu: package squid3/3.1.20-2.2+deb7u1 (NMU)
Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: Luigi Gangitano lu...@debian.org
Dear release team,
I intend to NMU squid3/3.1.20-2.2+deb7u1 to stable to fix #712754. The
bug is about squid3 occasionally dieing from an assertion failure. The
bug is hard to trigger and the only parameter that is known to have an
influence is load. After the main squid worker dies it is automatically
restarted by its supervisor process. Still this bug causes pages to be
truncated when squid crashes.
Please find the proposed .debdiff attached. I am running it on my
wheezy/amd64 server for testing and did not observe similar crashes or
regressions since switching to the patched package.
Can I go ahead an upload the fixed package?
Helmut
diff -Nru squid3-3.1.20/debian/changelog squid3-3.1.20/debian/changelog
--- squid3-3.1.20/debian/changelog 2013-02-23 15:07:26.0 +0100
+++ squid3-3.1.20/debian/changelog 2014-06-12 23:21:22.0 +0200
@@ -1,3 +1,11 @@
+squid3 (3.1.20-2.2+deb7u1) stable-proposed-updates; urgency=medium
+
+ * Non-maintainer upload.
+ * Add fix-712754-assertion-failure-commHandleRead.patch. Fix sporadic
+assertion failure under high load. (Closes: #712754)
+
+ -- Helmut Grohne hel...@subdivi.de Thu, 12 Jun 2014 23:02:19 +0200
+
squid3 (3.1.20-2.2) unstable; urgency=low
* Non-maintainer upload.
diff -Nru
squid3-3.1.20/debian/patches/fix-712754-assertion-failure-commHandleRead.patch
squid3-3.1.20/debian/patches/fix-712754-assertion-failure-commHandleRead.patch
---
squid3-3.1.20/debian/patches/fix-712754-assertion-failure-commHandleRead.patch
1970-01-01 01:00:00.0 +0100
+++
squid3-3.1.20/debian/patches/fix-712754-assertion-failure-commHandleRead.patch
2014-06-12 22:59:34.0 +0200
@@ -0,0 +1,36 @@
+Description: fix assertion failure in commHandleRead
+Origin: upstream, http://bugs.squid-cache.org/attachment.cgi?id=2276
+Bug: http://bugs.squid-cache.org/show_bug.cgi?id=3048
+Bug-Debian: http://bugs.debian.org/712754
+Author: Alex Rousskov
+Last-Update: 2014-06-12
+Applied-Upstream: yes
+
+Fix for comm.cc:322 commio_has_callback(fd, IOCB_READ, ccb) assertion
+may also be applicable to a similar IOCB_WITE assertion.
+
+When we start closing a descriptor, we call commio_finish_callback() to remove
+I/O callbacks. If this is not done from commHandleRead or commHandleWrite,
+then select(2) structures may still have our descriptor registration and will
+call Comm back to read or write before the descriptor is closed for good. This
+will trigger a commio_has_callback() assertion.
+
+=== modified file 'src/comm.cc'
+--- a/src/comm.cc 2010-05-06 05:01:14 +
b/src/comm.cc 2010-05-09 21:32:23 +
+@@ -1635,11 +1635,13 @@
+ commStopHalfClosedMonitor(fd);
+ commSetTimeout(fd, -1, NULL, NULL);
+
+-// notify read/write handlers
++// notify read/write handlers after canceling select reservations, if any
+ if (commio_has_callback(fd, IOCB_WRITE, COMMIO_FD_WRITECB(fd))) {
++commSetSelect(fd, COMM_SELECT_WRITE, NULL, NULL, 0);
+ commio_finish_callback(fd, COMMIO_FD_WRITECB(fd), COMM_ERR_CLOSING,
errno);
+ }
+ if (commio_has_callback(fd, IOCB_READ, COMMIO_FD_READCB(fd))) {
++commSetSelect(fd, COMM_SELECT_READ, NULL, NULL, 0);
+ commio_finish_callback(fd, COMMIO_FD_READCB(fd), COMM_ERR_CLOSING,
errno);
+ }
+
+
diff -Nru squid3-3.1.20/debian/patches/series
squid3-3.1.20/debian/patches/series
--- squid3-3.1.20/debian/patches/series 2013-02-23 15:07:26.0 +0100
+++ squid3-3.1.20/debian/patches/series 2014-06-12 22:56:57.0 +0200
@@ -4,3 +4,4 @@
20-ipv6-fix
30-CVE-2012-5643-CVE-2013-0189.patch
fix-701123-regression-in-cachemgr.patch
+fix-712754-assertion-failure-commHandleRead.patch
Bug#737538: org-mode beamer
Hi Olivier, is this still a problem for you ? Cheers, --SD -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751478: flann FTBFS for mips/mipsel
Package: flann Version: 1.8.4-3 Tags: sid patch Severity: important Justification: FTBFS User: debian-mips-dev-disc...@lists.alioth.debian.org Usertags: mips-patch Package flann FTBFS for mips and mipsel with an error: [ 85%] Built target flann_mpi_server Linking CXX executable ../bin/flann_example_mpi cd /«PKGBUILDDIR»/obj-mipsel-linux-gnu/examples /usr/bin/cmake -E cmake_link_script CMakeFiles/flann_example_mpi.dir/link.txt --verbose=1 /usr/bin/c++ -g -O2 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fopenmp -Wl,-z,relro -Wl,--as-needed CMakeFiles/flann_example_mpi.dir/flann_example_mpi.cpp.o -o ../bin/flann_example_mpi -rdynamic ../lib/libflann_cpp.so.1.8.4 -lhdf5 -lpthread -lz -ldl -lm -lmpi_cxx -lmpi -ldl -lhwloc -lboost_mpi -lboost_system -lboost_serialization -lboost_thread -lpthread -Wl,-whole-archive ../lib/libflann_cpp_s.a -Wl,-no-whole-archive -lz -ldl -lm -lmpi_cxx -lmpi -lhwloc -lboost_mpi -lboost_system -lboost_serialization -lboost_thread -Wl,-rpath,/«PKGBUILDDIR»/obj-mipsel-linux-gnu/lib: make[3]: Leaving directory `/«PKGBUILDDIR»/obj-mipsel-linux-gnu' /usr/bin/cmake -E cmake_progress_report /«PKGBUILDDIR»/obj-mipsel-linux-gnu/CMakeFiles 4 [ 85%] Built target flann_example_mpi virtual memory exhausted: Cannot allocate memory make[3]: *** [src/cpp/CMakeFiles/flann_s.dir/flann/flann.cpp.o] Error 1 After adding ggc-min-expand flag, package builds successfully. Patch that contains this fix is attached. Could you please consider including this patch? Best regards, Dejan--- flann-1.8.4.orig/debian/rules 2013-12-08 08:15:49.0 +0100 +++ flann-1.8.4/debian/rules 2014-05-12 16:19:42.0 +0200 @@ -5,6 +5,12 @@ DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) +DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH) + +ifneq (,$(filter $(DEB_BUILD_ARCH),mips mipsel)) + export DEB_CXXFLAGS_MAINT_APPEND = --param ggc-min-expand=20 +endif + CMAKE_FLAGS = \ -DCMAKE_BUILD_TYPE:STRING=None \ -DBUILD_MATLAB_BINDINGS:BOOL=OFF \
Bug#751397: ITP: drmips -- Educational MIPS simulator - DrMIPS
I have uploaded a new package, version 1.2.2-1 (I also updated the upstream code). I had found that, when the package was compiled with JDK 7, it would not run in Java 6 (which seems to be the default in Debian stable). I have now added compile flags that fix this. Sorry, I uploaded the package in a hurry and didn't have time to test it in Debian (I use Ubuntu). I have tested it now using Debian stable. -- Bruno Nova
Bug#749808: perlrdf: FTBFS - Base class package Exporter::TypeTiny is empty
Quoting Axel Beckert (2014-06-13 12:50:07) Michael Tautschnig wrote: During a rebuild of all packages in a clean sid chroot (and cowbuilder+pbuilder) thanks for the report, but I cannot reproduce this build failure. It builds fine for me inside an amd64 Sid pbuilder (no cowbuilder though). Can you retry if you can still reproduce this issue? Thanks, Axel. I believe this bug stil exist (but arguably not as severe) however, even if unreproducible in sid. Just a moment ago I asked upstream (Toby Inkster) to look into it. His suspects it is Role::Commons needing a cleanup. Therefore, if Michael can confirm this is unreproducible in Sid, please do not close but just lower severity. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#751475: new upstream version (moved to a new repository)
Hi Harald, On 13:08 Fri 13 Jun , Harald Dunkel wrote: Package: drbd8-utils Version: 2:8.4.4-1 Severity: wishlist Upstream provides a new version of drbd8-utils, promised to work with drbd 8.3, 8.4 and 9.0. There is also a new git repository. See the mailing list archives, e.g. http://www.gossamer-threads.com/lists/drbd/users/26441 It would be nice if this version could be included in Jessie. Thanks for the report. We're already aware of this and will upgrade to the new version soon. Regards, Apollon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751479: ghc 7.8.2 FTBFS for mips/mipsel
Package: ghc Version: 7.8.20140411-5 Tags: experimental patch Severity: important Justification: FTBFS User: debian-mips-dev-disc...@lists.alioth.debian.org Usertags: mips-patch While trying to build ghc 7.8.2 on mips/mipsel architecture, build fails on testing with an error: inplace/bin/ghc-stage1 -package-name rts -shared -dynamic -dynload deploy -no-auto-link-packages `cat rts/dist/libs.depend` rts/dist/build/Globals.dyn_o rts/dist/build/RtsUtils.dyn_o rts/dist/build/Weak.dyn_o rts/dist/build/Sparks.dyn_o rts/dist/build/Interpreter.dyn_o rts/dist/build/Arena.dyn_o rts/dist/build/Trace.dyn_o rts/dist/build/Hash.dyn_o rts/dist/build/RaiseAsync.dyn_o rts/dist/build/Proftimer.dyn_o rts/dist/build/RtsFlags.dyn_o rts/dist/build/RtsMessages.dyn_o rts/dist/build/RetainerSet.dyn_o rts/dist/build/Task.dyn_o rts/dist/build/RtsDllMain.dyn_o rts/dist/build/StgPrimFloat.dyn_o rts/dist/build/Papi.dyn_o rts/dist/build/HsFFI.dyn_o rts/dist/build/Stats.dyn_o rts/dist/build/StgCRun.dyn_o rts/dist/build/OldARMAtomic.dyn_o rts/dist/build/FileLock.dyn_o rts/dist/build/Disassembler.dyn_o rts/dist/build/WSDeque.dyn_o rts/dist/build/ProfHeap.dyn_o rts/dist/build/Stable.dyn_o rts/dist/build/RtsMain.dyn_o rts/dist/build/Schedule.dyn_o rts/dist/build/RtsAPI.dyn_o rts/dist/build/RtsStartup.dyn_o rts/dist/build/Capability.dyn_o rts/dist/build/Threads.dyn_o rts/dist/build/Hpc.dyn_o rts/dist/build/ThreadLabels.dyn_o rts/dist/build/Messages.dyn_o rts/dist/build/Inlines.dyn_o rts/dist/build/LdvProfile.dyn_o rts/dist/build/Ticky.dyn_o rts/dist/build/Adjustor.dyn_o rts/dist/build/Linker.dyn_o rts/dist/build/RetainerProfile.dyn_o rts/dist/build/ClosureFlags.dyn_o rts/dist/build/CheckUnload.dyn_o rts/dist/build/Profiling.dyn_o rts/dist/build/Timer.dyn_o rts/dist/build/ThreadPaused.dyn_o rts/dist/build/Printer.dyn_o rts/dist/build/STM.dyn_o rts/dist/build/hooks/OutOfHeap.dyn_o rts/dist/build/hooks/MallocFail.dyn_o rts/dist/build/hooks/FlagDefaults.dyn_o rts/dist/build/hooks/OnExit.dyn_o rts/dist/build/hooks/StackOverflow.dyn_o rts/dist/build/sm/MBlock.dyn_o rts/dist/build/sm/Scav.dyn_o rts/dist/build/sm/Compact.dyn_o rts/dist/build/sm/Sweep.dyn_o rts/dist/build/sm/GCAux.dyn_o rts/dist/build/sm/GCUtils.dyn_o rts/dist/build/sm/BlockAlloc.dyn_o rts/dist/build/sm/MarkWeak.dyn_o rts/dist/build/sm/GC.dyn_o rts/dist/build/sm/Sanity.dyn_o rts/dist/build/sm/Evac.dyn_o rts/dist/build/sm/Storage.dyn_o rts/dist/build/eventlog/EventLog.dyn_o rts/dist/build/posix/OSMem.dyn_o rts/dist/build/posix/GetTime.dyn_o rts/dist/build/posix/OSThreads.dyn_o rts/dist/build/posix/Itimer.dyn_o rts/dist/build/posix/TTY.dyn_o rts/dist/build/posix/Signals.dyn_o rts/dist/build/posix/Select.dyn_o rts/dist/build/posix/GetEnv.dyn_o rts/dist/build/PrimOps.dyn_o rts/dist/build/StgStartup.dyn_o rts/dist/build/Exception.dyn_o rts/dist/build/StgStdThunks.dyn_o rts/dist/build/Apply.dyn_o rts/dist/build/HeapStackCheck.dyn_o rts/dist/build/Updates.dyn_o rts/dist/build/StgMiscClosures.dyn_o rts/dist/build/AutoApply.dyn_o -o rts/dist/build/libHSrts-ghc7.8.2.so /usr/bin/ld: rts/dist/build/Globals.dyn_o: relocation R_MIPS_HI16 against `__gnu_local_gp' can not be used when making a shared object; recompile with - fPIC rts/dist/build/Globals.dyn_o: error adding symbols: Bad value collect2: error: ld returned 1 exit status make[2]: *** [rts/dist/build/libHSrts-ghc7.8.2.so] Error 1 A patch that adds mips and mipsel into NoSharedLibsPlatformList is attached. After applying this patch, I was able to successfully build ghc 7.8.2 for mips nad mipsel. Could you please consider including this patch? Best regards, Dejan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751481: RM: libgd-gd2-noxpm-perl -- NVIU; superceded by libgd-perl
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 As subject says, please drop libgd-gd2-noxpm-perl: libgd-perl supercedes it. Regards, - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJTmuc3XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWeHYH+wTgTiZ/TW+KutghlPAl7+X1 /Wl9EdxXUDGkDJd8KLwR0ZblbwaXN69HQjD9puiSmixQ3auAbxM4cOzQI4dRAqaM UTIv/3hEW0t7PKRrqUVZrs07Rb8Hfam3GRAnJ6/urr/pCN+3rIRMgKBLOwIMJ4Fh hhl+bGIGMfmnYIvjltGTqD2RjbK6xy+322plxP9zHeLfKoB6TDc6PZGqcQIWR3kF 88JHI9cnPDolwGdyHMw4Ho2JJDv3soPX9qY/CqxKKm1adva6Ypc82nNJa+R5W1Js dTF3x4oqKI29sTCl2d0NW0xleZR8zzQEEB1vzQZCtzTlxu21wYp3CAIc4J3Z8Ag= =5nQr -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#751480: debian-keyring: Distribute recent version via stable-updates
Package: debian-keyring Version: 2013.04.21 Severity: wishlist Dear Maintainer, At debian-u...@lists.debian.org, it was discussed [ https://lists.debian.org/debian-user/2014/06/msg00856.html ff] that the current linux source package for wheezy could not be verified using $ dpkg-source -x linux[...] It was suggested on list to wish for a recent d-k to be distributed via stable-updates, which I am hereby doing. If there is something I can help with to make this possible, please let me know. Best regards, Simon Hollenbach -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash debian-keyring depends on no packages. Versions of packages debian-keyring recommends: ii gnupg 1.4.12-7+deb7u3 debian-keyring suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751482: RM: libgd-gd2-perl -- NVIU; superceded by libgd-perl
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, As subject says, please drop libgd-gd2-perl from unstable: libgd-perl supercedes it. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJTmuelXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vW7FkIAJNgV7OtSJn/1SmpyBGJWnHD 1rMKR6FguqjXhjdxHn0wDAO+rFTTiGTntA+e/ZHLagZcxb2YyRoG1QXmmmT1V1Rr yYCE/IbrneWMNZWxwIWPvCWxxkPIHvpF+flNpQbXTNWA7I1roGUV+Wj6aAAm1mm0 QwAfZK5TLosUMrd6UM6eC207g70s2un8yTOaYGX2eZu1rT9Q9Z25Q7nE7a5GAJDQ 2M6fnOtDjIq1mMEITYtXz7EwHIGryBaiW4kOBhRzA7xSdnUGBsl5fdpUlmLh+Lxq Pwq+o5rDnbPynSg9o2MwVMsqFKWHJXRfyTQBHfYKdZOQuTfWj90uAYYX2OwJUsc= =3XGR -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#743123: Pending fixes for bugs in the libparanoid-perl package
tag 743123 + pending thanks Some bugs in the libparanoid-perl package are closed in revision ff9babdce652f1f41047589159d72ae8f91c1ac4 in branch 'master' by Axel Beckert The full diff can be seen at http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libparanoid-perl.git;a=commitdiff;h=ff9babd Commit message: Add patch to no more use DB_CDB_ALLDB inside Paranoid::BerkeleyDB Fixes FTBFS due to test-suite failures. (Closes: #743123) Yay for build-time testing! :-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750836: machine/atomic.h broken, missing __compiler_membar macro
On 07/06/14 12:59, Romain Francoise wrote:
Package: kfreebsd-kernel-headers
Version: 10.0~5
Severity: serious
libpcap is broken on kfreebsd since kfreebsd-kernel-headers was updated
to the FreeBSD 10 headers, which apparently include this change:
http://svnweb.freebsd.org/base?view=revisionrevision=241374
The sys/cdefs.h file shipped in libc0.1-dev doesn't include the
__compiler_membar macro, so anything that uses the atomic functions will
get a spurious undefined reference. Here's a quick test program:
| #include sys/types.h
| #include sys/cdefs.h
| #include machine/atomic.h
|
| int main(int argc, char **argv)
| {
| unsigned int p, v = 0;
| atomic_store_rel_int(p, v);
| return 0;
| }
this gives:
| rfrancoise@falla ~ % gcc -Wall -o test test.c
| /tmp/cczzxYAr.o: In function `atomic_store_rel_int':
| test.c:(.text+0x15): undefined reference to `__compiler_membar'
| collect2: error: ld returned 1 exit status
| rfrancoise@falla ~ %
Thanks,
This is the last blocker for the libgnutls-deb0-28 transition. It'd be great if
someone could take a look.
Thanks,
Emilio
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751483: python-magcode-core: Uneeded build-dep on python3-all-dev
Package: python-magcode-core Version: 1.4.3-3 Severity: normal This package does not appear to contain any compiled python3 extensions, so the build-dep on python3-all-dev is unneeded. python3-all is sufficient. It would make things easier for python3 transitions because we track what pacakages need recompiling based on the build-deps and so this shows up as needing rebuilding when it, in fact, does not. Also, when reviewing the package, I did not see any architecture specific code. You might consider changing the package from arch:any to arch:all and saving load on the buildds. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750473: u-boot: Please enable Cubietruck support
On Thu, 2014-06-12 at 16:09 -0700, Vagrant Cascadian wrote: Definitely starting to think about splitting the u-boot package into one package per platform, at least for armhf... I'm not aware of your reasoning for that, but in my experience splitting packages up in very small pieces in not a great idea. Even if I don't doubt you're ability to deal with the maintenance overhead, you'll still hit the NEW queue alot Each additional platform adds .5+ MB to the package, and some of these platforms may have limited space, and little or no use for platforms other than their own... Slightly orthogonally, it would be useful (for FEL boot) to be able to install u-boot packages on foreign architectures (so e.g. I can install the cubietruck u-boot on the x86 box at the other end of the USB cable to my truck). I suppose multiarch is the answer rather than Arch:all packages? (Especially since each u-boot will want to be built natively, at least for now...) The size of the package will have nearly doubled since wheezy, and I wouldn't be surprised if people want to add more platforms. I think sunxi in particular will end up contributing *lots* of new platforms. But that's kind of outside the scope of this bug report... Yeah, sorry to add to the off-topicness. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743123: Pending fixes for bugs in the libparanoid-perl package [rt.cpan.org #94349]
Hi, it seems as if the root of this issue is that BerkeleyDB::Env no more supports the flag DB_CDB_ALLDB, it returns Invalid argument. I haven't found anything about this in BerkeleyDB.pm's change log, so I suspect it may be related to BDB changes. The patch at http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libparanoid-perl.git;a=blob_plain;f=debian/patches/dont-use-DB_CDB_ALLDB.patch drops passing that flag to BerkeleyDB::Env and fixes the test suite failures for me. A Debian package containing that patch has just been uploaded to Debian Unstable. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751477: wheezy-pu: package squid3/3.1.20-2.2+deb7u1 (NMU)
Hi, Thanks Helmut for taking care of this bug. Release Team, I support this upload from Helmut. Best regards, L Il giorno 13/giu/2014, alle ore 13:18, Helmut Grohne hel...@subdivi.de ha scritto: Package: release.debian.org Severity: normal Tags: wheezy User: release.debian@packages.debian.org Usertags: pu X-Debbugs-CC: Luigi Gangitano lu...@debian.org Dear release team, I intend to NMU squid3/3.1.20-2.2+deb7u1 to stable to fix #712754. The bug is about squid3 occasionally dieing from an assertion failure. The bug is hard to trigger and the only parameter that is known to have an influence is load. After the main squid worker dies it is automatically restarted by its supervisor process. Still this bug causes pages to be truncated when squid crashes. Please find the proposed .debdiff attached. I am running it on my wheezy/amd64 server for testing and did not observe similar crashes or regressions since switching to the patched package. Can I go ahead an upload the fixed package? Helmut squid3_3.1.20-2.2+deb7u1.debdiff -- Luigi Gangitano -- lu...@debian.org -- gangit...@lugroma3.org GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972 C24A F19B A618 924C 0C26 GPG: 4096R/2BA97CED: 8D48 5A35 FF1E 6EB7 90E5 0F6D 0284 F20C 2BA9 7CED -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751277: python-biopython: FTBFS on mips* powerpc s390x
* Scott Kitterman deb...@kitterman.com, 2014-06-11, 12:46:
All four archs fail with a similar error:
E: pybuild pybuild:256: test: plugin custom failed with: exit code=1: mkdir -p
/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Doc; \
cp -a Doc/Tutorial.tex
/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Doc; \
cp -a Tests
/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build; \
cd
/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Tests; \
env DIALIGN2_DIR=/usr/share/dialign
EMBOSS_ROOT=/usr/lib/emboss HOME=/tmp python2.7 run_tests.py --offline
dh_auto_test: pybuild --test -i python{version} -p 2.7 --test --system=custom
--test-args=mkdir -p {build_dir}/Doc; \
cp -a Doc/Tutorial.tex {build_dir}/Doc; \
cp -a Tests {build_dir}; \
cd {build_dir}/Tests; \
env DIALIGN2_DIR=/usr/share/dialign
EMBOSS_ROOT=/usr/lib/emboss HOME=/tmp {interpreter} run_tests.py --offline
--dir . returned exit code 13
make[1]: *** [override_dh_auto_test] Error 13
That's only dh_auto_* and pybuild exiting noisily. The actual reasons
for failures are elsewhere, and they vary with architecture:
On mips:
| ==
| ERROR: test_long (test_Muscle_tool.SimpleAlignTest)
| Simple muscle call using long file
| --
| Traceback (most recent call last):
| File
/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Tests/test_Muscle_tool.py,
line 275, in test_long
| align = AlignIO.read(child.stdout, clustal)
| File
/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Bio/AlignIO/__init__.py,
line 427, in read
| raise ValueError(No records found in handle)
| ValueError: No records found in handle
|
| ==
| ERROR: test_align (test_Wise.TestWise)
| Call dnal with optional arguments, and do a trivial check on the output.
| --
| Traceback (most recent call last):
| File
/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Tests/test_Wise.py,
line 45, in test_align
| temp_file = Wise.align([dnal], (Wise/human_114_g01_exons.fna_01,
Wise/human_114_g02_exons.fna_01), kbyte=10, force_type=DNA, quiet=True)
| File
/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Bio/Wise/__init__.py,
line 111, in align
| return align(cmdline, pair, 0, force_type, dry_run, quiet, debug)
| File
/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Bio/Wise/__init__.py,
line 113, in align
| raise OSError(%s returned %s % ( .join(cmdline), status))
| OSError: dnal returned 36
|
| --
| Ran 211 tests in 10267.955 seconds
|
| FAILED (failures = 2)
| Skipping any tests requiring internet access
| Python version: 2.7.7 (default, Jun 4 2014, 17:09:48)
On mipsel:
| ==
| ERROR: test_align (test_Wise.TestWise)
| Call dnal with optional arguments, and do a trivial check on the output.
| --
| Traceback (most recent call last):
| File
/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Tests/test_Wise.py,
line 45, in test_align
| temp_file = Wise.align([dnal], (Wise/human_114_g01_exons.fna_01,
Wise/human_114_g02_exons.fna_01), kbyte=10, force_type=DNA, quiet=True)
| File
/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Bio/Wise/__init__.py,
line 111, in align
| return align(cmdline, pair, 0, force_type, dry_run, quiet, debug)
| File
/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Bio/Wise/__init__.py,
line 113, in align
| raise OSError(%s returned %s % ( .join(cmdline), status))
| OSError: dnal returned 36
|
| --
| Ran 211 tests in 1166.417 seconds
|
| FAILED (failures = 1)
| Skipping any tests requiring internet access
| Python version: 2.7.7 (default, Jun 4 2014, 00:11:03)
On powerpc and s390x:
| ==
| ERROR: test_clusterdistance (test_Cluster.TestCluster)
| --
| Traceback (most recent call last):
| File
/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_3.4/build/Tests/test_Cluster.py,
line 212, in test_clusterdistance
| method='a', transpose=0)
| ValueError: method should be a single character
|
|
Bug#751484: c-icap: installing a recompiled c-icap on debian wheezy ends in a broken system
Source: c-icap Version: 1:0.3.3-2 Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? - Installed a clean debian Wheezy. get the source of c-icap from sid. - recompiled c-icap for wheezy without problems/errors. - uploaded it to my personal apt repo, and installed it with apt-get install c-icap now it ends with the error : /etc/init.d/c-icap: 69: export: config_dsSocket /var/ru: bad variable name * What exactly did you do (or not do) that was effective (or ineffective)? - installed it, and got the error, apt-get remove c-icap was not working. * What was the outcome of this action? - manualy edited the status file, to get things running again. * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Best regards, Louis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751485: pinentry-curses: concurent calls mess up the terminal (locking missing)
Package: pinentry-curses Version: 0.8.3-2 Severity: normal Tags: upstream Dear Maintainer, When two parallel instance gpg(1) prompt the user for a passphrase, there should be a locking mechanism to avoid both pinentry to try to modify the TTY at the same time. The problem is visible in the following example: $ killall -u $(whoami) -HUP gpg-agent $ echo blah | gpg --recipient $keyID --encrypt \ | gpg --use-agent --decrypt | gpg --use-agent --sign /dev/null (Another example is where one decrypts a file and sends the cleartext to a remote machine through SSH, where the SSH key is in fact an OpenPGP subkey with Authentication capability, which is decrypted using a ProxyCommand.) Thanks! Cheers, -- Guilhem. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pinentry-curses depends on: ii libc6 2.19-1 ii libncursesw5 5.9+20140118-1 ii libtinfo5 5.9+20140118-1 pinentry-curses recommends no packages. Versions of packages pinentry-curses suggests: pn pinentry-doc none -- no debconf information signature.asc Description: Digital signature
Bug#751487: science-astronomy-dev: recommends non-free libsofa-c-dev
Package: science-astronomy-dev Version: 1.1 Severity: serious Justification: Policy §2.2.1 science-astronomy-dev recommends libsofa-c-dev, which is non-free. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741804: #741804 patch
tags 741804 + patch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751277: python-biopython: FTBFS on mips* powerpc s390x
Hi BioPython developers, I have updated the Debian package to version 1.64 (BTW, it is fine to ping debian-...@lists.debian.org about new upstream versions - we might become more quick in packaging new versions). Thanks for adopting the patches we sended to you. Since the Debian package is built on different hardware architectures, we were facing different problems in the test suite. Here you have an overview about all build logs: https://buildd.debian.org/status/package.php?p=python-biopythonsuite=unstable Jakub Wilk was kind enough to point to the real problems of the tests which can be read below (since the end of the build log does not say a lot). It would be great if you give some advise how to deal with these problems. Kind regards Andreas. On Fri, Jun 13, 2014 at 02:18:48PM +0200, Jakub Wilk wrote: ... The actual reasons for failures are elsewhere, and they vary with architecture: On mips: | == | ERROR: test_long (test_Muscle_tool.SimpleAlignTest) | Simple muscle call using long file | -- | Traceback (most recent call last): | File /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Tests/test_Muscle_tool.py, line 275, in test_long | align = AlignIO.read(child.stdout, clustal) | File /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Bio/AlignIO/__init__.py, line 427, in read | raise ValueError(No records found in handle) | ValueError: No records found in handle | | == | ERROR: test_align (test_Wise.TestWise) | Call dnal with optional arguments, and do a trivial check on the output. | -- | Traceback (most recent call last): | File /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Tests/test_Wise.py, line 45, in test_align | temp_file = Wise.align([dnal], (Wise/human_114_g01_exons.fna_01, Wise/human_114_g02_exons.fna_01), kbyte=10, force_type=DNA, quiet=True) | File /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Bio/Wise/__init__.py, line 111, in align | return align(cmdline, pair, 0, force_type, dry_run, quiet, debug) | File /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Bio/Wise/__init__.py, line 113, in align | raise OSError(%s returned %s % ( .join(cmdline), status)) | OSError: dnal returned 36 | | -- | Ran 211 tests in 10267.955 seconds | | FAILED (failures = 2) | Skipping any tests requiring internet access | Python version: 2.7.7 (default, Jun 4 2014, 17:09:48) On mipsel: | == | ERROR: test_align (test_Wise.TestWise) | Call dnal with optional arguments, and do a trivial check on the output. | -- | Traceback (most recent call last): | File /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Tests/test_Wise.py, line 45, in test_align | temp_file = Wise.align([dnal], (Wise/human_114_g01_exons.fna_01, Wise/human_114_g02_exons.fna_01), kbyte=10, force_type=DNA, quiet=True) | File /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Bio/Wise/__init__.py, line 111, in align | return align(cmdline, pair, 0, force_type, dry_run, quiet, debug) | File /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Bio/Wise/__init__.py, line 113, in align | raise OSError(%s returned %s % ( .join(cmdline), status)) | OSError: dnal returned 36 | | -- | Ran 211 tests in 1166.417 seconds | | FAILED (failures = 1) | Skipping any tests requiring internet access | Python version: 2.7.7 (default, Jun 4 2014, 00:11:03) On powerpc and s390x: | == | ERROR: test_clusterdistance (test_Cluster.TestCluster) | -- | Traceback (most recent call last): | File /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_3.4/build/Tests/test_Cluster.py, line 212, in test_clusterdistance | method='a', transpose=0) | ValueError: method should be a single character | | == | ERROR: test_kcluster (test_Cluster.TestCluster) | -- | Traceback (most recent call last): | File /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_3.4/build/Tests/test_Cluster.py, line 141, in test_kcluster |
Bug#751488: initramfs-tools: Shell spawned despite panic=0
Package: initramfs-tools
Version: 0.109.1
Severity: critical
Tags: patch
Hi,
I've set panic=0 as a kernel cmdline argument which should trigger a
reboot instead of spawning a shell. However, the reboot seems to be
uneffective and a shell is spawned nevertheless. This is unpleasing
since spawn=0 is marketed as a security feature in
initramfs-tools(8):
panic sets an timeout on panic. panic=sec is a documented
security feature: it disables the debug shell.
Output on screen:
Loading, please wait ...
Spawning shell within the initramfs
Rebooting automatically due to panic= boot argument
BusyBox v1.20.2 (Debian 1:1.20.0-7) built-in shell (ash)
Enter 'help' for a list of built-in commands.
/bin/sh: can't access tty; job control turned off
(initramfs) _
The commands halt, reboot, etc. don't work either.
To fix the security impact of an open shell I propose to at least add a
return after the reboot command so that if the reboot is effectively a
NOP still no shell is spawned.
diff --git a/scripts/functions b/scripts/functions
index 5352f1d..de64494 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -43,6 +43,7 @@ panic()
echo Rebooting automatically due to panic= boot argument
sleep ${panic}
reboot
+ return
fi
modprobe -v i8042 || true
modprobe -v atkbd || true
Regards,
Lukas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751489: developers-reference: gandi discount (section 4.13.2) no longer available
Package: developers-reference Version: 3.4.11 Severity: normal Hi, I just got the following answer from gandi support regarding the discount for debian developers: I am sorry, but this offer dates back from 2008, and is no longer available. So section 4.13.2 of the developers reference can be removed. Regards, Jan -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (989, 'stable'), (500, 'oldstable'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15.0-smapi-x61s-amd64-6-g7a1ba90 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash developers-reference depends on no packages. Versions of packages developers-reference recommends: ii debian-policy 3.9.3.1 Versions of packages developers-reference suggests: ii doc-base 0.10.4 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741966:
control: tags -1 confirmed Indeed that was confusing from reading the documentation. Maybe a small example would have been appreciated [...] $ dcut dm --uid Paul Tagliamonte --allow glibc foobar froz [...] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751396: genisoimage: -xa option not documented in man page
On further research, it appears the man page was updated to include this option (and many others, some of them aliases to already-documented commands and some previously undocumented) in upstream SVN... in January 2011. (With typo fixes in March of the same year.) However, the last official upstream release was made in October 2010. The only commits upstream since that official release are documentation updates, documentation spelling/typo fixes, a correction to a Changelog entry, and a segfault fix for icedax. That doesn't seem enough to be worth making a release over, which probably explains why upstream hasn't made one. Any chance of either updating the package to the latest upstream SVN revision, or at least cherry-picking the man-page changes into the Debian package? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750817: ITP: x265 -- x265 HEVC Encoder
This version will store the 10 bit libs in a subfolder, like in the x264 package: https://github.com/darealshinji/Debian/tree/master/x265-new -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751492: libavcodec55: Libavc causes VLC to SIGSEGV
Source: libavcodec55 Version: 6:10.1-1 Severity: important Dear Maintainer, * What led up to the situation? Open vlc to play a video file. The file plays ok but at some point vlc crashes. * What exactly did you do (or not do) that was effective (or ineffective)? Playing same file with another player (kaffeine) works without any problem. VLC crashes at the exact same point of the video every time. I'm not exactly sure if the problem is in libavcodec55 , vlc or even my own file so don't hesitate to contact me if I can provide any helpful information for you. This is a gdb execution + backtrace of vlc when it crashed (in case it helps in any way). Starting program: /usr/bin/vlc [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be) [New Thread 0x7fffeb9b2700 (LWP 3465)] [New Thread 0x7fffeb1b1700 (LWP 3466)] [New Thread 0x7fffe8902700 (LWP 3467)] [0x605118] main libvlc: Executar o VLC coa interface predeterminada. Use 'cvlc' para usar o VLC sen interface. [New Thread 0x7fffe8801700 (LWP 3468)] [New Thread 0x7fffdc1d8700 (LWP 3469)] [New Thread 0x7fffcf02f700 (LWP 3470)] [New Thread 0x7fffce8f5700 (LWP 3471)] [Thread 0x7fffcf02f700 (LWP 3470) exited] [Thread 0x7fffce8f5700 (LWP 3471) exited] [New Thread 0x7fffce8f5700 (LWP 3472)] [New Thread 0x7fffcf02f700 (LWP 3473)] [New Thread 0x7fffcc1bc700 (LWP 3474)] Fontconfig warning: FcPattern object size does not accept value 0 Fontconfig warning: FcPattern object size does not accept value 0 [New Thread 0x7fffb4164700 (LWP 3475)] Fontconfig warning: FcPattern object size does not accept value 0 Fontconfig warning: FcPattern object size does not accept value 0 [0x7fffa8001248] main vout display error: Failed to resize display [Thread 0x7fffcf02f700 (LWP 3473) exited] [Thread 0x7fffcc1bc700 (LWP 3474) exited] [Thread 0x7fffce8f5700 (LWP 3472) exited] [New Thread 0x7fffce8f5700 (LWP 3476)] [New Thread 0x7fffcc1bc700 (LWP 3477)] [New Thread 0x7fffcf02f700 (LWP 3478)] Fontconfig warning: FcPattern object size does not accept value 0 Fontconfig warning: FcPattern object size does not accept value 0 [0x7fffa8001248] main vout display error: Failed to resize display [0x7fffb8002cb8] mpgatofixed32 audio converter error: libmad error: bad main_data_begin pointer Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffcc1bc700 (LWP 3477)] 0x7fffbdaeafc7 in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.55 (gdb) backtrace #0 0x7fffbdaeafc7 in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.55 #1 0x7fffbdaeb9aa in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.55 #2 0x7fffbd956891 in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.55 #3 0x7fffbd95829a in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.55 #4 0x7fffbd946344 in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.55 #5 0x7fffbd7c41f5 in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.55 #6 0x7fffbd7c4a7c in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.55 #7 0x7fffbd9eaea3 in avcodec_decode_video2 () from /usr/lib/x86_64-linux-gnu/libavcodec.so.55 #8 0x7fffbe506d3d in ?? () from /usr/lib/vlc/plugins/codec/libavcodec_plugin.so #9 0x77147baf in ?? () from /usr/lib/libvlccore.so.7 #10 0x77149aaa in ?? () from /usr/lib/libvlccore.so.7 #11 0x779ac0ca in start_thread () from /lib/x86_64-linux- gnu/libpthread.so.0 #12 0x774dcffd in clone () from /lib/x86_64-linux-gnu/libc.so.6 -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751491: php-horde-text-filter: recommends non-free php-horde-text-filter-jsmin
Package: php-horde-text-filter Version: 2.2.1-1 Severity: serious Justification: Policy §2.2.1 php-horde-text-filter recommends php-horde-text-filter-jsmin, which is non-free. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751490: php-horde-core: recommends non-free php-horde-javascriptminify-jsmin
Package: php-horde-core Version: 2.12.0~beta2+debian0-2 Severity: serious Justification: Policy §2.2.1 php-horde-core recommends php-horde-javascriptminify-jsmin, which is non-free. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751480: debian-keyring: Distribute recent version via stable-updates
tags 751480 wontfix thanks Simon Hollenbach dijo [Fri, Jun 13, 2014 at 01:57:21PM +0200]: Dear Maintainer, At debian-u...@lists.debian.org, it was discussed [ https://lists.debian.org/debian-user/2014/06/msg00856.html ff] that the current linux source package for wheezy could not be verified using $ dpkg-source -x linux[...] It was suggested on list to wish for a recent d-k to be distributed via stable-updates, which I am hereby doing. If there is something I can help with to make this possible, please let me know. Hi, I would even argue in the opposite way :) The debian-keyring package is not always updated when we upload a new keyring, and it's a never-dying source of confusion. Given we have a public Git tree, which is up-to-date with the live keyring, I guess that should suffice — And maybe distributing the package as a static thing never to be updated is no longer useful. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750836: machine/atomic.h broken, missing __compiler_membar macro
Emilio Pozuelo Monfort po...@debian.org writes: This is the last blocker for the libgnutls-deb0-28 transition. It'd be great if someone could take a look. If necessary I can work around this issue by disabling zerocopy BPF in libpcap until this is fixed on the kFreeBSD side... -- Romain Francoise rfranco...@debian.org http://people.debian.org/~rfrancoise/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751493: predict: Conflicting declarations of function on_cb_disconnect_clicked to shadow risk of undefined behaviour
Package: predict Version: 2.2.3-4 Severity: wishlist Usertags: goto-cc Tags: upstream During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder and pbuilder) the build failed with the following error. Please note that we use our research compiler tool-chain (using tools from the cbmc package), which permits extended reporting on type inconsistencies at link time. [...] gcc -g -O2 -Wall -o gsat main.o support.o interface.o callbacks.o comms.o plugins.o db.o prefs.o -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lm -ldl error: conflicting function declarations on_cb_disconnect_clicked old definition in module interface file callbacks.h line 28 void (struct _GtkButton *button, void *user_data) new definition in module comms file comms.c line 51 void (void) Makefile:365: recipe for target 'gsat' failed make[3]: *** [gsat] Error 64 make[3]: Leaving directory '/srv/jenkins-slave/workspace/sid-goto-cc-predict/predict-2.2.3/clients/gsat-1.1.0/src' Makefile:376: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 According to its definition here http://sources.debian.net/src/predict/2.2.3-4/clients/gsat-1.1.0/src/callbacks.c?hl=144#L143 on_cb_disconnect_clicked requires two arguments. Yet the declaration here http://sources.debian.net/src/predict/2.2.3-4/clients/gsat-1.1.0/src/comms.c?hl=51#L51 states that the function takes none, and consequently all calls don't pass any. This would result in buffer underflows, yet it seems the arguments aren't actually used at present. With the current declaration, however, the compiler will not be in a position to provide warnings should this change. Best, Michael PS.: I believe this is an upstream issue, but the control file and thus PTS does not provide any Homepage information. pgp4EI0HzOHV8.pgp Description: PGP signature
Bug#751482: RM: libgd-gd2-perl -- NVIU; superceded by libgd-perl
On Friday, June 13, 2014 13:59:34 Jonas Smedegaard wrote: Package: ftp.debian.org Severity: normal Hi, As subject says, please drop libgd-gd2-perl from unstable: libgd-perl supercedes it. - Jonas Checking reverse dependencies... # Broken Depends: circos: circos ircmarkers: ircmarkers libbio-graphics-perl: libbio-graphics-perl libcatalyst-view-gd-perl: libcatalyst-view-gd-perl libcgi-application-plugin-ajaxupload-perl: libcgi-application-plugin- ajaxupload-perl libchado-perl: libchado-perl libchart-strip-perl: libchart-strip-perl libgd-svg-perl: libgd-svg-perl libgd-text-perl: libgd-text-perl libosm-gary68-perl: libosm-gary68-perl libtest-image-gd-perl: libtest-image-gd-perl lightsquid: lightsquid movabletype-opensource: movabletype-opensource # Broken Build-Depends: libbarcode-code128-perl: libgd-gd2-perl libbio-graphics-perl: libgd-gd2-perl (= 2.3) libcatalyst-view-gd-perl: libgd-gd2-perl libchado-perl: libgd-gd2-perl libchart-strip-perl: libgd-gd2-perl libgd-graph3d-perl: libgd-gd2-perl libgd-svg-perl: libgd-gd2-perl libgd-text-perl: libgd-gd2-perl libosm-gary68-perl: libgd-gd2-perl libtest-cgi-multipart-perl: libgd-gd2-perl (= 1:2.45-2) libtest-image-gd-perl: libgd-gd2-perl Please investigate/resolve these issues and then remove the moreinfo tag. Scott K -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751494: python3-falcon: cython extensions for python3 not built
Package: python3-falcon
Version: 0.1.8-2
Severity: normal
Tags: patch
Since python-falcon build-depends on the python3 -dev packages and
python3-falcon is arch:any, I assume you want to build the compiled cython
extensions for it. This isn't currently done. Please see the attached
patch. It's versioned as an NMU, but I have no intent to NMU for this since
it's nowhere near an RC bug.
Alternately, if you don't want the compiled extensions for the python3
packages, please drop the -dev packages for python3 from build-depends and
make python3-falcon arch:all.
diff -Nru python-falcon-0.1.8/debian/changelog python-falcon-0.1.8/debian/changelog
--- python-falcon-0.1.8/debian/changelog 2014-04-18 06:11:20.0 -0400
+++ python-falcon-0.1.8/debian/changelog 2014-06-13 09:04:20.0 -0400
@@ -1,3 +1,12 @@
+python-falcon (0.1.8-2.1) UNRELEASED; urgency=medium
+
+ * Build cython compiled extensions for python3
+- Switch to pybuild and simplify debian/rules
+- Add python{3}-falcon.install
+- Add cython3 to build-depends
+
+ -- Scott Kitterman sc...@kitterman.com Fri, 13 Jun 2014 08:11:10 -0400
+
python-falcon (0.1.8-2) unstable; urgency=medium
* rm -rf $(CURDIR)/debian/python*-falcon/usr/lib/python*/dist-packages/tests
diff -Nru python-falcon-0.1.8/debian/control python-falcon-0.1.8/debian/control
--- python-falcon-0.1.8/debian/control 2014-04-18 06:11:20.0 -0400
+++ python-falcon-0.1.8/debian/control 2014-06-13 09:05:06.0 -0400
@@ -6,7 +6,9 @@
Thomas Goirand z...@debian.org,
Mehdi Abaakouk sil...@sileht.net
Build-Depends: cython,
+ cython3,
debhelper (= 9),
+ dh-python,
lsb-release,
openstack-pkg-tools,
python-all (= 2.6.6-3~),
diff -Nru python-falcon-0.1.8/debian/python3-falcon.install python-falcon-0.1.8/debian/python3-falcon.install
--- python-falcon-0.1.8/debian/python3-falcon.install 1969-12-31 19:00:00.0 -0500
+++ python-falcon-0.1.8/debian/python3-falcon.install 2014-06-13 09:04:59.0 -0400
@@ -0,0 +1,2 @@
+usr/lib/python3*/dist-packages/falcon
+usr/bin
diff -Nru python-falcon-0.1.8/debian/python-falcon.install python-falcon-0.1.8/debian/python-falcon.install
--- python-falcon-0.1.8/debian/python-falcon.install 1969-12-31 19:00:00.0 -0500
+++ python-falcon-0.1.8/debian/python-falcon.install 2014-06-13 09:04:59.0 -0400
@@ -0,0 +1 @@
+usr/lib/python2*/dist-packages/falcon
diff -Nru python-falcon-0.1.8/debian/rules python-falcon-0.1.8/debian/rules
--- python-falcon-0.1.8/debian/rules 2014-04-18 06:11:20.0 -0400
+++ python-falcon-0.1.8/debian/rules 2014-06-13 09:04:52.0 -0400
@@ -8,19 +8,11 @@
include /usr/share/openstack-pkg-tools/pkgos.make
%:
- dh $@ --buildsystem=python_distutils --with python2,python3
+ dh $@ --buildsystem=pybuild --with python2,python3
override_dh_auto_install:
- set -e for pyvers in $(PYTHONS); do \
- python$$pyvers setup.py install --install-layout=deb \
- --root $(CURDIR)/debian/python-falcon; \
- done
- set -e for pyvers in $(PYTHON3S); do \
- python$$pyvers setup.py install --install-layout=deb \
- --root $(CURDIR)/debian/python3-falcon; \
- done
- rm -rf $(CURDIR)/debian/python*-falcon/usr/lib/python*/dist-packages/tests
- mv $(CURDIR)/debian/python3-falcon/usr/bin/falcon-bench $(CURDIR)/debian/python3-falcon/usr/bin/python3-falcon-bench
+ dh_auto_install
+ rm -rf $(CURDIR)/debian/tmp/usr/lib/python*/dist-packages/tests
override_dh_auto_test:
ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
Bug#751495: netdiag: Parameter declarations of function makeaddr differ in signedness
Package: netdiag Version: 1.1-1 Severity: wishlist Usertags: goto-cc Tags: upstream During a rebuild of all packages in a clean sid chroot (and cowbuilder+pbuilder) the build failed with the following error. Please note that we use our research compiler tool-chain (using tools from the cbmc package), which permits extended reporting on type inconsistencies at link time. [...] gcc -o netwatch -g -O2 curs.o dispdata.o services.o netwatch.o processinetrc.o gh.o warning.o -lncurses error: conflicting function declarations makeaddr old definition in module dispdata file dispdata.c line 211 void (char *, char *) new definition in module netwatch file netwatch.c line 2475 void (unsigned char *naddr, char *ascii) Makefile:23: recipe for target 'netwatch' failed make[1]: *** [netwatch] Error 64 make[1]: Leaving directory '/srv/jenkins-slave/workspace/sid-goto-cc-netdiag/netdiag-1.1/netwatch-1.0c' debian/rules:32: recipe for target 'build-stamp' failed It seems the forward declaration in dispdata.c is inconsistent with the actual definition. This should be fixed in order to enable the compiler generate appropriate diagnostics. Best, Michael PS.: I believe this is an upstream issue, but the control file and thus PTS does not provide any Homepage information. pgpSHCCI_lEzD.pgp Description: PGP signature
Bug#751484: FW: Bug#751484: Acknowledgement (c-icap: installing a recompiled c-icap on debian wheezy ends in a broken system)
Hai, I tested also the previous version c-icap-0.3.2-1 from ubuntu trusty. compiled and installed ok no errors works as expected. I got the previous version from ubuntu trusty. i wget them, extraxted them and compiled them. So imo or bugfix 743202 is causing this or the upstream release 0.3.3-1 ( and up ) Best regards, Louis -Oorspronkelijk bericht- Van: Debian BTS [mailto:debb...@buxtehude.debian.org] Namens ow...@bugs.debian.org Verzonden: vrijdag 13 juni 2014 14:21 Aan: Louis Onderwerp: Bug#751484: Acknowledgement (c-icap: installing a recompiled c-icap on debian wheezy ends in a broken system) Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Tim Weippert we...@weiti.org If you wish to submit further information on this problem, please send it to 751...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 751484: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751484 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689230: virtuoso 7.1 to Debian proper [Was: Bug#689230: new version is needed!]
Hi Tim, We are looking to get virtuoso updated in Debian. I was referred to http://wiki.lod2.eu/display/LOD2DOC/Installation+of+a+local+LOD2+stack as an alternative source and I see that you have done some work to update package (from Ubuntu) for the 7.1 release. Since you had some experience with it, would you be interested to jump on board with maintaining virtuoso in Debian? (there is seems to be some work still needed to finalize the package you have created so it could be accepted to stock Debian) Cheers! On Wed, 11 Jun 2014, Sebastian Trüg wrote: On 10.06.2014 20:27, Kjetil Kjernsmo wrote: On Tuesday 10. June 2014 18.30.01 Lisandro Damián Nicanor Pérez Meyer wrote: As far as I understand we need this exact version of virtuoso for nepomuk. No older, no newer. Yes, KDE is switching to baloo, which is actually sitting in NEW IIRC. But that doesn't means that everything has switched to it yet. OK! I'm putting Sebastian Trüg on the CC list, as he is the main mind behind Nepomuk and works for OpenLink (the upstream provider of Virtuoso). I am, actually, not involved in Nepomuk and KDE at all anymore. Sad as it is I do not have the time. Sebastian, could you please have a look at https://bugs.debian.org/689230 and comment (by replying to this email)? I suppose that retaining virtuoso-opensource-6.1 maintained by the KDE team, and try to find someone else to package virtuoso-opensource-7.1 is an option. I would always vote for packaging Virtuoso 7, even for Nepomuk. While I am not developing it anymore, I have been running Nepomuk on Virtuoso 7 for close to 2 years now. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751496: gedit: Please change python3-dev build-dep to python3
Source: gedit Version: 3.12.1-1 Severity: normal gedit does not appear to contain any compiled python extensions, so it does not need python3-dev. Please change it to python3, so it does not show up on the list of packages needing to be rebuilt for python3 transitions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751498: python-greenlet: FTBFS on arm* due to test failures
Source: python-greenlet Version: 0.4.2-1 Severity: serious Justification: fails to build from source (but built successfully in the past) The failure looks the same on both armel and armhf: Linking /«PKGBUILDDIR»/build/lib.linux-armv7l-2.7/greenlet.so to /«PKGBUILDDIR»/greenlet.so copying build/lib.linux-armv7l-2.7/greenlet.so - build/test-2.7 PYTHONPATH=build/test-2.7 python2.7 run-tests.py -n python 2.7.7 (32 bit) using greenlet 0.4.2 from /«PKGBUILDDIR»/build/test-2.7/greenlet.so cc1plus: warning: command line option '-Wstrict-prototypes' is valid for C/ObjC but not for C++ test_exception_disables_tracing (tests.test_tracing.TracingTests) ... ERROR test_greenlet_tracing (tests.test_tracing.TracingTests) ... Segmentation fault make[1]: *** [test-2.7-stamp] Error 139 debian/rules:36: recipe for target 'test-2.7-stamp' failed make[1]: Leaving directory '/«PKGBUILDDIR»' make: *** [build-arch] Error 2 debian/rules:12: recipe for target 'build-arch' failed dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751497: mangler: Return types of function ventrilo3_handshake differ in signedness
Package: mangler Version: 1.2.5-2 Severity: wishlist Usertags: goto-cc Tags: upstream During a rebuild of all packages in a clean sid chroot (and cowbuilder+pbuilder) the build failed with the following error. Please note that we use our research compiler tool-chain (using tools from the cbmc package), which permits extended reporting on type inconsistencies at link time. [...] libtool: link: gcc -shared -fPIC -DPIC .libs/libventrilo3.o .libs/libventrilo3_message.o .libs/ventrilo3_handshake.o -lspeex -lopus -lm -lespeak /usr/lib/libg15daemon_client.so /usr/lib/libg15render.so -lxosd -lgsm -O2 -pthread -Wl,-z -Wl,relro -Wl,--as-needed -pthread -Wl,-soname -Wl,libventrilo3.so.0 -o .libs/libventrilo3.so.0.0.0 error: conflicting function declarations ventrilo3_handshake old definition in module libventrilo3 file libventrilo3.h line 642 signed int (unsigned int, unsigned short int, unsigned char *, unsigned int *, unsigned char *) new definition in module ventrilo3_handshake file ventrilo3_handshake.c line 100 unsigned int (unsigned int ip, unsigned short int port, unsigned char *handshake, unsigned int *handshake_num, unsigned char *handshake_key) Makefile:436: recipe for target 'libventrilo3.la' failed make[4]: *** [libventrilo3.la] Error 64 make[4]: Leaving directory '/srv/jenkins-slave/workspace/sid-goto-cc-mangler/mangler-1.2.5/libventrilo3' Makefile:425: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 Observe the difference between definition and declaration on on the return type; in this case actually the declaration in the header file appears to be more correct than the implementation as it uses -1 as return value. Best, Michael PS.: If the maintainer is registered with upstream's forum, please feel free to forward the bug. pgp9XZRicln14.pgp Description: PGP signature
Bug#751455: laptop-mode-tools: logs -eq: unexpected operator on start
Control: tag -1 +fixed-upstream +pending On 06/13/2014 10:26 AM, Nathan Myers wrote: Package: laptop-mode-tools Version: 1.61-2 Severity: important Tags: upstream patch Dear Maintainer, On startup and when running /etc/init.d/laptop-mode, I see logged messages like cat: /sys/class/net/wlan0/device/enable: No such file or directory /usr/sbin/laptop_mode: 29: [: -eq: unexpected operator The effect of this bug seems to be to interfere with power management on laptop wireless devices. These are a result of a fault in two of the module scripts, where the script tries to read a sys file that doesn't exist: ENABLED=`cat $DEVICE/device/enable` The fix is just s/enable/enabled/ IMPORTANT: this bug appears in two places: /usr/share/laptop-mode-tools/modules/wireless-iwl-power line 27 /usr/share/laptop-mode-tools/modules/wireless-ipw-power line 72 (In version 1.64, it's line 74, not 72.) This corresponds to Ubuntu bug #1298884, which at the time of this writing had no resolution. Thank you for the report Nathan. This is already known, fixed and will be part of the next release, i.e. 1.65, which is due any time soon. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Bug#751499: libwmf: Parameter declarations of any2eucjp differ in signedness
Package: libwmf Version: 0.2.8.4-10.3 Severity: wishlist Usertags: goto-cc Tags: upstream During a rebuild of all packages in a clean sid chroot (and cowbuilder+pbuilder) the build failed with the following error. Please note that we use our research compiler tool-chain (using tools from the cbmc package), which permits extended reporting on type inconsistencies at link time. [...] libtool: link: gcc -shared -fPIC -DPIC .libs/font.o .libs/stream.o .libs/wmf.o .libs/xml.o -Wl,--whole-archive ipa/.libs/libipa.a extra/gd/.libs/libgd.a -Wl,--no-whole-archive -Wl,-rpath -Wl,/srv/jenkins-slave/workspace/sid-goto-cc-libwmf/libwmf-0.2.8.4/src/.libs ./.libs/libwmflite.so -L/usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libfreetype.so -lpng12 -lX11 /usr/lib/x86_64-linux-gnu/libexpat.so -ljpeg -lpng -lz -lm -O2 -pthread -Wl,-z -Wl,relro -pthread -Wl,-soname -Wl,libwmf-0.2.so.7 -o .libs/libwmf-0.2.so.7.1.0 error: conflicting function declarations any2eucjp old definition in module gdft file gdft.c line 654 signed int (char *, char *, unsigned int) new definition in module gdkanji file gdkanji.c line 559 signed int (unsigned char *dest, unsigned char *src, unsigned int dest_max) Makefile:571: recipe for target 'libwmf.la' failed make[4]: *** [libwmf.la] Error 64 make[4]: Leaving directory '/srv/jenkins-slave/workspace/sid-goto-cc-libwmf/libwmf-0.2.8.4/src' Makefile:627: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 Observe that the first and second parameter differ in signedness of the pointer sub-type. This should be fixed to help the compiler generated appropriate diagnostics. Best, Michael PS.: I believe this is an upstream issue, but the control file and thus PTS does not provide any Homepage information. pgpLSl1AghfJh.pgp Description: PGP signature
Bug#751500: ipsvd: Parameter declarations of function ssl_io differ in signedness
Package: ipsvd Version: 1.0.0-2 Usertags: goto-cc Tags: upstream During a rebuild of all packages in a clean sid chroot (and cowbuilder+pbuilder) the build failed with the following error. Please note that we use our research compiler tool-chain (using tools from the cbmc package), which permits extended reporting on type inconsistencies at link time. [...] ./load sslio ssl_io.o uidgid.o sslerror_str.o unix.a byte.a time.a \ -lmatrixssl error: conflicting function declarations ssl_io old definition in module sslio file ssl_io.h line 22 signed int (signed int, const char **) new definition in module ssl_io file ssl_io.c line 334 signed int (unsigned int newsession, const char **prog) Makefile:35: recipe for target 'sslio' failed make[2]: *** [sslio] Error 64 make[2]: Leaving directory '/srv/jenkins-slave/workspace/sid-goto-cc-ipsvd/ipsvd-1.0.0/ipsvd-1.0.0/compile' Makefile:4: recipe for target 'default' failed make[1]: *** [default] Error 2 Observe the difference on the first parameter; this will only be safe as long as no negative values are being passed in. Yet the declaration in ssl_io.h should be fixed to ensure appropriate compiler diagnostics. Best, Michael PS.: I believe this is an upstream issue, but the control file and thus PTS does not provide any Homepage information. pgpWdniCUtchs.pgp Description: PGP signature
Bug#751487: science-astronomy-dev: recommends non-free libsofa-c-dev
I fixed this in the repository, 9c44c5d5ad. Shall I upload this or what is the right way for a metapackage? Cheers Ole -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
