Bug#796907: vte3: should be removed, obsoleted by src:vte2.91
Source: vte3 Severity: serious The src:vte3 and packages built from it should be removed ASAP. It is obsoleted by src:vte2.91 and all reverse dependencies should move to using that (eg. via build-dep on libvte-2.91-dev instead of libvte-2.90-dev). This bug report should help keep src:vte3 out of testing once that's possible and hopefully also alert some reverse dep maintainers about this via http://packages.qa.debian.org so that the removal can happen before Stretch. Regards, Andreas Henriksson
Bug#789699: vulture review
On 25.08.2015 19:17, Gianfranco Costamagna wrote: Control: owner -1 ! Hi Daniel, I would appreciate if you could provide the python3 package, or both. What do you think? according to setup.py the package is python3 ready, so maybe running pybuild --with python3, or providing two packages might be good. what do you think? ... yeah, this would be an option, Py3 as default is coming up, anyway. This is going to be an enhancement for Prospector, which is on Py2, but I think it runs Vulture as an app, an not imports anything from it. I'll take a look and come back! Daniel -- http://www.danielstender.com/blog/ 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
Bug#796280: appstream-glib: Update to 0.5.0 release
This is blocked until we have GNOME-Software 3.18, which supports the new API (needs GNOME 3.18 release). Also, the specification will have to be updated (in progress, almost done). Cheers, Matthias
Bug#781103: Fix confirmed
Simply upgrading the package restores a working Wacom setup in GNOME. Fix confirmed; thank you! -- Andrew Chadwick
Bug#796891: libvtk6-dev: Reference to non-existant vtkGUISupportQtModule.h in /usr/include/vtk-6.2/QVTKWidget.h
tags 796891 +pending severity 796891 important thanks
Bug#794784: Enable memcache support in mapcache
Hi Frederic, On 06-08-15 17:07, Sebastiaan Couwenberg wrote: On 06-08-15 16:50, Frederic Junod wrote: Can you please consider enabling memcache support in mapcache? See attached patch. We should have a recent enough apr to support it, so I've applied your patch in git and the memcache support will be included in the next upload. That will take a little time because the mapcache build dependencies are currently uninstallable due to the ongoing GCC 5 related transitions. Due to missing memcache support on a number of architectures (armel armhf i386 mips mipsel powerpc hppa), so I hope you're not using i386 or one of these other architectures where I had to disable the memcache option. I presume you're using amd64 like most people, this message is mostly meant to document the issue for later reference. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#796908: Should not be released with Stretch, replaced by gnome-desktop3
Source: gnome-desktop Version: 2.32.1-2 Severity: serious Filing this bug with RC severity, to make sure we don't release gnome-desktop with Stretch. Bugs against all reverse-dependencies have been filed. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#796899: Acknowledgement (interesting segfault)
Colin Watson wrote: Here's LD_DEBUG=all output, which suggests it might relate to NSS. 22014: symbol=fclose; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0] 22014: binding file /lib/x86_64-linux-gnu/libnss_compat.so.2 [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `fclose' [GLIBC_2.2.5] strace shows curl gets as far as reading ~/.curlrc before crashing, while ssh seems to start running and reads /etc/passwd before crashing. gdb shows ssh and curl crashing in fwrite and fputc, respectively. Starting program: /lib64/ld-linux-x86-64.so.2 /usr/bin/ssh [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. __GI__IO_fwrite (buf=0x77db4a00, size=1, count=525, fp=0x0) at iofwrite.c:41 41 iofwrite.c: No such file or directory. Starting program: /lib64/ld-linux-x86-64.so.2 /usr/bin/curl [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. fputc (c=99, fp=0x0) at fputc.c:37 37 fputc.c: No such file or directory. -- see shy jo signature.asc Description: Digital signature
Bug#796901: fails to build stage1 cross compiler for kfreebsd-any
Source: gcc-5 Version: 5.1.1-13 Tags: patch User: helm...@debian.org Usertags: rebootstrap Trying to build a stage1 cross compiler for kfreebsd-any, e.g. kfreebsd-amd64 fails with the following error: From https://jenkins.debian.net/job/rebootstrap_kfreebsd-amd64_gcc5/2/console | /tmp/buildd/gcc1/gcc-5-5.2.1/build/./gcc/xgcc -B/tmp/buildd/gcc1/gcc-5-5.2.1/build/./gcc/ -B/usr/x86_64-kfreebsd-gnu/bin/ -B/usr/x86_64-kfreebsd-gnu/lib32/ -isystem /usr/x86_64-kfreebsd-gnu/include -isystem /usr/x86_64-kfreebsd-gnu/sys-include -isystem /tmp/buildd/gcc1/gcc-5-5.2.1/build/sys-include-g -O2 -m32 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fpic -mlong-double-80 -I. -I. -I../../.././gcc -I../../../../src/libgcc -I../../../../src/libgcc/. -I../../../../src/libgcc/../gcc -I../../../../src/libgcc/../include -DHAVE_CC_TLS -DUSE_TLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c ../../../../src/libgcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS | In file included from ../../../../src/libgcc/unwind-dw2.c:401:0: | ./md-unwind-support.h:29:23: fatal error: sys/types.h: No such file or directory | compilation terminated. | ../../../../src/libgcc/static-object.mk:17: recipe for target 'unwind-dw2.o' failed | make[6]: *** [unwind-dw2.o] Error 1 | make[6]: Leaving directory '/tmp/buildd/gcc1/gcc-5-5.2.1/build/x86_64-kfreebsd-gnu/32/libgcc' | Makefile:1154: recipe for target 'multi-do' failed | make[5]: *** [multi-do] Error 1 | make[5]: Leaving directory '/tmp/buildd/gcc1/gcc-5-5.2.1/build/x86_64-kfreebsd-gnu/libgcc' | Makefile:117: recipe for target 'all-multi' failed | make[4]: *** [all-multi] Error 2 | make[4]: Leaving directory '/tmp/buildd/gcc1/gcc-5-5.2.1/build/x86_64-kfreebsd-gnu/libgcc' | Makefile:10662: recipe for target 'all-target-libgcc' failed | make[3]: *** [all-target-libgcc] Error 2 | make[3]: Leaving directory '/tmp/buildd/gcc1/gcc-5-5.2.1/build' | Makefile:852: recipe for target 'all' failed | make[2]: *** [all] Error 2 | make[2]: Leaving directory '/tmp/buildd/gcc1/gcc-5-5.2.1/build' | s=`cat status`; rm -f status; test $s -eq 0 | debian/rules2:1169: recipe for target 'stamps/05-build-stamp' failed | make[1]: *** [stamps/05-build-stamp] Error 1 | make[1]: Leaving directory '/tmp/buildd/gcc1/gcc-5-5.2.1' | debian/rules:52: recipe for target 'stamps/05-build-stamp' failed | make: *** [stamps/05-build-stamp] Error 2 This is a regression introduced in gcc-5 svn revision 8143 which amounts to version 5.1.1-13. It updates the patch stack for a new gcc-5 release and thus updates debian/patches/kfreebsd-unwind.diff. The mentioned patch drops the creation of src/libgcc/config/i386/freebsd-unwind.h, because that file was upstreamed. Well almost that is. What was upstreamed is different from what was removed from packaging patches. In particular the #ifndef inhibit_libc that was present in the Debian patch was dropped upstream. However it was what made the stage1 build work. I therefore propose appending the attached patch to debian/patches/kfreebsd-unwind.diff. Thanks to Steven Chamberlain for his help to sort this out. Helmut --- a/src/libgcc/config/i386/freebsd-unwind.h +++ a/src/libgcc/config/i386/freebsd-unwind.h @@ -26,6 +26,8 @@ /* Do code reading to identify a signal frame, and set the frame state data appropriately. See unwind-dw2.c for the structs. */ +#ifndef inhibit_libc + #include sys/types.h #include signal.h #include sys/ucontext.h @@ -171,3 +171,5 @@ return _URC_NO_REASON; } #endif /* ifdef __x86_64__ */ + +#endif /* ifndef inhibit_libc */
Bug#771413: fixed in dracut 043-1
On Tue, 25 Aug 2015 15:33:51 +0300, Andrei Demekhov and...@appl.sci-nnov.ru said: Should we hope that this important bug fix will propagate back to the stable version? Since this bug is only of severity normal, there's little hope to get this acknowledged by the release team. Maybe open a new bug, which describes exactly what is not working for you when using 040-1. Does your system do not boot when using dracut? -- regards Thomas
Bug#796863: libassa3.5-5v5 and libassa-3.5-5v5: error when trying to install together
* Riley Baird (bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch) wrote: This is listed in the FTP master's cruft report, so if I'm correct, it shouldn't be necessary to request a removal from unstable. Yeah and you have the right conflicts/replaces. I'm surprised it's complaining about this. -- Eric Dorland e...@kuroneko.ca 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
Bug#794845: freedombox-setup: Tor socks port should be available on LAN networks
On 08/07/2015 04:25 PM, Sunil Mohan wrote: On 08/07/2015 04:09 PM, Petter Reinholdtsen wrote: [Sunil Mohan] Can we not have Tor listen on 0.0.0.0:9050 even when transparent proxying is enabled? Sure, but I am unsure how that will work with iptables redirects. Services (web, mumble, etc.) provided on FreedomBox should still be accessible after enabling transparent proxy. To make this happen I imagine that the transparent proxy iptables rule will exclude the current host from the destination list for transparent proxying. Something like: origin:any to destination:!currenthost - proxy. If the rule is written in the FORWARDING table, I think a packet will not enter the chain if it is meant for the localhost. However, I a bit rusty on the topic. I have dug up a bit more and lightly read the TOr transparent proxy page[1]. The rules go into nat/PREROUTING chain in case of Anonymizing Middlebox case, go into OUTPUT chain in case of local redirection case or both. In case of the former services, rules can certainly be written such that traffic directed at local machine is ignored and remaining traffic transparently proxied. It is not a problem to listen on internal interfaces. I have submitted a patch to Plinth to setup Tor and listen on 0.0.0.0. Firewalld (already) only opens the port to internal interfaces and closes them for external interfaces. I have also submitted another patch to remove Tor configuration from freedombox-setup. With this I am marking this bug as patch available so it can be closed when then Plinth patch is committed. Links: 1) https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy -- Sunil signature.asc Description: OpenPGP digital signature
Bug#766993: jackd2: FTBFS with DEB_BUILD_PARALLEL=1 DEB_BUILD_OPTIONS=parallel=4
Quoting Adrian Knoth (2015-08-25 17:42:28) On 10/27/14 16:24, Jonas Smedegaard wrote: Quoting YunQiang Su (2014-10-27 15:16:44) On Mon, Oct 27, 2014 at 9:58 PM, Jonas Smedegaard d...@jones.dk wrote: If I understand your patch correctly (have only read it briefly) the first lines are better written without making shell calls, like this: WAF_EXTRA_ARGS = $(filter-out -j%,$(DEB_MAKE_EXTRA_ARGS)) WAF_JOBS = $(filter -j%,$(DEB_MAKE_EXTRA_ARGS)) Yes, using functions from make should be better. ...and even better by using underlying variable instead of extracting from DEB_MAKE_EXTRA_ARGS. I am not very familiar with cdbs, so no idea about it. Fully understood, and not a problem: I just mention for the record, in case someone would want to dive in and refine even further :-) I do expect your original patch to work fine - all of this is just suggestions for improvements. Thanks, again, for your reporting this issue and providing a patch! I know I'm late by ~10 months, but did you ultimately apply anything? :) nope :-/ - 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#796770: libm17n-dev: arch-dependent file in Multi-Arch: same package
Hi Jakub, Thanks for the feedback. If you are an expert on multi-arch support, I would really appreciate your assistance. On 24/08/15 19:50, Jakub Wilk wrote: Package: libm17n-dev Version: 1.7.0-1 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch libm17n-dev is marked as Multi-Arch: same, but the following file is architecture-dependent: /usr/bin/m17n-config 1) My understanding was that Multi-Arch: same was for files that are architecture-dependent and Multi-Arch: foreign was for files that are architecture-independent. Is that correct? 2) Since m17n-config contains paths that include the triplet, should m17n-config itself be placed somewhere architecture specific instead of in /usr/bin/ ? Are there some good examples of packages that are multi-arch enabled that deal with the same issue? 3) re: https://wiki.debian.org/Multiarch/Implementation: -- /usr/lib - /usr/lib/triplet /usr/lib/pkgdir - /usr/lib/triplet/pkgdir /usr/include: no change /usr/bin: no change /usr/share: no change /usr/sbin: no change -- What should happen to files in /usr/lib/debug/? Should they reside in /usr/lib/triplet/debug/ ? Thanks, #
Bug#775490: ITP: natron -- Natron is an open-source, crossplatform, nodal compositing software
retitle 775490 ITP: natron -- Natron is an open-source, crossplatform, nodal compositing software owner 775490 ! -- I'd like to package Natron. Thanks, Thomas. signature.asc Description: OpenPGP digital signature
Bug#796902: python-scipy: FTBFS: dh: unable to load addon sphinxdoc
Source: python-scipy Version: 0.16.0-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Builds of python-scipy in minimal environments geared for building only its architecture-dependent binary packages have been failing with errors along the lines of dpkg-buildpackage: host architecture arm64 fakeroot debian/rules clean dh clean --with python2,python3,sphinxdoc dh: unable to load addon sphinxdoc: Can't locate Debian/Debhelper/Sequence/sphinxdoc.pm in @INC (you may need to install the Debian::Debhelper::Sequence::sphinxdoc module) (@INC contains: /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/aarch64-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at (eval 5) line 2. BEGIN failed--compilation aborted at (eval 5) line 2. make: *** [clean] Error 2 debian/rules:16: recipe for target 'clean' failed Please either conditionalize the use of --with sphinxdoc appropriately or move python-sphinx from Build-Depends-Indep to Build-Depends. Thanks!
Bug#791114: libdap: library transition may be needed when GCC 5 is the default
On 16-08-15 01:50, Simon McVittie wrote: I believe this one is ready for binNMUs. nmu gdal_1.10.1+dfsg-9 . ALL . -m 'Rebuild against libdap17v5' nmu grads_2:2.0.2-5 . ALL . -m 'Rebuild against libdap17v5' The libdap transition is pretty much done, only the old gdal packages still keep the old libdap packages around. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#796564: [pkg-gnupg-maint] Bug#796564: Upgrade to gpg2.1 breaks enigmail
Am 24.08.2015 um 14:56 schrieb Werner Koch: On Mon, 24 Aug 2015 12:02, bi...@debian.org said: Is this a bug in enigmail then? Any ideas why this worked with gpg2.0? pinentry-gnome requires some extra information for proper working thus Enigmail needs to be changed as well. IIRC, 2.0 does not yet support pinentry-gnome. Hm, that's strange. I did get the GNOME3 pinentry dialogs when using TB/Icedove + enigmail with gpg2.0. So for me the current behaviour is a regression. Anyway, does this bug need to be re-assigned then to enigmail? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#789699: vulture review
Control: owner -1 ! Hi Daniel, I would appreciate if you could provide the python3 package, or both. What do you think? according to setup.py the package is python3 ready, so maybe running pybuild --with python3, or providing two packages might be good. what do you think?
Bug#758223: RFP: variety -- beautiful wallpaper changing program
Control: retitle -1 ITP: variety -- beautiful wallpaper changing program Hi everyone, I'm interested in adopting this package. Best, James signature.asc Description: OpenPGP digital signature
Bug#796400: [pkg-go] Bug#796400: Bug#796400: golang-github-jacobsa-ratelimit: Non-determistically FTBFS due to unreliable timing in tests
On Tue, Aug 25, 2015 at 7:13 PM, Chris Lamb la...@debian.org wrote: Sure. Are you able to modify the test before running it on the relevant system and find a timing that works reliably? lamby, do I have access to the system on which the tests don’t pass? I fear gaining access to this machine would serve no real purpose; the solution here is not to bump the values so that the test is less flaky - the test would remain non-determistic and thus this bug would remain unresolved IMHO, even though it might be harder to trigger. As a concept, I have no problem with automated solutions to point out potential performance regressions, but having a testsuite that fails I don’t think the intention of the test in question is to point out performance regressions, so while I agree with your general statement about flakyness in general, I’m not convinced it applies here. non-determinstically is generally perceived to be a Bad Idea in software engineering. Perhaps some sort of switch or environment variable can be introduced to enable them so that they do not get in the way of the regular build. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- -- Best regards, Michael
Bug#796907: vte3: should be removed, obsoleted by src:vte2.91
Am 25.08.2015 um 19:33 schrieb Andreas Henriksson: Source: vte3 Severity: serious The src:vte3 and packages built from it should be removed ASAP. It is obsoleted by src:vte2.91 and all reverse dependencies should move to using that (eg. via build-dep on libvte-2.91-dev instead of libvte-2.90-dev). This bug report should help keep src:vte3 out of testing once that's possible and hopefully also alert some reverse dep maintainers about this via http://packages.qa.debian.org so that the removal can happen before Stretch. Bugs have already been filed, so I'm posting this for completeness sake: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-gnome-maintain...@lists.alioth.debian.org;tag=vte3-removal -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#785979: ckanclient: diff for NMU version 0.9-1.1
Control: tags 785979 + patch Control: tags 785979 + pending Dear maintainer, I've prepared an NMU for ckanclient (versioned as 0.9-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- WBR, wRAR diff -u ckanclient-0.9/debian/control ckanclient-0.9/debian/control --- ckanclient-0.9/debian/control +++ ckanclient-0.9/debian/control @@ -5,7 +5,7 @@ Build-Depends: debhelper (= 7), python-all-dev, - python-support, + dh-python, python-setuptools Standards-Version: 3.9.2 Homepage: http://thedatahub.org/dataset/ckanclient reverted: --- ckanclient-0.9/debian/pycompat +++ ckanclient-0.9.orig/debian/pycompat @@ -1 +0,0 @@ -2 diff -u ckanclient-0.9/debian/changelog ckanclient-0.9/debian/changelog --- ckanclient-0.9/debian/changelog +++ ckanclient-0.9/debian/changelog @@ -1,3 +1,11 @@ +ckanclient (0.9-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Replace python-support with dh-python in Build-Depends (Closes: #785979). + * Drop obsolete debian/pycompat. + + -- Andrey Rahmatullin w...@debian.org Tue, 25 Aug 2015 22:47:13 +0500 + ckanclient (0.9-1) unstable; urgency=low * Initial release signature.asc Description: Digital signature
Bug#796892: ftp.debian.org: Broken Sources.bz2 file for at least 3 repositories
This is causing me sadness as well.
Bug#796891: libvtk6-dev: Reference to non-existant vtkGUISupportQtModule.h in /usr/include/vtk-6.2/QVTKWidget.h
My reading of this split out is that all the users of the Qt parts of VTK will need to update their build-depends. I think it would be appropriate to file bugs against the relevant packages so they know. Scott K On Tuesday, August 25, 2015 05:14:04 PM Anton Gladky wrote: I think the second option should be better. Anton 2015-08-25 16:49 GMT+02:00 Scott Kitterman deb...@kitterman.com: So does that mean that libvtk6-dev should depend on libvtk6-qt-dev or perhaps /usr/include/vtk-6.2/QVTKWidget.h should move there as well? Scott K On Tuesday, August 25, 2015 04:26:23 PM Anton Gladky wrote: It is in libvtk6-qt-dev [1]. [1] https://packages.debian.org/sid/amd64/libvtk6-qt-dev/filelist Anton 2015-08-25 15:44 GMT+02:00 Scott Kitterman deb...@kitterman.com: Package: libvtk6-dev Version: 6.2.0+dfsg1-3 Severity: grave Tags: upstream Justification: renders package unusable I was trying to build a newer version of gammaray locally to see if it would build with vtk6 and the build failed with this error: In file included from /tmp/buildd/gammaray-2.3.0/plugins/objectvisualizer/vtkwidget.h:31:0, from /tmp/buildd/gammaray-2.3.0/plugins/objectvisualizer/objectvisualizerwidget.cpp:30: /usr/include/vtk-6.2/QVTKWidget.h:39:55: fatal error: vtkGUISupportQtModule.h: No such file or directory compilation
Bug#796904: linux-image-3.16.0-4-amd64: Backport i915 DP 1.2 MST support in Jessie stable Kernel possible?
Package: src:linux Version: 3.16.7-ckt11-1+deb8u3 Severity: wishlist Is it possible do backport DP 1.2 MST support in Debian Jessie stable Kernel? http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0e32b39ceed665bfa4a77a4bc307b6652b991632 -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=63d3aa47-06eb-4dc8-a3bc-dbdf9529d886 ro quiet splash ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-3.16.0-4-amd64 depends on: ii debconf [debconf-2.0] 1.5.56 ii initramfs-tools [linux-initramfs-tool] 0.120 ii kmod18-3 ii linux-base 3.5 Versions of packages linux-image-3.16.0-4-amd64 recommends: ii firmware-linux-free 3.3 pn irqbalance none Versions of packages linux-image-3.16.0-4-amd64 suggests: pn debian-kernel-handbook none ii grub-pc 2.02~beta2-22 pn linux-doc-3.16 none Versions of packages linux-image-3.16.0-4-amd64 is related to: pn firmware-atherosnone pn firmware-bnx2 none pn firmware-bnx2x none pn firmware-brcm80211 none pn firmware-intelwimax none pn firmware-ipw2x00none pn firmware-ivtv none pn firmware-iwlwifinone pn firmware-libertas none ii firmware-linux 0.43 ii firmware-linux-nonfree 0.43 pn firmware-myricomnone pn firmware-netxen none pn firmware-qlogic none pn firmware-ralink none pn firmware-realteknone pn xen-hypervisor none -- debconf information: linux-image-3.16.0-4-amd64/prerm/removing-running-kernel-3.16.0-4-amd64: true linux-image-3.16.0-4-amd64/postinst/depmod-error-initrd-3.16.0-4-amd64: false linux-image-3.16.0-4-amd64/postinst/mips-initrd-3.16.0-4-amd64:
Bug#795270: coreutils: df does not display all nfs mounts for the same mount points
On 25/08/15 17:41, Phil Schwartz wrote: Re: coreutils 8.21 These mount points are different as are the targets: loui-nac01:/vol/vol_pdbuild /srv/builds nfs defaults,nosuid 0 0 loui-nac01:/vol/vol_archive /srv/archives nfs defaults,nosuid 0 0 Yet the latest df doesn’t show them both: df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/hoth--vg-root117G 2.7G 109G 3% / /dev/sda1236M 39M 186M 18% /boot loui-nac01:/vol/vol_pdbuild 5.0T 4.3T 740G 86% /srv/builds So the logic to get rid of duplicates is too aggressive. Using “df -a” the second mount point shows: df -ha Filesystem Size Used Avail Use% Mounted on /dev/mapper/hoth--vg-root117G 2.7G 109G 3% / /dev/sda1236M 39M 186M 18% /boot loui-nac01:/vol/vol_archive 6.5T 5.8T 741G 89% /srv/archives loui-nac01:/vol/vol_pdbuild 5.0T 4.3T 741G 86% /srv/builds Please fix. Thanks. Thanks should be fixed in v8.24
Bug#796524: Fwd: [Bug 728] SMTP listener keeping log file open for days
Control: tags -1 pending On 2015-08-25 Andreas Pflug pgad...@pse-consulting.de wrote: Fixed upstream. [...] Thanks a lot for chasing this. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#796715: coinor-osi: working diff
On Tue, Aug 25, 2015 at 3:46 AM, Rene Engelhard r...@debian.org wrote: Either you can upload it yourself or I can do a team upload, whatever you prefer. Thanks for figuring this out, I don't currently have the time to work through the transition. Team upload would be appreciated. Best, Miles
Bug#796752: IPv6 Nameservers
I've done a little bit more testing on this. Removing IPv6 nameservers from /etc/resolv.conf does seem to resolve this issue on my test system. I must have goofed the initial testing on that.
Bug#796891: libvtk6-dev: Reference to non-existant vtkGUISupportQtModule.h in /usr/include/vtk-6.2/QVTKWidget.h
So does that mean that libvtk6-dev should depend on libvtk6-qt-dev or perhaps /usr/include/vtk-6.2/QVTKWidget.h should move there as well? Scott K On Tuesday, August 25, 2015 04:26:23 PM Anton Gladky wrote: It is in libvtk6-qt-dev [1]. [1] https://packages.debian.org/sid/amd64/libvtk6-qt-dev/filelist Anton 2015-08-25 15:44 GMT+02:00 Scott Kitterman deb...@kitterman.com: Package: libvtk6-dev Version: 6.2.0+dfsg1-3 Severity: grave Tags: upstream Justification: renders package unusable I was trying to build a newer version of gammaray locally to see if it would build with vtk6 and the build failed with this error: In file included from /tmp/buildd/gammaray-2.3.0/plugins/objectvisualizer/vtkwidget.h:31:0, from /tmp/buildd/gammaray-2.3.0/plugins/objectvisualizer/objectvisualizerwidget.cpp:30: /usr/include/vtk-6.2/QVTKWidget.h:39:55: fatal error: vtkGUISupportQtModule.h: No such file or directory compilation
Bug#796893: cpuset: cset program not functional in Debian 8 due to change of file paths.
Package: cpuset Version: 1.5.6-4 Severity: grave Justification: renders package unusable Dear Maintainer, I was looking into setting up a cset shield in order to move kernel threads off of an isolated CPU when I ran into this: ``` $ sudo cset shield -v cset: ** [Errno 2] No such file or directory: '/cpusets//cpus' $ sudo cset shield -c 1-3 cset: ** [Errno 2] No such file or directory: '/cpusets//cpus' ``` None of the invocations I have tried have said anyhting different. The reason for is (I think) described here: https://code.google.com/p/cpuset/issues/detail?id=10 The upstream bug is several years old, which is worrying. I although this is not directly a debian related issue, I am filiing in case it is possible for the Debian team to locally patch. As it stands cset is not functional on Debian 8. Thanks -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (200, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (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 Init: systemd (via /run/systemd/system) Versions of packages cpuset depends on: ii python 2.7.9-1 pn python:any none cpuset recommends no packages. cpuset suggests no packages. -- no debconf information
Bug#759647: runstatedir in autoconf
On Sat, Aug 22, 2015 at 10:41:52AM -0700, Ben Pfaff wrote: On Fri, Aug 21, 2015 at 10:28:46AM +0100, Jonathan McDowell wrote: I don't see any sign that autoconf 2.70 is imminent, and I'd quite like to be able to make use of this macro. Any ETA for when it might possibly hit the Debian 2.69 package? Thanks for the reminder. I applied the patch in question to the package and uploaded it as 2.69-9, just now. Please do test it. Looks to be working as I'd expect; thanks! J. -- /-\ | Wake up, wake up dead man. |@/ Debian GNU/Linux Developer | \- |
Bug#793503: lintian: Please warn on obsolete URLs
Hi Riku! * Riku Voipio riku.voi...@iki.fi, 2015-08-24, 11:00: These obsolete urls are already checked with duck[1][2]. I think what would make sense would be to make lintian recommend duck. Then lintian can run duck if it has been installed. Leaving aside privacy issues, that would make Lintian output dependent on external world, which would be against its design constraints: https://lintian.debian.org/manual/section-1.3.html So I'm afraid we can't run duck, at least not by default. -- Jakub Wilk
Bug#796894: RFS: afl/1.86b-1 -- fuzzy tester for binary formats [ITA]
❦ 25 août 2015 16:23 +0200, Daniel Stender deb...@danielstender.com : I'm looking for an uploader for my new package of American Fuzzy Lop (afl), which is on ITA [1]. Hi Daniel! I don't see any obvious problem. Did you already contact Jakub about this RFS? It's always easier for the previous maintainer to check a new upload. I would also suggest to move the package to a more modern packaging by using dh (but this could be done at a later point). -- Debian package sponsoring guidelines: http://vincent.bernat.im/en/debian-package-sponsoring.html signature.asc Description: PGP signature
Bug#760853: Jitsi still uninstallable
I have the same problem, trying to install jitsi from sid, using apt-pinning, the system is jessie otherwise. My /etc/apt/preferences.d/98jitsi file is as follows: ``` Package: jitsi Pin: release a=unstable Pin-Priority: 1000 Package: * Pin: release a=jessie Pin-Priority: 500 Package: * Pin: release a=unstable Pin-Priority: 400 Package: * Pin: release a=experimental Pin-Priority: 300 ``` The error I get when using sudo apt-get -t unstable install jitsi is: ``` The following packages have unmet dependencies: jitsi : Depends: libjitsi (= 415-0) but it is not installable Depends: libjitsi-jni (= 415-0) but it is not installable E: Unable to correct problems, you have held broken packages. ``` -Milos
Bug#792206: apt-cacher: modifies conffiles (policy 10.7.3): /etc/default/apt-cacher
package apt-cacher fixed 792206 1.7.6 forcemerge 688890 792206 thanks I have loked at this some more and I think it is a spurious piuparts result which is a duplicate of fixed bug #688890 (fixed since 1.7.6). So I propose merging this report with that. Mark
Bug#796891: libvtk6-dev: Reference to non-existant vtkGUISupportQtModule.h in /usr/include/vtk-6.2/QVTKWidget.h
It is in libvtk6-qt-dev [1]. [1] https://packages.debian.org/sid/amd64/libvtk6-qt-dev/filelist Anton 2015-08-25 15:44 GMT+02:00 Scott Kitterman deb...@kitterman.com: Package: libvtk6-dev Version: 6.2.0+dfsg1-3 Severity: grave Tags: upstream Justification: renders package unusable I was trying to build a newer version of gammaray locally to see if it would build with vtk6 and the build failed with this error: In file included from /tmp/buildd/gammaray-2.3.0/plugins/objectvisualizer/vtkwidget.h:31:0, from /tmp/buildd/gammaray-2.3.0/plugins/objectvisualizer/objectvisualizerwidget.cpp:30: /usr/include/vtk-6.2/QVTKWidget.h:39:55: fatal error: vtkGUISupportQtModule.h: No such file or directory compilation terminated. plugins/objectvisualizer/CMakeFiles/gammaray_objectvisualizer_ui_plugin.dir/build.make:57: recipe for target 'plugins/objectvisualizer/CMakeFiles/gammaray_objectvisualizer_ui_plugin.dir/objectvisualizerwidget.cpp.o' failed make[4]: *** [plugins/objectvisualizer/CMakeFiles/gammaray_objectvisualizer_ui_plugin.dir/objectvisualizerwidget.cpp.o] Error 1 make[4]: Leaving directory '/tmp/buildd/gammaray-2.3.0/obj-qt5' CMakeFiles/Makefile2:3257: recipe for target 'plugins/objectvisualizer/CMakeFiles/gammaray_objectvisualizer_ui_plugin.dir/all' failed make[3]: *** [plugins/objectvisualizer/CMakeFiles/gammaray_objectvisualizer_ui_plugin.dir/all] Error 2 make[3]: Leaving directory '/tmp/buildd/gammaray-2.3.0/obj-qt5' Makefile:149: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/tmp/buildd/gammaray-2.3.0/obj-qt5' dh_auto_build: make -j1 returned exit code 2 debian/rules:17: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory '/tmp/buildd/gammaray-2.3.0' debian/rules:10: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 I checked in the installed QVTKWidget.h and line 39 says: #include vtkGUISupportQtModule.h // For export macro but it's not there: ls /usr/include/vtk-6.2/vtkGUISupportQtModule.h ls: cannot access /usr/include/vtk-6.2/vtkGUISupportQtModule.h: No such file or directory It's not listed here either: https://packages.debian.org/sid/amd64/libvtk6-dev/filelist -- debian-science-maintainers mailing list debian-science-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#796900: aptitude: display of resolution options is completely broken
Package: aptitude Version: 0.7-1+b1 Severity: serious Justification: unusable Dear aptitude maintainers, since the update to the +b1 version and a general libstdc++ upgrade orgy, the aptitude on my computer is now more or less broken. When ever there is a conflict/problem (red status line, suggesting resolutions) and I go into the examine screen with 'e', the list of packages to be examined is completely messed up. Not *one* package name is readable (see attached screenshot). This is 100% reproducible, and independent of terminals, I tried gnome-terminal and roxterm. I have no idea what/who is the culprit here, but on my system everything is set to UTF8, as usual. All the best Norbert -- Package-specific info: Terminal: xterm $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.7 compiled at Aug 7 2015 19:34:17 Compiler: g++ 5.2.1 20150730 Compiled against: apt version 4.16.0 NCurses version 5.9 libsigc++ version: 2.4.1 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20150810 cwidget version: 0.5.17 Apt version: 4.16.0 aptitude linkage: linux-vdso.so.1 (0x7ffd388b8000) libapt-pkg.so.4.16 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.16 (0x7fafed668000) libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7fafed438000) libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7fafed20d000) libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7fafed007000) libcwidget.so.3 = /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7fafecd08000) libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fafeca3a000) libboost_iostreams.so.1.58.0 = /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x7fafec821000) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7fafec41f000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fafec201000) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fafebe86000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fafebb85000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fafeb96e000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fafeb5c5000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7fafeb3c2000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fafeb1bd000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7fafeafa2000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7fafead92000) liblzma.so.5 = /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fafeab6e000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7fafea966000) libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fafea76) /lib64/ld-linux-x86-64.so.2 (0x560eeff0d000) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (300, 'testing'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-rc7+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common 0.7-1 ii libapt-pkg4.161.0.10.2 ii libboost-iostreams1.58.0 1.58.0+dfsg-3 ii libc6 2.19-19 ii libcwidget3v5 0.5.17-4 ii libgcc1 1:5.2.1-15 ii libncursesw5 6.0+20150810-1 ii libsigc++-2.0-0v5 2.4.1-2 ii libsqlite3-0 3.8.11.1-1 ii libstdc++65.2.1-15 ii libtinfo5 6.0+20150810-1 ii libxapian22v5 1.2.21-1.2 Versions of packages aptitude recommends: pn aptitude-doc-en | aptitude-doc none ii libparse-debianchangelog-perl 1.2.0-7 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: ii apt-xapian-index 0.47 pn debtags none pn tasksel none -- no debconf information
Bug#796899: interesting segfault
Package: openssh-server Version: 1:6.9p1-1 Severity: normal /lib64/ld-linux-x86-64.so.2 /usr/bin/ssh Segmentation fault This is puzzling, AFAICS it should be the same as running ssh directly. Happens on amd64, not on i386, and didn't used to happen before probably version 1:6.9p1-1. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openssh-server depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.57 ii dpkg 1.18.1 ii init-system-helpers1.23 ii libc6 2.19-19 ii libcomerr2 1.42.13-1 ii libgssapi-krb5-2 1.13.2+dfsg-2 ii libkrb5-3 1.13.2+dfsg-2 ii libpam-modules 1.1.8-3.1 ii libpam-runtime 1.1.8-3.1 ii libpam0g 1.1.8-3.1 ii libselinux12.3-2+b1 ii libssl1.0.01.0.2d-1 ii libwrap0 7.6.q-25 ii lsb-base 4.1+Debian13+nmu1 ii openssh-client 1:6.9p1-1 ii openssh-sftp-server1:6.9p1-1 ii procps 2:3.3.10-2 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages openssh-server recommends: ii ncurses-term 5.9+20150516-2 ii xauth 1:1.0.9-1 Versions of packages openssh-server suggests: pn molly-guard none pn monkeysphere none pn rssh none ii ssh-askpass 1:1.2.4.1-9 pn ufw none -- debconf information excluded -- see shy jo signature.asc Description: Digital signature
Bug#796899: Acknowledgement (interesting segfault)
reassign 796899 libc6 found 796899 2.19-19 thanks This also happens with curl, not just ssh, so reassigning to libc6. /lib64/ld-linux-x86-64.so.2 /usr/bin/curl Segmentation fault Since curl 7.44.0-1 works when run via ld.so, and curl 7.43.0-1 segfaults, I think this might have to do with the ongoing gcc transition. -- see shy jo
Bug#796890: libtest-distmanifest-perl: FTBFS with perl 5.22: test failures
Control: tag -1 + confirmed
On Tue, 25 Aug 2015 15:34:40 +0200, Dominic Hargreaves wrote:
Source: libtest-distmanifest-perl
Version: 1.014-1
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.22-transition
Tags: sid stretch
This package FTBFS with perl 5.22 (currently in experimental):
# Unable to parse MANIFEST.SKIP file:
# No such file or directory
# Using default skip data from ExtUtils::Manifest 1.70
# Distribution files are missing in MANIFEST:
# .pc/applied-patches
# .pc/.quilt_series
# .pc/.version
# .pc/.quilt_patches
# debian/compat
# debian/libtest-distmanifest-perl.examples
# debian/rules
# debian/libtest-distmanifest-perl.docs
# debian/watch
# debian/control
# debian/changelog
# debian/copyright
# debian/libtest-distmanifest-perl.debhelper.log
# debian/source/format
# debian/upstream/metadata
# Failed test 'All files are listed in MANIFEST or skipped'
# at t/02manifest.t line 24.
# Looks like you failed 1 test of 4.
t/02manifest.t .
Interesting that this builds in unstable. - Ah, that's why:
t/02manifest.t . skipped: ExtUtils::Manifest not new enough - your
configuration requires version 1.69
There's something interesting in the POD:
#pod =head1 NON-FATAL ERRORS
#pod
#pod By default, errors in the BMANIFEST or BMANIFEST.SKIP files are treated
#pod as fatal, which really is the purpose of using CTest::DistManifest as
part
#pod of your author test suite.
#pod
#pod In some cases this is not desirable behaviour, such as with the Debian Perl
#pod Group, which runs all tests - including author tests - as part of its
module
#pod packaging process. This wreaks havoc because Debian adds its control files
#pod in Cdebian/ downstream, and that directory or its files are generally
not
#pod in BMANIFEST.SKIP.
#pod
#pod By setting the environment variable BMANIFEST_WARN_ONLY to a true value,
#pod errors will be non-fatal - they show up as diagnostic messages only, but
all
#pod tests pass from the perspective of CTest::Harness.
#pod
#pod This can be used in a test script as:
#pod
#pod $ENV{MANIFEST_WARN_ONLY} = 1;
#pod
#pod or from other shell scripts as:
#pod
#pod export MANIFEST_WARN_ONLY=1
#pod
#pod Note that parsing errors in BMANIFEST and circular dependencies will
#pod always be considered fatal. The author is not aware of any cases where
#pod other behaviour would be useful.
The following attempt to handle this situation works:
#v+
--- a/debian/rules
+++ b/debian/rules
@@ -2,3 +2,6 @@
%:
dh $@
+
+override_dh_auto_test:
+ MANIFEST_WARN_ONLY=1 dh_auto_test
#v-
Not sure if it's the best way ...
Cheers,
gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/
`. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe
`- NP: Dire Straits: Tunnel Of Love
signature.asc
Description: Digital Signature
Bug#796894: RFS: afl/1.86b-1 -- fuzzy tester for binary formats [ITA]
Package: sponsorship-requests Severity: normal Hi, I'm looking for an uploader for my new package of American Fuzzy Lop (afl), which is on ITA [1]. The package is Git-ized here: http://anonscm.debian.org/cgit/collab-maint/afl.git Build log: http://www.danielstender.com/buildlogs/afl_1.86b-1_amd64-20150825-1547.build Mentors upload: http://mentors.debian.net/debian/pool/main/a/afl/afl_1.86b-1.dsc Due to problems with clang-3.5 on arm64 [2] I've disabled the build for this arch temporarily, as Jakub suggested to do. Gianfranco has found out that the package builds again fine with = clang-3.7. When this is in I want to prepare a -2 for experimental patched for llvm-toolchain-3.7 for those really need this on arm64. [1] https://bugs.debian.org/786806 ITA: afl -- instrumentation-driven fuzzer for binary formats [2] https://bugs.debian.org/796343 clang-3.5: [arm64] segfault in 'Greedy Register Allocator' -- http://www.danielstender.com/blog/ 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
Bug#796896: Lintian is requesting python-*-dbgsym to be in section python
Package: lintian Version: 2.5.36.1 Severity: normal When enabling the brand new automatic debug packages, one get lintian warnings such as: W: python-rrdtool-dbgsym: wrong-section-according-to-package-name python-rrdtool-dbgsym = python N: N:This package has a name suggesting that it belongs to a section other N:than the one it is currently categorized in. N: N:Severity: normal, Certainty: possible N: N:Check: fields, Type: binary, udeb, source N: Automatic debug symbols packages should not be in python section, this is a false positive. My guess is that the generated DEBIAN/control with Section: debugsym is correct. -- Nirgal
Bug#796894: RFS: afl/1.86b-1 -- fuzzy tester for binary formats [ITA]
❦ 25 août 2015 14:46 GMT, Gianfranco Costamagna costamagnagianfra...@yahoo.it : 1) please don't set architectures fields that way. Either choose !arm64 (it should work) or (in my opinion the best way) leave any. When llvm will transition (and it should transition as soon as gcc is sorted out), a simple binNMU will make it build, without any source upload. So since the problem is actually related to another package I would prefer to build and fail rather than avoid the build (specially because it takes some seconds to build) 2) afl-clang.install do you really need to install .o files? README.experiments and persistent_demo might belong to dh_installexamples or dh_installdocs or similar (same for afl.install) Well, sorry for missing those. I already did the upload. -- Debian package sponsoring guidelines: http://vincent.bernat.im/en/debian-package-sponsoring.html signature.asc Description: PGP signature
Bug#796892: ftp.debian.org: Broken Sources.bz2 file for at least 3 repositories
Package: ftp.debian.org Severity: grave tracker.debian.org has been failing to import new source packages for 4 days. I have such failures during apt-get update: [...] FetchFailedException: W:Failed to fetch file:/srv/mirrors/debian/dists/jessie-backports/main/source/Sources Hash Sum mismatch , W:Failed to fetch file:/srv/mirrors/debian/dists/jessie-backports/non-free/source/Sources Hash Sum mismatch , W:Failed to fetch file:/srv/mirrors/debian/dists/proposed-updates/main/source/Sources Hash Sum mismatch , E:Some index files failed to download. They have been ignored, or old ones used instead. Double checking everything with the corresponding Release file I noticed this: The size/checksums of the uncompressed Sources entry does not match the file that you get when you uncompress the .bz2 file. When you uncompress the .xz file then you have the expected content and it matches the data of the uncompressed entry in Release. In both cases, the size/checksum of the .bz2 and .xz file matches the data from the Release file. hertzog@ticharich:/srv/tracker.debian.org/distro-tracker$ bzip2 -dc /srv/mirrors/debian/dists/proposed-updates/main/source/Sources.bz2 /tmp/Sources hertzog@ticharich:/srv/tracker.debian.org/distro-tracker$ md5sum /tmp/Sources a1d3ad43e13bf3bd1ffc9a25b572c17a /tmp/Sources hertzog@ticharich:/srv/tracker.debian.org/distro-tracker$ grep main/source/Sources$ /srv/mirrors/debian/dists/proposed-updates/Release 653093668be2c8f6cb884a553c7ab7bf 430108 main/source/Sources 39e40dd8616c7819bbb20486015766d440832afc 430108 main/source/Sources 033f74594208451e9fdb9083608b5fe43d00444e8ee4aaf2e04b1332b6b6002d 430108 main/source/Sources hertzog@ticharich:/srv/tracker.debian.org/distro-tracker$ ls -l /tmp/Sources -rw-r--r-- 1 hertzog Debian 418824 août 25 13:23 /tmp/Sources hertzog@ticharich:/srv/tracker.debian.org/distro-tracker$ xz -dc /srv/mirrors/debian/dists/proposed-updates/main/source/Sources.xz /tmp/Sources hertzog@ticharich:/srv/tracker.debian.org/distro-tracker$ ls -l /tmp/Sources -rw-r--r-- 1 hertzog Debian 430108 août 25 13:40 /tmp/Sources hertzog@ticharich:/srv/tracker.debian.org/distro-tracker$ md5sum /tmp/Sources 653093668be2c8f6cb884a553c7ab7bf /tmp/Sources So it looks like the Sources.bz2 is stale for a few repositories...
Bug#796897: xtitle does not need xterm as it works fine remotely
Package: xtitle Version: 1.0.2-6 The xtitle executable does not need xterm, as it works fine remotely (e.g., in an ssh session), so the Requires: xterm ... is much too strong. I'd suggest a gentle Enhances: xterm ... --Barak. -- Barak A. Pearlmutter ba...@pearlmutter.net Dept Comp Sci Hamilton Institute, Maynooth University, Co. Kildare, Ireland http://barak.pearlmutter.net
Bug#796807: jackd2: please make the build reproducible
On 08/24/15 18:46, Chris Lamb wrote: Source: jackd2 Version: 1.9.10+20140719git3eb0ae6a~dfsg-3 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org The attached patch removes locale and timezone-varying timestamps from the build system. Once applied, jackd2 can be built reproducibly in our reproducible toolchain. Thanks, applied. Next upload will fix it. Cheers
Bug#786913: Bug#794583: ocaml: Allow setting arbitrary RNG seed in ocamlopt
Le 04/08/2015 18:41, Valentin Lorentz a écrit : While working on the “reproducible builds” effort [1], we have noticed that ocamlopt relies on temporary files whose names are generated randomly and are part of the output files' symbols. See #795784, #796336 and #786913. Therefore, we need a way to make these names determinist. [...] I don't agree with this conclusion; I'd rather use a way to not record those random names in the first place, or set them to some sane value without messing with file names. GCC also uses temporary files whose names are generated randomly (this can be seen with the -v option). But it arranges for these random names to not appear in compiled objects. For example, with assembly files, the name of the source file (which is then recorded in compiled objects) can be given with a .file directive. gcc adds them to its assembly files. And adding such directives to assembly files generated by ocamlopt solves #795784 and #796336. For #786913, temporary files are C files. Ideally, a .file counterpart should exist for C files (I thought of #line cpp directives, but they don't work... maybe we should make them work?). However, I've found a way to tell gcc to not record the file name, using stdin: gcc -x c -c -o foo.o foo.c. I would very much prefer a .file-like directive, though. [...] For instance, reading an environment variable in the main function of ocamlopt (driver/optmain.ml) and calling “Random.seed 0” if it is set would be perfect. Using OCAMLPARAM (driver/compenv.ml) would work as well. I am not thrilled by this proposition. Filename.temp_file is the equivalent of mkstemp, and mkstemp doesn't have this feature. Cheers, -- Stéphane
Bug#788926: lintian: regex deprecation warnings with perl 5.22
On 2015-08-25 15:39, Dominic Hargreaves wrote: Control: retitle -1 lintian: FTBFS with perl 5.22: test failures/regex deprecation warnings [...] Hi, Here is the full build log from lintian under perl 5.22. Apologies it's taken so long to get to this. Do let me know if the perl team can help out with this. Cheers, Dominic. Hi, Did you perhaps omit an attachment? Thanks, ~Niels
Bug#788926: lintian: regex deprecation warnings with perl 5.22
On Tue, Aug 25, 2015 at 04:00:41PM +0200, Niels Thykier wrote: On 2015-08-25 15:39, Dominic Hargreaves wrote: Control: retitle -1 lintian: FTBFS with perl 5.22: test failures/regex deprecation warnings [...] Hi, Here is the full build log from lintian under perl 5.22. Apologies it's taken so long to get to this. Do let me know if the perl team can help out with this. Cheers, Dominic. Hi, Did you perhaps omit an attachment? *sigh* yep. Here we go. Dominic. lintian_2.5.36.1_amd64-20150822-1436.build.gz Description: Binary data
Bug#792053: prometheus: FTBFS w/ test suite errors
found 792053 0.15.1+ds-1 notfixed 792053 0.15.1+ds-1 thanks Aaron M. Ucko u...@debian.org writes: Builds of prometheus on those architectures on which its build dependencies are available (so far just armel, armhf, and i386, aside from amd64) have been failing with assorted test suite errors: I'm happy to confirm that 0.15.1+ds-1 fixes the original errors. However, new ones have cropped up, per https://buildd.debian.org/status/logs.php?pkg=prometheusver=0.15.1%2Bds-1 : TestEvictAndLoadChunkDescsType0 fails on armhf, and TestEvictAndLoadChunkDescsType1 fails on armel and i386. Could you please take another look? Incidentally, I did not explicitly request an update to a new upstream release (though I certainly don't object!), so best practice would have been to note in the changelog what this bug report was actually about. You'll get a chance yet. ;-) Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#727096: uscan: debian/upstream/signing-key.pgp debian/upstream/signing-key.asc debian/upstream-signing-key.pgp
Hi,
On Sun, Aug 23, 2015 at 10:13:04AM -0400, James McCoy wrote:
On Aug 23, 2015 9:33 AM, Osamu Aoki os...@debian.org wrote:
Hi,
Its been almost 2 years.
As I read the source of the current uscan of version 2.15.3, around L865:
$keyring = first { -r $_ }
qw(debian/upstream/signing-key.pgp debian/upstream/signing-key.asc
debian/upstream-signing-key.pgp);
So your requested feature is practically there.
Not really. This is looking for the keyring which is used to verify the
signature. Ansgar wants uscan to be able to perform verification after the
fact, using a cached signature stored in debian/upstream.
Thanks for explanation.
That should really be a separate tool, which uscan could then use to do on the
fly checking. I thought dkg may have also discussed having the signature
stored somewhere, but maybe I'm misremembering.
I see.
Osamu
Bug#796894: RFS: afl/1.86b-1 -- fuzzy tester for binary formats [ITA]
Control: owner -1 ! Control: tag -1 moreinfo Hi Daniel some issues I found: 1) please don't set architectures fields that way. Either choose !arm64 (it should work) or (in my opinion the best way) leave any. When llvm will transition (and it should transition as soon as gcc is sorted out), a simple binNMU will make it build, without any source upload. So since the problem is actually related to another package I would prefer to build and fail rather than avoid the build (specially because it takes some seconds to build) 2) afl-clang.install do you really need to install .o files? README.experiments and persistent_demo might belong to dh_installexamples or dh_installdocs or similar (same for afl.install) 3) patches directory might be removed 4) rules: using plain dh calls might be better :) 5) watch: you might want to look for common tarball extensions rather than only tgz (acually just a nitpick) cheers, G.
Bug#796891: libvtk6-dev: Reference to non-existant vtkGUISupportQtModule.h in /usr/include/vtk-6.2/QVTKWidget.h
I think the second option should be better. Anton 2015-08-25 16:49 GMT+02:00 Scott Kitterman deb...@kitterman.com: So does that mean that libvtk6-dev should depend on libvtk6-qt-dev or perhaps /usr/include/vtk-6.2/QVTKWidget.h should move there as well? Scott K On Tuesday, August 25, 2015 04:26:23 PM Anton Gladky wrote: It is in libvtk6-qt-dev [1]. [1] https://packages.debian.org/sid/amd64/libvtk6-qt-dev/filelist Anton 2015-08-25 15:44 GMT+02:00 Scott Kitterman deb...@kitterman.com: Package: libvtk6-dev Version: 6.2.0+dfsg1-3 Severity: grave Tags: upstream Justification: renders package unusable I was trying to build a newer version of gammaray locally to see if it would build with vtk6 and the build failed with this error: In file included from /tmp/buildd/gammaray-2.3.0/plugins/objectvisualizer/vtkwidget.h:31:0, from /tmp/buildd/gammaray-2.3.0/plugins/objectvisualizer/objectvisualizerwidget.cpp:30: /usr/include/vtk-6.2/QVTKWidget.h:39:55: fatal error: vtkGUISupportQtModule.h: No such file or directory compilation -- debian-science-maintainers mailing list debian-science-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#796894: RFS: afl/1.86b-1 -- fuzzy tester for binary formats [ITA]
❦ 25 août 2015 17:05 +0200, Daniel Stender deb...@danielstender.com : I don't see any obvious problem. Did you already contact Jakub about this RFS? It's always easier for the previous maintainer to check a new upload. I would also suggest to move the package to a more modern packaging by using dh (but this could be done at a later point). Hi Vincent, I've taken over a very huge portion of my packages from him and as far as I know he's always glad if somebody else could sponsor/upload it, he said something like no need to RFA otherwise. ... further, I've seen that the package became even orphaned. So, if you like, welcome! :-) OK, uploaded. And I say it again, it would be better if the package was converted to dh at some point. -- Debian package sponsoring guidelines: http://vincent.bernat.im/en/debian-package-sponsoring.html signature.asc Description: PGP signature
Bug#747412: uscan: option to verify current upstream tarball
On Sun, Aug 23, 2015 at 04:34:19PM +0200, Paul Wise wrote: On Sun, 2015-08-23 at 22:45 +0900, Osamu Aoki wrote: This should do: uscan: option to *download* current upstream tarball Just downloading the tarball for the current upstream version does not verify the tarball that is on disk already against the one downloaded for the current upstream version. True. Do you still think we need to add more feature to uscan? Yes. OK. I think you do not mind accessing web page itself but you wish to just only download PGP file. Regards, Osamu PS: I am too spoiled for bandwidth ... Excuse me.
Bug#789826: ignition-math2: FTBFS: test suite fails on some platforms
found 789826 2.2.2+dfsg1-1 notfixed 789826 2.2.2+dfsg1-1 thanks Aaron M. Ucko u...@debian.org writes: Builds of ignition-math2 wound up failing with test suite errors on a few platforms: 2.2.2+dfsg1-1 indeed fixed the UNIT_Line2_TEST errors in *i386, but still encountered test suite errors on armel and mips; could you please take another look? https://buildd.debian.org/status/logs.php?pkg=ignition-math2ver=2.2.2%2Bdfsg1-1 Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#796898: python-pykmip: Remove Depends and Build-Depends on python3-enum34
Source: python-pykmip Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, python-pykmip currently includes Depends and Build-Depends on python3-enum34. This package is incompatible with Python 3.5 and unnecessary for Python 3.4 since the stdlib already contains the package 'enum' which is the importable name in both cases. python3-enum34 has been removed from the archive for Stretch. Please remove these dependencies. - -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJV3IcfAAoJEBJutWOnSwa/410QAKa0jrDH00Ai6zy8cZxTDBuh qwj8uitaWj0TbksidBin17O7Fbu+5rVyCVNZSCc4gutv+WlOMZRoXWWyUuOeonZX HmQsMGTkBFCdVvWehiENjtlTcR1olTZZtDBL6EHFr54r5r+qNqPBaLx6cgf6c+xP 8C0jSegRT/PHbC5qNfghJ/7B2DoknQLG0A9MBp9NYS8RMjUXQ2ChomGw0TigQgt1 RV+AdNnviAilJZ+9rOlUn9LyUjctl1mqaYluOkD/21KOGlK/861H1fiaNoAZWnGx ICkYwLARAj4MWPUWOdIMnKr/3cJzsfiqrd481JI3pmNGI8ubHAndJoBzFA2M4j9D s7AkgHE4nSaTW/rRvaI5v2L3mPcPq3xbAuB6rcpUqLr3HxX/aKKV9GOKH5+tem18 qQYhx7LtiF7OuWfq5GlpoWhI6FIygGI8nLG3gO1QauxLJpVNaLiHS41AilXY1SRz uBcCj/+DI+dFEn5UVwn4F4meGR+BduFknNidXh9TcZQ7VpHwef4N7JqsWIQBZar6 yolb/ZQbYZw0rB+ixhdH9HY+2l88aY+S91aNkPbsv56ANydiTwSog+xppdrzKxvC 9IYyGQcRM2CB4MgGScDxQtnKYlXhgdEonxcQ6R9/hLj/BEgxl96N5dlgr8SyRqco dW/lHbxPQvY0IlyR7sEH =FdaX -END PGP SIGNATURE-
Bug#794321: codespell manpage: inconsistent formatting of options
Hi Peter! * Peter Spiess-Knafl d...@spiessknafl.at, 2015-08-14, 20:54: This inconsistency comes from using the combination of python's argparse and help2man. The alternative would be to generate it once and fix the errors, but than additionally options might be out of sync with the program. Yes, which is why it'd be best if it was upstream who keeps the manpage up to date. :) Using sed to fix the errors would make the manpage creation kind of complicated. What do you think? IMO, help2man is too brittle to be used at build time. It might be good enough to create an initial manpage quickly, but that's it. -- Jakub Wilk
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On 25-08-15 09:09, Tomasz Buchert wrote: Hi, do you understand this lintian warning about incomplete translation? It complains about the templates file, it looks strange to me. I believe it complains that there are no translations for the debconf templates yet. I'm not sure how to get translations for a package that isn't in the archive yet though, a quick search revealed only workflows for existing packages. Cheers, Oxan
Bug#796428: libur-perl: FTBFS with perl 5.22: test failures
On Fri, 21 Aug 2015 22:21:02 +0200, Dominic Hargreaves wrote: Source: libur-perl Version: 0.430-3 Severity: important User: debian-p...@lists.debian.org Usertags: perl-5.22-transition Tags: sid stretch patch fixed-upstream Forwarded: https://github.com/genome/UR/issues/40 This package FTBFS with perl 5.22 (currently in experimental): Test Summary Report --- t/URT/t/04e_file_track_open_close.t (Wstat: 65280 Tests: 8 Failed: 1) Failed test: 8 Non-zero exit status: 255 Parse errors: Bad plan. You planned 100 tests but ran 8. t/URT/t/13e_messaging_format_string.t (Wstat: 768 Tests: 12 Failed: 3) Failed tests: 3, 7, 11 Non-zero exit status: 3 Files=251, Tests=8340, 371 wallclock secs ( 1.97 usr 2.49 sys + 313.05 cusr 28.25 csys = 345.76 CPU) The new upstream release 0.44 fixes at least one of these test failures. Interesting, with 0.430-3 I only get the second one (which is fixed upstream). After importing 0.440 into git it also builds with perl 5.22, so I'm closing the bug in the changelog. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Dire Straits: Planet Of New Orleans signature.asc Description: Digital Signature
Bug#796736: mirror listing update for mirrors.mit.edu
Control: tag -1 +moreinfo Hello, This ticket has been opened as a submission update however there is no mirrors.mit.edu on the official mirrors list. May I assume this is a new submission? The http://mirrors.mit.edu/debian/ directory does not display the README.html file for the directory listing. Otherwise everything looks fine. Could you please clarify and check your configuration? Best regards, Donald Norwoo On Sun, 23 Aug 2015 19:24:28 + MIT SIPB Mirrors Maintainers mirr...@mit.edu wrote: Package: mirrors Severity: minor Submission-Type: update Site: mirrors.mit.edu Type: leaf Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc Archive-ftp: /debian/ Archive-http: /debian/ Archive-rsync: debian/ Backports-ftp: /debian-backports/ Backports-http: /debian-backports/ Backports-rsync: debian-backports/ IPv6: no Archive-upstream: debian.gtisc.gatech.edu Backports-upstream: debian.gtisc.gatech.edu Updates: four Maintainer: MIT SIPB Mirrors Maintainers mirr...@mit.edu Country: US United States Location: Cambridge, MA, USA Sponsor: MIT Student Information Processing Board http://sipb.mit.edu/ Comment: 1 Gbps uplink signature.asc Description: OpenPGP digital signature
Bug#793604: gammaray: FTBFS against VTK 6.2
On Sat, 25 Jul 2015 15:17:40 +0200 Andreas Beckmann a...@debian.org wrote: Source: gammaray Version: 2.2.1-1 Severity: serious Justification: fails to build from source (but built successfully in the past) As can be seen on https://buildd.debian.org/status/package.php?p=gammaraysuite=unstable gammaray does no longer build against VTK 6.2 and had test failures on many platform on the last attempt that still used VTK 6.1 The immediate problem in the bug is solved by adding libvtk6-qt-dev to build- depends, but I'm unsure about getting the package to build, so I'll leave it and work on something else. Scott K
Bug#640303: python-pdfminer: Please package latest upstream
On Thursday 06 August 2015 12:49:56 Daniele Tricoli wrote: I will ping stefanor once the package is ready. A quick update: stefanor will look at my RFS. I just talked to him on IRC. Kind regards, -- Daniele Tricoli 'eriol' https://mornie.org signature.asc Description: This is a digitally signed message part.
Bug#777601: systemd: Loosing LXC memory cgroups after service install
On Tue, 25 Aug 2015 18:41:59 +0200 Luca Bruno lethalma...@gmail.com wrote: I've tried this patch and looks like adding another bug to me. Please confirm what I'm experiencing. It's true, it does not remove cgroups created by systemd, but then it doesn't cleanup cgroups that systemd created either. Correction, sorry for the confusing wording: It's true, it does not remove cgroups *not* created by systemd, but then it doesn't cleanup cgroups that systemd created either.
Bug#728710: jackd2: Bus error w/ POST_PACKED_STRUCTURE on powerpc G4 32bit
On 05/15/15 01:27, Martin Langer wrote: Hi, Hi! I run into the same bus error with a freshly installed jessie on my powerpc (1GHz Powerbook, G4). Nevertheless this small patch fixes the bus error and jack is running fine now with jessie. Thanks for reporting back. I've applied the patch to upstream jackd2, it will be included when we sync the next time (we just synced today prior to inclusion). Upstream commit: https://github.com/jackaudio/jack2/commit/460063d8dc2cb465e22fd538239817a0cb0baec6 Cheers
Bug#766993: jackd2: FTBFS with DEB_BUILD_PARALLEL=1 DEB_BUILD_OPTIONS=parallel=4
On 10/27/14 16:24, Jonas Smedegaard wrote: Quoting YunQiang Su (2014-10-27 15:16:44) On Mon, Oct 27, 2014 at 9:58 PM, Jonas Smedegaard d...@jones.dk wrote: If I understand your patch correctly (have only read it briefly) the first lines are better written without making shell calls, like this: WAF_EXTRA_ARGS = $(filter-out -j%,$(DEB_MAKE_EXTRA_ARGS)) WAF_JOBS = $(filter -j%,$(DEB_MAKE_EXTRA_ARGS)) Yes, using functions from make should be better. ...and even better by using underlying variable instead of extracting from DEB_MAKE_EXTRA_ARGS. I am not very familiar with cdbs, so no idea about it. Fully understood, and not a problem: I just mention for the record, in case someone would want to dive in and refine even further :-) I do expect your original patch to work fine - all of this is just suggestions for improvements. Thanks, again, for your reporting this issue and providing a patch! I know I'm late by ~10 months, but did you ultimately apply anything? :) Cheers
Bug#796905: python3-matplotlib: Matplotlib startup feels extremely slow
Package: python3-matplotlib
Version: 1.4.2-3.1
Severity: normal
[ Apologies if this is a duplicate. I've submitted this yesterday already, but
never got an email confirmation nor does the bug show up on bugs.debian.org ]
Since upgrading from Wheezy, the startup of matplotlib seems extremely slow.
Scripts that previously appeared to show results instantanously now take
multiple seconds until the first plot appears.
I tried debugging this with a very simple test script:
#!/usr/bin/env python3
import matplotlib.pyplot as plt
plt.plot([1, 2, 3])
plt.show()
Looking at the strace output, I found a large number of seemingly
completely pointless lseek() calls. For example:
open(/usr/lib/python3.4/encodings/__pycache__/unicode_escape.cpython-34.pyc,
O_RDONLY|O_CLOEXEC) = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=1842, ...}) = 0
lseek(8, 0, SEEK_CUR) = 0
fstat(8, {st_mode=S_IFREG|0644, st_size=1842, ...}) = 0
read(8,
\356\f\r\n\240#5T\240\4\0\0\343\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0@\0\0...,
1843) = 1842
read(8, , 1) = 0
close(8)= 0
open(/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf, O_RDONLY|O_CLOEXEC) = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=741536, ...}) = 0
ioctl(8, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
0x7ffe52ac0a90) = -1 ENOTTY (Inap
fstat(8, {st_mode=S_IFREG|0644, st_size=741536, ...}) = 0
lseek(8, 0, SEEK_CUR) = 0
fcntl(8, F_DUPFD_CLOEXEC, 0)= 9
fcntl(9, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat(9, {st_mode=S_IFREG|0644, st_size=741536, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5403f06000
lseek(9, 0, SEEK_CUR) = 0
lseek(8, 0, SEEK_CUR) = 0
lseek(9, 0, SEEK_SET) = 0
fstat(9, {st_mode=S_IFREG|0644, st_size=741536, ...}) = 0
lseek(9, 741376, SEEK_SET) = 741376
read(9, +\0++..., 160) = 160
lseek(9, 0, SEEK_SET) = 0
lseek(9, 0, SEEK_SET) = 0
lseek(9, 0, SEEK_SET) = 0
read(9, \0\1\0\0\0\23\1\0\0\4\FFTMh\275QN\0\0\1\0\0\0\34GDEF..., 4096) =
4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
[...]
Note that there are no other syscalls between the lseek() - Python simply seeks
to the same position over and over again. I am not 100% sure that
this is the cause of the slow-down, but it certainly looks like
something is wrong here.
$ strace -o log python3 test.py
$ grep lseek log | wc -l
1871
$ strace -o log python3 -c 'print(Hello)'
Hello
$ grep lseek log | wc -l
31
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages python3-matplotlib depends on:
ii libc6 2.19-18
ii libfreetype62.5.2-3
ii libgcc1 1:4.9.2-10
ii libjs-jquery1.7.2+dfsg-3.2
ii libjs-jquery-ui 1.10.1+dfsg-1
ii libpng12-0 1.2.50-2+b2
ii libstdc++6 4.9.2-10
ii libtcl8.6 8.6.2+dfsg-2
ii libtk8.68.6.2-1
ii python-matplotlib-data 1.4.2-3.1
ii python3 3.4.2-2
ii python3-dateutil2.2-2
ii python3-nose1.3.4-1
ii python3-numpy [python3-numpy-abi9] 1:1.8.2-2
ii python3-pyparsing 2.0.3+dfsg1-1
ii python3-six 1.8.0-1
ii python3-tz 2012c+dfsg-0.1
Versions of packages python3-matplotlib recommends:
ii python3-pil 2.6.1-2
ii python3-tk 3.4.2-1+b1
Versions of packages python3-matplotlib suggests:
pn dvipngnone
ii ghostscript 9.06~dfsg-2+deb8u1
ii gir1.2-gtk-3.03.14.5-1
ii inkscape 0.48.5-3
ii ipython3 2.3.0-2
ii librsvg2-common 2.40.5-1
ii python-matplotlib-doc 1.4.2-3.1
pn python3-cairocffi none
ii python3-gi [python3-gobject] 3.14.0-1
ii python3-gi-cairo 3.14.0-1
ii python3-pyqt4
Bug#795976: sphinx: please make the build reproducible (timestamps, randomness)
Hi,
I can't reproduce the unreproducibility on my computer.
However, reading debian/rules, I think setting PYTHONHASHSEED=0 when
calling dh_sphinxdoc should work. Actually, modifying dh_sphinxdoc to
set this variable may be better (in case someone copy-pastes it to their
own package).
If it does not work, try the attached package.
On 25/08/2015 14:13, Dmitry Shachnev wrote:
Hi Val,
Looks like my latest upload is still not reproducible: the debbindiff [1]
reports differing contents of searchindex.js.
Do you know if this can be fixed by yet another PYTHONHASHSEED=0 setting,
or this is more complicate?
[1]:
https://reproducible.debian.net/dbd/unstable/amd64/sphinx_1.3.1-5.debbindiff.html
--
Dmitry Shachnev
diff -u -r sphinx-1.3.1.old/sphinx/search/__init__.py sphinx-1.3.1/sphinx/search/__init__.py
--- sphinx-1.3.1.old/sphinx/search/__init__.py 2015-08-25 12:52:11.119163557 +
+++ sphinx-1.3.1/sphinx/search/__init__.py 2015-08-25 13:11:28.671207670 +
@@ -259,9 +259,9 @@
rv = {}
otypes = self._objtypes
onames = self._objnames
-for domainname, domain in iteritems(self.env.domains):
+for domainname, domain in sorted(iteritems(self.env.domains)):
for fullname, dispname, type, docname, anchor, prio in \
-domain.get_objects():
+sorted(domain.get_objects()):
# XXX use dispname?
if docname not in fn2index:
continue
signature.asc
Description: OpenPGP digital signature
Bug#795270: coreutils: df does not display all nfs mounts for the same mount points
Re: coreutils 8.21 These mount points are different as are the targets: loui-nac01:/vol/vol_pdbuild /srv/builds nfs defaults,nosuid 0 0 loui-nac01:/vol/vol_archive /srv/archives nfs defaults,nosuid 0 0 Yet the latest df doesn't show them both: df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/hoth--vg-root117G 2.7G 109G 3% / /dev/sda1236M 39M 186M 18% /boot loui-nac01:/vol/vol_pdbuild 5.0T 4.3T 740G 86% /srv/builds So the logic to get rid of duplicates is too aggressive. Using df -a the second mount point shows: df -ha Filesystem Size Used Avail Use% Mounted on /dev/mapper/hoth--vg-root117G 2.7G 109G 3% / /dev/sda1236M 39M 186M 18% /boot loui-nac01:/vol/vol_archive 6.5T 5.8T 741G 89% /srv/archives loui-nac01:/vol/vol_pdbuild 5.0T 4.3T 741G 86% /srv/builds Please fix. Thanks.
Bug#777601: systemd: Loosing LXC memory cgroups after service install
Control: unarchive -1 On Thu, 12 Feb 2015 15:43:30 +0100 Martin Pitt mp...@debian.org wrote: Hello again, so the patch that got proposed at http://lists.freedesktop.org/archives/systemd-devel/2014-September/023276.html actually makes a lot of sense: This makes systemd only clean up cgroups that it created by itself, and thus won't clean up empty ones in other controllers that LXC created. I tested this and committed this for the experimental branch for now: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimentalid=286ef78fd I'd like to see this out in the wild for some time before applying it to jessie, though. I'm also still interested in what the actual impact of that is -- critical seems rather inflated? Losing empty cgroups doesn't sound that dangerous after all, aside from the LXC warnings when shutting down a container? Thanks, I've tried this patch and looks like adding another bug to me. Please confirm what I'm experiencing. It's true, it does not remove cgroups created by systemd, but then it doesn't cleanup cgroups that systemd created either. Example: 1) set MemoryLimit to a service, the memory limit will appear in the cgroups 2) unset MemoryLimit to the same service, reload daemon, restart, disable, re-enable, whatever... but the memory limit will NOT disappear from the cgroups Seems wrong and possibly worse to me. Best regards,
Bug#796874: gtkspellmm: transition needed for g++-5 ABI
Hi Simon, thanks again for taking care of this transition - it's really appreciated! I think I fixed the package, could you have a look and sponsor it if it fits for you? http://anonscm.debian.org/cgit/collab-maint/gtkspellmm.git Thanks, Philip signature.asc Description: OpenPGP digital signature
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On 25/08/15 17:59, Oxan van Leeuwen wrote: On 25-08-15 09:09, Tomasz Buchert wrote: Hi, do you understand this lintian warning about incomplete translation? It complains about the templates file, it looks strange to me. I believe it complains that there are no translations for the debconf templates yet. I'm not sure how to get translations for a package that isn't in the archive yet though, a quick search revealed only workflows for existing packages. Cheers, Oxan I've added Polish translation and the lintian tag is gone. The package is now uploaded and will hit NEW queue soon. Thanks for your patience! :D Tomasz signature.asc Description: Digital signature
Bug#796422: libopengl-image-perl: FTBFS: perl5/5.20/auto/OpenGL/OpenGL.so: undefined symbol: glResizeBuffersMESA
Control: tag -1 + confirmed Control: block -1 with 795741 On Fri, 21 Aug 2015 20:57:34 +0100, Chris Lamb wrote: Source: libopengl-image-perl Version: 1.03-1 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, libopengl-image-perl fails to build from source in unstable/amd64: [..] make -j1 test TEST_VERBOSE=1 make[1]: Entering directory '/tmp/buildd/libopengl-image-perl-1.03' PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -MTest::Harness -e undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch') t/*.t Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.20/auto/OpenGL/OpenGL.so' for module OpenGL: /usr/lib/x86_64-linux-gnu/perl5/5.20/auto/OpenGL/OpenGL.so: undefined symbol: glResizeBuffersMESA at /usr/lib/x86_64-linux-gnu/perl/5.20/DynaLoader.pm line 187. at t/OpenGL-Image.t line 3. Compilation failed in require at t/OpenGL-Image.t line 3. BEGIN failed--compilation aborted at t/OpenGL-Image.t line 3. t/OpenGL-Image.t .. Dubious, test returned 2 (wstat 512, 0x200) No subtests run This looks like fallout from / a duplicate of #795741. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Rolling Stones: Catfish signature.asc Description: Digital Signature
Bug#796906: fails to build stage1 cross compiler for m68k
Source: gcc-5 Tags: patch User: helm...@debian.org Usertags: rebootstrap m68k implements does not have hardware supported atomics, so it falls back to linux syscalls to implement atomics on that architecture even when one builds a stage1 (without libc). However the Build-Depends do not reflect that. Building the stage1 cross compiler for m68k without linux-libc-dev installed results in the following error: From https://jenkins.debian.net/job/rebootstrap_m68k_gcc5/27/console | /tmp/buildd/gcc1/gcc-5-5.2.1/build/./gcc/xgcc -B/tmp/buildd/gcc1/gcc-5-5.2.1/build/./gcc/ -B/usr/m68k-linux-gnu/bin/ -B/usr/m68k-linux-gnu/lib/ -isystem /usr/m68k-linux-gnu/include -isystem /usr/m68k-linux-gnu/sys-include -isystem /tmp/buildd/gcc1/gcc-5-5.2.1/build/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fPIC -I. -I. -I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/. -I../../../src/libgcc/../gcc -I../../../src/libgcc/../include -DHAVE_CC_TLS -o linux-atomic.o -MT linux-atomic.o -MD -MP -MF linux-atomic.dep -c ../../../src/libgcc/config/m68k/linux-atomic.c -fvisibility=hidden -DHIDE_EXPORTS | ../../../src/libgcc/config/m68k/linux-atomic.c:36:24: fatal error: asm/unistd.h: No such file or directory | compilation terminated. | ../../../src/libgcc/static-object.mk:17: recipe for target 'linux-atomic.o' failed | make[4]: *** [linux-atomic.o] Error 1 | make[4]: Leaving directory '/tmp/buildd/gcc1/gcc-5-5.2.1/build/m68k-linux-gnu/libgcc' | Makefile:10662: recipe for target 'all-target-libgcc' failed | make[3]: *** [all-target-libgcc] Error 2 | make[3]: Leaving directory '/tmp/buildd/gcc1/gcc-5-5.2.1/build' | Makefile:852: recipe for target 'all' failed | make[2]: *** [all] Error 2 | make[2]: Leaving directory '/tmp/buildd/gcc1/gcc-5-5.2.1/build' | s=`cat status`; rm -f status; test $s -eq 0 | debian/rules2:1169: recipe for target 'stamps/05-build-stamp' failed | make[1]: *** [stamps/05-build-stamp] Error 1 | make[1]: Leaving directory '/tmp/buildd/gcc1/gcc-5-5.2.1' | debian/rules:52: recipe for target 'stamps/05-build-stamp' failed | make: *** [stamps/05-build-stamp] Error 2 I have not seen a similar error for any other architecture. Thus I am proposing to add that dependency just for m68k, which is implemented in the attached patch. Please consider applying it. Helmut diff --git a/debian/control b/debian/control index 0a7807d..c27a523 100644 --- a/debian/control +++ b/debian/control @@ -7,7 +7,7 @@ Standards-Version: 3.9.6 Build-Depends: debhelper (= 5.0.62), dpkg-dev (= 1.17.11), g++-multilib [amd64 i386 kfreebsd-amd64 mips mips64 mips64el mipsel mipsn32 mipsn32el powerpc ppc64 s390 s390x sparc sparc64 x32], g++-4.9 [arm64], libc6.1-dev (= 2.13-5) [alpha ia64] | libc0.3-dev (= 2.13-5) [hurd-i386] | libc0.1-dev (= 2.13-5) [kfreebsd-i386 kfreebsd-amd64] | libc6-dev (= 2.13-5), libc6-dev (= 2.13-31) [armel armhf], libc6-dev-amd64 [i386 x32], libc6-dev-sparc64 [sparc], libc6-dev-sparc [sparc64], libc6-dev-s390 [s390x], libc6-dev-s390x [s390], libc6-dev-i386 [amd64 x32], libc6-dev-powerpc [ppc64], libc6-dev-ppc64 [powerpc], libc0.1-dev-i386 [kfreebsd-amd64], lib32gcc1 [amd64 ppc64 kfreebsd-amd64 mipsn32 mipsn32el mips64 mips64el s390x sparc64 x32], libn32gcc1 [mips mipsel mips64 mips64el], lib64gcc1 [i386 mips mipsel mipsn32 mipsn32el powerpc sparc s390 x32], libc6-dev-mips64 [mips mipsel mipsn32 mipsn32el], libc6-dev-mipsn32 [mips mipsel mips64 mips64el], libc6-dev-mips32 [mipsn32 mipsn32el mips64 mips64el], libc6-dev-x32 [amd64 i386], libx32gcc1 [amd64 i386], libc6.1-dbg [alpha ia64] | libc0.3-dbg [hurd-i386] | libc0.1-dbg [kfreebsd-i386 kfreebsd-amd64] | libc6-dbg, - kfreebsd-kernel-headers (= 0.84) [kfreebsd-any], + kfreebsd-kernel-headers (= 0.84) [kfreebsd-any], linux-libc-dev [m68k], m4, libtool, autoconf2.64, libunwind7-dev (= 0.98.5-6) [ia64], libatomic-ops-dev [ia64], autogen, gawk, lzma, xz-utils, patchutils, diff --git a/debian/control.m4 b/debian/control.m4 index 251b37d..a65f051 100644 --- a/debian/control.m4 +++ b/debian/control.m4 @@ -60,7 +60,7 @@ Standards-Version: 3.9.6 ifdef(`TARGET',`dnl cross Build-Depends: debhelper (= 5.0.62), DPKG_BUILD_DEP LIBC_BUILD_DEP, LIBC_BIARCH_BUILD_DEP - kfreebsd-kernel-headers (= 0.84) [kfreebsd-any], + kfreebsd-kernel-headers (= 0.84) [kfreebsd-any], linux-libc-dev [m68k], LIBUNWIND_BUILD_DEP LIBATOMIC_OPS_BUILD_DEP AUTO_BUILD_DEP SOURCE_BUILD_DEP CROSS_BUILD_DEP ISL_BUILD_DEP MPC_BUILD_DEP MPFR_BUILD_DEP GMP_BUILD_DEP,
Bug#790777: Building with sbuild?
* Jelmer Vernooij jel...@debian.org [2015-08-22 22:45]: Are you building with sbuild? You are possibly hitting http://bugs.debian.org/750593 I was using sbuild but I also see it in a normal chroot. Are you saying you don't see it? -- Martin Michlmayr Linux for HP Helion, Hewlett-Packard
Bug#796903: please support nocheck build profile
tags 796903 + pending thanks Hi! Helmut Grohne wrote: However this does not suffice to build it in a bootstrap setting, because libc0.1-dev is unavailable when kfreebsd-kernel-headers is needed. Thus please mark that dependency with !nocheck. Of course. Thanks. The moving of headers to multiarch paths that you implemented is very useful and fixes bootstrap issues down the road. I would appreciate an upload of ~6 to unstable for this reason alone. I will test reverse depends as quickly as possible and then upload this to unstable. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#779803: smuxi performs autoconnect on first startup
Control: tags 779803 + fixed pending Upstream fix to not reveal realname: https://github.com/meebey/smuxi/commit/f21cc42e087e93f621b1a368770f46e41d6cff2f trivial on purpose in order to not introduce regressions signature.asc Description: OpenPGP digital signature
Bug#777833: digikam: ftbfs with GCC-5 (patch)
tags 777833 patch thanks Hello all, I tried to rebuild digikam on sid today. The current version still misses libsoprano-dev dependency and fails with: make[3]: *** No rule to make target '/usr/lib/libsoprano.so', needed by 'lib/libkvkontakte.so.1.0.0'. Stop. Once a build-time dependency on libsoprano-dev was declared, I was able to compile digikam on a sid sbuild, it linked against the new opencv-*2.4v5 libraries. - Danny diff -Nru digikam-4.4.0/debian/control digikam-4.4.0/debian/control --- digikam-4.4.0/debian/control2014-11-15 17:37:35.0 +0100 +++ digikam-4.4.0/debian/control2015-08-10 14:51:04.0 +0200 @@ -6,6 +6,7 @@ Build-Depends: debhelper (= 9), pkg-kde-tools (= 0.9), pkg-config, cmake (= 2.6.2), doxygen, kdelibs5-dev, kdepimlibs5-dev, + libsoprano-dev, libmarble-dev, libkipi-dev (= 4:4.12), libkexiv2-dev (= 4:4.12), libkdcraw-dev (= 4:4.12), libksane-dev, baloo-dev, libkfilemetadata-dev,
Bug#786429: libjs-bootstrap requires newer (non-packaged) version of jquery
Hello, A newer version of libjs-jquery (1.11.3) as require by bootstrap is available now in Debian unstable. I have tested with this library and Bootstrap Javascript and consequently its menus etc. are working again. -- Sunil signature.asc Description: OpenPGP digital signature
Bug#786737: jackd1: crashes with -n option specified
On 05/25/15 04:53, Frank Heckenbach wrote: Package: jackd1 Version: 1:0.124.1+20140122git5013bed0-3 Severity: normal Tags: upstream patch When the -n option is given, jackd crashes when accessing properties (which it seems to do implicitly for any client, e.g. jack_lsp). Forwarded to jack-devel@. Thanks for both your report and the patch. Cheers
Bug#796903: please support nocheck build profile
Source: kfreebsd-kernel-headers Version: 10.1~6 Severity: wishlist User: helm...@debian.org Usertags: rebootstrap Hi Steven, I see that you already implemented DEB_BUILD_OPTIONS=nocheck in the unreleased version 10.1~6 in SVN. Thank you. However this does not suffice to build it in a bootstrap setting, because libc0.1-dev is unavailable when kfreebsd-kernel-headers is needed. Thus please mark that dependency with !nocheck. The moving of headers to multiarch paths that you implemented is very useful and fixes bootstrap issues down the road. I would appreciate an upload of ~6 to unstable for this reason alone. Helmut
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On 25/08/15 17:59, Oxan van Leeuwen wrote: On 25-08-15 09:09, Tomasz Buchert wrote: Hi, do you understand this lintian warning about incomplete translation? It complains about the templates file, it looks strange to me. I believe it complains that there are no translations for the debconf templates yet. I'm not sure how to get translations for a package that isn't in the archive yet though, a quick search revealed only workflows for existing packages. Cheers, Oxan Ok, I'll upload what we have now. Tomasz signature.asc Description: Digital signature
Bug#795284: troubles with range requests
package apt-cacher reassign 795284 apt thanks I have looked at this some more and I think apt-cacher is following the spec correctly. It seems as if apt-get doesn't realise that the 416 response with the Content-Range denominator equal to the size it already has indicates the file is complete. So I am going to reassign to apt. Apt team, if I have got this analysis wrong, sorry, do point out my error and assign back. Thanks. Mark
Bug#792206: apt-cacher: modifies conffiles (policy 10.7.3): /etc/default/apt-cacher
package apt-cacher notfound 792206 1.7.11 thanks
Bug#777601: systemd: Loosing LXC memory cgroups after service install
Am 25.08.2015 um 18:41 schrieb Luca Bruno: I've tried this patch and looks like adding another bug to me. Please confirm what I'm experiencing. It's true, it does not remove cgroups created by systemd, but then it doesn't cleanup cgroups that systemd created either. Example: 1) set MemoryLimit to a service, the memory limit will appear in the cgroups 2) unset MemoryLimit to the same service, reload daemon, restart, disable, re-enable, whatever... but the memory limit will NOT disappear from the cgroups Seems wrong and possibly worse to me. Please raise your issue upstream -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#796400: [pkg-go] Bug#796400: Bug#796400: golang-github-jacobsa-ratelimit: Non-determistically FTBFS due to unreliable timing in tests
Sure. Are you able to modify the test before running it on the relevant system and find a timing that works reliably? lamby, do I have access to the system on which the tests don’t pass? I fear gaining access to this machine would serve no real purpose; the solution here is not to bump the values so that the test is less flaky - the test would remain non-determistic and thus this bug would remain unresolved IMHO, even though it might be harder to trigger. As a concept, I have no problem with automated solutions to point out potential performance regressions, but having a testsuite that fails non-determinstically is generally perceived to be a Bad Idea in software engineering. Perhaps some sort of switch or environment variable can be introduced to enable them so that they do not get in the way of the regular build. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#796812: (no subject)
Sent from Samsung Mobile
Bug#792555: libc6.1-alphaev67 issue now reported upstream
Control: tags -1 upstream The segfaults resulting from installing libc6.1-alphaev67 on an Alpha ev67 (or better) system have been isolated down to ld reloc sorting causing crashes in glibc as reported upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=18867 I'll leave it for the glibc and binutils maintainers to decide which package the bug should be assigned to. Cheers Michael.
Bug#776727: closed by Johann Felix Soden joh...@debian.org (Bug#776727: fixed in vim-latexsuite 20141116.812-1)
Thanks again for your NMU which accelerated my upload of further changes. NMU..? Where? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#796951: Updating texlive-bin in Jessie
Package: release.debian.org
Tags: jessie
User: release.debian@packages.debian.org
Usertag: pu
Control: submitter -1 Norbert Preining prein...@logic.at
X-Debbugs-Cc: Norbert Preining prein...@logic.at,
debian-tex-ma...@lists.debian.org, Osamu Aoki os...@debian.org
Filing this properly.
On Wed, Aug 26, 2015 at 09:14:04 +0900, Norbert Preining wrote:
Dear Release Team,
I am proposing to update src:texlive-bin in Jessie to a new version.
The version that was released unfortunately is completely broken
when one tries to use Xe(La)TeX with Type1 fonts (this was a side-effect
of switching from libfreetype to harfbuzz).
One of the most prominent examples of a document that does this are
the Debian release-notes.
Building the release-notes on Jessie results in all letters shifted
by one position, that is completely broken documents. See attachement 1,
jessie-original.png as examples.
Unfortunately, the fix for this problem has entered TeX Live upstream
only very recently. For unstable I have fixed this with the recent
upload of 2015.20150524.37493-6 which uses the released TeX Live 2015
sources and includes the TeX Live subversion changes in the dvipdfm-x
subdirectory.
Fixing this in Jessie, which is based on older TeX Live sources,
unfortunately cannot be done by patching, as there have been too
many unrelated changes.
Thus, I have prepared an updated packages that does the following:
* keep the current Jessie sources as is
* include a checkout/tar of the current TeX Live svn dvipdfmx-x
directory which fixes the problem
* on build, replace the buggy dvipdm-x directory with the fixed
one from current TeX Live.
Due to the highly modular build system of TeX Live, this procedure is
safe.
With these packages installed, building the release notes again works
as expected, see attached screenshot 2, jessie-fixed.png.
I am well aware that this is a big change, and that there is no diff
that can be shown (well, I could make a diff between the current dvipdfm-x
and the new one, but that will not help as it is too big).
We have been discussing this extensively on the Debian TeX list,
starting here: https://lists.debian.org/debian-tex-maint/2015/06/msg00159.html
and Osamu Aoki (in Cc) supports the unconvential update
(see https://lists.debian.org/debian-tex-maint/2015/06/msg00206.html)
The updated packages (source and amd64) are available at
deb http://people.debian.org/~preining/TeX/ jessie/
deb-src http://people.debian.org/~preining/TeX/ jessie/
or directly via
dget
http://people.debian.org/~preining/TeX/jessie/texlive-bin_2014.20140926.35254-7.dsc
(all signed with my Debian key)
I include the debdiff between the current source and the proposed
updates (attachment 3). The changes are:
* debian/control:
add dependency on t1utils as t1disasm program is necessary
for the new dvipdfm-x
* debian/rules:
add code to unpack the dvipdmfx tarball and undo the changes on clean
Thanks for consideration
Norbert
PREINING, Norbert http://www.preining.info
JAIST, Japan TeX Live Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
diff -Nru texlive-bin-2014.20140926.35254/debian/changelog
texlive-bin-2014.20140926.35254/debian/changelog
--- texlive-bin-2014.20140926.35254/debian/changelog 2015-01-19
00:04:33.0 +0900
+++ texlive-bin-2014.20140926.35254/debian/changelog 2015-08-26
08:12:58.0 +0900
@@ -1,3 +1,10 @@
+texlive-bin (2014.20140926.35254-7) stable-proposed-updates; urgency=medium
+
+ * update dvipdfmx to a version where Type1 font is fixed
+ * add t1utils (for t1disasm, needed by new dvipdfm*) to dependencies
+
+ -- Norbert Preining prein...@debian.org Wed, 26 Aug 2015 08:12:23 +0900
+
texlive-bin (2014.20140926.35254-6) unstable; urgency=high
* cherrypick security fix for libpng CVE-2015-0973 (Closes: #775673)
diff -Nru texlive-bin-2014.20140926.35254/debian/control
texlive-bin-2014.20140926.35254/debian/control
--- texlive-bin-2014.20140926.35254/debian/control2015-01-19
00:04:33.0 +0900
+++ texlive-bin-2014.20140926.35254/debian/control2015-08-26
08:12:58.0 +0900
@@ -11,7 +11,7 @@
Package: texlive-binaries
Architecture: any
-Depends: libptexenc1 (= ${source:Version}), libptexenc1 (
${source:Version}.1~), libkpathsea6 (= ${source:Version}), libkpathsea6 (
${source:Version}.1~), ${shlibs:Depends}, ${misc:Depends}, tex-common (=
5.02), perl, dpkg (= 1.15.4) | install-info
+Depends: libptexenc1 (= ${source:Version}), libptexenc1 (
${source:Version}.1~), libkpathsea6 (= ${source:Version}), libkpathsea6 (
${source:Version}.1~), ${shlibs:Depends},
Bug#796949: piuparts: Missing Build-Depends on python-lzma
Source: piuparts
Version: 0.65
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Dear Maintainer,
piuparts fails to build from source in unstable/amd64 due
to missing Build-Depends on python-lzma:
[..]
==
ERROR: Failure: ImportError (No module named lzma)
--
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/nose/loader.py, line 420, in
loadTestsFromName
addr.filename, addr.module)
File /usr/lib/python2.7/dist-packages/nose/importer.py, line 47,
in importFromPath
return self.importFromDir(dir_path, fqname)
File /usr/lib/python2.7/dist-packages/nose/importer.py, line 94,
in importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File /tmp/buildd/piuparts-0.65/tests/test_pkgsummary.py, line 8,
in module
import piupartslib.pkgsummary as pkgsummary
File /tmp/buildd/piuparts-0.65/piupartslib/__init__.py, line 22,
in module
import lzma
ImportError: No module named lzma
--
Ran 5 tests in 0.111s
FAILED (errors=5)
Makefile:149: recipe for target 'check' failed
make[1]: *** [check] Error 1
make[1]: Leaving directory '/tmp/buildd/piuparts-0.65'
dh_auto_test: make -j1 check returned exit code 2
debian/rules:7: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
[..]
The full build log is attached or can be viewed here:
https://reproducible.debian.net/logs/unstable/amd64/piuparts_0.65.build1.log.gz
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Tue Aug 25 07:35:51 GMT+12 2015
I: pbuilder-time-stamp: 1440531351
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/unstable-reproducible-base.tgz]
I: creating local configuration
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /dev/shm
I: Mounting /sys
I: policy-rc.d already exists
I: Installing the build-deps
- Attempting to satisfy build-dependencies
- Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team pbuilder-ma...@lists.alioth.debian.org
Description: Dummy package to satisfy dependencies with aptitude - created by
pbuilder
This package was created automatically by pbuilder to satisfy the
build-dependencies of the package being currently built.
Depends: debhelper (= 9.20120909~), python (= 2.7), python-debian,
python-apt, python-distro-info, python-nose, python-debianbts, python-yaml,
python-mox3, asciidoc, git, xmlto
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 20247 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring
anyway as you requested:
pbuilder-satisfydepends-dummy depends on python (= 2.7); however:
Package python is not installed.
pbuilder-satisfydepends-dummy depends on python-debian; however:
Package python-debian is not installed.
pbuilder-satisfydepends-dummy depends on python-apt; however:
Package python-apt is not installed.
pbuilder-satisfydepends-dummy depends on python-distro-info; however:
Package python-distro-info is not installed.
pbuilder-satisfydepends-dummy depends on python-nose; however:
Package python-nose is not installed.
pbuilder-satisfydepends-dummy depends on python-debianbts; however:
Package python-debianbts is not installed.
pbuilder-satisfydepends-dummy depends on python-yaml; however:
Package python-yaml is not installed.
pbuilder-satisfydepends-dummy depends on python-mox3; however:
Package python-mox3 is not installed.
pbuilder-satisfydepends-dummy depends on asciidoc; however:
Package as
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
Building tag database...
The following NEW packages will be installed:
asciidoc{a} ca-certificates{a} distro-info-data{a} docbook-xml{a}
docbook-xsl{a} git{a} git-man{a} libapt-inst1.7{a}
Bug#796948: verbose output documentation does not match actual output
Package: kpartx Version: 0.5.0-7 Severity: normal Man page: kpartx -av disk.img This will output lines such as: loop3p1 : 0 20964762 /dev/loop3 63 Reality: root@darkstar:/home/joeykpartx -avs disk add map loop0p1 (254:0): 0 192512 linear /dev/loop0 2048 It would be helpful if the man page documents that the actual output looks like, at least to the point of documenting that it starts with add map. It may be that the output format has changed since the man page was written. That's worrying. I'm not sure if the verbose output is really intended to be parsed, but there are programs that do parse it (for example, vmdebootstrap). -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kpartx depends on: ii dmsetup 2:1.02.103-1 ii libc6 2.19-19 ii libdevmapper1.02.1 2:1.02.103-1 ii udev223-2 kpartx recommends no packages. kpartx suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#796947: jessie-pu: package s3ql/2.11.1+dfsg-2
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu Dear release managers, Would it be acceptible to upload a fix for #792685 to jessie? In short, the S3QL version currently in jessie is unable to read file system created with the S3QL version in wheezy. All stored data thus becomes inaccessible unless one installs an intermediate version (that is currently not available in Debian). The proposed patch forward-ports the necessary capability from an intermediate S3QL version. An update package can be downloaded from http://mentors.debian.net/debian/pool/main/s/s3ql/s3ql_2.11.1+dfsg-3.dsc Thanks for considering!
Bug#796945: reportbug: UI epic-fails
control: tag -1 -upstream -patch +moreinfo On Wed, Aug 26, 2015 at 2:10 AM, Richard Jasmin frazzledj...@gmail.com wrote: Package: reportbug Version: 6.6.3 Severity: normal Tags: upstream patch I dont see any patch here, nor the upstream tag has sense in this contect. please dont use tags without knowing what they are. Ok, I see this is using python-vte for the UI. Im not an expert in UI programming but. the following applies: we should detect if python-vte is being ran. what do you mean? be more specific Reason behind this is that UI elements and only UI elements apply and affect a UI application. You cannot close a UI application but hitting enter unless someone default selected a close button. Nobody has done so. This results in an empty input dialog and nothing happening. The text input dialog is not needed in the UI. in which panel is this happening? report the exact steps to replicate this issue (and what the exact issue is, as it not clear at all) IIRC, you can still issue a pause command in linux..but if not its only a few lines of code to add in: writeln(Press any key to continue..) line:=readline; Ok, well this is python but you get by drift. No i dont, you need to be specific and on topic, and not using a mocking language (what's that, pascal? who's relevant here?) And of course I want to close reportbug if I click on close button. Why does it ask me? surprise, because you might have hit the close botton by mistake and we dont want screaming users to complain they lost their reports because they hit close Similar UI glitches abound in the UI of reportbug in various areas. So report them, one by one, with precise and exact information on how to replicate them and how you would address these glitches. if you use the word 'epic-fail' in the subject, you NEED to provide a quality report, which this is absolutely not. I didnt close it just because I want to hear what you have to say, but it has a very low value (if any at all). -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Bug#796950: NameError: global name 're' is not defined
Package: obnam
Version: 1.15-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I was attempting to run obnam backup and received the following python stack
trace.
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/cliapp/app.py, line 189, in _run
self.process_args(args)
File /usr/lib/python2.7/dist-packages/obnamlib/app.py, line 206, in
process_args
self.hooks.call('config-loaded')
File /usr/lib/python2.7/dist-packages/obnamlib/hooks.py, line 188, in call
self.hooks[name].call_callbacks(*args, **kwargs)
File /usr/lib/python2.7/dist-packages/obnamlib/hooks.py, line 65, in
call_callbacks
callback(*args, **kwargs)
File /usr/lib/python2.7/dist-
packages/obnamlib/plugins/exclude_pathnames_plugin.py, line 57, in
config_loaded
self.compile_exclusion_patterns()
File /usr/lib/python2.7/dist-
packages/obnamlib/plugins/exclude_pathnames_plugin.py, line 81, in
compile_exclusion_patterns
self.compile_regexps(regexps, self.pathname_excluder.exclude_regexp)
File /usr/lib/python2.7/dist-
packages/obnamlib/plugins/exclude_pathnames_plugin.py, line 97, in
compile_regexps
except re.error as e:
NameError: global name 're' is not defined
Looking at exclude_pathnames_plugin.py it does call except re.error and I
couldn't find a corresponding import re. So something seems wrong.
Attached are the modifications I made to exclude_pathnames_plugin in order to
get it to work.
--- /tmp/exclude_pathnames_plugin.py 2015-08-25 22:27:42.290914865 -0700
+++ /usr/lib/python2.7/dist-packages/obnamlib/plugins/exclude_pathnames_plugin.py 2015-08-25 22:27:13.923549566 -0700
@@ -18,8 +18,9 @@
import logging
import os
import stat
import time
+import re
import obnamlib
@@ -93,11 +94,11 @@
logging.debug('Regular expression: %s', regexp)
try:
compiler(regexp)
except re.error as e:
-msg = ('error compiling regular expression %s: %s' % (x, e))
+msg = ('error compiling regular expression %s: %s' % (regexp, e))
logging.error(msg)
-self.progress.error(msg)
+#self.progress.error(msg)
def read_patterns_from_files(self, filenames):
patterns = []
for filename in filenames:
Bug#796298: tcplay: FTBFS: CMake Error at CMakeLists.txt:30 (message): Could not find the devmapper library
On Fri, Aug 21, 2015 at 10:10 AM, Chris Lamb la...@debian.org wrote: Source: tcplay Version: 1.1-2 Severity: serious Justification: fails to build from source CMake Error at CMakeLists.txt:30 (message): Could not find the devmapper library From a cursory glance, devmapper.pc specifies Requires.Private librt, which doesn't have a librt.pc (which is likely correct as it's meant to be linked statically? I'll leave it to you). You are right in the sense that without 'Requires.private:' the devmapper library is found correctly. On the other hand I don't think static linking is mandatory as libdevmapper.so.* exists and is under /lib (no need to have /usr mounted, can be used in emergency shells as well). Can be a cmake issue? Will investigate further. Laszlo/GCS
Bug#697370: clusterssh: add autocompletion for defined clusters
On 08/16/2015 11:14 PM, Oliver Meißner wrote: Hello, the following file should do autocompletion in bash for clusterssh-clusters: Hello Oliver, Thank you for the patch. I'll work on getting it into the next upload of clusterssh. Cheers, tony signature.asc Description: OpenPGP digital signature
Bug#724518: openldap: Patch to allow bootstrapping without heimdal-dev
On Tue, Aug 25, 2015 at 12:51 PM, Ryan Tandy r...@nardis.ca wrote: No hurry. Revised patch attached... I think it's correct, but would appreciate a thumbs-up when you have time. Thanks a lot for your help! That patch looks good to me. -- Daniel
