Bug#765789: dpkg: cycle found while processing triggers
Package: hicolor-icon-theme Version: 0.13-1 Severity: important Dear Maintainer, Here is the error message shown while installing upgrades dpkg: cycle found while processing triggers: chain of packages whose triggers are or may be responsible: man-db - libglib2.0-0:i386 packages' pending triggers which are or may be unresolvable: hicolor-icon-theme: /usr/share/icons/hicolor gnome-menus: /usr/share/applications man-db: /usr/share/man menu: /usr/share/menu libglib2.0-0:i386: /usr/share/glib-2.0/schemas libglib2.0-0:amd64: /usr/share/glib-2.0/schemas desktop-file-utils: /usr/share/applications mime-support: /usr/lib/mime/packages: /usr/share/applications dpkg: error processing package hicolor-icon-theme (--unpack): triggers looping, abandoned -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_IN.utf8, LC_CTYPE=en_IN.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765790: libjpeg-progs: It can not overwrite a manpage
Package: libjpeg-progs Version: 1:1.3.1-3 Severity: normal Dear Maintainer, When i dist-upgarde, i get the following message: // dpkg: error processing archive /var/cache/apt/archives/libjpeg-progs_1%3a9a-2_i386.deb (--unpack): trying to overwrite '/usr/share/man/man1/exifautotran.1.gz', which is also in package libjpeg-turbo-progs 1:1.3.1-3 / Yours, Mohsen -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.16-2-686-pae (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libjpeg-progs depends on: ii libjpeg-turbo-progs 1:1.3.1-3 libjpeg-progs recommends no packages. libjpeg-progs suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765791: RM: tpconfig -- ROM; Doesn't work with 2.6+ kernels
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi! Please, remove tpconfig from the archive. It doesn't work with 2.6+ kernels. People should use synclient from xserver-xorg-input-synaptics instead. Thanks! -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUQg7oAAoJEJWkL+g1NSX5olgP/2HMJFeUXrpIsofHdBxi5RM3 w3c4dIaeZoemrP3MD0aP0EYIggk1PQPBtlf2YpxjLDVbD5ekqyPG4W3YgtBJi//V IXyepoDoimpgxzwiORNP6x4qoGXWFELXN6u8V9QiXNnAX2um20U+ykAJ7JOjSUjR gc8U5jOYkIY90XOSlKNBSwuuEDCDOKsRCSTKT8mOzt+Jmgf4wx0v+t9ix6w7T8tx O4zX2AbjZLs9fFO8PWugswLxGq1aI/5ncHoeOMfNBYV0rG+OIOcG2pLUNxoq8P9L MotHL1Lj0WqTYQLG/spo8Y5Hvz71sl2YQyLnsWJOpRIeI78qoiKrHHBVzFPJwAzN 41WsDvyc19eiaERP7GvSyDySbhtLwZ/NDXYbjTOOlC4pjDOzMkgiTg8MR3boxzKo qaPoXhgQYEAoeBP0g9GOOe6swXPTvSXoaJM37BU7/5FnBi4IbqD7T1ap9a6gRezj ZN9i59ZRpQhj+pPsHTZzwDuKBNyBQvuWOf2pN6LJ7MJ5CtmjGuAeQwMnPKdMrXnh br/+XUVzaFbTesBQ/+Cw22f2DGkx2BgegFh00iupyVGnj3/PVTqfmmwSCx8/wWJE 6YyZcv3pZOqiQ9COAtdk/O5YC3G3YWJVTr5v4uS0+ztOsM1INoWIGaiug6J1I6Uy Jp+k5zKGMAbFGGT/XwTM =1tVY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764761: pyqt4-dev-tools: fontMetrics.elidedText performs poorly on '\t' in QLabel.
On Fri, 17 Oct 2014 21:48:45 +0200, Enno wrote: Segfault? Well maybe I should add the full code: See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764761#15 The width of the tab is 80px according to Qt documentation, but this is not consistent with my experience, in my configuration in this QLabel it seems to be about 56px wide. I think 80px is *maximum* tab width, and real tab width will be (− width of previous text) mod (80px). Anyway, if it is less than the documented value, I think it is not a bug. Anyway, this should not stop you from discussing it with upstream :) -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Bug#765792: googleearth-package: googleearth package contains missing /usr/lib/googleearth/libcurl.so.4 md5sum
Package: googleearth-package Version: 1.2.2 Severity: serious Justification: fails to build from source -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, make-googleearth-package generates the googleearth.md5sums file before deleting libcurl.so.4 (#716695), causing: $ debsums -c googleearth debsums: missing file /usr/lib/googleearth/libcurl.so.4 (from googleearth package) $ Probably the 'if [ -e ]; then rm; fi' lines just need to be moved 10 lines up or so, before calling make_md5sums. Sebastian - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-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 Versions of packages googleearth-package depends on: ii bzip2 1.0.6-7 ii dpkg-dev1.17.18 ii fakeroot1.20.2-1 ii file1:5.19-2 ii wget1.15-1+b1 ii x11-common 1:7.7+7 ii x11-utils 7.7+2 Versions of packages googleearth-package recommends: pn libdb5.3:i386 none pn libgnutls26:i386 none pn libldap-2.4-2:i386none pn libsasl2-2:i386 none pn libsasl2-modules-db:i386 none pn libsasl2-modules:i386 none googleearth-package suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIVAwUBVEISdPhx3EthBlqjAQi+AA//fcN1vzgGqCuEhKYTFRCFBDZSdQIWgZMX MVgu6TC0wE6OqTqwmHzlikxYi5IuiErg4KXCEdKpwKEOTtxLH0UQIV0T9zqmS1iO iv/nSAp9TERIPXK/6htwQXlPI3uwRD+IPS43TiFvHJI9GpTV2Z2jKWe9BFkW5sog AjpKwXcaNL14Hvd7Nqj9c4Zc+3Osa+F22banZe/3pzXDZ3T7dgP2Nq69ThgERVmz TSpIxSsvyAvlrqxChUsJyrrLoWcpc8agL3hHZ0ffc5EwoPJeMJL4TuWypa+vK+yh TRpINJ+o3LFlnKq847JFMs/jR3diNynzA9um+YWlnNDmXhHYZHldafq855x2f/52 zC86nGpiiM77W0R9CWD1iyJs+EeEJbc32DiLIRk0v6I6ieXDKfo0r+uCnMHMKb9C GNNBfRUY1nWNzsK5+J6ZjfNbXEeFguezu5LHQ3IJtG+GLlQ3ZW1gLQMh8Tp2kN87 79CBV3XsZCiqJrUZgriZwofLLBZ1isYGC5I2qIHNpa3Kr8l8Ize7iKqmTOcSxJmy 3IzVrM7W850djgw3+mF9gPLoH/ruo/Gel+zjvOLbGiAPC+J4SScFhQSBQbqgpfC6 Z4pQsOoqE/VgFIlXvDiZxPImbLEDsUgIXNBG3yEQ6mHwzOhd/ZcDlSRXuuRU0QR6 1XWrx/zUuKo= =yQLR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756104: binary removal mrpt
Thank you very much!! I am on a 48h trip with only mobile access, I will check it out asap. On Friday, October 17, 2014, Gianfranco Costamagna costamagnagianfra...@yahoo.it wrote: Hi Jose, In order to get them removed you have to open a bug against ftp.debian.org Feel free to copy the significant bit from this bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764859 cheers, Gianfranco -- ___ Dr. Jose-Luis Blanco-Claraco CITE-IV 1.05 Universidad de Almería, Departamento de Ingeniería 04120 Almería (Spain) http://www.ual.es/~jlblanco/ ___
Bug#765793: glx-alternative-nvidia: makes EGL applications crash
Package: glx-alternative-nvidia Version: 0.4.2 Severity: important Dear Maintainer, When running 'vlc -Vgl /some/video/file', VLC crashes straight away if glx-alternative-nvidia is installed. It appears that libGL.so points (correctly) to the NVIDIA driver, but libEGL.so points to the Mesa implementation, resulting in a memory corruption. 'export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/nvidia/current' works around the problem, assuming libegl1-nvidia is installed. libEGL.so should ostensibly be redirected at the same time as libGL.so. -- Package-specific info: Diversions: diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions /usr/lib/mesa-diverted: total 52 drwxr-xr-x 5 root root 4096 Mar 22 2014 . drwxr-xr-x 86 root root 32768 Oct 18 09:55 .. drwxr-xr-x 2 root root 4096 Oct 24 2013 arm-linux-gnueabihf drwxr-xr-x 2 root root 4096 Oct 18 09:53 i386-linux-gnu lrwxrwxrwx 1 root root33 Mar 22 2014 libGL.so-master - /etc/alternatives/libGL.so-master drwxr-xr-x 2 root root 4096 Oct 18 09:53 x86_64-linux-gnu /usr/lib/mesa-diverted/i386-linux-gnu/: total 688 drwxr-xr-x 2 root root 4096 Oct 18 09:53 . drwxr-xr-x 5 root root 4096 Mar 22 2014 .. lrwxrwxrwx 1 root root 14 Oct 14 00:57 libGL.so.1 - libGL.so.1.2.0 -rw-r--r-- 1 root root 695836 Oct 14 00:57 libGL.so.1.2.0 /usr/lib/mesa-diverted/x86_64-linux-gnu/: total 624 drwxr-xr-x 2 root root 4096 Oct 18 09:53 . drwxr-xr-x 5 root root 4096 Mar 22 2014 .. lrwxrwxrwx 1 root root 14 Oct 14 12:34 libGL.so - libGL.so.1.2.0 lrwxrwxrwx 1 root root 14 Oct 14 12:34 libGL.so.1 - libGL.so.1.2.0 -rw-r--r-- 1 root root 627320 Oct 14 12:34 libGL.so.1.2.0 Alternative 'glx': glx - auto mode link currently points to /usr/lib/nvidia /usr/lib/mesa-diverted - priority 5 slave glx--libGL.so.1-i386-linux-gnu: /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 slave glx--libGL.so.1-x86_64-linux-gnu: /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 /usr/lib/nvidia - priority 100 slave glx--libGL.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 slave glx--libGL.so.1-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 slave glx--libnvidia-cfg.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 slave glx--libnvidia-cfg.so.1-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 slave glx--linux-libglx.so: /usr/lib/nvidia/libglx.so slave glx--nvidia-blacklists-nouveau.conf: /etc/nvidia/nvidia-blacklists-nouveau.conf slave glx--nvidia-bug-report.sh: /usr/lib/nvidia/nvidia-bug-report.sh slave glx--nvidia_drv.so: /usr/lib/nvidia/nvidia_drv.so Current 'best' version is '/usr/lib/nvidia'. lrwxrwxrwx 1 root root 15 Oct 7 23:36 /etc/alternatives/glx - /usr/lib/nvidia lrwxrwxrwx 1 root root 48 Mar 22 2014 /etc/alternatives/glx--libGL.so-x86_64-linux-gnu - /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so lrwxrwxrwx 1 root root 41 Oct 7 23:36 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Oct 7 23:36 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx
Bug#765794: Race condition when running scripts in stdin mode
Package: pymol Version: 1.7.2.1-1 Severity: normal Hello, I've been trying to make a small script that drives pymol completely uninteractively using a pymol -c -p command. Unfortunately, pymol is polling from stdin DURING the reading of scripts from within a @ command, which leads to painful race conditions, as I'm wrapping the call to scripts to a cd in/cd out command. For instance, I'm running cd /home/vincent/Recherche/Proteines/CODH @ CODH-clusters.pml cd /home/vincent/tmp The CODH-clusters.pml runs a series of pymol scripts by itself. As you can see below, the cd /home/vincent/tmp comes between select prot, ((all) and (not ((fes) or (nifes and select s, /S3 Both of these commands are within the CODH-Chydrogenoformans-definitions.pml script. This is really painful, since one cannot assume that because one sends commands sequentially, the previous one is finished before the next one starts. PyMOLcd /home/vincent/Recherche/Proteines/CODH cd: now in /home/vincent/Recherche/Proteines/CODH PyMOL@ CODH-clusters.pml PyMOL@ CODH-vue-generale.pml PyMOL@ CODH-Chydrogenoformans-definitions.pml PyMOLload ../PDB/1SU8.pdb.gz, Ch; [...] PyMOLselect prot, ((all) and (not ((fes) or (nifes Selector: selection prot defined with 11466 atoms. PyMOLcd /home/vincent/tmp PyMOLselect s, /S3 I'll try to see if this can be easily fixed... Vincent -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.3+macbook (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pymol depends on: ii freeglut3 2.8.1-2 ii libc6 2.19-11 ii libfreetype6 2.5.2-2 ii libgcc1 1:4.9.1-16 ii libgl1-mesa-glx [libgl1] 10.2.8-1 ii libglew1.10 1.10.0-3 ii libglu1-mesa [libglu1]9.0.0-2 ii libpng12-01.2.50-2 ii libstdc++64.9.1-16 ii python2.7.8-1 ii python-numpy [python-numpy-abi9] 1:1.8.2-2 ii python-pmw1.3.2-6 ii python-tk 2.7.8-2 pn python2.7:any none Versions of packages pymol recommends: ii apbs 1.4-1 pymol suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765789: dpkg: cycle found while processing triggers
Control: reassign -1 dpkg Control: forcemerge 765434 -1 On 2014-10-18 08:03 +0200, L. Guruprasad wrote: Package: hicolor-icon-theme Version: 0.13-1 Severity: important Dear Maintainer, Here is the error message shown while installing upgrades dpkg: cycle found while processing triggers: chain of packages whose triggers are or may be responsible: man-db - libglib2.0-0:i386 packages' pending triggers which are or may be unresolvable: hicolor-icon-theme: /usr/share/icons/hicolor gnome-menus: /usr/share/applications man-db: /usr/share/man menu: /usr/share/menu libglib2.0-0:i386: /usr/share/glib-2.0/schemas libglib2.0-0:amd64: /usr/share/glib-2.0/schemas desktop-file-utils: /usr/share/applications mime-support: /usr/lib/mime/packages: /usr/share/applications dpkg: error processing package hicolor-icon-theme (--unpack): triggers looping, abandoned This is a bug in dpkg, see #765434 and friends. Cheers, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696981: [git/munin] stable-2.0: Merge branch 'bts/696981-fix-not-a-reference-utils-pm' into stable-2.0 (c9f44f2)
control: tags -1 + pending On Freitag, 17. Oktober 2014, comm...@munin-monitoring.org wrote: Repository : ssh://g...@munin-monitoring.org/munin On branch : stable-2.0 --- commit c9f44f25b019c0aa1e998bfb3cba05b1123d751e Merge: 9c231e4 92f33dc Author: Steve Schnepp steve.schn...@pwkf.org Date: Fri Oct 17 20:34:09 2014 +0200 Merge branch 'bts/696981-fix-not-a-reference-utils-pm' into stable-2.0 --- c9f44f25b019c0aa1e998bfb3cba05b1123d751e master/lib/Munin/Master/Utils.pm |4 1 file changed, 4 insertions(+) signature.asc Description: This is a digitally signed message part.
Bug#765744: xombrero: entries in URI and Search fields not readable due to default color combinations
I'm having the same problem with xombrero showing the URI and Search fields in unreadable color combinations; this also includes text that is being selected (which becomes white on white) This happened not with a xombrero update, but after updating libglib2.0-0 (and some other packages, see below) from version 2.40.0-5 to 2.42.0-2. I don't use a desktop environment (I use fluxbox) and I don't have Gnome installed, which may be relevant. --- packages update that started the issue (from etckeeper log) --- +adwaita-icon-theme 3.14.0-2 +gobby 0.4.13-2 +gobby-0.4 0.4.13-2 +gobby-0.5 0.5.0-1 -libglib2.0-0 2.40.0-5 -libglib2.0-bin 2.40.0-5 +libglib2.0-0 2.42.0-2 +libglib2.0-bin 2.42.0-2 -libglib2.0-dev 2.40.0-5 -libglibmm-2.4-1c2a 2.40.0-1 +libglib2.0-dev 2.42.0-2 +libglibmm-2.4-1c2a 2.42.0-1 -libgtk-3-0 3.12.2-3+b1 +libgtk-3-0 3.14.1-1 -libgtk-3-common 3.12.2-3 +libgtk-3-common 3.14.1-1 +libgtkmm-3.0-1 3.14.0-1 +libgtksourceview-3.0-1 3.14.0-1 +libgtksourceview-3.0-common 3.14.0-1 +libgtksourceview2.0-0 2.10.5-2 +libgtksourceview2.0-common 2.10.5-2 +libinfgtk3-0.6-0 0.6.2-1 +libinfinity-0.6-0 0.6.2-1 +libnet6-1.3-0 1:1.3.14-2 +libobby-0.4-1 0.4.8-1 +libunique-3.0-0 3.0.2-2 +xdg-user-dirs 0.15-2 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xombrero depends on: ii libbsd0 0.7.0-2 ii libc6 2.19-11 ii libgdk-pixbuf2.0-0 2.30.8-1+b1 ii libglib2.0-02.42.0-2 ii libgnutls-deb0-28 3.3.8-2 ii libgtk-3-0 3.14.1-1 ii libjavascriptcoregtk-3.0-0 2.4.6-1 ii libpango-1.0-0 1.36.8-2 ii libsoup2.4-12.48.0-1 ii libwebkitgtk-3.0-0 2.4.6-1 xombrero recommends no packages. xombrero suggests no packages. -- no debconf information -- Elena ``of Valhalla'' signature.asc Description: Digital signature
Bug#714436: [Pkg-fonts-devel] Bug#714436: Bug#714436: Only three Hangul glyphs in it
Quoting Changwoo Ryu (cw...@debian.org): 2014-05-10 21:29 GMT+09:00 Jonas Smedegaard d...@jones.dk: Hi Changwoo (or is that your family name? I aimed for first name), Hello, Mostly shorter one is the Korean family name and the other is give name. Yes, Changwoo is my given name. IMO simple solution is just to copypaste Hangul glyphs from another DroidSansFallback file to DroidSansFallbackFull.ttf. Simple python-fontforge script can do the job. It will modify font file but I think it's better than increasing package size and messing with fontconfig configs. Opinions? Best is, I believe, to try collaborate upstream on such improvements, as else we will effectively create a fork of the font which is generally bad for the FLOSS eco system. If you find it more comfortable to work only with Debian on this, then perhaps you could try put together the script that you envision and share it as a patch to this bugreport, and others can then pass that upstream for their consideration. In my years of Debian development, I have almost always worked with upstream and I think you are right in general. But in this specific case, working with upstream won't work. These Hangul glyphs have been removed with clear reason; because they are replaced by NanumGothic font in Android. What could AOSP do on this? We can't expect them to restore the Hangul glyphs or to begin maintaining general font file for non-Android use. My idea is to copy Hangul glyphs from DroidSansFallback.ttf to installed DroidSansFallbackFull.ttf during package building. It's not about modifying the font data directly. Coming back to this issue... I'm still not comfortable about modifying upstream files, even simply as you suggest. As I'm currently working to fix #762296, the two DroidSansFallback.ttf and DroidSansFallbackLegacy.ttf files will no longer be in fontconfig directories. Still, people can manually tweak their configuration to use them (and therefore better display Hangul charactersbut it seems that just installing fonts-nanum better does the job. So, shouldn't just fonts-droid Recommend fonts-nanum ? signature.asc Description: Digital signature
Bug#661712: dvswitch: Provide some information about the free space of the hd
I don't see the point of doing this in DVswitch. There are applets
for this and a stock GNOME installation will warn on low disk space.
I believe it would be nice to see the amount of disk free where I look
to check if the dvsink is working, and made a untested draft patch to
do so.
Something along these lines would help me a bit when doing video
recordings:
Index: src/dvsink-files.c
===
--- src/dvsink-files.c (revision 414)
+++ src/dvsink-files.c (working copy)
@@ -17,6 +17,7 @@
#include sys/types.h
#include sys/stat.h
#include unistd.h
+#include sys/statfs.h
#include config.h
#include dif.h
@@ -162,6 +163,19 @@
return total;
}
+/* Return the amount of megabyte free on the disk of the file descriptor */
+static long freespace(int fd)
+{
+struct statfs stat;
+long free;
+if (0 == fstatfs(fd, stat))
+{
+free = stat.f_bsize * stat.f_bavail / (1024*1024) ;
+} else {
+free = -1;
+}
+}
+
static void transfer_frames(struct transfer_params * params)
{
static uint8_t buf[SINK_FRAME_HEADER_SIZE + DIF_MAX_FRAME_SIZE];
@@ -207,7 +221,8 @@
file = create_file(output_name_format, name);
if (starting)
printf(INFO: Started recording\n);
- printf(INFO: Created file %s\n, name);
+ long free = freespace(file);
+ printf(INFO: Created file %s - free space $ld MiB\n, name, free);
fflush(stdout);
}
Perhaps something to include?
--
Happy hacking
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687126: SubDownloader package in Debian
Ok, thanks. That is appreciated. Emilien, the freeze is in 2 weeks. we need to make progress in the next few days. :) Sylvestre On 28/09/2014 09:32, Marco Rodrigues wrote: Hi Emilien, I'm OK with that, you can take the maintainer role of SubDownloader package. Cheers. -- Marco Rodrigues http://lu.linkedin.com/in/gothicx On Sat, Sep 27, 2014 at 3:29 PM, Emilien Klein emilien+deb...@klein.st mailto:emilien+deb...@klein.st wrote: Hi Marco, 2012-11-23 21:38 GMT+01:00 Emilien Klein emilien+deb...@klein.st mailto:emilien%2bdeb...@klein.st: Hello Marco Rodrigues, [snip] Since the latest update of the package in Debian is almost 2 years old, I wanted to check if you were still interested in maintaining it, or if I should propose my help in maintaining the SubDownloader package in Debian. I am a Debian Maintainer (i.e. not [yet] a DD), so I can't directly update new packages, but I'd like to help maintain SubDownloader if you need help/don't have time to take care of it anymore. Are you OK if I take maintainer role over from you for SubDownloader in Debian? Cheers, +Emilien
Bug#731355: Bug unreproducible for me as well
tags 731355 unreproducible thanks I can't reproduce this bug either. See attached screenshots. Even at 5 point, the exclamation mark is still an exclamation mark. -- signature.asc Description: Digital signature
Bug#758183: Autologin no longer works
I can confirm this bug too. It would be a shame if the autologin feature (which is available upstream) was missing in the next stable release. Could you please fix this bug before the release of jessie ? Regards, Bertrand -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764285: kernel panic with fuse mounted partition (ntfs-3g) when using virtualbox
I had the same problem. A report is available in the linux kernel bug tracker at the address https://bugzilla.kernel.org/show_bug.cgi?id=82951 .
Bug#684344: libopenblas-base: please install OpenMP version
Hi Sebastien, Isn't it possible to build another version of openblas compiled with openmp instead of pthreads, make it a different package (libopenblas-omp for instance) and prevent its co-installation with the regular pthread libopenblas ? Ghis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765540: grub2: symbol 'grub_term_highlight_color' not found
Hi, Actually, I still have no idea how to do the latter. I assume the dpkg-reconfigure you mentioned will do that, but I currently don't feel like breaking my boot again ;-) Indeed running dpkg-reconfigure grub-pc and telling it to install grub on both /dev/sda and /dev/sdb fixed the problem. Phew :D However, I still think some way to tell the user that this is actually necessary, would be a great improvement. For example, when running grub-install manually, it could say that while this installed the *current version*, further means have to be taken for future upgrades to be applied. Kind regards Ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765795: openblas: new upstream version (0.2.12)
Source: openblas Severity: wishlist Dear Maintainer, A new upstream version has been released (0.2.12) with a bunch of fixes [1]. For some reasons, the PTS failed to track the new release though uscan picks it up. Cheers, Ghislain [1] https://github.com/xianyi/OpenBLAS/blob/develop/Changelog.txt -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748867: patch: Let's fix this by adding APIKEY
control: tags 748867 patch thanks We are reaching closer to freeze. This -2 package is missing APIKEY still and pushed almost immediately to testing archive breaking not just unstable but *tesing* systems. I have no idea why urgency=medium package takes only one day to migrate to testing. I have no idea why the same trick of immediate push to testing is not used to fix this situation since fix seems to be known for 5 days. https://bugs.debian.org/748867#117 Mike said on 5 days ago https://bugs.debian.org/748867#122: And when it comes to api keys, the plan has been to implement it differently this time, which has yet to be done, but is probably going to take less time than this email anyway. I understand Mike's (long term) plan to separate APIKEY to different package. But, at least for now, can we have functioning package in testing without reading and manually tweeking the system? Any reason not to update this? Then with next package, Mike can do whatever as long as it is cordinated with ftp-master for the new package. I attach a quick fix idea here. (We can remove etc/chromium.d from debian/chromium.dirs) Mike is right it took less time to write this patch than writing this report. I guess something much more urgent is holding Mike to fix this. Can someone NMU this package after applying and checking this patch, if Mike is not available? At least adding this key fixed my system. (I have removed old ~/.chromium directory before adding the API key. If removal of this is required for upgrade, please consider adding entry to debian/NEWS) Regards, Osamu diff -Nru chromium-browser-38.0.2125.101.orig/debian/chromium.install chromium-browser-38.0.2125.101/debian/chromium.install --- chromium-browser-38.0.2125.101.orig/debian/chromium.install 2014-10-13 08:15:44.0 +0900 +++ chromium-browser-38.0.2125.101/debian/chromium.install 2014-10-18 17:25:39.767440130 +0900 @@ -15,3 +15,5 @@ debian/chromium.xml usr/share/gnome-control-center/default-apps debian/chromium.desktop usr/share/applications + +debian/GOOGLE_API_KEY etc/chromium.d diff -Nru chromium-browser-38.0.2125.101.orig/debian/GOOGLE_API_KEY chromium-browser-38.0.2125.101/debian/GOOGLE_API_KEY --- chromium-browser-38.0.2125.101.orig/debian/GOOGLE_API_KEY 1970-01-01 09:00:00.0 +0900 +++ chromium-browser-38.0.2125.101/debian/GOOGLE_API_KEY 2014-10-18 17:23:24.559444031 +0900 @@ -0,0 +1,5 @@ +# Debian's Google API KEY +export GOOGLE_API_KEY=AIzaSyCkfPOPZXDKNn8hhgu3JrA62wIgC93d44k +export GOOGLE_DEFAULT_CLIENT_ID=811574891467.apps.googleusercontent.com +export GOOGLE_DEFAULT_CLIENT_SECRET=kdloedMFGdGla2P1zacGjAQh +
Bug#765796: encfs: [INTL:it] Italian translation of debconf messages
Package: encfs Severity: wishlist Tags: l10n patch Hi. Please find attached the Italian translation of encfs debconf messages proofread by the Italian localization team. Please include it in your next upload. Thanks, Beatrice # Italian translation of encfs debconf messages. # Copyright (C) 2014, encfs package's copyright holder # This file is distributed under the same license as the encfs package. # Beatrice Torracca beatri...@libero.it, 2014. msgid msgstr Project-Id-Version: encfs\n Report-Msgid-Bugs-To: en...@packages.debian.org\n POT-Creation-Date: 2014-10-07 19:56+0200\n PO-Revision-Date: 2014-10-17 18:28+0200\n Last-Translator: Beatrice Torracca beatri...@libero.it\n Language-Team: Italian debian-l10n-ital...@lists.debian.org\n Language: it\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=2; plural=(n != 1);\n X-Generator: Virtaal 0.7.1\n #. Type: error #. Description #: ../encfs.templates:1001 msgid Encfs security information msgstr Informazioni di sicurezza su Encfs #. Type: error #. Description #: ../encfs.templates:1001 msgid According to a security audit by Taylor Hornby (Defuse Security), the current implementation of Encfs is vulnerable or potentially vulnerable to multiple types of attacks. For example, an attacker with read/write access to encrypted data might lower the decryption complexity for subsequently encrypted data without this being noticed by a legitimate user, or might use timing analysis to deduce information. msgstr Secondo una verifica di sicurezza fatta da Taylor Hornby (Defuse Security), l'attuale implementazione di Encfs è vulnerabile o potenzialmente vulnerabile a diversi tipi di attacchi. Per esempio, l'autore di un attacco con accesso in lettura/scrittura ai dati cifrati potrebbe abbassare la complessità di decifrazione per i dati cifrati da lì in avanti, senza che questo venga notato da un utente legittimo, oppure potrebbe usare analisi sulle tempistiche per dedurre informazioni. #. Type: error #. Description #: ../encfs.templates:1001 msgid Until these issues are resolved, encfs should not be considered a safe home for sensitive data in scenarios where such attacks are possible. msgstr Fino a che questi problemi non saranno risolti encfs non dovrebbe essere considerato un luogo sicuro per dati sensibili in scenari dove questo tipo di attacco è possibile.
Bug#765797: grub-efi-amd64: vga and vbe modules appear in grub.cfg while not being installed
Package: grub-efi-amd64 Version: 1.99-27+deb7u2 Severity: minor Dear Maintainer, * What led up to the situation? Installation of LMDE (based upon debian testing), on a preinstalled win8 machine with uefi boot. errors on boot, in the end the message booting anyway (file not found, mode not supported) * What exactly did you do (or not do) that was effective (or ineffective)? Solution: outcomment insmod vga insmod vbe and replace with insmod efi_gob insmod efi_uga insmod font Change the resolution to a higher one in grub.cfg (for the mode not supported) * What was the outcome of this action? no visible errors on boot This could be a single case, but could it be that vga en vbe should not be present by default in the grub.cfg for efi version of grub. mvg, Wim Bertels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765747: RFS: openldap/2.4.40-1 [RC]
Ryan Tandy r...@nardis.ca writes: - Invoke find, chmod, and chown with -H in case /var/lib/ldap is a symlink. (Closes: #742862) You mean chgrp, not chmod. * debian/slapd.README.Debian: Add a note about database format upgrades and the consequences of missing one. (Closes: #594711) HDB is the recommended database backend. Is this still so? Not MDB? Maybe the Logging section could mention rsyslog, which is the current default system log daemon. I personally use /etc/rsyslog.d/50-slapd.conf: # Globally turn off rate limiting on the unix socket (mostly slapd logs) $SystemLogRateLimitInterval 0 local4.* -/var/log/slapd.log ~ with a corresponding logrotate snippet, although it could be done another way as well (http://wiki.rsyslog.com/index.php/DailyLogRotation). * debian/slapd.init.ldif: Btw: why do you give rigths to the RootDN explicitly? Doesn't it skip all ACL processing anyway? I much hope to see OpenLDAP 2.4.40 in jessie! -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745901: [Pkg-fglrx-devel] Bug#745901: fglrx-driver: fglrx update crashes totem, gdm, gnome-session and anything that uses clutter
On Fri, Sep 26, 2014 at 10:47:31PM +1000, Craig Small wrote: Trying it again. Version is 1:14.6~ga14.201-1 Version is now 1:14.9+ga14.201-1 Same as before. What I really can't live with is the lack of mouse pointer. Any idea why the mouse pointer disappears? The mouse is still there because if I guess where something is and click, I get the right response. Also if a button has an effect (glows,or shades for example) when the mouse hovers over it, that happens too. Just no pointer, its quite frustrating. My choices seem to be use the intel integrated device with pretty awful 3d performance or the fglrx driver on the dedicated device with good 3d performance and no mouse. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748867: patch: Let's fix this by adding APIKEY
❦ 18 octobre 2014 18:12 +0900, Osamu Aoki os...@debian.org : We are reaching closer to freeze. This -2 package is missing APIKEY still and pushed almost immediately to testing archive breaking not just unstable but *tesing* systems. I have no idea why urgency=medium package takes only one day to migrate to testing. I have no idea why the same trick of immediate push to testing is not used to fix this situation since fix seems to be known for 5 days. https://bugs.debian.org/748867#117 This is because the release team bypassed the regular delay (due to CVE fixed in -1 and I suppose because of the importance of the bugs fixed by -2). I guess something much more urgent is holding Mike to fix this. Can someone NMU this package after applying and checking this patch, if Mike is not available? I think that Mike is the only member of the Chromium team now. I also think that your patch is the right way to move forward. At least adding this key fixed my system. (I have removed old ~/.chromium directory before adding the API key. If removal of this is required for upgrade, please consider adding entry to debian/NEWS) It is not needed. I have kept my .chromium without any issue (segfaulted with -1 but worked unmodified with -2). -- printk(Illegal format on cdrom. Pester manufacturer.\n); 2.2.16 /usr/src/linux/fs/isofs/inode.c signature.asc Description: PGP signature
Bug#765798: RFS: lxqt-common/0.8.0-1 (ITP: #747599)
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package lxqt-common * Package name: lxqt-common Version : 0.8.0-1 Upstream Author : LXQt team lxde-l...@lists.sourceforge.net * URL : http://lxqt.org * License : (GPL, LGPL) Section : x11 It builds those binary packages: lxqt-common-qt5 - Common files for LXQt To access further information about this package, please visit the following URL: http://mentors.debian.net/package/lxqt-common Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/lxqt-common/lxqt-common_0.8.0-1.dsc More information about lxqt-common can be obtained from https:://github.com/debian-lxqt/lxqt-common . Changes since the last upload: lxqt-common (0.8.0-1) unstable; urgency=medium * Imported Upstream version 0.8.0 * bump standards to 3.9.6 * Min Qt version 5.3.2 * Min liblxqt-qt5-dev version 0.8.0 * added a lintian-override for startlxqt manpage * enable compton by default -- Alf Gaida aga...@siduction.org Sat, 18 Oct 2014 02:39:04 +0200 Regards, Alf Gaida -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574669: asterisk-prompt-es-co: adjust to asterisk 1.6.0 layout
Package: asterisk-prompt-es-co Followup-For: Bug #574669 Tzafrir, Do you think this package is still useful? If so, please, fell free to take over it to maintain through the pkg-voip team. Otherwise, I'd ask to remove it, since the sounds are not longer updated. Cheers, Santiago -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765799: qemu-system-x86: USB Passthrough Not Working
Package: qemu-system-x86 Version: 2.1+dfsg-5 Severity: normal Dear maintainer, USB passthrough is not working for qemu-system-x86_64 version 2.1.2 (Debian 2.1+dfsg-5). Passthrough methods attempted: - starting a guest image via qemu-system-x86_64 and appending '-usbdevice host:$bus.$addr' - starting a guest image via qemu-system-X86_64, switching to the qemu monitor and using 'usb_add host:$vendorid:$productid' - using virsh or virt-manager to start a guest and using the GUI with Add hardware-USB Host Device ... OR virsh attach-device $guest foo.xml Running lsusb on the guest does not reveal the target device. When using libvirt methods to attach USB logs report: libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/007/021: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. I don't use this feature a lot so I can't be certain, but this used to work so I'm assuming the change has been intruduced with recent patching that upgraded a number of qemu packages. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages qemu-system-x86 depends on: ii ipxe-qemu 1.0.0+git-2013.c3d1e78-2.1 ii libaio1 0.3.109-4 ii libasound2 1.0.28-1 ii libbluetooth3 5.23-1 ii libbrlapi0.65.0-3 ii libc6 2.19-11 ii libcurl3-gnutls 7.38.0-2 ii libfdt1 1.4.0+dfsg-1 ii libgcc1 1:4.9.1-16 ii libglib2.0-02.42.0-2 ii libgnutls-deb0-28 3.3.8-2 ii libiscsi2 1.12.0-2 ii libjpeg88d1-1 ii libncurses5 5.9+20140913-1 ii libpixman-1-0 0.32.6-3 ii libpng12-0 1.2.50-2 ii libpulse0 5.0-6+b1 ii librados2 0.80.6-1 ii librbd1 0.80.6-1 ii libsasl2-2 2.1.26.dfsg1-11 ii libsdl1.2debian 1.2.15-10 ii libseccomp2 2.1.1-1 ii libspice-server10.12.5-1 ii libssh2-1 1.4.3-4 ii libtinfo5 5.9+20140913-1 ii libusb-1.0-02:1.0.19-1 ii libusbredirparser1 0.7-1 ii libuuid12.20.1-5.11 ii libvdeplug2 2.3.2-4.2 ii libx11-62:1.6.2-3 ii libxen-4.4 4.4.1-2 ii libxenstore3.0 4.4.1-2 ii qemu-system-common 2.1+dfsg-5 ii seabios 1.7.5-1 ii zlib1g 1:1.2.8.dfsg-2 Versions of packages qemu-system-x86 recommends: ii qemu-utils 2.1+dfsg-5 Versions of packages qemu-system-x86 suggests: ii kmod 18-3 pn ovmf none pn sambanone pn sgabios none pn vde2 none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765800: dh-make: short option -c doesn't work
Package: dh-make Version: 0.61 Severity: normal The short option -c doesn't work: % dh_make -p foo_1.0 --s --copyright gpl [...] License : gpl3 % dh_make -p foo_1.0 --s -c gpl [...] License : blank I don't know much about Perl option handling, but there seems to be some case confusion. If I (for testing) change 'packageclass|C=s' to 'packageclass|x=s', it works (even though c and C are two totally different letters :) and shouldn't conflict): % dh_make -p foo_1.0 --s -c gpl [...] License : gpl3 -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (900, 'stable'), (500, 'stable-updates'), (500, 'proposed-updates') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages dh-make depends on: ii debhelper 9.20120909 ii dpkg-dev 1.16.15 ii make 4.0-8 ii perl 5.14.2-21+deb7u1 dh-make recommends no packages. Versions of packages dh-make suggests: ii build-essential 11.5 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765421: jmapviewer: Resolution for missing Bing logo
hello all,
the good news is I have received a mail from a Microsoft employee
(unfortunately late on Friday) inviting me on a call regarding
use of the Bing logo in jmapviewer.
I will make that call on Monday morning and maybe we will be able to
agree on a free license that I can put in debian/copyright and thus I
can re-include bing_maps.png
But if MS decides the logo must not be included in jmapviewer
then I'm afraid I *must* remove BingAerialTileSource.java from
jmapviewer and apply the attached patch [1] to 0.0.svn7480+dfsg1-2,
removing Bing support from JOSM. Otherwise jmapviewer may be moved to
non-free because it contains Bing support but not the logo [2].
-- can we agree on this?
[1] dquilt import josm2.diff should be enough before running
gbp buildpackage.
[2] https://lists.debian.org/debian-gis/2014/10/msg00115.html
Cheers and Best Regards,
--
Felix Natter
diff --git a/src/org/openstreetmap/josm/actions/AddImageryLayerAction.java b/src/org/openstreetmap/josm/actions/AddImageryLayerAction.java
index 318257f..c597d08 100644
--- a/src/org/openstreetmap/josm/actions/AddImageryLayerAction.java
+++ b/src/org/openstreetmap/josm/actions/AddImageryLayerAction.java
@@ -150,7 +150,7 @@ public class AddImageryLayerAction extends JosmAction implements AdaptableAction
// never enable blacklisted entries. Do not add same imagery layer twice (fix #2519)
if (info.isBlacklisted() /*|| isLayerAlreadyPresent()*/) { // FIXME check disabled to allow several instances with different settings (see #7981)
setEnabled(false);
-} else if (info.getImageryType() == ImageryType.TMS || info.getImageryType() == ImageryType.BING || info.getImageryType() == ImageryType.SCANEX) {
+} else if (info.getImageryType() == ImageryType.TMS /*|| info.getImageryType() == ImageryType.BING*/ || info.getImageryType() == ImageryType.SCANEX) {
setEnabled(true);
} else if (Main.isDisplayingMapView() !Main.map.mapView.getAllLayers().isEmpty()) {
setEnabled(true);
diff --git a/src/org/openstreetmap/josm/data/imagery/ImageryInfo.java b/src/org/openstreetmap/josm/data/imagery/ImageryInfo.java
index fce96df..82daf15 100644
--- a/src/org/openstreetmap/josm/data/imagery/ImageryInfo.java
+++ b/src/org/openstreetmap/josm/data/imagery/ImageryInfo.java
@@ -45,8 +45,6 @@ public class ImageryInfo implements ComparableImageryInfo, Attributed {
TMS(tms),
/** An HTML proxy (previously used for Yahoo imagery) entry. **/
HTML(html),
-/** TMS entry for Microsoft Bing. */
-BING(bing),
/** TMS entry for Russian company a href=https://wiki.openstreetmap.org/wiki/WikiProject_Russia/kosmosnimki;ScanEx/a. **/
SCANEX(scanex),
/** A WMS endpoint entry only stores the WMS server info, without layer, which are chosen later by the user. **/
diff --git a/src/org/openstreetmap/josm/gui/MapView.java b/src/org/openstreetmap/josm/gui/MapView.java
index 91d5b6b..d1185a9 100644
--- a/src/org/openstreetmap/josm/gui/MapView.java
+++ b/src/org/openstreetmap/josm/gui/MapView.java
@@ -978,7 +978,7 @@ public class MapView extends NavigatableComponent implements PropertyChangeListe
layerInfo.add(i.getName());
}
for (final ImageryLayer i : getLayersOfType(ImageryLayer.class)) {
-layerInfo.add(ImageryInfo.ImageryType.BING.equals(i.getInfo().getImageryType()) ? Bing : i.getName());
+layerInfo.add(/*ImageryInfo.ImageryType.BING.equals(i.getInfo().getImageryType()) ? Bing :*/ i.getName());
}
return Utils.join(; , layerInfo);
}
diff --git a/src/org/openstreetmap/josm/gui/layer/ImageryLayer.java b/src/org/openstreetmap/josm/gui/layer/ImageryLayer.java
index 6176e0a..737b848 100644
--- a/src/org/openstreetmap/josm/gui/layer/ImageryLayer.java
+++ b/src/org/openstreetmap/josm/gui/layer/ImageryLayer.java
@@ -152,7 +152,7 @@ public abstract class ImageryLayer extends Layer {
public static ImageryLayer create(ImageryInfo info) {
if (info.getImageryType() == ImageryType.WMS || info.getImageryType() == ImageryType.HTML)
return new WMSLayer(info);
-else if (info.getImageryType() == ImageryType.TMS || info.getImageryType() == ImageryType.BING || info.getImageryType() == ImageryType.SCANEX)
+else if (info.getImageryType() == ImageryType.TMS /*|| info.getImageryType() == ImageryType.BING*/ || info.getImageryType() == ImageryType.SCANEX)
return new TMSLayer(info);
else throw new AssertionError();
}
diff --git a/src/org/openstreetmap/josm/gui/layer/TMSLayer.java b/src/org/openstreetmap/josm/gui/layer/TMSLayer.java
index b940251..5a64dab 100644
--- a/src/org/openstreetmap/josm/gui/layer/TMSLayer.java
+++ b/src/org/openstreetmap/josm/gui/layer/TMSLayer.java
@@ -51,7 +51,6 @@ import org.openstreetmap.gui.jmapviewer.interfaces.TileCache;
import org.openstreetmap.gui.jmapviewer.interfaces.TileClearController;
Bug#763908: Bug#763892: aspell-en needs to be Multi-Arch: foreign
2014-10-06 11:46 GMT+02:00 Agustin Martin agmar...@debian.org: On Fri, Oct 03, 2014 at 10:35:35PM +0200, Tollef Fog Heen wrote: where aspell-autobuildhash is established as the preferred method for packaging aspell dictionaries, but not made mandatory. That sounds like an RC bug in aspell, missing Breaks/Conflicts against packages it breaks? Unless I'm misunderstanding something. Right, thanks. Just filed [#764189: Must break old pre-multiarch arch:any aspell dictionaries] Will care of this ASAP with a 0-day NMU. Hi again, Noticed that my wording above might be confusing. The 0-day NMU refers to aspell, not norwegian, I did not intend to NMU norwegian. On the other hand, aspell is waiting for fixed aspell-da and aspell-no to reach testing. I started co-maintaining aspell-da and a new upload also including new upstream release is waiting to reach testing. That leaves aspell-no as the only pending issue. Let me know if you prefer me to request a binary NMU. Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756777: Dirac FTBFS on armhf and blocks migration of arm64 fix.
2014-10-18 2:21 GMT+02:00 Jonas Smedegaard d...@jones.dk: Quoting peter green (2014-10-17 23:25:14) peter green wrote: I've just tested and found that building with gcc/g++ 4.8 fixes the build. Gcc maintainer is pushing to drop gcc-4.8 for Jessie - see bug#765380. In similar cases please consider using clang instead of an old, to-be-retired version of gcc. Cheers, Balint -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765799: qemu-system-x86: USB Passthrough Not Working
On 10/18/2014 01:55 PM, Dave Hellewell wrote: Package: qemu-system-x86 Version: 2.1+dfsg-5 Severity: normal Dear maintainer, USB passthrough is not working for qemu-system-x86_64 version 2.1.2 (Debian 2.1+dfsg-5). Passthrough methods attempted: - starting a guest image via qemu-system-x86_64 and appending '-usbdevice host:$bus.$addr' So what happens when you do this, what does qemu tell you? Does the user you run qemu as has read-write access to the devices in question? [] Running lsusb on the guest does not reveal the target device. Again, what does qemu tell you? When using libvirt methods to attach USB logs report: libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/007/021: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. This is clearly a libvirt problem. Libvirt runs qemu as an unprivileged user, and grants access to various privileged files/devices using special ways, so it should grant access to the required USB devices. I don't use this feature a lot so I can't be certain, but this used to work so I'm assuming the change has been intruduced with recent patching that upgraded a number of qemu packages. Using usb devices at low level like this has always been a privileged operation which required additional permissions. No upgrading can change that, the kernel always enforced that, and no of qemu binaries as shipped in official debian repositories had any additional privileges (like being set-uid etc). So if the problem is the lack of permission as you noted above, that has always been the case, unless, ofcourse, you start qemu as root (don't do that, qemu is a huge application and has never intended to be run as root). Unless there's anything else _besides_ the permission problems (the questions above), there's no bug and I'll close this bugreport. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714436: [Pkg-fonts-devel] Bug#714436: Bug#714436: Only three Hangul glyphs in it
2014-10-18 17:39 GMT+09:00 Christian PERRIER bubu...@debian.org: Coming back to this issue... This bug #714436 was filed when fonts-droid did not ship DroidSansFallback.ttf. So this bug has been fixed by #737105. But... I'm still not comfortable about modifying upstream files, even simply as you suggest. As I'm currently working to fix #762296, the two DroidSansFallback.ttf and DroidSansFallbackLegacy.ttf files will no longer be in fontconfig directories. Moving those two files will bring back this bug again. If we decide to drop Hangul from Droid font default installation, it's OK. But these three remaining Hangul glyphs in DroidSansFallbackFull will make problems. Removing two font files and leaving DroidSansFallbackFull only, it will make the three Hangul characters and others will be displayed in different fonts. Still, people can manually tweak their configuration to use them (and therefore better display Hangul charactersbut it seems that just installing fonts-nanum better does the job. So, shouldn't just fonts-droid Recommend fonts-nanum ? I think it is not necessary. There are many Hangul fonts nowadays. And DroidSansFallback has its own Hangul glyphs. So if anyone installs DroidSansFallback for displaying Hangul text, I think he/she wants Hangul glyphs from this font, not from other fonts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765421: Re: Re: Re: Bug#765421: jmapviewer/josm issue
I cooked up a patch that fetches the logo image if the embedded resource
isn't found in the package. The reason I did this instead of just
overriding the original code is to hopefully make it possibly more
upstreamable.
I tried building and installing the package with the patch applied and
Josm can successfully load Bing aerials with this.
//Marcus
diff -r jmapviewer-1.03+dfsg.orig/src/org/openstreetmap/gui/jmapviewer/tilesources/BingAerialTileSource.java jmapviewer-1.03+dfsg/src/org/openstreetmap/gui/jmapviewer/tilesources/BingAerialTileSource.java
5a6
import java.io.InputStream;
177c178,184
return ImageIO.read(JMapViewer.class.getResourceAsStream(images/bing_maps.png));
---
final InputStream imageResource =
JMapViewer.class.getResourceAsStream(images/bing_maps.png);
if (imageResource != null) {
return ImageIO.read(imageResource);
} else {
return ImageIO.read(new URL(http://dev.virtualearth.net/Branding/logo_powered_by.png;));
}
Bug#765598: python-xmpp: When I use python-xmpp, we have problem in package sslwrap.
Hello friends. At this morning, I update python package using apt-get update upgrade. The error now is these. File /etc/postfix/jabber.py, line 62, in module cl.connect(); File /usr/lib/python2.7/dist-packages/xmpp/client.py, line 205, in connect while not self.TLS.starttls and self.Process(1): pass File /usr/lib/python2.7/dist-packages/xmpp/dispatcher.py, line 303, in dispatch handler['func'](session,stanza) File /usr/lib/python2.7/dist-packages/xmpp/transports.py, line 330, in StartTLSHandler self._startSSL() File /usr/lib/python2.7/dist-packages/xmpp/transports.py, line 309, in _startSSL tcpsock._sslIssuer = tcpsock._sslObj.issuer() AttributeError: '_ssl._SSLSocket' object has no attribute 'issuer' ) 2014-10-16 18:46 GMT-03:00 Lucas Willian Bocchi lucas.boc...@gmail.com: Dear Cosimo. apt-get update upgrade on my jessie/sid (testing) never updates these package. Only unstable version have this pkt. 2014-10-16 12:58 GMT-03:00 Cosimo Alfarano cos...@alfarano.net: On 16 Oct 2014, at 14:42, Lucas Willian Bocchi lucas.boc...@gmail.com wrote: Command output: An error occurred while looking up _xmpp-client._tcp.gbocchi.com.br Traceback (most recent call last): File /etc/postfix/jabber.py, line 62, in module cl.connect(); File /usr/lib/python2.7/dist-packages/xmpp/client.py, line 205, in connect while not self.TLS.starttls and self.Process(1): pass File /usr/lib/python2.7/dist-packages/xmpp/dispatcher.py, line 303, in dispatch handler['func'](session,stanza) File /usr/lib/python2.7/dist-packages/xmpp/transports.py, line 330, in StartTLSHandler self._startSSL() File /usr/lib/python2.7/dist-packages/xmpp/transports.py, line 308, in _startSSL tcpsock._sslObj= socket.ssl(tcpsock._sock, None, None) File /usr/lib/python2.7/socket.py, line 64, in ssl return _realssl.sslwrap_simple(sock, keyfile, certfile) File /usr/lib/python2.7/ssl.py, line 980, in sslwrap_simple ssl_sock = _ssl.sslwrap(sock, 0, keyfile, certfile, CERT_NONE, AttributeError: 'module' object has no attri bute 'sslwrap' ) Hi Lucas, thank you for reporting this issue. I believe it's related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762010 which should now be fixed. Can you try to install the new package and see if it fixes the issue, please? thanks, Cosimo. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765421: jmapviewer: Resolution for missing Bing logo
On 10/18/2014 12:12 PM, Felix Natter wrote: the good news is I have received a mail from a Microsoft employee (unfortunately late on Friday) inviting me on a call regarding use of the Bing logo in jmapviewer. I will make that call on Monday morning and maybe we will be able to agree on a free license that I can put in debian/copyright and thus I can re-include bing_maps.png If they license the logo under a DFSG compatible license that would be great. And making our lives much easier. But if MS decides the logo must not be included in jmapviewer then I'm afraid I *must* remove BingAerialTileSource.java from jmapviewer and apply the attached patch [1] to 0.0.svn7480+dfsg1-2, removing Bing support from JOSM. Otherwise jmapviewer may be moved to non-free because it contains Bing support but not the logo [2]. I'm not sure that the alternative is that you *must* remove the Bing support from jmapviewer. The logo referenced by the BrandLogoUri in the attribution REST-call be fine the use instead of the bing_map.png included in jmapviewer. As mentioned by Martin Krüger: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765421#30 The Bing license says: and if the required logos and copyright notices are not included in the service generated content, you shall add the logos and copyright notices provided by Microsoft to the service generated content as described in the SDKs Since the attribution REST-call includes the logo in its generated content, downloading and using that instead of adding it in jmapviewer itself seems to comply with the license. -- can we agree on this? In the interest of our JOSM users, doing our best to prevent the removal of Bing support in jmapviewer should be our priority. Please discuss the BrandLogoUri solution with Microsoft in your call, that seems to be the preferred solution to keep jmapviewer and its rdeps in main, while also complying with the Bing license terms. While my brief tests with your patch show that JOSM works fine without Bing support, it's a major loss of functionality. MapBox Satellite and other freely usable satellite imagery is not on par with the Bing imagery. Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765579: cowbuilder and eatmydata
Mattia Rizzolo dixit: It should work just fine provided that 1) the target arch is the same as the host This is something that will, for me, almost never be the case. I currently have 22 chroots, one (1) of them being the same as the host arch (x32); the others are all for a different architecture (i386 or amd64). But to work like that, or in the foreign-arch /bin/bzip2 example we had earlier in this mail thread, is precisely what’s needed in a M-A scenario. We *really* need that to work. Maybe we should involve the glibc people and ask how we can do an automatic-architecture LD_PRELOAD. 2) the target chroot has the libeatmydata1 package installed That is something I can easily do (backport it). bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765795: openblas: new upstream version (0.2.12) + patch
tags 765795 patch I have had a go at it. Besides a bunch of patch refresh, the package builds fine. I have forwarded my debian.tar.xz Cheers, Ghis openblas_0.2.12-1.debian.tar.xz Description: application/xz
Bug#765421: jmapviewer/josm issue
On 10/18/2014 12:42 PM, Marcus Lundblad wrote: I cooked up a patch that fetches the logo image if the embedded resource isn't found in the package. The reason I did this instead of just overriding the original code is to hopefully make it possibly more upstreamable. I tried building and installing the package with the patch applied and Josm can successfully load Bing aerials with this. Thanks for your patch. Now we have code for two possible solutions to our problem. Ideally the logo URL is not hardcoded but extracted from the attribution response. If the service changes the URL the code doesn't need changing. Is it possible to implement that in your patch? Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#405833: reopening dia bugs that are nofixed upstream
unarchive 405833 unarchive 492400 unarchive 497896 unarchive 519721 unarchive 601356 reopen 405833 reopen 492400 reopen 497896 reopen 519721 reopen 601356 notfixed 405833 dia/0.97.2-1 notfixed 492400 dia/0.97.2-1 notfixed 497896 dia/0.97.2-1 notfixed 497896 dia/0.97.2-1 notfixed 601356 dia/0.97.2-1 stop Le samedi 26 avril 2014 à 10:29:03, Steve Cotton a écrit : Hi Stéphane, Upstream's dia-0-97 branch branched in 2009, and doesn't include some of these bugfixes. The last common commit is 7ee04f30. I've retested #519721, and it is still in 0.97.2-15. I haven't tested the others, but git-cherry can't find a corresponding commit in dia-0-97 for any of them. OTOH, I don't think #519721 is important enough for a local Debian patch. Sorry, Steve I reopen this bug before finally forgotten that they are not corrected. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748867: patch: Let's fix this by adding APIKEY
Il 18/10/2014 11:12, Osamu Aoki ha scritto: I understand Mike's (long term) plan to separate APIKEY to different package. But, at least for now, can we have functioning package in testing without reading and manually tweeking the system? Any reason not to update this? Then with next package, Mike can do whatever as long as it is cordinated with ftp-master for the new package. Oh well, so if you understand Mike's (long term) plan, can you please make me understand why people should change APIKEY? And so we have chromium broken for a month only for the very small number of people that will change APIKEY? Cheers, Giuseppe. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765749: icedove: empty folder pane
Hello Gary!
On Fri, Oct 17, 2014 at 03:07:30PM -0400, Gary Dale wrote:
I restarted my computer and launched icedove. The folder pane was present but
empty
while the messages pane just showed one e-mail with a non-working read e-mail
button.
* What exactly did you do (or not do) that was effective (or ineffective)?
Searched the Internet for similar problems. Tried removing session.json and
folders.json.
Tried a few add-ons that were supposed to be able to help. Purged Icedove and
reinstalled.
Installed the version from Sid.
What happen is you restart Icedove with the option -safe-mode from a
command line? This disables all plugin for the next session.
What plugins do you have running?
Are this plugins all installed from the Debian archives or have you some
plugins manually installed.
Tried starting from Konsole. Got this message:
(process:23945): GLib-CRITICAL **: g_slice_set_config: assertion
'sys_page_size == 0' failed
This behavior is normal, this doesn't come from Icedove. This message
commes from the glibc.
Tried starting from Konsole using icedove -jsconsole and got this message in
the error console:
Timestamp: 17/10/14 03:02:07 PM
Warning: mutating the [[Prototype]] of an object will cause your code to run
very slowly; instead create the object with the correct initial [[Prototype]]
value using Object.create
Source File: resource://gre/components/steelApplication.js
Line: 783
The hint says that the internal usage of functions and prototypes is not
correct. This is upstream related and is depended on the internal
restructure done by Mozilla.
Searched for Application.js. Closest I could find was in /usr/local/sushi.
Tried reinstalling
sushi and found that it wasn't installed. Installed it. After that had no
impact, I purged
sushi.
shushi has nothing to with Icedove. And /usr/local/... is nothing that
come from any official Debian package. ;)
The steelApplication.js is shipped within the upstream sources:
git grep steelApplication.js
mail/installer/package-manifest.in:@BINPATH@/components/steelApplication.js
mail/installer/removed-files.in: components/steelApplication.js
mail/steel/moz.build:'steelApplication.js',
mail/steel/steelApplication.manifest:component
{f265021a-7f1d-4b4b-bdc6-9aedca4d8f13} steelApplication.js
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765801: mount: fails to mount vfat filesystem unless -t vfat used
Package: mount Version: 2.25.1-5 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Attempting to mount a 16 gigabyte microsd installed in a Nokia C5-00 handset when handset was set to provide USB mass-storage interface. The microsd card had previously been removed from the handset and fsck -av run on it. dmesg reported: [154083.838576] usb 2-2: new high-speed USB device number 7 using ehci-pci [154083.972067] usb 2-2: New USB device found, idVendor=0421, idProduct=0594 [154083.972075] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber= 3 [154083.972077] usb 2-2: Product: C5-00.3 [154083.972080] usb 2-2: Manufacturer: Nokia [154083.972081] usb 2-2: SerialNumber: 357007040736419 [154083.973883] usb-storage 2-2:1.0: USB Mass Storage device detected [154083.974386] scsi host13: usb-storage 2-2:1.0 [154084.973580] scsi 13:0:0:0: Direct-Access NokiaS60 1.0 PQ: 0 ANSI: 0 [154084.974428] sd 13:0:0:0: Attached scsi generic sg3 type 0 [154084.977220] sd 13:0:0:0: [sdc] Attached SCSI removable disk [154089.207239] sd 13:0:0:0: [sdc] 31116288 512-byte logical blocks: (15.9 GB/14 .8 GiB) [154089.374942] sdc: [154089.380998] sd 13:0:0:0: [sdc] [154089.381006] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [154089.381008] sd 13:0:0:0: [sdc] [154089.381010] Sense Key : Not Ready [current] [154089.381013] sd 13:0:0:0: [sdc] [154089.381017] Add. Sense: Medium not present [154089.381019] sd 13:0:0:0: [sdc] CDB: [154089.381021] Read(10): 28 00 01 da cb 80 00 00 08 00 [154089.381029] end_request: I/O error, dev sdc, sector 31116160 [154089.383111] sd 13:0:0:0: [sdc] [154089.383117] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [154089.383119] sd 13:0:0:0: [sdc] [154089.383120] Sense Key : Not Ready [current] [154089.383123] sd 13:0:0:0: [sdc] [154089.383127] Add. Sense: Medium not present [154089.383129] sd 13:0:0:0: [sdc] CDB: [154089.383130] Read(10): 28 00 01 da cb f0 00 00 08 00 [154089.383138] end_request: I/O error, dev sdc, sector 31116272 [154089.384427] sd 13:0:0:0: [sdc] [154089.384433] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [154089.384435] sd 13:0:0:0: [sdc] [154089.384437] Sense Key : Not Ready [current] [154089.384441] sd 13:0:0:0: [sdc] [154089.38] Add. Sense: Medium not present [154089.384446] sd 13:0:0:0: [sdc] CDB: [154089.384448] Read(10): 28 00 01 da cb f0 00 00 08 00 [154089.384456] end_request: I/O error, dev sdc, sector 31116272 [154089.384460] Buffer I/O error on device sdc, logical block 3889534 [154089.396911] sd 13:0:0:0: [sdc] [154089.396919] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [154089.396921] sd 13:0:0:0: [sdc] [154089.396923] Sense Key : Not Ready [current] * What exactly did you do (or not do) that was effective (or ineffective)? # mount /dev/sdc /mnt/nokia mount: wrong fs type, bad option, bad superblock on /dev/sdc, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. # mount -t vfat /dev/sdc /mnt/nokia succeeds. (there is no uncommented entry for /mnt/nokia or /dev/sdc in /etc/fstab) Furthermore, blkid does not show the device. * What was the outcome of this action? * What outcome did you expect instead? If mount cannot reliably detect vfat it should be documented. *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.17.0+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mount depends on: ii libc6 2.19-11 ii libmount1 2.25.1-5 ii libselinux12.3-2 ii libsmartcols1 2.25.1-5 mount recommends no packages. Versions of packages mount suggests: pn nfs-common none -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661712: dvswitch: Provide some information about the free space of the hd
On Sat, 2014-10-18 at 10:42 +0200, Petter Reinholdtsen wrote:
I don't see the point of doing this in DVswitch. There are applets
for this and a stock GNOME installation will warn on low disk space.
I believe it would be nice to see the amount of disk free where I look
to check if the dvsink is working, and made a untested draft patch to
do so.
Something along these lines would help me a bit when doing video
recordings:
Index: src/dvsink-files.c
===
--- src/dvsink-files.c (revision 414)
+++ src/dvsink-files.c (working copy)
@@ -17,6 +17,7 @@
#include sys/types.h
#include sys/stat.h
#include unistd.h
+#include sys/statfs.h
#include config.h
#include dif.h
@@ -162,6 +163,19 @@
return total;
}
+/* Return the amount of megabyte free on the disk of the file descriptor */
+static long freespace(int fd)
+{
+struct statfs stat;
+long free;
+if (0 == fstatfs(fd, stat))
From statfs(2):
Linux-specific. The Linux statfs() was inspired by the 4.4BSD one (but
they do not use the same structure).
[...]
LSB has deprecated the library calls statfs() and fstatfs() and tells
us to use statvfs(2) and fstatvfs(2) instead.
+{
+free = stat.f_bsize * stat.f_bavail / (1024*1024) ;
+} else {
+free = -1;
+}
+}
This is not even self-consistent in brace placement!
static void transfer_frames(struct transfer_params * params)
{
static uint8_t buf[SINK_FRAME_HEADER_SIZE + DIF_MAX_FRAME_SIZE];
@@ -207,7 +221,8 @@
file = create_file(output_name_format, name);
if (starting)
printf(INFO: Started recording\n);
- printf(INFO: Created file %s\n, name);
+ long free = freespace(file);
Local variable free hides global function free().
+ printf(INFO: Created file %s - free space $ld MiB\n, name,
free);
So it prints free space -1 MiB in case of error??
Ben.
fflush(stdout);
}
Perhaps something to include?
--
Ben Hutchings
Life is what happens to you while you're busy making other plans.
- John Lennon
signature.asc
Description: This is a digitally signed message part
Bug#765802: util-linux: blkid fails to show mass-storage device on USB connected mobile handset
Package: util-linux Version: 2.25.1-5 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Connecting my Nokia C5-00 handset to the machine running Debian via USB cable and selecting mass storage as the connection option on the handset. * What exactly did you do (or not do) that was effective (or ineffective)? mount -t vfat worked but mount without the vfat filesystem type failed (see Debian bug report #765801). It appears that the filesystem detection used by mount and blkid failed. * What was the outcome of this action? * What outcome did you expect instead? blkid should show all block devices with recognisable filesystems on them that are currently active on the machine. *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.17.0+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages util-linux depends on: ii initscripts2.88dsf-53.4 ii libblkid1 2.25.1-5 ii libc6 2.19-11 ii libmount1 2.25.1-5 ii libncurses55.9+20140913-1 ii libpam0g 1.1.8-3.1 ii libselinux12.3-2 ii libslang2 2.3.0-1 ii libsmartcols1 2.25.1-5 ii libtinfo5 5.9+20140913-1 ii libuuid1 2.25.1-5 ii lsb-base 4.1+Debian13 ii tzdata 2014h-2 ii zlib1g 1:1.2.8.dfsg-2 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 3.0.26-4 ii kbd 1.15.5-1 ii util-linux-locales 2.25.1-5 -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661712: dvswitch: Provide some information about the free space of the hd
On Sat, 2014-10-18 at 10:42 +0200, Petter Reinholdtsen wrote:
I don't see the point of doing this in DVswitch. There are applets
for this and a stock GNOME installation will warn on low disk space.
I believe it would be nice to see the amount of disk free where I look
to check if the dvsink is working, and made a untested draft patch to
do so.
Something along these lines would help me a bit when doing video
recordings:
Index: src/dvsink-files.c
===
--- src/dvsink-files.c (revision 414)
+++ src/dvsink-files.c (working copy)
@@ -17,6 +17,7 @@
#include sys/types.h
#include sys/stat.h
#include unistd.h
+#include sys/statfs.h
#include config.h
#include dif.h
@@ -162,6 +163,19 @@
return total;
}
+/* Return the amount of megabyte free on the disk of the file descriptor */
+static long freespace(int fd)
+{
+struct statfs stat;
+long free;
+if (0 == fstatfs(fd, stat))
From statfs(2):
Linux-specific. The Linux statfs() was inspired by the 4.4BSD one (but
they do not use the same structure).
[...]
LSB has deprecated the library calls statfs() and fstatfs() and tells
us to use statvfs(2) and fstatvfs(2) instead.
+{
+free = stat.f_bsize * stat.f_bavail / (1024*1024) ;
+} else {
+free = -1;
+}
+}
This is not even self-consistent in brace placement!
static void transfer_frames(struct transfer_params * params)
{
static uint8_t buf[SINK_FRAME_HEADER_SIZE + DIF_MAX_FRAME_SIZE];
@@ -207,7 +221,8 @@
file = create_file(output_name_format, name);
if (starting)
printf(INFO: Started recording\n);
- printf(INFO: Created file %s\n, name);
+ long free = freespace(file);
Local variable free hides global function free().
+ printf(INFO: Created file %s - free space $ld MiB\n, name,
free);
And if free 0?
Ben.
fflush(stdout);
}
Perhaps something to include?
--
Ben Hutchings
Life is what happens to you while you're busy making other plans.
- John Lennon
--
Ben Hutchings
Life is what happens to you while you're busy making other plans.
- John Lennon
signature.asc
Description: This is a digitally signed message part
Bug#765803: tech-ctte: Ask before changing init system when upgrading to jessie and Inform about init systems when installing jessie
Package: tech-ctte Severity: Important When upgrading an old system installing certain packages, like network-manager and gdm3 systemd-sysv is installed changing the init system. These packages depend on libpam-systemd, which depends on systemd-sysv | systemd-shim. If systemd-shim is not installed systemd-sysv will be, and the init system changes the default to systemd-sysv, and changing PID 1. Changing init system, i.e. PID1, should be warned about loudly by debconf. Not all users want to change init system when doing and upgrade, of course this should not happen (sometimes unnoticed by upgrading a lot of packages). For new installations the situation is different, systemd is the default init system. Nevertheless, perhaps even for new installations the user should be given a choice. At least on how to reinstall sysvinit-core after installing the default init system: systemd-sysv in the Debian Installer (DI) (if not solvable by other means in the DI). The bug on (and the discussion there) on systemd-sysv: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747535 has ping-ponged in severity and the systemd maintainers always downgrade the severity to wishlist and tagged it wontfix. The only way to resolve this issue is that the CTTE makes a decision on this matter. Other bugs related to this issue are: 760601 764186 746578 In summary, the CTTE is asked to make a decision on debconf warnings on: 1) Changing init system on upgrades (including sid) 2) Inform about alternate init systems for new installations Thank you for your attention! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709569: [PATCH xrandr] Mention of --brightness with -h option
tags 709569 + fixed-upstream stop See http://cgit.freedesktop.org/xorg/app/xrandr/commit/?id=20d76f773cf8de474cf7a3f1082961605732c3f1 Fixed in version xrandr-1.4.3 (2014-08-02) -- Stéphane Aulery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763164: bash: Bash function exporting appears to be working again now
Package: bash Followup-For: Bug #763164 I have upgraded to bash 4.3-11 and this problem is no longer reproducible. I notice in the changlog that the initial Shellshock fixes have been replaced with upstream patches, which presumably work a bit differently. I believe this bug can be closed. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.utf8) Shell: /bin/sh linked to /bin/bash Versions of packages bash depends on: ii base-files 7.5 ii dash 0.5.7-4 ii debianutils 4.4 ii libc62.19-11 ii libncurses5 5.9+20140913-1 ii libtinfo55.9+20140913-1 Versions of packages bash recommends: pn bash-completion none Versions of packages bash suggests: pn bash-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765341: more information
Hi Klaumi!
Regarding (1):
El 16/10/14 a les 23:53, Klaumi Klingsporn ha escrit:
You find a sample-project at:
https://www.dropbox.com/s/79d6p6sri6shlj5/sample-project.tgz?dl=0
Thanks, that sample project helped a lot to track down the problem! :-)
I identified the problem as a bug in wxWidgets 3.0. In order to fulfill
clipboard operations, they have to process GDK events. Unfortunately,
the processing isn't sufficiently protected and processes not only
clipboard events, but all kinds of stuff - like wxShowEvent and
wxTimerEvent, which in our case perform clipboard operations on their
own and cause the reentry.
If you want the details, you can find them in the upstream bug report I
filed:
http://trac.wxwidgets.org/ticket/16636
Actually the situation was even worse in wxWidgets 2.8: While in 3.0
they have a porous safety net in the event processing, in 2.8 they
didn't have any safety net at all. BUT:
* Audacity had its own safety net in place as a workaround - which,
however is now incompatible with wxWidgets' own safety net (they both
rely on changing the GDK event handler - whoever does the change later,
wins).
* The distribution of the clipboard operations (in which event they are
processed) in Audacity with 2.8 was more fortunate.
So I tried to work around this by shifting the moment of doing the event
processing that involves clipboard operations at a moment at which we
can be certain of not being in a YieldFor(..) call (and therefore not in
a clipboard operation executed before). I hope that I've covered all
dangerous processings, it's not easy to identify them. I've attached a
patch (wxwidgets-clipboard-reentry-workaround.patch) that works for me
with the audacity-2.0.6-1 package. Do you have the chance to try it? Or
do you want me to provide a binary package for you to try it or something?
3. Segmentation fault on applying LV2 plugins
[...]
Only an idea of an user-only: Maybe it has something to do with my
extra set configure-flag --with-lv2=system.
I think there's a good chance that it's related to that. However, could
you be more specific about the LV2 plugin you tried and where it comes
from? The crash that I could produce turned out to be more related to
the LV2 plugin itself than audacity.
Cheers,
Martin
Description: Workaround for wxWidgets bug: Reentry in clipboard
The wxWidgets bug http://trac.wxwidgets.org/ticket/16636 prevents
us from doing clipboard operations in wxShowEvent and wxTimerEvent
processing because those event could possibly be processed during
the (not sufficiently protected) Yield() of a first clipboard
operation, causing reentry. Audacity had a workaround in place
for this problem (the class CaptureEvents), which however isn't
applicable with wxWidgets 3.0 because it's based on changing the
gdk event handler, a change that would be overridden by wxWidgets's
own gdk event handler change.
Instead, as a new workaround, specifically protect those processings
of wxShowEvent and wxTimerEvent that try to do clipboard operations
from being executed within Yield(). This is done by delaying their
execution by posting pure wxWidgets events - which are never executed
during Yield().
Author: Martin Steghöfer mar...@steghoefer.eu
Bug-Debian: https://bugs.debian.org/765341
--- a/src/Project.cpp
+++ b/src/Project.cpp
@@ -1625,9 +1625,13 @@
// Call OnSize again (the previous calls to OnSize might not
// have succeeded because some methods are not available before
- // the actual creation/showing of the window)
- wxSizeEvent sizeEvent(GetSize());
- OnSize(sizeEvent);
+ // the actual creation/showing of the window).
+ // Post the event instead of calling OnSize(..) directly. This ensures that
+ // this is a pure wxWidgets event (no GDK event behind it) and that it
+ // therefore isn't processed within the YieldFor(..) of the clipboard
+ // operations (workaround for Debian bug #765341).
+ wxSizeEvent *sizeEvent = new wxSizeEvent(GetSize());
+ GetEventHandler()-QueueEvent(sizeEvent);
// Further processing by default handlers
event.Skip();
--- a/src/TrackPanel.cpp
+++ b/src/TrackPanel.cpp
@@ -360,6 +360,8 @@
EVT_MENU(OnTimeTrackLinID, TrackPanel::OnTimeTrackLin)
EVT_MENU(OnTimeTrackLogID, TrackPanel::OnTimeTrackLog)
EVT_MENU(OnTimeTrackLogIntID, TrackPanel::OnTimeTrackLogInt)
+
+EVT_TIMER(wxID_ANY, TrackPanel::OnTimer)
END_EVENT_TABLE()
/// Makes a cursor from an XPM, uses CursorId as a fallback.
@@ -927,7 +929,7 @@
}
/// AS: This gets called on our wx timer events.
-void TrackPanel::OnTimer()
+void TrackPanel::OnTimer(wxTimerEvent event)
{
mTimeCount++;
// AS: If the user is dragging the mouse and there is a track that
--- a/src/TrackPanel.h
+++ b/src/TrackPanel.h
@@ -207,7 +207,7 @@
virtual double GetMostRecentXPos();
- virtual void OnTimer();
+ virtual void OnTimer(wxTimerEvent event);
virtual int GetLeftOffset() const { return
Bug#765804: libblkid1: vfat detection failing on Nokia C5-00 handset USB connected as mass storage
Package: libblkid1 Version: 2.25.1-5 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Both blkid and mount without the -t vfat option failed to detect the 16 GB microsd card installed in my Nokia C5-00 handset and shared as USB mass-storage. Please see bugs #765801 and #765802. * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.17.0+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libblkid1 depends on: ii libc6 2.19-11 ii libuuid1 2.25.1-5 ii multiarch-support 2.19-11 libblkid1 recommends no packages. libblkid1 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765795: openblas: new upstream version (0.2.12)
Le samedi 18 octobre 2014 à 10:08 +0100, Ghislain Antony Vaillant a écrit : Source: openblas Severity: wishlist Dear Maintainer, A new upstream version has been released (0.2.12) with a bunch of fixes [1]. For some reasons, the PTS failed to track the new release though uscan picks it up. I am not sure I can get this version into Jessie. The reason is that I want first version 0.2.11-3 to migrate to jessie, since it contains coordinated changes (blas.pc/lapack.pc) with the other BLAS implementations. The migration should happen October 25th if everything goes well. Then I could upload 0.2.12, which will take 10 days to migrate, so maybe it can make it before the freeze (November 5th), but the time margin is very tight (I am actually not even sure that this is feasible). Uploading 0.2.12 right now would mean taking the risk of not having the coordinated changes (blas.pc/lapack.pc) in jessie (because 0.2.12 could introduce new problems), and I don't want to take that risk. In the worst case, if 0.2.12 does not make it into jessie, it will still possible to fix issues in jessie that are of severity important or higher (in practice, that means crashes or wrong calculated results). If you are aware of such fixes that are incorporated into 0.2.12, you can either tell me or open new bugs against openblas (linking to upstream bug reports and commits). Thanks, -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://sebastien.villemot.name `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Bug#765805: FTBFS: Drop libjpeg8-dev from Build-Depends to unbreak build
Package: src:openlugaru Version: 0~20110520.1+hge4354+dfsg-4 Severity: serious Justification: FTBFS -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, please drop libjpeg8-dev from your Build-Depends to allow building the package again. I have a working NMU (with just that change), so if you are unable to fix this yourself, please say so. (I will also upload the NMU if I don't hear from you to speed up the transition to src:libjpeg-turbo). Cheers, Ondrej - -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (700, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJUQk2sXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMEI5MzNEODBGQ0UzRDk4MUEyRDM4RkIw Qzk5QjcwRUY0RkNCQjA3AAoJEAyZtw70/LsHA+wQAJf67zfP5w89VUXBlpRN79IW 3RKB6NCO3jgNgJ0Ax1c91dQ6admDv+t1ekXyu6qF8RDKFDgTNUQ4w6L+QICwC4Tg xuR8oU9dEB1zFf48k/8RK5sNIiH53vUBjEvjhdiupzNzbksQkJCN1wt5XXW6PfPa 2KDnxL9UCfij7B0qdGjhqToituR0wdCGtoPalED2uRZGU02hSGNXbIZDLdMfL3Dl 00AOVyJk0mU0rPUWfozMFROgdUL8tyzl1Oj0qRCdw/F2BFhXut8oh2JpdORmmQ9Z E6/1FZa7RYWFV61nnZeAyckMxAAUQaVd4Glv1AP1f3oZNZ/RFBT3Am6xbp8wqW90 4OMXr8FlAWpDyuqzUSKQa9lSS0Z1XnHBiOOvI203C7c8tdgl8beaAbIJBY2pf0+O 2f/78Dg1hDh/52xsD/o8dePV+9VwnAIrj8sS/UpNH1Op9bJ2IDegGX6y1gmeiUnm n0nj4g7TvqgHdhckQJ9KSyAoUxdRszWPmLga3W33Dj+rfLHONozzLaDZAABGXBCp AZi7N+H+GMCqvvHYlSbYJttRrU7sL81/bCeANGosm5Oq9Z67CFEFotwBOGO+74nr KbJB9WI6LKmkOdUgxswnHFdz0pkhIWvUwhx+3Un1NwSKX5/dXVKjbd/e2Z2VtX/i 5h/Zp/MIB2KWDRfjHQtt =HzD0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765801: mount: fails to mount vfat filesystem unless -t vfat used
Package: mount Version: 2.25.1-5 Followup-For: Bug #765801 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? Downgrading libblkid1 to 2.20.1-5.11 also fixed the problem. * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.17.0+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mount depends on: ii libc6 2.19-11 ii libmount1 2.25.1-5 ii libselinux12.3-2 ii libsmartcols1 2.25.1-5 mount recommends no packages. Versions of packages mount suggests: pn nfs-common none -- no debconf information -- debsums errors found: prelink: /bin/findmnt: at least one of file's dependencies has changed since prelinking debsums: changed file /bin/findmnt (from mount package) prelink: /bin/mount: at least one of file's dependencies has changed since prelinking prelink: /bin/umount: at least one of file's dependencies has changed since prelinking prelink: /sbin/swapoff: at least one of file's dependencies has changed since prelinking debsums: changed file /sbin/swapoff (from mount package) prelink: /sbin/swapon: at least one of file's dependencies has changed since prelinking debsums: changed file /sbin/swapon (from mount package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765802: util-linux: blkid fails to show mass-storage device on USB connected mobile handset
Package: util-linux Followup-For: Bug #765802 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? Downgrading to libblkid1:amd642.20.1-5.11 util-linux 2.20.1-5.3 restored the ability of blkid to show the block device shared via USB mass-storage from the Nokia C5-00 handset. * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.17.0+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages util-linux depends on: ii debconf [debconf-2.0] 1.5.53 ii dpkg 1.17.18 ii initscripts2.88dsf-53.4 ii install-info 5.2.0.dfsg.1-4 ii libblkid1 2.20.1-5.11 ii libc6 2.19-11 ii libncurses55.9+20140913-1 ii libselinux12.3-2 ii libslang2 2.3.0-1 ii libtinfo5 5.9+20140913-1 ii libuuid1 2.25.1-5 ii lsb-base 4.1+Debian13 ii tzdata 2014h-2 ii zlib1g 1:1.2.8.dfsg-2 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 3.0.26-4 ii kbd 1.15.5-1 ii util-linux-locales 2.20.1-5.11 -- debconf information: util-linux/noauto-with-nonzero-passnum: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764421: Cannot reproduce
Hi, unfortunately i cannot reproduce this bug on a freshly installed Jessie system with onionshare 0.5-1. Cheers, u. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765804: libblkid1: vfat detection failing on Nokia C5-00 handset USB connected as mass storage
Package: libblkid1 Followup-For: Bug #765804 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? when I downgraded to: ii libblkid1:amd642.20.1-5.11 amd64block device id library ii libmount1:amd642.25.1-5 amd64device mounting library ii mount 2.25.1-5 amd64Tools for mounting and manipulating filesystems ii pmount 0.9.23-3 amd64mount removable devices as normal user ii udisks-glue1.3.5-1 amd64simple automount daemon with support for user-defined actions ii util-linux 2.20.1-5.3 amd64Miscellaneous system utilities ii util-linux-locales 2.20.1-5.11 all Locales files for util-linux mount worked without requiring -t vfat and blkid detected the block device shared as a USB mass storage device by the Nokia C5-00 handset. * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.17.0+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libblkid1 depends on: ii libc6 2.19-11 ii libuuid1 2.25.1-5 ii multiarch-support 2.19-11 libblkid1 recommends no packages. libblkid1 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661712: dvswitch: Provide some information about the free space of the hd
Thank you for the comments and the review. But the question I really need an answer to before continuing is if such change will be accepted or not. So far me and another user have seen the need for printing free space, while you have stated two years ago that you do not see the need. If the feature is interesting and acceptable, I can brush up the patch into a usable state, but if not I would rather spend the time elsewhere. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765573: hugin: Creation timestamp metadata not set on created panorama (regression)
On 2014-10-16 Ayke van Laethem aykevanlaet...@gmail.com wrote: I've seen this feature being referenced in a different bug, so it really was there before: https://bugs.launchpad.net/hugin/+bug/679932 were these two headers be copied from (one of) the input images or were they set by hugin (time of panorama generation)? They were set to the same time as the first input image. The first being the one with the oldest timestamp, the first in an alphabetic directory listing, or the first image being added. I'm not entirely sure how it picks the 'first' image, but as the Create time is the same, it must have copied it. Hello, thanks for the additional info. However, I cannot reproduce the problem. I have just taken some old images of mine and restitched them (starting freshly, not using the old project file) and indeed as you decribed Create Date|Date/Time Original was copied from the first image: ametzler@argenau:/tmp/Sospel$ exiftool testimage_fused.tif | grep -E 'Create Date|Date/Time Original' Date/Time Original : 2008:09:02 10:03:15 Create Date : 2008:09:02 10:03:15 Could you doublecheck whether some local setting is broken by temporarily moving away ~/.hugin and checking with a simple project (starting from scratch)? 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' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765565: [Pkg-openssl-devel] Bug#765565: Bug#765565: openssl: don't completely disable ssl3/2 but rather just don't use it
Kurt, Just realised that I'd replied to you off-list - my bad. I'm not really sure where this should be logged as separate bug (or a security issue?) - I'll leave that up to you guys. ~Robin On 17/10/14 23:42, Kurt Roeckx wrote: On Fri, Oct 17, 2014 at 11:21:38PM +0100, rbsec wrote: Kurt, I just re-ran sslscan with Wireshark capturing the traffic to take a look. I added a few more options to disable sslscan features to give a nice clean output - the only check performed is the preferred ciphersuite for the SSLv3 protocol. $ ./sslscan --no-heartbleed --no-compression --no-renegotiation --no-ciphersuites --no-check-certificate --ssl3 target Wireshark shows an SSLv3 handshake (SSL Version 0x0300 == SSLv3), and I get a ServerHello returned with the same version. Can you recreate this with sslscan? You seem to be right. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732391: unreproducible in 0.9.10.0-3
I also had this problem with -2, and it seems to have gone away with -3. FWIW, it seemed specific to my home dsl router. d -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748867: patch: Let's fix this by adding APIKEY
❦ 18 octobre 2014 13:13 +0200, Giuseppe Iuculano giuse...@iuculano.it : I understand Mike's (long term) plan to separate APIKEY to different package. But, at least for now, can we have functioning package in testing without reading and manually tweeking the system? Any reason not to update this? Then with next package, Mike can do whatever as long as it is cordinated with ftp-master for the new package. Oh well, so if you understand Mike's (long term) plan, can you please make me understand why people should change APIKEY? And so we have chromium broken for a month only for the very small number of people that will change APIKEY? Maybe the key is considered as non-free material. -- /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any * way. */ 2.4.3 linux/net/core/netfilter.c signature.asc Description: PGP signature
Bug#765565: [Pkg-openssl-devel] Bug#765565: Bug#765565: openssl: don't completely disable ssl3/2 but rather just don't use it
On Sat, Oct 18, 2014 at 01:06:29PM +0100, rbsec wrote: Kurt, Just realised that I'd replied to you off-list - my bad. I'm not really sure where this should be logged as separate bug (or a security issue?) - I'll leave that up to you guys. So my current understanding is that sslscan uses SSLv3_client_method(), and that that is probably the only way to still set up an SSL 3.0 connection. I don't plan to bring back SSL 3.0 support, just assume that it's going to go away. sslscan also doesn't seem to support TLS 1.1 or higher for some reason? Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765801: mount: fails to mount vfat filesystem unless -t vfat used
Package: mount Followup-For: Bug #765801 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? downgrading mount and related packages to 2.25.1-4 resulted in mount being able to work successfully without requiring the -t vfat option. * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.17.0+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mount depends on: ii libc6 2.19-11 ii libmount1 2.25.1-5 ii libselinux12.3-2 ii libsmartcols1 2.25.1-5 mount recommends no packages. Versions of packages mount suggests: pn nfs-common none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765747: RFS: openldap/2.4.40-1 [RC]
I backported your package to wheezy and upgraded a machine carrying a partial replica. The upgrade failed, so I added the -s option to the slapadd call in the postinst. Please consider using it. Btw. is the dump/restore necessary with MDB? I found no information about the format incompatibilities between the various versions. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765806: Some patches to get cgit special stuff working in debian
Package: cgit
Version: 0.10.2.git2.0.1-3
Hi,
thanks for packaging.
I have some old patches from my own packaging efforts
(https://build.opensuse.org/package/show/home:stbuehler/cgit):
* 0001-assume-highlight-version-3-in-filter-script.patch
this one is important and should be straight forward
* 0002-configure-cgit-make-options.patch
just for your information; I didn't look how you build it, but
perhaps it is useful to you.
* 0004-add-highlighting-rules-to-cgit.css.patch
perhaps this could be checked if it still matches the current
highlight output
* 0005-Force-man2html-groff-to-use-UTF-8-as-input-encoding.patch
UTF-8 is my own preference, not absolutely necessary
* 0006-Use-debian-binary-name-rst2html.patch
somehow obvious :)
0003 got fixed upstream, that is why I left it out :)
regards,
StefanFrom: =?UTF-8?q?Stefan=20B=C3=BChler?= stbueh...@web.de
Date: Fri, 10 May 2013 09:53:00 +0200
Subject: assume highlight version 3 in filter script
---
filters/syntax-highlighting.sh |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/filters/syntax-highlighting.sh b/filters/syntax-highlighting.sh
index 24f6bb4..2ff2032 100755
--- a/filters/syntax-highlighting.sh
+++ b/filters/syntax-highlighting.sh
@@ -53,7 +53,7 @@ EXTENSION=${BASENAME##*.}
# found (for example) on EPEL 6.
#
# This is for version 2
-exec highlight --force -f -I -X -S $EXTENSION 2/dev/null
+#exec highlight --force -f -I -X -S $EXTENSION 2/dev/null
# This is for version 3
-#exec highlight --force -f -I -O xhtml -S $EXTENSION 2/dev/null
+exec highlight --force -f -I -O xhtml -S $EXTENSION 2/dev/null
From: =?UTF-8?q?Stefan=20B=C3=BChler?= stbueh...@web.de
Date: Fri, 10 May 2013 10:55:14 +0200
Subject: configure cgit make options
---
cgit.conf |9 +
1 file changed, 9 insertions(+)
create mode 100644 cgit.conf
diff --git a/cgit.conf b/cgit.conf
new file mode 100644
index 000..cf9463c
--- /dev/null
+++ b/cgit.conf
@@ -0,0 +1,9 @@
+CGIT_SCRIPT_PATH=/usr/lib/cgi-bin
+CGIT_DATA_PATH=/usr/share/cgit
+V=1
+NO_OPENSSL=1
+SHA1_HEADER=block-sha1/sha1.h
+
+export V
+export NO_OPENSSL
+export SHA1_HEADER
From: =?UTF-8?q?Stefan=20B=C3=BChler?= stbueh...@web.de
Date: Wed, 29 May 2013 11:23:53 +0200
Subject: add highlighting rules to cgit.css
---
cgit.css | 17 +
1 file changed, 17 insertions(+)
diff --git a/cgit.css b/cgit.css
index d467c66..d3e48c7 100644
--- a/cgit.css
+++ b/cgit.css
@@ -800,3 +800,20 @@ div#cgit table.ssdiff td.space {
div#cgit table.ssdiff td.space div {
min-height: 3em;
}
+
+/* Style definition file generated by highlight 3.9, http://www.andre-simon.de/ */
+/* Highlighting theme: Kwrite Editor */
+/* adapted for cgit */
+div#cgit table.blob .num { color:#b07e00; }
+div#cgit table.blob .esc { color:#ff00ff; }
+div#cgit table.blob .str { color:#bf0303; }
+div#cgit table.blob .pps { color:#818100; }
+div#cgit table.blob .slc { color:#838183; font-style:italic; }
+div#cgit table.blob .com { color:#838183; font-style:italic; }
+div#cgit table.blob .ppc { color:#008200; }
+div#cgit table.blob .opt { color:#00; }
+div#cgit table.blob .lin { color:#55; }
+div#cgit table.blob .kwa { color:#00; font-weight:bold; }
+div#cgit table.blob .kwb { color:#0057ae; }
+div#cgit table.blob .kwc { color:#00; font-weight:bold; }
+div#cgit table.blob .kwd { color:#010181; }
From: =?UTF-8?q?Stefan=20B=C3=BChler?= stbueh...@web.de
Date: Wed, 29 May 2013 14:33:50 +0200
Subject: Force man2html/groff to use UTF-8 as input encoding
---
filters/html-converters/man2html |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/filters/html-converters/man2html b/filters/html-converters/man2html
index 1b28437..4975da4 100755
--- a/filters/html-converters/man2html
+++ b/filters/html-converters/man2html
@@ -1,5 +1,5 @@
#!/bin/sh
echo div style=\font-family: monospace\
-groff -mandoc -T html -P -r -P -l | egrep -v '(html|head|meta|title|/title|/head|body|/body|/html|!DOCTYPE|http://www.w3.org)'
+groff -mandoc -T html -K UTF-8 -P -r -P -l | egrep -v '(html|head|meta|title|/title|/head|body|/body|/html|!DOCTYPE|http://www.w3.org)'
echo /div
From: =?UTF-8?q?Stefan=20B=C3=BChler?= stbueh...@web.de
Date: Wed, 29 May 2013 14:34:15 +0200
Subject: Use debian binary name rst2html
---
filters/html-converters/rst2html |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/filters/html-converters/rst2html b/filters/html-converters/rst2html
index c51f5be..a1ba574 100755
--- a/filters/html-converters/rst2html
+++ b/filters/html-converters/rst2html
@@ -1,2 +1,2 @@
#!/bin/sh
-rst2html.py --template=$(dirname $0)/resources/rst-template.txt
+rst2html --template=$(dirname $0)/resources/rst-template.txt
Bug#742578: --simulate (etc) dropped from apt
Control: reopen -1 0.9.11 On Tue, Oct 14, 2014 at 07:28:54PM +1100, Zenaan Harkness wrote: Note that the comment from Ritesh below (above) The newer versions of apt have completely replaced --simulate with -s. is incorrect, as far as I can see Yeap, that is wrong, we still support -s and co, but … $ apt -s E: Command line option 's' [from -s] is not known. $ apt --simulate E: Command line option --simulate is not understood $ apt-get -s E: Command line option 's' [from -s] is not known. $ apt-get --simulate E: Command line option --simulate is not understood … not in the way you are trying it here. Since 0.9.11 apt is a bit stricter in its parsing of the commandline – for the benefit of the user – in that it doesn't allow options anymore for commands where they don't have an effect. So, apt-get dist-upgrade -s works, but e.g. apt-get download -s doesn't (Imagine the suprised look and dangerous effects if you run a command with -s, but the command doesn't understand it and acts normal as a consequence…). It doesn't work for source at the moment either, but that is a bug in sofar as there is actually code in the source command to handle the option, so we can accept it - it was simply overlooked in the rework. I am going to fix that to unbreak the previous usecases, even though I would advice using --print-uris here as what source does with the simulation flag is really not a simulation compared to what other commands like install do with it. Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#703710: killer CRON disabled on diskless workstations
Hi Petter, On Do 16 Okt 2014 13:58:56 CEST, Petter Reinholdtsen wrote: The disabling of cron jobs on diskless workstations is done by the script /usr/share/ltsp/plugins/ltsp-build-client/Debian-custom/032-edu-pkgs in the debian-edu-config package. It also, as you say, disable the killer cron job. This is the comment on top of that code block: # Disable the cron jobs that should not be running on a diskless # workstation. Keep rwhod, shutdown-at-night and # sitesummary-client. Should we run killer on diskless workstations and thin clients? I am not sure. If killer works reliably, then: yes (for diskless workstations). Otherwise, diskless workstations (not sure about thin clients, actually) will not get affected by shutdown-at-night if users forgot to log out. The expected behaviour would be for diskless workstations: o killer ends still-running / not-logged-off sessions after 6h of session duration o shutdown-at-night turns of the diskless machine within the next hour Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpBGAA1cODCE.pgp Description: Digitale PGP-Signatur
Bug#245065: [saul...@free.fr: Re: forwarded 245065]
tags 245065 + moreinfo stop Upstream need more info please : https://bugs.freedesktop.org/show_bug.cgi?id=66348#c1 Please provide some information why you need this, use-cases, etc. But if this bug is no longer relevant, please report me to closing, please. Thank you for your help. Thanks -- Stéphane Aulery ---BeginMessage--- Le samedi 29 juin 2013 à 02:50:28, Stéphane Aulery a écrit : forwarded 245065 https://bugs.freedesktop.org/show_bug.cgi?id=66348 tags 245065 + moreinfo stop Upstream need more info please : https://bugs.freedesktop.org/show_bug.cgi?id=66348#c1 Please provide some information why you need this, use-cases, etc. But if this bug is no longer relevant, please report me to closing, please. Thank you for your help. Thanks -- Stéphane Aulery ---End Message---
Bug#765795: openblas: new upstream version (0.2.12)
No problem. I know that the upcoming freeze makes for very tight timings. I will leave it like that until Jessie's release then. Besides, the changelog list does not that big so the most severe bugs should be manageable by subsequent patching. Merci Sebastien, Ghis On 18/10/14 12:40, Sébastien Villemot wrote: Le samedi 18 octobre 2014 à 10:08 +0100, Ghislain Antony Vaillant a écrit : Source: openblas Severity: wishlist Dear Maintainer, A new upstream version has been released (0.2.12) with a bunch of fixes [1]. For some reasons, the PTS failed to track the new release though uscan picks it up. I am not sure I can get this version into Jessie. The reason is that I want first version 0.2.11-3 to migrate to jessie, since it contains coordinated changes (blas.pc/lapack.pc) with the other BLAS implementations. The migration should happen October 25th if everything goes well. Then I could upload 0.2.12, which will take 10 days to migrate, so maybe it can make it before the freeze (November 5th), but the time margin is very tight (I am actually not even sure that this is feasible). Uploading 0.2.12 right now would mean taking the risk of not having the coordinated changes (blas.pc/lapack.pc) in jessie (because 0.2.12 could introduce new problems), and I don't want to take that risk. In the worst case, if 0.2.12 does not make it into jessie, it will still possible to fix issues in jessie that are of severity important or higher (in practice, that means crashes or wrong calculated results). If you are aware of such fixes that are incorporated into 0.2.12, you can either tell me or open new bugs against openblas (linking to upstream bug reports and commits). Thanks, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765802: util-linux: blkid fails to show mass-storage device on USB connected mobile handset
Package: util-linux Followup-For: Bug #765802 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? Downgrading util-linux and libblkid1 to versions: ii libblkid1:amd642.24.2-1 amd64block device id library ii util-linux 2.24.2-1 amd64Miscellaneous system utilities resulted in blkid correctly identifying the block device: /dev/sdc: UUID=3033-6165 TYPE=vfat These the most recent versions of libblkid1 and util-linux that seem to work for showing this block device. * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.17.0+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages util-linux depends on: ii debconf [debconf-2.0] 1.5.53 ii dpkg 1.17.18 ii initscripts2.88dsf-53.4 ii install-info 5.2.0.dfsg.1-4 ii libblkid1 2.24.2-1 ii libc6 2.19-11 ii libmount1 2.25.1-5 ii libncurses55.9+20140913-1 ii libpam0g 1.1.8-3.1 ii libselinux12.3-2 ii libslang2 2.3.0-1 ii libtinfo5 5.9+20140913-1 ii libuuid1 2.25.1-4 ii lsb-base 4.1+Debian13 ii tzdata 2014h-2 ii zlib1g 1:1.2.8.dfsg-2 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 3.0.26-4 ii kbd 1.15.5-1 ii util-linux-locales 2.25.1-4 -- debconf information: util-linux/noauto-with-nonzero-passnum: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765285: closed by Olivier Sallou osal...@debian.org (Bug#765285: fixed in mapsembler2 2.2.3+dfsg-1)
Control: reopen -1 On 2014-10-15 06:06:20, Debian Bug Tracking System wrote: mapsembler2 (2.2.3+dfsg-1) unstable; urgency=medium . * New upstream release * Fix some compilation issues * Fix FTBS on non x86 (Closes: #765285). Unfortunately it still fails on mips, mipsel and powerpc with | [ 97%] Building CXX object ext/gatb-core/tools/CMakeFiles/dbgh5.dir/dbgh5.cpp.o | Linking CXX executable ../bin/dbgh5 | ../lib/libgatbcore.a(Storage.cpp.o): In function `gatb::core::tools::storage::impl::BagHDF5gatb::core::tools::math::NativeInt8::insert(gatb::core::tools::math::NativeInt8 const*, unsigned int)': | /«BUILDDIR»/mapsembler2-2.2.3+dfsg/mapsembler2_extremities/thirdparty/gatb-core/src/gatb/tools/storage/impl/CollectionHDF5.hpp:102: undefined reference to `__sync_fetch_and_add_8' | ../lib/libgatbcore.a(BranchingAlgorithm.cpp.o): In function `gatb::core::tools::storage::impl::BagHDF5gatb::core::kmer::impl::Kmer64u::Count::insert(gatb::core::kmer::impl::Kmer64u::Count const*, unsigned int)': | /«BUILDDIR»/mapsembler2-2.2.3+dfsg/mapsembler2_extremities/thirdparty/gatb-core/src/gatb/tools/storage/impl/CollectionHDF5.hpp:102: undefined reference to `__sync_fetch_and_add_8' | ../lib/libgatbcore.a(BranchingAlgorithm.cpp.o): In function `gatb::core::tools::storage::impl::BagHDF5gatb::core::kmer::impl::Kmer96u::Count::insert(gatb::core::kmer::impl::Kmer96u::Count const*, unsigned int)': | /«BUILDDIR»/mapsembler2-2.2.3+dfsg/mapsembler2_extremities/thirdparty/gatb-core/src/gatb/tools/storage/impl/CollectionHDF5.hpp:102: undefined reference to `__sync_fetch_and_add_8' | ../lib/libgatbcore.a(BranchingAlgorithm.cpp.o): In function `gatb::core::tools::storage::impl::BagHDF5gatb::core::kmer::impl::Kmer128u::Count::insert(gatb::core::kmer::impl::Kmer128u::Count const*, unsigned int)': | /«BUILDDIR»/mapsembler2-2.2.3+dfsg/mapsembler2_extremities/thirdparty/gatb-core/src/gatb/tools/storage/impl/CollectionHDF5.hpp:102: undefined reference to `__sync_fetch_and_add_8' | ../lib/libgatbcore.a(BranchingAlgorithm.cpp.o): In function `gatb::core::tools::storage::impl::BagHDF5gatb::core::kmer::impl::Kmer32u::Count::insert(gatb::core::kmer::impl::Kmer32u::Count const*, unsigned int)': | /«BUILDDIR»/mapsembler2-2.2.3+dfsg/mapsembler2_extremities/thirdparty/gatb-core/src/gatb/tools/storage/impl/CollectionHDF5.hpp:102: undefined reference to `__sync_fetch_and_add_8' | ../lib/libgatbcore.a(DebloomAlgorithm.cpp.o):/«BUILDDIR»/mapsembler2-2.2.3+dfsg/mapsembler2_extremities/thirdparty/gatb-core/src/gatb/tools/storage/impl/CollectionHDF5.hpp:102: more undefined references to `__sync_fetch_and_add_8' follow | collect2: error: ld returned 1 exit status Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#765728: [Pkg-xfce-devel] Bug#765728: xfce4-session is not setting XDG_CURRENT_DESKTOP (affects Qt5)
On ven., 2014-10-17 at 16:24 +0100, Darren Salt wrote: Package: xfce4-session Version: 4.10.1-8 Tags: patch Qt5 selects a theme according to the value of XDG_CURRENT_DESKTOP. With this unset, Qt5 apps use its default theme, ignoring local configuration. If I set it to XFCE, they use a GTK+-like theme which fits in with the rest of the desktop (well, almost – there's a bug in Qt5's font rendering). See also https://forum.manjaro.org/index.php?topic=13728 I have to admin I'm a bit puzzled at this. Looking around I can find an old thread from 2011 [1] with no real conclusion. And for example it's seems unclear if it should be set by the DM or by the session script itself. LightDM apparently [2] supports setting that variable if it's set in the Xsession .desktop file, I'll check that and report back. Unfortunately it won't work with the “default” session (which uses the Debian alternatives system), so maybe the patch is still useful. Regards, [1]: http://lists.freedesktop.org/archives/xdg/2011-July/012004.html [2]: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1212408 -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#765565: [Pkg-openssl-devel] Bug#765565: Bug#765565: openssl: don't completely disable ssl3/2 but rather just don't use it
Kurt, You're correct that sslscan uses SSLv3_client_method() - it also uses the SSLv2, TLS1.0, 1.1 and 1.2 equivalents as well depending on which protocols are enabled in OpenSSL (and which ones it's told to scan with commandline options). TLSv1.2 is supported (it can be forced with --tls12) - not sure why that wouldn't be working for you. I'm fully expecting SSLv3 to stop working in sslscan on Debian (just like it did when SSLv2 was disabled a while back). I installed sid so that I could patch sslscan so it would still build and run properly (albeit with a warning message) if there was no SSLv3 support in the library) - which is when I found that SSLv3 was still working despite the appearance that it wouldn't. Once the SSLv3 stuff is properly gone I can look at patching sslscan, and also updating the script that comes with it to rebuild OpenSSL with SSLv2 (and now SSLv3) support). Thanks, ~Robin On 18/10/14 13:28, Kurt Roeckx wrote: On Sat, Oct 18, 2014 at 01:06:29PM +0100, rbsec wrote: Kurt, Just realised that I'd replied to you off-list - my bad. I'm not really sure where this should be logged as separate bug (or a security issue?) - I'll leave that up to you guys. So my current understanding is that sslscan uses SSLv3_client_method(), and that that is probably the only way to still set up an SSL 3.0 connection. I don't plan to bring back SSL 3.0 support, just assume that it's going to go away. sslscan also doesn't seem to support TLS 1.1 or higher for some reason? Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757375: Debian bug #757375
fixed 757375 ipmitool/1.8.14-4~bpo70+1 thanks. Hello, the support is included in version 1.8.14-4~bpo70+1. CU Jörg -- pgp Fingerprint: 7D13 3C60 0A10 DBE1 51F8 EBCB 422B 44B0 BE58 1B6E pgp Key: BE581B6E CAcert Key S/N: 0E:D4:56 Jörg Frings-Fürst D-54526 Niederkail Threema-ID: SYR8SJXB IRC: j_...@freenode.net, j_...@oftc.net signature.asc Description: This is a digitally signed message part.
Bug#765807: torbrowser-launch: FTBFS: OSError: [Errno 2] No such file or directory
Source: torbrowser-launcher Version: 0.1.5-1 Severity: serious Justification: fails to build from source (but built successfully in the past) torbrowser-launcher failed to build on the buildds: |dh_auto_clean -O--buildsystem=python_distutils | Traceback (most recent call last): | File setup.py, line 34, in module | distro = subprocess.check_output(['lsb_release', '-i']).split()[-1] | File /usr/lib/python2.7/subprocess.py, line 566, in check_output | process = Popen(stdout=PIPE, *popenargs, **kwargs) | File /usr/lib/python2.7/subprocess.py, line 710, in __init__ | errread, errwrite) | File /usr/lib/python2.7/subprocess.py, line 1335, in _execute_child | raise child_exception | OSError: [Errno 2] No such file or directory | dh_auto_clean: python setup.py clean -a returned exit code 1 For a full build log see https://buildd.debian.org/status/fetch.php?pkg=torbrowser-launcherarch=amd64ver=0.1.5-1stamp=1413119944. Looks like lsb-release is missing from Build-Depends. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#765808: edfbrowser: FTBFS on kfreebsd-*: error: 'specialfont' was not declared in this scope
Source: edfbrowser Version: 1.54-1 Severity: serious Justification: fails to build from source (but built successfully in the past) edfbrowser failed to build on kfreebsd-*: | g++ -c -D_FORTIFY_SOURCE=2 -Wall -Wshadow -Wextra -ggdb3 -O2 -Wall -W -D_REENTRANT -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/glibc-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -Imoc -o objects/annotations_dock.o annotations_dock.cpp | annotations_dock.cpp: In member function 'void UI_Annotationswindow::updateList()': | annotations_dock.cpp:797:25: error: 'specialfont' was not declared in this scope |listitem-setFont(specialfont); | ^ | make[2]: *** [objects/annotations_dock.o] Error 1 For a full build log see https://buildd.debian.org/status/fetch.php?pkg=edfbrowserarch=kfreebsd-amd64ver=1.54-1stamp=1413046881. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#765565: [Pkg-openssl-devel] Bug#765565: Bug#765565: openssl: don't completely disable ssl3/2 but rather just don't use it
On Sat, Oct 18, 2014 at 02:03:38PM +0100, rbsec wrote: Kurt, You're correct that sslscan uses SSLv3_client_method() - it also uses the SSLv2, TLS1.0, 1.1 and 1.2 equivalents as well depending on which protocols are enabled in OpenSSL (and which ones it's told to scan with commandline options). TLSv1.2 is supported (it can be forced with --tls12) - not sure why that wouldn't be working for you. There is no --tls12 option in the debian package of it. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754401: gource starts on the wrong X11 screen
On Wednesday 15 October 2014 16:50:25 Steaphan Greene wrote: I'd love to see this fix show up in the Debian package. :) Sounds good. I'm on it. All the best -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765809: nmap: FTBFS on kfreebsd-*: asm/types.h: No such file or directory
Source: nmap Version: 6.47-3 Severity: serious Justification: fails to build from source (but built successfully in the past) nmap failed to build on kfreebsd-*: | libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../include -I../include -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -c route-linux.c -o route-linux.o | route-linux.c:16:23: fatal error: asm/types.h: No such file or directory | #include asm/types.h |^ | compilation terminated. | Makefile:283: recipe for target 'route-linux.lo' failed For the full build log see https://buildd.debian.org/status/fetch.php?pkg=nmaparch=kfreebsd-amd64ver=6.47-3stamp=1413052539. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#765728: [Pkg-xfce-devel] Bug#765728: Bug#765728: xfce4-session is not setting XDG_CURRENT_DESKTOP (affects Qt5)
On sam., 2014-10-18 at 14:59 +0200, Yves-Alexis Perez wrote: On ven., 2014-10-17 at 16:24 +0100, Darren Salt wrote: Package: xfce4-session Version: 4.10.1-8 Tags: patch Qt5 selects a theme according to the value of XDG_CURRENT_DESKTOP. With this unset, Qt5 apps use its default theme, ignoring local configuration. If I set it to XFCE, they use a GTK+-like theme which fits in with the rest of the desktop (well, almost – there's a bug in Qt5's font rendering). See also https://forum.manjaro.org/index.php?topic=13728 I have to admin I'm a bit puzzled at this. Looking around I can find an old thread from 2011 [1] with no real conclusion. And for example it's seems unclear if it should be set by the DM or by the session script itself. LightDM apparently [2] supports setting that variable if it's set in the Xsession .desktop file, I'll check that and report back. Unfortunately it won't work with the “default” session (which uses the Debian alternatives system), so maybe the patch is still useful. Actually GDM now supports DesktopNames [1] property for the same thing. [1]: https://bugzilla.gnome.org/show_bug.cgi?id=727546 -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#703710: killer CRON disabled on diskless workstations
[Mike Gabriel] Hi Petter, Hi. If killer works reliably, then: yes (for diskless workstations). As far as I know, it work reliably. But not quite like you think it is working. Otherwise, diskless workstations (not sure about thin clients, actually) will not get affected by shutdown-at-night if users forgot to log out. Killer will kill processes for people not logged into the machine, not throw out logged in users. It get rid of leftover processes. The expected behaviour would be for diskless workstations: o killer ends still-running / not-logged-off sessions after 6h of session duration o shutdown-at-night turns of the diskless machine within the next hour I am not sure killer is the autologout-mechanism you are looking for. shutdown-at-night would work if you had such autologin mechanism. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748867: patch: Let's fix this by adding APIKEY
Hi, On Sat, Oct 18, 2014 at 01:13:39PM +0200, Giuseppe Iuculano wrote: Il 18/10/2014 11:12, Osamu Aoki ha scritto: I understand Mike's (long term) plan to separate APIKEY to different package. But, at least for now, can we have functioning package in testing without reading and manually tweaking the system? Any reason not to update this? Then with next package, Mike can do whatever as long as it is coordinated with ftp-master for the new package. Oh well, so if you understand Mike's (long term) plan, This refers to https://bugs.debian.org/748867#122 by Mike: | This has been the plan all along, I just haven't gotten to it yet | since the plan is a separate apikeys package and that's going to | involve a trip through NEW. NEW process takes *long time* and it is not good idea at this time for most DDs as I understand. But it mat\y be different for Mike. can you please make me understand why people should change APIKEY? Did I say this? I thought this patch was just following workaround mentioned in this bug report thread and used old APIKEYs shipped with Debian. And so we have chromium broken for a month only for the very small number of people that will change APIKEY? I have 2 systems. One somehow survived through this package transition. The other causing problem. I upgraded at different timing. The system which required this API key was the one which I removed ~/.config/chromium removed after facing the breakage. I have not investigated much. If I was the unfortunate few, then I am OK with the package as they are as long as it works for people upgrading from wheezy. (If API key removal was caused by the licensing issue, then it should be documented somewhere.) Regards, Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765579: cowbuilder and eatmydata
Control: clone -1 -2 control: reassign -2 eatmydata 82-1 control: severity -2 normal control: retitle -2 the eatmydata binary should work with different arches transparently On Sat, Oct 18, 2014 at 12:51 PM, Thorsten Glaser t...@mirbsd.de wrote: Mattia Rizzolo dixit: It should work just fine provided that 1) the target arch is the same as the host This is something that will, for me, almost never be the case. [...] But to work like that, or in the foreign-arch /bin/bzip2 example we had earlier in this mail thread, is precisely what’s needed in a M-A scenario. We *really* need that to work. Maybe we should involve the glibc people and ask how we can do an automatic-architecture LD_PRELOAD. You're right, cloned this bug where I'll track this (I already have sketched up an ugly workaround; if you, for some odd reasons, want a fix right now) For now, manually set LD_PRELOAD to libeatmydata.so works, though. 2) the target chroot has the libeatmydata1 package installed That is something I can easily do (backport it). I already planned a classic backport to wheezy-backports, once I'm sure there are no more real big bugs with this new version. -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765360: [Pkg-xfce-devel] Bug#765360: lightdm: Login screen should not show up as a active session in loginctl
On mar., 2014-10-14 at 15:01 +0200, Petter Reinholdtsen wrote: console user logged in at the moment, look like this: SESSION UID USERSEAT c2 116 lightdm seat0 21000 pere Note how the lightdm login screen is counted as a active login session on seat0. Also could paste the output of loginctl show-session c2 ? -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#765811: mediatomb: FTBFS - unable to configure libmp4v2 support
Package: mediatomb
Version: 0.12.1-6
Severity: serious
Usertags: goto-cc
During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.
[...]
checking mp4v2/mp4v2.h usability... no
checking mp4v2/mp4v2.h presence... no
checking for mp4v2/mp4v2.h... no
checking /usr/local/include/mp4v2/mp4v2.h usability... no
checking /usr/local/include/mp4v2/mp4v2.h presence... no
checking for /usr/local/include/mp4v2/mp4v2.h... no
checking mp4.h usability... no
checking mp4.h presence... no
checking for mp4.h... no
checking /usr/local/include/mp4.h usability... no
checking /usr/local/include/mp4.h presence... no
checking for /usr/local/include/mp4.h... no
configure: error: unable to configure libmp4v2 support
== config.log ==
[...]
configure: exit 1
dh_auto_configure: ./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=${prefix}/include --mandir=${prefix}/share/man
--infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--libdir=${prefix}/lib/x86_64-linux-gnu
--libexecdir=${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking --enable-sqlite3 --enable-mysql --enable-libjs
--enable-libmagic --enable-inotify --enable-libexif --enable-taglib
--enable-ffmpeg --enable-ffmpegthumbnailer --enable-external-transcoding
--enable-curl --enable-youtube --enable-db-autocreate --disable-id3lib
--enable-libmp4v2 --disable-libextractor --disable-lastfmlib returned exit code
1
debian/rules:42: recipe for target 'override_dh_auto_configure' failed
make[1]: *** [override_dh_auto_configure] Error 255
make[1]: Leaving directory
'/srv/jenkins-slave/workspace/sid-goto-cc-mediatomb/mediatomb-0.12.1'
debian/rules:63: recipe for target 'binary' failed
make: *** [binary] Error 2
The full build log is attached; please do let me know if the problem is
unreproducible, in which case I shall try to investigate further. Yet it seems
all buildds fail with the same error. It seems build dependencies need to be
adjusted.
Best,
Michael
mediatomb-build-log.txt.gz
Description: application/gunzip
pgpFjS20Ryg9C.pgp
Description: PGP signature
Bug#765812: GNOME Evolution SIGSEGV with latest SQLite3
Package: evolution Version: 3.12.7-1 I'm on Debian/sid with all packages up-to-date. After upgrading SQLite3 this morning from 3.8.6-1 to 3.8.7-1 GNOME Evolution crashes with a segmentation violation. I got the hint on SQLite3 by running Evolution under gdb, here is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff64ff9700 (LWP 7212)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x7fffee7d757b in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 #2 0x7fffee807f4f in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 #3 0x7fffee80824e in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 #4 0x7fffee83a96e in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 #5 0x7fffee83dbc7 in sqlite3_step () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 #6 0x7fffee82c8aa in sqlite3_exec () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 #7 0x76d9d3c8 in ?? () from /usr/lib/libcamel-1.2.so.49 #8 0x76d9ee6f in camel_db_select () from /usr/lib/libcamel-1.2.so.49 #9 0x76d9efd4 in camel_db_get_folder_uids () from /usr/lib/libcamel-1.2.so.49 #10 0x76db017d in camel_folder_summary_load_from_db () from /usr/lib/libcamel-1.2.so.49 #11 0x7fffcb5f3888 in ?? () from /usr/lib/evolution-data-server/camel-providers/libcamellocal.so #12 0x7fffcb5e7079 in camel_local_summary_load () from /usr/lib/evolution-data-server/camel-providers/libcamellocal.so #13 0x7fffcb5e4c4c in camel_local_folder_construct () from /usr/lib/evolution-data-server/camel-providers/libcamellocal.so #14 0x7fffcb5f07ff in camel_maildir_folder_new () from /usr/lib/evolution-data-server/camel-providers/libcamellocal.so #15 0x7fffcb5f1590 in ?? () from /usr/lib/evolution-data-server/camel-providers/libcamellocal.so #16 0x76e02817 in camel_store_get_folder_sync () from /usr/lib/libcamel-1.2.so.49 #17 0x7fffc8f0b7b1 in e_mail_session_uri_to_folder_sync () from /usr/lib/evolution/3.12/libemail-engine.so.0 #18 0x7fffc8f18546 in ?? () from /usr/lib/evolution/3.12/libemail-engine.so.0 #19 0x7fffc8f13017 in ?? () from /usr/lib/evolution/3.12/libemail-engine.so.0 #20 0x738852b8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #21 0x73884925 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #22 0x773400a4 in start_thread (arg=0x7fff64ff9700) at pthread_create.c:309 #23 0x73551c2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 (gdb) quit Reverting SQLite3 to 3.8.6-1 fixes the problem on my side. Thanks, -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765565: [Pkg-openssl-devel] Bug#765565: Bug#765565: openssl: don't completely disable ssl3/2 but rather just don't use it
Kurt, The Debian sslscan package looks like it was last updated in 2011, it's probably based off the original fork by IOError - which has been pretty much abandoned for the last few years. I have an updated fork on GitHub (https://github.com/rbsec/sslscan) with some new features like IPv6 and TLS 1.1/1.2 support. There are also a couple of other forks out there (like the one by DinoTools). ~Robin On 18/10/14 14:14, Kurt Roeckx wrote: On Sat, Oct 18, 2014 at 02:03:38PM +0100, rbsec wrote: Kurt, You're correct that sslscan uses SSLv3_client_method() - it also uses the SSLv2, TLS1.0, 1.1 and 1.2 equivalents as well depending on which protocols are enabled in OpenSSL (and which ones it's told to scan with commandline options). TLSv1.2 is supported (it can be forced with --tls12) - not sure why that wouldn't be working for you. There is no --tls12 option in the debian package of it. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765813: torbrowser-launcher: FTBFS - missing build dependency on lsb-release
Package: torbrowser-launcher Version: 0.1.5-1 Severity: serious Usertags: goto-cc During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder and pbuilder) the build failed with the following error. [...] fakeroot debian/rules clean dh clean --with python2 --buildsystem=python_distutils dh_testdir -O--buildsystem=python_distutils dh_auto_clean -O--buildsystem=python_distutils Traceback (most recent call last): File setup.py, line 34, in module distro = subprocess.check_output(['lsb_release', '-i']).split()[-1] File /usr/lib/python2.7/subprocess.py, line 566, in check_output process = Popen(stdout=PIPE, *popenargs, **kwargs) File /usr/lib/python2.7/subprocess.py, line 710, in __init__ errread, errwrite) File /usr/lib/python2.7/subprocess.py, line 1335, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory dh_auto_clean: python setup.py clean -a returned exit code 1 debian/rules:7: recipe for target 'clean' failed make: *** [clean] Error 1 The full build log is attached; please do let me know if the problem is unreproducible, in which case I shall try to investigate further. Best, Michael torbrowser-launcher-build-log.txt.gz Description: application/gunzip pgpzd0RtLpuVq.pgp Description: PGP signature
Bug#765814: node-source-map: FTBFS - TypeError: Cannot call method 'forEach' of undefined
Package: node-source-map Version: 0.1.40-1 Severity: serious Usertags: goto-cc During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder and pbuilder) the build failed with the following error. [...] dh binary dh_testdir dh_auto_configure debian/rules override_dh_auto_build make[1]: Entering directory '/srv/jenkins-slave/workspace/sid-goto-cc-node-source-map/node-source-map-0.1.40' nodejs Makefile.dryice.js Creating dist/SourceMap.jsm - Failed to compile source-map/source-map-consumer.js: TypeError: Cannot call method 'parse' of undefined TypeError: Cannot call method 'forEach' of undefined at CommonJsProject.require (/usr/lib/nodejs/dryice/lib/dryice/index.js:944:26) at null.anonymous (/usr/lib/nodejs/dryice/lib/dryice/index.js:372:21) at Array.forEach (native) at Object.defineProperty.get (/usr/lib/nodejs/dryice/lib/dryice/index.js:371:19) at copy.Destination._sourceToOutput (/usr/lib/nodejs/dryice/lib/dryice/index.js:454:20) at null.anonymous (/usr/lib/nodejs/dryice/lib/dryice/index.js:463:21) at Array.forEach (native) at copy.Destination._sourceToOutput (/usr/lib/nodejs/dryice/lib/dryice/index.js:462:10) at copy.FileDestination.processSource (/usr/lib/nodejs/dryice/lib/dryice/index.js:501:19) at copy (/usr/lib/nodejs/dryice/lib/dryice/index.js:32:8) debian/rules:11: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 8 The full build log is attached; please do let me know if the problem is unreproducible, in which case I shall try to investigate further. Best, Michael node-source-map-build-log.txt.gz Description: application/gunzip pgpaa1O22obVJ.pgp Description: PGP signature
Bug#765816: node-redis: FTBFS - service: Command not found
Package: node-redis Version: 0.12.1-1 Severity: serious Usertags: goto-cc During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder and pbuilder) the build failed with the following error. [...] debian/rules build dh build dh_testdir dh_auto_configure debian/rules override_dh_auto_test make[1]: Entering directory '/srv/jenkins-slave/workspace/sid-goto-cc-node-redis/node-redis-0.12.1' service redis-server stop make[1]: service: Command not found debian/rules:13: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 127 make[1]: Leaving directory '/srv/jenkins-slave/workspace/sid-goto-cc-node-redis/node-redis-0.12.1' debian/rules:8: recipe for target 'build' failed make: *** [build] Error 2 The full build log is attached; please do let me know if the problem is unreproducible, in which case I shall try to investigate further. Best, Michael node-redis-build-log.txt.gz Description: application/gunzip pgprtvJCKNi9j.pgp Description: PGP signature
Bug#765815: Black screen on acm
Package: acm Version: 5.0-29 acm often and repeatably shows a black screen. But not always. Running via ssh -Y to a VM resulted in it working perfectly. Running the same version (different arch) on the same host machine but natively resulted in a black screen. In this case, pressing r (which should change the radar mode) made the screen draw correctly, but with a very low frame rate for the scenery while the instrument panel updated at a sensible frame rate. No obvious differences in the capability of the X server other than 32 (the VM) vs 64 bit (the host). Checking on a native 32 bit machine, the bug does not show. Posting this bug as a reminder to myself for further investigation (first, chasing down lots of compiler warnings?). Cross-reference to Ubuntu LP bug 1015343 https://bugs.launchpad.net/ubuntu/+source/acm/+bug/1015343 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755981: evolution-data-server: this seems to have to do with ipv6 DNS issues
Package: evolution-data-server Version: 3.12.7.1-1 Followup-For: Bug #755981 Dear Maintainer, I am experienceing the same issue, but oddly enough, it happens on one of my computers but not on another although I thought they are configured very similarly. Not sure why. However: 1. When this happens, almost all the network activity consists of bombarding the DNS server with requests (checked with iftop -P) 2. Disabling ipv6 (or even just the global ipv6 address) makes the problem disappear. Hope this helps. Cheers, Itai. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (600, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages evolution-data-server depends on: ii evolution-data-server-common 3.12.7.1-1 ii libc6 2.19-11 ii libcamel-1.2-49 3.12.7.1-1 ii libdb5.3 5.3.28-6 ii libebackend-1.2-7 3.12.7.1-1 ii libebook-1.2-14 3.12.7.1-1 ii libebook-contacts-1.2-0 3.12.7.1-1 ii libecal-1.2-163.12.7.1-1 ii libedata-book-1.2-20 3.12.7.1-1 ii libedata-cal-1.2-23 3.12.7.1-1 ii libedataserver-1.2-18 3.12.7.1-1 ii libgcr-base-3-1 3.14.0-2 ii libgcr-ui-3-1 3.14.0-2 ii libgdata190.16.0-1 ii libglib2.0-0 2.42.0-2 ii libgoa-1.0-0b 3.14.0-1 ii libgtk-3-03.14.3-1 ii libgweather-3-6 3.14.1-1 ii libical1 1.0-1 ii libldap-2.4-2 2.4.39-1.1+b1 ii libpango-1.0-01.36.8-2 ii libsecret-1-0 0.18-1+b1 ii libsoup2.4-1 2.48.0-1 ii libxml2 2.9.1+dfsg1-4 evolution-data-server recommends no packages. Versions of packages evolution-data-server suggests: ii evolution 3.12.7-1 pn evolution-data-server-dbg none -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765818: simgear: FTBFS[kfreebsd]: wrong usage of GL/glxext.h
Package: simgear Version: 3.0.0-5 Severity: serious Control: block 754988 by -1 Hi, Upgrading mesa-common-dev from upstream version 10.2.8 to 10.3.1, unfortuntaely made simgear FTBFS: https://buildd.debian.org/status/fetch.php?pkg=simgeararch=kfreebsd-amd64ver=3.0.0-5%2Bb1stamp=1413603273 Normally one includes gl.h first, which in turn includes glext.h, but specifically on kfreebsd, simgear was preventing that with the GL_GLEXT_LEGACY flag: simgear/canvas/ShivaVG/src/shDefs.h: | #if defined(VG_API_LINUX) | #include GL/gl.h | #include GL/glu.h | #include GL/glx.h | ... | #else | #define GL_GLEXT_LEGACY /* don't include glext.h */ | #include GL/gl.h | #include GL/glu.h | #include GL/glx.h | #endif From Mesa 10.3 there are some glext.h types used in glxext.h; it would be necessary to use a new GLX_GLXEXT_LEGACY flag to avoid inclusion of the latter as well. But, there is no reason GNU/kFreeBSD can't use VG_API_LINUX, and use the normal GL API without any _LEGACY flags. Patch attached! Thanks. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash From: Steven Chamberlain ste...@pyro.eu.org Subject: GL usage for GNU/kFreeBSD Date: Sat, 18 Oct 2014 13:12:53 +0100 Since mesa 10.3, glx.h fails to compile if GL_GLEXT_LEGACY is used without also GLX_GLXEXT_LEGACY. And GNU/kFreeBSD should better use the GNU/Linux VG_API_LINUX rather than VG_API_FREEBSD anyway. --- a/simgear/canvas/ShivaVG/src/shConfig.h +++ b/simgear/canvas/ShivaVG/src/shConfig.h @@ -16,7 +16,7 @@ #define NOMINMAX #endif -#elif defined(linux) || defined(__linux) +#elif defined(linux) || defined(__linux) || defined(__GLIBC__) // Linux #define VG_API_LINUX @@ -26,7 +26,7 @@ // MacOS #define VG_API_MACOSX -#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) +#elif defined(__FreeBSD__) // FreeBSD #define VG_API_FREEBSD --- a/simgear/canvas/ShivaVG/src/shDefs.h +++ b/simgear/canvas/ShivaVG/src/shDefs.h @@ -170,6 +170,7 @@ #define GL_GLEXT_LEGACY /* don't include glext.h */ #include GL/gl.h #include GL/glu.h +#define GLX_GLXEXT_LEGACY /* don't include glxext.h */ #include GL/glx.h #endif
Bug#765817: virtualbox: Crash with GNOME in guest
Package: virtualbox Version: 4.3.14-dfsg-1 Severity: grave Justification: renders package unusable Dear Maintainer, Since GNOME 3.x virtulabox 4.3.14 crash render the virtual machine unusable. This bug has been fixed in 4.3.16 (latest upstream version is 4.3.18). https://www.virtualbox.org/ticket/13335 Christian -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.17.1 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages virtualbox depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.18 ii libc62.19-11 ii libcurl3 7.38.0-2 ii libgcc1 1:4.9.1-17 ii libgsoap52.8.17-1 ii libpng12-0 1.2.50-2 ii libpython2.7 2.7.8-10 ii libsdl1.2debian 1.2.15-10 ii libssl1.0.0 1.0.1j-1 ii libstdc++6 4.9.1-17 ii libvncserver00.9.9+dfsg-6+b2 ii libvpx1 1.3.0-2.1 ii libx11-6 2:1.6.2-3 ii libxcursor1 1:1.1.14-1 ii libxext6 2:1.3.3-1 ii libxml2 2.9.1+dfsg1-4 ii libxmu6 2:1.1.2-1 ii libxt6 1:1.1.4-1 ii python 2.7.8-1 ii python2.72.7.8-10 ii zlib1g 1:1.2.8.dfsg-2 Versions of packages virtualbox recommends: ii libgl1-mesa-glx [libgl1] 10.3.1-1 ii libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii virtualbox-dkms 4.3.14-dfsg-1 ii virtualbox-qt 4.3.14-dfsg-1 ii virtualbox-source 4.3.14-dfsg-1 Versions of packages virtualbox suggests: pn vde2none ii virtualbox-guest-additions-iso 4.3.14-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765819: i3-wm: switch from X-LightDM-DesktopName to DesktopNames in desktop file
Source: i3-wm Severity: wishlist Hi, following #765728 and some researches done, I'm intending (as LightDM maintainer) to switch from X-LightDM-DesktopName to DesktopNames to set XDG_CURRENT_DESKTOP. Since i3-wm seems to be the only user in Debian [1] I don't really intend to make a large transition for this, and simply upload a new version once you're ready. I've also asked upstream about this [2]. Can you keep me posted on this? Regards, -- Yves-Alexis [1]: http://codesearch.debian.net/search?q=X-LightDM-DesktopName [2]: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1212408 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (450, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661712: dvswitch: Provide some information about the free space of the hd
I have been using this for years:
print 'free space: %s gig' % round(gigfree,1)
print 'room for: %s min' % round(minutes,1)
if minutes5:
else:
print %s minutes is not enough. % (minutes)
https://github.com/CarlFK/dvsmon/blob/master/sink_find_dir.py#L48
I hardly ever look at it.
The not enough has never been useful.
My point: this seems like a good idea when you have lost a recording due to
running out of disk space, but in practice I don't think it will help. So
I wouldn't bother adding code to dvswitch.
What does work for me:
Before the event starts look at the schedule and estimate how much space is
needed. Check to make sure you have that much free space.
On Sat, Oct 18, 2014 at 6:12 AM, Ben Hutchings b...@decadent.org.uk wrote:
On Sat, 2014-10-18 at 10:42 +0200, Petter Reinholdtsen wrote:
I don't see the point of doing this in DVswitch. There are applets
for this and a stock GNOME installation will warn on low disk space.
I believe it would be nice to see the amount of disk free where I look
to check if the dvsink is working, and made a untested draft patch to
do so.
Something along these lines would help me a bit when doing video
recordings:
Index: src/dvsink-files.c
===
--- src/dvsink-files.c (revision 414)
+++ src/dvsink-files.c (working copy)
@@ -17,6 +17,7 @@
#include sys/types.h
#include sys/stat.h
#include unistd.h
+#include sys/statfs.h
#include config.h
#include dif.h
@@ -162,6 +163,19 @@
return total;
}
+/* Return the amount of megabyte free on the disk of the file
descriptor */
+static long freespace(int fd)
+{
+struct statfs stat;
+long free;
+if (0 == fstatfs(fd, stat))
From statfs(2):
Linux-specific. The Linux statfs() was inspired by the 4.4BSD
one (but
they do not use the same structure).
[...]
LSB has deprecated the library calls statfs() and fstatfs() and
tells
us to use statvfs(2) and fstatvfs(2) instead.
+{
+free = stat.f_bsize * stat.f_bavail / (1024*1024) ;
+} else {
+free = -1;
+}
+}
This is not even self-consistent in brace placement!
static void transfer_frames(struct transfer_params * params)
{
static uint8_t buf[SINK_FRAME_HEADER_SIZE + DIF_MAX_FRAME_SIZE];
@@ -207,7 +221,8 @@
file = create_file(output_name_format, name);
if (starting)
printf(INFO: Started recording\n);
- printf(INFO: Created file %s\n, name);
+ long free = freespace(file);
Local variable free hides global function free().
+ printf(INFO: Created file %s - free space $ld MiB\n, name,
free);
So it prints free space -1 MiB in case of error??
Ben.
fflush(stdout);
}
Perhaps something to include?
--
Ben Hutchings
Life is what happens to you while you're busy making other plans.
- John
Lennon
--
dvswitch-devel mailing list
dvswitch-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/dvswitch-devel
--
Carl K
Bug#765820: libxapian22: please add multi-arch support for libxapian22
Package: libxapian22
Version: 1.2.18-1.1
Severity: normal
Tags: patch
User: crossbu...@debian.org
Usertags: cross
Hi there,
Please find attached a patch to xapian-core to transition it to use of
the multiarch library paths as described at
http://wiki.debian.org/Multiarch/Implementation.
Both aptitude and zeitgeist-core depend on libxapian22, and
zeitgeist-core as a dependency of gnome so this means that gnome and
aptitude need to be the same architecture.
So this change makes it so that aptitude and gnome can have different
architectures (eg: i386 amd64).
I've done very minimal testing: I installed libxapian22 and checked
that aptitude started without error.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (700, 'testing'), (650, 'stable'), (600, 'unstable'), (550,
'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libxapian22 depends on:
ii libc6 2.19-11
ii libgcc1 1:4.9.1-16
ii libstdc++6 4.9.1-16
ii libuuid12.20.1-5.11
ii zlib1g 1:1.2.8.dfsg-2
libxapian22 recommends no packages.
Versions of packages libxapian22 suggests:
pn xapian-tools none
-- no debconf information
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@
Priority: important
Maintainer: Olly Betts o...@survex.com
Standards-Version: 3.9.5
-Build-Depends: debhelper (= 7), autotools-dev, zlib1g-dev, uuid-dev, dh-autoreconf
+Build-Depends: debhelper (= 8.1.3), autotools-dev, zlib1g-dev, uuid-dev, dh-autoreconf
Homepage: http://xapian.org/
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/xapian-core.git
Vcs-git: git://anonscm.debian.org/collab-maint/xapian-core.git
@@ -11,8 +11,10 @@
Package: libxapian22
Architecture: any
Section: libs
+Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: xapian-tools
+Multi-Arch: same
Description: Search engine library
This package contains the core Xapian runtime library.
.
@@ -30,6 +32,7 @@
Priority: extra
Depends: libxapian22 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
Suggests: libc6-dbg, libgcc1-dbg, zlib1g-dbg, libstdc++6-4.6-dbg
+Multi-Arch: same
Description: Debugging symbols for the Xapian Search engine library
This package contains debugging symbols for the core Xapian library.
.
--- a/debian/libxapian-dev.install
+++ b/debian/libxapian-dev.install
@@ -1,8 +1,8 @@
usr/bin/xapian-config
usr/include
-usr/lib/cmake/xapian
-usr/lib/libxapian.a
-usr/lib/libxapian.la
-usr/lib/libxapian.so
+usr/lib/*/cmake/xapian
+usr/lib/*/libxapian.a
+usr/lib/*/libxapian.la
+usr/lib/*/libxapian.so
usr/share/aclocal
usr/share/man/man1/xapian-config.1
--- a/debian/libxapian22.install
+++ b/debian/libxapian22.install
@@ -1 +1 @@
-usr/lib/libxapian.so.*
+usr/lib/*/libxapian.so.*
--- a/debian/libxapianVERSION-dev.install
+++ b/debian/libxapianVERSION-dev.install
@@ -1,8 +1,8 @@
usr/bin/xapian-config
usr/include
-usr/lib/cmake/xapian
-usr/lib/libxapian.a
-usr/lib/libxapian.la
-usr/lib/libxapian.so
+usr/lib/*/cmake/xapian
+usr/lib/*/libxapian.a
+usr/lib/*/libxapian.la
+usr/lib/*/libxapian.so
usr/share/aclocal
usr/share/man/man1/xapian-config.1
--- a/debian/libxapianVERSION.install
+++ b/debian/libxapianVERSION.install
@@ -1 +1 @@
-usr/lib/libxapian.so.*
+usr/lib/*/libxapian.so.*
--- a/debian/rules
+++ b/debian/rules
@@ -53,6 +53,7 @@
# Disable the testsuite when cross-compiling.
DEB_BUILD_OPTIONS += nocheck
endif
+confflags += --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
# For i386 and *-i386.
ifeq ($(patsubst %-i386,i386,$(DEB_HOST_ARCH)), i386)
@@ -175,13 +176,13 @@
ifdef XAPIAN_BUILD_SSE
$(MAKE) -C build-sse2 DESTDIR=$(CURDIR)/debian/tmp-sse2 install
- mkdir -p $(CURDIR)/debian/libxapian$(libxapian_soversion)/usr/lib/sse2
- mv $(CURDIR)/debian/tmp-sse2/usr/lib/libxapian*.so.* $(CURDIR)/debian/libxapian$(libxapian_soversion)/usr/lib/sse2
+ mkdir -p $(CURDIR)/debian/libxapian$(libxapian_soversion)/usr/lib/$(DEB_HOST_MULTIARCH)/sse2
+ mv $(CURDIR)/debian/tmp-sse2/usr/lib/$(DEB_HOST_MULTIARCH)/libxapian*.so.* $(CURDIR)/debian/libxapian$(libxapian_soversion)/usr/lib/$(DEB_HOST_MULTIARCH)/sse2
rm -rf $(CURDIR)/debian/tmp-sse2
endif
# Empty dependency_libs to placate luddite release goal.
- sed -i 's/^\(dependency_libs=\).*/\1/' $(CURDIR)/debian/tmp/usr/lib/libxapian.la
+ sed -i 's/^\(dependency_libs=\).*/\1/' $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libxapian.la
# Install the example source code
mkdir -p debian/tmp/usr/share/doc/xapian-examples/examples
