Bug#711812: freecad: FreeCAD Version: 0.13.1830-dfsg-2 depends on the new coin package (version 4)
tags 711812 +moreinfo severity 711812 minor thanks Hi, thanks for bugreport. Please, clarify what you mean. Cheers, Anton 2013/6/10 Geordie geo...@kos.net: Package: freecad Version: 0.13.1830-dfsg-2 Severity: grave Justification: renders package unusable Dear Maintainer, This version of libcoin was installed 2013-06-08 on a update. apt-cache policy libcoin80 libcoin80: Installed: 3.1.4~abc9f50-3 Candidate: 3.1.4~abc9f50-3 Version table: *** 3.1.4~abc9f50-3 0 500 http://http.debian.net/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711821: please close bug
Please close bug: I've upgraded to the latest nfs-common and now all is fine again. Folkert van Heusden -- Ever wonder what is out there? Any alien races? Then please support the seti@home project: setiathome.ssl.berkeley.edu -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711822: pcb: FTBFS (gtk/gtkgl.h: No such file or directory)
Source: pcb Version: 20110918-7 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: jessie sid Control: block 706828 with -1 See the build logs at https://buildd.debian.org/status/logs.php?pkg=pcbver=20110918-7%2Bb1suite=sid gcc -std=gnu99 -DLOCALEDIR=\/usr/share/locale\ -DHAVE_CONFIG_H -I. -I../../src -I.. -I../.. -I../../src/icons -I../../src/../gts -I./hid/gtk -D_FORTIFY_SOURCE=2 -DPREFIXDIR=\/usr\ -DBINDIR=\/usr/bin\ -DHOST=\x86_64-pc-linux-gnu\ -DPCBLIBDIR=\/usr/share/pcb\ -DPCBTREEDIR=\/usr/share/pcb/newlib\ -DPCBTREEPATH=\/usr/share/pcb/newlib:/usr/share/pcb/pcblib-newlib\ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/harfbuzz -pthread -pthread -Wall -Wdeclaration-after-statement -DNDEBUG -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/harfbuzz -pthread -pthread -Wall -Wdeclaration-after-statement -MT hid/gtk/libgtk_a-gtkhid-gl.o -MD -MP -MF hid/gtk/.deps/libgtk_a-gtkhid-gl.Tpo -c -o hid/gtk/libgtk_a-gtkhid-gl.o `test -f 'hid/gtk/gtkhid-gl.c' || echo '../../src/'`hid/gtk/gtkhid-gl.c ../../src/hid/gtk/gtkhid-gl.c:28:23: fatal error: gtk/gtkgl.h: No such file or directory compilation terminated. make[6]: *** [hid/gtk/libgtk_a-gtkhid-gl.o] Error 1 Cheers, Julien signature.asc Description: Digital signature
Bug#711823: gnome-terminal: fails to launch X applications on gnome-terminal called with ssh -X
Package: gnome-terminal Version: 3.8.2-1 Severity: important Dear Maintainer, * What led up to the situation? when upgraded gnome-terminal from 3.4.1.1-2 to 3.8.2-1 * What exactly did you do (or not do) that was effective (or ineffective)? from a remote Debian machine, I did ssh -X -f foo gnome-terminal and got gnome-terminal, then I open emacs on it. I saw emacs in a terminal mode and after I closed emacs I got an message Display localhost:10.0 unavailable, simulating -nw * What was the outcome of this action? It seems I cant launch X applications from gnome-terminal called with ssh -X * What outcome did you expect instead? when I open emacs without -nw it should open emacs in graphic mode. Thanks for your maintenance. Best regards, Mon Jun 10 2013 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-terminal depends on: ii dconf-gsettings-backend [gsettings-backend] 0.16.0-4 ii gconf-service3.2.6-1 ii gnome-terminal-data 3.8.2-1 ii gsettings-desktop-schemas3.4.2-3 ii libatk1.0-0 2.8.0-2 ii libc62.17-5 ii libdconf10.16.0-4 ii libgconf-2-4 3.2.6-1 ii libglib2.0-0 2.36.1-2build1 ii libgtk-3-0 3.8.2-1 ii libpango-1.0-0 1.32.5-5+b1 ii libuuid1 2.20.1-5.4 ii libvte-2.90-91:0.34.5-2 ii libx11-6 2:1.5.0-1+deb7u1 Versions of packages gnome-terminal recommends: ii dbus-x11 1.6.10-1 ii gvfs 1.16.2-2 ii yelp 3.8.1-2 gnome-terminal 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#711805: libvncserver: FTBFS on hppa -- gtkvncviewer.c:566:2: error
severity 711805 important found 711805 0.9.9+dfsg-1 notfound 711805 0.9.9+dfsg thanks hppa is not a release architecture, downgrading severity. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711304: nouveau: X terminates or freezes randomly, cannot be started again
FWIW, Linux tglase.lan.tarent.de 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 i686 GNU/Linux 08:51:32 up 3 days, 22:24, 2 users, load average: 0.11, 0.27, 0.29 This one is stable. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649079: gnome-bluetooth: edit /etc/machine-info
reassign 649079 gnome-control-center forwarded 649079 https://bugzilla.gnome.org/show_bug.cgi?id=575991 thanks On 10/06/13 03:27, Gonzalo Berm��dez wrote: Package: gnome-bluetooth Version: 3.4.2-1 Followup-For: Bug #649079 Although there's no GUI to get that changed, you can set a variable named PRETTY_HOSTNAME in /etc/machine-info (this file most likely won't exist) to set the bluetooth device's name. No need for that. gnome-bluetooth could set the adapter name through bluez's dbus API. This file is part of a freedesktop tool named hostnamectl, I discovered it while playing with Fedora 18. Didn't get a clue from Debian. Guess it hasn't landed here yet. Probably part of newer systemd than what is in Debian. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711774: Re: [exact-image] Re: Bug#711774: exactimage: dcraw vs libraw ?
On Sun, Jun 9, 2013 at 9:08 PM, Sven Eckelmann s...@narfation.org wrote: Just a small remark at the beginning: I didn't meant dcraw upstream with dcraw guys but the Debian maintainers for dcraw. And I really think it is a good question because the package is dead since 3 years and missing some updates from upstream. (Ok, the embedded copy of dcraw in exactimage seems to be older) On Sunday 09 June 2013 19:37:03 Rene Rebe wrote: I think dcraw did all the original research and he does not want to make it a library because he believes an executable to call is the unix way and a library he could boy change so flexible. This is why I embedded the not too big code to make it a simple built in library inside exact image. This is correct, but is not really about the problem here. Just to give more insight in what Mathieu Malaterre said: Embedded copies of code are bad when used in Distributions because (just some examples): * they increase the binary size when there would be shared object that could be used instead * they increase memory usage because different programs cannot share the loaded library * they are hard to maintain Ok, the first two points are easy to understand but the last one might be quite vague. So here an explanation with two different scenarios (actually it is the same example but with different impacts): dcraw gets a new version (lets call it 9.18 for obvious reasons) with X-Trans and EOS C500 support. Now all programs using an embedded copy have to be updated in Debian to bring these versions on par with the upstream one and fix outstanding bugs/request for EOS C500/X-Trans. This is not really trivial because the programs have to be identified first and then the maintainer has to be waken up. This is a lot of work and time spend on a task that is completely unnecessary. Therefore, it is better to use the library version when available. And yes, I am fully aware that interface changes are problems which can be a negative effect when switching to external libraries. Now to the part with a little more impact. Lets assume that dcraw has a bug which can be exploited quite easily (send a prepared image which causes some buffer overflows and so on). Now it is extreme important to find all versions of the embedded copy because otherwise it is a security risk. You don't really want to provide an web service doing raw image conversions when there might be a big security hole because the security bug was fixed in the original program/library but not in the embedded copy. So back to the main questions. Do you see a possible way to switch from your dcraw version to libraw and make more of the embedded copies optional? I know, the embedded copies from libjpeg for jpeg rotation are for example really hard because libjpeg doesn't export the necessary stuff. But it seemed to have caused some headaches for the previous maintainers of this package because no one updated the embedded copy of jpegint/transupp and it just crashed when used together with never versions of libjpeg like libjpeg8. And the current one in exactimage upstream still does. Very well summarized, Sven ! Security was mostly my main objection, since exactimage offer perl, python and php5 bindings it is quite likely this will be used on webserver, therefore security risk is not anymore just a theoretical issue. Regards, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711254: [php-maint] Bug#711254: It's a problem of PHP and not MySQL
Please provide your php5 versions (dpkg -l '*php5*'). Ondřej Surý On 10. 6. 2013, at 2:30, Bob Proulx b...@proulx.com wrote: reassign 711254 php5 tag 711254 + moreinfo thanks Karsten Malcher wrote: In case of wikimedia no clear update command is send, but in phpbb i could see that the update is blank instead of the content. 1339 Query UPDATE phpbb_topics SET topic_title = '', topic_type = 0 WHERE topic_id = 1066 The topic_title should contain a text. Something goes wrong in PHP5. Thank you for the bug report. However this is very little to go upon. From what you have said so far there isn't enough information to know what might be happening. At this point the problem could be anything. Because php has been updated to 5.5.0 it is most likely that your wikimedia and phpbb applications are not updated to work with the changes in php 5.5. I think that is the most likely problem. If it didn't work at all then there would be many reports. Therefore this is probably simply an incompatibility with the recent updates and changes in upstream php 5.5. Since you have the problem, and no one else is seeing the problem so far, and you have been making progress debugging it then it would be most helpful if you could keep going and get to the bottom of the problem. Thanks, Bob ___ pkg-php-maint mailing list pkg-php-ma...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711824: [gcc-4.8] FTBS when trying to backport to testing
Package: gcc-4.8 Version: 4.8.1-2 Severity: normal I just try to backport latest gcc from sid to jessie. The package FTBS as gcc-as-needed.diff patch is rejected. Taking a closer look I notice that --hash-style=both and not --hash-style=gnu as expected in the files to be patched. --- System information. --- Architecture: amd64 Kernel: Linux 3.2.0-4-amd64 Debian Release: jessie/sid 500 testing-proposed-updates ftp.fr.debian.org 500 testing security.debian.org 500 testing http.us.debian.org 500 testing ftp.fr.debian.org 500 testing euler.lcmi.local 500 stable dl.google.com 500 jessie neuro.debian.net 500 dataneuro.debian.net --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty. -- Christophe TROPHIME Research Engineer LNCMI CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE CNRS Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711825: tgif: Japanese fonts are broken in the exported EPS
Package: tgif Version: 1:4.2.5-1.2 Severity: normal Dear Maintainer, * What led up to the situation? If you input Japanese fonts and print a file(ie exported as EPS) then you will see broken Japanese (mojibake in Japanese). * What exactly did you do (or not do) that was effective (or ineffective)? Upgraded tgif and modified /etc/X11/ja_JP.eucJP/app-defaults/Tgif for Japanese fonts * What was the outcome of this action? When prit a file containing Japanese font to LaTeX(EPS) format I got broken Japanese. * What outcome did you expect instead? Of course, I expect correct Japanese in EPS file. FYI. this is well-known problem and you can get the fix in http://bourbon.usc.edu/tgif/download.html#tgif-QPL-4.2.5b it is tgif-QPL-4.2-patch5b.gz Thanks for your maintenance. Best regards, Mon Jun 10, 2013 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.9-1-amd64 (SMP w/2 CPU cores) Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tgif depends on: ii debconf [debconf-2.0] 1.5.50 ii gettext-base 0.18.2.1-1 ii ghostscript9.05~dfsg-6.3 ii libc6 2.17-5 ii libice62:1.0.8-2 ii libidn11 1.25-2 ii libsm6 2:1.2.1-2 ii libx11-6 2:1.5.0-1+deb7u1 ii libxext6 2:1.3.1-2+deb7u1 ii libxmu62:1.1.1-1 ii libxt6 1:1.1.3-1+deb7u1 ii netpbm 2:10.0-15+b1 ii python-uniconvertor1.1.4-1+b2 ii texlive-latex-base 2013.20130530-1 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages tgif recommends: ii xfonts-75dpi 1:1.0.3 tgif suggests no packages. -- Configuration Files: /etc/X11/ja_JP.eucJP/app-defaults/Tgif changed [not included] -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711826: no more unattended upgrades since Wheezy is out
Package: unattended-upgrades Version: 0.62.2 Since Wheezy is out the unattended-upgrades for Squeeze don't work anymore. The default configuration in /etc/apt/apt.conf.d/50unattended-upgrades says Unattended-Upgrade::Allowed-Origins { ${distro_id} stable; ${distro_id} ${distro_codename}-security; // ${distro_id} ${distro_codename}-updates; // ${distro_id} ${distro_codename}-proposed-updates; }; but security upgrades like the most recent libkrb5-3 are not installed automagically. Looking at its changelog entry I see krb5 (1.8.3+dfsg-4squeeze7) oldstable-security; urgency=medium * Fix cve-2002-2443: kpasswd udp ping-pong (Closes: #708267) : : Note the oldstable-security. Regards Harri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711827: RFA: gthumb -- image viewer and browser
Package: wnpp Severity: normal I request an adopter for the gthumb package. The package description is: gThumb is an advanced image viewer and browser. It has many useful features, such as filesystem browsing, slide show, image catalogs, web album creation, camera import, image CD burning, batch file operations and quick image editing features like transformation and color manipulation. . It's designed for GNOME 2 desktop environment and uses its platform. For camera import feature, the gPhoto2 library is used. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711828: RFA: gtkaml -- XML application markup language for GTK+ and Vala
Package: wnpp Severity: normal I request an adopter for the gtkaml package. The package description is: gtkaml is a XML language that extends the Vala.Parser and aimed at creating valid GTK+ UI classes. It features a compact XML syntax for describing the way Gtk widgets are laid out in custom widgets. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711839: RFA: gedit-valencia-plugin -- Vala plugin for gedit
Package: wnpp Severity: normal I request an adopter for the gedit-valencia-plugin package. The package description is: Valencia is a gedit plugin that turns gedit into a lightweight IDE for Vala. Using Valencia, you can easily browse between symbols in a Vala program. You can build a Vala program inside gedit and can easily jump to lines with build errors. You can also get tooltips for methods and get autocompletion suggestions by invoking autocomplete in the appropriate context. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711832: RFA: mockito -- mocking framework for Java
Package: wnpp Severity: normal I request an adopter for the mockito package. The package description is: Mockito is a mocking library which lets you write tests with a clean and simple API. . It generates mocks using reflection, it records all mock invocations, including methods arguments. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711840: RFA: apache-mime4j -- MIME and RFC822 parser for Java
Package: wnpp Severity: normal I request an adopter for the apache-mime4j package. The package description is: mime4j provides a parser, MimeStreamParser, for e-mail message streams in plain rfc822 and MIME format. The parser uses a callback mechanism to report parsing events such as the start of an entity header, the start of a body, etc. If you are familiar with the SAX XML parser interface you should have no problem getting started with mime4j. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711833: RFA: postr -- upload photos to Flickr
Package: wnpp Severity: normal I request an adopter for the postr package. The package description is: Postr is a Flickr uploading tool for the GNOME desktop, which aims to be simple to use but exposing enough of Flickr to be useful. . It has a simple user interface, and lets you set common attributes for your photos: title, description, tags, sets, groups, privacy, licence, etc. . It is integrated with Nautilus: you can either run postr when you are browsing your photos or just drag them from Nautilus to drop them in Postr. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711829: RFA: gphoto2 -- The gphoto2 digital camera command-line client
Package: wnpp Severity: normal I request an adopter for the gphoto2 package. The package is currently maintained by the Debian PhotoTools Team, CCed. The package description is: The gphoto2 library can be used by applications to access various digital camera models, via standard protocols such as USB Mass Storage and PTP, or vendor-specific protocols. . This package provide the gphoto2 command-line frontend. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711837: RFA: mapnik -- C++/Python toolkit for developing GIS applications
Package: wnpp Severity: normal I request an adopter for the mapnik package. The package is currently maintained within the Debian GIS Team, CCed. The package description is: Mapnik is an OpenSource C++/Python toolkit for developing GIS (Geographic Information Systems) applications. At the core is a C++ shared library providing algorithms/patterns for spatial data access and visualization. . Essentially a collection of geographic objects (map, layer, datasource, feature, geometry), the library doesn't rely on windowing systems and is intended to work in multi-threaded environments . High-level Python bindings (boost.python) facilitate rapid application development, targeting zope3, django, etc. . This package contains the development headers, API documentation, and build utilities. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711838: RFA: gettext-ant-tasks -- Java classes for internationalization (i18n)
Package: wnpp Severity: normal I request an adopter for the gettext-ant-tasks package. The package description is: Lightweight library combining the power of the unix-style gettext tools with the widely used Java ResourceBundles. This makes it possible to use the original text instead of arbitrary property keys, which is less cumbersome and makes programs easier to read. . This package contains tasks to be used with the Ant build system. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711831: RFA: libgphoto2 -- gphoto2 digital camera library
Package: wnpp Severity: normal I request an adopter for the libgphoto2 package. The package is currently maintained within the Debian PhotoTools Team, CCed. The package description is: The gphoto2 library can be used by applications to access various digital camera models, via standard protocols such as USB Mass Storage and PTP, or vendor-specific protocols. . This package contains the library. . The gphoto2 command-line frontend is shipped separately, in the gphoto2 package. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711834: RFA: pudb -- full-screen, console-based Python debugger
Package: wnpp Severity: normal I request an adopter for the pudb package. The package description is: PuDB is a full-screen, console-based visual debugger for Python. . Its goal is to provide all the niceties of modern GUI-based debuggers in a more lightweight and keyboard-friendly package. PuDB allows you to debug code right where you write and test it -- in a terminal. If you've worked with the excellent (but nowadays ancient) DOS-based Turbo Pascal or C tools, PuDB's UI might look familiar. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711642: overview at bottom obscures entered letters
Hi, thanks for the report. Indeed it should be fixed; I just have to find out how to scale a TextView the way I currently scale a label, while retaining the ability to interact with the widget. Then one can simply edit the man view. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#711836: webdruid: unsatisfiable build-dep on automake1.11
Source: webdruid Version: 0.5.4-12.1 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: jessie sid Control: block 706828 with -1 Hi, webdruid build-depends on automake1.11, but that package is no longer in sid (automake is now at 1.13). Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711830: RFA: leocad -- virtual brick CAD software
Package: wnpp Severity: normal I request an adopter for the leocad package. The package description is: LeoCAD is a CAD program that can be used to create virtual models with bricks similar to those found in many toys. It has an easy to use interface and currently features over 2000 different pieces created by the LDraw community. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711835: RFA: valatoys -- Vala Toys for gEdit
Package: wnpp Severity: normal I request an adopter for the valatoys package. The package description is: Vala Toys for gEdit is an experimental collection of plugins that extends the gEdit editor to make it a better developer editor. . Vtg tries to make less compromises as possible so, for now, its scope is narrowed only to support the Vala programming language. . Vtg is written in Vala itself and it is currently composed of just one plugin with four modules and it adds to gEdit: . * Bracket completion * Symbol completion * Project Manager * Project build / execute -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711841: xawtv makes whole system freezed
Package: xawtv Version: 3.103-1 Severity: important Dear Maintainer, * What led up to the situation? only upgrading xawtv from 3.102-3 to 3.103-1 * What exactly did you do (or not do) that was effective (or ineffective)? nothing special. * What was the outcome of this action? system was freezex and didn't accept any key iputs etc. so I needed to power down by power button. * What outcome did you expect instead? xawtv runs smoothly I now downgraded xawtv to 3.102-3 and manually changed version number in reportbug session. Please don't ask me try again 3.103-1. It certainly made my system deep freezed. Thanks for your maintenance. Best regards, Mon Jun 10, 2013 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xawtv depends on: ii debconf [debconf-2.0] 1.5.50 ii lesstif2 1:0.95.2-1.1 ii libasound21.0.27.1-1 ii libc6 2.17-3 ii libfontconfig12.9.0-7.1 ii libgl1-mesa-glx [libgl1] 8.0.5-6 ii libice6 2:1.0.8-2 ii libjpeg8 8d-1 ii liblircclient00.9.0~pre1-1 ii libncurses5 5.9+20130504-1 ii libpng12-01.2.49-4 ii libsm62:1.2.1-2 ii libtinfo5 5.9+20130504-1 ii libx11-6 2:1.5.0-1+deb7u1 ii libxaw7 2:1.0.10-2 ii libxext6 2:1.3.1-2+deb7u1 ii libxft2 2.3.1-1 ii libxinerama1 2:1.1.2-1+deb7u1 ii libxmu6 2:1.1.1-1 ii libxp61:1.0.1-2+deb7u1 ii libxpm4 1:3.5.10-1 ii libxrandr22:1.3.2-2+deb7u1 ii libxrender1 1:0.9.7-1+deb7u1 ii libxt61:1.1.3-1+deb7u1 ii libxv12:1.0.7-1+deb7u1 ii libxxf86dga1 2:1.1.3-2+deb7u1 ii libxxf86vm1 1:1.1.2-1+deb7u1 ii libzvbi0 0.2.33-7 ii pia 3.102-3 ii scantv3.102-3 ii v4l-conf 3.103-1 ii x11-utils 7.7~1 ii xawtv-plugins 3.102-3 ii zlib1g1:1.2.8.dfsg-1 xawtv recommends no packages. Versions of packages xawtv suggests: pn tv-fonts none pn xawtv-plugin-qt none -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703424: Regression: CUPS Web interface fails to authenticate Kerberos access to IPP information
Control: tags -1 +moreinfo Hi Timothy, and thanks for your bugreport, Le mardi, 19 mars 2013 14.32:33, Timothy Pearson a écrit : When using the Web interface to CUPS in a Kerberized environment, CUPS fails to pass Kerberos authentication information to the local IPP socket. This manifests as access being denied to any pages which access printer information, even though the user logged in via Kerberos has been granted access to both the pages and printers in question. The CUPS error log shows that it has rejected unauthenticated access to the printers in question, even though the prior access to the Web printer list page was successfully authenticated. This appears to be a regression introduced when resolving Bug 640939, specifically this patch removes the ability for CUPS to pass Kerberos login credentials to the local IPP socket: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=105;filename=cups-1.5.3-2. 14-nmu.diff;att=1;bug=640939 Can you confirm that this still applies to CUPS 1.6.2 (as uploaded to unstable)? Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701775: wget: Not reproducible in Debian unstable
Package: wget Followup-For: Bug #701775 Dear Maintainer, I just made some tests. The original bug is not reproducible on current unstable neither on current Wheezy. The same goes for msg#31 - the server seems to have a problem since the HTTP header looks fine for me (and of course works with an Apache test environment). I also tested all examples of msg#31, all work fine. It also works on the current Wheezy (i386 kvm virtual machine): ii wget1.13.4-3 ii libc6:i386 2.13-38 ii libgcrypt11:i3861.5.0-5 ii libgnutls26:i3862.12.20-7 ii libgpg-error0:i386 1.10-3.1 ii libidn11:i386 1.25-2 ii libuuid1:i386 2.20.1-5.3 ii zlib1g:i386 1:1.2.7.dfsg-13 -- 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.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages wget depends on: ii libc6 2.17-5 ii libgcrypt111.5.2-2 ii libgnutls262.12.23-5 ii libgpg-error0 1.10-3.1 ii libidn11 1.25-2 ii libuuid1 2.20.1-5.4 ii zlib1g 1:1.2.8.dfsg-1 wget recommends no packages. wget 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#711254: It's a problem of PHP and not MySQL
Hello Bob, Am 10.06.2013 02:30, schrieb Bob Proulx: Thank you for the bug report. However this is very little to go upon. From what you have said so far there isn't enough information to know what might be happening. At this point the problem could be anything. Yes - i have the same problem at this time. But most of the applications are to complex for a simply debug. Because php has been updated to 5.5.0 it is most likely that your wikimedia and phpbb applications are not updated to work with the changes in php 5.5. I think that is the most likely problem. The server installation is complete new (no upgrade) with wheezy from beginning of may. I installed most of the applications new to the latest stable releases. So wikimedia is V 1.20.4. The migration of the previous version seems not make problems. What can i do more than to install the actual version? There is other software that has no newer versions. E.g. http://www.phpmyedit.org/ Here i have the problem that the software is doing nearly nothing. There is no error message in the apache2 logs and links and buttons are not working. But this error is consistent. What i cannot understand is why an update is empty depending of the content (always simple text)? If it didn't work at all then there would be many reports. Yes - i wonder about this also . And i thought that PHP is more downwards compatible. Hopefully someone will answer with the same problem. Therefore this is probably simply an incompatibility with the recent updates and changes in upstream php 5.5. Up to now i can't find similar problem descriptions. Since you have the problem, and no one else is seeing the problem so far, and you have been making progress debugging it then it would be most helpful if you could keep going and get to the bottom of the problem. Thanks, Bob I must find out how to increase the debug information of php5? Here the installed packages: ii libapache2-mod-php5 5.4.4-14 i386 server-side, HTML-embedded scripting language (Apache 2 module) ii php5 5.4.4-14 all server-side, HTML-embedded scripting language (metapackage) ii php5-cli 5.4.4-14 i386 command-line interpreter for the php5 scripting language ii php5-common 5.4.4-14 i386 Common files for packages built from the php5 source ii php5-curl5.4.4-14 i386 CURL module for php5 ii php5-exactimage 0.8.5-5i386 fast image manipulation library (PHP bindings) ii php5-gd 5.4.4-14 i386 GD module for php5 ii php5-geoip 1.0.7-8 i386 GeoIP module for php5 ii php5-imagick 3.1.0~rc1-1+b2 i386 ImageMagick module for php5 ii php5-imap5.4.4-14 i386 IMAP module for php5 ii php5-intl5.4.4-14 i386 internationalisation module for php5 ii php5-mcrypt 5.4.4-14 i386 MCrypt module for php5 ii php5-mysql 5.4.4-14 i386 MySQL module for php5 ii php5-pspell 5.4.4-14 i386 pspell module for php5 ii php5-recode 5.4.4-14 i386 recode module for php5 ii php5-sqlite 5.4.4-14 i386 SQLite module for php5 Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711842: jabref: Fails to start with openjdk-7
Package: jabref Version: 2.10~beta1+ds-2 Severity: important Dear Maintainer, jabref fails to start with openjdk-7: DEBUG_WRAPPER=1 JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/ jabref [debug] /usr/bin/jabref: Using provided JAVA_HOME = '/usr/lib/jvm/java-7 -openjdk-amd64/' [debug] /usr/bin/jabref: Found JAVA_HOME = '/usr/lib/jvm/java-7-openjdk-amd64/' [debug] /usr/bin/jabref: Found JAVA_CMD = '/usr/lib/jvm/java-7-openjdk- amd64//bin/java' [debug] /usr/bin/jabref: Environment variable CLASSPATH is '' [debug] /usr/bin/jabref: Runnning /usr/lib/jvm/java-7-openjdk-amd64//bin/java -classpath /usr/share/java/jabref.jar:/usr/share/java/JPFCodeGenerator- rt.jar:/usr/share/java/antlr.jar:/usr/share/java/antlr3.jar:/usr/share/java /commons- logging.jar:/usr/share/java/glazedlists.jar:/usr/share/java/jempbox.jar:/usr/share/java /jgoodies-common.jar:/usr/share/java/jgoodies-forms.jar:/usr/share/java /jgoodies-looks.jar:/usr/share/java/jpf.jar:/usr/share/java/jpf- boot.jar:/usr/share/java/microba.jar:/usr/share/java/mysql-connector- java.jar:/usr/share/java/pdfbox.jar:/usr/share/java/postgresql.jar:/usr/share/java/spin.jar net.sf.jabref.JabRefMain log4j:WARN No appenders could be found for logger (org.java.plugin.ObjectFactory). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Found 4 plugin(s): - net.sf.jabref.core (jar:file:/usr/share/jabref/JabRef-2.10b.jar!/plugins/net.sf.jabref.core/plugin.xml) - adsfetcher (jar:file:/home/winchen/.jabref/plugins/ADSFetcher-0.3.jar!/plugin.xml) - gvkfetcher (jar:file:/home/winchen/.jabref/plugins/gvkPlugin-0.18.jar!/plugin.xml) - net.sf.jabref.export.misq (jar:file:/usr/share/jabref/JabRef-2.10b.jar!/plugins/net.sf.jabref.export.misq/plugin.xml) Unable to create graphical interface. With openjdk-6 jabref works fine. Brest regards, Tobias -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages jabref depends on: ii antlr 2.7.7+dfsg-5 ii antlr3 3.2-7 ii default-jre [java6-runtime]1:1.6-47 ii java-wrappers 0.1.25 ii libcommons-logging-java1.1.3-1 ii libglazedlists-java1.8.0.dfsg-4 ii libjempbox-java1:1.7.0+dfsg-4 ii libjgoodies-common-java1.4.0-2 ii libjgoodies-forms-java 1.6.0-4 ii libjgoodies-looks-java 2.5.2-2 ii libjpf-java1.5.1+dfsg-4 ii libjpfcodegen-java 0.4+dfsg-4 ii libmicroba-java1:0.4.4.3-4 ii libmysql-java 5.1.16-2 ii libpdfbox-java 1:1.7.0+dfsg-4 ii libpostgresql-jdbc-java9.2-1002-1 ii libspin-java 1.5+dfsg-5 ii openjdk-6-jre [java6-runtime] 6b27-1.12.5-2 ii velocity 1.7-4 Versions of packages jabref recommends: ii libreoffice-java-common 1:4.0.3-3 ii libreoffice-writer 1:4.0.3-3 ii xdg-utils1.1.0~rc1+git20111210-7 Versions of packages jabref suggests: ii evince [postscript-viewer] 3.4.0-3.1 ii ghostscript [postscript-viewer] 9.05~dfsg-6.3 ii gv [postscript-viewer] 1:3.7.3-1 ii okular [postscript-viewer] 4:4.8.4-3+b1 pn xpdf-reader | pdf-viewer 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#711540: iproute2 FTBFS on sparc
08.06.2013 15:31, Andreas Henriksson wrote: Hello Michael! I'm mostly offline until next week, but have a quick moment to give you a reply on this. (please beware that I've only had a few minutes to look into it all.) And I think that next week is now current, too... I too was out of the city during the weekend and wasn't able to reply sooner than now. Thank you for the the comments. It seems the initial bug report mail hasn't reached me... :/ Well, I just submitted a bugreport. Before, I also wrote to the address listed in Maintainer: field, -- I sent almost the same thing as in the bugreport, but were just asking if your guys need any help or not and what's up with that issue. After some days without reply I filed the bugreport. On Sat, Jun 08, 2013 at 02:21:53AM +0400, Michael Tokarev wrote: diff -Nru iproute2-3.9.0/debian/changelog iproute2-3.9.0/debian/changelog --- iproute2-3.9.0/debian/changelog 2013-05-08 16:27:40.0 +0400 +++ iproute2-3.9.0/debian/changelog 2013-06-07 21:54:32.0 +0400 @@ -1,3 +1,14 @@ +iproute2 (3.9.0-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add debian/patches/suseconds-to-long.diff to fix FTBFS on sparc +(Closes: #711540) Not a big issue, your way probably works too... but using the upstream commit fixing this would IMHO be better. I didn't know there's an upstream commit addressing this. I don't even know where iproute2 is maintained upstream, -- probaly it'd be better if I looked. I just tried to fix the immediate issue (which is rather trivial), basically leaving the full expertise to someone who is more familiar with the package. + * Urgency is set to medium because due to the above bug, the package +is holding a long and complicated list of other packages which +grows and becomes more complicated. I fail to see this! Someone would have to have introduced a versioned dependency or change from iproute to iproute2. Who has done so? You mentioned ifupdown, which has the same version in unstable testing!!! You also mentioned netcf, which primary reason for not migrating (yet) is that it's too young. secondarily that buildds on some arch are trying to catch up doesn't seem at all related to iproute2. Well. This all may have something to do with my incomplete understanding of how buildd works. This is what I have in mind: https://buildd.debian.org/status/package.php?p=netcf Dependency installability problem for netcf on sparc: netcf (= 1:0.2.3-3) build-depends on one of: - ifupdown (= 0.7.43) - netscript-2.4 (= 5.2.12) The exact version is not in build-depends, it is from internals of buildd, it is the version which were available at the time of build but it weren't installable. And it _looks_ like inability to install ifupdown on SID boils down to the fact that iproute[2] just isn't available on SID for sparc, and ifupdown depends on iproute. This is the middle of the chain, but it is the most non-obvious step I think. So as far as I can see, netcf can't be _built_ on _sid_ because one of its build-deps aren't installable on _sid_ (not testing!), so there's no netcf available on sid, so any other build-dependent packges can't be built either. So we're at the situation we're at, with a long(ish) and non-obvious chain of unsatisfyable build-deps. My understanding is that a package isn't available as build-dep on sid before it is built itself on all necessary arches. Yes you're right that netcf isn't reached 10 days yet (it passes today), but even if it did, that wont be of any help because of the above. And yes, netcf is just one of several issues we have with libvirt qemu. I'm trying to resolve them all at the same time. Maybe DELAYED/3 was a bit too soon, especially since we both had no time to look at it during the weekend. But on the other hand, the issue and the fix are so trivial it's a pity this thing is holding anything at all. If it actually does -- note I stated at the very beginning that I'm not exactly sure I understand the working of buildds right. No time to look at more of these, but again... I fail to see how iproute2 could be blocking anything from migrating. Please educate me on what I'm missing... (maybe it'll be obvious next week when I'm not in such a hurry.) If you still think the NMU is needed, then don't hold back with delayed uploads! Thank you for the trust! However, it is always nice, I think, to ask the maintainer first and to let him to have a chance to review, correct or maybe even fix the upload, or to implement maybe a better fix he was planning. And as I mentioned above, and as you already found out, I'm not exactly familiar with the package, and I didn't know there's an upstream fix for that. How about me cancelling the delayed upload instead, until there's some time to do that left? ;) PS. you mentioned a binNMU which it's clearly not since you're modifying the source of the package.
Bug#711822: [Pkg-electronics-devel] Bug#711822: pcb: FTBFS (gtk/gtkgl.h: No such file or directory)
reassign 711822 libgtkglext1-dev 1.2.0-3 quit On Mon, Jun 10, 2013 at 08:13:22AM +0200, Julien Cristau wrote: Source: pcb Version: 20110918-7 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: jessie sid Control: block 706828 with -1 See the build logs at https://buildd.debian.org/status/logs.php?pkg=pcbver=20110918-7%2Bb1suite=sid gcc -std=gnu99 -DLOCALEDIR=\/usr/share/locale\ -DHAVE_CONFIG_H -I. -I../../src -I.. -I../.. -I../../src/icons -I../../src/../gts -I./hid/gtk -D_FORTIFY_SOURCE=2 -DPREFIXDIR=\/usr\ -DBINDIR=\/usr/bin\ -DHOST=\x86_64-pc-linux-gnu\ -DPCBLIBDIR=\/usr/share/pcb\ -DPCBTREEDIR=\/usr/share/pcb/newlib\ -DPCBTREEPATH=\/usr/share/pcb/newlib:/usr/share/pcb/pcblib-newlib\ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/harfbuzz -pthread -pthread -Wall -Wdeclaration-after-statement -DNDEBUG -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/harfbuzz -pthread -pthread -Wall -Wdeclaration-after-statement -MT hid/gtk/libgtk_a-gtkhid-gl.o -MD -MP -MF hid/gtk/.deps/libgtk_a-gtkhid-gl.Tpo -c -o hid/gtk/libgtk_a-gtkhid-gl.o `test -f 'hid/gtk/gtkhid-gl.c' || echo '../../src/'`hid/gtk/gtkhid-gl.c ../../src/hid/gtk/gtkhid-gl.c:28:23: fatal error: gtk/gtkgl.h: No such file or directory compilation terminated. make[6]: *** [hid/gtk/libgtk_a-gtkhid-gl.o] Error 1 ---end quoted text--- libgtkglext1-dev needs to add libpangox-1.0-dev to its Depends: # pkg-config --cflags gtkglext-1.0 Package pangox was not found in the pkg-config search path. Perhaps you should add the directory containing `pangox.pc' to the PKG_CONFIG_PATH environment variable Package 'pangox', required by 'GdkGLExt', not found -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Bug#711843: libusb-java: Fix FTBFS for distro targets where default-java != openjdk-6
Package: libusb-java Version: 0.8+ztex20090101-5.1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu saucy ubuntu-patch Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: * d/p/jniInclude.patch: Restore original auto-detection of JAVAPREFIX so that package continues to build on targets with default-java != openjdk-6. Thanks for considering the patch. -- System Information: Debian Release: wheezy/sid APT prefers raring-updates APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 'raring-proposed'), (500, 'raring'), (100, 'raring-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8.0-24-generic (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 diff -Nru libusb-java-0.8+ztex20090101/debian/changelog libusb-java-0.8+ztex20090101/debian/changelog diff -Nru libusb-java-0.8+ztex20090101/debian/patches/jniInclude.patch libusb-java-0.8+ztex20090101/debian/patches/jniInclude.patch --- libusb-java-0.8+ztex20090101/debian/patches/jniInclude.patch 2012-09-16 19:56:37.0 +0100 +++ libusb-java-0.8+ztex20090101/debian/patches/jniInclude.patch 2013-06-10 09:01:33.0 +0100 @@ -1,14 +1,11 @@ -Index: libusb-java-0.8+ztex20090101/Makefile -=== libusb-java-0.8+ztex20090101.orig/Makefile 2011-02-02 13:13:45.0 +0100 -+++ libusb-java-0.8+ztex20090101/Makefile 2012-09-16 20:45:06.0 +0200 -@@ -13,7 +13,8 @@ +--- a/Makefile b/Makefile +@@ -13,7 +13,7 @@ # # $(JAVAPREFIX)/include should contain jni.h -JAVAPREFIX=/usr/local/java -+#JAVAPREFIX=$(shell find /usr/lib/jvm/ -name jni.h | sed -e 's/include.*//' | head -n 1) -+JAVAPREFIX=/usr/lib/jvm/java-6-openjdk-$(shell dpkg-architecture -qDEB_BUILD_ARCH|tr -d \n) ++JAVAPREFIX=$(shell find /usr/lib/jvm/ -name jni.h | sed -e 's/include.*//' | head -n 1) ### # this should not be modified #
Bug#652480: wget: Fails to verify SSL server certificate
Package: wget Version: 1.14-2 Followup-For: Bug #652480 Dear Maintainer, while the problem still exists in Debian Sid, a self-compiled wget (linking to gnutls 3.1) works well. wget https://developer.pidgin.im/static/win32/cyrus-sasl-2.1.22.zip --2013-06-10 10:08:37-- https://developer.pidgin.im/static/win32/cyrus-sasl-2.1.22.zip Resolving developer.pidgin.im (developer.pidgin.im)... 67.202.116.116, 2607:f128:40:2400::16 Connecting to developer.pidgin.im (developer.pidgin.im)|67.202.116.116|:443... connected. ERROR: The certificate of 'developer.pidgin.im' is not trusted. ERROR: The certificate of 'developer.pidgin.im' hasn't got a known issuer. ../src/wget https://developer.pidgin.im/static/win32/cyrus-sasl-2.1.22.zip --2013-06-10 10:10:20-- https://developer.pidgin.im/static/win32/cyrus-sasl-2.1.22.zip Resolving developer.pidgin.im (developer.pidgin.im)... 67.202.116.116, 2607:f128:40:2400::16 Connecting to developer.pidgin.im (developer.pidgin.im)|67.202.116.116|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 795294 (777K) [application/zip] Saving to: 'cyrus-sasl-2.1.22.zip.2' 100%[===] 795,294 586KB/s in 1.3s 2013-06-10 10:10:22 (586 KB/s) - 'cyrus-sasl-2.1.22.zip.2' saved [795294/795294] [patchwork.sugarlabs.org can't be resolved any more.] -- 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.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages wget depends on: ii libc6 2.17-5 ii libgcrypt111.5.2-2 ii libgnutls262.12.23-5 ii libgpg-error0 1.10-3.1 ii libidn11 1.25-2 ii libuuid1 2.20.1-5.4 ii zlib1g 1:1.2.8.dfsg-1 wget recommends no packages. wget 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#711780: systemd: boot hangs on checking/mounting FAT or Ext4 filesystems
Am Montag, 10. Juni 2013, 00:00:08 schrieb Michael Biebl: Am 09.06.2013 19:22, schrieb Martin Steigerwald: Package: systemd Version: 44-11 Severity: important Dear Maintainer, Today I build a 3.10-rc5 kernel from upstream and rebooted in order to use it. Then systemd hung on mounting or checking /boot/efi (FAT32) I booted into system rescue mode and commented out /boot/efi in fstab. Then on reboot systemd hung on mounting or checking /boot (Ext4). Then I used /sbin/init to boot up the system which comes up just fine. /etc/fstab entries for both: LABEL=boot /boot ext4noatime 0 1 /dev/sda2 /boot/efi vfatnoatime 0 0 merkaba:~ blkid | egrep (boot|msdos) /dev/sda2: SEC_TYPE=msdos UUID=[…] TYPE=vfat· /dev/sda3: LABEL=boot UUID=[…] TYPE=ext4 I am not reporting upstream, since the systemd version in Debian is outdated. Since it worked so far I bet some recent update broke it. Can be just a few days since I successfully rebooted into a new kernel a few days ago with systemd. The systemd package itself hasn't changed for quite a while, so I suspect a change in another package. Can you try to use the Debian kernel from sid or wheezy? Happens also with linux-image-3.9-1-amd64 (3.9.4-1). With 3.10-rc5 I waited a bit longer for it to happen and got some additional messages from systemd: About 9th second of booting: Started /boot... EXT4.fs (sda3): mounted filesystem with ordered data mode. Opts: (null) Started /boot/efi... FAT-fs (sda2): utf8 is not a recommended IO charset for FAT filesystems will be case sensitive! FAT-fs (sda2): Volume is not properly unmounted. Some data may be corrupt. Please run fsck. [... some kernel messages about psmouse serio2 and IBM Trackpoint ...] About 15th second of booting: Dependency failed. Aborted start of /mnt/home-zeit Welcome to emergency mode. Use systemctl default or ^D to enter default mode. Give root password for maintenance (or type Control-D to continue): I give root password. Then do mount /mnt/home-zeit which works just well. No errors in dmesg. /mnt/home-zeit has the root subvol of the /home BTRFS filesystem mounted, which contains the snapshots so that they can easily be excluded on backup. LABEL=home /home btrfs noatime,space_cache,compress=lzo0 0 LABEL=home /mnt/home-zeit btrfs noatime,space_cache,compress=lzo,subvolid=5 0 0 The filesystem scrubbed just well last Saturday, so I think it is okay. Will scrub it again today to make sure. Last update of btrfs-progs was Start-Date: 2013-05-20 20:32:27 Commandline: apt-get upgrade Upgrade: libavformat53:amd64 (0.8.6-1, 0.8.7-1), libavformat54:amd64 (9.5-1, 9.6-1), libstartup-notification0:amd64 (0.12-1, 0.12-3), libevent-2.0-5:amd64 (2.0.19-stable-3, 2.0.21-stable-1), libavresample1:amd64 (9.5-1, 9.6-1), libavfilter2:amd64 (0.8.6-1, 0.8.7-1), libpython2.7-stdlib:amd64 (2.7.5-3, 2.7.5-4), luatex:amd64 (0.70.1.20120524-3, 0.76.0-1), python-pylibacl:amd64 (0.5.1-1.1, 0.5.1-1.1+b1), libavcodec-extra-53:amd64 (0.8.6-1, 0.8.7-1), libattr1:amd64 (2.4.46-8, 2.4.47-1), libattr1:i386 (2.4.46-8, 2.4.47-1), libattr1-dev:amd64 (2.4.46-8, 2.4.47-1), python2.7:amd64 (2.7.5-3, 2.7.5-4), libswscale2:amd64 (9.5-1, 9.6-1), ffmpeg:amd64 (0.8.6-1, 0.8.7-1), python-pyxattr:amd64 (0.5.1-1.1, 0.5.1-1.1+b1), libav-tools:amd64 (0.8.6-1, 0.8.7-1), libpython2.7:amd64 (2.7.5-3, 2.7.5-4), libpostproc52:amd64 (0.8.6-1, 0.8.7-1), dnsmasq-base:amd64 (2.66-1, 2.66-2), libdlrestrictions1:amd64 (0.15.6, 0.15.7), libgps20:amd64 (3.6-5, 3.9-1), libkpathsea6:amd64 (2012.20120628-4, 2013.20130516.30500-1), cmake:amd64 (2.8.9-1, 2.8.11-2), pkg-kde-tools:amd64 (0.15.6, 0.15.7), python2.7-minimal:amd64 (2.7.5-3, 2.7.5-4), libavcodec54:amd64 (9.5-1, 9.6-1), libavdevice53:amd64 (0.8.6-1, 0.8.7-1), cmake-curses-gui:amd64 (2.8.9-1, 2.8.11-2), tex-common:amd64 (4.02, 4.03), btrfs-tools:amd64 (0.19+20130131-3+really20121004-1, 0.19+20130315-2), cmake-data:amd64 (2.8.9-1, 2.8.11-2), printer-driver-m2300w:amd64 (0.51-7, 0.51-9), ethtool:amd64 (3.4.2-1, 3.9-1), attr:amd64 (2.4.46-8, 2.4.47-1), libptexenc1:amd64 (2012.20120628-4, 2013.20130516.30500-1), libdbd-mysql-perl:amd64 (4.021-1+b1, 4.023-1), libpython2.7-minimal:amd64 (2.7.5-3, 2.7.5-4), libavutil51:amd64 (0.8.6-1, 0.8.7-1), libavutil52:amd64 (9.5-1, 9.6-1), printer-driver-ptouch:amd64 (1.3-4, 1.3-6) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2013-05-20 20:33:28 I don´t remember the error. Ah according to term.log.1.gz it was tex: Log started: 2013-05-20 20:32:27 […] tex-common (4.03) wird eingerichtet ... Running mktexlsr. This may take some time... done. Running updmap-sys. This may take some time... updmap-sys failed. Output has
Bug#711844: illegal-runtime-test-name on capital letters in test names
Package: lintian Version: 2.5.13 When I was working on some packaging for xorg-integration-tests, I noticed that capital letters were not allowed in a test name. I can run xorg-integration-tests just fine with them, so it looks like a bug in lintian, or the autopkgtest documentation must be changed to explicitly allow capital letters in the test names. $ lintian xorg-integration-tests_0.0.1.20130523-0ubuntu1.dsc W: xorg-integration-tests source: illegal-runtime-test-name lib.libX11 W: xorg-integration-tests source: illegal-runtime-test-name lib.libXi The original test binary names are libX11 and libXi in xorg-integration-tests.git, so it would make sense to have the test names the same. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711273: [Pkg-xen-devel] Bug#711273: xen-hypervisor-4.2-amd64: Acn't re-create domains after migration from 4.1 to 4.2
severity -1 important On Thu, Jun 06, 2013 at 12:57:56AM +0200, JP Pozzi wrote: Severity: critical Justification: breaks the whole system Please explain how it breaks the system and not only itself? After migration from Xen 4.1 to 4.2 all VMs have disapeared and I am unable to re-create my VM from the configfiles. When I try xm new com-web i get a python message : Please provide the config file in question and the contents of /var/log/xen/xend.log. Is it a problem of Python version ? Unlikely. The easiest fix is to use the new stack called xl by modifying /etc/default/xen with TOOLSTACK=xl. This will get the default in the near future. Bastian -- What terrible way to die. There are no good ways. -- Sulu and Kirk, That Which Survives, stardate unknown -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711844: illegal-runtime-test-name on capital letters in test names
reassign 711844 autopkgtest severity 711844 wishlist retitle 711844 autopkgtest: Allow uppercase letters in test names thanks On 2013-06-10 10:19, Maarten Lankhorst wrote: Package: lintian Version: 2.5.13 When I was working on some packaging for xorg-integration-tests, I noticed that capital letters were not allowed in a test name. I can run xorg-integration-tests just fine with them, so it looks like a bug in lintian, or the autopkgtest documentation must be changed to explicitly allow capital letters in the test names. Lintian is following the spec here: Test names are separated by whitespace and should contain only characters which are legal in package names, plus `/'. Uppercase letters are not allowed in package names. Re-assigning to autopkgtest as a wishlist bug. [...] The original test binary names are libX11 and libXi in xorg-integration-tests.git, so it would make sense to have the test names the same. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711254: [php-maint] Bug#711254: It's a problem of PHP and not MySQL
On Mon, Jun 10, 2013 at 9:58 AM, Karsten Malcher deb...@dct.mine.nu wrote: The server installation is complete new (no upgrade) with wheezy from beginning of may. I installed most of the applications new to the latest stable releases. So wikimedia is V 1.20.4. There was something related to the upgrade of mediawiki in Debian: http://anonscm.debian.org/viewvc/pkg-mediawiki/mediawiki/trunk/debian/NEWS?view=markup But I am not sure if this is related to your installation. Does the affected applications use some common (could be PEAR or PECL or just some PHP files somewhere) library which you have installed by hand? Ondrej -- Ondřej Surý ond...@sury.org
Bug#711845: xfce4-verve-plugin: Verve CL plugin breaks auto-hide panel ability
Package: xfce4-verve-plugin Version: 1.0.0-2 Severity: normal Dear Maintainer, When I add verve-plugin to the xfce panel and enter any command, this panel stops to hide despite of it pointed in panel preferences. Panel stays always visible until reboot. After reboot this situation repeats again: I enter anything to verve command-line and panel becomes constantly visible. I hope it can be solved easily. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xfce4-verve-plugin depends on: ii exo-utils 0.10.2-2 ii libc6 2.17-3 ii libcairo2 1.12.14-4 ii libdbus-1-3 1.6.10-1 ii libdbus-glib-1-20.100.2-1 ii libgdk-pixbuf2.0-0 2.28.1-1 ii libglib2.0-02.36.1-2build1 ii libgtk2.0-0 2.24.18-1 ii libpcre31:8.31-2 ii libxfce4util6 4.10.1-1 ii libxfcegui4-4 4.10.0-2 ii xfce4-panel 4.10.1-1 xfce4-verve-plugin recommends no packages. xfce4-verve-plugin 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#697158: snappy1.0.3-java: Fixup jar file installation under newer versions of maven-debian-helper
Package: snappy1.0.3-java Version: 1.0.3-rc3~dfsg-3 Followup-For: Bug #697158 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu saucy ubuntu-patch Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: * Fixup installation of jar files (LP: #1078012): - d/snappy1.0.3-java: Use --java-lib to ensure jar file is installed to /usr/share/java. - d/links: Dropped, no longer required. Ubuntu carried a delta for a while which mean't that jar files where automatically installed to /usr/share/java for the right packages; the links file was overwriting this and causing a link circle. The same change is now in the Debian version of m-d-h as well. Thanks for considering the patch. -- System Information: Debian Release: wheezy/sid APT prefers raring-updates APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 'raring-proposed'), (500, 'raring'), (100, 'raring-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8.0-24-generic (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 diff -Nru snappy1.0.3-java-1.0.3-rc3~dfsg/debian/changelog snappy1.0.3-java-1.0.3-rc3~dfsg/debian/changelog diff -Nru snappy1.0.3-java-1.0.3-rc3~dfsg/debian/libsnappy1.0.3-java.poms snappy1.0.3-java-1.0.3-rc3~dfsg/debian/libsnappy1.0.3-java.poms --- snappy1.0.3-java-1.0.3-rc3~dfsg/debian/libsnappy1.0.3-java.poms 2012-09-03 07:36:24.0 +0100 +++ snappy1.0.3-java-1.0.3-rc3~dfsg/debian/libsnappy1.0.3-java.poms 2013-06-10 09:40:16.0 +0100 @@ -25,4 +25,4 @@ # --site-xml=location: Optional, the location for site.xml if it needs to be installed. # Empty by default. [mh_install] # -pom.xml +pom.xml --java-lib diff -Nru snappy1.0.3-java-1.0.3-rc3~dfsg/debian/links snappy1.0.3-java-1.0.3-rc3~dfsg/debian/links --- snappy1.0.3-java-1.0.3-rc3~dfsg/debian/links 2012-09-03 07:41:38.0 +0100 +++ snappy1.0.3-java-1.0.3-rc3~dfsg/debian/links 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -/usr/share/maven-repo/org/xerial/snappy/snappy1.0.3-java/1.0.3-rc3/snappy1.0.3-java-1.0.3-rc3.jar /usr/share/java/snappy1.0.3-java.jar
Bug#711254: [php-maint] Bug#711254: It's a problem of PHP and not MySQL
Hello, Am 10.06.2013 10:42, schrieb Ondřej Surý: On Mon, Jun 10, 2013 at 9:58 AM, Karsten Malcher deb...@dct.mine.nu mailto:deb...@dct.mine.nu wrote: The server installation is complete new (no upgrade) with wheezy from beginning of may. I installed most of the applications new to the latest stable releases. So wikimedia is V 1.20.4. There was something related to the upgrade of mediawiki in Debian: http://anonscm.debian.org/viewvc/pkg-mediawiki/mediawiki/trunk/debian/NEWS?view=markup But I am not sure if this is related to your installation. The user has all rights for the DB. There is a good and comfatable installer for mediawiki. Every checkes and migration works without problem. I have the reported problems with the user. For this i will ask the mediawiki team. Does the affected applications use some common (could be PEAR or PECL or just some PHP files somewhere) library which you have installed by hand? No - i only downloaded the installation file and unpacked it. Thank you for help. Karsten Ondrej -- Ondřej Surý ond...@sury.org mailto:ond...@sury.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699274: wget segfault: -T 0 --no-check-certificate
Package: wget Followup-For: Bug #699274 Dear Maintainer, this seems to be an issue of wget 1.13 on wheezy. The following version work as expected: ii wget1.11.4-2+lenny2 [lenny] ii wget1.12-2.1 [squeeze] ii wget1.14-2 [sid] -- 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.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages wget depends on: ii libc6 2.17-5 ii libgcrypt111.5.2-2 ii libgnutls262.12.23-5 ii libgpg-error0 1.10-3.1 ii libidn11 1.25-2 ii libuuid1 2.20.1-5.4 ii zlib1g 1:1.2.8.dfsg-1 wget recommends no packages. wget 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#711582: jasmin-sable: Patch to fix FTBFS
Package: jasmin-sable Version: 2.4.0-2 Followup-For: Bug #711582 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu saucy ubuntu-patch Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: * d/rules: Add '-p' option when creating classes dir to prevent FTBFS. Thanks for considering the patch. -- System Information: Debian Release: wheezy/sid APT prefers raring-updates APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 'raring-proposed'), (500, 'raring'), (100, 'raring-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8.0-24-generic (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 diff -Nru jasmin-sable-2.4.0/debian/changelog jasmin-sable-2.4.0/debian/changelog diff -Nru jasmin-sable-2.4.0/debian/rules jasmin-sable-2.4.0/debian/rules --- jasmin-sable-2.4.0/debian/rules 2013-05-22 23:46:56.0 +0100 +++ jasmin-sable-2.4.0/debian/rules 2013-06-10 09:14:41.0 +0100 @@ -10,7 +10,7 @@ dh $@ override_dh_auto_build: - mkdir classes + mkdir -p classes ant build_parser jasmin-jar override_dh_auto_clean:
Bug#711816: New upstream version available
hi, On Mon, Jun 10, 2013 at 01:10:20AM -0300, Rog?rio Brito wrote: There is a new upstream version available (at the moment, it is 4.34), which incorporates both the previous feature request of mine as well as canonicalization of the device names. i will try to care about this in the coming days! BTW, the Debian packaging of di could have some some. Do you have it under some VCS? at the moment not, in case we could move it to collab-maint or something! bye, - michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#152311: still a bug
This one still happens almost 11 years later. Strangely creating a subdirectory of the freecraft tree that is writable by the user doesn't help. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476545: drbd8-utils: drbd should start before mountnfs.sh mounts ocfs2 filesystems
Package: drbd8-utils Version: 2:8.3.13-2 Followup-For: Bug #476545 Hi, just to add that this bug is also preventing ocfs2 filesystems on drbd devices from being mounted automatically. I tried using Wiebe's workaround (mentioned earlier in this BTS thread): My problem is that drbd is started after xendomains, but drbd needs to be active for starting Xen domains (in my case). I added xendomains to the following parameters in /etc/init.d/drbd: # X-Start-Before: heartbeat corosync xendomains # X-Stop-After: heartbeat corosync xendomains with his xendomains changed to mountnfs (and mountnfs.sh) but without success. In the end I just set the mounts to 'noauto' and mount them from rc.local (and restart nfs-kernel-server too, as my ocfs2 systems are exported via NFS). Alexis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711841: xawtv makes whole system freezed
¡Hola Atsuhito! El 2013-06-10 a las 16:02 +0900, Atsuhito Kohda escribió: * What led up to the situation? only upgrading xawtv from 3.102-3 to 3.103-1 * What was the outcome of this action? system was freezex and didn't accept any key iputs etc. so I needed to power down by power button. I now downgraded xawtv to 3.102-3 and manually changed version number in reportbug session. Please don't ask me try again 3.103-1. It certainly made my system deep freezed. As much as I understand that you don't want your system to freeze, I can't reproduce it here so I will need more information about your system. -- debconf information excluded Could you provide the output of: debconf-show xawtv? Also, what kind of v4l2 input are you using? Could you provide the output of: lspci and lsusb? If you have xawtv/build-config in true the postinst script of xawtv might call scantv, which would open the first v4l2 device and search signals in the specified frequencies, if this is causing your system to hang I would suspect of a kernel issue regarding the module for your first v4l2 device (scantv might be slow, or even buggy, but it shouldn't hang your system, that's normally a kernel issue.). You can skip the scantv by reconfiguring xawtv and setting xawtv/build-config: false. -- There are only two things wrong with C++: The initial concept and the implementation. -- Bertrand Meyer Saludos /\/\ /\ `/ signature.asc Description: Digital signature
Bug#711759: flash-kernel: FTBFS in test_db due to sorting vs. locale issues
On Sun, Jun 09, 2013, Cyril Brulebois wrote: I think I'll work around it by exporting LC_ALL=C for wheezy (which is affected by a similar issue with the tagged-but-not-uploaded 3.3+deb7u1), at least until a proper fix lands in master. Fetching more changes from master, including the Bootloader-Sets-Root case change, looks way too intrusive for wheezy, and it isn't sufficient anyway. Yeah, I ran into this when preparing the 3.7 upload, but catched it in sbuild; I fixed this in 67e61b9cfa883d3b6ec234c773de1e0b01e48476 by ignoring the case when sorting (and updating the order of fields in the test), isn't that enough in the backport? Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708548: security policy / root passwords
Hi, Le dimanche 09 juin 2013 à 18:45 +0200, Daniel Pocock a écrit : There have been multiple complaints about the new Gnome popup asking for the root password I opened a bug for discussion about the issue, but it was closed by another DD (not the maintainer) - [1]. Other users have come across the bug too and requested attention for it with the same concerns that I have. Essentially, my feeling is that users should be encouraged to NEVER put their root password into some popup that appears spontaneously on their computer. Having this popup in Debian, by default, desensitizes users to the type of popups that will aim to deceive them. I think there is some big confusion here. It is not new for GNOME to ask for the root password for actions that require root permissions. This is done through PolicyKit, which avoids to run privileged code in the GUI, but which will nevertheless require to type the root password in an unprivileged process (there is not much way around that). What is new is that PackageKit asks for a system update *systematically* when it finds the system is not up-to-date. I don’t know why, but it seems to have started with the wheezy release, it did not happen during the freeze. I consider it a bug, and one that we should aim to fix in the first wheezy point release. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711846: iceweasel windows resized to 0x0 due to wrongly interpreted maximum width and height
Package: sawfish Version: 1:1.5.3-2.1+b1 Severity: serious Tags: patch Since iceweasel 17, which hit stable now, resizing a browser window results in it being 0x0. For me, one window is immediately sized to an unusable dimension, another one is strangely unaffected. This effectively breaks iceweasel for me, thus the severity. If I am the only one seeing this, it can be downgraded, of course. I am testing backporting an upstream patch right now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711847: security upgrade to iceweasel 17 (needlessly) breaks cookie monster
Package: xul-ext-cookie-monster Version: 1.1.0-4 Severity: grave With the upgrade to iceweasel 17, cookie monster 1.1.0-4 became uninstallable. The changes from -5 fix that, so this is a request to migrate 1.1.0-5 to wheezy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708863: GFDL with invariant section
On Sat, Jun 8, 2013 at 10:01 AM, أحمد المحمودي aelmahmo...@sabily.org wrote: On Sun, May 19, 2013 at 11:14:53AM +0200, bastien ROUCARIES wrote: dico.info as front cover please render dfsg compliant ---end quoted text--- I don't understand, what is the problem ? and what should I do to fix it ? File under doc/ include license: Copyright @copyright{} 2008, 2010 Sergey Poznyakoff Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover texts being ``GNU Dico Manual'', and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled ``GNU Free Documentation License''. (a) The FSF's Back-Cover Text is: ``You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.'' @end copying Please read http://wiki.debian.org/qa.debian.org/gfdlinvariant -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711837: RFA: mapnik -- C++/Python toolkit for developing GIS applications
This packages seems in a quite good situation. Is it? The boost transition will effect this package. Is it will be need to bump package name then? On Mon, Jun 10, 2013 at 3:33 PM, David Paleino da...@debian.org wrote: Package: wnpp Severity: normal I request an adopter for the mapnik package. The package is currently maintained within the Debian GIS Team, CCed. The package description is: Mapnik is an OpenSource C++/Python toolkit for developing GIS (Geographic Information Systems) applications. At the core is a C++ shared library providing algorithms/patterns for spatial data access and visualization. . Essentially a collection of geographic objects (map, layer, datasource, feature, geometry), the library doesn't rely on windowing systems and is intended to work in multi-threaded environments . High-level Python bindings (boost.python) facilitate rapid application development, targeting zope3, django, etc. . This package contains the development headers, API documentation, and build utilities. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711848: cups-client: lp and lpr print the document on a wrong printer
Package: cups-client Version: 1.6.2-8 Severity: grave Tags: security Justification: user security hole I have the following options in .cups/lpoptions: Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi Default lipucb-mono-1 The lpq command gives as expected: lipucb-mono-1 is ready no entries But when I print a document with lpr file.pdf, I get nothing on this printer. Then I tried: lp file.pdf, and I get nothing either on this printer, but the following line was output in the terminal: request id is lip-multi-1-292103 (1 file(s)) lip-multi-1 is a printer in a different building... The LPDEST and PRINTER environment variables are not set. CUPS 1.5.x didn't have such a problem. This is a big security problem when one wants to print documents with confidential information... -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cups-client depends on: ii adduser3.113+nmu3 ii cups-common1.6.2-8 ii libc6 2.17-5 ii libcups2 1.6.2-8 ii libcupsimage2 1.6.2-8 Versions of packages cups-client recommends: pn smbclient none Versions of packages cups-client suggests: ii cups 1.6.2-8 ii cups-bsd 1.6.2-8 ii xpp 1.5-cvs20050828-1.2 -- 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#711846: Patch: iceweasel windows resized to 0x0 due to wrongly interpreted maximum width and height
Straight from debian/patches. Description: cap max-width / max-height of a window Cherry-picked from upstream commit 798c6992. Fixes issues with Iceweasel 17. Author: Robert Bihlmeyer ro...@orcus.priv.at Origin: upstream Bug-Debian: 711846 --- sawfish-1.5.3.orig/src/windows.c +++ sawfish-1.5.3/src/windows.c @@ -1286,6 +1286,13 @@ associated with WINDOW. Possible keys in hints = VWIN(win)-hints; flags = hints-flags; +/* workaround stuff like Firefox 17 that + * has enormous max-width/maxh-height */ +if (hints-max_width = 32767) + hints-max_width = 32767; +if (hints-max_height = 32767) + hints-max_height = 32767; + /* Some sanity checking */ if ((flags PMinSize) (hints-min_width 0 || hints-min_height 0))
Bug#711820: unburden-home-dir: Manpage contains du-related See also
Control: tag -1 + moreinfo Hi Daniel, thanks for caring about unburden-home-dir. Daniel Koch wrote: The Man-Page contains this: SEE ALSO corekeeper (http://openvswitch.org/cgi-bin/gitweb.cgi?p=corekeeper), autotrash(1), agedu(1), bleachbit(1). For du(1)-like but more comfortable tools, see ncdu(1) (text-mode), baobab(1) (GNOME), filelight(1) (KDE), xdiskusage(1) (X tool calling du(1) itself), or xdu(1) (X tool reading du(1) output from STDIN). This seams to be related to du. I guess it was used as an template. Why should it be from a template? I actually fail to see the issue here. That entry looks as expected and intended for me. (... with the exception that there's no more need for the corekeeper URL as corekeeper is back in Debian. But I guess that's not what you meant.) Can you please tell me a little bit more verbose what you think that is wrong with the cited man-page excerpt? Or maybe tell me what you would have expected instead of the above text since it seems not having the effect I intended. My plan was to point users to tools which can be helpful in finding files they want to add to their unburden-home-dir configuration. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657215: [PATCH videoproto] Xvproto: fix xvEncodingInfo to match actual wire protocol
On 9 June 2013 19:00, Julien Cristau jcris...@debian.org wrote: The padding is *before* the rate field, so the rate is placed on a 32bit boundary. This change adds explicit padding between height and rate, and removes extraneous padding after the rate field, which the server never sent and xlib never read. This changes sizeof(xvEncodingInfo). Hopefully that's not a big deal as clients only see the Xlib structure XvEncodingInfo. (Hopefully, I'm right with that): I think that's an ABI change and a bit more difficult. Think about an X server, which is compiled against a xvproto version without that change and the lib compiled against xvproto with that change. In that case the lib would start to read the encoding info, where the X server just sended those extraneous pad bytes. I just saw that the reply structure itself (xvQueryEncodingsReply) has such extraneous padding too: ... CARD32 length B32; CARD16 num_encodings B16; CARD32 padl3 B32; ... And even without this padding sz_xvQueryEncodingsReply=32 is wrong, as the fields sum up to 34 and with that padding we're at 36. Cheers, Daniel Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711837: RFA: mapnik -- C++/Python toolkit for developing GIS applications
On Mon, 10 Jun 2013 17:28:10 +0800, YunQiang Su wrote: This packages seems in a quite good situation. Is it? There is a new upstream version, and it needs to be re-transitioned to libmapnik (from the current libmapnik2). Also, there's a SONAME bump involved. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#711848: cups-client: lp and lpr print the document on a wrong printer
Control: severity -1 important Control: tags -1 +moreinfo +unreproducible Hi Vincent, and thanks for your bugreport, Le lundi, 10 juin 2013 11.25:57, Vincent Lefevre a écrit : I have the following options in .cups/lpoptions: Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi Default lipucb-mono-1 I did lpoptions -d new-default-printer and got that Default line in .cups/lpoptions too. The lpq command gives as expected: lipucb-mono-1 is ready no entries Same here. But when I print a document with lpr file.pdf, I get nothing on this printer. Then I tried: lp file.pdf, and I get nothing either on this printer, but the following line was output in the terminal: When trying here with either lpr or lp, I get the file printed on the correct new-default-printer (which is obviously not the same printer as the system's default printer) as defined above, so I can't reproduce your problem here. What are the access rights and contents of /etc/cups/lpoptions and .cups/lpoptions ? CUPS 1.5.x didn't have such a problem. This is a big security problem when one wants to print documents with confidential information... Granted, that's a bug, but it doesn't fit my reading of serious [0], it's at most important, hereby downgrading. Cheers, OdyX [0] http://www.debian.org/Bugs/Developer.en.html#severities -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711837: RFA: mapnik -- C++/Python toolkit for developing GIS applications
On Mon, Jun 10, 2013 at 5:48 PM, David Paleino da...@debian.org wrote: On Mon, 10 Jun 2013 17:28:10 +0800, YunQiang Su wrote: This packages seems in a quite good situation. Is it? There is a new upstream version, and it needs to be re-transitioned to libmapnik (from the current libmapnik2). Also, there's a SONAME bump involved. I am interested. let me have a try first. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657215: [PATCH videoproto] Xvproto: fix xvEncodingInfo to match actual wire protocol
On Mon, Jun 10, 2013 at 11:41:00 +0200, Daniel Martin wrote: On 9 June 2013 19:00, Julien Cristau jcris...@debian.org wrote: The padding is *before* the rate field, so the rate is placed on a 32bit boundary. This change adds explicit padding between height and rate, and removes extraneous padding after the rate field, which the server never sent and xlib never read. This changes sizeof(xvEncodingInfo). Hopefully that's not a big deal as clients only see the Xlib structure XvEncodingInfo. (Hopefully, I'm right with that): I think that's an ABI change and a bit more difficult. Think about an X server, which is compiled against a xvproto version without that change and the lib compiled against xvproto with that change. In that case the lib would start to read the encoding info, where the X server just sended those extraneous pad bytes. No. As said in the commit message, the server never sent the extraneous pad bytes, so this patch doesn't change either the server or libXv behaviour. Both it and libXv use sz_xvEncodingInfo, which is ok. I just saw that the reply structure itself (xvQueryEncodingsReply) has such extraneous padding too: ... CARD32 length B32; CARD16 num_encodings B16; CARD32 padl3 B32; ... And even without this padding sz_xvQueryEncodingsReply=32 is wrong, as the fields sum up to 34 and with that padding we're at 36. Looks like padl3 should really be CARD16... Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711774: [exact-image] Bug#711774: exactimage: dcraw vs libraw ?
Hi, On Jun 10, 2013, at 9:01 , Mathieu Malaterre wrote: On Sun, Jun 9, 2013 at 9:08 PM, Sven Eckelmann s...@narfation.org wrote: Just a small remark at the beginning: I didn't meant dcraw upstream with dcraw guys but the Debian maintainers for dcraw. And I really think it is a good question because the package is dead since 3 years and missing some updates from upstream. (Ok, the embedded copy of dcraw in exactimage seems to be older) On Sunday 09 June 2013 19:37:03 Rene Rebe wrote: I think dcraw did all the original research and he does not want to make it a library because he believes an executable to call is the unix way and a library he could boy change so flexible. This is why I embedded the not too big code to make it a simple built in library inside exact image. This is correct, but is not really about the problem here. Just to give more insight in what Mathieu Malaterre said: Embedded copies of code are bad when used in Distributions because (just some examples): * they increase the binary size when there would be shared object that could be used instead * they increase memory usage because different programs cannot share the loaded library * they are hard to maintain Ok, the first two points are easy to understand but the last one might be quite vague. So here an explanation with two different scenarios (actually it is the same example but with different impacts): dcraw gets a new version (lets call it 9.18 for obvious reasons) with X-Trans and EOS C500 support. Now all programs using an embedded copy have to be updated in Debian to bring these versions on par with the upstream one and fix outstanding bugs/request for EOS C500/X-Trans. This is not really trivial because the programs have to be identified first and then the maintainer has to be waken up. This is a lot of work and time spend on a task that is completely unnecessary. Therefore, it is better to use the library version when available. And yes, I am fully aware that interface changes are problems which can be a negative effect when switching to external libraries. Now to the part with a little more impact. Lets assume that dcraw has a bug which can be exploited quite easily (send a prepared image which causes some buffer overflows and so on). Now it is extreme important to find all versions of the embedded copy because otherwise it is a security risk. You don't really want to provide an web service doing raw image conversions when there might be a big security hole because the security bug was fixed in the original program/library but not in the embedded copy. So back to the main questions. Do you see a possible way to switch from your dcraw version to libraw and make more of the embedded copies optional? I know, the embedded copies from libjpeg for jpeg rotation are for example really hard because libjpeg doesn't export the necessary stuff. But it seemed to have caused some headaches for the previous maintainers of this package because no one updated the embedded copy of jpegint/transupp and it just crashed when used together with never versions of libjpeg like libjpeg8. And the current one in exactimage upstream still does. Very well summarized, Sven ! Security was mostly my main objection, since exactimage offer perl, python and php5 bindings it is quite likely this will be used on webserver, therefore security risk is not anymore just a theoretical issue. Well, the dcraw author is the authority when it come to RAN reverse engineering. I would rather use his, than some other random library. That it is not a real library, and the ongoing compatibility breakage of libpng and libjpeg is very unfortunate, but honestly not my construction site. After all my decade of excessive open source work and contribution I'm left vastly disappointment by all this movements, incompatibly, breakage and flamewars. In the end all the big companies like Google, Facebook, IBM, Oracle and others just make the big money of all our work there. I'm afraid I can not longer donate my short life to their profit and thus mostly do other stuff now, like for Mac and even Windows. I adapt ExactImage to new library versions as time allows, but unfortunately the random breakage and incompatibility mess does not motivate me too much to look into things like that. Patches welcome. René -- http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
Bug#711717: pu: package slbackup-php/0.4.3-3
Hi Adam, Petter, On So 09 Jun 2013 23:10:53 CEST Adam D. Barratt wrote: However, can the update of slbackup-php be uploaded to s-p-u? What is the preferred version? 0.4.3-3 or 0.4.3-2+deb7u1? In general, the latter is preferable as it clearly indicates that the upload was made to a suite other than unstable / experimental; -3 would also work so long as that version has never been used before. Please feel free to upload for inclusion in 7.2. uploaded slbackup-php to stable-p-u as 0.4.3-2+deb7u1. Cheers, 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 pgpyi_T5wiZtp.pgp Description: Digitale PGP-Unterschrift
Bug#692465: Interested in maintenance of aiccu
Hi Jeroen, On So 09 Jun 2013 02:24:02 CEST Jeroen Massar wrote: On 2013-06-08 16:16, Mike Gabriel wrote: Hi Jeroen, as a regular user of aiccu (and a DD) I will be happy to take over maintenance of the aiccu package. I will also be happy to place you guys from upstream into the Uploaders: field and train people from Sixxs in Debian packaging (and the distro workflow) if there is the need. There would be no need for that, as we know how Debian packaging works, noting that we have been 'playing' with Debian since 1.2 era (heck, I have a p200 which was upgraded from there to the current unstable ;) and that the original Debian packaging was performed by us, and then extended to support the debconf support by Gary Coady which we integrated into that packaging and then somewhere along the way it finally ended up in Debian. Ack. Good to hear. Please also see the note in the very bug referenced by your email: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692465#10 Yes, noted. We still intend to do that and given some free time will come around to doing that including a full push of that work out to https://github.com/SixXS/aiccu but this all in due time, real life and work has to come first. Here I'd like to step in. I highly recommend sticking to the git-buildpackage workflow here. This means having two independent Git repositories. The first is the upstream Git project of aiccu (e.g. on Github). Upstream releases are done in this repos and tagged properly. The second repos is the Debian packaging repos. It imports your upstream releases (via uscan --force-download --rename and a proper watch file pointing to the upstream tags of aiccu on Github). The packaging achievements can in regular intervals be adapted on the upstream repos (if you like to ship the /debian folder upstream). Mixing upstream development and debian packaging turns aiccu into some sort of a native package which I do disrecommend, as it mixes two workflows (upstream, downstream) that should IMHO stay separate. Greets, Jeroen 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 pgpKXJUJyjD_4.pgp Description: Digitale PGP-Unterschrift
Bug#709687: transition: ptlib, opal
On 2013-06-07 18:53, Adam D. Barratt wrote: On Fri, 2013-06-07 at 18:48 +0100, Adam D. Barratt wrote: The packages haven't transitioned yet because the last binNMU for h323plus only finished building a few hours ago and the old libraries haven't been decrufted yet. It's in hand... :) And then I noticed that openam hasn't been rebuilt yet because it doesn't actually build-depend on ptlib but gets its runtime dependency transitively via h323plus; I've just scheduled binNMUs. A quick update: All of the binNMUs in unstable were successful, and the old packages were decrufted. The new packages migrated this morning, but the transition isn't quite over yet as a couple of the applications still need to migrate. t38modem just isn't quite old enough, which is easily resolved, but ekiga is affected by #698627 - please could one of the maintainers either verify that the bug does not affect the 4.0 packages and add an appropriate fixed version, or fix the bug in that series? Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711584: gnome-control-center: *** Error in `gnome-control-center': free(): invalid pointer: 0x00007f6e3619c000 ***
Hi, On 08/06/13 07:28, Ludovic Lebègue wrote: Package: gnome-control-center Version: 1:3.4.3.1-3 Severity: normal Unable to launch gnome-control-center Does this happen all the time? How are you starting gnome-control-center? We would need a valgrind log and a gdb backtrace to better debug this, with libdrm-nouveau1a-dbg xserver-xorg-video-nouveau-dbg libclutter-1.0-dbg libcogl9-dbg libc6-dbg libglib2.0-0-dbg installed. But from the trace below this looks like a bug in nouveau. @debian-x, does this look familiar? Cheers, Emilio Stack trace : === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x7aac6)[0x7f6e5c52bac6] /lib/x86_64-linux-gnu/libc.so.6(+0x7b843)[0x7f6e5c52c843] /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0x1a370e)[0x7f6e383b470e] /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0x211672)[0x7f6e38422672] /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0xd3617)[0x7f6e382e4617] /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0x12034a)[0x7f6e3833134a] /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0x1205c1)[0x7f6e383315c1] /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0xe6106)[0x7f6e382f7106] /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0xe66b3)[0x7f6e382f76b3] /usr/lib/x86_64-linux-gnu/libcogl.so.9(+0x18b2c)[0x7f6e39f4db2c] /usr/lib/x86_64-linux-gnu/libcogl.so.9(+0x6361a)[0x7f6e39f9861a] /usr/lib/x86_64-linux-gnu/libcogl.so.9(cogl_context_new 0x10b)[0x7f6e39f562bb] /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0(+0x65333)[0x7f6e3a42f333] /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0(+0x7c2b3)[0x7f6e3a4462b3] /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0(+0x87cda)[0x7f6e3a451cda] /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0(+0x87f0b)[0x7f6e3a451f0b] /lib/x86_64-linux- gnu/libglib-2.0.so.0(g_option_context_parse+0x3b7)[0x7f6e5ce09757] /usr/lib/x86_64-linux- gnu/libclutter-1.0.so.0(clutter_init+0xd2)[0x7f6e3a4521d2] /usr/lib/x86_64-linux-gnu/libcheese- gtk.so.21(cheese_gtk_init+0x24)[0x7f6e3a913e34] /usr/lib/control-center-1/panels/libuser- accounts.so(g_io_module_load+0x33)[0x7f6e3ab372e3] /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(+0x5c4f6)[0x7f6e5d35c4f6] /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0(g_type_module_use+0x81)[0x7f6e5d0e45a1] /usr/lib/x86_64-linux- gnu/libgio-2.0.so.0(g_io_modules_load_all_in_directory_with_scope +0x84)[0x7f6e5d35c8d4] gnome-control-center[0x4098da] /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0(g_type_create_instance+0x15f)[0x7f6e5d0e193f] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x15758)[0x7f6e5d0c6758] /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0(g_object_newv+0x781)[0x7f6e5d0c8211] /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0(g_object_new+0xec)[0x7f6e5d0c885c] gnome-control-center(main+0x72)[0x407c62] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f6e5c4d2a55] gnome-control-center[0x407d11] === Memory map: 0040-00412000 r-xp 08:07 673312 /usr/bin/gnome-control-center 00611000-00612000 r--p 00011000 08:07 673312 /usr/bin/gnome-control-center 00612000-00613000 rw-p 00012000 08:07 673312 /usr/bin/gnome-control-center 02489000-02ef9000 rw-p 00:00 0 [heap] 7f6e36108000-7f6e36188000 rw-s 126b9f000 00:05 9973 /dev/dri/card0 7f6e36188000-7f6e362a rw-p 00:00 0 7f6e362a-7f6e362a1000 ---p 00:00 0 7f6e362a1000-7f6e36aa9000 rw-p 00:00 0 [stack:10164] 7f6e36aa9000-7f6e37ef r-xp 08:07 1089975 /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1 7f6e37ef-7f6e37ef1000 ---p 01447000 08:07 1089975 /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1 7f6e37ef1000-7f6e37ff5000 r--p 01447000 08:07 1089975 /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1 7f6e37ff5000-7f6e37ffc000 rw-p 0154b000 08:07 1089975 /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1 7f6e37ffc000-7f6e3800a000 rw-p 00:00 0 7f6e3800a000-7f6e3801 r-xp 08:07 1089971 /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0 7f6e3801-7f6e3820f000 ---p 6000 08:07 1089971 /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0 7f6e3820f000-7f6e3821 r--p 5000 08:07 1089971 /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0 7f6e3821-7f6e38211000 rw-p 6000 08:07 1089971 /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0 7f6e38211000-7f6e38811000 r-xp 08:07 1173972 /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 7f6e38811000-7f6e38a1 ---p 0060 08:07 1173972 /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 7f6e38a1-7f6e38a3b000 rw-p 005ff000 08:07 1173972 /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 7f6e38a3b000-7f6e38c1b000 rw-p 00:00 0 7f6e38c1b000-7f6e38c2 r-xp 08:07 1589426 /usr/lib/x86_64-linux-gnu/libxcb-util.so.0.0.0 7f6e38c2-7f6e38e2 ---p 5000 08:07 1589426 /usr/lib/x86_64-linux-gnu/libxcb-util.so.0.0.0 7f6e38e2-7f6e38e21000 rw-p 5000 08:07 1589426 /usr/lib/x86_64-linux-gnu/libxcb-util.so.0.0.0 7f6e38e21000-7f6e38e29000 r-xp 08:07 1094096
Bug#711070: python-otr: please port to libotr5-dev
FYI: package is not used anymore and has been superseded. -- Kjell mail/xmpp fn...@pentabarf.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681248: [Pkg-pdns-maintainers] Bug#681248: Here too, powerdns fails after upgrade to wheezy...
Hi marc, On 05/17/2013 04:29 PM, Marc Haber wrote: - placing a nonworking bind backend configuration file in the include directory. Please elaborate about the nonworking part. I did another upgrade yesterday, now with some more attention: Situation before the upgrade: - I have launch=gmysql in /etc/powerdns/pdns.conf - I have gmysql-*= options in /etc/powerdns/pdns.d/pdns.local I believe this is how the installation was written by default in powerdns in earlier version(s). Now, with the simplebind addition, which contains launch=bind pdns[22264]: Fatal error: Trying to set unexisting parameter 'gmysql-dbname' launch=bind overrides the any other launch= (be it in pdns.conf or pdns.local, if it were there), which makes my mysql backend not work after upgrade and leaves pdns guardian in an infinite retry-loop until I remove the simplebind include. Correct syntax: launch=gmysql,bind Tom -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711540: iproute2 FTBFS on sparc
Hello again Michael! Just now trying to catch up with work that piled up during last week. On Mon, Jun 10, 2013 at 12:02:34PM +0400, Michael Tokarev wrote: [...] It seems the initial bug report mail hasn't reached me... :/ Well, I just submitted a bugreport. Before, I also wrote to the address listed in Maintainer: field, -- I sent almost the same thing as in the bugreport, but were just asking if your guys need any help or not and what's up with that issue. After some days without reply I filed the bugreport. Seems I also lost the initial mail from you. :/ Feel free to resend if there is any open issue you still want to discuss. Help is very welcome! There are RFH out and atleast one bug tagged help. Help with any open bug report is welcome ofcourse! [...] I didn't know there's an upstream commit addressing this. I don't even know where iproute2 is maintained upstream, -- probaly it'd be better if I looked. I just tried to fix the immediate issue (which is rather trivial), basically leaving the full expertise to someone who is more familiar with the package. Stephen Hemminger is the upstream maintainer for iproute2. He has a git repository at git.kernel.org and the primary mailing list (except for sending patches directly to shemminger) is net...@vger.kernel.org. The pkg-iproute repo should be available via debcheckout. [... snip explanation of netcf build problems in sid...] My understanding is that a package isn't available as build-dep on sid before it is built itself on all necessary arches. Thanks for the explanation. As I understand it, the problem is not the need for iproute2 to transition to testing then but a(ny) version not being able to the buildds. [...] How about me cancelling the delayed upload instead, until there's some time to do that left? ;) [...] I've just uploaded -3 Fwiw, another dark cloud just appeared on the sky: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711782 -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711849: cups-browsed depends on avahi-daemon, unnecessarily
Package: cups-browsed Version: 1.0.34-3 Severity: minor cups-browsed works nicely without avahi when instructed to BrowsePoll a specific server. The avahi-daemon is pulled in unnecessaily and needs to be disabled in our setup. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.9.5 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cups-browsed depends on: pn avahi-daemon none ii libavahi-client3 0.6.31-2 ii libavahi-common3 0.6.31-2 ii libavahi-glib10.6.31-2 ii libc6 2.17-5 ii libcups2 1.6.2-8 ii libglib2.0-0 2.36.1-2build1 cups-browsed recommends no packages. cups-browsed suggests no packages. -- Configuration Files: /etc/cups/cups-browsed.conf changed: BrowseRemoteProtocols dnssd BrowsePoll 134.245.xx.xx -- 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#711848: cups-client: lp and lpr print the document on a wrong printer
On 2013-06-10 11:50:52 +0200, Didier 'OdyX' Raboud wrote: But when I print a document with lpr file.pdf, I get nothing on this printer. Then I tried: lp file.pdf, and I get nothing either on this printer, but the following line was output in the terminal: When trying here with either lpr or lp, I get the file printed on the correct new-default-printer (which is obviously not the same printer as the system's default printer) as defined above, so I can't reproduce your problem here. Well, this may be server dependent. I suspect a bug related to the authentication mechanism. When I do lpq, authentication is not required, so that its output is OK. However some printers need authentication (the user's password). Perhaps lp and lpr ignore the default printer when it requires authentication, or something like that? The printer to which the files had been sent doesn't require a password. Note that the -P lpr option works as expected (and the password must be typed). What are the access rights and contents of /etc/cups/lpoptions and .cups/lpoptions ? ypig:~ cat /etc/cups/lpoptions cat: /etc/cups/lpoptions: No such file or directory ypig:~ cat .cups/lpoptions Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi Default lipucb-mono-1 CUPS 1.5.x didn't have such a problem. This is a big security problem when one wants to print documents with confidential information... Granted, that's a bug, but it doesn't fit my reading of serious [0], it's at most important, hereby downgrading. [...] [0] http://www.debian.org/Bugs/Developer.en.html#severities I disagree. I see [0] as giving a non-exhaustive list of grave/critical problems. For instance, a bug that would make a mail server an open relay by default should also be seen as a grave/critical bug, even though such a problem isn't listed in [0]. It should include problems like private data disclosure. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705390: gnome-calculator: gnome-applications.menu (from /etc/sdg/menus) looking for gnome-calculator.desktop
reassign 705390 gnome-menus forcemerge 705390 711605 thanks On 14/04/13 09:38, Alex Vanderpol wrote: Package: gnome-calculator Version: 3.8.0-1 Severity: important Dear Maintainer, After much frustration I finally discovered why GNOME's Calculator is not showing up in the GNOME applications menu. The applications menu file is looking for a differently named desktop file than is currently being shipped. The package currently ships gcalctool.desktop (the old name from the old gcalctool package, before it was renamed). The menu file is looking for gnome- calculator.desktop (named such after the new package providing the GNOME Calculator program). Could you please correct this? gnome-menus is wrong here, will fix this shortly. Thanks for your report. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705007: E763: Word characters differ between spell files
On Mon, Apr 08, 2013 at 07:08:01PM +0200, Uwe Storbeck wrote: [...] spell files. They are not compatible with spell files which vim automatically downloads from ftp.vim.org: [...] When I manually download the current English spell files from http://ftp.vim.org/pub/vim/runtime/spell/ and copy them to /home/uwe/.vim/spell spell checking works as expected without any error messages. An interesting part is my Vim reported errors for English UTF-8 .spl even after downloading a new version from ftp.vim.org to ~/.vim/spell. What actually caused an error was an old Polish UTF-8 dictionary. After downloading it from ftp.vim.org the problem stopped and I still use packaged English spell files. -- Marcin Szewczyk http://wodny.org mailto:marcin.szewc...@wodny.borg - remove b / usuń b xmpp:wo...@ubuntu.pl xmpp:wo...@jabster.pl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711848: cups-client: lp and lpr print the document on a wrong printer
Hi again Vincent, Le lundi, 10 juin 2013 12.56:33, Vincent Lefevre a écrit : Well, this may be server dependent. I suspect a bug related to the authentication mechanism. When I do lpq, authentication is not required, so that its output is OK. However some printers need authentication (the user's password). Perhaps lp and lpr ignore the default printer when it requires authentication, or something like that? The printer to which the files had been sent doesn't require a password. Note that the -P lpr option works as expected (and the password must be typed). Thanks for the followup. What are the access rights and contents of /etc/cups/lpoptions and .cups/lpoptions ? ypig:~ cat /etc/cups/lpoptions cat: /etc/cups/lpoptions: No such file or directory ypig:~ cat .cups/lpoptions Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi Default lipucb-mono-1 Can you provide the access rights of .cups/lpoptions? $ ls -l ~/.cups/lpoptions CUPS 1.5.x didn't have such a problem. This is a big security problem when one wants to print documents with confidential information... Granted, that's a bug, but it doesn't fit my reading of serious [0], it's at most important, hereby downgrading. I disagree. I see [0] as giving a non-exhaustive list of grave/critical problems. For instance, a bug that would make a mail server an open relay by default should also be seen as a grave/critical bug, even though such a problem isn't listed in [0]. It should include problems like private data disclosure. It's fine for you to disagree, but the list [0] is considered as authoritative on bugs severities. If you think this list should be changed, please start a discussion on a proper forum; probably a bug on debian-policy as it's 1.1 chapter defines what bug corresponds to a serious severity, which is completed by the Release Team's RC policy [1]. Under the current rules, this bug doesn't fit the defintion of serious in my reading. (Please also take a look at the Developers' Reference, §5.8.3, alinea 3 [2]). Cheers, OdyX [0] http://www.debian.org/Bugs/Developer.en.html#severities [1] http://release.debian.org/jessie/rc_policy.txt [2] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug- housekeeping -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711247: freebsd-utils: please ship pflogd
Hi Martin, On 05/06/13 21:59, Martin Zobel-Helas wrote: With DSA hat on: Would be nice if freebsd-utils including the pflogd binary could be uploaded to backports. Even with those (fairly generic) patches applied, pflogd still doesn't compile. We would additionally need a pcap-int.h (internals) header which libpcap-dev does not provide currently. There is probably a reason why it doesn't; anything using the header might pick up a tight dependency on a particular source version of libpcap. That also means it may not be so trivial to backport. But otherwise, with a couple of minor changes I got pflogd built on a Wheezy system. And it seems to be functioning. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660932: Double quote in (some) wget's international output for downloaded filename
Package: wget Version: 1.14-2 Followup-For: Bug #660932 Dear Maintainer, what happens is that the translation project introduces extra quotes where the original has none. Since Wget handles/adds quotes in it's own style, quotation gets out of sync. I just wrote to translator-team-de NOT to introduce extra quotes for Wget. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698284: usb-modeswitch-data: ttyUSB* rule should have SYMLINK+= not SYMLINK=
Hi Josua, I have now uploaded your latest usb-modeswitch-data source package to Debian and stumbled upon this bug while housekeeping the remnant bugs lying around. :) Apparently you forgot to include this change in the new rules file (also in the gen_rules.tcl) apparently; was that intentional? Keep us posted, cheers, OdyX Le mercredi, 16 janvier 2013 20.39:30, Josua Dietze a écrit : Am 16.01.2013 10:57, schrieb Didier 'OdyX' Raboud: Le mercredi, 16 janvier 2013 09.53:26, John Hedges a écrit : Symlinks created by local rules for ttyUSB devices are lost because of the following rule in /lib/udev/rules.d/40-usb_modeswitch.rules KERNEL==ttyUSB*, ATTRS{bNumConfigurations}==*, PROGRAM=usb_modeswitch --symlink-name %p %s{idVendor} %s{idProduct} %E{PRODUCT}, SYMLINK=%c Chould it be changed to SYMLINK+=%c ? As I don't have a definite opinion on that, let's see what upstream thinks. Josh: what's your opinion ? Yes, this definitely should be changed. There is no disadvantage. I will do so in the next release, but that is not scheduled yet - so you might want to correct this prior to my update. OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689571: CVE-2012-4463: Improper sanitization of MC_EXT_SELECTED variable when viewing multiple files
Package: mc Dear maintainer, Recently you fixed one or more security problems and as a result you closed this bug. These problems were not serious enough for a Debian Security Advisory, so they are now on my radar for fixing in the following suites through point releases: squeeze (6.0.8) - use target oldstable Please prepare a minimal-changes upload targetting each of these suites, and submit a debdiff to the Release Team [0] for consideration. They will offer additional guidance or instruct you to upload your package. I will happily assist you at any stage if the patch is straightforward and you need help. Please keep me in CC at all times so I can track [1] the progress of this request. For details of this process and the rationale, please see the original announcement [2] and my blog post [3]. 0: debian-rele...@lists.debian.org 1: http://prsc.debian.net/tracker/689571/ 2: 201101232332.11736.th...@debian.org 3: http://deb.li/prsc Thanks, with his security hat on: -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711851: qcontrol: disable watchdog on QNAP devices does not work
Package: qcontrol Version: 0.4.2-7+wheezy1 Severity: important The qcontrol init script in /usr/share/initramfs-tools/scripts/init-bottom/qcontrol contains a command line to be executed on QNAP deveices in order to disable their builtin watchdog and prevent them from rebooting after 5 minutes of runtime. This line is: /sbin/qcontrol --direct watchdog off || true Executing this line interactively returns a Command not found error message: root@debian:~# /usr/sbin/qcontrol --direct watchdog off Command not found root@debian:~# due to an apparently inappropriate parameter '--direct', which when left out does not report an error: root@debian:~# /usr/sbin/qcontrol watchdog off root@debian:~# The qcontrol call is used in the initrd to prevent the device from rebooting periodically. With the failed call these reboots happen every five minutes, which is especially tooo short, if the file system check is run. In that case the reboot happens repeatedlÃy during the fs check, which has a very high risk of corrupting data. Since the --direct option is not mentioned in the qcontrol manpage, I conclude that it is an invalid option and should not be used. Hence I'd suggest this fix to be applied to the qcontrol init script. I did not yet try this fix, since my qnap device is geographically distand from my personal location and I'd have some trouble getting it operational again, if a reboot fails. Meanwhile I am using the workaround echo -n g /dev/ttyS1 to disable the watchdog. --- /usr/share/initramfs-tools/scripts/init-bottom/qcontrol.orig 2013-06-10 13:45:38.0 +0200 +++ /usr/share/initramfs-tools/scripts/init-bottom/qcontrol 2013-06-10 13:45:58.0 +0200 @@ -30,6 +30,6 @@ exit 0 fi -/sbin/qcontrol --direct watchdog off || true +/sbin/qcontrol watchdog off || true exit 0 -- System Information: Debian Release: 6.0.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: armel (armv5tel) Kernel: Linux 2.6.32-5-kirkwood Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages qcontrol depends on: ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii liblua5.1-0 5.1.4-5Simple, extensible, embeddable pro ii udev 164-3 /dev/ and hotplug management daemo qcontrol recommends no packages. qcontrol 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#711850: java-wrappers: jvm-list.sh fails to find jvm from /etc/alternatives
Package: java-wrappers Version: 0.1.25 Severity: important Tags: patch I have just installed freemind. I have Oracle Java installed under /usr/local/app/java-oracle/jdk1.7.0 and correctly mapped into /etc/alternatives. I'm aware of issues surrounding Oracle Java but it's required for another application I use. I also have OpenJDK versions 6 and 7 installed but unused. Running freemind triggers a calls to java-wrappers, which in turn uses jvm-list to detect an appropriate jvm. Unfortunately this fails because my jvm is not installed under /usr/lib/jvm so java-wrappers is led to believe there is no valid jvm installed, and consequently freemind will not start. Investigating further it appears that there is a line within /usr/lib/java- wrappers/jvm-list.sh that assumes a jvm linked from /etc/alternatives/java is going to be somewhere under /usr/lib/jvm. The attached patch removes this dependency assumption. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) 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 java-wrappers depends on: ii unzip 6.0-8 java-wrappers recommends no packages. java-wrappers suggests no packages. -- no debconf information --- jvm-list.sh.2013-06-10 2011-09-14 17:27:08.0 +0100 +++ jvm-list.sh 2013-06-10 11:43:05.205951794 +0100 @@ -56,7 +56,7 @@ __jvm_java2=$__jvm_java5 $__jvm_gcj2 # current java alternatives -__jvm_alt=$(readlink /etc/alternatives/java|sed -n 's/\(\/usr\/lib\/jvm\/[^\/]*\)\/.*/\1/p') +__jvm_alt=$(readlink /etc/alternatives/java|sed -n 's!\(.*\)/bin/[^/]*$!\1!p') # All JVMs __jvm_all=$__jvm_default /usr/lib/jvm/*
Bug#711848: cups-client: lp and lpr print the document on a wrong printer
Hi, On 2013-06-10 13:27:47 +0200, Didier 'OdyX' Raboud wrote: Can you provide the access rights of .cups/lpoptions? $ ls -l ~/.cups/lpoptions ypig:~ ls -l ~/.cups/lpoptions -rw-r--r-- 1 vlefevre vlefevre 74 2013-02-01 16:29:37 /home/vlefevre/.cups/lpoptions I've also done a strace diff between: (1) strace -o str1.out -f lpr lineskip.pdf (2) strace -o str2.out -f lpr -P lip-multi-3 lineskip.pdf in this order. I can notice in particular: [...] open(/usr/lib/locale/locale-archive, O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=117407552, ...}) = 0 mmap(NULL, 117407552, PROT_READ, MAP_PRIVATE, 3, 0) = hex close(3) = 0 futex(hex, FUTEX_WAKE_PRIVATE, 2147483647) = 0 geteuid() = 1000 getuid() = 1000 getegid() = 1000 getgid() = 1000 -access(lineskip.pdf, R_OK) = 0 -open(/home/vlefevre/.cups/lpoptions, O_RDONLY) = 3 -fcntl(3, F_GETFD) = 0 -fcntl(3, F_SETFD, FD_CLOEXEC) = 0 -read(3, Dest lip-multi-3 ColorModel=Gray..., 4096) = 74 -close(3) = 0 open(/home/vlefevre/.cups/client.conf, O_RDONLY) = -1 ENOENT (No such file or directory) open(/etc/cups/client.conf, O_RDONLY) = 3 fcntl(3, F_GETFD) = 0 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 read(3, #\n#\n# Sample client configurat..., 4096) = 2224 read(3, , 4096) = 0 close(3) = 0 open(/home/vlefevre/.cups/client.conf, O_RDONLY) = -1 ENOENT (No such file or directory) open(/etc/cups/client.conf, O_RDONLY) = 3 fcntl(3, F_GETFD) = 0 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 read(3, #\n#\n# Sample client configurat..., 4096) = 2224 read(3, , 4096) = 0 close(3) = 0 rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, hex}, NULL, 8) = 0 access(/etc/gcrypt/fips_enabled, F_OK) = -1 ENOENT (No such file or directory) open(/proc/sys/crypto/fips_enabled, O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 [...] -getrusage(RUSAGE_SELF, {ru_utime={0, 4000}, ru_stime={0, 8000}, ...}) = 0 -times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1718347093 -getrusage(RUSAGE_SELF, {ru_utime={0, 4000}, ru_stime={0, 8000}, ...}) = 0 -times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1718347093 -open(/etc/cups/lpoptions, O_RDONLY) = -1 ENOENT (No such file or directory) -open(/home/vlefevre/.cups/lpoptions, O_RDONLY) = 5 -fcntl(5, F_GETFD) = 0 -fcntl(5, F_SETFD, FD_CLOEXEC) = 0 -read(5, Dest lip-multi-3 ColorModel=Gray..., 4096) = 74 +recvfrom(4, [...], 5, 0, NULL, NULL) = 5 +recvfrom(4, [...]..., 784, 0, NULL, NULL) = 784 +getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={0, 12000}, ...}) = 0 +times({tms_utime=0, tms_stime=1, tms_cutime=0, tms_cstime=0}) = 1718362144 +getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={0, 12000}, ...}) = 0 +times({tms_utime=0, tms_stime=1, tms_cutime=0, tms_cstime=0}) = 1718362144 +open(/dev/tty, O_RDONLY)= 5 +ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 +ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 +ioctl(5, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost -isig -icanon -echo ...}) = 0 +ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0 +fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 9), ...}) = 0 +mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = hex +write(1, Password for vlefevre on lip-pri..., 60) = 60 [...] I won't send you the strace as it contains the password and maybe other private information, but /home/vlefevre/.cups/lpoptions is read twice (successfully) in case (1) and none in case (2). In case (1), the file was sent to lip-multi-1 instead of lipucb-mono-1. In case (2), the file was sent to lip-multi-3 as expected. It's fine for you to disagree, but the list [0] is considered as authoritative on bugs severities. If you think this list should be changed, please start a discussion on a proper forum; probably a bug on debian-policy as it's 1.1 chapter defines what bug corresponds to a serious severity, which is completed by the Release Team's RC policy [1]. Under the current rules, this bug doesn't fit the defintion of serious in my reading. [1] also says: in the maintainer's opinion, makes the package unsuitable for release (these issues are serious severity) You could also consider that due to security concerns, the package is unsuitable for release. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Bug#711853: insserv: Design bug: rcN.d unstable and not maintainable
Package: insserv Version: 1.14.0-5 Severity: normal When update-rc.d calls insserv, the rcN.d directories are rebuilt without taking into consideration any adjustment that might have been set up locally. That seems to be done on the assumption that the dependencies coded in the LSB blocks are universally accurate. Now, LSBs are a great improvement over numeric priorities, but to hamper local system tuning, which is not necessarily related to LSBs, IMHO is an insult to the legendary versatility of SysV init. On the other hand, when .legacy-bootordering exists, update-rc.d does not use LSB blocks at all, and mindlessly links at priority 20. I understand that maintainers don't put default priority orders, which are difficult to maintain: That is exactly the reason why LSB INIT INFO blocks were devised. So, why not use them? A way to use that info and still respect existing priorities is coded in the attached script. Thanks to it, I was able to get the cleanest boot since I upgraded to wheezy. Unlike update-rc.d, fix-init does not take a scrip name to operate on. It assumes all links older than .legacy-bootordering are to be respected, and writes any action it deems required to a shell script. Please have a look at it. Regards Ale -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.41ale20 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages insserv depends on: ii libc6 2.13-38 insserv recommends no packages. Versions of packages insserv suggests: pn bootchart2 none -- debconf-show failed #! /usr/bin/perl # written by Alessandro Vesely in June 2013. This is free software. =head1 NAME fix-init - rebuild Finit?.d links according to LSB headers =head1 SYNOPSIS fix-init [-n|--dry-run [Ifile]] [-r|--renum [Istep]] [--root Iroot] [-v|--verbose [2|3|4]] fix-init -h|--help [1|2] =head1 OPTIONS =over =item help An optional value of I1 displays these options in addition to the synopsis. Use I2 for a man-like page. =item root Default to F/. Use a different directory for testing. =item dry-run Bfix-init writes shell commands on a temporary file, then executes it. This option prevents that execution. It is implied if Iroot is not writable. If an output Ifile is specified, it will be used instead of a temporary one, overwriting its previous content if any. =item renum Without this option, Bfix-init tries to respect the existing order of links. Otherwise, it renumbers them. The default Istep is 6, resulting in names like FS06xyz, FS12xyzzy, FS18foo, ... This option is implied if dependecy based boot sequencing is in effect. =item verbose Minimal verbosity (I-v) is recommended, otherwise Bfix-init is almost silent. At intermediate verbosity, unsatisfied required dependencies (I-v 2), optional (should) and satisfied ones (I-v 3) are displayed, as well as some skipped files and strange facts. Top verbosity (I-v 4) dumps some internal structures, such as the initial and resulting order for each level. =back =cut use strict; use warnings; use feature switch; use File::Find; use File::Temp 'tempfile'; use Getopt::Long; use List::Util qw(max min); use Data::Dumper; use Pod::Usage; use constant {BROKEN_LINK = 1, PLAIN_FILE = 2, STRANGE_LINK = 3, NEW_LINK = 4}; my ($dryrun, $renum, $help, $root, $verbose); Getopt::Long::Configure('no_ignore_case'); if (!GetOptions('verbose|v:i' = \$verbose, 'dry-run|n:s' = \$dryrun, 'renum|r:i' = \$renum, 'root=s' = \$root, 'help|h:i'= \$help)) { pod2usage(); exit 1; } if (defined($help)) { pod2usage(-verbose = $help); } if (defined($verbose)) { $verbose = 1 unless ($verbose); # -v same as -v 1 } else {$verbose = 0;} $root = '/' unless defined($root); $root .= '/' unless (substr($root, -1) eq '/'); my $initdir = $root . 'etc/init.d'; my $init_link = ../init.d/; my $fix_flag = $initdir .'/.legacy-bootordering'; my $overridepath = /usr/share/insserv/overrides; my $hostoverridepath = /etc/insserv/overrides; $Data::Dumper::Terse = 1; my @levels = map $_, ('S', 0.. 6); my %rc_d = map {$_ = $root .etc/rc$_.d} @levels; my $rc_d_length = length($rc_d{0}); # different from length($initdir) do { my @invalid = grep ! -d, values %rc_d; push(@invalid, $initdir) unless -d $initdir; pod2usage(-msg = 'Invalid dir: '. join(', ', @invalid)) if (@invalid); }; my $timestamp = (stat($fix_flag))[9]; if (!defined($timestamp)) { $timestamp = 0; if (!defined($renum)) { $renum = 0; print Dependecy based boot sequencing detected, --renum implied\n if ($verbose); } } my $defaultstep = 6; $renum = $defaultstep if (defined($renum) $renum == 0); # cannot do, because order becomes negative or larger than 99 my
Bug#711852: maven.pm: Don't install documentation jar into maven-repo by default
Package: maven-debian-helper Severity: wishlist Tags: patch Standard place where generated javadoc API documentation is installed on Debian system is /usr/share/doc/package-name/api/. Maven dh build installs it also a JAR in maven-repo. Having this duplicate file isn't necessary, so please consider not installing the javadoc JAR by default. Required change is implemented in attached patch. Adding 'export MH_INSTALL_DOC=1' into d/rules overrides the setting. Regards, Jakub From 81c9f308c6a21979f8e3d7feb2a3af232ce825b7 Mon Sep 17 00:00:00 2001 From: Jakub Adam jakub.a...@ktknet.cz Date: Mon, 10 Jun 2013 13:35:10 +0200 Subject: [PATCH] maven.pm: Don't install documentation jar into maven-repo by default Add 'export MH_INSTALL_DOC=1' into d/rules to override the setting. --- share/perl/maven.pm |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/share/perl/maven.pm b/share/perl/maven.pm index 00520df..ca94eff 100644 --- a/share/perl/maven.pm +++ b/share/perl/maven.pm @@ -97,9 +97,11 @@ sub install { $this-doit_in_builddir(mh_resolve_dependencies, --non-interactive, --offline, -p$this-{package}, @resolvedep_args); if ($this-{doc_package}) { - $this-doit_in_builddir(@{$this-{maven_cmd}}, - -Ddebian.package=$this-{doc_package}, - org.debian.maven:debian-maven-plugin:$maven_debian_version:install-doc); + if ($ENV{MH_INSTALL_DOC} == 1) { + $this-doit_in_builddir(@{$this-{maven_cmd}}, +-Ddebian.package=$this-{doc_package}, +org.debian.maven:debian-maven-plugin:$maven_debian_version:install-doc); + } doit(cp,debian/$this-{package}.substvars, debian/$this-{doc_package}.substvars); # clean up generated docs -- 1.7.10.4
Bug#711848: cups-client: lp and lpr print the document on a wrong printer
Hi again, Le lundi, 10 juin 2013 13.27:47, Didier 'OdyX' Raboud a écrit : Under the current rules, this bug doesn't fit the defintion of serious in my reading. As you brought this bug to debian-devel@ [0], let me explain in little more details (which I thought were obvious) why I think this bug is neither a security or a serious problem: * it doesn't happen for everyone (it works as expected here); * not all printed documents carry sensitive information and failing to print to the correct printer is not a security problem in all cases. I never wrote that I wouldn't try to get this bug (which I agree it is) fixed, but just corrected the inflated bug severity. That useless debate on severities just distracted me from working on the bug itself. OdyX [0] http://lists.debian.org/%3c20130610111552.ga17...@ypig.lip.ens-lyon.fr%3E -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711854: libunwind8-dev: ship upstream pkg-config files
Package: libunwind8-dev Version: 1.1-1 Severity: normal libunwind provides .pc files that other software use in their configure scripts to check if libunwind is available and get the necessary cflags and linker flags. Please install those files in the -dev package. Emilio -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.9-1-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 Versions of packages libunwind8-dev depends on: ii libunwind8 1.1-1 libunwind8-dev recommends no packages. libunwind8-dev 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#711826: no more unattended upgrades since Wheezy is out
2013/6/10 Harald Dunkel harald.dun...@aixigo.de: Since Wheezy is out the unattended-upgrades for Squeeze don't work anymore. The default configuration in /etc/apt/apt.conf.d/50unattended-upgrades says Unattended-Upgrade::Allowed-Origins { ${distro_id} stable; stable == wheezy now, thus you probably need to update your config with oldstable. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711855: RFS: aircrack-ng/1:1.1-6
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package aircrack-ng * Package name: aircrack-ng Version : 1:1.1-6 Upstream Author : Thomas d'Otreppe tdotre...@aircrack-ng.org * URL : http://www.aircrack-ng.org * License : GPL-2 Section : net It builds those binary packages: aircrack-ng - wireless WEP/WPA cracking utilities To access further information about this package, please visit the following URL: http://mentors.debian.net/package/aircrack-ng Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/aircrack-ng/aircrack-ng_1.1-6.dsc Changes since the last upload: * Remove unused Build-Depends on obsolete libnl-dev (Closes: #688158) * Add 019-fix-spelling-manpages.diff (Closes: #697346) * Add 020-ignore-negative-one.diff (Adds an option ignore-negative-one to workaround broken channel handling) * Add 021-fix-airodump-ng-oui-update.diff (Recently the oui file included some leading spaces that makes it not recognizable by airodump-ng. Fix it) * Update airodump-ng-oui.txt file Regards! signature.asc Description: OpenPGP digital signature
Bug#711316: [Pkg-phototools-devel] Bug#711316: Bug#711316: darktable: CVE-2013-2126: double free
David Bremner brem...@debian.org writes: I'm not sure yet that the vulnerability occurs in the version of libraw embedded in darktable. There is some relevant discussion on the darktable developers list http://article.gmane.org/gmane.comp.graphics.darktable.devel/2628 If nothing else, the proposed patch won't apply, because raw_alloc doesn't occur at all in src/External/LibRaw/src/libraw_cxx.cpp It seems like this might be the backported fix (suggesting there was indeed a problem to fix). https://github.com/LibRaw/LibRaw/commit/c14ae36d28e80139b2f31b5d9d7623db3b597a3a Darktable upstream just cherry picked that to their current release branches. I don't know yet if the same patch applies to the version in wheezy. d -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711694: src:stealth: uses deprecated find -perm +0123
On 06/08/2013 12:26 PM, Adam Borowski wrote: Package: src:stealth Version: 2.11.02-1 Severity: normal Tags: patch Hi! An incoming version of findutils drops the syntax of find -perm +0123, which contradicts POSIX and thus has been deprecated since 2005. The replacement is -perm /0123. The documentation of stealth uses this in a number of places, curiously, sometimes using +0123 sometimes /0123 -- it looks like someone already partially fixed it but did not finish. Thus, to fix this: sed -i 's:-perm +\([0-9]\):-perm /\1:g' `find -type f` Hi Adam, thank you for the detailed bug report and for the patch. I'll get this patched in Debian and forward on to Frank for inclusion upstream. Cheers, tony signature.asc Description: OpenPGP digital signature
Bug#689571: CVE-2012-4463: Improper sanitization of MC_EXT_SELECTED variable when viewing multiple files
Hi Jonathan, Thank you for useful information and reminder. Unfortunately I did not succeed in isolating and backporting the fix for this issue. Upstream re-factored the code and that made patch too difficult to apply to previous versions at least at my competence level... Best wishes, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711277: [buildd-tools-devel] Bug#711277: contents of 1.7.0 tarball has changed
On Wed, Jun 05, 2013 at 04:00:09PM -0700, Zach Carter wrote: There are at least two versions of the schroot_1.7.0.orig.tar.xz tarball that exist in the wild. One of them I can build, the other (current) one generates unit test failures when I attempt to build it under Fedora: 1) test: test_run_parts::test_run2 (E) uncaught exception of type N5boost10filesystem16filesystem_errorE - boost::filesystem::directory_iterator::construct: No such file or directory: test/testdata/run-parts.ex2 In particular, these two files are missing in the current tarball: Only in older.schroot-1.7.0/scripts: test-driver Only in older.schroot-1.7.0/test: run-parts.ex2 Could that be the cause of my unit test failures? As an additional datapoint, I believe I was getting the same unit test failures when I attempted to build the stable 1.6.5 version. Here is a link to the relevant Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=969885 I am attaching a recursive diff of the two tarballs. Any ideas of what to do are appreciated. Thanks for the diff. I'm not sure where the different tarballs have originated from--maybe one was a prerelease test tarball? The definitive release version is the signed distribution/schroot-1.7.0 tag from git://git.debian.org/git/buildd-tools/schroot-dist If you run git archive --prefix=schroot-1.7.0/ distribution/schroot-1.7.0 schroot-1.7.0.tar this will give you the release tarball. And this should match http://ftp.de.debian.org/debian/pool/main/s/schroot/schroot_1.7.0.orig.tar.xz exactly. (This is a separate repo from the main repo due to the size of the history) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711855: RFS: aircrack-ng/1:1.1-6
Hello, Why not work on aircrack-ng 1.2~beta1 instead ? -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Bug#711118: gnome-mplayer: messes up with dconf settings even when the user didn't change anything
On 2013-06-08 19:49:21, Francesco Poli wrote: On Wed, 5 Jun 2013 00:07:53 +0200 Sebastian Ramacher wrote: [...] As I've already said in the in the other bug report, please report this issue upstream yourself. I don't inted to spent any time on this. You can find upstream's bug tracker at https://code.google.com/p/gnome-mplayer/issues/list Unfortunately, it seems to require registration of an account, in order to report bugs. If I register an account on the upstream bug tracker of each Debian package I use, I will quickly go crazy... :-( I'm sure you can also reach upstream via mail. His address can be found in the copyright file. That's why I kindly asked you to forward my bug report upstream. Pretty please? Sorry, but no. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#711856: dovecot-imapd: Permission denied missing +w perm: /var/mail, we're not in group 8(mail)
Package: dovecot-imapd Version: 1:2.1.7-7 Severity: important Dear Maintainer, * What led up to the situation? I guess aptitude full-upgrade to wheezy * What exactly did you do (or not do) that was effective (or ineffective)? Move mail from spam to Inbox * What was the outcome of this action? Mail returned to spam * What outcome did you expect instead? mail be and stay in Inbox. Got this in /var/log/mail.info: Jun 10 14:38:35 s dovecot: imap(bernhard): Error: file_dotlock_create(/var/mail/bernhard) failed: Permission denied (euid=1000(bernhard) egid=1000(bernhard) missing +w perm: /var/mail, we're not in group 8(mail), dir owned by 0:8 mode=0775) (set mail_privileged_group=mail) Workaround: addgroup bernhard mail /etc/init.d/dovecot restart #not sure if required -- Package-specific info: dovecot configuration - # 2.1.7: /etc/dovecot/dovecot.conf # OS: Linux 3.2.0-4-686-pae i686 Debian 7.0 mail_location = mbox:~/mail:INBOX=/var/mail/%u namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox Sent Messages { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { driver = pam } protocols = imap pop3 ssl_cert = /etc/dovecot/dovecot.pem ssl_key = /etc/dovecot/private/dovecot.pem userdb { driver = passwd } -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dovecot-imapd depends on: ii dovecot-core 1:2.1.7-7 ii libc6 2.13-38 ii ucf 3.0025+nmu3 dovecot-imapd recommends no packages. dovecot-imapd suggests no packages. Versions of packages dovecot-imapd is related to: ii dovecot-core [dovecot-common] 1:2.1.7-7 pn dovecot-dbgnone pn dovecot-devnone pn dovecot-gssapi none ii dovecot-imapd 1:2.1.7-7 pn dovecot-ldap none pn dovecot-lmtpd none pn dovecot-managesieved none pn dovecot-mysql none pn dovecot-pgsql none ii dovecot-pop3d 1:2.1.7-7 pn dovecot-sieve none pn dovecot-sqlite 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#711788: [Debian-med-packaging] Bug#711788: Uninstallable on sid/jessie: depends on libminc2-1 -- now only in wheezy, we have libminc2-3 in sid/jessie
On June 9, 2013 09:29:44 PM Steve M. Robbins wrote: On June 9, 2013 02:18:42 PM Yaroslav Halchenko wrote: fix could be as simple as adjust build-depends Actually, looking more closely: the build-depends is fine (libminc-dev). All it needs is a binary rebuild. d'oh -- rright! ;) have you requested one already? -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711856: dovecot-imapd: Permission denied missing +w perm: /var/mail, we're not in group 8(mail)
On 06/10/2013 03:05 PM, Bernhard Kuemel wrote: * What led up to the situation? I guess aptitude full-upgrade to wheezy No, I reinstalled debian. -- Encrypt emails. My GPG key is on public key servers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711855: RFS: aircrack-ng/1:1.1-6
On Mon, Jun 10, 2013 at 02:12:02PM +0200, Carlos Alberto Lopez Perez wrote: * Remove unused Build-Depends on obsolete libnl-dev (Closes: #688158) ---end quoted text--- Why is netlink support disabled ? -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature