Bug#770663: unblock: java3d/1.5.2+dfsg-10
Control: tags -1 moreinfo On 2014-11-23 05:49, tony mancill wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package java3d Dear Release Team, Please consider an unblock for java3d/1.5.2+dfsg-10. This upload resolves FTBFS bug #769301. [...] It also includes packaging-only updates (that were already in the packaging repo since August). These don't affect the resulting binary. The debdiff is attached. Thank you for considering the unblock. tony unblock java3d/1.5.2+dfsg-10 [...] Hi tony, Thanks for resolving this bug. I would love to unblock it - unfortunately, the changes also includes a debhelper compat bump, which is explicitly listed as an unacceptable change in the freeze policy[1]. This is due to debhelper compat bumps having implicit changes that are not immediately visible in the diffs. If you undo the d/compat change, I will accept the rest of the changes as-is. Thanks, ~Niels [1] https://release.debian.org/jessie/freeze_policy.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770671: redis-server: warning in postinst
Source: redis-server Severity: minor Dear Maintainer, When instaling redis-server, the postinst emits the following warning: adduser: Warning: The home directory `/var/lib/redis' does not belong to the user you are currently creating. The installation was done in a (mostly-clean) Jessie chroot when installing build-deps for hiredis: apt-get build-dep hiredis Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: libjemalloc1 redis-server redis-tools 0 upgraded, 3 newly installed, 0 to remove and 7 not upgraded. Need to get 476 kB of archives. After this operation, 1420 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://cdn.debian.net/debian/ jessie/main libjemalloc1 amd64 3.6.0-3 [89.1 kB] Get:2 http://cdn.debian.net/debian/ jessie/main redis-tools amd64 2:2.8.17-1 [78.9 kB] Get:3 http://cdn.debian.net/debian/ jessie/main redis-server amd64 2:2.8.17-1 [308 kB] Fetched 476 kB in 0s (1286 kB/s) Selecting previously unselected package libjemalloc1. (Reading database ... 118182 files and directories currently installed.) Preparing to unpack .../libjemalloc1_3.6.0-3_amd64.deb ... Unpacking libjemalloc1 (3.6.0-3) ... Selecting previously unselected package redis-tools. Preparing to unpack .../redis-tools_2%3a2.8.17-1_amd64.deb ... Unpacking redis-tools (2:2.8.17-1) ... Selecting previously unselected package redis-server. Preparing to unpack .../redis-server_2%3a2.8.17-1_amd64.deb ... Unpacking redis-server (2:2.8.17-1) ... Processing triggers for man-db (2.7.0.2-3) ... Setting up libjemalloc1 (3.6.0-3) ... Setting up redis-tools (2:2.8.17-1) ... Setting up redis-server (2:2.8.17-1) ... adduser: Warning: The home directory `/var/lib/redis' does not belong to the user you are currently creating. Starting redis-server: redis-server. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770613: botch: FTBFS: Unbound module BoilerplateNoRpm
Hi, Quoting Daniel Schepler (2014-11-22 17:49:21) Error: Unbound module BoilerplateNoRpm thanks for reporting this. This problem is known and was introduced by the recent upload of dose3 3.3-beta1. Botch upstream was adapted to work with dose3 3.3 which only sits in experimental. So a botch upload that fixes this FTBFS can only happen to experimental. Thanks! cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770672: gnome-packagekit: FTBFS without docbook: reference to entity REFENTRY for which no system identifier could be generated
Source: gnome-packagekit Version: 3.14.0-1 Severity: serious From my pbuilder build log, using an archive of locally rebuilt packages: ... Making all in man make[3]: Entering directory '/tmp/buildd/gnome-packagekit-3.14.0/man' docbook2man gpk-application.sgml /dev/null docbook2man gpk-dbus-service.sgml /dev/null docbook2man gpk-install-local-file.sgml /dev/null docbook2man gpk-log.sgml /dev/null docbook2man gpk-prefs.sgml /dev/null docbook2man gpk-update-viewer.sgml /dev/null nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:1:59:W: cannot generate system identifier for public text -//OASIS//DTD DocBook V4.1//EN nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:7:0:E: reference to entity REFENTRY for which no system identifier could be generated nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:1:0: entity was defined here nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:7:0:E: DTD did not contain element declaration for document type name nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-application.sgml:1:59:W: cannot generate system identifier for public text -//OASIS//DTD DocBook V4.1//EN nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-application.sgml:7:0:E: reference to entity REFENTRY for which no system identifier could be generated nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-application.sgml:1:0: entity was defined here nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-application.sgml:7:0:E: DTD did not contain element declaration for document type name nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:9:9:E: element REFENTRY undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-update-viewer.sgml:1:59:W: cannot generate system identifier for public text -//OASIS//DTD DocBook V4.1//EN nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:10:15:E: element REFENTRYINFO undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:11:12:E: element ADDRESS undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:12:12:E: element EMAIL undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:14:11:E: element AUTHOR undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:15:16:E: element FIRSTNAME undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-update-viewer.sgml:7:0:E: reference to entity REFENTRY for which no system identifier could be generated nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-update-viewer.sgml:1:0: entity was defined here nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:16:14:E: element SURNAME undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:18:14:E: element COPYRIGHT undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:19:11:E: element YEAR undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-update-viewer.sgml:7:0:E: DTD did not contain element declaration for document type name nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:20:13:E: element HOLDER undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:22:10:E: element DATE undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:24:10:E: element REFMETA undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:25:18:E: element REFENTRYTITLE undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:26:14:E: element MANVOLNUM undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:28:13:E: element REFNAMEDIV undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:29:12:E: element REFNAME undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:30:15:E: element REFPURPOSE undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:32:17:E: element REFSYNOPSISDIV undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:33:16:E: element CMDSYNOPSIS undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-application.sgml:9:9:E: element REFENTRY undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:34:14:E: element COMMAND undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:35:10:E: element ARG undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-application.sgml:10:15:E: element REFENTRYINFO undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:35:18:E: element OPTION undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-application.sgml:11:12:E: element ADDRESS undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-application.sgml:12:12:E: element EMAIL undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:38:11:E: element REFSECT1 undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-prefs.sgml:39:10:E: element TITLE undefined nsgmls:/tmp/buildd/gnome-packagekit-3.14.0/man/gpk-application.sgml:14:11:E: element
Bug#769557: education-common: package fails to upgrade properly from wheezy
Hi Don, On Sonntag, 23. November 2014, Don Armstrong wrote: is it accepted by bendel (lists.debian.org) And then it gets discarded by the mailing list because the message was too large. I think the limit is 200K, and that message exceeds it. ah, thanks. Did Lucas get a warning about this or are these mails silently discarded? signature.asc Description: This is a digitally signed message part.
Bug#770673: evince: SIGSEGV when pdf file is changed while viewed
Package: evince Version: 3.14.1-1 Severity: normal Hi, from time to time I saw evince crashing with SIGSEGV when viewing a pdf file which is at the same time recreated by a LaTeX compilation. To further look into that issue, I used the following test sequence: * open 'some.pdf' file in evince * make a copy 'copy.pdf' of the pdf file * run while true; do cat copy.pdf some.pdf; done * wait a few seconds -- SIGSEGV Attached is the gdb session including a backtrace. Best regards, Andi -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages evince depends on: ii evince-common 3.14.1-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii libatk1.0-02.14.0-1 ii libc6 2.19-13 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libevdocument3-4 3.14.1-1 ii libevview3-3 3.14.1-1 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.0-2 ii libgtk-3-0 3.14.4-2 ii libnautilus-extension1a3.14.0-1 ii libpango-1.0-0 1.36.8-2 ii libpangocairo-1.0-01.36.8-2 ii libsecret-1-0 0.18-1+b1 ii libxml22.9.1+dfsg1-4 ii shared-mime-info 1.3-1 ii zlib1g 1:1.2.8.dfsg-2 Versions of packages evince recommends: ii dbus-x11 1.8.10-1 ii gvfs 1.22.1-1 Versions of packages evince suggests: pn nautilus none ii poppler-data 0.4.7-1 pn unrar none -- no debconf information GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from evince...Reading symbols from /usr/lib/debug//usr/bin/evince...done. done. (gdb) run Starting program: /usr/bin/evince [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x7fffee0be700 (LWP 12475)] [New Thread 0x7fffed8bd700 (LWP 12476)] [New Thread 0x7fffed0bc700 (LWP 12477)] [New Thread 0x7fffd700 (LWP 12478)] [New Thread 0x7fffdf7fe700 (LWP 12479)] [New Thread 0x7fffde6e2700 (LWP 12480)] [Thread 0x7fffed8bd700 (LWP 12476) exited] [Thread 0x7fffdf7fe700 (LWP 12479) exited] [New Thread 0x7fffdf7fe700 (LWP 12506)] [New Thread 0x7fffed8bd700 (LWP 12508)] [New Thread 0x7fffc700 (LWP 12509)] [Thread 0x7fffc700 (LWP 12509) exited] [Thread 0x7fffed8bd700 (LWP 12508) exited] [Thread 0x7fffdf7fe700 (LWP 12506) exited] [New Thread 0x7fffdf7fe700 (LWP 12517)] [New Thread 0x7fffed8bd700 (LWP 12521)] [New Thread 0x7fffc700 (LWP 12522)] [New Thread 0x7fffcf7fe700 (LWP 12523)] [New Thread 0x7fffceffd700 (LWP 12524)] [New Thread 0x7fffce7fc700 (LWP 12525)] [New Thread 0x7fffcdffb700 (LWP 12526)] [New Thread 0x7fffcd7fa700 (LWP 12527)] [New Thread 0x7fffccff9700 (LWP 12528)] [New Thread 0x7fffb700 (LWP 12529)] [Thread 0x7fffc700 (LWP 12522) exited] [Thread 0x7fffcdffb700 (LWP 12526) exited] [Thread 0x7fffcd7fa700 (LWP 12527) exited] [Thread 0x7fffce7fc700 (LWP 12525) exited] [Thread 0x7fffcf7fe700 (LWP 12523) exited] [Thread 0x7fffceffd700 (LWP 12524) exited] [Thread 0x7fffdf7fe700 (LWP 12517) exited] [Thread 0x7fffb700 (LWP 12529) exited] [Thread 0x7fffed8bd700 (LWP 12521) exited] Program received signal SIGSEGV, Segmentation fault. __GI___libc_free (mem=0x3037312d363631) at malloc.c:2929 (gdb) bt #0 __GI___libc_free (mem=0x3037312d363631) at malloc.c:2929 #1 0x7797bdc4 in ev_view_build_height_to_page_cache (view=view@entry=0x7622e0, cache=cache@entry=0xd3d3b0) at /tmp/buildd/evince-3.14.1/./libview/ev-view.c:313 #2 0x7797d7b7 in ev_view_get_height_to_page (dual_height=0x0, height=synthetic pointer, page=0, view=0x7622e0) at /tmp/buildd/evince-3.14.1/./libview/ev-view.c:439 #3 get_page_y_offset (view=view@entry=0x7622e0, page=0, y_offset=y_offset@entry=0x762374) at /tmp/buildd/evince-3.14.1/./libview/ev-view.c:1202 #4 0x7797e9c6 in ev_view_size_request_continuous (requisition=0x762370, view=0x7622e0) at /tmp/buildd/evince-3.14.1/./libview/ev-view.c:3721 #5
Bug#770675: banshee: Crashes when loading Context Pane
Package: banshee Version: 2.6.2-2 Severity: normal Dear Maintainer, When I attempt to load the Context Pane (set to Wikipedia) while playing a song, Banshee crashes. The pane says Loading... and then the crash. Here's the output of banshee --debug: [1 Debug 00:27:14.646] Player state change: Idle - Loading [1 Debug 00:27:15.375] (libbanshee:player) [gapless] Triggering track-change signal [1 Warn 00:27:15.942] Seem to be stuck loading file:///home/dan/Music/UntrustUs.ogg, so re-trying [1 Debug 00:27:17.696] Player state change: Loading - Loaded [1 Info 00:27:18.078] Uncached artwork size 34 requested [1 Debug 00:27:18.095] Player state change: Loaded - Playing [1 Debug 00:27:18.207] Creating Pango.Layout, configuring Cairo.Context [1 Debug 00:27:18.213] Creating Pango.Layout, configuring Cairo.Context [1 Debug 00:27:19.094] TrackInfoDisplay RenderAnimation: 21.00 FPS [1 Debug 00:27:33.226] Opening http://en.wikipedia.org/wiki/Crystal_Castles Stacktrace: at unknown 0x at (wrapper managed-to-native) Gtk.Application.gtk_main () IL 0x00022, 0x at Gtk.Application.Run () IL 0x0, 0x00018 at Banshee.Gui.GtkBaseClient.Run () IL 0x00019, 0x000d8 at Banshee.Gui.GtkBaseClient.Startup () IL 0x00010, 0x00068 at Hyena.Gui.CleanRoomStartup.Startup (Hyena.Gui.CleanRoomStartup/StartupInvocationHandler) IL 0x00050, 0x000e4 at Banshee.Gui.GtkBaseClient.StartupT () IL 0x00038, 0x000c8 at Banshee.Gui.GtkBaseClient.StartupT (string[]) IL 0x00050, 0x0017c at Nereid.Client.Main (string[]) IL 0x2, 0x00028 at (wrapper runtime-invoke) Module.runtime_invoke_void_object (object,intptr,intptr,intptr) IL 0x00050, 0x at unknown 0x at (wrapper managed-to-native) System.AppDomain.ExecuteAssembly (System.AppDomain,System.Reflection.Assembly,string[]) IL 0x0002f, 0x at System.AppDomain.ExecuteAssemblyInternal (System.Reflection.Assembly,string[]) IL 0x0002f, 0x00064 at System.AppDomain.ExecuteAssembly (string,System.Security.Policy.Evidence,string[]) IL 0xb, 0x0004c at (wrapper remoting-invoke-with-check) System.AppDomain.ExecuteAssembly (string,System.Security.Policy.Evidence,string[]) IL 0x0003b, 0x at System.AppDomain.ExecuteAssembly (string) IL 0x4, 0x00038 at (wrapper remoting-invoke-with-check) System.AppDomain.ExecuteAssembly (string) IL 0x00039, 0x at Booter.Booter.BootClient (string) IL 0x00025, 0x000ac at Booter.Booter.Main () IL 0x0010c, 0x002d4 at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) IL 0x0004c, 0x Native stacktrace: banshee() [0x100bb9d0] banshee() [0x100f5c3c] linux-vdso32.so.1(__kernel_sigtramp_rt32+0) [0x1003a0] /usr/lib/powerpc-linux-gnu/libjavascriptcoregtk-1.0.so.0(_ZN3JSC5LLInt5CLoop7executeEPNS_9ExecStateEPvb+0x12fc) [0x9d8897c] /usr/lib/powerpc-linux-gnu/libjavascriptcoregtk-1.0.so.0(_ZN3JSC5LLInt5CLoop7executeEPNS_9ExecStateEPvb+0x480) [0x9d87b00] /usr/lib/powerpc-linux-gnu/libjavascriptcoregtk-1.0.so.0(callToJavaScript+0x254) [0x9d870d4] /usr/lib/powerpc-linux-gnu/libjavascriptcoregtk-1.0.so.0(_ZN3JSC7JITCode7executeEPNS_2VMEPNS_14ProtoCallFrameEPNS_8RegisterE+0x68) [0x9d77058] /usr/lib/powerpc-linux-gnu/libjavascriptcoregtk-1.0.so.0(_ZN3JSC11Interpreter7executeEPNS_17ProgramExecutableEPNS_9ExecStateEPNS_8JSObjectE+0x14ac) [0x9d71fec] /usr/lib/powerpc-linux-gnu/libjavascriptcoregtk-1.0.so.0(_ZN3JSC8evaluateEPNS_9ExecStateERKNS_10SourceCodeENS_7JSValueEPS5_+0x2f0) [0x9e64a50] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0x519634) [0xa6f0634] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0x519950) [0xa6f0950] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0x74f730) [0xa926730] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0x9a8618) [0xab7f618] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0x9a8938) [0xab7f938] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0x9a8d9c) [0xab7fd9c] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0x9a8dcc) [0xab7fdcc] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0x992260) [0xab69260] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0xb2b098) [0xad02098] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0xb2ac70) [0xad01c70] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0xb3a4f0) [0xad114f0] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0xbaafc0) [0xad81fc0] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0xb9e1b4) [0xad751b4] /usr/lib/powerpc-linux-gnu/libwebkitgtk-1.0.so.0(+0x15e6824) [0xb7bd824] /usr/lib/powerpc-linux-gnu/libgio-2.0.so.0(+0x7d3b0) [0xf6cb3b0] /usr/lib/powerpc-linux-gnu/libgio-2.0.so.0(+0xb4078) [0xf702078] /usr/lib/powerpc-linux-gnu/libgio-2.0.so.0(+0xb40cc) [0xf7020cc] /lib/powerpc-linux-gnu/libglib-2.0.so.0(+0x59904)
Bug#770653: unblock (pre-approval): vlc/2.2.0~rc2-1
Control: tags -1 confirmed On 2014-11-23 00:32, Sebastian Ramacher wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock vlc 2.2.0~rc2 got released today. Similar to #767971, I'd like to get this version into jessie and stick with upstream as close as possible. Besides the bugs mentioned in d/changelog, it includes fixes for integer overflows in the rtp code, fixes for memcpy used on overlapping memory areas and fixes for use-after-free errors. Hi Sebastian, Please go ahead and upload this one to unstable and let us know once it has been accepted. Also, please be advised that the freeze policy will become stricter in the near future (5th of December). The filtered debdiff is attached. It was generated with [...] Some of the code has been re-intended for no good reason and so the debdiff includes some noise eventhough it was generated with git diff -w (especially VLSub.lua). The diffstat of the remaining changes (Translation updates and stuff not for us) is the following: [...] Thanks for including these lists. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691259: Chromium and open_generic
Hi, this bug report has now been open for two years. The problem as described by Alad Wenter actually breaks mailto: links in chromium for me. Maybe I should have made this more clear in the initial report. I already provided a patch. Is there anything else I can do to get this fixed? regards tobias signature.asc Description: OpenPGP digital signature
Bug#769787: unblock (pre-approval): poco 1.3.6p1-5
Control: tags -1 confirmed On 2014-11-22 16:21, Cristian Greco wrote: On Mon, 17 Nov 2014 23:25:25 +0100 Niels Thykier ni...@thykier.net wrote: [...] Hi Niels, please find attached a new debdiff for review. Maxime reworked the patch to avoid ABI/API breakages by adding a new static function. The changes have been approved by upstream authors: https://github.com/pocoproject/poco/issues/615 Thanks, -- Cristian Greco GPG key ID: 0xCF4D32E4 Hi Cristian, Thanks for the alternative patch. Please upload that debdiff to unstable. Once the upload has been accepted in unstable, please ping this bug and remove the moreinfo tag. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770677: blender: Blender crashes while rendering with cycles.
Package: blender Version: 2.72.b+dfsg0-1 Severity: important Dear Maintainer, blender crashes while rendering with cycles (with gui and in a shell also). I tested it on all my systems, so I think it is a problem in general. The originalpackage from blender.org works. Thank you and best regards Tom Guder -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/12 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages blender depends on: ii blender-data 2.72.b+dfsg0-1 ii fonts-droid 1:4.4.4r2-4 ii libavcodec56 10:2.4.3-dmo1 ii libavdevice55 6:11-2 ii libavformat56 10:2.4.3-dmo1 ii libavutil54 10:2.4.3-dmo1 ii libboost-date-time1.55.0 1.55.0+dfsg-3 ii libboost-filesystem1.55.0 1.55.0+dfsg-3 ii libboost-locale1.55.0 1.55.0+dfsg-3 ii libboost-regex1.55.0 1.55.0+dfsg-3 ii libboost-system1.55.0 1.55.0+dfsg-3 ii libboost-thread1.55.0 1.55.0+dfsg-3 ii libc6 2.19-13 ii libfftw3-double3 3.3.4-1.1 ii libfreetype6 2.5.2-2 ii libgcc1 1:4.9.1-19 ii libgl1-mesa-glx [libgl1] 10.3.2-1 ii libglew1.10 1.10.0-3 ii libglu1-mesa [libglu1]9.0.0-2 ii libgomp1 4.9.1-19 ii libilmbase6 1.0.1-6.1 ii libjack-jackd2-0 [libjack-0.116] 1.9.10+20140719git3eb0ae6a~dfsg-2 ii libjpeg62-turbo 1:1.3.1-10 ii libjs-jquery 1.7.2+dfsg-3.2 ii libjs-jquery-ui 1.10.1+dfsg-1 ii libopenal11:1.15.1-5 ii libopencolorio1 1.0.9~dfsg0-3 ii libopenexr6 1.6.1-8 ii libopenimageio1.4 1.4.14~dfsg0-1 ii libopenjpeg5 1:1.5.2-3 ii libpng12-01.2.50-2+b1 ii libpython3.4 3.4.2-1 ii libsdl1.2debian 1.2.15-10 ii libsndfile1 1.0.25-9+b1 ii libspnav0 0.2.2-1 ii libstdc++64.9.1-19 ii libswscale3 10:2.4.3-dmo1 ii libtiff5 4.0.3-10+b3 ii libx11-6 2:1.6.2-3 ii libxi62:1.7.4-1+b1 ii libxxf86vm1 1:1.1.3-1+b1 ii zlib1g1:1.2.8.dfsg-2 blender recommends no packages. blender 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#770676: quodlibet: Playback error with audio equalizer
Package: quodlibet Version: 3.2.2-1 Severity: normal Dear Maintainer, When I attempt to play a song with the equalizer plugin enabled, I get a popup message saying, Playback Error: Could not create GStreamer Pipeline. In the terminal output, all it had was: W: Linking the GStreamer pipeline failed W: Could not create GStreamer pipeline Playback without the equalizer enabled is fine. Regards, Dan -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 3.16-2-powerpc 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 quodlibet depends on: ii exfalso 3.2.2-1 ii gir1.2-gst-plugins-base-1.0 1.4.4-2 ii gir1.2-gstreamer-1.01.4.4-2 ii gstreamer1.0-plugins-bad [gstreamer1.0-audiosink] 1.4.4-2 ii gstreamer1.0-plugins-base 1.4.4-2 ii gstreamer1.0-plugins-good [gstreamer1.0-audiosink] 1.4.4-2 ii gstreamer1.0-plugins-ugly 1.4.4-2 ii gstreamer1.0-pulseaudio [gstreamer1.0-audiosink]1.4.4-2 ii python 2.7.8-2 Versions of packages quodlibet recommends: ii gir1.2-gtksource-3.0 3.14.1-1 ii gir1.2-keybinder-3.0 0.3.0-1 ii libgpod4 0.8.3-1.1+b1 ii media-player-info 22-2 ii notification-daemon 0.7.6-2 ii python-dbus 1.2.0-2+b3 ii python-feedparser 5.1.3-3 ii python-pyinotify 0.9.4-1 ii udisks2 2.1.3-5 Versions of packages quodlibet suggests: ii gstreamer1.0-plugins-bad 1.4.4-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#770678: claws-mail-pgpinline: pgpinline does not automatically encrypt / decrypt attachments
Package: claws-mail-pgpinline Version: 3.11.1-1 Severity: wishlist This is the first time I have ever had the opportunity to used PGP-encrypted e-mail, and it is mostly two thumbs up on claws! But: the organization I am working with (mostly) uses Outlook with a gpg4o plugin which is apparently not PGP-MIME compatible. On there end Outlook is not decrypting my PGP-MIME e-mail, they have to decrypt manually. E-mail text only works properly between us if I use PGP-inline to communicate with them. However, on there side, this gpg4o thing DOES automatically encypt / decrypt attachments, which puts me at a bit of a disadvantage because our PGP-inline DOES NOT, and I cannot use PGP-MIME So if possible, it would be very convenient for me if PGP-inline were to handle attachments automatically. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.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 claws-mail-pgpinline depends on: ii claws-mail 3.11.1-1 ii claws-mail-pgpmime [claws-mail-pgpcore] 3.11.1-1 ii libarchive13 3.1.2-9 ii libassuan0 2.1.2-2 ii libatk1.0-0 2.14.0-1 ii libc62.19-13 ii libcairo21.14.0-2.1 ii libdb5.3 5.3.28-6 ii libetpan17 1.5-1 ii libfontconfig1 2.11.0-6.1 ii libfreetype6 2.5.2-2 it libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.0-2 ii libgnutls-deb0-283.3.8-4 ii libgpg-error01.17-2 ii libgpgme11 1.5.1-6 ii libgtk2.0-0 2.24.25-1 ii liblockfile1 1.09-6 ii libpango-1.0-0 1.36.8-2 ii libpangocairo-1.0-0 1.36.8-2 ii libpangoft2-1.0-01.36.8-2 ii libsasl2-2 2.1.26.dfsg1-12 ii zlib1g 1:1.2.8.dfsg-2 claws-mail-pgpinline recommends no packages. claws-mail-pgpinline 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#769981: reprepro complaining about 'all' architecture
* Michael P. Soulier msoul...@digitaltorque.ca [141119 20:51]: On Nov 19, 2014, at 12:45 PM, Debian Bug Tracking System ow...@bugs.debian.org wrote: - delete all from all Architecture: lines in conf/distributions - run reprepro --delete clearvanished (reprepro should tell you to do this if you try to run it) So for my packages that will run on any platform, should they be architecture “any” then? Your package is Architecture all. If you include it, reprepro will by default add it to every architecture. So for an architecture any package the split is done at build time: debian/control Architecture: any Binaries generated by the different builds: _amd64.deb _i386.deb _deb put into: binary-amd64/Packages, binary-i386/Packages, binary-.../Packages while for an architecture all package the split is done when including it into a repository: debian/control Architecture: any Binaries generated by the builds: _all.deb put into: binary-amd64/Packages, binary-i386/Packages, binary-.../Packages Hope that clears it up, Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770679: gstreamer1.0-alsa crashes multiple apps
Package: gstreamer1.0-alsa
Version: 1.4.4-2
Severity: important
Dear Maintainer,
When I have gstreamer1.0-alsa installed on my system, every gstreamer audio
app I have crashes when attempting to play a file. Removing gstreamer1.0-alsa
fixes the problem. Here are a couple of backtraces, first Rhythmbox and then
gst123:
[New Thread 0xb621c260 (LWP 3035)]
[Thread 0xb621c260 (LWP 3035) exited]
[New Thread 0xb5595260 (LWP 3036)]
[New Thread 0xb4d95260 (LWP 3037)]
[Thread 0xb4d95260 (LWP 3037) exited]
[New Thread 0xb4595260 (LWP 3038)]
[Thread 0xb4595260 (LWP 3038) exited]
[New Thread 0xb3d95260 (LWP 3039)]
[Thread 0xb3d95260 (LWP 3039) exited]
[New Thread 0xb3d95260 (LWP 3040)]
[New Thread 0xb3564260 (LWP 3041)]
[New Thread 0xb2bff260 (LWP 3042)]
[New Thread 0xb23ff260 (LWP 3043)]
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0xb23ff260 (LWP 3043)]
0xb2d551a0 in ?? ()
(gdb) bt full
#0 0xb2d551a0 in ?? ()
No symbol table info available.
#1 0x07a1dfa8 in ?? ()
from /usr/lib/powerpc-linux-gnu/gstreamer-1.0/libgstaudioconvert.so
No symbol table info available.
#2 0x07a1e00c in ?? ()
from /usr/lib/powerpc-linux-gnu/gstreamer-1.0/libgstaudioconvert.so
No symbol table info available.
#3 0x07a13874 in ?? ()
from /usr/lib/powerpc-linux-gnu/gstreamer-1.0/libgstaudioconvert.so
No symbol table info available.
#4 0x07a14600 in ?? ()
from /usr/lib/powerpc-linux-gnu/gstreamer-1.0/libgstaudioconvert.so
No symbol table info available.
#5 0x07a10920 in ?? ()
from /usr/lib/powerpc-linux-gnu/gstreamer-1.0/libgstaudioconvert.so
No symbol table info available.
#6 0x0c43c35c in ?? () from /usr/lib/powerpc-linux-gnu/libgstbase-1.0.so.0
No symbol table info available.
#7 0x0c43ccd8 in ?? () from /usr/lib/powerpc-linux-gnu/libgstbase-1.0.so.0
No symbol table info available.
#8 0x0c2f2040 in ?? () from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
---Type return to continue, or q return to quit---
#9 0x0c43ce1c in ?? () from /usr/lib/powerpc-linux-gnu/libgstbase-1.0.so.0
No symbol table info available.
#10 0x0c2f2040 in ?? () from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#11 0x0c2dcc18 in gst_proxy_pad_chain_default ()
from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#12 0x0c2f2040 in ?? () from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#13 0x0c2dcc18 in gst_proxy_pad_chain_default ()
from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#14 0x0c2f2040 in ?? () from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#15 0x0c2dcc18 in gst_proxy_pad_chain_default ()
from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#16 0x0c2f2040 in ?? () from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#17 0x0c43ce1c in ?? () from /usr/lib/powerpc-linux-gnu/libgstbase-1.0.so.0
No symbol table info available.
#18 0x0c2f2040 in ?? () from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
---Type return to continue, or q return to quit---
#19 0x0c43ce1c in ?? () from /usr/lib/powerpc-linux-gnu/libgstbase-1.0.so.0
No symbol table info available.
#20 0x0c2f2040 in ?? () from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#21 0x0c43ce1c in ?? () from /usr/lib/powerpc-linux-gnu/libgstbase-1.0.so.0
No symbol table info available.
#22 0x0c2f2040 in ?? () from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#23 0x0c2dcc18 in gst_proxy_pad_chain_default ()
from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#24 0x0c2f2040 in ?? () from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#25 0x080a6af8 in ?? ()
from /usr/lib/powerpc-linux-gnu/gstreamer-1.0/libgstcoreelements.so
No symbol table info available.
#26 0x0c32d4fc in ?? () from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#27 0x0c32e9bc in ?? () from /usr/lib/powerpc-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#28 0x0c0f0918 in ?? () from /lib/powerpc-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#29 0x0c0ef918 in ?? () from /lib/powerpc-linux-gnu/libglib-2.0.so.0
---Type return to continue, or q return to quit---
No symbol table info available.
#30 0x0bfeec3c in start_thread (arg=0xb23ff260) at pthread_create.c:311
pd = 0xb23ff260
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -1219281896,
-1229576216, 4864, 0, 0, 0, 1, -1, -1, 0, 0, 0,
-1229947800, 1, -1219281848, 0, 0, -1295950992, 0, 0, 0, 1,
2392064, 0, 0, 202004528, 0, 0, 1, 204436912, 0, 0, 134895680,
0, 0, 280059448, 0, 0, 0, 0, 0, 0, 0, 0, 0, 204418048, 0, 0,
0,
Bug#769100: Minimal vs. proper fix of #769100 (htcondor is marked for auto-removal from testing)
Thanks for the report. I am CC'ing the Debian release team to get feedback regarding an acceptable fix Debian testing. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769100 This bug is caused by the (now invalid) assumption of the Debian packaging to find all relevant config variables in the main condor_config file (see the various sed expressions in debian/rules). However, as explained in https://htcondor-wiki.cs.wisc.edu/index.cgi/tktview?tn=4325 the mechanism for specifying the default configuration changed leading up to the 8.2.x series. The proper way to fix this is to move all default configuration settings from debian/rules into a patch of src/condor_utils/param_info.in. Alternatively, a CRED_STORE_DIR variable could be reintroduced into the default config file shipped with the package, which would override this particular (broken) default. The changes to the source package would be minimal, but the general invalid approach to specifying a default configuration would be kept. While I have the attention of the release time, I'd like to ask for feedback on pushing an upstream update into jessie. HTCondor uses the odd/even version setup for stable and development releases. The 8.2.x series is the stable branch that only sees fixes and no feature additions. After the freeze of jessie, htcondor 8.2.4 has been released which contains numerous bug fixes. An exhaustive list to the respective tickets can be found here. http://research.cs.wisc.edu/htcondor/manual/v8.2.4/10_3Stable_Release.html If approved, I'd like to update the package to 8.2.4, change the default configuration handling to a generally valid approach, and include the new translation available from the bug tracker. Thanks in advance for your feedback. Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768816: fwbuilder crashes in libqtgui
On 11/23/2014 02:29 AM, Michael Banck wrote: severity 768816 important thanks That's fine, given that you guys are not seeing it. On Fri, Nov 14, 2014 at 11:01:45AM +0100, Sylvestre Ledru wrote: Could you provide the backtrace? I cannot reproduce this issue on amd64 I tried in a i386 chroot and cannot reproduce it there either, so downgrading this bug to non-RC severity. But I still get it. [97180.030109] fwbuilder[20394]: segfault at 8 ip 7f6e92fee438 sp 7fff6845fd40 error 4 in libQtGui.so.4.8.6[7f6e92889000+aa] [100172.428166] fwbuilder[24000]: segfault at 8 ip 7f242d7b1438 sp 7fff52a7eb40 error 4 in libQtGui.so.4.8.6[7f242d04c000+aa] [100553.836676] fwbuilder[24388]: segfault at 8 ip 7fa04d5c6438 sp 7fff412d6bd0 error 4 in libQtGui.so.4.8.6[7fa04ce61000+aa] [100750.725408] fwbuilder[24869]: segfault at 8 ip 7f5d2d19e438 sp 767ff980 error 4 in libQtGui.so.4.8.6[7f5d2ca39000+aa] [101966.094268] fwbuilder[26170]: segfault at 8 ip 7f2739d2e438 sp 7fff58e73290 error 4 in libQtGui.so.4.8.6[7f27395c9000+aa] What makes me wonder is that the issue is only seen with my regular user account. On the same machine, under a different user account (test), fwbuilder works fine. Is it possible that a crash could occur only for a particular user, given that the apps are system shipped ? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Bug#770680: collectd: please backport fix for segfault in lvm.c
Package: collectd Version: 5.4.1-5 Severity: important Tags: patch Dear Maintainer, A fix for #747093 is available upstream. I believe it should be included in the package shipped with jessie, as it prevents collectd from crashing in a pretty common situation. This patch will be part of upcoming bugfix release 5.4.2 and can be retrieved at this address: https://github.com/collectd/collectd/commit/25d7de930baa8a2 Thanks ! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770670: g++: fails to compile in c++0x mode on ppc64el with std::vector and SDL
Control: reassign -1 libsdl2-dev Control: severity -1 serious Control: retitle -1 libsdl2-dev - SDL.h includes altivec.h, breaks c++ code On Sun, Nov 23, 2014 at 08:54:52AM +0100, Johannes Schauer wrote: The issue seems to only appear when compiling with c++. It does not happen when compiling with clang++. Thus I'm reporting this bug against g++. Please reassign if this was the wrong conclusion. The problem lies within SDL_cpuinfo.h. It includes altivec.h, which by definition[1] provides an unconditional vector, pixel and bool define in standard-c++ mode. In GNU-c++ mode this names are only defined context-sensitive by cpp. SDL_cpuinfo.h is included by SDL.h. None of the SDL headers actually use vector or any of the vec_* functions, so this include looks unused. I re-assigned this bug to the correct package and made it RC. Including altivec.h makes arbitrary code break. Greetings, Bastian [1]: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html#PowerPC-AltiVec_002fVSX-Built-in-Functions -- You! What PLANET is this! -- McCoy, The City on the Edge of Forever, stardate 3134.0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770447: use of ssl.PROTOCOL_SSLv3 which we don't support anymore
On 11/22/2014 03:28 AM, Matteo F. Vescovi wrote: Hi! On Nov 21, 2014 7:51 PM, Thomas Goirand z...@debian.org mailto:z...@debian.org wrote: Thanks for taking the time to investigat it (which I didn't have time yet, but still wanted to push the bug before I had to go out of $workplace). Now, given that the SSLv3 feature is disabled by default, could this bug be closed? Thomas, is it ok for you? Cheers. Hi, I'm not sure you get the point of me opening this bug. The point is, if you have an instance of ssl.PROTOCOL_SSLv3, then when the Python parser will try to execute the code, it will crash (stack dump). For this reason, I've done something like this in my packages: http://anonscm.debian.org/cgit/openstack/oslo.messaging.git/commit/?id=6e39d2c1fad7be373651abd709feea9c3b56977c Maybe your package needs that too? Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770681: collectd fails to handle acknowledgements from riemann
Package: collectd Version: 5.4.1-5 Severity: important Tags: patch Dear Maintainer, Collectd doesn't handle the communication with a remote riemann server properly, which eventually leads the riemann server to stall. A patch for this issue will be part of upcoming bugfix release 5.4.2 and can be retrieved at this address: https://github.com/collectd/collectd/commit/e5d3760160c8f I believe it should be included in the package shipped with jessie, as it prevents a lockup and data loss when using collectd together with riemann with the default settings. Thanks ! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769100: Minimal vs. proper fix of #769100 (htcondor is marked for auto-removal from testing)
On 2014-11-23 10:21, Michael Hanke wrote: Thanks for the report. I am CC'ing the Debian release team to get feedback regarding an acceptable fix Debian testing. [...] Thanks in advance for your feedback. Michael Hi Michael, I will have to ask you to open a pre-approval unblock bug against the release.debian.org pseudo package with the debdiff of the desired changes. This is to avoid us losing track of your request due to the high amount of requests, we receive. You may propose the new upstream release as the changeset, arguing that all the changes are important bug fixes and the upload compiles with the [FREEZE POLICY]. If the changes are re-viewable[1] and agree with said assertion, we may approve it. Alternatively, we will ask you to kindly provide a target fix for the RC bug (and possibly a few of the others cherry-picked). Keep in mind that the window for getting non-RC bugs fixes into Jessie closes in less than two weeks! ~Niels [FREEZE POLICY] https://release.debian.org/jessie/freeze_policy.html [1] Pro-tip: The use of filterdiff to remove auto-generated files/transitions/etc. from the debdiff is appreciated, provided that the actual filter is provided with the debdiff. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770683: collectd: please backport fix for threading issue in curl* plugins
Package: collectd Version: 5.4.1-5 Severity: important Tags: patch Dear Maintainer, Collectd incorrectly initialises libgcrypt in the plugins using libcurl, leading to a segfault due to concurrent threads accessing shared resources. A patch for this issue will be part of upcoming bugfix release 5.4.2 and can be retrieved at this address: https://github.com/collectd/collectd/commit/66b400ab01b I believe it should be included in the package shipped with jessie, as it prevents collectd from crashing when several libgcrypt-backed plugins are used together. Also, this issue was raised but only partly fixed in #735173. The patch mentioned above fixes it completely. Thanks ! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769508: apt-spacewalk: diff for NMU version 1.0.6-4.1
Hi, Thanks for the upload, please move it from the delayed/5 to delayed/0 or upload it to the normal queue again. I'll ask for an unblock. Thanks, Bernd Am 22. November 2014 19:00:49 MEZ, schrieb Andreas Bombe andreas.bo...@mytum.de: Control: tags 769508 + patch Control: tags 769508 + pending Dear maintainer, I've prepared an NMU for apt-spacewalk (versioned as 1.0.6-4.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Also attached are the two commits which I haven't pushed to collab-maint yet (I will push them later). Regards. -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Bug#770682: nano: copyright file points to v2.0, should point to v2.3
Package: nano Version: 2.3.6-1 Severity: minor The /usr/share/doc/nano/copyright file says: It was downloaded from http://www.nano-editor.org/dist/v2.0/ This should either be updated to point at the current version or the version number should be dropped from the URL: http://www.nano-editor.org/dist/ -- Edward. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770684: lxc-start creates /dev with wrong permissions if invoked with restrictive umask
Package: lxc Version: 1:1.0.6-3 Severity: minor Recently I started a container via « sudo lxc-start … » without configuring sudo to reset the umask first. I subsequently found SSHing into the container was slightly broken and user sessions were hanging in weird ways. This turned out to be because /dev had been created with mode 0750 instead of the proper 0755; the problem went away when I explicitly reset the umask from 0027 to 0022. It would be nice if LXC programs that deal with files in the container either reset the umask themselves or explicitly chmodded created files to avoid causing problems when so invoked. --- Drake Wilson -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lxc depends on: ii init-system-helpers 1.21 ii libapparmor1 2.9.0-2 ii libc62.19-13 ii libcap2 1:2.24-6 ii libseccomp2 2.1.1-1 ii libselinux1 2.3-2 ii multiarch-support2.19-13 ii python3 3.4.2-1 Versions of packages lxc recommends: ii debootstrap 1.0.64 ii openssl 1.0.1j-1 ii rsync3.1.1-2+b1 Versions of packages lxc suggests: pn lua5.2 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#770685: collectd: please backport fix for segfault in configfile.c
Package: collectd Version: 5.4.1-5 Severity: important Tags: patch Dear Maintainer, A fix for #750440 is available upstream. I believe it should be included in the package shipped with jessie, as it prevents collectd from crashing in a pretty common situation. This patch will be part of upcoming bugfix release 5.4.2 and can be retrieved at this address: https://github.com/collectd/collectd/commit/6207fce91a09 Thanks ! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770686: RM: mp -- ROM; obsolete
Package: ftp.debian.org Severity: normal Please remove the package mp from the archive. It's been dead upstream for at least 10 years, and its build process is severely outdated (autotools 2.13, gtk1.2, etc). There are plenty of decent replacements with identical functionality in the archive (a2ps comes to mind). Thanks, Bas. -- Bas Zoetekouw SURFnet Collabotation Infra Services Tel: +31 30 2305362 Fax: +31 30 2305329 SURFnet - POBox 19035 - NL-3501 DA Utrecht - The Netherlands signature.asc Description: OpenPGP digital signature
Bug#770687: Default installation breaks access to gallery icons
Package: libapache-gallery-perl
Version: 1.0.2-3
Severity: important
Hi,
it seems the default installation of the galler-perl module does not work as
documented in the README (anymore?). The README contains this section about
making the static icons available and mentions that it has to come before
apache's standard /icons/ Alias:
2. Place the icons
For accessing the icons, you can create an alias to the directory where they
reside. Icons for libapache-gallery-perl *must* appear under /icons/gallery
on your topmost apache tree:
Alias /icons/gallery/ /usr/share/libapache-gallery-perl/icons/
This however does not work, in the apache logs its visible why this leads to a
403:
[Sat Nov 22 11:33:33.612612 2014] [core:error] [pid 26104] (2)No such file or
directory: [client 192.168.1.
51:55421] AH00132: file permissions deny server access:
/usr/share/libapache-gallery-perl/icons//usr/share/
libapache-gallery-perl/icons/agfolder.png
As you can see the /usr/share-path is duplicated when apache tries to access
the file. After quite some fruitless debugging attempts I finally turned to the
actual perl module and found this:
# Let Apache serve icons without us modifying the request
if ($r-uri =~ m/^\/icons/i) {
if ($r-uri =~ m/^\/icons\/gallery\/([^\/]+$)/i) {
$filename = /usr/share/libapache-gallery-perl/icons/$filename;
$r-filename($filename);
}
return $::MP2 ? Apache2::Const::DECLINED() :
Apache::Constants::DECLINED();
}
Which apparently prepends the directory to the filename. However as far as I
can see $filename is already set to the right path at this point which means
these lines break the path. Removing the line
$filename = /usr/share/libapache-gallery-perl/icons/$filename;
fixes accessing files via myhost/icons/gallery/agfolder.png.
Unfortunately just removing the Alias for icons/gallery won't work either since
then the default one from Apache kicks in.
Andreas
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libapache-gallery-perl depends on:
ii libapache2-mod-perl2 2.0.9~1624218-2
ii libimage-imlib2-perl 2.03-1+b3
ii libimage-info-perl 1.28-1
ii libimage-size-perl 3.232-1
ii libtemplate-perl 2.24-1.2+b1
ii libtext-template-perl 1.46-1
ii perl 5.20.1-2
libapache-gallery-perl recommends no packages.
libapache-gallery-perl 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#770688: collectd leak memory when using snmp plugin
Package: collectd Version: 5.4.1-5 Severity: important Tags: patch Dear Maintainer, collectd leaks memory when monitoring more than one SNMP device. This quickly leads to resource exhaustion on the machine running collectd. Two patches for this issue will be part of upcoming bugfix release 5.4.2. I've merged them together and I'm attaching the resulting patch here for your convenience. I believe this fix should be included in the package shipped with jessie, as it prevents collectd from saturating the host's memory in a pretty common situation. Thanks ! diff --git a/src/snmp.c b/src/snmp.c index ad81c89..7d340d1 100644 --- a/src/snmp.c +++ b/src/snmp.c @@ -1316,6 +1316,8 @@ static int csnmp_read_table (host_definition_t *host, data_definition_t *data) snmp_free_pdu (res); res = NULL; + /* snmp_synch_response already freed our PDU */ + req = NULL; sfree (errstr); csnmp_host_close_session (host); @@ -1437,6 +1439,10 @@ static int csnmp_read_table (host_definition_t *host, data_definition_t *data) snmp_free_pdu (res); res = NULL; + if (req != NULL) +snmp_free_pdu (req); + req = NULL; + if (status == 0) csnmp_dispatch_table (host, data, instance_list_head, value_list_head);
Bug#770690: collectd: please backport fix for threading issue in java plugin
Package: collectd Version: 5.4.1-5 Severity: important Tags: patch Dear Maintainer, Collectd incorrectly detaches threads in the java plugin, leading to a plugin lockup. A patch for this issue will be part of upcoming bugfix release 5.4.2 and can be retrieved at this address: https://github.com/collectd/collectd/commit/513a5cafb5c1 I believe it should be included in the package shipped with jessie, as it prevents collectd from locking up. Thanks ! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770689: python-pycuda: Insecure temporary file creation for kernel cache
Package: python-pycuda Severity: grave Tags: upstream security Justification: user security hole Dear Maintainer, See https://github.com/inducer/pycuda/issues/54 for the upstream report of this bug, which allows a local attacker to run arbitrary GPU code in the address space of the victim's application. The link also contains a patch. I happen to be running Ubuntu Trusty on the machine where I first discovered this, but it presumably affects any UNIX system with a shared system temporary directory. -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-39-generic (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770691: unblock: init-system-helpers/1.22
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: init-system-help...@packages.debian.org
(Filing this as requested by init-system-helpers maintainer
Michael Stapelberg.)
Please unblock init-system-helpers_1.22. It removes the problematic
perl dependency (growing the base system and, until recently, even
the essential set) now that perl_5.20.1-3 has acquired the required
new modules.
Changes:
init-system-helpers (1.22) unstable; urgency=medium
.
* Depend on perl-base instead of perl (Closes: #757891)
Full debdiff attached.
Thanks for your work,
--
Niko Tyni nt...@debian.org
diff -Nru init-system-helpers-1.21/debian/changelog
init-system-helpers-1.22/debian/changelog
--- init-system-helpers-1.21/debian/changelog 2014-08-21 08:40:58.0
+0300
+++ init-system-helpers-1.22/debian/changelog 2014-11-17 21:48:01.0
+0200
@@ -1,3 +1,9 @@
+init-system-helpers (1.22) unstable; urgency=medium
+
+ * Depend on perl-base instead of perl (Closes: #757891)
+
+ -- Michael Stapelberg stapelb...@debian.org Mon, 17 Nov 2014 20:47:58 +0100
+
init-system-helpers (1.21) unstable; urgency=medium
* Demote augeas-tools to Suggests and let the systemd2init tool error out
diff -Nru init-system-helpers-1.21/debian/control
init-system-helpers-1.22/debian/control
--- init-system-helpers-1.21/debian/control 2014-08-21 08:40:58.0
+0300
+++ init-system-helpers-1.22/debian/control 2014-11-18 19:56:41.0
+0200
@@ -13,7 +13,7 @@
Package: init-system-helpers
Architecture: all
Multi-Arch: foreign
-Depends: ${perl:Depends}, ${misc:Depends}
+Depends: perl-base (= 5.20.1-3), ${perl:Depends}, ${misc:Depends}
Breaks: systemd ( 44-12)
Description: helper tools for all init systems
This package contains helper tools that are necessary for switching between
diff -Nru init-system-helpers-1.21/debian/rules
init-system-helpers-1.22/debian/rules
--- init-system-helpers-1.21/debian/rules 2014-08-21 08:40:58.0
+0300
+++ init-system-helpers-1.22/debian/rules 2014-11-18 19:56:32.0
+0200
@@ -9,6 +9,10 @@
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
+override_dh_perl:
+ dh_perl -d --package=init-system-helpers
+ dh_perl --no-package=init-system-helpers
+
override_dh_auto_build:
dh_auto_build
for file in $$(ls script); do \
diff -Nru init-system-helpers-1.21/script/deb-systemd-helper
init-system-helpers-1.22/script/deb-systemd-helper
--- init-system-helpers-1.21/script/deb-systemd-helper 2014-08-21
08:40:58.0 +0300
+++ init-system-helpers-1.22/script/deb-systemd-helper 2014-11-17
23:59:23.0 +0200
@@ -84,11 +84,12 @@
use warnings;
use File::Path qw(make_path); # in core since Perl 5.001
use File::Basename; # in core since Perl 5
-use File::Find; # in core since Perl 5
use File::Temp qw(tempfile); # in core since Perl 5.6.1
use Text::ParseWords qw(shellwords); # in core since Perl 5
use Getopt::Long; # in core since Perl 5
-use Data::Dumper;
+# Make Data::Dumper::Dumper available if present (not present on systems that
+# only have perl-base, not perl).
+eval { require Data::Dumper; } or *Data::Dumper::Dumper = sub { no
Data::Dumper };
my $quiet = 0;
my $enabled_state_dir = '/var/lib/systemd/deb-systemd-helper-enabled';
@@ -260,7 +261,7 @@
my @links = get_link_closure($scriptname, $service_path);
debug Old state file contents: .
-Dumper([ state_file_entries($dsh_state) ]);
+Data::Dumper::Dumper([ state_file_entries($dsh_state) ]);
make_path(dirname($dsh_state));
my ($outfh, $tmpname) = tempfile('.stateX',
@@ -278,14 +279,14 @@
error(Unable to move $tmpname to $dsh_state);
debug New state file contents: .
-Dumper([ state_file_entries($dsh_state) ]);
+Data::Dumper::Dumper([ state_file_entries($dsh_state) ]);
}
sub was_enabled {
my ($scriptname) = @_;
my @entries = state_file_entries(dsh_state_path($scriptname));
-debug Contents: . Dumper(\@entries);
+debug Contents: . Data::Dumper::Dumper(\@entries);
for my $link (@entries) {
if (! -l $link) {
@@ -308,7 +309,7 @@
my $dsh_state = dsh_state_path($service_path);
my @entries = state_file_entries($dsh_state);
-debug Contents: . Dumper(\@entries);
+debug Contents: . Data::Dumper::Dumper(\@entries);
if (is_purge()) {
unlink($dsh_state) if -e $dsh_state;
Bug#770693: collectd: please backport fixes for notifications types
Package: collectd
Version: 5.4.1-5
Severity: important
Tags: patch
Dear Maintainer,
Collectd doesn't use the proper type for timestamps when sending
notifications, leading to erroneous date/times getting emitted. Several
patches for this issue will be part of upcoming bugfix release 5.4.2.
I've merged them together and I'm attaching the resulting patch here for
your convenience.
I believe this fix should be included in the package shipped with
jessie, as leads to collectd emitting bogus data with the default
settings.
Thanks !
diff --git a/src/exec.c b/src/exec.c
index cfd82a3..b9a7365 100644
--- a/src/exec.c
+++ b/src/exec.c
@@ -744,8 +744,8 @@ static void *exec_notification_one (void *arg) /* {{{ */
fprintf (fh,
Severity: %s\n
- Time: %.3f\n,
- severity, CDTIME_T_TO_DOUBLE (n-time));
+ Time: %u\n,
+ severity, (unsigned int)CDTIME_T_TO_TIME_T(n-time));
/* Print the optional fields */
if (strlen (n-host) 0)
diff --git a/src/pyvalues.c b/src/pyvalues.c
index 307af17..4f5c4ce 100644
--- a/src/pyvalues.c
+++ b/src/pyvalues.c
@@ -767,7 +771,7 @@ static void Values_dealloc(PyObject *self) {
}
static PyMemberDef Values_members[] = {
- {interval, T_INT, offsetof(Values, interval), 0, interval_doc},
+ {interval, T_DOUBLE, offsetof(Values, interval), 0, interval_doc},
{values, T_OBJECT_EX, offsetof(Values, values), 0, values_doc},
{meta, T_OBJECT_EX, offsetof(Values, meta), 0, meta_doc},
{NULL}
diff --git a/src/threshold.c b/src/threshold.c
index 7df4d61..887dbca 100644
--- a/src/threshold.c
+++ b/src/threshold.c
@@ -942,6 +942,7 @@ static int ut_missing (const value_list_t *vl,
cdtime_t missing_time;
char identifier[6 * DATA_MAX_NAME_LEN];
notification_t n;
+ cdtime_t now;
if (threshold_tree == NULL)
return (0);
@@ -951,13 +952,15 @@ static int ut_missing (const value_list_t *vl,
if ((th == NULL) || ((th-flags UT_FLAG_INTERESTING) == 0))
return (0);
- missing_time = cdtime () - vl-time;
+ now = cdtime ();
+ missing_time = now - vl-time;
FORMAT_VL (identifier, sizeof (identifier), vl);
NOTIFICATION_INIT_VL (n, vl);
ssnprintf (n.message, sizeof (n.message),
%s has not been updated for %.3f seconds.,
identifier, CDTIME_T_TO_DOUBLE (missing_time));
+ n.time = now;
plugin_dispatch_notification (n);
diff --git a/src/utils_cmd_putnotif.c b/src/utils_cmd_putnotif.c
index 5a9faff..d3cf383 100644
--- a/src/utils_cmd_putnotif.c
+++ b/src/utils_cmd_putnotif.c
@@ -49,13 +49,18 @@ static int set_option_severity (notification_t *n, const char *value)
static int set_option_time (notification_t *n, const char *value)
{
- time_t tmp;
-
- tmp = (time_t) atoi (value);
- if (tmp = 0)
+ char *endptr = NULL;
+ double tmp;
+
+ errno = 0;
+ tmp = strtod (value, endptr);
+ if ((errno != 0) /* Overflow */
+ || (endptr == value) /* Invalid string */
+ || (endptr == NULL) /* This should not happen */
+ || (*endptr != 0)) /* Trailing chars */
return (-1);
- n-time = tmp;
+ n-time = DOUBLE_TO_CDTIME_T (tmp);
return (0);
} /* int set_option_time */
Bug#770692: python-pyopencl: Insecure temporary file creation for kernel cache
Package: python-pyopencl Severity: grave Tags: upstream security Justification: user security hole Dear Maintainer, PyOpenCL creates a cache of compiled kernels in a predictable location in the temporary directory. Assuming a system-wide /tmp, an attacker can exploit this. This allows for arbitrary code execution on OpenCL devices (which could be a CPU); the cache also contains a Python pickle file, which may allow another route to arbitrary code execution. https://github.com/pyopencl/pyopencl/pull/68 contains an upstream patch to fix the issue by storing the cache in the XDG per-user cache directory instead of the temporary temporary. I happen to be running Ubuntu Trusty on the machine where I first discovered this, but it presumably affects any UNIX system with a shared system temporary directory. -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-39-generic (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769554: [Pkg-haskell-maintainers] Bug#769554: libghc-authenticate-doc: package fails to upgrade properly from wheezy
Hi, Am Sonntag, den 23.11.2014, 11:13 +0100 schrieb Joachim Breitner: Hence my question to those in the know (hence CC’ing debian-dpkg): How do I make sure that ghc-doc’s trigger is not run until all of ghc-doc’s dependencies (and their dependencies) are installed (not necessarily configured). The current chain of dependencies is: Package: ghc-doc Depends: haddock-interface-22, perl Package: ghc-haddock Provides: haddock, haddock-interface-21, haddock-interface-22 Depends: ghc (= 7.6.3-19), libc6 (= 2.14), libffi6 (= 3.0.4), libgmp10 or maybe I should be using interest-noawait instead of interest? After a reading of deb-triggers(5) that seems to be the case. I’ll just try it out... Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#769554: [Pkg-haskell-maintainers] Bug#769554: libghc-authenticate-doc: package fails to upgrade properly from wheezy
Hi, Am Freitag, den 14.11.2014, 14:49 +0100 schrieb Joachim Breitner: We might have to add some pre-depends somewhere. Is anyone volunteering to look into this issue? I take that as a no. So here is my analysis: ghc-doc’s trigger runs haddock. Haddock requires libffi6. For some reason, apt tries to run the trigger before all of ghc-haddock’s dependencies are installed. Here are the relevant bits from the log at http://aws-logs.debian.net/ftbfs-logs/2014/11/14/libghc-authenticate-doc_jessie_upgrade.log.gz The following NEW packages will be installed: libdevmapper1.02.1 libdns-export100 libexpat1 libfcgi-perl libffi6 The following packages will be upgraded: ghc-haddock grep ifupdown initscripts iproute libapt-pkg4.12 libc-bin Get:38 http://localhost/debian/ jessie/main ghc-haddock amd64 7.6.3-19 [4270 kB] Get:97 http://localhost/debian/ jessie/main libffi6 amd64 3.1-2 [19.8 kB] [...] Preparing to replace libghc-tagged-doc 0.4.2.1-1 (using .../libghc-tagged-doc_0.7.2-1_all.deb) ... Unpacking replacement libghc-tagged-doc ... Preparing to replace ghc-haddock 7.4.1-4 (using .../ghc-haddock_7.6.3-19_amd64.deb) ... Unpacking replacement ghc-haddock ... Preparing to replace libghc-socks-dev 0.4.1-1+b4 (using .../libghc-socks-dev_0.5.4-1+b1_amd64.deb) ... Unpacking replacement libghc-socks-dev ... [.. note no installation of libffi6 yet ..] Unpacking replacement libghc-enumerator-dev ... Preparing to replace libghc-parsec3-dev 3.1.2-1+b3 (using .../libghc-parsec3-dev_3.1.3-3+b1_amd64.deb) ... Unpacking replacement libghc-parsec3-dev ... Processing triggers for ghc-doc ... + set -e + test -x /usr/lib/ghc/bin/ghc-pkg + /usr/lib/ghc/bin/ghc-pkg recache --global + /usr/lib/ghc-doc/gen_contents_index haddock: error while loading shared libraries: libffi.so.6: cannot open shared object file: No such file or directory dpkg: error processing ghc-doc (--unpack): subprocess installed post-installation script returned error exit status 127 Unfortunately https://www.debian.org/doc/debian-policy/ch-relationships.html only talks about configuring and running postinst, but not triggers, Hence my question to those in the know (hence CC’ing debian-dpkg): How do I make sure that ghc-doc’s trigger is not run until all of ghc-doc’s dependencies (and their dependencies) are installed (not necessarily configured). The current chain of dependencies is: Package: ghc-doc Depends: haddock-interface-22, perl Package: ghc-haddock Provides: haddock, haddock-interface-21, haddock-interface-22 Depends: ghc (= 7.6.3-19), libc6 (= 2.14), libffi6 (= 3.0.4), libgmp10 (Alternatively, maybe ghc-doc’s trigger should simply fail less hard, under the assumption that the final trigger run should work, and if not, a broken documentation index is sever enough to abort an upgrade.) Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#769260: openturns: FTBFS in jessie/i386: Tests failures
tags 769260 pending thanks 2014-11-14 13:27 GMT+00:00 Cyril Brulebois k...@debian.org: [...] The following tests FAILED: 234 - cppcheck_TrapezoidalFactory_std (Failed) Errors while running CTest make[2]: *** [test] Error 8 Makefile:140: recipe for target 'test' failed Reproduced locally in a jessie i386 chroot (amd64 is passing the tests just fine). Relevant lines seem to be: | 273/359 Test #234: cppcheck_TrapezoidalFactory_std ..***Failed3.77 sec | --- /home/kibi/hack/bsp/i386/openturns-1.3/lib/test/t_TrapezoidalFactory_std.expout 2014-11-14 12:06:07.425831849 + | +++ /home/kibi/hack/bsp/i386/openturns-1.3/obj-i586-linux-gnu/lib/test/t_TrapezoidalFactory_std.out 2014-11-14 12:24:12.176560743 + | @@ -1,8 +1,8 @@ | Distribution =class=Trapezoidal name=Trapezoidal dimension=1 a=1 b=2.3 c=4.5 d=5 h=0.322581 | -Estimated distribution=class=Trapezoidal name=Trapezoidal dimension=1 a=1.005 b=2.279 c=4.545 d=4.99 h=0.32 | +Estimated distribution=class=Trapezoidal name=Trapezoidal dimension=1 a=1.006 b=2.275 c=4.545 d=4.99 h=0.3198 | Default distribution=class=Trapezoidal name=Trapezoidal dimension=1 a=-2 b=-1 c=1 d=2 h=0.33 | Distribution from parameters=class=Trapezoidal name=Trapezoidal dimension=1 a=1 b=2.3 c=4.5 d=5 h=0.322581 | Trapezoidal =class=Trapezoidal name=Trapezoidal dimension=1 a=1 b=2.3 c=4.5 d=5 h=0.322581 | -Estimated trapezoidal=class=Trapezoidal name=Trapezoidal dimension=1 a=1.005 b=2.279 c=4.545 d=4.99 h=0.32 | +Estimated trapezoidal=class=Trapezoidal name=Trapezoidal dimension=1 a=1.006 b=2.275 c=4.545 d=4.99 h=0.3198 | Default trapezoidal=class=Trapezoidal name=Trapezoidal dimension=1 a=-2 b=-1 c=1 d=2 h=0.33 | Trapezoidal from parameters=class=Trapezoidal name=Trapezoidal dimension=1 a=1 b=2.3 c=4.5 d=5 h=0.322581 Not quite the expected results but almost… Right, this test used to produce different results on x86, see http://anonscm.debian.org/cgit/debian-science/packages/openturns.git/tree/debian/patches/modify-tests-O0-i386.patch?id=9a477a3 It looks like there is a newer GCC version which fixed this issue, I will drop this patch. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770694: collectd: please backport fix for muted loglevel
Package: collectd
Version: 5.4.1-5
Severity: important
Tags: patch
Dear Maintainer,
A fix for #687067 is available upstream. I believe it should be included
in the package shipped with jessie, as it prevents collectd from not
emiting any logs at all, including important notifications about
monitoring data which went out of bounds.
The fix consists of two patches, which I've merged together and I'm
attaching the resulting patch here for your convenience.
Thanks !
diff --git a/src/logfile.c b/src/logfile.c
index 0f20f3c..63448cb 100644
--- a/src/logfile.c
+++ b/src/logfile.c
@@ -54,7 +54,11 @@ static int logfile_config (const char *key, const char *value)
{
if (0 == strcasecmp (key, LogLevel)) {
log_level = parse_log_severity(value);
- if (log_level == -1) return 1; /* to keep previous behaviour */
+ if (log_level 0) {
+ log_level = LOG_INFO;
+ ERROR (logfile: invalid loglevel [%s] defaulting to 'info', value);
+ return (1);
+ }
}
else if (0 == strcasecmp (key, File)) {
sfree (log_file);
diff --git a/src/syslog.c b/src/syslog.c
index 4f5d0c4..834ba79 100644
--- a/src/syslog.c
+++ b/src/syslog.c
@@ -48,7 +48,11 @@ static int sl_config (const char *key, const char *value)
{
log_level = parse_log_severity (value);
if (log_level 0)
+ {
+ log_level = LOG_INFO;
+ ERROR (syslog: invalid loglevel [%s] defaulting to 'info', value);
return (1);
+ }
}
else if (strcasecmp (key, NotifyLevel) == 0)
{
Bug#770695: Dovecot-core unable to finish its installation
Package: dovecot-core Version: 1:2.2.13-6 Severity: critical Hello, I'm trying to install dovecot on Jessie, but it's unable to install properly. There are two distinct problems: Missing SSL certificate, as reported in #732263 Broken post-install script (this report). the installer is stuck with this process: root@mailserver-1:~# dpkg --configure -a Setting up dovecot-core (1:2.2.13-6) ... Starting IMAP/POP3 mail server: dovecot. ps -fax shows this: 8651 pts/3S+ 0:00 \_ dpkg --configure -a 8652 pts/3S+ 0:00 \_ /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/dovecot-core.postinst configure 8658 pts/3Z+ 0:00 \_ [dovecot-core.po] defunct 10116 ?Ss 0:00 /usr/sbin/dovecot -c /etc/dovecot/dovecot.conf 10119 ?S 0:00 \_ dovecot/anvil 10120 ?S 0:00 \_ dovecot/log 10122 ?S 0:00 \_ dovecot/config It seems there's something wanting to ask questions, but nothing shows up on the screen… dpkg -l | grep dovecot: iF dovecot-core 1:2.2.13-6 amd64 System information: Distributor ID: Debian Description:Debian GNU/Linux testing (jessie) Release:testing Codename: jessie Running in a Vagrant box (Virtualbox provider). Cheers, C. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765071: Change in severity
To be more clear is not a browser problem.
As I said before every browser I tried on several devices does not
display icons.
I did a fresh install on amd64 and it works fine. I can connect to
mediatob from any browser.
I did a fresh install on armel and the result is no icons no matter
which browser I use for connecting to the mediatomb.
I think the severity should be reverted to grave.
Cheers
Mike
Michele Cane, PhD.
On Sat, Nov 22, 2014 at 6:38 PM, Sebastian Ramacher
sramac...@debian.org wrote:
Control: tags -1 + moreinfo unreproducible
Control: severity -1 normal
On 2014-11-17 20:38:25, Michele Cane wrote:
Hi,
I decided to change the severity to grave since I am not able to use
the program.
When I reach the webpage from any device the icons are not displayed
and therefore I cannot add folders.
Here the errors from the chromium console:
Uncaught SyntaxError: Unexpected token { prototype.js:2636
Uncaught SyntaxError: Unexpected identifier nanotree.js:51
Uncaught SyntaxError: Unexpected token } tree.js:31
Uncaught TypeError: Cannot read property 'src' of null
chrome-extension://mmoheajlpfaigefceljflpohdehkjbli/findblog.js:12
Uncaught ReferenceError: Try is not defined 192.168.2.101/:65
Error in response to storage.get: TypeError: Cannot read property
'data-pin-hover' of undefined
at Object.eval [as callback] (eval at anonymous
(chrome-extension://gpdjojdkbbmdfjfahjcgigfpmkopogic/hoverbuttons.js:4:11),
anonymous:579:28) 192.168.2.101/:1
I am available for providing any additional info.
Cheers
This is not reproducible with a fresh install of mediatomb. We have
tried it with iceweasel and chromium and all icons are displayed
correctly.
Do you have any extensions installed that mess with your browser?
I'm downgrading the bug since I don't think this is a bug in mediatomb.
Cheers
--
Sebastian Ramacher
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764251: Please set the build timestamp to a deterministic time
Hello, I appreciate this patch, it will go in the next bug fix / porting release. Regards Gerhard Rieger On 11/21/2014 01:24 AM, Stéphane Aulery wrote: Hello, Jérémy Bobbio lu...@debian.org proposed a patch to the Debian maintainer of socat to fix a compilation problem [1]. He commented: As part of the “reproducible builds” effort, we have discovered that socat is using the __DATE__ and __TIME__ C pre-processor macro to record the time of the build. This prevent socat build to be reproducible. The attached patch will instead set the value of the timestamp variable to the date of the latest debian/changelog entry. In order to do so, it will patch the build system to allow the build timestamp to be externally set through the BUILD_DATE variable. Once applied, socat can be built reproducibly. Maybe can you integrate it, please? [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764251 Regards, signature.asc Description: OpenPGP digital signature
Bug#769072: #769191, #770588: nvidia-opencl-icd breaking non-nvidia systems
Rebecca Palmerr wrote: The only other [than pyopencl] Depends or Recommends on opencl-icd in the current archive is bfgminer. Sorry...only ones found by path:debian/control opencl-icd in sources.debian.net search (apt-cache rdepends doesn't work on virtual packages), which evidently doesn't search non-free as it missed that nvidia-libopencl1 Recommends: nvidia-opencl-icd. Nathaniel Smith wrote: Looking through my apt history, it looks like the critical operation that gave me nvidia stuff was the installation of libboost[-all-dev] (!?): libboost-all-dev Depends: libboost-mpi-dev Depends: libboost-mpi1.55-dev Depends: libboost-mpi1.55.0 Depends: libhwloc5 Recommends: libhwloc-plugins, which at the time had Depends: libopencl-1.1-1, a virtual package provided by (among other things) nvidia-libopencl1, which Recommends: nvidia-opencl-icd. This has already been reported (#739409) and fixed: libhwloc-plugins now Depends: ocl-icd-libopencl1 | libopencl-1.1-1. However, cutting the chain there doesn't remove nvidia-opencl-icd if already installed, hence this bug. On 23/11/14 02:09, Andreas Beckmann wrote: I don't know how seriously the missing libcuda1 breaks nvidia-opencl-icd. I can see that this is being dlopen()ed, but at least clinfo still reports something about the GPU. I don't have a better testcase right now, suggestions welcome. If you want a quick does OpenCL work test, try python3 accuracy_speed_test.py (from https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=accuracy_speed_test.py;att=1;bug=768090 , Depends: python3-pyopencl, python3-scipy ). (Note that some of those tests are expected to give high/NaN errors because not all the inputs used are valid for all the functions: for the present purpose we're mainly looking for crashes/exceptions.) Given that we also don't want to break systems that are intentionally using nvidia-opencl-icd, a better fix might be for whatever sets nvidia as default graphics provider to only do so if the hardware is present, but I don't know whether that's practical. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768881: [Debian-ha-maintainers] Bug#768881: Bug#768881: FTBFS: unable to parse drbdsetup.xml.in
Control: severity -1 serious Control: tags -1 - moreinfo unreproducible Hi Adam, On 01:12 Sun 23 Nov , Adam Borowski wrote: On Sat, Nov 22, 2014 at 07:49:57PM +0200, Apollon Oikonomopoulos wrote: After looking a bit into this, it looks as if the parser state of xsltproc got messed up for some reason. Note that I am unable to reproduce this in any way, so I tend to think this might have been a problem with the build environment. I compared some systems which reproduce this with some that do not. And it turns out the build connects to http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd over live internet and acts differently according to whatever response it receives. Which is RC. Good catch. Actually it shouldn't connect to the internet at all, but we're missing a build-dependency on docbook-xml (we B-D only on docbook-xsl). Re-upgrading this to serious, because of the missing B-D. Thanks, Apollon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770696: r-base-core: R crashes with *** caught illegal operation ***
Package: r-base-core Version: 2.15.1-4 Severity: important R crashes because it tries to execute an illegal instruction. This is how you can reproduce: $ R R version 2.15.1 (2012-06-22) -- Roasted Marshmallows Copyright (C) 2012 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-pc-linux-gnu (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. ar.yw(rnorm(4000), aic=F, order.max=100) *** caught illegal operation *** address 0x7ff14fbd6d44, cause 'illegal operand' Traceback: 1: solve.default(toeplitz(drop(xacf)[seq_len(order)])) 2: solve(toeplitz(drop(xacf)[seq_len(order)])) 3: ar.yw.default(rnorm(4000), aic = F, order.max = 100) 4: ar.yw(rnorm(4000), aic = F, order.max = 100) Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace Selection: 1 aborting ... Illegal instruction Here is the /proc/cpuinfo of the machine: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping: 1 microcode : 0x17 cpu MHz : 2793.249 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl cid cx16 xtpr bogomips: 5586.49 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping: 1 microcode : 0x17 cpu MHz : 2793.249 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl cid cx16 xtpr bogomips: 5586.11 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-1, LC_CTYPE=en_GB.ISO-8859-1 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages r-base-core depends on: ii libatlas3-base [liblapack.so.3] 3.8.4-9+deb7u1 ii libblas3 [libblas.so.3] 1.2.20110419-5 ii libbz2-1.0 1.0.6-4 ii libc62.13-38+deb7u6 ii libcairo21.12.2-3 ii libgfortran3 4.7.2-5 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgomp1 4.7.2-5 ii libice6 2:1.0.8-2 ii libjpeg8 8d-1+deb7u1 ii liblapack3 [liblapack.so.3] 3.4.1+dfsg-1+deb70u1 ii liblzma5 5.1.1alpha+20120614-2 ii libpango1.0-01.30.0-1 ii libpaper-utils 1.1.24+nmu2 ii libpcre3 1:8.30-5 ii libpng12-0 1.2.49-1 ii libquadmath0 4.7.2-5 ii libreadline6 6.2+dfsg-0.1 ii libsm6 2:1.2.1-2 ii libtiff4 3.9.6-11 ii libx11-6 2:1.5.0-1+deb7u1 ii libxext6 2:1.3.1-2+deb7u1 ii libxss1 1:1.2.2-1 ii libxt6 1:1.1.3-1+deb7u1 ii tcl8.5 8.5.11-2 ii tk8.58.5.11-2 ii ucf 3.0025+nmu3 ii unzip6.0-8 ii xdg-utils1.1.0~rc1+git20111210-6+deb7u1 ii zip 3.0-6 ii zlib1g
Bug#770623: Fix Image version URL
In the section: -- Package-specific info: Boot method: started with DVD ISO then chosen to download packeges from the network Image version: DVD ISO Image: Debian GNU/Linux 7.6.0 _Wheezy_ - Official amd64 DVD Binary-1 20140712-14:11, I guess the url is http://cdimage.debian.org/cdimage/ar the URL has been truncated. The correct URL of the Image version is:http://cdimage.debian.org/cdimage/archive/7.6.0/amd64/iso-dvd/debian-7.6.0-amd64-DVD-1.iso
Bug#770377: (no subject)
25 is not much a difference from current limitation which is 20. When you tell about 10 - 10 is default, which can be changed in the configuration dialog, but you cannot increase it over 20, only way to increase is manually editing ini file but in that case you will be forever prohibited to open configuration again because it will then instantly reset it to 20 and drop all the history items over 20. Just compare it with the URL history which is maxed to 50. Have partial history being much bigger than full history is insane, and I believe full history should be allowed to set to 50 as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770648: hiredis: FTBFS: Test failure
Package: src:hiredis
Followup-For: Bug #770648
Dear Maintainer,
As already mentioned by David, you must not use network when building the
package,
even lo might not be available.
The attached patch disables the network-based tests.
PS: The pid-file location hardcoded to /tmp looks weird.. Maybe should be
patched
to use $CURDIR or a relatie path ?
If you want me to sponsor that upload, please ping me.
--
tobi
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Description: Disable network-based tests
As on the buildds no network is available, this patch disables the tests
which are expect are working network
Author: Tobias Frost t...@debian.org
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: hiredis-0.11.0/test.c
===
--- hiredis-0.11.0.orig/test.c
+++ hiredis-0.11.0/test.c
@@ -282,12 +282,16 @@ static void test_reply_reader(void) {
static void test_blocking_connection_errors(void) {
redisContext *c;
+#if 0
test(Returns error when host cannot be resolved: );
c = redisConnect((char*)idontexist.local, 6379);
test_cond(c-err == REDIS_ERR_OTHER
(strcmp(c-errstr,Name or service not known) == 0 ||
strcmp(c-errstr,Can't resolve: idontexist.local) == 0));
redisFree(c);
+#else
+test(SKIPPED: Returns error when host cannot be resolved\n);
+#endif
/*test(Returns error when the port is not open: );
c = redisConnect((char*)localhost, 1);
@@ -634,11 +638,15 @@ int main(int argc, char **argv) {
test_reply_reader();
test_blocking_connection_errors();
+#if 0
printf(\nTesting against TCP connection (%s:%d):\n, cfg.tcp.host, cfg.tcp.port);
cfg.type = CONN_TCP;
test_blocking_connection(cfg);
test_blocking_io_errors(cfg);
if (throughput) test_throughput(cfg);
+#else
+ printf(\nSKIPPED: Testing against TCP connection\n);
+#endif
printf(\nTesting against Unix socket connection (%s):\n, cfg.unix.path);
cfg.type = CONN_UNIX;
Bug#770697: dovecot-core: dovecot.pem not created
Package: dovecot-core Version: 1:2.2.13-6 Severity: important Dear maintainer of dovecot! I just installed dovecot-imapd from jessie on my server. Debconf forgot to create a server key and certificate. But /etc/dovecot/conf.d/10-ssl.conf includes them. So /etc/init.d/dovecot start fails and dpkg reports that it was not able to install dovecot correctly. After creating key and cert everything is fine. I propose either leave on localhost with disabled 10-ssl.conf or create some Pem-Files that work out of the box. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758973: [fontconfig-config] Stop breaking user configuration in /etc/fonts/conf.d/ after every upgrade
Control: -1 severity important Control: -1 retitle [fontconfig-config] Removed symlinks in /etc/fonts/conf.d get recreated when the opposite link doesn't exist either Hi, This is what I do: # rm /etc/fonts/conf.d/70-no-bitmaps.conf So, what is happening is that this is not a supported operation with the current scripts. Ths is where the data is read from the current state: debian/fontconfig-config.config enable_bitmaps=dunno yes_bitmaps_2_3=30-debconf-yes-bitmaps.conf yes_bitmaps_2_4=70-yes-bitmaps.conf no_bitmaps_2_3=30-debconf-no-bitmaps.conf no_bitmaps_2_4=70-no-bitmaps.conf if [ -h $CONFDIR/$yes_bitmaps_2_4 -o -h $CONFDIR/$yes_bitmaps_2_3 ]; then enable_bitmaps=true fi if [ -h $CONFDIR/$no_bitmaps_2_4 -o -h $CONFDIR/$no_bitmaps_2_3 ]; then enable_bitmaps=false fi # Versions prior to 2.6.0-2 are broken and leave us with no symbolic # link, so we have to re-ask the user his choice :( if [ $enable_bitmaps = dunno ]; then db_fset fontconfig/enable_bitmaps seen false enable_bitmaps=false fi db_set fontconfig/enable_bitmaps $enable_bitmaps end snippet And this is where it's applied: debian/fontconfig-config.postinst db_get fontconfig/enable_bitmaps enable_bitmaps=$RET yes_bitmaps=70-yes-bitmaps.conf no_bitmaps=70-no-bitmaps.conf if [ -h $CONFDIR/$yes_bitmaps ]; then rm $CONFDIR/$yes_bitmaps fi if [ -h $CONFDIR/$no_bitmaps ]; then rm $CONFDIR/$no_bitmaps fi case $enable_bitmaps in true) ln -s $CONFAVAIL/$yes_bitmaps $CONFDIR/$yes_bitmaps ;; *) ln -s $CONFAVAIL/$no_bitmaps $CONFDIR/$no_bitmaps ;; esac end snippet So, as you can see, it either creates the yes symlink or the no symlink. When you remove the no symlink without creating the yes symlink, you end up in an inconsistent state. This is the same situation for the other two debconf questions, if you remove the symlinks instead of creating the opposite one, you end up in an inconsistent state. This means a very bad user experience, but I'm not convinced that this is a grave bug, it's actually doing the right thing in reading the links that exist and not using debconf as a registry. It's just that you need to create the yes symlink instead of just removing the no symlink. Imagine that instead of symlinks this would be a conf file with a field in it, say enable_bitmaps, and you can either set it to true or false, but you go and set it to an empty string. This would be an inconsistent state and it would be acceptable for the field to be re-filled to turn into a consistent state again. The solution to your problem is to either run dpkg-reconfigure fontconfig-config and answer the bitmap question with yes, or manually create the yes file. The solution to this bug is much more complex, as it would require somehow signalling from the .config to the .postinst script that the user is in an inconsistent state and that state shouldn't be corrected. -- Regards, Marga -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669292: gitweb: automatic configuration breaks with apache2 2.4
Source: gitweb Severity: important Followup-For: Bug #669292 Well, I saw this bug on the BSP in Munich. My 2¢: unless the package cannot be configured manually this does not warrant a RC bug severity; its still useable for others. Downgrading to important, if you disagree, please feel free to bump it again (but consider that it won) -- tobi -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606224: oggvideotools: oggJoin fails on powerpc
[Daniel Kahn Gillmor] I haven't tested recently, and won't have access to a ppc machine for a few days. feel free to ping me later if i haven't made it back to test this, though. thanks for picking up this package! Did you manage to test if oggJoin still fail on powerpc? Perhaps you can send us a test script to run during build to discover the problem? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770193: glib2.0: FTBFS in jessie: gsettings test hangs during /gsettings/no-write-binding
Control: severity 770193 important Hi, On Sat, Nov 22, 2014 at 07:26:53PM +, Simon McVittie wrote: Anyone know whether FTBFS-when-building-as-root is considered to be RC? I'm pessimistically assuming yes for now, but it's possible that that's not something we intend to support. Packages should build on the buildds, otherwise they are RC-buggy (if they built fine before). This issue doesn't affect buildds (they don't build as root). Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
On Sat, Nov 22, 2014 at 08:51:41PM +, Dimitri John Ledkov wrote: On 22 November 2014 at 16:21, Ron r...@debian.org wrote: Dimitri wrote: Thus multiarch cross tooling is not so relevant for fresh bootstraps, and/or targeting non-debian architectures, or otherwise incomplete systems (e.g. those that do not have compatible set of pre-compiled binaries that use multiarch-paths I'll leave it to Helmut to talk about his existing work with bootstraps that's been stalled by reverting this patch. I can categorically say though that we are currently using a toolchain built this way on Jessie before it was broken by this change, both for embedded systems that do run Debian, and for microcontrollers that couldn't possibly run it (memory measured in kB, no MMU). It works just fine for all of those cases. The *only* problem we have at present is that we can no longer update the Jessie systems this was being done on, because our ability to do this was removed and there appears to be no actually working replacement for it. Also since it is a source package change, rebuild outside the archive, one is free to patch it, thankfully the source packaging is open source which one can patch when rebuilding toolchains in the partially new to jessie ways. So ... you're saying that ... if someone manually restores this for themselves, they can have back the only behaviour that has been tested and is known to work (well or at all) for Jessie with m-a, but if it is restored in advance, so our users don't have to do that manually ... then the universe somehow comes to a cataclysmic end? Can you point us to the actual explanation of what *breaks*? The people who have actually been working on this _in Debian_ are well aware of what is not perfect about it and what extra work remains for post-Jessie to make it more so, and they are actually working on those things. They even have packages based on this uploaded to sid, so that the other work on fixing those things can continue, e.g.: https://packages.debian.org/sid/gcc-4.9-arm-linux-gnueabi What nobody has explained to us is what problem is *fixed* by gratuitously breaking this for existing users of Jessie. Can we all settle and move these developments to experimental targeting for stretch, instead? Nobody is suggesting that other options can't be, or shouldn't be, explored for post-Jessie. Restoring the functionality that existed before this was removed will not in any way prevent or hinder that, it just means we won't repeat the sad state of Wheezy where this became no longer possible at all. Nothing you said here explains why we can't have the best of both worlds with this. If having this working for Jessie is not so relevant to you, that's fine - but it's very relevant to quite a few other people and was working for them until a few weeks ago when support for it was simply removed. We have people prepared to do the work to keep it working. What we don't have is an explanation of what it actually broke, if anything, to warrant removing it, without comment or warning, at this late stage of the Jessie release. This bug report annoys me a lot, given the amount of inaccuracies it has in portraying the current state of the affairs - that is exaggerating the regression, when simply a desired feature by some, failed pear-review was found feature incomplete and was not fully included into jessie. You haven't actually pointed out anything inaccurate that anyone has said here, and having this working is actually a pre-requisite for some of the other work that you're saying isn't yet done, to be done. Yes, it's still a bit more awkward to build a toolchain than we all would like, but this is still infinitely easier and cleaner than anything we've ever had before. What do we gain by denying people the ability to easily use and experiment with that, in real life use cases, while we work on improving the other things too? Can you point us to this pear-review that you say occurred? The only thing I can see is that this functionality was quietly removed on the eve of the freeze, without any discussion with the people working on this _in Debian_, and that trying to discuss that is what led to this going pear-shaped and needing to be escalated to the -ctte for mediation. Given a zero sum game rules, Fortunately, this isn't a zero sum game. We can have the Good now without ruining anyone's chances of making that Perfect later. Why is it in the interest of Debian or the users of Jessie to not (continue to) have that? Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732263: dovecot-core postinst fails on new install when create-ssl-cert is false
Control: severity -1 serious Le lundi, 16 décembre 2013, 06.29:07 Ben Winslow a écrit : If you perform a clean installation of dovecot-core and opt out of self-signed certificate generation, dovecot will fail to start (because dovecot.pem doesn't exist), which will cause the postinst script to fail. If dovecot.pem doesn't exist, ssl support should be disabled (or, at minimum, the postinst script shouldn't fail.) I've just tried to install dovecot-core on a clean jessie VM (freshly installed with the daily d-i); the installation doesn't finish because the postinst fails, because invoke-rc.d dovecot start fails. The systemctl log says that /etc/dovecot/dovecot.pem doesn't exist. Creating the two /etc/dovecot/dovecot.pem /etc/dovecot/private/dovecot.pem through openssl allows the installation to finish. Failure to finish installation is clearly a serious issue, hereby bumping the severity. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#762194: Alternative proposal for init switch on upgrades.
On Sun, 2014-11-23 at 03:10 +0100, Adam Borowski wrote: On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote: I would like to propose a different one. [...] So, the change would be that: the sysvinit package would cease being a transition / shim package, however it would not signal that a user explicitly installed sysvinit; sysvinit-core would be a simple package that just depended on sysvinit, and the presence of this package *would* signal that the user explicitly installed sysvinit; init would (pre-)depend on systemd-sysv | sysvinit | sysvinit-core | upstart. I'm afraid this doesn't allow partial upgrades from wheezy to use systemd-sysv, as sysvinit is an essential package there, and apt considers packages to be essential if they're present in any source. Do people use the usb stick/cd/dvd etc for upgrades to jessie, i.e. the debian installer. Or do they only use apt/aptitude/etc? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768905: FTBFS: fails test CHECK INVALID KEY TYPE
On 23/11/14 03:03, Adam Borowski wrote: On Sun, Nov 23, 2014 at 02:07:42AM +0100, Christian Kastner wrote: On 2014-11-23 01:16, Adam Borowski wrote: On Sat, Nov 22, 2014 at 09:09:55PM +0100, Tomasz Buchert wrote: On 10/11/14 10:56, Christian Kastner wrote: I cannot confirm this bug in both cases I've tried: * amd64 (Linux 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09) x86_64 GNU/Linux) * amrhf (Linux 3.14.4.1-bone-armhf.com #1 SMP Tue Jun 3 12:37:22 UTC 2014 armv7l GNU/Linux) My tests: armhf 3.8.13.28: FTBFS Was this either a Debian or a vanilla kernel? I ask because 3.8 kernels are often vendor-provided variants of certain ARM devices. I have heard myths of ARM devices that can run upstream kernels, but I have yet to see one :p. This one is git://github.com/hardkernel/linux, a pretty well behaved one as vendor kernels go. Guys, I went crazy and tested this assertion. I've upgraded the vendor arm kernel to the testing kernel and guess what - it didn't boot... (I'll have to fix it when I'm back home) That said, one of the Debian developers built it for me on armhf 3.16.3 (slightly newer than the testing kernel) and it went fine. If you still think that it may not work in jessie, you could ask for rebuild (https://release.debian.org/wanna-build.txt). If not, you could downgrade the severity to unblock keyutils for the jessie release (I'm not sure if tagging with +sid will stop it being RC). Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770666: partman-base: partman overwrites parts of u-boot (imx6/am335x)
Vagrant Cascadian vagr...@debian.org (2014-11-22):
Package: partman-base
Version: 179
Severity: important
Tags: patch
Several armhf platforms have u-boot installed directly to the device
in an area which gets wiped out by partman. This results in
debian-installer producing a successful install, but zeros out the
location of the bootloader in the process... so fails to boot.
This was fixed for sunxi/allwinner platforms (see:
https://bugs.debian.org/751704), but other platforms such as imx6
(Wandboard, CuBox-i) and am335x (BeagleBone Black) are still affected
by the issue.
The following proof-of-concept patch may be a little too broad,
affecting all Freescale or AM33XX systems, although it is limited to
installs to /dev/mmcblk0. BeagleBone Black may also need this code
when installing to /dev/mmcblk1...
I've committed it as-is for now, and uploaded partman-base 180.
debian-arm@ people may want to give daily images a shot once a build has
happened with that version.
Thanks!
Mraw,
KiBi.
Essentially it renames the is_sunxi_system to
is_system_with_firmware_on_disk, and adds cases for the additional
platforms.
diff --git a/parted_server.c b/parted_server.c
index 808a85f..e9e72a0 100644
--- a/parted_server.c
+++ b/parted_server.c
@@ -1330,9 +1330,10 @@ command_dump()
oprintf(OK\n);
}
-/* Check whether we are running on a sunxi-based system. */
+/* Check whether we are running on a sunxi-based, freescale-based, or
+ AM33XX (beaglebone black) system. */
int
-is_sunxi_system()
+is_system_with_firmware_on_disk()
{
int cpuinfo_handle;
int result = 0;
@@ -1345,6 +1346,10 @@ is_sunxi_system()
buf[length]='\0';
if (strstr(buf, Allwinner) != NULL)
result = 1;
+else if (strstr(buf, Freescale) != NULL)
+result = 1;
+else if (strstr(buf, AM33XX) != NULL)
+result = 1;
}
close(cpuinfo_handle);
}
@@ -1365,9 +1370,9 @@ command_commit()
* the firmware area, resulting in an unbootable system (see
* bug #751704).
*/
-if (is_sunxi_system() !strcmp(disk-dev-path, /dev/mmcblk0)) {
+if (is_system_with_firmware_on_disk() !strcmp(disk-dev-path,
/dev/mmcblk0)) {
disk-needs_clobber = 0;
-log(Sunxi platform detected. Disabling ped_disk_clobber \
+log(Sunxi/Freescale/AM33XX detected. Disabling
ped_disk_clobber \
for the boot device %s to protect the firmware \
area., disk-dev-path);
}
Thanks for considering!
live well,
vagrant
signature.asc
Description: Digital signature
Bug#768905: FTBFS: fails test CHECK INVALID KEY TYPE
On 2014-11-23 12:35, Tomasz Buchert wrote: On 23/11/14 03:03, Adam Borowski wrote: On Sun, Nov 23, 2014 at 02:07:42AM +0100, Christian Kastner wrote: On 2014-11-23 01:16, Adam Borowski wrote: My tests: armhf 3.8.13.28: FTBFS Was this either a Debian or a vanilla kernel? I ask because 3.8 kernels are often vendor-provided variants of certain ARM devices. I have heard myths of ARM devices that can run upstream kernels, but I have yet to see one :p. This one is git://github.com/hardkernel/linux, a pretty well behaved one as vendor kernels go. Guys, I went crazy and tested this assertion. I've upgraded the vendor arm kernel to the testing kernel and guess what - it didn't boot... (I'll have to fix it when I'm back home) Oh, I should have warned you, sorry! What I forgot to say was that generally speaking, if it's not a bug that can be reproduced with a Debian kernel or vanilla kernel of the same version(in a QEMU VM, for instance) , I'm going to go by experience assume that it's a bug in the vendor kernel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759424: di-netboot-assistant: please update package for jessie / new syslinux
Control: tag -1 moreinfo
Hi Jonas and Andreas,
Jonas Smedegaard d...@jones.dk (2014-11-21):
Package: di-netboot-assistant
Followup-For: Bug #759424
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Attached is a patch believed to fix all issues related to new syslinux:
* Lookup pxelinux.0 in /usr/lib/PXELINUX (not only /usr/lib/syslinux).
* Lookup only BIOS binaries (not accidentally include EFI binaries).
* Install core modules at tftpd root dir.
* Keep vesamenu and menu modules in sync with PXELINUX.
thank you both for providing patches to di-netboot-assistant; is there
any chance you could submit a branch or patch series against its git
repository (git://anonscm.debian.org/d-i/netboot-assistant.git)?
Of course I could try and split up your patches into atomic commits, but
I guess it'd be better if knowledgeable could document patches. There's
of course the part where Andreas had to patch a bit more what Jonas
provided, so cross-checking each other would be nice.
Mraw,
KiBi.
- Jonas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQF8BAEBCgBmBQJUbnZLXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWlDkH/2evg6qc0Jf8Ho/BHtNw8uEZ
MVMUq4+xD+ziLDSSVKfFCfn17SnypXLxPzDBVQ4SoLv1W6+AnTHs5ExaQ2KzgJZy
9qJueFkpDGBY0G6A/IUqjwTEvmN5L0FS4MxjACbswNIlCnkvnlixVnhxNonF5kS5
q6fkbJ+M9XZNYxaMJN9croUV7KsnOGZhVJg6Rk7Mu3FUv4xzhY3+U0HHV1by2TI3
H9qNvC1/DVJ/8oGgFgu39G5cDdSMW8kyhebE5r6X+HP7g8zJT4EYIfeaP+gBQO0g
ZYU0GUw0fshmEKmosXw77EUtvAcXQzfytprDsMEVrP179dTHW1Q5RjfW7ggYrWE=
=m57Q
-END PGP SIGNATURE-
--- di-netboot-assistant.orig 2013-07-13 10:31:11.0 +0200
+++ di-netboot-assistant 2014-11-20 22:50:18.151437802 +0100
@@ -200,12 +200,13 @@
# #
# find_file()
#Return the name of the first file matching criteria.
-# Parameters: dir name
+# Parameters: name dir [dir...]
# Returns: (STRING) file
# #
find_file() {
if [ $1 -a $2 ]; then
- find $2 -type f -name $1 | head -n 1
+ local name=$1; shift
+ find $@ -type f -name $name | head -n 1
else
echo
fi
@@ -241,7 +242,14 @@
[ ! $src -o ! $dst ] return 1
- newbin=$(find_file pxelinux.0 $src 2/dev/null)
+ if [ $SYSLINUX = $src ]; then
+ # avoid recent SYSLINUX EFI binaries incompatible with PXELINUX
+ [ ! -d $src/modules/bios ] || src=$src/modules/bios
+ # recent SYSLINUX ships PXELINUX at separate location
+ newbin=$(find_file pxelinux.0 /usr/lib/PXELINUX $SYSLINUX
2/dev/null)
+ else
+ newbin=$(find_file pxelinux.0 $src 2/dev/null)
+ fi
[ ! -f $dst/pxelinux.0 -a ! -f $newbin ] return 1
pxe_new_ver=$(pxelinux_version $newbin)
@@ -253,7 +261,11 @@
echo I: Upgrading PXELinux ($pxe_cur_ver to $pxe_new_ver)
for f in pxelinux.0 menu.c32 vesamenu.c32; do
- srcf=$(find_file $f $src)
+ if [ pxelinux.0 = $f ]; then
+ srcf=$newbin
+ else
+ srcf=$(find_file $f $src)
+ fi
[ ${f#*c32} ] || f=pxelinux.cfg/$f
[ -L $dst/$f ] rm $dst/$f
if [ -f $srcf ]; then
@@ -264,6 +276,13 @@
done
# Smooth transition to vesamenu
[ ! -f $c32_dir/menu.c32 ] ln -s vesamenu.c32 $c32_dir/menu.c32
+ # Add core modules at root (see https://bugs.debian.org/756275#49)
+ if [ $TFTP_ROOT/debian-installer/ = $dst ]; then
+ for f in ldlinux.c32 libcom32.c32 libutil.c32; do
+ srcf=$(find_file $f $src)
+ [ -z $srcf ] || cp -np $srcf $TFTP_ROOT/$f
+ done
+ fi
return 0
}
@@ -907,6 +926,21 @@
if ! copy_syslinux_bin $expand_dir $TFTP_ROOT/debian-installer/ ;
then
echo E: No PXELinux menu installed. Please file a bug. 12
fi
+ # ensure only a single PXELINUX version is used for all its modules
+ for f in $(find $expand_dir -type f -name '*.c32'); do
+ case $(basename $f) in
+ vesamenu.c32|menu.c32)
+ cp -pft $(dirname $f)
$TFTP_ROOT/debian-installer/pxelinux.cfg/$(basename $f)
+ ;;
+ ldlinux.c32|libcom32.c32|libutil.c32)
+ cp -pft $(dirname $f) $TFTP_ROOT/$(basename $f)
+ ;;
+ *)
+ echo W: Unusual PXELINUX module \$f\ may not work.
12
+ continue
+ ;;
+ esac
+ done
for f in $(find $expand_dir -type f -a \( -name default -o -name
boot.txt -o -name '*.cfg' \) ); do
mv $f $f.ORIG
Mraw,
KiBi.
Bug#770698: apt: wants to install systemd packages on wheezy system with testing at lower priority
Package: apt Version: 0.9.7.9+deb7u6 Severity: important Dear maintainer, I added Jessie as a installation source at lower priority to my wheezy server VM. It seems owncloud seems to be removed from testing[1]. To have updated owncloud packages with all security fixes, I can either go for upstream packages or to testing packages. I decided for the later according to a recommendation[2]. In order to not have every package in wheezy-backports upgraded to testing I made sure that wheezy-backports is pinned above testing. That way there should not be any upgrades to the system unless I explicitely ask for them. And aptitude agrees: mondschein:~ LANG=C aptitude dist-upgrade No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. Yet apt-get insists otherwise: mondschein:~ LANG=C apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. mondschein:~ LANG=C apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following NEW packages will be installed: libaudit0 libcryptsetup4 libpam-systemd libsystemd-daemon0 libsystemd-id128-0 libsystemd-journal0 libsystemd-login0 systemd 0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/1765 kB of archives. After this operation, 4573 kB of additional disk space will be used. Do you want to continue [Y/n]? n Abort. This seems to be broke for me in two ways: 1) On the apt upgrade those systemd packages are not shown as held back. 2) It has no business to install these anyway. None of the packages is currently installed and surely wheezy is priority 500 and testing is priority 150. So no business to install these. Even when I lower testing priority to 100 it insists to install these. daemon0 libsystemd-id128-0 libsystemd-journal0 libsystemd-login0 systemd ; do LANG=C apt-cache policy $PACKAGE; done libaudit0: Installed: (none) Candidate: 1:1.7.18-1.1 Version table: 1:1.7.18-1.1 0 500 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages libcryptsetup4: Installed: (none) Candidate: 2:1.4.3-4 Version table: 2:1.6.6-3 0 150 http://ftp.de.debian.org/debian/ jessie/main i386 Packages 2:1.6.4-4~bpo70+1 0 200 http://ftp.de.debian.org/debian/ wheezy-backports/main i386 Packages 2:1.4.3-4 0 500 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages libpam-systemd: Installed: (none) Candidate: 44-11+deb7u4 Version table: 215-5+b1 0 150 http://ftp.de.debian.org/debian/ jessie/main i386 Packages 204-14~bpo70+1 0 200 http://ftp.de.debian.org/debian/ wheezy-backports/main i386 Packages 44-11+deb7u4 0 500 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages 500 http://security.debian.org/ wheezy/updates/main i386 Packages libsystemd-daemon0: Installed: (none) Candidate: 44-11+deb7u4 Version table: 215-5+b1 0 150 http://ftp.de.debian.org/debian/ jessie/main i386 Packages 204-14~bpo70+1 0 200 http://ftp.de.debian.org/debian/ wheezy-backports/main i386 Packages 44-11+deb7u4 0 500 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages 500 http://security.debian.org/ wheezy/updates/main i386 Packages libsystemd-id128-0: Installed: (none) Candidate: 44-11+deb7u4 Version table: 215-5+b1 0 150 http://ftp.de.debian.org/debian/ jessie/main i386 Packages 204-14~bpo70+1 0 200 http://ftp.de.debian.org/debian/ wheezy-backports/main i386 Packages 44-11+deb7u4 0 500 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages 500 http://security.debian.org/ wheezy/updates/main i386 Packages libsystemd-journal0: Installed: (none) Candidate: 44-11+deb7u4 Version table: 215-5+b1 0 150 http://ftp.de.debian.org/debian/ jessie/main i386 Packages 204-14~bpo70+1 0 200 http://ftp.de.debian.org/debian/ wheezy-backports/main i386 Packages 44-11+deb7u4 0 500 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages 500 http://security.debian.org/ wheezy/updates/main i386 Packages libsystemd-login0: Installed: (none) Candidate: 44-11+deb7u4 Version table: 215-5+b1 0 150 http://ftp.de.debian.org/debian/ jessie/main i386 Packages 204-14~bpo70+1 0 200 http://ftp.de.debian.org/debian/ wheezy-backports/main i386 Packages 44-11+deb7u4 0 500 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages 500 http://security.debian.org/ wheezy/updates/main i386 Packages systemd: Installed: (none) Candidate: 44-11+deb7u4 Version table: 215-5+b1 0 150 http://ftp.de.debian.org/debian/ jessie/main i386 Packages
Bug#730828: fixed in dovecot 1:2.2.13-6
Hi Jaldhar, hi dovecot maintainers, Le dimanche, 26 octobre 2014 17.04:27, vous avez écrit : * [e393868] Removed SSL certificate generation from postinst. From now on you have to do this yourself. See dovecot-core's README.debian for instructions. (Closes: #730828) This change makes dovecot-core's postinst fail to finish on initial installation (because of missing certificates), see #732263 and #770695. I suggest to either re-add SSL certificate generation in the dovecot packaging (I don't really get why it got removed, frankly), or disable SSL in the initial dovecot-core configuration. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#768905: FTBFS: fails test CHECK INVALID KEY TYPE
(Tomasz, apparently I forgot to CC you on this mail yesterday, sorry) On 2014-11-23 02:55, Christian Kastner wrote: On 2014-11-23 01:16, Adam Borowski wrote: amd64 vanilla 3.16.7: builds ok amd64 vanilla 3.17.3: FTBFS I can confirm that is issue exists with 3.17. The syscall is returning ENOKEY where until 3.16 it was returning EPERM. I am now quite certain that the issue is being caused by this kernel commit in 3.17: Commit: a4e3b8d79a5c6d40f4a9703abf7fe3abcc6c3b8d KEYS: special dot prefixed keyring name bug fix The thing is, I'm not sure whether this needs to be fixed in keyutils, or in the kernel. I now contacted upstream about this. Depending on the answer, I'll either fix keyutils, or reassign to src:linux. Either way, I tagged this sid as it can only appear with a kernel that will not be part of Jessie. So that should solve the RC problem, no? Thank you for all your work, guys! Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770699: mlocate: please ship db.h as /usr/include/mlocate_db.h
Package: mlocate Version: 0.26-1 Severity: wishlist Dear Maintainer, Please ship db.h as /usr/include/mlocate_db.h This files only weights 2714 bytes, so it's not interresting to build an independant mlocate-dev package. I need it to read mlocate binary database dirrectly for speed. I guess some other users might want to do the same. I currently ship a local copy in my database, but it seems against the spirit of the policy: https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles The 'sudo' package do the same with /usr/include/sudo_plugin.h . Here is my ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770445 Goal is to solve this long-standing bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429602 Thanks, Alexandre Detiste -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mlocate depends on: ii adduser 3.113+nmu3 ii libc62.19-13 mlocate recommends no packages. mlocate suggests no packages. -- Configuration Files: /etc/updatedb.conf changed: PRUNE_BIND_MOUNTS=yes PRUNEPATHS=/tmp /media PRUNEFS=NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs devtmpfs mfs shfs sysfs cifs lustre tmpfs usbfs udf fuse.glusterfs fuse.sshfs curlftpfs -- 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#770214: source tarball should not be compressed with xz
Control: tag -1 patch pending Joey Hess i...@joeyh.name (2014-11-19): Package: debootstrap Version: 1.0.64 Severity: normal xz is not a common format, and this makes it unncessarily difficult to install debootstrap from source on unfamiliar linux systems. The space savings are miniscule. Please switch to a tar.gz. Thanks for the report, master has a patch: | dpkg-source -i -I -b debootstrap | dpkg-source: info: using options from debootstrap/debian/source/options: --compression=gzip | dpkg-source: info: using source format `3.0 (native)' | dpkg-source: info: building debootstrap in debootstrap_1.0.65.tar.gz | dpkg-source: info: building debootstrap in debootstrap_1.0.65.dsc http://anonscm.debian.org/cgit/d-i/debootstrap.git/commit/?id=777f456324cf4f9f68dbad75853973741aa2872f Mraw, KiBi. signature.asc Description: Digital signature
Bug#429602: cruft: replace find by locate
Hi, Please have a look at my ITP for cruft-ng: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770445 This is a rewrite of cruft in C. It reads mlocate binary database dirreclty to achieve a 15x - 30x speed-up. Any comments welcome Alexandre Detiste -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770700: unblock: wordpress/4.0.1+dfsg-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package wordpress
Wordpress 4.0 which is currently in Jessie has several
security bugs, see upstream announcement at
https://wordpress.org/news/2014/11/wordpress-4-0-1/
for details. Security bug is #770425.
The Debian 4.0.1+dfsg-1 package is *only* this upstream
change, I have no fixed anything else in order to give
the smallest delta to what we already have. I not that
the debdiff shows libphp-phpmailer version bump but
version 5.2.9+dfsg-2 is in jessie so there's no problem there.
- Craig
unblock wordpress/4.0.1+dfsg-1
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
File lists identical (after any substitutions)
Control files of package wordpress: lines which differ (wdiff format)
-
Depends: apache2 | httpd, libapache2-mod-php5 | php5, ca-certificates,
mysql-client | mariadb-client, php5-gd, php5-mysql | php5-mysqlnd,
wordpress-theme-twentyfourteen, libjs-cropper (= 1.2.2), libphp-phpmailer (=
[-5.2.8+dfsg),-] {+5.2.9+dfsg),+} libphp-snoopy (= 1.2.4)
Installed-Size: [-15462-] {+15468+}
Version: [-4.0+dfsg-1-] {+4.0.1+dfsg-1+}
Control files of package wordpress-l10n: lines which differ (wdiff format)
--
Depends: wordpress (= [-4.0+dfsg-1)-] {+4.0.1+dfsg-1)+}
Version: [-4.0+dfsg-1-] {+4.0.1+dfsg-1+}
Control files of package wordpress-theme-twentyfourteen: lines which differ
(wdiff format)
--
Version: [-4.0+dfsg-1-] {+4.0.1+dfsg-1+}
Control files of package wordpress-theme-twentythirteen: lines which differ
(wdiff format)
--
Installed-Size: [-638-] {+639+}
Version: [-4.0+dfsg-1-] {+4.0.1+dfsg-1+}
Control files of package wordpress-theme-twentytwelve: lines which differ
(wdiff format)
Version: [-4.0+dfsg-1-] {+4.0.1+dfsg-1+}
Bug#762399: console-setup: WARNING: Unknown X keysym permille
2014-10-07 20:17 GMT+03:00 Martin-Éric Racine martin-eric.rac...@iki.fi: 2014-10-07 18:52 GMT+03:00 Anton Zinoviev an...@lml.bas.bg: On Mon, Sep 22, 2014 at 12:33:25AM +0300, Martin-Éric Racine wrote: Setting up console-setup (1.113) ... WARNING: Unknown X keysym permille WARNING: Unknown X keysym permille WARNING: Unknown X keysym permille WARNING: Unknown X keysym permille WARNING: Unknown X keysym ezh WARNING: Unknown X keysym EZH WARNING: Unknown X keysym ezh WARNING: Unknown X keysym EZH WARNING: Unknown X keysym ezh WARNING: Unknown X keysym EZH WARNING: Unknown X keysym ezh WARNING: Unknown X keysym EZH Setting up libprotobuf9:i386 (2.6.0-3) ... Could this be caused by ckbcomp's built-in (X keysym - kernel keysym) table missing these? Yes. Alright. Would it be possible to re-generate that symbol table and fix the issue? :) Thanks for fixing the issue in 1.115. However, the package is currently blocked because of the freeze and it would need an unblock request to propagate into Testing. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-dist
Bug#759424: di-netboot-assistant: please update package for jessie / new syslinux
Quoting Cyril Brulebois (2014-11-23 12:49:58) Jonas Smedegaard d...@jones.dk (2014-11-21): Attached is a patch believed to fix all issues related to new syslinux: * Lookup pxelinux.0 in /usr/lib/PXELINUX (not only /usr/lib/syslinux). * Lookup only BIOS binaries (not accidentally include EFI binaries). * Install core modules at tftpd root dir. * Keep vesamenu and menu modules in sync with PXELINUX. thank you both for providing patches to di-netboot-assistant; is there any chance you could submit a branch or patch series against its git repository (git://anonscm.debian.org/d-i/netboot-assistant.git)? Of course I could try and split up your patches into atomic commits, but I guess it'd be better if knowledgeable could document patches. There's of course the part where Andreas had to patch a bit more what Jonas provided, so cross-checking each other would be nice. Sure thing: I will prepare git commits. I am puzzled why you needed that change, Andreas. Perhaps it depend on the versions of syslinux involved. I tested on Jessie, with stable, testing and daily for amd64 and i386 - what did you test? Or perhaps it is related to choice and configuration of tftpd. I use tftpd-hpa with TFTP_OPTIONS=--blocksize 1468 -v -v -v -v --secure and adapting di-netboot-assistant to use /srv/tftp. Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#766670: Security fix without feature enhancement for 4.32.0 and 4.20.0
On Sat, 22 Nov 2014, Charles Cazabon wrote:
I hope Debian can simply accept the newer version of getmail; as I said, I try
The next stable version of Debian (aka jessie) has getmail 4.46.0.
We also have an official backports archive, and it will also have getmail
4.46.0 in a few days. This won't automatically update any of the users of
current Debian stable (aka wheezy) to 4.46.0, but they can manually do so
if they so wish.
However, to get current Debian stable (wheezy) users automatically updated
to 4.46.0, we need a so called stable-update. This needs an OK from the
stable release managers, and the non-trivial changes from 4.32.0 to 4.46.0
are a problem.
The key issue here is risk of regression. I have not seen any
regressions, and I have been using a 4.46.0 backport for a while already,
but we need to convince the stable release manager that the benefits of
going from 4.32.0 to 4.46.0 are worth the risk of regression, and that these
risks are low.
For the record, attached is an unified diff with the relevant (i.e.
excluding documentation) changes between 4.32.0 and 4.46.0.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
diff -ru getmail-4.32.0/docs/CHANGELOG getmail-4.46.0/docs/CHANGELOG
diff -ru getmail-4.32.0/docs/configuration.html getmail-4.46.0/docs/configuration.html
diff -ru getmail-4.32.0/docs/configuration.txt getmail-4.46.0/docs/configuration.txt
diff -ru getmail-4.32.0/docs/documentation.txt getmail-4.46.0/docs/documentation.txt
diff -ru getmail-4.32.0/docs/faq.html getmail-4.46.0/docs/faq.html
diff -ru getmail-4.32.0/docs/faq.txt getmail-4.46.0/docs/faq.txt
diff -ru getmail-4.32.0/docs/getmail.1 getmail-4.46.0/docs/getmail.1
diff -ru getmail-4.32.0/docs/troubleshooting.txt getmail-4.46.0/docs/troubleshooting.txt
diff -ru getmail-4.32.0/getmail getmail-4.46.0/getmail
--- getmail-4.32.0/getmail 2012-06-20 00:44:15.0 -0300
+++ getmail-4.46.0/getmail 2014-04-07 00:24:46.0 -0300
@@ -14,6 +14,18 @@
import pprint
from optparse import OptionParser, OptionGroup
import socket
+import signal
+
+# Optional gnome-keyring integration
+try:
+import gnomekeyring
+import glib
+glib.set_application_name('getmail')
+# And test to see if it's actually available
+if not gnomekeyring.is_available():
+gnomekeyring = None
+except ImportError:
+gnomekeyring = None
options_bool = (
'read_all',
@@ -22,9 +34,11 @@
'received',
'message_log_verbose',
'message_log_syslog',
+'fingerprint',
)
options_int = (
'delete_after',
+'delete_bigger_than',
'max_message_size',
'max_messages_per_session',
'max_bytes_per_session',
@@ -45,7 +59,7 @@
logging
from getmailcore.exceptions import *
from getmailcore.utilities import eval_bool, logfile, format_params, \
-address_no_brackets, expand_user_vars
+address_no_brackets, expand_user_vars, get_password
except ImportError, o:
sys.stderr.write('ImportError: %s\n' % o)
sys.exit(127)
@@ -62,6 +76,7 @@
'read_all' : True,
'delete' : False,
'delete_after' : 0,
+'delete_bigger_than' : 0,
'max_message_size' : 0,
'max_messages_per_session' : 0,
'max_bytes_per_session' : 0,
@@ -71,8 +86,21 @@
'message_log_verbose' : False,
'message_log_syslog' : False,
'logfile' : None,
+'fingerprint' : False,
}
+
+
+
+###
+def convert_to_sigint(unused1, unused2):
+Catch a SIGTERM and raise a SIGINT so getmail exits normally and does
+cleanup if killed with default signal.
+
+raise KeyboardInterrupt('from signal')
+
+signal.signal(signal.SIGTERM, convert_to_sigint)
+
###
def blurb():
log.info('getmail version %s\n' % __version__)
@@ -80,7 +108,7 @@
'GNU GPL version 2.\n')
###
-def go(configs):
+def go(configs, idle):
Main code.
Returns True if all goes well, False if any error condition occurs.
@@ -88,7 +116,27 @@
blurb()
summary = []
errorexit = False
+idling = False
+
+if len(configs) 1 and idle:
+log.info('more than one config file given with --idle, ignoring\n')
+idle = False
+
for (configfile, retriever, _filters, destination, options) in configs:
+if options['read_all'] and not options['delete']:
+if idle:
+# This is a nonsense combination of options; every time the
+# server returns from IDLE, all messages will be re-retrieved.
+log.error('%s: IDLE, read_all, and not delete - bad '
+ 'combination, skipping\n'
+ % retriever)
+continue
+else:
+# Slightly less nonsensical,
Bug#770701: unblock: libvirt/1.2.9-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libvirt
The changes are:
Help package managers and users to cope with the libvirt-bin -
{libvirt-daemon-system, libvirt-daemon} package split:
* [fb4bf47] Add suggests to libvirt-daemon-system to libvirt-daemon
(Closes: #767343)
Clean's up a piuparts error:
* [e4f03ca] Check if the directories exist before removing them
rmdir returns nonzero otherwise and this is more strict than just using
|| true. (Closes: #767672)
Security fix:
* [030fd97] CVE-2014-7823: dumpxml: security hole with migratable flag
(Closes: #769149)
To ease backports:
* [4cdad47] Allow backported versions of dh-systemd
There are some more pending issues for jessie like bugs in the lxc,
xen and vbox driver but I'd like to give them some more testing before
letting them enter jessie so I'd be awesome to have these changes
already unblocked.
unblock libvirt/1.2.9-4
Cheers,
-- Guido
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable'),
(1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-rc6 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff --git a/debian/changelog b/debian/changelog
index cf256c7..a639322 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+libvirt (1.2.9-4) unstable; urgency=medium
+
+ * [4cdad47] Allow backported versions of dh-systemd
+ * [fb4bf47] Add suggests to libvirt-daemon-system to libvirt-daemon
+(Closes: #767343)
+ * [e4f03ca] Check if the directories exist before removing them
+rmdir returns nonzero otherwise and this is more strict than just using
+|| true. (Closes: #767672)
+ * [030fd97] CVE-2014-7823: dumpxml: security hole with migratable flag
+(Closes: #769149)
+
+ -- Guido Günther a...@sigxcpu.org Wed, 12 Nov 2014 08:11:17 +0100
+
libvirt (1.2.9-3) unstable; urgency=medium
* [28dd361] Remove obsolete conffiles in libvirt-bin too. Depending on the
diff --git a/debian/control b/debian/control
index 59b0910..4e2cd0e 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Debian Libvirt Maintainers
pkg-libvirt-maintain...@lists.alioth.deb
Uploaders: Guido Günther a...@sigxcpu.org, Laurent Léonard
laur...@open-minds.org
Build-Depends:
debhelper (= 7),
- dh-systemd (= 1.18),
+ dh-systemd (= 1.18~),
libxml2-dev,
libncurses5-dev,
libreadline-dev,
@@ -89,6 +89,8 @@ Depends:
Section: admin
Replaces: libvirt-bin ( 1.2.6-1~)
Conflicts: libvirt-bin ( 1.2.6-1~)
+Suggests:
+ libvirt-daemon,
Description: programs for the libvirt library
Libvirt is a C toolkit to interact with the virtualization capabilities
of recent versions of Linux (and other OSes). The library aims at providing
@@ -109,6 +111,8 @@ Recommends:
qemu-kvm | qemu (= 0.9.1),
libxml2-utils,
netcat-openbsd,
+Suggests:
+ libvirt-daemon-system,
Description: programs for the libvirt library
Libvirt is a C toolkit to interact with the virtualization capabilities
of recent versions of Linux (and other OSes). The library aims at providing
diff --git a/debian/libvirt-daemon-system.postrm
b/debian/libvirt-daemon-system.postrm
index 2499c8a..62d9b4b 100644
--- a/debian/libvirt-daemon-system.postrm
+++ b/debian/libvirt-daemon-system.postrm
@@ -37,14 +37,15 @@ case $1 in
rm -rf /var/log/libvirt \
/var/cache/libvirt/qemu/capabilities
- # Clean up created dirs if emtpy, they contain
- # precious data otherwise
- rmdir --ignore-fail-on-non-empty \
- /var/lib/libvirt/qemu/save \
- /var/lib/libvirt/qemu/snapshot \
- /var/lib/libvirt/qemu/dump \
- /var/lib/libvirt/qemu \
- /var/cache/libvirt/qemu
+ # Clean up created dirs if existend and emtpy, they contain precious
+ # data otherwise
+ for dir in /var/lib/libvirt/qemu/save \
+ /var/lib/libvirt/qemu/snapshot \
+ /var/lib/libvirt/qemu/dump \
+ /var/lib/libvirt/qemu \
+ /var/cache/libvirt/qemu; do
+ [ ! -d $dir ] || rmdir --ignore-fail-on-non-empty $dir
+ done
;;
remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
;;
diff --git
a/debian/patches/security/CVE-2014-7823-dumpxml-security-hole-with-migratable-.patch
b/debian/patches/security/CVE-2014-7823-dumpxml-security-hole-with-migratable-.patch
new file mode 100644
index 000..a22a1e3
--- /dev/null
+++
b/debian/patches/security/CVE-2014-7823-dumpxml-security-hole-with-migratable-.patch
@@ -0,0 +1,64 @@
+From: Eric Blake ebl...@redhat.com
+Date: Thu, 6 Nov 2014 09:42:24 +0100
+Subject: CVE-2014-7823: dumpxml: security hole with migratable flag
+
+Commit 28f8dfd
Bug#769072: Bug#770588: Bug#769072: #769191, #770588: nvidia-opencl-icd breaking non-nvidia systems
guys, sorry to ask, but there's no link: how to unsubscribe ? On 23/11/2014 08:35, Rebecca N. Palmer wrote: Rebecca Palmerr wrote: The only other [than pyopencl] Depends or Recommends on opencl-icd in the current archive is bfgminer. Sorry...only ones found by path:debian/control opencl-icd in sources.debian.net search (apt-cache rdepends doesn't work on virtual packages), which evidently doesn't search non-free as it missed that nvidia-libopencl1 Recommends: nvidia-opencl-icd. Nathaniel Smith wrote: Looking through my apt history, it looks like the critical operation that gave me nvidia stuff was the installation of libboost[-all-dev] (!?): libboost-all-dev Depends: libboost-mpi-dev Depends: libboost-mpi1.55-dev Depends: libboost-mpi1.55.0 Depends: libhwloc5 Recommends: libhwloc-plugins, which at the time had Depends: libopencl-1.1-1, a virtual package provided by (among other things) nvidia-libopencl1, which Recommends: nvidia-opencl-icd. This has already been reported (#739409) and fixed: libhwloc-plugins now Depends: ocl-icd-libopencl1 | libopencl-1.1-1. However, cutting the chain there doesn't remove nvidia-opencl-icd if already installed, hence this bug. On 23/11/14 02:09, Andreas Beckmann wrote: I don't know how seriously the missing libcuda1 breaks nvidia-opencl-icd. I can see that this is being dlopen()ed, but at least clinfo still reports something about the GPU. I don't have a better testcase right now, suggestions welcome. If you want a quick does OpenCL work test, try python3 accuracy_speed_test.py (from https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=accuracy_speed_test.py;att=1;bug=768090 , Depends: python3-pyopencl, python3-scipy ). (Note that some of those tests are expected to give high/NaN errors because not all the inputs used are valid for all the functions: for the present purpose we're mainly looking for crashes/exceptions.) Given that we also don't want to break systems that are intentionally using nvidia-opencl-icd, a better fix might be for whatever sets nvidia as default graphics provider to only do so if the hardware is present, but I don't know whether that's practical. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770635: linux: [armhf/armmp] Add udeb modules to support video and keyboard for imx6
Control: tag -1 +pending On Sat, 2014-11-22 at 12:40 -0800, Vagrant Cascadian wrote: I believe adding the following modules to the fb-modules and usb-modules udebs should allow this to work for hd-media (and possibly netboot as well). I've committed the patch to the pkg-kernel svn. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760414: [ola] Some sources are not included in your package
On Sat, Nov 22, 2014 at 12:08:38PM -0500, Scott Kitterman wrote: On November 22, 2014 5:57:56 AM EST, Wouter Verhelst wou...@debian.org wrote: On Fri, Nov 21, 2014 at 07:12:53AM -0500, Scott Kitterman wrote: Your analysis is rather different than that of the FTP Team. See https://lists.debian.org/msgid-search/1948618.u6YZvnFvaf@scott-latitude-e6320 Please readjust the severity back to serious. That is the correct value. I have explained my opinion in https://lists.debian.org/debian-devel/2014/05/msg00191.html: the source *is* in Debian, just in a different source package. The actual code, used by the package when installed, is used from that different source package. This is no different from something using the Built-Using header. The minified javascript library is a convenience copy of free software, but can be exchanged by another copy or implementation of the exact same functionality, as I assert by symlinking the actually-used file from the file system. I remain unconvinced that removing something from a source package that is shipped identically elsewhere in Debian is useful to our users, our upstreams, our maintainers, or free software in general. Please explain to me how it is, before asserting that I'm wrong. Just to make sure I understand you correctly: The way I read what you are saying is that you believe binary only artifacts used for the upstream build system as embedded convenience copies are okay as long as some version of the source for it exists somewhere in the archive? Is that right? Close, but not entirely. First of all, I wouldn't call minified javascript a binary. I agree that it's not source, but that doesn't imply it's a binary (that is orthogonal to my point, but I want to point that out). Obviously what is in main needs to be DFSG-free; that implies it needs to have source available. But nowhere in the DFSG do I see a strict requirement that the said source is part of the same source package. The fact that we have Built-Using would suggest the same; it shows that there are other cases where a source package does not contain the full source to a program. This case is the same as when we deal with a convenience copy of a library that ships with a program: you don't need to remove the convenience copy, but you do need to ensure it isn't used. That's what I'm doing here, too: the convenience copy remains, but the binary package does not use it. So in my reading of our rules, that's fine. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770680: collectd: please backport fix for segfault in lvm.c
forcemerge 747093 770680 thanks On Sun, Nov 23, 2014 at 10:23:05AM +0100, Marc Fournier wrote: A fix for #747093 is available upstream. I believe it should be included in the package shipped with jessie, as it prevents collectd from crashing in a pretty common situation. This patch will be part of upcoming bugfix release 5.4.2 and can be retrieved at this address: https://github.com/collectd/collectd/commit/25d7de930baa8a2 Thanks for reporting this. The same issue was also reported in #747093. Cheers, Sebastian -- Sebastian tokkee Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin signature.asc Description: Digital signature
Bug#770701: unblock: libvirt/1.2.9-4
Control: tags -1 moreinfo On 2014-11-23 13:07, Guido Günther wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libvirt The changes are: [...] There are some more pending issues for jessie like bugs in the lxc, xen and vbox driver but I'd like to give them some more testing before letting them enter jessie so I'd be awesome to have these changes already unblocked. unblock libvirt/1.2.9-4 Cheers, -- Guido [...] Unfortunately, libvert/1.2.9-4 FTBFS on several architectures, which is a regression to 1.2.9-3. Until those are resolved, we cannot accept libvirt/1.2.9-4. Sorry, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768816: fwbuilder crashes in libqtgui
On Sun, Nov 23, 2014 at 02:52:29PM +0530, Ritesh Raj Sarraf wrote: But I still get it. Could you record a backtrace in gdb this time? [97180.030109] fwbuilder[20394]: segfault at 8 ip 7f6e92fee438 sp 7fff6845fd40 error 4 in libQtGui.so.4.8.6[7f6e92889000+aa] [100172.428166] fwbuilder[24000]: segfault at 8 ip 7f242d7b1438 sp 7fff52a7eb40 error 4 in libQtGui.so.4.8.6[7f242d04c000+aa] [100553.836676] fwbuilder[24388]: segfault at 8 ip 7fa04d5c6438 sp 7fff412d6bd0 error 4 in libQtGui.so.4.8.6[7fa04ce61000+aa] [100750.725408] fwbuilder[24869]: segfault at 8 ip 7f5d2d19e438 sp 767ff980 error 4 in libQtGui.so.4.8.6[7f5d2ca39000+aa] [101966.094268] fwbuilder[26170]: segfault at 8 ip 7f2739d2e438 sp 7fff58e73290 error 4 in libQtGui.so.4.8.6[7f27395c9000+aa] What makes me wonder is that the issue is only seen with my regular user account. On the same machine, under a different user account (test), fwbuilder works fine. Is it possible that a crash could occur only for a particular user, given that the apps are system shipped ? Maybe it is theming related or so? Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770702: nautilus: New windows do not open
Package: nautilus Version: 3.14.0-1 Severity: normal Using Gnome, sometimes Nautilus windows fail to open. If Nautilus is in the favorites area, when first trying to open a new window, the white gradient appears below it indicate that it is running, but no windows appear. Right clicking on the Nautilus icon in the favorites area and selecting New Window also fails to open a new window for browsing files. The issue can be worked around by quitting nautilus with `nautilus -q` and then restarting it. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.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 nautilus depends on: ii desktop-file-utils 0.22-1 ii gsettings-desktop-schemas 3.14.1-1 ii gvfs 1.22.1-1 ii libatk1.0-02.14.0-1 ii libc6 2.19-13 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libexempi3 2.2.1-2 ii libexif12 0.6.21-2 ii libgail-3-03.14.4-2 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.0-2 ii libglib2.0-data2.42.0-2 ii libgnome-desktop-3-10 3.14.1-1 ii libgtk-3-0 3.14.4-2 ii libnautilus-extension1a3.14.0-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.8-2 ii libpangocairo-1.0-01.36.8-2 ii libselinux12.3-2 ii libtracker-sparql-1.0-01.2.2-2+b1 ii libx11-6 2:1.6.2-3 ii libxml22.9.1+dfsg1-4 ii nautilus-data 3.14.0-1 ii shared-mime-info 1.3-1 Versions of packages nautilus recommends: ii eject 2.1.5+deb1+cvs20081104-13.1 ii gnome-icon-theme-symbolic 3.12.0-1 ii gnome-sushi3.12.0-2 ii gvfs-backends 1.22.1-1 ii librsvg2-common2.40.5-1 Versions of packages nautilus suggests: ii brasero3.11.4-1 ii eog3.14.1-1 ii evince [pdf-viewer]3.14.1-1 ii totem 3.14.0-2 ii tracker1.2.2-2+b1 ii vlc [mp3-decoder] 2.2.0~pre4-2 ii vlc-nox [mp3-decoder] 2.2.0~pre4-2 ii xdg-user-dirs 0.15-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#770701: unblock: libvirt/1.2.9-4
Control: tags -1 + moreinfo On Sun, 2014-11-23 at 13:07 +0100, Guido Günther wrote: Please unblock package libvirt [...] unblock libvirt/1.2.9-4 Unfortunately that's not possible, as -4 FTBFS on most architectures. See #769653 (and the PTS / grep-excuses). 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#555979: debian-policy: Symlinks pointing beyond the root of the file system
On Sun, Nov 23, 2014 at 01:58:41AM +, Anthony Towns wrote: On Sat, Nov 22, 2014 at 12:39:44PM +0500, Andrey Rahmatullin wrote: On Thu, Nov 12, 2009 at 04:31:52PM -0800, Russ Allbery wrote: Lintian has a tag: Tag: symlink-has-too-many-up-segments Severity: serious + Symbolic links must not traverse above the root directory. This isn't listed in https://release.debian.org/jessie/rc_policy.txt I don't see any reason why it should be RC; so s/must/should/ IMO. Is it your position that an issue that cause the FTP masters to reject the package at upload time is not necessarily RC ? Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768905: FTBFS: fails test CHECK INVALID KEY TYPE
On 23/11/14 12:55, Christian Kastner wrote: (Tomasz, apparently I forgot to CC you on this mail yesterday, sorry) On 2014-11-23 02:55, Christian Kastner wrote: On 2014-11-23 01:16, Adam Borowski wrote: amd64 vanilla 3.16.7: builds ok amd64 vanilla 3.17.3: FTBFS I can confirm that is issue exists with 3.17. The syscall is returning ENOKEY where until 3.16 it was returning EPERM. I am now quite certain that the issue is being caused by this kernel commit in 3.17: Commit: a4e3b8d79a5c6d40f4a9703abf7fe3abcc6c3b8d KEYS: special dot prefixed keyring name bug fix The thing is, I'm not sure whether this needs to be fixed in keyutils, or in the kernel. I now contacted upstream about this. Depending on the answer, I'll either fix keyutils, or reassign to src:linux. Either way, I tagged this sid as it can only appear with a kernel that will not be part of Jessie. So that should solve the RC problem, no? Thank you for all your work, guys! Christian My pleasure! I think that this bug is not RC anymore - it is not listed here: https://udd.debian.org/bugs/bugs/bugs/bugs/?release=jessie_and_sidpatch=ignmerged=igndone=ignfnewerval=7rc=1sortby=idsorto=ascctags=1ctags=1cdeferred=1#results Good luck with 3.17 :D - if you need help, let me know. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
On 23 November 2014 at 11:23, Ron r...@debian.org wrote: On Sat, Nov 22, 2014 at 08:51:41PM +, Dimitri John Ledkov wrote: On 22 November 2014 at 16:21, Ron r...@debian.org wrote: Dimitri wrote: Thus multiarch cross tooling is not so relevant for fresh bootstraps, and/or targeting non-debian architectures, or otherwise incomplete systems (e.g. those that do not have compatible set of pre-compiled binaries that use multiarch-paths I'll leave it to Helmut to talk about his existing work with bootstraps that's been stalled by reverting this patch. I can categorically say though that we are currently using a toolchain built this way on Jessie before it was broken by this change, both for embedded systems that do run Debian, and for microcontrollers that couldn't possibly run it (memory measured in kB, no MMU). It works just fine for all of those cases. The *only* problem we have at present is that we can no longer update the Jessie systems this was being done on, because our ability to do this was removed and there appears to be no actually working replacement for it. Also since it is a source package change, rebuild outside the archive, one is free to patch it, thankfully the source packaging is open source which one can patch when rebuilding toolchains in the partially new to jessie ways. So ... you're saying that ... if someone manually restores this for themselves, they can have back the only behaviour that has been tested and is known to work (well or at all) for Jessie with m-a, but if it is restored in advance, so our users don't have to do that manually ... then the universe somehow comes to a cataclysmic end? no, you are mangling my words, and not being constructive with me. I don't know what's your involvement in this is, but I don't like working with you. Please stop. The only behaviour that has been tested and is known to work (well or at all) for Jessie with m-a has been available for a long time, and is unchanged from stable and in testing. Which bit do you not understand from this? And/or any parts of documentation I've sent in the other email? Can you point us to the actual explanation of what *breaks*? The newly introdued mualtiarch cross building in jessie to a few packages: * cannot be build on standard debian buildds * cannot build multilib toolchains * and thus resulting toolchains cannot rebuild non-trivial core debian packages These reasons have been pointed out to the people raising this bug report before. If anyone missed that for any reason, it is pointed out now. I'm not sure if you are deliberately missing portions I've emails that I sent. The people who have actually been working on this _in Debian_ are well aware of what is not perfect about it and what extra work remains for post-Jessie to make it more so, and they are actually working on those things. They even have packages based on this uploaded to sid, so that the other work on fixing those things can continue, e.g.: https://packages.debian.org/sid/gcc-4.9-arm-linux-gnueabi This package is not build on Debian and cannot be ever rebuild on Debian. And RC bug reports are filed. This concrete example is very good way to show that its upload is pre-mature. The reason is quite simple, that we do not have foreign architectures enabled on the builders, nor any easy way to enable them (being or has been fixed in sbuild), however on-demand enabling foreign architectures will not be in place until only after one stable release where it is possible to do so and buildds getting upgraded to such release. What nobody has explained to us is what problem is *fixed* by gratuitously breaking this for existing users of Jessie. The problem is introducing incomplete broken things into archive. E.g. the above uploaded package into sid FTBFS on any release: sid, testing or stable. This is obsurd to call it as actually working, and no changes to gcc-4.X packages will make cross-gcc-4.9-armel finally build from source on debian infrastructure. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766625 Can we all settle and move these developments to experimental targeting for stretch, instead? Nobody is suggesting that other options can't be, or shouldn't be, explored for post-Jessie. Restoring the functionality that existed before this was removed will not in any way prevent or hinder that, it just means we won't repeat the sad state of Wheezy where this became no longer possible at all. Nothing you said here explains why we can't have the best of both worlds with this. If having this working for Jessie is not so relevant to you, that's fine - but it's very relevant to quite a few other people and was working for them until a few weeks ago when support for it was simply removed. We have people prepared to do the work to keep it working. What we don't have is an explanation of what it actually broke, if anything, to
Bug#770665: libxvidcore4: Xvideo not working
Control: reassign -1 mpv Control: retitle -1 mpv: Xvideo output not working On 2014-11-23 00:10:39, rican-linux wrote: Package: libxvidcore4 Version: 2:1.3.3-1 Severity: important Dear Maintainer, I am having with mplayer and mpv using xv as my video out. I am getting the following error [vo/xv] No Xvideo support found. When I run xvinfo I get this: rican-linux@debian-ppc:~$ xvinfo X-Video Extension version 2.2 screen #0 no adaptors present I tried to search the the net for a possilbe solution but I really could not find anything. I am hoping the library I am referencing is the right one. The description of libxvidcore4 is Open source MPEG-4 video codec (library). This has nothing to do with Xvideo output. Re-assigning to mpv. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#770695: Acknowledgement (Dovecot-core unable to finish its installation)
#-done@ Control: severity -1 normal Hello, After some more tests, it appears the vagrant box I used was the root of the problem regarding stuck post-inst process. Sorry for the noise. Cheers, C. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760430: libical: Error in timezone handling
Package: libical1 Version: 1.0-1.1 Followup-For: Bug #760430 I can confirm this issue for my debian system. It would be nice to have this fixed for jessie, as the error is known since August 2013 and a patch exists [1]. In Fedora 20 this has been fixed in November 2013 [2]. [1] http://sourceforge.net/p/freeassociation/code/1150/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1021136 -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libical1 depends on: ii libc6 2.19-13 ii tzdata 2014i-1 libical1 recommends no packages. libical1 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#770703: slapd segfault with memberof overlay on frontend db
Package: slapd
Version: 2.4.31-1+nmu2
Severity: important
Dear Maintainer,
when adding someone to a group and the memberOf overlay is activated in the
frontend slapd crashes with the following stacktrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f5e6be4e700 (LWP 16374)]
0x7f5e7307428c in over_op_func (op=0x7f5e6be4bf90, rs=0x7f5e6be4bdb0,
which=op_aux_chk_controls)
at ../../../../servers/slapd/backover.c:704
704 ../../../../servers/slapd/backover.c: No such file or directory.
(gdb) bt
#0 0x7f5e7307428c in over_op_func (op=0x7f5e6be4bf90, rs=0x7f5e6be4bdb0,
which=op_aux_chk_controls)
at ../../../../servers/slapd/backover.c:704
#1 0x7f5e73014df9 in backend_check_restrictions
(op=op@entry=0x7f5e6be4bf90,
rs=rs@entry=0x7f5e6be4bdb0, opdata=opdata@entry=0x0)
at ../../../../servers/slapd/backend.c:1042
#2 0x7f5e7301e3af in fe_op_modify (op=0x7f5e6be4bf90, rs=0x7f5e6be4bdb0)
at ../../../../servers/slapd/modify.c:252
#3 0x7f5e730741c6 in overlay_op_walk (op=op@entry=0x7f5e6be4bf90,
rs=0x7f5e6be4bdb0, which=op_modify, oi=0x7f5e73cd6b90, on=0x0)
at ../../../../servers/slapd/backover.c:671
#4 0x7f5e7307431b in over_op_func (op=0x7f5e6be4bf90, rs=optimized out,
which=optimized out)
at ../../../../servers/slapd/backover.c:723
#5 0x7f5e7301e569 in fe_op_modify (op=0x7f5e6be4bf90, rs=0x7f5e6be4bdb0)
at ../../../../servers/slapd/modify.c:303
#6 0x7f5e730741c6 in overlay_op_walk (op=op@entry=0x7f5e6be4bf90,
rs=0x7f5e6be4bdb0, which=op_modify, oi=0x7f5e73cd6b90, on=0x0)
at ../../../../servers/slapd/backover.c:671
#7 0x7f5e7307431b in over_op_func (op=0x7f5e6be4bf90, rs=optimized out,
which=optimized out)
at ../../../../servers/slapd/backover.c:723
The last 3 rows are repeated several times (seems to be an endless recursion or
something.
The upstream bug seems to be
http://www.openldap.org/its/index.cgi/Incoming?id=7249
but I'm not sure whether its fixed or not.
My frontend configuration looks like this:
version: 1
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcFrontendConfig
objectClass: olcDatabaseConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=extern
al,cn=auth manage by * break
olcAccess: {1}to dn.exact= by * read
olcAccess: {2}to dn.base=cn=Subschema by * read
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 0
olcMonitoring: FALSE
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
dn: olcOverlay={0}memberof,olcDatabase={-1}frontend,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
olcOverlay: {0}memberof
olcMemberOfDangling: ignore
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
olcMemberOfRefInt: FALSE
-- System Information:
Debian Release: 7.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages slapd depends on:
ii adduser 3.113+nmu3
ii coreutils 8.13-3.5
ii debconf [debconf-2.0] 1.5.49
ii libc6 2.13-38+deb7u6
ii libdb5.15.1.29-5
ii libgcrypt11 1.5.0-5+deb7u2
ii libgnutls26 2.12.20-8+deb7u2
ii libldap-2.4-2 2.4.31-1+nmu2
ii libltdl72.4.2-1.1
ii libodbc12.2.14p2-5
ii libperl5.14 5.14.2-21+deb7u2
ii libsasl2-2 2.1.25.dfsg1-6+deb7u1
ii libslp1 1.2.1-9
ii libwrap07.6.q-24
ii lsb-base4.1+Debian8+deb7u1
ii multiarch-support 2.13-38+deb7u6
ii perl [libmime-base64-perl] 5.14.2-21+deb7u2
ii psmisc 22.19-1+deb7u1
Versions of packages slapd recommends:
ii libsasl2-modules 2.1.25.dfsg1-6+deb7u1
Versions of packages slapd suggests:
pn ldap-utils none
-- debconf information:
slapd/password_mismatch:
slapd/invalid_config: true
shared/organization: skweez.net
slapd/upgrade_slapcat_failure:
slapd/backend: HDB
slapd/dump_database: when needed
slapd/allow_ldap_v2: false
slapd/no_configuration: false
slapd/move_old_database: true
slapd/dump_database_destdir: /var/backups/slapd-VERSION
slapd/purge_database: false
slapd/domain: skweez.net
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758973: [fontconfig-config] Stop breaking user configuration in /etc/fonts/conf.d/ after every upgrade
Control: retitle -1 [fontconfig-config] Removed symlinks in /etc/fonts/conf.d get recreated when the opposite link doesn't exist My previous commands had failed, and I guess that's fine. After discussing this extensively on #debian-devel, the agreement was that this was still failing to comply with policy, so I'm going to leave it at serious and try to fix it. My approach to fix it is: 1) Detect if this is or not a first install (by checking the $2 parameter in the postinst) 2) Detect if this is or not a dpkg-reconfigure run (by checking the $DEBCONF_RECONFIGURE variable) If it's not a new install and it's not a reconfigure run, then the symlinks (or lack of them) shouldn't be touched. -- Regards, Marga -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768163: CUPS and CM option
Hi Joe, hi Till, As you might have seen from this Debian bug (#768163), the Color management option is missing all non-english translations. I must say that I'm quite concerned by this Color management patch for the following reasons: - Debian's now in freeze; adding HTML template patches across 9 languages (without having resources to translate these…) is slightly invasive for this freeze phase. - In https://www.cups.org/str.php?L4462, upstream basically refused to accept your patch on a longer term. I will _not_ adopt the maintenance of this patch as Debian maintainer, so that questions the long-term maintainability of this patch. - There's still #763517 about a failure to work correctly (which is arguably in need of more info from the submitter). I'm now considering either of these options: a) Leave it as-is for Jessie; this leaves CUPS in jessie with no non- english translations for this feature at the advantage of not needing much work. I'm still questioning the responsibility for that patch over the course of the jessie stable release lifecycle. b) Patch 9 translations with english content; this makes CUPS in jessie with english texts in native translations, and I'm not sure that it will be accepted at this point of the release cycle by the release team. c) Drop the Color Management patch entirely for the Jessie release cycle: given that upstream has released the 2.0.x series and that, as far as I know, there is no color-management patch available for that codebase yet (and that upstream has declined to include your patch), I tend to think that this is the most future-proof decision for this patch. What's your opinion on this? TIA, cheers, OdyX Le mercredi, 5 novembre 2014, 16.33:26 Pascal Obry a écrit : I just found out that on the CUPS page when defining (or modifying) a printer the Color Calibration Mode check box only appears only when the language of the desktop is set to English. signature.asc Description: This is a digitally signed message part.
Bug#731473: Wheezy: eth0 not working
Package: src:linux Version: 3.2.63-2+deb7u1 Followup-For: Bug #731473 Dear Maintainer, Same problem here. Fresh wheezy install on Shuttle DS47 hardware. Wired ethernet doesn't work (link up, no traffic - neither via DHCP nor via fixed IP). Got wireless ethernet to work by installing realtek drivers from debian non-free repository, but it doesn't help for wired. Note : As C/C++ developer, I'm available for kernel patch attempts or hardcore troubleshooting if need be. -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.63-2+deb7u1 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=UUID=d03a347f-4673-4728-a3d0-090f9f3cb14a ro quiet ** Not tainted ** Kernel log: [3.638928] usb 3-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [3.638932] usb 3-1.4: Product: Cruzer Blade [3.638935] usb 3-1.4: Manufacturer: SanDisk [3.638938] usb 3-1.4: SerialNumber: 4C530001200717120275 [3.639295] scsi6 : usb-storage 3-1.4:1.0 [3.716668] udevd[361]: starting version 175 [3.795083] iTCO_vendor_support: vendor-support=0 [3.795953] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.07 [3.796083] iTCO_wdt: Found a Panther Point TCO device (Version=2, TCOBASE=0x0460) [3.796172] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [3.819085] [drm] Initialized drm 1.1.0 20060810 [3.832891] ACPI: Requesting acpi_cpufreq [3.833329] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input2 [3.833341] ACPI: Power Button [PWRB] [3.842903] snd_hda_intel :00:1b.0: irq 46 for MSI/MSI-X [3.842956] snd_hda_intel :00:1b.0: setting latency timer to 64 [3.843371] cfg80211: Calling CRDA to update world regulatory domain [3.864881] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 [3.864954] ACPI: Power Button [PWRF] [3.893088] rtl8192ce :01:00.0: setting latency timer to 64 [3.893176] rtl8192ce:_rtl92ce_read_chip_version():0-0 Chip Version ID: Unknown. Bug? [3.906065] input: PC Speaker as /devices/platform/pcspkr/input/input4 [3.906566] ** This B_CUT device may not work with kernels 3.6 and earlier [3.915750] Error: Driver 'pcspkr' is already registered, aborting... [4.010148] rtl8192ce :01:00.0: firmware: agent loaded rtlwifi/rtl8192cfwU_B.bin into memory [4.014760] ieee80211 phy0: Selected rate control algorithm 'rtl_rc' [4.015702] rtlwifi: wireless switch is on [4.311222] scsi 4:0:0:0: Direct-Access Generic STORAGE DEVICE 9454 PQ: 0 ANSI: 0 [4.314013] sd 4:0:0:0: Attached scsi generic sg2 type 0 [4.315695] sd 4:0:0:0: [sdc] Attached SCSI removable disk [4.412221] HDMI status: Codec=3 Pin=7 Presence_Detect=0 ELD_Valid=0 [4.412515] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci:00/:00:1b.0/sound/card0/input5 [4.412996] input: HDA Intel PCH Headphone as /devices/pci:00/:00:1b.0/sound/card0/input6 [4.413459] ACPI: resource :00:1f.3 [io 0xf040-0xf05f] conflicts with ACPI region SMBI [io 0xf040-0xf04f] [4.413466] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [4.414093] i915 :00:02.0: setting latency timer to 64 [4.474103] mtrr: type mismatch for e000,1000 old: write-back new: write-combining [4.474108] [drm] MTRR allocation failed. Graphics performance may suffer. [4.474475] i915 :00:02.0: irq 47 for MSI/MSI-X [4.474488] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [4.474491] [drm] Driver supports precise vblank timestamp query. [4.474617] [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call failed [4.474722] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [4.487461] scsi 5:0:0:0: Direct-Access Kingston DataTraveler G2 PMAP PQ: 0 ANSI: 0 CCS [4.488782] sd 5:0:0:0: Attached scsi generic sg3 type 0 [4.490246] sd 5:0:0:0: [sdd] 7827456 512-byte logical blocks: (4.00 GB/3.73 GiB) [4.490736] sd 5:0:0:0: [sdd] Write Protect is off [4.490741] sd 5:0:0:0: [sdd] Mode Sense: 23 00 00 00 [4.491244] sd 5:0:0:0: [sdd] No Caching mode page found [4.491308] sd 5:0:0:0: [sdd] Assuming drive cache: write through [4.495859] sd 5:0:0:0: [sdd] No Caching mode page found [4.495931] sd 5:0:0:0: [sdd] Assuming drive cache: write through [4.497700] sdd: sdd1 [4.501616] sd 5:0:0:0: [sdd] No Caching mode page found [4.501690] sd 5:0:0:0: [sdd] Assuming drive cache: write through [4.501760] sd 5:0:0:0: [sdd] Attached SCSI removable disk [4.519056] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [4.637598] scsi 6:0:0:0: Direct-Access SanDisk Cruzer Blade 1.26 PQ: 0 ANSI: 6 [4.639374] sd 6:0:0:0: Attached scsi generic sg4 type 0 [
Bug#770704: ITP: wcwidth -- determine printable width of a string on a terminal
Package: wnpp Severity: wishlist Owner: Sebastian Ramacher sramac...@debian.org * Package name: wcwidth Version : 0.1.4 Upstream Author : Jeff Quast * URL : https://pypi.python.org/pypi/wcwidth/0.1.4 * License : Expat Programming Lang: Python Description : determine printable width of a string on a terminal wcwidth allows to determine the printable width of a string on a terminal. It provides functions similar to wcwidth(3) and wcswidth(3) for Python programs. -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#770705: zim: New (sub)page window height increases incrementally
Package: zim Version: 0.62-3 Severity: minor Tags: upstream Dear Maintainer, From the intial start of zim, the window of adding a page or subpage keeps expanding vertically with every addition, untill the window has taken on the height of the screen, after adding say 20 pages. Closing and restarting Zim didn't sovle this issue, neither did adding pages in other parts of the page tree. It might be worth noting that it concerns a Notebook originally created with an older version of Zim. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages zim depends on: ii python 2.7.8-2 ii python-gobject 3.14.0-1 ii python-gtk2 2.24.0-4 ii python-xdg 0.25-4 Versions of packages zim recommends: ii python-gtkspell 2.25.3-13 Versions of packages zim suggests: pn bzr none pn ditaa none pn dvipngnone pn git none ii gnuplot 4.6.6-1 pn graphviz none pn lilypond none pn mercurial none pn python-zeitgeist none pn r-basenone pn scrot 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#764251: Please set the build timestamp to a deterministic time
Hello, Le dimanche 23 novembre 2014 à 11:25:07, Gerhard Rieger a écrit : I appreciate this patch, it will go in the next bug fix / porting release. Thanks for your quick and positive answer. I note that you integrate the patch soon. This will be a point for us to follow. Regards, -- Stéphane Aulery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770706: keystone.service does not start, /var/run/keystone not created
Package: keystone Version: 2014.1.3-2 Severity: important Dear Maintainer, When installing keystone on a host running systemd, the service does not start. The error from the unit on start is: Nov 23 12:33:41 server.example.com keystone[18089]: mkdir: cannot create directory ‘/var/run/keystone’: Permission denied Nov 23 12:33:41 server.example.com keystone[18089]: chown: cannot access ‘/var/run/keystone’: No such file or directory Nov 23 12:33:41 server.example.com keystone[18089]: start-stop-daemon: unable to open pidfile '/var/run/keystone/keystone.pid' for writing (No such file or directory) Nov 23 12:33:41 server.example.com keystone[18089]: start-stop-daemon: child returned error exit status 2 (No such file or directory) Nov 23 12:35:11 server.example.com systemd[1]: keystone.service start operation timed out. Terminating. Nov 23 12:35:11 server.example.com systemd[1]: Failed to start OpenStack Identity service. Nov 23 12:35:11 server.example.com systemd[1]: Unit keystone.service entered failed state. Adding RuntimeDirectory=keystone under [Service] in the /lib/systemd/system/keystone.service unit fixes the problem. This will make systemd create the keystone runtime directory under /run. I would like to submit a patch, but can't easily find the source of the systemd units in the packaging repo at http://anonscm.debian.org/cgit/openstack/keystone.git/ -- I do notice that the override_dh_clean target removes them, so I suspect they are generated somehow. I set the severity to important, but suspect that an upgrade to serious is necessary to get it unfrozen and fixed before the release of jessie. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages keystone depends on: ii adduser3.113+nmu3 ii dbconfig-common1.8.47+nmu3 ii debconf [debconf-2.0] 1.5.53 ii dpkg 1.17.21 ii lsb-base 4.1+Debian13+nmu1 ii python-configobj 5.0.6-1 ii python-keystone2014.1.3-2 pn python:any none ii sqlite33.8.7.1-1 ii ssl-cert 1.0.35 keystone recommends no packages. keystone suggests no packages. -- Configuration Files: [not relevant, and just filled with defaults] -- debconf information excluded -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768134: Plugin does not work with gedit 3.8
Package: gedit-latex-plugin Followup-For: Bug #768134 Control: tags -1 pending Hi Pietro, I read your last message as a pending is warranted... (Please remove it again when I'm wrong...) -- tobi -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763771: cups-daemon: reload failed during upgrade
Le mercredi, 12 novembre 2014, 14.58:40 Vincent Lefevre a écrit : since I gave additional information. I can't debug it as core dumps are disabled. So, please fix bug 760475. Could you retry with the latest CUPS version (1.7.5-8) which I just uploaded? It fixes a random crash, and could help with your issue. It also enabled core-dumps through the same patch. TIA, 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#759424: di-netboot-assistant: please update package for jessie / new syslinux
Quoting Jonas Smedegaard (2014-11-23 13:05:36) Quoting Cyril Brulebois (2014-11-23 12:49:58) Jonas Smedegaard d...@jones.dk (2014-11-21): Attached is a patch believed to fix all issues related to new syslinux: * Lookup pxelinux.0 in /usr/lib/PXELINUX (not only /usr/lib/syslinux). * Lookup only BIOS binaries (not accidentally include EFI binaries). * Install core modules at tftpd root dir. * Keep vesamenu and menu modules in sync with PXELINUX. thank you both for providing patches to di-netboot-assistant; is there any chance you could submit a branch or patch series against its git repository (git://anonscm.debian.org/d-i/netboot-assistant.git)? Of course I could try and split up your patches into atomic commits, but I guess it'd be better if knowledgeable could document patches. There's of course the part where Andreas had to patch a bit more what Jonas provided, so cross-checking each other would be nice. Sure thing: I will prepare git commits. I am puzzled why you needed that change, Andreas. Perhaps it depend on the versions of syslinux involved. I tested on Jessie, with stable, testing and daily for amd64 and i386 - what did you test? Or perhaps it is related to choice and configuration of tftpd. I use tftpd-hpa with TFTP_OPTIONS=--blocksize 1468 -v -v -v -v --secure and adapting di-netboot-assistant to use /srv/tftp. @Andreas: If you configured your tftpd to treat debian-installer subdir as root dir for tftpd, then you should move/copy those three files yourself: This script currently has configurable TFTP_ROOT but hardcoded debian-installer subdir - making that configurable too is independent from this bug. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#767653:
Hi Jochen, can you please check if you committed everything? Especially I'm missing changes to d/changelog... Is this a team upload? A NMU? I assume you are on the multimedia team, have your patch been discussed there? What is the relation to openni when this bug is reported against libopenni-sensor-pointclouds0 / libopenni-sensor-primesense0 ? Can you please clarify? Thanks -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760475: closed by Didier Raboud o...@debian.org (Bug#760475: fixed in cups 1.7.5-8)
Control: reopen 760475 On Sun, Nov 23, 2014 at 01:09:31PM +, Debian Bug Tracking System wrote: * Add a USB quirk fix for Brother HL-1250 (Closes: #712512) * Backport upstream patch to fix random crash in TLS handling. The patch also enables coredumps.(Closes: #760475, #760476) cupsd disables core files for fun and profit, it sets the soft limit to 0. This makes it impossible to get any usable debugging information when cupsd crashes. This was not a bug-report about the crash, but about the rlimit munging. Bastian -- ... bacteriological warfare ... hard to believe we were once foolish enough to play around with that. -- McCoy, The Omega Glory, 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#770701: unblock: libvirt/1.2.9-4
On Sun, Nov 23, 2014 at 01:16:40PM +0100, Niels Thykier wrote: Control: tags -1 moreinfo On 2014-11-23 13:07, Guido Günther wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libvirt The changes are: [...] There are some more pending issues for jessie like bugs in the lxc, xen and vbox driver but I'd like to give them some more testing before letting them enter jessie so I'd be awesome to have these changes already unblocked. unblock libvirt/1.2.9-4 Cheers, -- Guido [...] Unfortunately, libvert/1.2.9-4 FTBFS on several architectures, which is a regression to 1.2.9-3. Until those are resolved, we cannot accept libvirt/1.2.9-4. Thanks for the prompt reply! Just for the record: that's not caused by the modifications but by changes in libvirt's dependencies 1.2.9-3 will suffer the same on a rebuild. Will try to find some time to dig into this in the coming days/weeks. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770707: unblock: cups/1.7.5-8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package cups. The 1.7.5-8 upload has the following changes: * Add a USB quirk fix for Brother HL-1250 (Closes: #712512) This was reported upstream as https://www.cups.org/str.php?L4519 . It's a routine USB quirk change to accomodate printers with weird USB behaviours. Severity: important * Backport upstream patch to fix random crash in TLS handling. The patch also enables coredumps.(Closes: #760475, #760476) The interesting bug here is #760476 (severity: serious), which was about a crash within the TLS handling. The two upstreams discussed on https://cups.org/str.php?L4484 and AFAIK GnuTLS added a workaround in 3.3.8-3 (already in testing). Mike Sweet also fixed this in CUPS by reworking the file descriptors closing mechanisms. His patch also dropped the core dumps disabling (#760475, severity: important). I'm attaching the full debdiff (including quilt patch refreshments) as well as the two patches in isolation. (Aside to that, I'd be interested by the opinion of the Release Team on the Color Management patch, see https://lists.debian.org/3542659.lWsmeQSxEG@gyllingar ) Cheers, OdyX unblock cups/1.7.5-8 diff -Nru cups-1.7.5/debian/changelog cups-1.7.5/debian/changelog --- cups-1.7.5/debian/changelog 2014-10-23 22:06:22.0 +0200 +++ cups-1.7.5/debian/changelog 2014-11-23 13:26:25.0 +0100 @@ -1,3 +1,11 @@ +cups (1.7.5-8) unstable; urgency=medium + + * Add a USB quirk fix for Brother HL-1250 (Closes: #712512) + * Backport upstream patch to fix random crash in TLS handling. The patch also +enables coredumps.(Closes: #760475, #760476) + + -- Didier Raboud o...@debian.org Sun, 23 Nov 2014 13:26:24 +0100 + cups (1.7.5-7) unstable; urgency=medium * Revert to not socket-activating CUPS (Closes: #747073) diff -Nru cups-1.7.5/debian/patches/brother-hl-1250-quirks.patch cups-1.7.5/debian/patches/brother-hl-1250-quirks.patch --- cups-1.7.5/debian/patches/brother-hl-1250-quirks.patch 1970-01-01 01:00:00.0 +0100 +++ cups-1.7.5/debian/patches/brother-hl-1250-quirks.patch 2014-11-23 13:25:22.0 +0100 @@ -0,0 +1,18 @@ +Description: Add Brother HL-1250 usb quirks fix +Author: Didier Raboud o...@debian.org +Bug-Debian: https://bugs.debian.org/712512 +Bug: https://www.cups.org/str.php?L4519 +Last-Update: 2014-11-04 + +--- a/backend/org.cups.usb-quirks b/backend/org.cups.usb-quirks +@@ -90,6 +90,9 @@ + # Canon, Inc. MF4150 Printer, https://bugs.launchpad.net/bugs/1160638 + 0x04a9 0x26a3 no-reattach + ++# Brother Industries, Ltd HL-1250 Laser Printer, https://bugs.debian.org/712512 ++0x04f9 0x0007 no-reattach ++ + # Brother Industries, Ltd HL-1430 Laser Printer, https://bugs.launchpad.net/bugs/1038695 + 0x04f9 0x001a no-reattach + diff -Nru cups-1.7.5/debian/patches/cupsd-idleexittimeout.patch cups-1.7.5/debian/patches/cupsd-idleexittimeout.patch --- cups-1.7.5/debian/patches/cupsd-idleexittimeout.patch 2014-10-20 08:54:17.0 +0200 +++ cups-1.7.5/debian/patches/cupsd-idleexittimeout.patch 2014-11-23 13:25:59.0 +0100 @@ -46,8 +46,8 @@ + int t = -1; /* Timeout */ char *opt; /* Option character */ int fg; /* Run in the foreground */ - int fds; /* Number of ready descriptors */ -@@ -123,6 +124,8 @@ + int close_all = 1, /* Close all file descriptors? */ +@@ -125,6 +126,8 @@ #else time_t netif_time = 0; /* Time since last network update */ #endif /* __APPLE__ */ @@ -56,8 +56,8 @@ #if HAVE_LAUNCHD int launchd_idle_exit; /* Idle exit on select timeout? */ -@@ -288,6 +291,21 @@ - fg = 1; +@@ -304,6 +307,21 @@ + close_all = 0; break; + case 'x' : /* Exit on idle timeout */ @@ -78,7 +78,7 @@ default : /* Unknown option */ _cupsLangPrintf(stderr, _(cupsd: Unknown option \%c\ - aborting.), *opt); -@@ -533,6 +551,13 @@ +@@ -541,6 +559,13 @@ } /* @@ -92,7 +92,7 @@ * Clean out old temp files and printer cache data. */ -@@ -770,6 +795,26 @@ +@@ -778,6 +803,26 @@ if ((timeout = select_timeout(fds)) 1 LastEvent) timeout = 1; @@ -119,7 +119,7 @@ #if HAVE_LAUNCHD /* * If no other work is scheduled and we're being controlled by -@@ -883,6 +928,20 @@ +@@ -891,6 +936,20 @@ } #endif /* !__APPLE__ */ diff -Nru cups-1.7.5/debian/patches/cupsd-idleexittimeout-systemd.patch cups-1.7.5/debian/patches/cupsd-idleexittimeout-systemd.patch --- cups-1.7.5/debian/patches/cupsd-idleexittimeout-systemd.patch 2014-10-23 21:50:26.0 +0200 +++ cups-1.7.5/debian/patches/cupsd-idleexittimeout-systemd.patch 2014-11-23 13:25:22.0 +0100 @@ -33,7 +33,7 @@ /* Time after which an idle cupsd will exit */ --- a/scheduler/main.c +++ b/scheduler/main.c -@@ -1728,6 +1728,15 @@ +@@ -1736,6 +1736,15 @@ # endif /* HAVE_SSL */ } diff
