Bug#779360: RFP: owncloud-bookmarks -- bookmark manager - ownCloud application
Package: wnpp Severity: wishlist Control: affects -1 owncloud * Package name: owncloud-bookmarks Version : 0~8.0.0 Upstream Author : Brice Maron br...@bmaron.net * URL : https://doc.owncloud.org/server/8.0/user_manual/bookmarks.html * License : AGPL-3+ Programming Lang: PHP Description : bookmark manager - ownCloud application Third party application for ownCloud, providing a platform to easily view and sync your bookmarks across all your devices and enabling basic editing right on the web. . ownCloud gives you universal access to your files through a web interface or WebDAV. As recently proposed [1], we intend to package relevant owncloud apps in separate packages, and plan to maintain them in the ownCloud for Debian maintainers team. 1: https://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/Week-of-Mon-20150223/002086.html signature.asc Description: Digital signature
Bug#779361: RFP: owncloud-calendar -- calendar with CalDAV support - ownCloud application
Package: wnpp Severity: wishlist Control: affects -1 owncloud * Package name: owncloud-calendar Version : 0.6.4~8.0.0 Upstream Author : Georg Ehrke develo...@georgehrke.com * URL : https://doc.owncloud.org/server/8.0/user_manual/pim/calendar.html * License : AGPL-3+ Programming Lang: PHP Description : calendar with CalDAV support - ownCloud application Third party application for ownCloud, providing a platform to easily create and edit events, synchronize to other calendars you might use, and create new, personalized calendars. . ownCloud gives you universal access to your files through a web interface or WebDAV. As recently proposed [1], we intend to package relevant owncloud apps in separate packages, and plan to maintain them in the ownCloud for Debian maintainers team. 1: https://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/Week-of-Mon-20150223/002086.html signature.asc Description: Digital signature
Bug#779362: RFP: search-lucene -- full text search - ownCloud application
Package: wnpp Severity: wishlist Control: affects -1 owncloud * Package name: search-lucene Version : 0.6.0~8.0.0 Upstream Author : Jörn Friedrich Dreyer j...@butonic.de * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : full text search - ownCloud application The Search Lucene app adds a full text search for files stored in ownCloud. It is based on Zend Search Lucene and can index content from plain text, .docx, .xlsx, .pptx, .odt, .ods and .pdf files. . ownCloud gives you universal access to your files through a web interface or WebDAV. As recently proposed [1], we intend to package relevant owncloud apps in separate packages, and plan to maintain them in the ownCloud for Debian maintainers team. 1: https://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/Week-of-Mon-20150223/002086.html signature.asc Description: Digital signature
Bug#779358: ITP: owncloud-documents -- collaborative document editing - ownCloud application
Package: wnpp Severity: wishlist Owner: David Prévot taf...@debian.org Control: affects -1 owncloud * Package name: owncloud-documents Version : 0.3.0.1+8.0.0 Upstream Author : Victor Dubiniuk victor.dubin...@gmail.com * URL : https://doc.owncloud.org/server/8.0/user_manual/pim/documents.html * License : AGPL-3+ Programming Lang: PHP Description : collaborative document editing - ownCloud application The Documents application supports editing documents within ownCloud, without the need to launch an external application. It supports the following features: . * Cooperative edit, with multiple users editing files simultaneously. * Document creation within ownCloud. * Document upload. * Share and edit files in the browser, and then share them inside ownCloud or through a public link. . Supported file formats are .odt, .doc, and .docx. . ownCloud gives you universal access to your files through a web interface or WebDAV. As recently proposed [1], we intend to package relevant owncloud apps in separate packages, and plan to maintain them in the ownCloud for Debian maintainers team. 1: https://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/Week-of-Mon-20150223/002086.html Other applications need packaging, RFPs follow. Regards David signature.asc Description: Digital signature
Bug#779718: ITP: soundmanager2 -- cross-platform audio player API
Package: wnpp Severity: wishlist Owner: David PrĂ©vot taf...@debian.org Control: affect -1 owncloud-apps owncloud-music * Package name: soundmanager2 Version : 2.97a.20140901+dfsg Upstream Author : Scott Schiller s...@schillmania.com * URL : http://www.schillmania.com/projects/soundmanager2/ * License : BSD-3-clause Programming Lang: JavaScript, AS Description : cross-platform audio player API SoundManager 2 makes it easy to play audio using JavaScript by wrapping and extending HTML5 and Flash Audio APIs. . The current package does not yet provide the Flash 9/AS3 shim (it falls back to the Flash 8/AS2 if HTML5 is not available). Itâs currently used (as an embedded copy) by the Music application for ownCloud (as provided by owncloud-apps). The goal will be to provide the Flash 8 shim (currently deactivated) since the build toolchain is already available in Debian (not yet for the Flash 9 one though), and will be maintained inside the ownCloud for Debian maintainers team signature.asc Description: Digital signature
Bug#774317: possibly related to not renaming
Upstream notes he does not does not use libmtp rename support because it appears to confuse some Android apps (upstream README) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779514: [Pkg-mozext-maintainers] Bug#779514: xul-ext-requestpolicy: asks to allow manual inputed requests
Please, keep the bug CC (full quote for the bug log), and please also answer the last question (are more versions also affected or not?). i thought a picture is worth a thousand words but if that is not true for you i will try to explain it even so i am not very skilled in doing this using the english language... An error message in German, hidden in a picture, without an explanation, was definitely not understandable, thanks for coming back to us. * What led up to the situation? just installed requestpolicy using apt-get on my debian stable system and restarted my iceweasel * What exactly did you do (or not do) that was effective (or ineffective)? i dont think that the exact way i chose really matters. $ tail /var/log/apt/history.log Start-Date: 2015-03-01 19:18:36 Commandline: apt-get install xul-ext-requestpolicy Install: xul-ext-requestpolicy:amd64 (0.5.25-1) End-Date: 2015-03-01 19:18:42 startet iceweasel, tryed to open pages, got problems, pressed ctrl+t to open new tab, entered another url directly by keyboard, pressed return * What was the outcome of this action? the request policy plugin tryed to gard me from my own request. (as you can see at the picture) It thought that the request had been made by about:newtab but insted i typed in the url by my self. * What outcome did you expect instead? that my own request will be exepted, otherwise i had to whitelist every url that i am typing in what sure isnt the right way. i guess the reason for that error is an incompatibility between the iceweasel version and the request policy version. Even so both packages are part in the debian stable version. I have installed the latest version using mozillas addon page and the problem isnt present anymore. So please follow my steps, try that out and fix that!! thanks a lot and keep up the good work Am 01.03.2015 um 19:55 schrieb David PrĂ©vot: Hi treaki, Thanks for your interest in packaged extensions. Package: xul-ext-requestpolicy Version: 0.5.25-1 Severity: important have a look at this screenshot, ThatÂs not really a useful bug report. something is wrong.. Please, do explain what is going on, consider using the default reportbug template and answer the following questions: * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? please fix that Please also document if the issue is fixed in 0.5.28-1 (as available in Jessie and Sid) or 1.0.0~beta8.2+dfsg-1 (as available in experimental). Regards David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779490: ITP: three.js -- lightweight
Package: wnpp Severity: wishlist Owner: David Bremner brem...@debian.org * Package name: three.js Version : 70 Upstream Author : Mr.doob i...@mrdoob.com * URL : http://threejs.org * License : MIT Programming Lang: JavaScript Description : lightweight 3D graphics library JavaScript library that provides a high level API to create 3D graphics in the browser using WebGL. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779508: unblock: php-monolog/1.11.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package php-monolog
It fixes a potential security issue (mail header injection) by
cherry-picking an upstream commit that was already included in version
1.12.0-1 (as available in experimental). The patch also includes an
update to the test suite (showing how the issue may have been
exploited).
php-monolog (1.11.0-2) unstable; urgency=medium
* Add gbp.conf to track the Jessie branch
* Fix a potential security issue (header injection)
Prevent header injection through content type / encoding in
NativeMailerHandler.
-- David Prévot taf...@debian.org Sun, 01 Mar 2015 01:56:16 -0400
Please find attached the full debdiff, as well as the new patch itself
to ease the review.
unblock php-monolog/1.11.0-2
Thanks in advance for considering.
Regards
David
diff --git a/debian/changelog b/debian/changelog
index 8a207aa..a8bf6bb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+php-monolog (1.11.0-2) unstable; urgency=medium
+
+ * Add gbp.conf to track the Jessie branch
+ * Fix a potential security issue (header injection)
+Prevent header injection through content type / encoding in
+NativeMailerHandler.
+
+ -- David Prévot taf...@debian.org Sun, 01 Mar 2015 01:56:16 -0400
+
php-monolog (1.11.0-1) unstable; urgency=medium
[ gkedzierski ]
diff --git a/debian/gbp.conf b/debian/gbp.conf
new file mode 100644
index 000..fae4302
--- /dev/null
+++ b/debian/gbp.conf
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = jessie
diff --git a/debian/patches/0004-Prevent-header-injection-through-content-type-encodi.patch b/debian/patches/0004-Prevent-header-injection-through-content-type-encodi.patch
new file mode 100644
index 000..1c27746
--- /dev/null
+++ b/debian/patches/0004-Prevent-header-injection-through-content-type-encodi.patch
@@ -0,0 +1,65 @@
+From: Jordi Boggiano j.boggi...@seld.be
+Date: Sun, 28 Dec 2014 14:32:10 +
+Subject: Prevent header injection through content type / encoding in
+ NativeMailerHandler, fixes #458, closes #448
+
+Bug: https://github.com/Seldaek/monolog/pull/448 https://github.com/Seldaek/monolog/issues/458
+Origin: upstream, https://github.com/Seldaek/monolog/commit/515a096c864b00b3967f7f601680f85d4a2e4001
+---
+ src/Monolog/Handler/NativeMailerHandler.php | 8
+ tests/Monolog/Handler/NativeMailerHandlerTest.php | 18 ++
+ 2 files changed, 26 insertions(+)
+
+diff --git a/src/Monolog/Handler/NativeMailerHandler.php b/src/Monolog/Handler/NativeMailerHandler.php
+index 7605a14..0fe6b64 100644
+--- a/src/Monolog/Handler/NativeMailerHandler.php
b/src/Monolog/Handler/NativeMailerHandler.php
+@@ -129,6 +129,10 @@ class NativeMailerHandler extends MailHandler
+ */
+ public function setContentType($contentType)
+ {
++if (strpos($contentType, \n) !== false || strpos($contentType, \r) !== false) {
++throw new \InvalidArgumentException('The content type can not contain newline characters to prevent email header injection');
++}
++
+ $this-contentType = $contentType;
+
+ return $this;
+@@ -140,6 +144,10 @@ class NativeMailerHandler extends MailHandler
+ */
+ public function setEncoding($encoding)
+ {
++if (strpos($encoding, \n) !== false || strpos($encoding, \r) !== false) {
++throw new \InvalidArgumentException('The content type can not contain newline characters to prevent email header injection');
++}
++
+ $this-encoding = $encoding;
+
+ return $this;
+diff --git a/tests/Monolog/Handler/NativeMailerHandlerTest.php b/tests/Monolog/Handler/NativeMailerHandlerTest.php
+index 50ceace..c2553ee 100644
+--- a/tests/Monolog/Handler/NativeMailerHandlerTest.php
b/tests/Monolog/Handler/NativeMailerHandlerTest.php
+@@ -40,4 +40,22 @@ class NativeMailerHandlerTest extends TestCase
+ $mailer = new NativeMailerHandler('spam...@example.org', 'dear victim', 'recei...@example.org');
+ $mailer-addHeader(array(Content-Type: text/html\r\nFrom: fa...@attacker.org));
+ }
++
++/**
++ * @expectedException InvalidArgumentException
++ */
++public function testSetterContentTypeInjection()
++{
++$mailer = new NativeMailerHandler('spam...@example.org', 'dear victim', 'recei...@example.org');
++$mailer-setContentType(text/html\r\nFrom: fa...@attacker.org);
++}
++
++/**
++ * @expectedException InvalidArgumentException
++ */
++public function testSetterEncodingInjection()
++{
++$mailer = new NativeMailerHandler('spam...@example.org', 'dear victim', 'recei...@example.org');
++$mailer-setEncoding(utf-8\r\nFrom: fa...@attacker.org);
++}
+ }
diff --git a/debian/patches/series b/debian/patches/series
index 5286df5..9766944 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
0001-Use
Bug#779491: ownCloud video handling (Was: Bug#779491: fixed in mediaelement 2.15.1+dfsg-2)
Hi Mathieu, Thanks for your interest in the ownCloud Debian package and for your bug report. On Sun, Mar 01, 2015 at 05:59:57PM +0100, Mathieu ROY wrote: So will this new updated package will make sure that existing owncloud servers will stop trying to play video with a non existent file? The Flash (and Silverlight) shims are now really disabled (so they wonât be offered as an alternative anymore if proper HTML5 video is not known to be working). I'm not really concerned about the ability or inability of owncloud to play videos. I'm annoyed by the fact it acts as if it would but then silently end up on pop-up with a black screen. That, unfortunately, may still happen if the browser does not handle properly video. The only thing fixed by this upload, is it wonât offer a broken object or embed anymore, trying to download a non existing file. Upstream documents the current support by formats and vendors: http://mediaelementjs.com/#devices It would be nice to not offer a video at all if it is known not to work, but would be even nicer to be able to build (and ship) those Flash (and Silverlight) parts (as documented in the package description, the /usr/share/doc/libjs-mediaelement/README.Debian file, and #760297). Regards David signature.asc Description: Digital signature
Bug#779514: [Pkg-mozext-maintainers] Bug#779514: xul-ext-requestpolicy: asks to allow manual inputed requests
Hi treaki, Thanks for your interest in packaged extensions. Package: xul-ext-requestpolicy Version: 0.5.25-1 Severity: important have a look at this screenshot, ThatÂs not really a useful bug report. something is wrong.. Please, do explain what is going on, consider using the default reportbug template and answer the following questions: * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? please fix that Please also document if the issue is fixed in 0.5.28-1 (as available in Jessie and Sid) or 1.0.0~beta8.2+dfsg-1 (as available in experimental). Regards David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778375: apt-transport-https: segfaults
On Mon, Feb 16, 2015 at 01:16:19AM +0100, Tomasz Buchert wrote:
The tricky HTTPS server returns this line: HTTP/1.1 302. Note that
there is no explanation for the status code 302 (it should be
Found). Anyway, this is fine, the code seems to be prepared for
that case: elements is set to 3 in server.cc:128.
apt is since 0.8.0~pre2 (23 Aug 2010). I think back then it was also
a sourceforge server triggering this. Note that this is a violation of
the HTTP1.1 spec (see rfc7230 section 3.1.2) which allows for an empty
reason-phrase, but the space before that is non-optional.
However, Owner is NULL (I don't know why, I don't know the code, but
it is) so Owner-Debug fails in server.cc:132.
The attached patch checks whether Owner is NULL before dereferencing
it. This fixes this problem for me, but somebody who knows what Owner
is should make sure that it makes sense. Feel free to adjust the
patch to your needs, it's in public domain.
rambling
That is a good catch! 'Owner' refers here to the ServerMethod owning the
ServerState (that was a very helpful explanation, wasn't it? ;) ).
It boils down to this: In Sep 2013 I wanted to fix some bugs in https by
using less curl and more of our own http code. For this I invented
a bunch of Server classes as parents for http and https â in handsight,
I really should have used another name, but well, anyway â expect that
both were completely different in their implementation.
Somehow I managed to pull it of anyway with the result that they share
most of their State parsing/tracking which is quite helpful. It also
means through that the actual Methods using the State are still very
different so getting a common interface for them was hard. Somewhere
down that line I took a shortcut giving the HttpsState a NULL for its
owner as it 'never' really needed it and can hence be fixed 'later'
correctly, right?
Fast forward one and a half years and the 'never' as well as the 'later'
is spoiled. Its a bit ironic that a debug message does this to meâŠ
/rambling
The proposed patch works just fine as the other users for 'Owner'
aren't used by https and for http its always properly set (and nobody
dies if a debug message isn't shown even if requested) and at that point
in the release I guess everyone will be happy about a one-line fix.
(Michael is uploading it any minute now)
Attached is my fullblown 'proper' patch with a testcase I am going to
apply to our /experimental branch for comparison in the meantime.
Best regards
David Kalnischkies
diff --git a/methods/https.cc b/methods/https.cc
index 3a5981b..444bdef 100644
--- a/methods/https.cc
+++ b/methods/https.cc
@@ -109,7 +109,7 @@ HttpsMethod::progress_callback(void *clientp, double dltotal, double /*dlnow*/,
}
// HttpsServerState::HttpsServerState - Constructor /*{{{*/
-HttpsServerState::HttpsServerState(URI Srv,HttpsMethod * /*Owner*/) : ServerState(Srv, NULL)
+HttpsServerState::HttpsServerState(URI Srv,HttpsMethod * Owner) : ServerState(Srv, Owner)
{
TimeOut = _config-FindI(Acquire::https::Timeout,TimeOut);
Reset();
@@ -313,13 +313,11 @@ bool HttpsMethod::Fetch(FetchItem *Itm)
curl_easy_setopt(curl, CURLOPT_LOW_SPEED_TIME, timeout);
// set redirect options and default to 10 redirects
- bool const AllowRedirect = _config-FindB(Acquire::https::AllowRedirect,
- _config-FindB(Acquire::http::AllowRedirect,true));
curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, AllowRedirect);
curl_easy_setopt(curl, CURLOPT_MAXREDIRS, 10);
// debug
- if(_config-FindB(Debug::Acquire::https, false))
+ if (Debug == true)
curl_easy_setopt(curl, CURLOPT_VERBOSE, true);
// error handling
@@ -356,7 +354,7 @@ bool HttpsMethod::Fetch(FetchItem *Itm)
// go for it - if the file exists, append on it
File = new FileFd(Itm-DestFile, FileFd::WriteAny);
- Server = new HttpsServerState(Itm-Uri, this);
+ Server = CreateServerState(Itm-Uri);
// keep apt updated
Res.Filename = Itm-DestFile;
@@ -451,6 +449,25 @@ bool HttpsMethod::Fetch(FetchItem *Itm)
return true;
}
+ /*}}}*/
+// HttpsMethod::Configuration - Handle a configuration message /*{{{*/
+bool HttpsMethod::Configuration(string Message)
+{
+ if (ServerMethod::Configuration(Message) == false)
+ return false;
+
+ AllowRedirect = _config-FindB(Acquire::https::AllowRedirect,
+ _config-FindB(Acquire::http::AllowRedirect, true));
+ Debug = _config-FindB(Debug::Acquire::https,false);
+
+ return true;
+}
+ /*}}}*/
+ServerState * HttpsMethod::CreateServerState(URI uri) /*{{{*/
+{
+ return new HttpsServerState(uri, this);
+}
+ /*}}}*/
int main()
{
diff --git a/methods/https.h b/methods/https.h
index 411b714..f8d302d 100644
--- a/methods/https.h
+++ b/methods/https.h
@@ -52,7 +52,7 @@ class HttpsServerState : public ServerState
virtual ~HttpsServerState() {Close();};
};
-class HttpsMethod : public pkgAcqMethod
+class HttpsMethod : public ServerMethod
{
// minimum
Bug#779055: ITP: owncloud-contacts -- address book with CardDAV support - ownCloud application
Package: wnpp Severity: wishlist Owner: David PrĂ©vot taf...@debian.org * Package name: owncloud-contacts Version : 0.3.0.18+8.0.0-1 Upstream Author : Thomas Tanghus tho...@tanghus.net * URL : https://doc.owncloud.org/server/8.0/user_manual/pim/contacts.html * License : AGPL-3+ Programming Lang: PHP Description : address book with CardDAV support - ownCloud application Third party application for ownCloud, providing a platform to easily view and sync your contacts across all your devices and enabling basic editing right on the web. . ownCloud gives you universal access to your files through a web interface or WebDAV. As recently proposed [1], we intend to package relevant owncloud apps in separate packages, and plan to maintain them in the ownCloud for Debian maintainers team. 1: https://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/Week-of-Mon-20150223/002086.html Other applications need packaging, do not hesitate to get in touch with the team if you want to help, Iâll post some RFPs later if nobody beats me to it (and will be happy to sponsor any of the ownCloud related packages from people without upload rights). Regards David signature.asc Description: Digital signature
Bug#779175: error 403 for https
Control: retitle -1 apt-cacher-ng: deal/document https proxy handling Control: reassign -1 apt-cacher-ng Control: severity -1 wishlist Hi, On Wed, Feb 25, 2015 at 08:13:19AM +0100, Harald Dunkel wrote: My /etc/apt/apt.conf.d/proxy.conf says Acquire::http::Proxy http://debian-proxy:3142/;; debian-proxy is a local host running apt-cacher-ng. Problem: On apt-get update I get Err https://get.docker.com docker/main amd64 Packages Received HTTP code 403 from proxy after CONNECT If I drop the proxy redirection, then it works. apt.conf (5) documents this fallback in Acquire Group â https: | The Cache-control, Timeout, AllowRedirect, Dl-Limit and proxy options | work for HTTPS URIs in the same way as for the http method, and default | to the same values if they are not explicitly set. The section above this one is detailing http configuration and mentions the DIRECT keyword which is the solution to your problem here: + Acquire::https::Proxy DIRECT; (there are other solutions like proxy auto-detection if you want more) Since there is no https in the Acquire line, shouldn't the proxy be omitted for https traffic automagically? The fallback is in place as a proxy tends to be the only connection to the outside world. While a http proxy can't do its usual work on a https connection, it is still responsible for the connection to the outside, so these types of proxies accept https traffic and pass it through. Might not be the worst idea to implement something like it in apt-cacher-ng and/or hinting at the DIRECT config in its configuration, hence reassigning to them to decide on further actions. Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#777818: cmocka: ftbfs with GCC-5
Control: tags -1 patch Hi, On Thu, Feb 12, 2015 at 10:30:42AM +, Matthias Klose wrote: Package: src:cmocka Version: 0.4.1-2 [...] /«PKGBUILDDIR»/include/cmocka.h:52:18: error: ISO C does not support '__FUNCTION__' predefined identifier [-Wpedantic] #define __func__ __FUNCTION__ ^ Looks like the upstream author just provided a patch for the Fedora build: http://pkgs.fedoraproject.org/cgit/cmocka.git/diff/cmocka-1.0.0-fix_build_with_newer_gcc.patch Iâll include it if it works for us once upstream 1.0.0 will actually be available. Regards David signature.asc Description: Digital signature
Bug#778881: binfmt-support.service activating (start) for ever, no console
/bluetoothd 645 ?Ss 0:00 /usr/sbin/smartd -n 646 ?Ss 0:00 /usr/sbin/atd -f 647 ?Ss 0:00 /usr/sbin/cron -f 648 ?Ss 0:00 /usr/bin/freshclam -d --foreground=true 651 ?Ssl0:00 /usr/sbin/ModemManager 652 ?Ss 0:00 /usr/sbin/sshd -D 654 ?Ss 0:00 /usr/sbin/update-binfmts --enable 655 ?Ssl0:00 /usr/sbin/rsyslogd -n 658 ?Ss 0:00 /lib/systemd/systemd-logind 665 ?Ss 0:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 687 ?Ss 0:00 /usr/sbin/gpm -m /dev/input/mice -t exps2 692 ?S 0:00 [iprt] 713 ?Ssl0:00 /usr/bin/redis-server 127.0.0.1:6379 766 ?Ss 0:00 avahi-daemon: running [west.local] 779 ?Ss 0:00 /usr/sbin/acpid 818 ?S 0:00 avahi-daemon: chroot helper 819 ?S 0:00 /usr/bin/timidity -Os -iAD 824 ?Ss 0:00 /usr/sbin/cupsd -f 825 ?Ssl0:30 /usr/sbin/clamd --foreground=true 830 ?Ss 0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 110:119 1193 ?S 0:04 /usr/bin/python -O /usr/share/wicd/daemon/wicd-daemon.py 1217 ?Ss 0:00 /usr/sbin/exim4 -bd -q30m 1260 ?Ssl0:06 /usr/sbin/ntopng --daemon --pid /var/tmp/ntopng.pid -w 3000 1335 ?S 0:00 /usr/bin/python -O /usr/share/wicd/daemon/monitor.py 1922 ?Ss 0:00 wpa_supplicant -B -i wlan0 -c /var/lib/wicd/configurations/4494fc391fce -Dwext 2402 ?Ss 0:00 /sbin/dhclient -v wlan0 2635 ?S 0:00 /bin/sh -c /etc/acpi/power.sh 2637 ?S 0:00 /bin/sh /etc/acpi/power.sh 2638 ?S 0:00 [kworker/0:0] 2715 ?S 0:00 /bin/sh /usr/sbin/pm-powersave false 2749 ?S 0:00 /bin/sh /usr/lib/pm-utils/power.d/anacron false 2750 ?S 0:00 /bin/sh /usr/sbin/invoke-rc.d anacron start 2771 ?S 0:00 systemctl start anacron.service 2789 ?S 0:00 [kworker/1:0] 2859 ?Ss 0:00 sshd: david [priv] 2867 ?S 0:00 [kworker/u4:1] 2893 ?R 0:00 sshd: david@pts/1 2894 pts/1Ss 0:00 -bash 3060 ?S 0:00 [kworker/0:1] 3082 pts/1R+ 0:00 ps ax 3083 pts/1R+ 0:00 less ~# /sbin/shutdown -r now Failed to start reboot.target: Transaction is destructive. Broadcast message from david@west on pts/1 (Fri 2015-02-20 16:39:25 CST): The system is going down for reboot NOW! ~# /sbin/shutdown -P now Failed to start poweroff.target: Transaction is destructive. Broadcast message from david@west on pts/1 (Fri 2015-02-20 16:41:37 CST): The system is going down for power-off NOW! ~# [Power button now held for several seconds to power off.] -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages binfmt-support depends on: ii init-system-helpers 1.22 ii libc62.19-13 ii libpipeline1 1.4.0-1 ii lsb-base 4.1+Debian13+nmu1 binfmt-support recommends no packages. binfmt-support suggests no packages. -- no debconf information Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778928: reopened
While what I wrote is true, I sent it to the wrong bug. Sorry about that. d -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779153: Packaged php 5.4.38
Hi, please consider reviewing my packaging: http://de.mcbf.net/~squisher/debian/php/php5_5.4.38-0.dsc A couple of patches seem to have been adopted upstream, and I had to add one minor fix for the crypt config.m4. Thank you for your hard work! ~David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775456: ITP: sankore -- interactive whiteboard interface
Hi, [ The last two messages didnât make it to the bug log. My mistake, sorry, copying them after reordering. ] Le 13/02/2015 13:39, Miriam Ruiz a Ă©crit : 2015-02-13 17:58 GMT+01:00 David PrĂ©vot taf...@debian.org: On Fri, Feb 13, 2015 at 05:29:22PM +0100, Miriam Ruiz wrote: 2015-02-13 16:48 GMT+01:00 David PrĂ©vot taf...@debian.org: The first challenging bit might be to get rid of the sankore-ThirdParty code copy from the build system, Iâll start working on that now. The sankore-ThirdParty stuff hasn't changed since 2012 Noticed that. Thatâs one of the reason Iâd like to get rid of it. Have you already mixed them or do you prefer for me to prepare a working package from those sources and the current git repo? Iâd highly prefer to be able to use the dependencies already in the archive (quazip trolltech xpdf), and eventually package them if needed, rather than depending on old (and potentially security-flawed) convenient code copies. If really needed, we may use the multiple tarball feature of format 3.0 (quilt) to add back the missing bits. Yeah forget about the 3rd party, I agree with you. I meant mixing in the changes in the main program. Sure, feel free to start on getting rid of the ThirdParty tricks in order to make the package buildable again (Iâm looking at it too, but have still no clear view/understanding of the program yet, so youâll probably be a lot more efficient). Iâll push my work in progress in a separate branch in case I can make any progress, do not hesitate to do the same (I mean, even if itâs not working yet, something is better than nothing ;). On Sat, Feb 14, 2015 at 04:22:44PM +0100, Georges Khaznadar wrote: David PrĂ©vot a Ă©crit : On Fri, Jan 16, 2015 at 12:11:08PM +0100, Georges Khaznadar wrote: I am enthusiastic about your ITP. If I can help, please tell me! Thanks, do not hesitate to apply into Debian Edu team membership on Alioth, where I initially intend to share the packaging work I am subscribing my e-mail address to debian-...@lists.debian.org ... then, what next ? I actually meant on Alioth [1], in order to have write access to the packaging repository [2]. 1: https://alioth.debian.org/projects/debian-edu 2: https://anonscm.debian.org/gitweb/?p=debian-edu/pkg-team/sankore.git Regards David signature.asc Description: OpenPGP digital signature
Bug#778916: [Pkg-phototools-devel] Bug#778916: darktable: manual focus only works in big steps on Canon EF-S 60mm 1:2.8 USM macro
Marko MÀkelÀ msmak...@gmail.com writes: Package: darktable Version: 1.4.2-1+b3 Severity: normal Dear Maintainer, I am trying to use Darktable with a Canon EOS 650D in tethered mode. When I enable the live viewfinder, I would expect the focus buttons to affect the picture. This is most likely an upstream issue, so can you try darktable from experimental to see if it has the same problem? d -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779163: xfe: Crash after popping up toolbar docking menu.
Package: xfe Version: 1.37-4 Severity: normal Dear Maintainer, Right clicking on any of the toolbar handles to bring up that toolbar's docking popup menu, then left clicking on any toolbar handle (expecting the popup menu to close) crashes Xfe with... Unexpected X error: BadWindow (invalid Window parameter) serial 22611 error_code 3 request_code 4 minor_code 0) Regards, David. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfe depends on: ii libc6 2.19-13 ii libfox-1.6-0 1.6.50-1+b1 ii libfreetype6 2.5.2-2 ii libgcc1 1:4.9.1-19 ii libpng12-01.2.50-2+b2 ii libstdc++64.9.1-19 ii libx11-6 2:1.6.2-3 ii libxft2 2.3.2-1 ii xfe-themes1.37-4 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages xfe recommends: pn audacious none pn xarchiver none pn xfe-i18n none pn xterm none Versions of packages xfe suggests: pn rpm none pn xine-ui none pn xpdf none -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779153: php5: Please package new upstream version 5.4.38 because of CVE-2015-0273
Package: php5 Version: 5.4.36-0+deb7u3 Severity: normal Dear Maintainer, I'm a little concerned that there doesn't seem to be much activity to package php 5.4.38 which came out with the following announcement about a week ago: This release fixes several bugs and addresses CVE-2015-0235 and CVE-2015-0273. All PHP 5.5 users are encouraged to upgrade to this version. This affects squeeze as well, but I have no idea if a patch is available for 5.3. https://security-tracker.debian.org/tracker/CVE-2015-0273 Is there a particular reason for this delay? Thanks, ~David -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.12.20-x86_64-jb1 (SMP w/3 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 php5 depends on: ii libapache2-mod-php5 5.4.36-0+deb7u3 ii php5-common 5.4.36-0+deb7u3 ii php5-fpm 5.4.36-0+deb7u3 php5 recommends no packages. php5 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#770283: debugging 32bit crashes (or lack thereof)
Hi, unfortunately I don't have any good ideas of debugging these 32bit issues. Since it seems to be an issue in how xfburn uses gtk, it won't be easy to find. Some of the gtk code is pretty messy, I admit that, but cleaning it up is a major project. And right now for a lack of time, and small number of 32bit users, I don't think it'll happen. I hate to say that, but it's the realistic answer right now. Thomas, thanks as always for your time to get to the root of the problem! I very much appreciate it. ~David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781274: (pre-approval) unblock: owncloud/7.0.4+dfsg-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please pre-approve an unblock for the owncloud package
It cherry-picks three security fixes from the recently released 7.0.5
version (already in experimental):
owncloud (7.0.4+dfsg-3) unstable; urgency=medium
* Add gbp config file to follow the jessie branch
* Backport security fixes from 7.0.5:
- Multiple stored XSS in contacts application [OC-SA-2015-001]
- Multiple stored XSS in documents application [OC-SA-2015-002]
- Bypass of file blacklist [OC-SA-2015-004]
* Run upgrade script with sudo as www-data user
* Depend on php5-cli (it is actually used in postinst)
-- David Prévot taf...@debian.org Wed, 25 Mar 2015 16:20:32 -0400
Iâd also like to shim in two other small changes:
- the upgrade script should be run as the same user as the installed
data, i.e., www-data by default, instead of root: this recommendation
has recently been enforced upstream since the upgrade process may
touch data files on top of the potential database changes;
- since the php CLI is called during postinst, php5-cli should be a
dependency instead of a recommendation (the README.Debian change just
drops the now useless explanation why php5-cli was recommended).
The attached debdiff stripes away the webodf.js changes from the
cherry-picked commit from upstream: this minified JavaScript files is
anyway regenerated at build time and is thus not the file included in
the actual binary package.
unblock owncloud/7.0.4+dfsg-3
Thanks in advance
Regards
David
diff --git a/debian/README.Debian b/debian/README.Debian
index 72af84d..10f60aa 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -84,8 +84,6 @@ Some apps, not enabled by default, need the following dependencies:
Improve performance: php5-apcu | php5-xcache
php5-intl (language translation)
-Command line interface: php5-cli
-
Suggested packages
~~
diff --git a/debian/changelog b/debian/changelog
index 61c2c40..ee5fd9f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+owncloud (7.0.4+dfsg-3) unstable; urgency=medium
+
+ * Add gbp config file to follow the jessie branch
+ * Backport security fixes from 7.0.5:
+- Multiple stored XSS in contacts application [OC-SA-2015-001]
+- Multiple stored XSS in documents application [OC-SA-2015-002]
+- Bypass of file blacklist [OC-SA-2015-004]
+ * Run upgrade script with sudo as www-data user
+ * Depend on php5-cli (it is actually used in postinst)
+
+ -- David Prévot taf...@debian.org Wed, 25 Mar 2015 16:20:32 -0400
+
owncloud (7.0.4+dfsg-2) unstable; urgency=medium
* Upload to unstable as agreed with the release team
diff --git a/debian/control b/debian/control
index 193fed7..8b79bb2 100644
--- a/debian/control
+++ b/debian/control
@@ -44,9 +44,11 @@ Depends: apache2 | httpd,
php-symfony-console,
php-symfony-routing,
php5 (= 5.3.8),
+ php5-cli,
php5-gd,
php5-json,
php5-mysql | php5-pgsql | php5-sqlite,
+ sudo,
zendframework,
${misc:Depends}
Recommends: exim4 | mail-transport-agent,
@@ -55,7 +57,6 @@ Recommends: exim4 | mail-transport-agent,
php-dropbox,
php-google-api-php-client ( 1),
php5-apcu | php5-xcache,
-php5-cli,
php5-curl,
php5-intl,
php5-ldap,
diff --git a/debian/gbp.conf b/debian/gbp.conf
new file mode 100644
index 000..4e78e26
--- /dev/null
+++ b/debian/gbp.conf
@@ -0,0 +1,3 @@
+[DEFAULT]
+debian-branch = jessie
+upstream-branch = upstream-jessie
diff --git a/debian/patches/0010-Fix-encoding-in-3rdparty-lib.patch b/debian/patches/0010-Fix-encoding-in-3rdparty-lib.patch
new file mode 100644
index 000..537fa3f
--- /dev/null
+++ b/debian/patches/0010-Fix-encoding-in-3rdparty-lib.patch
@@ -0,0 +1,31 @@
+From: Lukas Reschke lu...@owncloud.com
+Date: Fri, 6 Feb 2015 15:12:43 +0100
+Subject: Fix encoding in 3rdparty lib
+
+Origin: upstream, https://github.com/owncloud/contacts/commit/72dcf24061b9639be75851e3746950b61495bc8f
+---
+ apps/contacts/js/contacts.js | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/apps/contacts/js/contacts.js b/apps/contacts/js/contacts.js
+index be551c9..f5d8879 100644
+--- a/apps/contacts/js/contacts.js
b/apps/contacts/js/contacts.js
+@@ -1089,7 +1089,7 @@ OC.Contacts = OC.Contacts || {};
+ this.$fullelem.find('.groupscontainer').show();
+ //this.$groupSelect.find('option').remove();
+ $.each(availableGroups, function(idx, group) {
+- var $option = $('option value=' + group.id + '' + group.name + '/option');
++ var $option = $('option value=' + group.id + '' + escapeHTML(group.name) + '/option');
+ if(self.inGroup(group.name)) {
+ $option.attr('selected', 'selected');
+ }
+@@ -1575,7 +1575,7 @@ OC.Contacts = OC.Contacts || {};
+ var
Bug#780170: Please, update compatibility.js symlink
Control: affects -1 libjs-pdf Hi Johannes, On Mon, Mar 09, 2015 at 09:36:42PM -0400, David PrĂ©vot wrote: Package: pdf2htmlex Iâd like to get rid of the compatibility symlinks introduced in pdf.js 1.0.21+dfsg-1, and thus encourage you to change the /usr/share/pdf2htmlEX/compatibility.js symlink so it points to /usr/share/javascript/pdf/web/compatibility.js Even better: you may use directly /usr/share/pdf.js/compatibility.js as shipped in pdf.js-common (= 1.0.1149) instead of depending on libjs-pdf. You may use a simple debian/links file containing the following line and drop the current override_dh_auto_install from debian/rules: /usr/share/pdf.js/compatibility.js usr/share/pdf2htmlEX/compatibility.js Regards David signature.asc Description: Digital signature
Bug#780039: Please, provide autoload.php
Package: php-tcpdf Version: 6.0.093+dfsg-1 Severity: wishlist Tags: patch Please, find attached a simple patch to build and provide an autoload.php file to ease class loading. Please, also consider using phpcomposer (from pkg-php-tools) in order to at least provide the currently missing dependency on PHP (later, autoload.php support may even be provided by this package helper), and also maintaining this package inside the PHP PEAR (and Composer) Maintainers team (X-Debbugs-CC). Regards David signature.asc Description: Digital signature
Bug#775625: [pkg-php-pear] Bug#775625: Bug#775625: symfony: Review, upload and unblock needed to fix #775625 (FTBFS in jessie)
Hi, Le 30/01/2015 06:30, Daniel Beyer a Ă©crit : Am Montag, den 26.01.2015, 14:41 -0400 schrieb David PrĂ©vot: Maybe the people behind the bug report or ci.d.n will be able to offer a shell to reproduce the issue weâve not managed to reproduce so far⊠A shell would be really great. I think something in Process/Process.php start() [1] is slow on that machine (and if I put a delay in there, I get those errors). However I have no idea what it could be. Who do we need to ask for a shell on ci.d.n? Looks like debian-qa is the expected point of contact: http://ci.debian.net/doc/#label-Contact Antonio is usually responsive for ci.d.n, and I guess Lucas will be able to help giving a shell on aws (that was used for this bug report). I would like to try one more thing and increased the timeout in the test from 0.1s to 0.5s. This is just an other wild guess and still we will not know what really is causing the problem. But it might prevent us from an other FTBFS in BTS. I've already added a new patch in the jessie branch, but did not update d/changelog. If you agree to try this out, it would be great if you could upload a 2.3.21+dfsg-3 to the archives. Iâll take care of the upload later today, thanks for your work on this issue. Regards David signature.asc Description: OpenPGP digital signature
Bug#776063: dbus fails to upgrade rendering entire apt unusable
(sry about leaving you guys hanging⊠I am not exactly blessed with free
time at the moment and this stuff requires the exact opposite⊠anyway,
more a problem description/comment than a solution. Far from the laterâŠ)
On Sun, Jan 25, 2015 at 12:45:10AM +, Simon McVittie wrote:
Is the fix for https://bugs.debian.org/769609 expected to fix this
particular issue, or am I misreading it?
No. Its not fixing any issue at the moment. It will be if dpkg/stretch
drops its compatibility run all runnable pending triggers code, but
that is (not) going to effect you in the jessie - stretch upgrade; not
now nor would it help as this trigger is not runnable (given that dpkg
tries, but ultimatively fails to do so) and all this bug is supposed to
prevent is that triggers which should have been run are not.
So whats the problem? Lets pretend this universe (which is a simplified
realworld one):
Package: systemd-sysv
Depends: systemd
Package: systemd
Postinst: trigger dbus-trig
Package: dbus
Depends: libdbus-1-3
Trigger: interest-await dbus-trig
Package: libdbus-1-3
Now, for simplicity lets just assume all of these packages are already
installed and we are going to install them again. Lets further assume
we pick libdbus-1-3 to be unpacked first and then we deal with the rest,
like this:
dpkg --unpack libdbus-1-3*.deb
dpkg --install systemd*.deb
dpkg --configure libdbus-1-3
So, what you will see is that the second dpkg call will fail because
systemd will end up in 'iW' on dbus which itself can't leave 'it' as it
depends on libdbus-1-3 which is just unpacked ('iU').
This never happened in the past as dpkg would just run the dbus trigger
anyway (not ideal, right?). This new style assumes on the other hand that
a dpkg-frontend like apt is making stuff up on the go rather than
planning out what to do once as for a frontend like apt the need to run
the dbus trigger comes out of no-where and derails the entire plan.
Now the universe constructed above is totally made up in that it is so
simple. In this simple scenario apt doesn't call dpkg in that way. Why
it runs dpkg in this way and insists on it I haven't checked thanks to
time issues, but given that this is the only trigger I know of there it
happens in real life and it isn't even limited to wheezy-upgrades (as
I got this on a sid system (only updated once in a blue moon through)
the other day) I presume its a very special snowflake thing going on
around pseudo-essentials, pre-depends and conflicts which apt is trying
to eagerly to avoid and instead steps on this trigger trap (SCNR).
Or if dropping it down to interest-noawait would help, that isn't
really semantically correct, but it's probably acceptable in practice?
Its not helping the general case of course, but -noawait triggers can't
run in to this problem as nothing can end up in 'iW' with them. So if
you think this is acceptable, I think it might be better than the
alternatives like ripping this out of dpkg again or busy-waiting for me
to figure something out (especially as I doubt that it will be pretty or
even simple if at all solveable for wheezy-upgrades given we only have
apt/wheezy for itâŠ).
Best regards
David Kalnischkies
P.S.: apt isn't recovering in this situation as it ignores 'iW' states,
while it should probably just half-ignore it by trying to get the
system in a state in which the package could be configured, but never
explicitely requesting the trigger processing, but the commit making it
ignore it is years old and as usual: changes to the install-order scare
the shit out of me, especially five minutes before release.
signature.asc
Description: Digital signature
Bug#780319: major regression
Hi, I would like to add that with initramfs-tools 0.116 and lvm2 2.02.111-2 the following fstab entry was mounted just fine during boot when using systemd: /dev/vg0/usr/usrxfs rw,relatime,nodev 0 2 This is a really annoying regression for us. I'm wondering if there would be issue to resolve the /dev/VG/LV path into exactly those components, and then to run the vgchange. After all, this is a valid path in /dev in a running system. ~David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780930: Please, actualy indent bullet (Was: Bug#780930: Please, drop excessive spaces from substvar)
Hi Mathieu,
On Sat, Mar 21, 2015 at 08:50:59PM -0400, David Prévot wrote:
Package: pkg-php-tools
Version: 1.28
I used the /m switch so the beginning of a line could be detected in a
multiline context, but the (existing) replacement for bullets deserves
one too. Feel free to merge the attached patch with the previous one.
+$tmp = preg_replace('/^ /m', '', $tmp);
The package.xml file from php-net-ldap2 contains:
descriptionNet_LDAP2 is the successor of Net_LDAP which is a clone of Perls
Net::LDAP
object interface to directory servers. It does contain most of
Net::LDAPs
features but has some own too.
With Net_LDAP2 you have:
* A simple object-oriented interface to connections, searches
entries and filters.
* Support for TLS and LDAP v3.
[âŠ]
pkg-php-tools currently translates
Description: ${phppear:summary}
${phppear:description}
as:
Description: Object oriented interface for searching and manipulating
LDAP-entries
Net_LDAP2 is the successor of Net_LDAP which is a clone of Perls Net::LDAP
object interface to directory servers. It does contain most of
Net::LDAPs
features but has some own too.
With Net_LDAP2 you have:
* A simple object-oriented interface to connections, searches
entries and filters.
* Support for TLS and LDAP v3.
[âŠ]
After applying the proposed patch, the long description looks more
conventional:
Description: Object oriented interface for searching and manipulating
LDAP-entries
Net_LDAP2 is the successor of Net_LDAP which is a clone of Perls Net::LDAP
object interface to directory servers. It does contain most of Net::LDAPs
features but has some own too.
With Net_LDAP2 you have:
* A simple object-oriented interface to connections, searches entries and
filters.
* Support for TLS and LDAP v3.
[âŠ]
Yet, the long line from the first bullet is wrapped, but the indentation
is not respected, so there is still room for improvement (of the
headache kindâŠ). We may change the bullet handling by:
- split the input by lines
- handle the bullets (indent, and linewrap at 72 characters)
- merge back the input
Yet, that wonât handle correctly an original input like
* A very long line
that continues
on more than a line
Maybe there is already a Dpkg Perl library to handle such description
properly, if not, I may propose a patch to implement the above proposed
behaviour if you think it would still be an improvement.
Regards
David
From fd4fac655291f9172f37fd3440bdc5bc0b913e93 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?David=20Pr=C3=A9vot?= taf...@debian.org
Date: Mon, 23 Mar 2015 12:43:22 -0400
Subject: [PATCH] Actually indent bullets
---
share/php/pkgtools/base/utils.php | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/share/php/pkgtools/base/utils.php b/share/php/pkgtools/base/utils.php
index 0d77ae2..d3c48aa 100644
--- a/share/php/pkgtools/base/utils.php
+++ b/share/php/pkgtools/base/utils.php
@@ -59,7 +59,7 @@ class Utils {
// Drop starting spaces
$tmp = preg_replace('/^ /m', '', $tmp);
// Indent bullets
-$tmp = preg_replace('/^\*/', ' *', $tmp);
+$tmp = preg_replace('/^\*/m', ' *', $tmp);
// Wrap to 80 chars
$tmp = wordwrap($tmp, 78);
// Convert new lines to ${Newline}
--
2.1.4
signature.asc
Description: Digital signature
Bug#483247: Updating grepmail
For what it's worth, I'm in the process of updating grepmail. I don't have ready access to the full CPAN-Testers test matrix, so I can't guarantee that all tests will be passing everywhere. But the obvious failures will be fixed, plus a few bug fixes as well as support for lzip and xz added.
Bug#781414: Embedded code copies
Hi Gunnar, and PHP PEAR Maintainers, On Wed, Apr 01, 2015 at 10:52:54PM -0600, Gunnar Wolf wrote: Sorry for the lateness - I'm currently devoid of free time, and my package maintainance status has suffered :( Itâs not even been a week since that bug was filed, so no need to apologize (and yay, double happy event may drag one into other activities, cheers! ;). - For php-seclib, after a quick diff, the version I currently have in Sid (0.3.8-1) seems clearly newer [...] In your experience, how incompatible would you expect a new version to be? Do you think I could just drop in the new one and not suffer too much? Iâve introduced php-seclib in the archive to get rid of the embedded code copy from ownCloud, and must admit Iâve never notice any BC break: Iâm happy to track the latest php-seclib upstream release for almost two years now, it seems to behave correctly ;). - As for php-htmlpurifier, it seems we are lucky as both packages carry 4.6.0. Thatâs a relief (#764885 would have applied otherwise). However, the one in Collabtive is a standalone file, stating in its header: * This file was auto-generated by generate-includes.php and includes all of * the core files required by HTML Purifier. Use this if performance is a * primary concern and you are using an opcode cache. PLEASE DO NOT EDIT THIS * FILE, changes will be overwritten the next time the script is run. So... Do you know what'd be the best way for this file to be replaced (or generated) from the package we are shipping? Simply requiring 'HTMLPurifier.autoload.php' (or 'HTMLPurifier.includes.php', or 'HTMLPurifier.safe-includes.php', orâŠ) instead of the standalone file should do the trick. Feel free to bug php-htmlpurifier if you really want it to provide a big standalone file, but Iâm not sure thatâs necessary (nor a good idea at first sight). Please, note I only team-uploaded this package once, so I may not be the best person to provide more insight. It looks like most existing PHP classes used as dependencies are currently symlinked. You may consider including them from where they belong instead. I prefered symlinking as it requires less patching of the upstream code. But, of course, if the PHP packaging group's best practices are to patch, I will do so. Just please confirm! Iâm a bit new in the PHP PEAR Maintainers team, other members may provide more insight here. My short experience with ownCloud packaging is that previous maintainers did it that way, and it looks a lot less hackish. E.g., if a file is added in an updated PHP class, as long as that file is not (yet) symlinked from the webapp using it, you may shoot yourself in the foot if this file is called from an existing one⊠Regards David signature.asc Description: Digital signature
Bug#781786: RFA: php-json-patch -- produce and apply json-patch objects
Package: wnpp Severity: normal I request an adopter for the php-json-patch package. I recently packaged it as a php-opencloud dependency, but it already doesnât use anymore. The package description is: json-patch-php implements IETF JSON-patch (RFC 6902) and JSON-pointer (RFC 6901). Regards David signature.asc Description: Digital signature
Bug#782421: Pushed route not handled
Package: network-manager-openvpn Version: 0.9.10.0-1 Severity: normal I have a server withh following directive : push route 62.210.16.3 255.255.255.255 net_gateway When used manually, it works. When connecting through network manager, I get following log Apr 11 23:48:28 bibi NetworkManager[2553]: error [1428788908.759589] [platform/nm-linux-platform.c:1714] add_object(): Netlink error adding 62.210.16.3/32 via 192.168.0.254 dev tun0 metric 1024 mss 0 src user: Unspecific failure 192.168.0.254 being the local gateway I see the pushed command has been understood, however NetworkManager is unable to setup the route. What could be interesting for debug is I also use push redirect-gateway def1 bypass-dhcp block-local (but I get same result without the block-local flag) -- System Information: Debian Release: 8.0 APT prefers testing-proposed-updates APT policy: (900, 'testing-proposed-updates'), (900, 'testing'), (700, 'proposed-updates'), (600, 'stable'), (400, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages network-manager-openvpn depends on: ii libc6 2.19-17 ii libdbus-1-3 1.8.16-1 ii libdbus-glib-1-2 0.102-1 ii libglib2.0-0 2.42.1-1 ii libnm-glib-vpn1 0.9.10.0-7 ii libnm-glib4 0.9.10.0-7 ii libnm-util2 0.9.10.0-7 ii openvpn 2.3.4-5 network-manager-openvpn recommends no packages. network-manager-openvpn 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#782131: (pre-approval) unblock: apt/1.0.9.8
Control: tags -1 - moreinfo Control: retitle -1 unblock: apt/1.0.9.8 Hi, On Sun, Apr 12, 2015 at 02:55:03PM +0200, Julien Cristau wrote: Thanks for this. Let us know when it's uploaded. It is was uploaded yesterday, but we (well, I) took the liberty to add another bugfix to it as Niels made me look at it (for jessie) and seemed supportive (and I didn't want to introduce further delay with an official approval roundtrip â may you and jessie have mercy with my soul). The bug in question is #60, the one 'everyone' is talking about because of ddeb (even through it is kinda unrelated to be honest). The patch is attached there and as one-liney and 'safe' as the rest of this bundle is supposed to be⊠Thanks and best regards David Kalnischkies signature.asc Description: Digital signature
Bug#782517: Could not configure, followed by Internal error, packages left unconfigured.
On Mon, Apr 13, 2015 at 06:05:35PM +0200, Joachim Breitner wrote: $ LANG=C sudo apt upgrade [âŠ] 2 upgraded, 0 newly installed, 0 to remove and 296 not upgraded. Need to get 0 B/47.5 kB of archives. After this operation, 138 kB disk space will be freed. Do you want to continue? [Y/n] E: Could not configure 'libghc-data-lens-template-dev:amd64'. E: Internal error, packages left unconfigured. libghc-data-lens-template-dev:amd64 Interesting. The difference between the commands can be explained: 'install' (and dist-upgrade) can do everything they want to, 'apt upgrade' can install new and upgrade old packages but not remove them and 'apt-get upgrade' can only upgrade packages, so different solutions wouldn't be a problem. That 'apt upgrade' is erroring out like that is one through as that isn't supposed to happen⊠And idealy the three wouldn't grossly disagree, but that just as a bonus⊠Can you attach your /var/lib/dpkg/status file (preferable compressed) ? [I think you know, but the usual disclaimer ramble anyhow: The file contains information about ALL packages you have installed and in what version. In case you don't want or can't expose these details to the public, you can sent it to me privately, if that is acceptable for you] Keeping the directory content of /var/lib/apt/lists someplace save might come in handy, too, but please just back it up somewhere as the resulting file would be too large and is usually not needed, if I can get hold of the Packages files any other way. libghc-data-lens-dev : Depends: libghc-comonad-dev-4.2.5-ae1b1 but it is not installable Depends: libghc-semigroupoids-dev-4.2-68274 but it is not installable Looking at the package names here makes me believe some unofficial/ staging repository is involved through. Is that one public? There are a bunch of debug flags we could try, but with ~300 packages involved that is usually not too much fun to look at via mail⊠Why solver comes to this solution: -o Debug::pkgDepCache::AutoInstall=1 -o Debug::pkgDepCache::Marker=1 -o Debug::pkgProblemResolver=1 How the execution shedule looks and why: -o Debug::pkgOrderList=1 (usually just noise through) -o Debug::pkgPackageManager=1 Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#783032: Minitube segfaults on startup
A better way to handle this would be with a config file instead of having to custom build for everyone. Happy Hacking, David E. McMackins II Associate, Free Software Foundation (#12889) www.mcmackins.org www.delwink.com www.gnu.org www.fsf.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783204: libfilter-perl requires gcc
Package: libfilter-perl Version: 1.45-1 Severity: important Dear Maintainer, I installed libfilter-cpp today on Wheezy. When I attempted to use it: $ head -n 2 filter-cpp.pl #!/usr/bin/perl use Filter::cpp ; $ perl filter-cpp.pl Cannot find cpp at filter-cpp.pl line 2 Compilation failed in require at filter-cpp.pl line 2. BEGIN failed--compilation aborted at filter-cpp.pl line 2. The problem was that there was no executable file named 'cc' in my $PATH. The solution was to install the 'gcc' Apt package. So, the 'libfilter' Apt package meta-data needs to indicate that the 'gcc' Apt package is required. David -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libfilter-perl depends on: ii libc6 2.13-38+deb7u8 ii perl5.14.2-21+deb7u2 ii perl-base [perlapi-5.14.2] 5.14.2-21+deb7u2 libfilter-perl recommends no packages. Versions of packages libfilter-perl suggests: ii perl [libcompress-zlib-perl] 5.14.2-21+deb7u2 -- 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#783028: uwsgi: mongrel2 plugin is missing
Package: uwsgi Version: 2.0.7-1 Severity: wishlist Dear Maintainer, the mongrel2 capabilities of uwsgi are missing in debian, whereas the mongrel2 example file is provided (/usr/share/doc/uwsgi/examples/mongrel2-uwsgi.conf) Is there a technical reason for the mongrel2 plugin not to be built and provided in a dedicated uwsgi-mongrel2 package? Thanks, David -- System Information: Debian Release: 8.0 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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages uwsgi depends on: ii initscripts 2.88dsf-58 ii lsb-base 4.1+Debian13+nmu1 ii uwsgi-core 2.0.7-1 uwsgi recommends no packages. uwsgi 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#782872: [Aptitude-devel] Bug#782872: aptitude: SIGSEGV got when create New Categorical Browser
Hi, (not the maintainer, I don't even have aptitude installled and have no idea what 'New Categorical Browser' means at the moment but still) On Sun, Apr 19, 2015 at 01:06:39PM +0800, Zhang Jingqiang wrote: When I try to get a New Categorical Browser from the curses menu, SYSSEGV happened. I install aptitude-dbg and run gdb aptitude, got the following output Program received signal SIGSEGV, Segmentation fault. __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:30 30 ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file or directory. It's always reproducible on my laptop. Can you please run 'bt' (backtrace) in gdb as a strcmp call could (and is) everywhere in aptitude or deeper down in the stack. Does this happen 'for a while' now or did you find out about it only recently? Maybe only since an upgrade of x, y and z? That could be highly state dependent (especially if it isn't aptitude but libapt failing here) so I wanted to chirp in before this state is lost to an update/upgrade or something. Maybe make a backup of /var/lib/apt/ and /var/lib/dpkg/status somewhere, in case we find out the relevant state is dependent on those. No such bug found on my cubietruck. btw: Is cubietruck 'armhf' or 'armel'? Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#780673: gitolite3: git-annex shell is not working: FATAL: bad git-annex-shell command - patch available
conc...@web.de writes: patch 780673 + jessie severity 780673 serious thanks I've just upgraded to Jessie and tried to download some data and now my repositories are broken and I cannot do anything with them. I only get get foo/bar (not available) Try making some of these repositories available: 52f2bae6-e67e-11e4-a474-0021ccb48233 (Note that these git remotes have annex-ignore set: origin) failed git-annex: get: 1 failed and it doesn't even want to work after I've applied the patch. New clones seem to work with the data which was already on the server but my other ones seem to be now broken and I have possible data loss. It seems more likely that the annex data is still there in the server repositories. You can check with % git annex findref HEAD as the gitolite user, in the gitolite server copy of the repository. Two things to check 1) Did you intend to have git.origin.annex-ignore set? this can happen if git-annex is convinced a remote is inaccessible (due to e.g. problems with git-annex-shell) 2) Do the annex uids match between .git/config in the local repo and the remote repo? You can check with git annex info in both places. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782871: apt (1.0.9.8) prevents aptitude handling forget-new properly.
Control: reassign -1 aptitude Control: forcemerge 782777 -1 Control: affects -1 apt On Sun, Apr 19, 2015 at 01:00:59PM +0900, Hae-woo Park wrote: Recently I upgraded the following packages from 1.0.9.7 to 1.0.9.8: apt, apt-utils, libapt-inst1.5, libapt-pkg4.12. (I am using sid.) After then aptitude could not handle 'forget-new' (and 'markauto'?) properly. When type 'f' (or 'M') for those instruction in aptitude, it seems working; but after restarting aptitude the status went back. Note that the 'markauto' issue was tested only with 'new' packages. So now I've rolled back those 4 packages, and aptitude properly forgets the new packages by 'forget-new'. This wierdness is discussed over at aptitude with #782777, so I am merging with it and let you guys figure it out because I can't reproduce it here with pure apt(-mark) and this aptitude thingy is pure black magic for my eyes and ears (on of these days I might start it). From what I read there it isn't clear to me that a downgrade actually fixes things. It seems more to fumble around stuff so that it pops up someplace else. My biggest problem with it is through that nothing in the vincity of the autobit handling changed in 1.0.9.8. Not even close to it. The closest is maybe parse specific-arch dependencies correctly on single-arch systems, but that just because it is the binary cache creation changed, which is state potentially shared between different versions of libapt, but is reshuffled on 'update' and at least partly with every change to the dpkg/status. I didn't invalidate the cache with a version bump, which from a (very) theoretical standpoint is incorrect, but that just means you are effected by the bug this commit is fixing until after the cache is invalidated next (given that just one package satisfying the criteria exists at all in all of Debian, that isn't as bad as it might sound â especially as the fix is for jessie and this one package is sid only). That is working the other way around, too, through as a downgrade isn't breaking it again instantly either. What I can see is that the two reporters who provided the information are single-arch systems, so they would be effected by this bug, for multi-arch systems nothing changed. Now, all that being said, this bears no relation to 'new' nor 'auto' as this is about dependencies being created incorrectly. At the most its removing packages as this bug created package structures with a bad name so they couldn't be found later, but that also means these bad packages never had a version belonging to it and I doubt aptitude considers those as new (and they are gone now, not added, so if anything, 1.0.9.8 would fix itâŠ). But yes, its the best I got, even through I have no idea what could be it as the other fixes I would consider even less likely to influence the outcome of aptitude than the current moon phase: - apt-key changes do not effect aptitude at all - VectorizeString is called by aptitude only in mkdir_parents, which is itself never called by aptitude⊠- WriteApportReport is disabled in Debian by default, called only by libapt itself and only as a reaction to a dpkg error while stuff is installed. Also, its a crash fix⊠- pkgAcquire::Item::Mode is another crash fix, a crash theoretically not happening and indeed never happening for 5 years in C++ code. Only python3 seems to manage to trigger it. Also only acts while stuff is being fetched from the interwebs. - https is, well, a seperate binary never called directly by aptitude, nor does it see the communication with it. Used also only while fetching stuff from the (encrypted) interweb. - a typo in the commandline parsing of apt-get. And that was it, all 7 changes in 1.0.9.8. Fun fact: This mail has more lines than 2 times the amount of changed code lines (which itself counts changes twice as one line added and one line removed) in the diff between 1.0.9.7 and 1.0.9.8. Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#783325: jessie rc3 requires nomodeset in grub.cfg to boot an i386 iMac with a radeon vga.
Package: firmware-linux-nonfree Bug: jessie rc3 requires nomodeset in grub.cfg to boot an i386 iMac with a radeon vga. The system is a Core Duo (i386) iMac model 4,1. 2GB ram, 250GB hard drive. Pertinent information from the install is appended: lspci, parted, fstab. rEFInd 0.8.7 was used to boot the Jessie rc3 i386 dvd1. rEFInd is installed on /dev/sda5. The system installed normally. I did not have a working wifi connection or hardwired ethernet. I've never gotten a flash drive set up and working with the Broadcom b43 driver to load. After installation rEFInd shows two Debian swirls for two efi bootloaders. On the initial boot using the grubia32.efi icon, the system appeared to halt after doing the fsck. I went into rescue mode, modified /etc/default/grub to remove quiet as an option. Then rebuilt the /boot/grub/grub.cfg file by using grub-mkconfig -o /boot/grub/grub.cfg This time, the verbose display shows the system halted right after a switch to the radeon framebuffer. I then changed the linux line in /boot/grub/grub.cfg to end in ro nomodeset to not switch to the radeon framebuffer. (I know I need to change file /etc/grub.d/10_linux to make this change permanent.) The iMac now completes the Jessie rc3 boot. I didn't have to do this for wheezy... as I recall, the radeon firmware load failed and wheezy continued booting without acceleration. Congrats to everyone that contributed to making EFI work on this buggy EFI hardware. The package used for this report is firmware-linux-nonfree because I couldnt think of anything closer. This package does not have a driver for this model radeon vga. wifi works after manually setting up the /lib/firmware/b43 directory from a tarball made under wheezy. lspci output: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03) 00:07.0 Performance counters: Intel Corporation Device 27a3 (rev 03) 00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 2 (rev 02) 00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7-M Family) SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 02) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV530/M56-P [Mobility Radeon X1600] 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 22) 03:00.0 Network controller: Broadcom Corporation BCM4311 802.11a/b/g (rev 01) 04:03.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) partition listing from parted: (parted) print Model: ATA WDC WD2500JS-40N (scsi) Disk /dev/sda: 250GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 1 20.5kB 210MB 210MB fat32 EFI System Partition boot, esp 2 210MB 50.2GB 50.0GB hfs+iMacGLW 3 50.4GB 140GB 90.0GB hfs+devel 4 140GB 150GB 9866MB hfs+comhfs 5 150GB 151GB 999MB hfs+rEFInd 6 151GB 152GB 99.6MB aBios 7 152GB 152GB 99.6MB bBios msftdata 8 152GB 154GB 2000MB ext2aBoot msftdata 9 154GB 156GB 2000MB ext2bBoot msftdata 10 156GB 196GB 40.0GB ext4aRoot msftdata 11 196GB 236GB 40.0GB ext4bRoot msftdata 12 236GB 239GB 3000MB linux-swap(v1) aSwap 13 239GB 242GB 3000MB linux-swap(v1) bSwap msftdata 14 242GB 250GB 8371MB linux-swap(v1) ctest msftdata # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a
Bug#781274: unblock: owncloud/7.0.4+dfsg-4
Hi, On Sat, Apr 25, 2015 at 10:17:33PM +0200, Salvatore Bonaccorso wrote: David, CVE-2015-3011 is exploitable if a victim user tries to edit a specially crafted contact item which he has access to? Indeed, I managed to craft a group name, allowing to inject JavaScript when editing the contact. The fix prevent to execute such JavaScript. On the other hand, I have not yet managed to figure out a PoC allowing to share the crafted field with another user (but thatâs probably just me not being aware of all features: upstream description is pretty clear about this attack vector. If the victim can only be the attacker, that would be pointless anywayâŠ). Regards David signature.asc Description: Digital signature
Bug#783315: RFA: doctrine-sphinx-theme -- Sphinx theme used by Doctrine
Package: wnpp Severity: normal I request an adopter for the doctrine-sphinx-theme package. I initially packaged it to build doctrine-orm-doc, but we donât build it anymore (not DFSG compliant anymore), so Iâm not interested anymore into its maintenance (and will ask for its removal if nobody shows any interest into it before Stretch). The package description is: This is the common Sphinx theme for all Doctrine project documentations. Regards David signature.asc Description: Digital signature
Bug#783421: Useless in Debian
Package: php-auth-http Version: 2.1.8-1 Severity: serious [Filled as RC by a team member to see it autoremoved from testing if nobody disagrees. Please, do downgrade it with an explanation if you disagree.] php-mime-type is only used by extplorer (removed from testing over a year ago), and has not been updated upstream in years (some bug have been filed upstream since the latest release without a reply, not sure itâs still maintained). I intend to follow up with an RM request in a few months if nobody objects (but feel free to beat me to it). Regards David signature.asc Description: Digital signature
Bug#783423: RM: php-mdb2-schema -- ROM; Useless in Debian
Package: ftp.debian.org Severity: normal php-mdb2-schema was introduced a few years ago as an owncloud dependency (that now uses Doctrine instead), has not been updated upstream in over six years, and wasnât ship with Jessie (nobody complained since it has been removed from testing over six months ago). I believe itâs time to acknowledge that this package is not useful in Debian anymore. Regards David signature.asc Description: Digital signature
Bug#783430: Useless in Debian
Package: php-mail-mbox
Version: 0.6.3-1
Severity: serious
[Filled as RC by a team member to see it autoremoved from testing if
nobody disagrees. Please, do downgrade it with an explanation if you
disagree.]
Hi,
Raphaël (X-D-CC) requested this package (#678093) as a Tuleap
dependency, but tuleap is not in Debian (not even {IT,RF)Pâed AFAICT).
Thomasâ concerns raised over two years ago in the RFP are still valid
(upstream package is not maintained, and âthe package is marked as
quality beta and there has been no upstream release since end of
2009â).
Furthermore, the package has a very low popcon.
I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).
Regards
David
signature.asc
Description: Digital signature
Bug#783422: Useless in Debian
Package: php-services-json Version: 1.0.3-1 Severity: serious [Filled as RC by a team member to see it autoremoved from testing if nobody disagrees. Please, do downgrade it with an explanation if you disagree.] php-services-json is only used by extplorer (removed from testing over a year ago), and has not been updated upstream in years (some bugs have been followed up by a reply, or commit to their VCS two years ago, but no release happened in four years, not sure itâs still maintained). I intend to follow up with an RM request in a few months if nobody objects (but feel free to beat me to it). Regards David signature.asc Description: Digital signature
Bug#783427: Useless in Debian
Package: php-xml-rss Version: 1.0.2-3 Severity: serious [Filled as RC by a team member to see it autoremoved from testing if nobody disagrees. Please, do downgrade it with an explanation if you disagree.] php-xml-rss has no reverse (build-)dependencies, has not been updated upstream in the last four years, and is officially not maintained upstream anymore. At least another package (libphp-magpierss) seem to provide similar features (but doesnât seem to be much maintained either), other XML parser might be useful to provide equivalent features (e.g., php-sabre-xml, actively maintained, or php-picofeed currently in NEW). I intend to follow up with an RM request in a few months if nobody objects (but feel free to beat me to it). Regards David signature.asc Description: Digital signature
Bug#783420: Useless in Debian
Package: php-mime-type Version: 1.3.1-1 Severity: serious [Filled as RC by a team member to see it autoremoved from testing if nobody disagrees. Please, do downgrade it with an explanation if you disagree.] php-mime-type is only used by extplorer (removed from testing over a year ago), and is not maintained upstream anymore (the version in Debian even predates the latest upstream version). I intend to follow up with an RM request in a few months if nobody objects (but feel free to beat me to it). Regards David signature.asc Description: Digital signature
Bug#783425: RM: php-event-dispatcher -- ROM; Useless in Debian, alternative exists
Package: ftp.debian.org Severity: normal php-event-dispatcher has not been updated upstream in over six years, and wasnât ship with Jessie (nobody complained since it has been removed from testing over six months ago), itâs also a low popcon. php-symfony-event-dispatcher seems to provide equivalent features, is actively maintained upstream (and in Debian ;), and has reverse dependencies in Debian. I believe itâs time to acknowledge that this package is not useful in Debian anymore. Regards David signature.asc Description: Digital signature
Bug#783426: RM: php-http-upload -- ROM; Useless in Debian, unmaintained upstream
Package: ftp.debian.org Severity: normal php-http-upload has not been updated upstream in the last five years, and is not maintained upstream anymore. It wasnât ship with Jessie (nobody complained since it has been removed from testing over six months ago). I believe itâs time to acknowledge that this package is not useful in Debian anymore. Regards David signature.asc Description: Digital signature
Bug#783429: RM: php-config -- ROM; Useless in Debian, alternative exists
Package: ftp.debian.org Severity: normal php-config has not been updated upstream in the last five years, and wasnât ship with Jessie (nobody complained since it has been removed from testing over six months ago). php-symfony-config seems to provide equivalent features, is actively maintained upstream (and in Debian ;), and has reverse dependencies in Debian. I believe itâs time to acknowledge that this package is not useful in Debian anymore. Regards David signature.asc Description: Digital signature
Bug#779887: Useless PHP PEAR packages (Was: Bug#779887: Useless in Debian)
Control: severity -1 serious Raising back the severity: if people are actually using or depend on any of these packages, now may be a good time to say so before they get removed (in the mean time, that should prevent automatic migration to testing). On Sat, Mar 07, 2015 at 10:47:47AM +0100, Ivo De Decker wrote: Please file a removal bug (for jessie or unstable, depending on what you think is best) for them in a few days. I still intend to follow up with a removal request in a few months if nobody objects (but feel free to beat me to it). Regards David signature.asc Description: Digital signature
Bug#779889: Is php-structures-datagrid-renderer-htmltable useful in Debian?
Control: clone -1 -2 Control: retitle -2 Useless in Debian Control: severity -2 serious On Thu, Mar 05, 2015 at 07:49:07PM -0400, David PrĂ©vot wrote: Package: php-structures-datagrid-renderer-htmltable Hi Cyril, The Homepage set in php-structures-datagrid-renderer-htmltable should point to the following URL: http://pear.php.net/package/Structures_DataGrid_Renderer_HTMLTable/ I canât help noticing in that page that the upstream package is not maintained, that the Debian package does not have any reverse (build-)dependencies, and (thus) have a very low popcon, do you still use/need it in the archive? Cloning this bug as RC: if people are actually using or depending on this package, now may be a good time to say so before it gets removed (in the mean time, that should make it automatically get removed from testing once all the release scripts are back on business). I intend to follow up with a removal request in a few months if nobody objects (but feel free to beat me to it). Regards David signature.asc Description: Digital signature
Bug#783438: Useless in Debian
Package: php-calendar Version: 0.5.5-2 Severity: serious [Filled as RC by a team member to see it autoremoved from testing if nobody disagrees. Please, do downgrade it with an explanation if you disagree.] php-calendar is a leaf package that has not been updated upstream in the last five years (even a bug report filed two days after the last release doesnât have any follow up), not sure itâs still maintained. Furthermore, the package has a very low popcon. I intend to follow up with an RM request in a few months if nobody objects (but feel free to beat me to it). Regards David signature.asc Description: Digital signature
Bug#762132: same issue, no hibrid
I am having the same issue, but my note is not a hibrid It's a lenove g40 70 with a radeon r5 230. I used the aticonfig --initial Now i removed the drivers because i was without my pointer -- David Aguiar de Aquino Paiva
Bug#783278: flash-kernel: Specifying Boot-Kernel-Image does nothing unless Dtb-Append, Machine-Id or U-Boot-Kernel-Address is also specified
Package: flash-kernel Version: 3.35 Severity: normal Dear Maintainer, * What led up to the situation? trying to use flash-kernel with a Raspberry Pi. * What exactly did you do (or not do) that was effective (or ineffective)? Created a .db file with: Machine: BCM2708 Boot-Kernel-Path: /boot/flash/kernel.img Then ran flash-kernel * What was the outcome of this action? flash-kernel should have copied the kernel, but instead did nothing and returned successfully. * What outcome did you expect instead? The kernel at /boot/vmlinuz-latest-version should have been copied to /boot/flash/kernel.img -- System Information: Distributor ID: ev3dev Description:ev3dev GNU/Linux testing (jessie) Release:testing Codename: jessie Architecture: armv6l Kernel: Linux 3.18.11-dlech+ (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages flash-kernel depends on: ii debconf [debconf-2.0] 1.5.56 ii devio 1.2-1+b1 ii initramfs-tools0.120 ii linux-base 3.5 ii ucf3.0030 Versions of packages flash-kernel recommends: ii u-boot-tools 2014.10+dfsg1-5 flash-kernel suggests no packages. -- Configuration Files: /etc/flash-kernel/db changed: Machine: Raspberry Pi -- debconf information: * flash-kernel/linux_cmdline: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783278: patch v2
Tags: patch I botched the first patch. This one fixes it correctly. From 6eb082b42ad9a7c22f08ecb9f18fab7f8891be95 Mon Sep 17 00:00:00 2001 From: David Lechner da...@lechnology.com Date: Fri, 24 Apr 2015 19:13:00 -0500 Subject: [PATCH] Handle case when kernel == kfile check in boot_kernel_path handler. This only applies to Method: generic. Old behavior: If the db entry specifies Boot-Kernel-Path, one of Dtb-Append, Machine-Id or U-Boot-Kernel-Address must be specified which changes the value of $kernel. When checking what to do wht Boot-Kernel-Path, the script checks to see if $kernel was changed from the original value ($kfile). If it did not change, it does nothing. There is a TODO comment about handling symlinks, but this does not make sense since this is the generic method, not the symlink method. New behavior: If $kernel was not changed, copy it to a temporary file before calling backup_and_install. backup_and_install moves the temporary file, effectivly deleting it. Also applied same fix to initrd. Use case: On Raspberry Pi, the boot loader uses the vmlinux-* file directly, but it needs to be renamed to kernel.img, which flash-kernel should be doing. --- functions | 20 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/functions b/functions index a7ff6de..6579b18 100644 --- a/functions +++ b/functions @@ -684,13 +684,11 @@ case $method in if [ -n $boot_kernel_path ]; then boot_kernel_path=$boot_mnt_dir/$boot_kernel_path # don't mv the original kernel - if [ $kernel != $kfile ]; then -backup_and_install $kernel \ - $boot_kernel_path - else -# TODO add support for kernel symlink -: + if [ $kernel = $kfile ]; then +cp $kernel $tmpdir/kernel +kernel=$tmpdir/kernel fi + backup_and_install $kernel $boot_kernel_path elif [ -n $kmtd ]; then flash_kernel $tmpdir/uImage $kmtd rm -f $tmpdir/uImage @@ -706,13 +704,11 @@ case $method in if [ -n $boot_initrd_path ]; then boot_initrd_path=$boot_mnt_dir/$boot_initrd_path # don't mv the original initrd - if [ $initrd != $ifile ]; then -backup_and_install $initrd \ - $boot_initrd_path - else -# TODO add support for initrd symlink -: + if [ $initrd = $ifile ]; then +cp $initrd $tmpdir/initrd +initrd=$tmpdir/initrd fi + backup_and_install $initrd $boot_initrd_path elif [ -n $imtd ]; then ipad=0 # padding isn't needed for U-Boot images -- 1.9.1
Bug#783278: patch
Here is how I have fixed the problem (attached patch). There was an if statement with a TODO that was not implemented, so I just took it out. From 20cea9a9506575a40a439766fb3e9d4bbb7587cb Mon Sep 17 00:00:00 2001 From: David Lechner da...@lechnology.com Date: Fri, 24 Apr 2015 19:13:00 -0500 Subject: [PATCH] remove kernel != kfile check in boot_kernel_path handler. This only applies to Method: generic. Old behavior: If the db entry specifies Boot-Kernel-Path, one of Dtb-Append, Machine-Id or U-Boot-Kernel-Address must be specified which changes the value of $kernel. When checking what to do wht Boot-Kernel-Path, the script checks to see if $kernel was changed from the original value ($kfile). If it did not change, it does nothing. There is a TODO comment about handling symlinks, but this does not make sense since this is the generic method, not the symlink method. New behavior: The check to see if $kernel changed is removed. As long as Boot-Kernel-Path is specified, flash-kernel will copy the kernel to the specified path. Use case: On Raspberry Pi, the boot loader uses the vmlinux-* file directly, but it needs to be renamed to kernel.img, which flash-kernel should be doing. --- functions | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/functions b/functions index a7ff6de..34e7536 100644 --- a/functions +++ b/functions @@ -684,13 +684,7 @@ case $method in if [ -n $boot_kernel_path ]; then boot_kernel_path=$boot_mnt_dir/$boot_kernel_path # don't mv the original kernel - if [ $kernel != $kfile ]; then -backup_and_install $kernel \ - $boot_kernel_path - else -# TODO add support for kernel symlink -: - fi + backup_and_install $kernel $boot_kernel_path elif [ -n $kmtd ]; then flash_kernel $tmpdir/uImage $kmtd rm -f $tmpdir/uImage -- 1.9.1
Bug#700337: kibana depends on logstash
Sorry for reviving an old thread, but the ITP is still open so I'm having hope. :) On Wed, 23 Jul 2014 14:52:26 -0400 Antoine Beaupré anar...@debian.org wrote: i don't see how kibana could get into debian without logstash... so i marked this as being dependent on logstash packaging (664841). Kibana, Logstash and Elasticsearch are often used together but are completely independent pieces of software, which don't even need to run on the same host, or to work together at all for that matter. Having a package for Kibana would already be awesome per se, and having one for Logstash would be awesomer ;) but the latter is not required in order for the former to work. Jose Manuel dos Santos Calhariz jose.calha...@netvisao.pt wrote: But now I have a sponsor for kibana. Jose, are you still in the process of packaging Kibana 3? Also, Kibana 4 is now out - do you have any plans to package it? Thanks. --David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782777: actions on specific packages don't work on single-arch systems
Control: reassign -1 apt 1.0.9.8 Control: affects -1 aptitude Control: severity -1 important Control: tags -1 patch Control: retitle -1 actions on specific packages don't work on single-arch systems Hi, (the mail starts with a LOT of technical bla bla a user doesn't need to concern itself with. I have cc'ed all reporters explicitly through as I would like them to try the workarounds mentioned further below, so feel free to skip over the technical reasoning straight to the 'meat'. And if you gonna reply, please ONLY to the bugreport, thanks!) On Tue, Apr 21, 2015 at 08:17:36PM +0200, Axel Beckert wrote: David already seems to on to something... After quite some hair-pulling and the occasional swearing which Axel thankfully endured I finally arrived at a rather misfortune conclusion (at least for me): I was wrong, which is quite a hurtful experience as I had put quite a bit of energy into preventing it⊠So, desperate me claiming the fix for #60 would have a low regression risk as there aren't that many packages in existence which expect this behaviour, I forgot to consider a potential side-effect: The correct creation of a package foo from architecture alien1 can if we haven't seen the package foo from our native architecture yet claim the price of being the first known package foo. The first place is assumed to belong to the package of the native architecture through, so a libapt application asking for the package foo of native architecture will get unconditionally handed the first package foo found, which if we are unlucky is the one for alien1 and not native⊠This assumption used to be true, but with the advent of architecture specific dependencies (and the deprecated policy-forbidden packages without architecture) not so much anymore. It is to be noted that not all architecture specific dependencies actually trigger this, they just have the potential to do it, if they do depends very much on the order of things, but we will get to that in a minute. Analysing amd64 sid+experimental you can find the following effected: libstdc++6-4.9-dbg arm64 libgcc-4.9-dev arm64 libgcc1-dbg arm64 libgomp1-dbg arm64 libitm1-dbg arm64 libatomic1-dbg arm64 libasan1-dbg arm64 liblsan0-dbg arm64 libtsan0-dbg arm64 libubsan0-dbg arm64 libcilkrts5-dbg arm64 libquadmath-dbg arm64 libgfortran-4.9-dev arm64 libgfortran3-dbg arm64 u-boot armhf (the second column is the architecture the first package is created for, which should have been amd64 if the made assumption would be valid). We have seen the names of most of them in this bugreport already, Axel used libgcc1-dbg in his example. The situation is a bit different for jessie sources: Only u-boot is effected here. u-boot:amd64 doesn't exist btw. (The reason is that crossbuild-* doesn't exist there). Note that this error doesn't add up, but can decrease with additional sources. Having testing+sid+experimental enabled e.g. leaves you with only two of them still on the list (if you have it in this exact order). Architectures aren't created equally either, but they are all playing in the same ballpark, so list isn't changing much if at all between archs. Bug #782889 mentions other packages effected on jessie through, and Axel has an example with libgnutls26 on an amd64 with sid+experimental, so how does these happen? It took me longer to realize than it should have, but it is actually quite simple now that I had a good 'talk' with my pillow: In my testing I was using either only the component main or the components main contrib non-free (in that order), but if you happen to do (lets say) contrib main you end up with these in addition: libldap-2.4-2 i386 libdb5.3 i386 libgnutls26 i386 libsasl2-2 i386 libsasl2-modules i386 libsasl2-modules-db i386 Which minus the libgnutls26 are also exactly the packages #782889 mentions for jessie (libgnutls26 isn't existing nor even referenced in this release, so the package comes never into existence for apt here). [and they are the only packages mentioned by the bugreport, so not all jessie users are effected at all â see also workaround 1.] So, what is the effect you might ask now: There are more or less four ways to get to a package in libapt. 1. You can follow a dependency. There is no lookup involved here, this will always point to the correct package as this one is prebuild with 2. 2. You get a Grp-structure, which has a FindPkg(arch) method giving you the package you desire. 3. You iterate over ALL packages one after the other (that sounds ridiculous stupid, but is done a lot as you usually have to touch them all in some way anyway) 4. You are asking the cache directly with a FindPkg(name[, arch]) call for a package. Only the last one is effected as this path includes a detection for single-arch which then has the incorrect assumption of the first package being the native package. The attached patch removes the single-arch special casing in this codepath, which means that the same code as on multi-arch is used
Bug#783714: mcron: Claims inability to read crontab for root
Package: mcron Version: 1.0.8-1 Severity: important I can send my crontab if needed. I have a file /root/.cron/job.guile with my crontab in it (per the instructions for mcron). If I run mcron, it compiles my crontab (typical guile behavior), and then it tells me that it cannot read the files in my .cron directory. Of course, it had to have read them to compile them, so maybe it's talking about the compiled output. I checked the permissions on them and made them identical to those of the text crontab, and the error persists. Regular users on the system are able to use mcron just fine, but the root account seems stuck. Notably, it does not fail if the crontab is an empty file. Here is the CLI output if I run it myself as root (the process exits with code 13): # mcron mcron: Cannot read files in your ~/.config/cron (or ~/.cron) directory. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) 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 Init: systemd (via /run/systemd/system) Versions of packages mcron depends on: ii dpkg1.17.25 ii guile-2.0 2.0.11+1-9 ii guile-2.0-libs 2.0.11+1-9 ii install-info5.2.0.dfsg.1-6 ii libc6 2.19-18 ii libgc1c21:7.2d-6.4 ii postfix [mail-transport-agent] 2.11.3-1 mcron recommends no packages. mcron 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#783552: [Pkg-mozext-maintainers] Bug#783552: Useless (superseded by native features)
Control: retitle -1 Doesnât work with recent iceweasel Hi Mike, Axel, Thanks for your quick follow up, On Tue, Apr 28, 2015 at 11:01:21PM +0200, Axel Beckert wrote: Mike Gabriel wrote: David PrĂ©vot wrote: As far as I can tell, the native fullscreen feature (F11) of current iceweasel versions provides the actual fullscreen this extension used to provide [âŠ] Actually, the F11 key didn't use to be scriptable (via prefs.js et al). That was my original motivation to upload xul-ext-fullscreen to Debian. At that time, I needed a browser on a customer system that started in fullscreen right away. Similar case here. Our event information displays run iceweasel with the fullscreen extension and ratpoison with window border size 0 as window manager. OK, so that extension is still useful then. I actually just notice that xul-ext-fullscreen 1.0.4 is unusable with Iceweasel 32.x. That's a pity. Indeed. Ouch, thatâs worse than I thought then, updating the bug title accordingly. Does the extension still work with Iceweasel 31 (as currently in Jessie)? If this extension is not maintained upstream anymore, maybe another one could be used instead (I just came across full-fullscreen [1], but it looks even less maintained than the current one). 1: https://addons.mozilla.org/en-US/firefox/addon/full-fullscreen/ There is the following note on this page [1]: âNote from Mozilla: This add-on has been discontinued. Try one of these [2] instead.â 2: https://addons.mozilla.org/fr/firefox/search/?q=kioskcat=all Among the list, at least one shares a similar namespace [3] and was updated more recently (well, 2012, donât hold your breath). 3: https://addons.mozilla.org/fr/firefox/addon/FF_Fullscreen/ If there is a another similar (possibly sharing the namespace) extension, changing the upstream source for this package could be an option. If the features can be found within another âkioskâ extension, maybe should it be packaged (and have it provide xul-ext-fullscreen, and whatever is needed to help a smooth transition). Thatâs my 2 cents worth to the discussion, Iâll let those who care about this feature take care of the best way forward (my initial interest, and the reason why I raised this issue, is that Iâm currently trying to make a little cleanup in the mozext team â e.g., make sure that all watch files are still working after the ârecentâ AMO change, so we donât miss new upstream version). Regards David signature.asc Description: Digital signature
Bug#783790: kerberos ticket written to wrong file
Package: kscreensaver Version: 4:4.14.2-1 Severity: normal On a system with kerberos authentication (through pam-krb5) Login through kdm, the ticket is written in a file (eg /tmp/krb5cc_4468_CkfHCh) and environment variable KRB5CCNAME is setup accordingly. Ater unlocking the screen, the ticket is written in another file, eg /tmp/krb5cc_pam_wFd4iA and original ticket file deleted. This makes ALL kerberos using programs client lose their way to get authenticattion through kerberos, unless the ticket file is manually renamed. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (900, 'testing'), (600, 'stable'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates'), (400, 'unstable') 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 Init: systemd (via /run/systemd/system) Versions of packages kscreensaver depends on: ii kde-runtime 4:4.14.2-2 ii kde-workspace-bin 4:4.11.13-2 ii libc6 2.19-18 ii libgl1-mesa-glx [libgl1] 10.3.2-1 ii libglu1-mesa [libglu1]9.0.0-2 ii libkdecore5 4:4.14.2-5 ii libkdeui5 4:4.14.2-5 ii libkexiv2-11 4:4.14.2-1 ii libkio5 4:4.14.2-5 ii libkparts44:4.14.2-5 ii libkscreensaver5 4:4.11.13-2 ii libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-3 ii libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-3 ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-3 ii libstdc++64.9.2-10 ii libx11-6 2:1.6.2-3 Versions of packages kscreensaver recommends: ii kde-window-manager 4:4.11.13-2 Versions of packages kscreensaver suggests: ii kscreensaver-xsavers 4:4.14.2-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783545: Doesnât work, abandonned upstream
Package: xul-ext-automatic-save-folder Version: 1.0.4-3 Severity: serious Hi, I was updating this package (to at least fix the watch file, but went a bit further, see the wip branch I just pushed), but was not able to make it work (even on a Jessie system with iceweasel 31.6.0esr-1). The (annoyingly ever displayed) extra tab explains very well what should be done, but I donât get the Automatic Save Folder menu under the âWhat should Firefox do with this file?â box. Am I missing something? There are similar complaints on the amo review page [1], so maybe itâs âjustâ an incompatibility with recent iceweasel versions. Since upstream maintenance ended [2], Iâm not sure there is much to do to fix the issue. 1: https://addons.mozilla.org/en-US/firefox/addon/automatic-save-folder/reviews/ 2: http://asf.mangaheart.org/?menu=5f=1t=167 I even tried to fetch the latest version from the upstream VCS to see if it works but didnât get any further. Maybe the em:maxVersion29.* from install.rdf is to take seriously. Please, do follow up if the extension works for you. Unless someone objects, Iâll request a removal of this package in a few months (or sooner depending on the feedback). Regards David -- System Information: Debian Release: 8.0 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (100, 'buildd-unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.0-trunk-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) xul-ext-automatic-save-folder depends on no packages. Versions of packages xul-ext-automatic-save-folder recommends: ii iceweasel 37.0.2-1 xul-ext-automatic-save-folder suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#783535: Please, allow dh to pass parameters
Package: mozilla-devscripts Version: 0.39 Severity: wishlist Hi, It would be nice the xul_ext buildsystem would honor the dh feature to pass parameters to the program that is run in its dh_auto_* target. E.g, it would allow us to use a simple rule like: %: dh $@ --with xul-ext --buildsystem=xul_ext -- --remove-license-files -x GPL instead of overriding the whole dh_auto_install target to pass the --remove-license-files option to install-xpi: override_dh_auto_install: install-xpi --remove-license-files -x GPL *.xpi Regards David P.-S.: if the GPL file were removed by --remove-license-files, I wouldnât complain either ;). signature.asc Description: Digital signature
Bug#756573: Useless in Jessie
Control: retitle -1 Useless in Debian On Wed, Jul 30, 2014 at 10:19:33PM -0400, David PrĂ©vot wrote: Package: php-mssql-bundle [Filled as an RC-bug by the maintainer to exclude packages from testing] php-mssql-bundle has recently been introduced as an owncloud dependency, but proper MsSQL support has been postponed to owncloud 8 Actually, itâs becoming less realistic to see proper support of MsSQL in the community version of ownCloud. Furthermore, MsSQL support may not be a feature worth providing in Debian anyway. I intend to follow up with an RM request before Stretch gets released if the situation doesnât evolve and nobody objects. In the mean time, Iâm keeping this RC bug open to prevent migration to testing. Regards David signature.asc Description: Digital signature
Bug#783552: Useless (superseded by native features)
Package: xul-ext-fullscreen Version: 1.0.4-1 Severity: serious [Filled as RC by a team member to see it autoremoved from testing if nobody disagrees. Please, do downgrade it with an explanation if you disagree.] As far as I can tell, the native fullscreen feature (F11) of current iceweasel versions provides the actual fullscreen this extension used to provide (I was an happy user of it with my 9â screen eeepc a few years ago). There hasnât been any upstream release since almost four years, and the popcon is very low. I intend to follow up with an RM request in a few months if nobody objects (but feel free to beat me to it). Regards David signature.asc Description: Digital signature
Bug#756580: Useless in Jessie
Control: retitle -1 Useless in Debian On Thu, Jul 31, 2014 at 12:23:06AM -0400, David PrĂ©vot wrote: Package: php-irods-prods [Filled as an RC-bug by the maintainer to exclude package from testing] php-irods-prods [âŠ] is a beta version (last activity upstream was about one year ago), so there is little point to release it On Fri, Jul 25, 2014 at 05:59:23PM +0200, Roman Valls Guimera wrote: I just noticed the following RFA: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748608 And your comment: I recently packaged it because it was used by owncloud, but that wonât be true anymore with the upcoming version 7 currently available in experimental. It might not be in core, but itâs still shipped as an app: https://github.com/owncloud/files_irods If someone intends to package owncloud-files-irods in Debian, of course it would be useful to keep php-irods-prods in the archive. In the mean time, I still advocate keeping this RC bug open to prevent migration to testing. Since there has only been a very low activity on files_irods upstream (only 4 commits, the last one being almost a year ago), Iâm not sure itâs currently realistic to see it packaged in the near future. If the status doesnât change until Stretch gets released, I would probably advocate a removal from the archive, but we can delay such decision until then. Regards David signature.asc Description: Digital signature
Bug#783560: RFA: php-crypt-blowfish -- Allows for quick two-way blowfish encryption without requiring the MCrypt PHP extension
Package: wnpp Severity: normal I request an adopter for the php-crypt-blowfish package. Mathieu used to care about this package as used by Horde, and so did I since it was used by ownCloud, but thatâs not true anymore. I believe itâs now superseded by php-seclib anyway. If someone cares about php-crypt-blowfish, now might be a good time to step up (including joining upstream maintenance: the last stable upstream release was almost ten years ago). The package description is: This package allows you to perform two-way blowfish encryption on the fly using only PHP. This package does not require the MCrypt PHP extension to work, although it can make use of it if available. Regards David signature.asc Description: Digital signature
Bug#779514: wxul-ext-requestpolicy: asks to allow manual inputed requests
Hi, On Sun, Mar 01, 2015 at 06:17:34PM -0400, David Prévot wrote: Please, keep the bug CC (full quote for the bug log), and please also answer the last question (are more versions also affected or not?). Ping? Please also document if the issue is fixed in 0.5.28-1 (as available in Jessie and Sid) or 1.0.0~beta8.2+dfsg-1 (as available in experimental). 1.0.0_beta9.1+dfsg-1 has now been uploaded to experimental. Regards David signature.asc Description: Digital signature
Bug#780170: Please, update compatibility.js symlink
Hi Johannes, On Sat, May 02, 2015 at 11:16:33PM +0200, Johannes Schauer wrote: Quoting Johannes Schauer (2015-03-18 21:13:51) Quoting David PrĂ©vot (2015-03-18 21:05:11) Even better: you may use directly /usr/share/pdf.js/compatibility.js as shipped in pdf.js-common (= 1.0.1149) instead of depending on libjs-pdf. I'll make the change as soon as Jessie is released :) I just uploaded the new pdf2htmlex upstream version to unstable but did not include the symlink change because pdf.js-common (= 1.0.1149) seems to still be in experimental only. Iâve uploaded 1.1.1+dfsg-2 to Sid now. I will make the change once pdf.js-common (= 1.0.1149) appears in unstable. That should happen in a few minutes ;). What is the advantage/reason of depending on compatibility.js in pdf.js-common instead of the one in libjs-pdf? pdf.js-common just ship the common files shared by libjs-pdf and xul-ext-pdf.js (and soon, pdf2htmlex too). libjs-pdf only ships a symlink to the actual file (well, two actually, but Iâll get rid of the extra one once this bug is fixed ;). Since libjs-pdf is about as big as pdf.js-common (and depend on it), using pdf.js-common directly will save (your users) one package, almost 1MB to download, and almost 3MB on disk for each installation. Symlinking to a symlink (that is already symlinking to a symlink) may not be the most effective thing anyway. Regards David signature.asc Description: Digital signature
Bug#774797: initramfs-tools: Include bcache.ko by default
Sorry for getting back so late on this issue. On 2015-01-07 11:46, Andreas Kloeckner wrote: I'm therefore suggesting that at the very least bcache.ko (and perhaps also bcache-tools) should be made part of the default initramfs image. I totally agree. /usr/share/initramfs-tools/hooks: bcache This file exists on your system and does install bcache.ko into the initrd: % lsinitramfs /boot/initrd.img-3.16.0-4-amd64 | grep bcache lib/modules/3.16.0-4-amd64/kernel/drivers/md/bcache lib/modules/3.16.0-4-amd64/kernel/drivers/md/bcache/bcache.ko lib/modules/3.16.0-4-amd64/kernel/fs/mbcache.ko lib/udev/probe-bcache lib/udev/rules.d/69-bcache.rules lib/udev/bcache-register Maybe the initramfs somehow did not get updated on your system? ~David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774797: initramfs-tools: Include bcache.ko by default
On 2015-05-02 16:58, Andreas Kloeckner wrote: That does exist, and it appears to be doing its job, but it comes from the bcache-tools package. That's not entirely what I'm talking about though. I'm more concerned about an annoying bootstrap issue that I've faced multiple times when installing Debian onto a bcache volume. Here's what I currently have to do: - Format as bcache using some live system - Reboot into d-i. - From within the debian installer, unpack bcache.ko out of the installer's kernel .deb, insmod it. - Register the bcache, install to it. - Reboot into the new system. Oops, boot fails, because there's no bcache.ko. Back to a live system, drop the right bcache.ko into /boot, reboot, insmod it, register the bcache, boot. (*) - Then install bcache-tools, and things start looking up. (*) This step is the most annoying, and what I'd like to see fixed. Alternatively, if d-i understood that I'm installing onto bcache and installed bcache-tools, my problem would also be solved... Ah, yes, so it's all about the installer. That was not obvious to me from the original bug report. Ideally I'd like to see full installer support but I don't know how much effort is involved. It is something that has been on my personal TODO list, and will get tackled sometimes now that jessie is out of the door. Thanks, ~David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784178: jessie-pu: package php-horde-passwd/5.0.2-3+deb8u1
Hi Mathieu, Le 03/05/2015 16:10, Mathieu Parent a Ă©crit : php-horde-passwd in jessie (5.0.2-3) has a typo bug in the Kolab driver (#780670) which needs a one-line fix. It looks like Sid is still affected. Can you please get a fixed version in Sid: I believe the release team will expect to have the fix in the archive before considering backporting it into stable. Regards David signature.asc Description: OpenPGP digital signature
Bug#783893: htop: Crashes with very specific input (fixed upstream)
Package: htop Version: 1.0.3-1 Severity: normal This is fixed in htop version 1.0.4, so it just needs an update. Steps: - Open htop - Strike F4 to do a process search - Type at least one letter into the search - Strike End, Home, then End again -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) 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 Init: systemd (via /run/systemd/system) Versions of packages htop depends on: ii libc6 2.19-18 ii libncursesw5 5.9+20140913-1+b1 ii libtinfo5 5.9+20140913-1+b1 htop recommends no packages. Versions of packages htop suggests: pn ltrace none ii strace 4.10-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783975: ITP: giac -- computer algebra system
Hi Petter, This software is used (among other places) in French schools, and provides menu/exercises related to the students level. How many langauges is the program translated to? po/ and doc/ contain: de, el, en, es, fr, pt, and zh (as well as it, but only in po/). The full documentation is advertised to be available both in English and Spanish (the French one being available under a not DFSG compliant license), but that status seems to have evolved. The upstream source is big (175Â MB) so I have not yet a clear view of what is actually relevant. Regards David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783975: ITP: giac -- computer algebra system
Package: wnpp Severity: wishlist Owner: David Prévot taf...@debian.org * Package name: giac Version : 1.2.0 Upstream Author : Bernard Parisse pari...@fourier.ujf-grenoble.fr * URL : http://www-fourier.ujf-grenoble.fr/~parisse/giac.html * License : GPL-3 Programming Lang: C++ Description : computer algebra system Giac is a computer algebra system, following the development of the CAS for HP calculators. It has fast implementation of algorithms for polynomial operations, and compatibility mode with Maple or Mupad CAS as well as TI calculators. This software is used (among other places) in French schools, and provides menu/exercises related to the students level. I intend to maintain this package under the Debian Edu team umbrella. Regards David signature.asc Description: Digital signature
Bug#773249: lists.debian.org: New list: debian-dug-washington-dc
On Mon, Dec 15, 2014 at 07:11:58PM -0500, Aaron M. Ucko wrote: Package: lists.debian.org Severity: wishlist Greetings! On behalf of the Washington, DC, US Debian developer community, I would like to request an official debian-dug-* list to supplant our current teams.debian.net list. (I'm sending a copy of this request to the list to solicit seconds from other members.) Last I checked, we had roughly a dozen full DDs, and several more who were going through various stages of NM. I do not have access to the current subscriber list, but perhaps the teams.d.n listmasters (Cc:ed as well) can share it with you; in the worst case, we can just fully reboot the list and ask everyone to resubscribe. I propose calling the new list debian-dug-washington-dc, but am open to alternative suggestions. (That said, please note that the area has three airports, so I'd rather not single out one.) We have not historically had a web archive, but I for one would be open to establishing one; subscription has always been public anyway. I can reconstruct only partial archives of the current list, but perhaps other members (or the teams.d.n listmasters) have more complete records. Here are the formal parameters, which correspond to what we have now modulo the addition of a web archive: Name: debian-dug-washington-dc Rationale: See above. Description: Discussion list for Debian community in Greater Washington Discussion list for the Debian Community in Washington, DC, US and surrounding areas. Category: Miscellaneous Debian Subscription Policy: open Post Policy: open Web Archive: yes Thanks in advance for considering this request; please let me know if you need anything else from me. Hello, Thanks for filling your interest to create a new mailing list. What's the current status of your community? It's been a few months since you requested the mailing list and I want to see if the interest is still current, etc. Also, did you confirm the availability of the archives? Thanks, damog, your listmaster for the day. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783441: Useless in Debian
Package: liboauth-php Version: 0~svn1262-1 Severity: serious [Filled as RC by the maintainer to see it autoremoved from testing if nobody disagrees. Please, do downgrade it with an explanation if you disagree.] liboauth-php is a leaf package that never had any proper release, and had not seen any activity in its VCS in over four years, not sure itâs still maintained (not much activity in upstream bug tracker in the last four years either). I intend to follow up with an RM request in a few months if nobody objects (but feel free to beat me to it). Regards David signature.asc Description: Digital signature
Bug#784152: linux: Queued TRIM causes ATA timeouts on Samsung SSD 850 Pro
Source: linux Severity: important Tags: upstream patch Dear Maintainer, The Samsung SSD 850 Pro produces ATA timeouts with queued TRIM. The problem is already fixed upstream, by blacklisting the device for queued TRIM. Fixed in commit 6fc4d97a4987c5d247655a157a9377996626221a libata: Blacklist queued TRIM on Samsung SSD 850 Pro https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=6fc4d97a4987c5d247655a157a9377996626221a -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) 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 Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784136: Blocks when enabling logs display
Package: filezilla Version: 3.9.0.5-1 Severity: normal When clicking on the toggle display logs button, filezilla blocks and must then be killed. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (900, 'testing'), (700, 'oldstable-proposed-updates'), (600, 'stable'), (500, 'proposed-updates'), (400, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages filezilla depends on: ii filezilla-common 3.9.0.5-1 ii libatk1.0-0 2.14.0-1 ii libc62.19-18 ii libcairo21.14.0-2.1 ii libdbus-1-3 1.8.16-1 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-4 ii libgcc1 1:4.9.2-10 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libgnutls-deb0-283.3.14-2 ii libgtk2.0-0 2.24.25-3 ii libidn11 1.30-1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-01.36.8-3 ii libsqlite3-0 3.8.7.4-1 ii libstdc++6 4.9.2-10 ii libtinyxml2.6.2 2.6.2-2 ii libwxbase3.0-0 3.0.2-1+b1 ii libwxgtk3.0-03.0.2-1+b1 Versions of packages filezilla recommends: ii xdg-utils 1.1.0~rc1+git20111210-7.4 filezilla 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#784421: Hibernate does not work
Package: kde-workspace Version: 4:4.11.13-2 Severity: normal On a fresh jessie install, hibernate writes to disk then power off the laptop. However at restart, it reads the disk, then reboot. systemctl hibernate works, so the underlying mechanism should be Ok. -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') 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 Init: systemd (via /run/systemd/system) Versions of packages kde-workspace depends on: ii freespacenotifier 4:4.11.13-2 ii kde-window-manager 4:4.11.13-2 ii kde-workspace-bin 4:4.11.13-2 ii klipper 4:4.11.13-2 ii ksysguard 4:4.11.13-2 ii systemsettings 4:4.11.13-2 Versions of packages kde-workspace recommends: ii kdm 4:4.11.13-2 ii kinfocenter 4:4.11.13-2 ii kmenuedit4:4.11.13-2 kde-workspace 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#784427: virt-manager: unsupported configuration: spicevmc not supported in this QEMU binary
Package: virt-manager
Version: 1:1.0.1-5
Severity: normal
Tags: upstream
Dear Maintainer,
virt-manager cannot create VMs when connected to some older libvirt-bin
versions due to the lack of configuration options to chose vnc over spice.
I'm using virt-manager in jessie to adminstrate an Ubuntu 12.04 libvirt-bin
0.9.8-2ubuntu17.20. The older libvirt installation does not yet support spice.
I used virt-manager to successfully connect via ssh+qemu and I can successcully
start/stop those VMs. But when attempting to create a new one:
Connection - New)
Connection: myserver (QEMU/KVM)
Chose ho you would like to install the operating system: Local install media
(ISO image or CDROM)
Use ISO image: /var/lib/libvirt/images/debian-8.0.0-amd64-netinst.iso
OS type: Linux
Version: Debian Wheezy (od later)
Memory (RAM): 1024
CPUs: 1
Enable storage for this virtual machine: True
Select managed or other existing storage: /dev/myvgname/mylvname
I get:
Unable to complete install: 'unsupported configuration: spicevmc not supported
in this QEMU binary'
Traceback (most recent call last):
File /usr/share/virt-manager/virtManager/asyncjob.py, line 91, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File /usr/share/virt-manager/virtManager/create.py, line 1787, in do_install
guest.start_install(meter=meter)
File /usr/share/virt-manager/virtinst/guest.py, line 403, in start_install
noboot)
File /usr/share/virt-manager/virtinst/guest.py, line 467, in _create_guest
dom = self.conn.createLinux(start_xml or final_xml, 0)
File /usr/lib/python2.7/dist-packages/libvirt.py, line 3440, in createLinux
if ret is None:raise libvirtError('virDomainCreateLinux() failed',
conn=self)
libvirtError: unsupported configuration: spicevmc not supported in this QEMU
binary
I am aware that the libvirt server does not support spice but I was not able to
select vnc as the graphics configuration. I also noticed that I was never
asked for the name of the vm-entry, but I guess that would be another bug
report.
I suppose that this is an upstream issue, so I have tagged the report as such,
but I haven't verified it since I'm a bit at a loss on how I wold successfully
install an upstream version of virt-manager with the correct versions of it's
dependancies.
I believe the fix would be to add the configuration options the UI to
explicitly set the graphics settings. I'm not sure how to go about the channel
settings which locally also refer to spice settings, but do not appear in the
setting of the older server.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 8.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages virt-manager depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1
ii gconf2 3.2.6-3
ii gir1.2-gtk-3.0 3.14.5-1
ii gir1.2-gtk-vnc-2.0 0.5.3-1.3
ii gir1.2-libvirt-glib-1.0 0.1.9-4
ii gir1.2-vte-2.90 1:0.36.3-1
ii librsvg2-common 2.40.5-1
ii python-dbus 1.2.0-2+b3
ii python-gi3.14.0-1
ii python-gi-cairo 3.14.0-1
ii python-ipaddr2.1.11-2
ii python-libvirt 1.2.9-1
ii python-urlgrabber3.9.1-4.1
pn python2.7:anynone
pn python:any none
ii virtinst 1:1.0.1-5
Versions of packages virt-manager recommends:
ii gir1.2-spice-client-gtk-3.0 0.25-1+b1
ii gnome-icon-theme 3.12.0-1
ii libvirt-daemon-system1.2.9-9
Versions of packages virt-manager suggests:
ii gnome-keyring3.14.0-1+b1
ii python-gnomekeyring 2.32.0+dfsg-3
pn python-guestfs none
pn ssh-askpass none
ii virt-viewer 1.0-1
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784626: x11-common: Hi,
Package: x11-common Version: 1:7.7+8 Severity: normal Dear Maintainer, With the latest update to sid x11 released a day or so ago (1:7.7+8) x fails to start. This has be traced to /usr/bin/X (wrapper for X) is not configured, and /etc/X11/xinit/xserverrc refers to this. Now I've hacked /etc/X11/xinit/xserverrc to point to /usr/bin/Xorg This means I can start X - but only as root, as not surprising permissions to start X where in the /usr/bin/X wrapper. Any ideas of a better fix? I could just create a link with the right sticky bit set - but seems better to fix at source. Thanks, David -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.0.0 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages x11-common depends on: ii debconf [debconf-2.0] 1.5.56 ii lsb-base 4.1+Debian13+nmu1 x11-common recommends no packages. x11-common suggests no packages. -- debconf information: * x11-common/xwrapper/allowed_users: Console Users Only x11-common/xwrapper/actual_allowed_users: console -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784606: csvtool: please supply a real man page
Package: csvtool Version: 1.3.3-1 Severity: wishlist as noted in the current stub, the information is there in the output of cvstool --help, but this is less convenient for users (e.g. no pager, extra command invokation) -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages csvtool depends on: ii libc6 2.19-18 csvtool recommends no packages. csvtool 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#784548: apt-get update race condition in candidate dependency resolution
Control: severity -1 normal Control: merge -1 717679 On Wed, May 06, 2015 at 04:39:05PM +0200, Stefan Schlesinger wrote: Justification: could cause unwanted versions to be installed without notice Severity: grave No*. At least if you are careful you have a few chances of noticing it. The -V option e.g. tells you the versions. The download progress tells you were stuff comes from. Running apt-get update on a system at the same time with other apt commands, causes apt to resolve package dependencies and policies inconsistently. Behavior causes race conditions during package cache update, resulting in altered candidate versions and you will end up with unwanted versions being installed (eg. when running 'apt-get upgrade -yâ or working with unattended-upgrades). Current stable version in Jessie - 1.0.9.8 is also affected. Every version ever in existence in the last 17 years is effected. That it survived 17 years is reason enough to not give it RC severity. Also note that you need root-rights to run 'apt-get update' (or equivalent) commands, much like you need root-rights to run 'rm -rf /'. rm got over the years safeguards to prevent this, but this will never be perfect and we are much in the same position. In the end root is the only account who can do everything, but it should be asked if that means that it should do everything. Maybe running multiple apt commands in parallel is just in general not a good idea⊠and btw, neither it is for dpkg or any other package management tool. Many things are heavily interlocked here working in concert to make package installation possible. Sometimes I think 'we' higherlevel parts like apt just made it too easy. On every other plattform which can be updated nobody would ever ask for running stuff in parallel, simply because those happen in total lockdown⊠IMO, this should either be an atomic file/directory move, once package files where downloaded successfully, or apt-get update should make use of locking as well. This isn't really about the Packages files, but about the Release files and only on a second step about all the other files apt downloads. What sounds like a trivial implementation happily explodes into a code nightmare with only slightly less edgecases than decimal places of pi. We are slowly getting better, but there is only so much you can do with the resources we have⊠We saw this issue affecting multiple apt commands and actions: Everyone using libapt is effected if you will, so even stuff like the typical software-center. And not all these are started and/or always working as root, so just 'locking' is not an option if you don't happen to forbid every use of libapt as non-root in the process and only allow libapt to be loaded by only one root application at the time. That would immensly cripple the useability for next to no gain⊠Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#784310: apt update always fails on experimental/non-free
Hi, On Tue, May 05, 2015 at 09:43:53AM +0200, Cesare Leonardi wrote: root@etna:~# apt update Get:1 http://httpredir.debian.org unstable InRelease [204 kB] Hit http://httpredir.debian.org experimental InRelease [âŠ] Err http://httpredir.debian.org experimental/non-free amd64 Packages Hit http://httpredir.debian.org experimental/non-free amd64 Packages Fetched 298 kB in 4s (66,2 kB/s) Would be nice if you could run apt update -o Debug::Acquire::http=1 (This enables a lot of output resembling the messages send between server(s) and the apt client(s). Probably best to redirect the output to a file with e.g.: 21 | tee apt-update.log as the different interactions happen in parallel, so the output can be a confusing mix of stuff on first look). We are working in /experimental on revamping the acquire system at large which is what is behind downloading stuff and shared between all package managers based on libapt, so apt and aptitude do exactly the same here. I am in particular working currently in my branch on the behavior of getting a 'Hit' for a (In)Release(.gpg) file currently, which is what you got in your example and likely most of the time as non-free experimental isn't changing a lot. Note that this Err isn't critical, apt happily recovers from many 'errors' as getting them is normal. apt implements an HTTP1.1 client which tries to use many features of HTTP1.1, but many servers running on mirrors implement only a subset of the features. And many different subsets. Not to mention that some downright refuse to implement them correctly (one of the sillier examples is e.g. #778375 or pipelining, my personal favorite). Unfortunately the internet isn't implemented based on specs, but based on what popular browsers use and support (which isn't much â its pretty ironic that our selfwritten test webserver supports more of HTTP1.1 than most 'real' webservers. And its only getting worse)⊠Usually you are not told about such errors, but it looks like one slipped through here. I haven't looked at the 'old' source, but I have a suspicion, which the debug output hopefully confirms: The server is supporting Range-requests, but not If-Range and hence answers with a 416, but not with Content-Range set. I at least have a faint memory of encountering such a server recently with these symptoms. So, summary: If the debug output isn't proofing me horribly wrong (possible), I am going to close this bugreport (if unreproducible with our forthcoming new acquire system) as this is a 'display issue' and the fix is basically our 'webservers are idiots' rewrite^Wrework⊠;) signature.asc Description: Digital signature
Bug#784654: ITP: chaussette -- WSGI (meta)server you can use to run your Python WSGI applications
Package: wnpp Severity: wishlist Owner: David Douard david.dou...@logilab.fr * Package name: chaussette Version : 1.2 Upstream Author : Mozilla Foundation Contributors services-...@lists.mozila.org * URL : https://chaussette.readthedocs.org * License : Apache 2.0 Programming Lang: Python Description : WSGI (meta)server you can use to run your Python WSGI applications Chaussette is a WSGI server you can use to run your Python WSGI applications. The particularity of Chaussette is that it can either bind a socket on a port like any other server does or run against already opened sockets. That makes Chaussette the best companion to run a WSGI or Django stack under a process and socket manager, such as Circus or Supervisor. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784653: ITP: circus -- Circus is a Process Socket Manager
Package: wnpp Severity: wishlist Owner: David Douard david.dou...@logilab.fr * Package name: circus Version : 0.12.0 Upstream Author : Mozilla Foundation Contributors services-...@lists.mozila.org * URL : http://circus.readthedocs.org * License : Apache 2.0 Programming Lang: Python Description : Circus is a Process Socket Manager Circus is a Python program which can be used to monitor and control processes and sockets. Circus can be driven via a command-line interface, a web interface or programmatically through its python API. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784427: closed by Guido GĂŒnther a...@sigxcpu.org (Re: [Pkg-libvirt-maintainers] Bug#784427: virt-manager: unsupported configuration: spicevmc not supported in this QEMU binary)
There is no customize configuration before install option available. In fact the Step 4 of 5 and Step 5 of 5 are almost idenitcal UI elements with the exception that the text of the Forward button is changed to Finish. Am Mittwoch, den 06.05.2015, 15:18 + schrieb Debian Bug Tracking System: This is an automatic notification regarding your Bug report which was filed against the virt-manager package: #784427: virt-manager: unsupported configuration: spicevmc not supported in this QEMU binary It has been closed by Guido GĂŒnther a...@sigxcpu.org. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Guido GĂŒnther a...@sigxcpu.org by replying to this email. -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate) signature.asc Description: This is a digitally signed message part
Bug#784765: libsane-common: upgrade failure
Package: libsane-common Version: 1.0.24-10 Severity: serious On Fri, May 08, 2015 at 04:13:01PM +0200, Jörg Frings-FĂŒrst wrote: fixed 784257 sane-backends/1.0.24-10 [âŠ] a fixed version is uploaded to sid. A broken version of a fix. Please, consider using debian/libsane-common.maintscript as documented in dh_installdeb(1), it will add the accurate entry (and wont forget the dpkg-maintscript-helper call). $ LC_ALL=C sudo aptitude upgrade Resolving dependencies... The following packages will be upgraded: libsane-common The following partially installed packages will be configured: libsane sane-utils 1 packages upgraded, 0 newly installed, 0 to remove and 3 not upgraded. Need to get 0 B/999 kB of archives. After unpacking 0 B will be used. Do you want to continue? [Y/n/?] Reading changelogs... Done (Reading database ... 567089 files and directories currently installed.) Preparing to unpack .../libsane-common_1.0.24-10_all.deb ... /var/lib/dpkg/tmp.ci/preinst: 9: /var/lib/dpkg/tmp.ci/preinst: rm_conffile: not found dpkg: error processing archive /var/cache/apt/archives/libsane-common_1.0.24-10_all.deb (--unpack): subprocess new pre-installation script returned error exit status 127 Errors were encountered while processing: /var/cache/apt/archives/libsane-common_1.0.24-10_all.deb Regards David signature.asc Description: Digital signature
Bug#784972: network-manager-openconnect does not ask for username/password
Package: network-manager-openconnect Version: 0.9.10.0-1 Severity: grave When trying to connect through openconnect and networkmanager 1) network-manager does not ask for password, I immediately get an error Necessary secrets for the VPN connection were not provided. 2) in the logs I see May 11 11:53:31 erdavid-lt NetworkManager[795]: (NetworkManager:795): libnm-util-CRITICAL **: get_secret_flags: assertion 'is_secret_prop (setting, secret_name, error)' failed May 11 11:53:32 erdavid-lt NetworkManager[795]: error [1431338012.235800] [vpn-manager/nm-vpn-connection.c:1721] plugin_need_secrets_cb(): (dd464b6b-5c9f-4cd4-9915-3d339a3f8e14/DMZ Paris) final secrets request failed to provide sufficient secrets Thus it is impossible to use network-manager for an openconect/anyconnect VPN. PS : connecting directly using openconect, it works -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') 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 Init: systemd (via /run/systemd/system) Versions of packages network-manager-openconnect depends on: ii adduser 3.113+nmu3 ii libc6 2.19-18 ii libdbus-1-3 1.8.16-1 ii libdbus-glib-1-2 0.102-1 ii libglib2.0-0 2.42.1-1 ii libnm-glib-vpn1 0.9.10.0-7 ii libnm-glib4 0.9.10.0-7 ii libnm-util2 0.9.10.0-7 ii network-manager 0.9.10.0-7 ii openconnect 6.00-2 network-manager-openconnect recommends no packages. network-manager-openconnect 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#783278: patch v2
Yes, you guessed correctly. The v2 patch is the good one. On 05/03/2015 03:19 AM, Ian Campbell wrote: Hi David, On Fri, 2015-04-24 at 21:25 -0500, David Lechner wrote: Tags: patch I botched the first patch. This one fixes it correctly. Thanks for the patch(es). The buglog at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783278 has somehow ended up with the message ordering confused. I'm pretty certain that the patch which should be correct is this one labelled in the subject as v2 at Message #10 and not what I suppose is v1 which for some reason didn't arrive until Message #15. The date headers match this interpretation. I suppose the first mail got delayed somehow on its way to the BTS so they appear in the opposite order in the log. I thought I ought to double check! Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762090: xul-ext-perspectives: javascript error poped up after i confirmed to whitelist my local net range
Hi treaki, If Iâm not mistaken, you havenât provided the information requested over five months ago, could you please do so now? Reminder follows: On Wed, Dec 10, 2014 at 09:10:24PM -0400, David PrĂ©vot wrote: On Fri, Nov 28, 2014 at 12:53:13AM +0100, treaki wrote: On 12/10/14 18:33, David PrĂ©vot wrote: Please, rather provide an error log. How can i create such an error log? From /usr/share/doc/xul-ext-perspectives/README: To debug the extension: * Edit the d_print_flags in plugin/chrome/content/common.js [ i.e,, /usr/share/xul-ext/perspectives/chrome/content/common.js ] * Reload the extension and restart your browser * Use the Firefox extension 'Firebug' to view what's happening as Perspectives runs Feel free to try [âŠ] other debug methods (cf. https://developer.mozilla.org/en/Setting_up_extension_development_environment) Please also test if the issue still exist with the latest version (4.6 is currently available from experimental, and soon from unstable). Regards David signature.asc Description: Digital signature
Bug#784290: Too strict version in ${misc:Recommends}
Package: apache2-dev
Version: 2.4.12-1
Severity: normal
Control: affects -1 owncloud
Hi,
Thanks for making our live easier with this tool!
I recently added â--with apache2â with a basic debian/apache2 file into
a packaged webapp.
$ cat debian/apache2
conf debian/config/apache/owncloud.conf
I noticed that since apache2-dev has been upgraded to 2.4.12-1, it now
generates the following ${misc:Recommends}:
apache2 (= 2.4.12~) | httpd
Yet, nothing changed in the generated code since last time I built the
webapp:
$ debdiff --controlfiles ALL ../owncloud_8.1.0~alpha[âŠ]
[âŠ]
No differences were encountered between the conffiles files
[âŠ]
[âŠ], apache2 (= [-2.4.10~)-] {+2.4.12~)+} | httpd
[âŠ]
No differences were encountered between the postinst files
No differences were encountered between the postrm files
No differences were encountered between the prerm files
That seems wrong to recommend the latest apache2 version just because
the package was built with the latest apache2-dev version, since nothing
requires it (there is no reason the package wouldnât work with the
previous apache2 version, 2.4.10, as available in Jessie).
Please, do not let apache2-dev bump the version unless it is actually
required: it will just makes it more painful to use such webapp in a
different but compatible environment (or require to rebuild it in the
other environment just to unbump the version in the control file,
without any other change).
Thanks in advance.
Regards
David
-- System Information:
Debian Release: stretch/sid
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'),
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (100,
'buildd-unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.18.0-trunk-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages apache2-dev depends on:
ii debhelper9.20150502
ii libapr1-dev 1.5.1-3
ii libaprutil1-dev 1.5.4-1
ii openssl 1.0.2a-1
ii perl 5.20.2-4
apache2-dev recommends no packages.
apache2-dev suggests no packages.
-- no debconf information
signature.asc
Description: Digital signature
Bug#784868: korganizer: korgac grabs focus loosing keys and missing notifications
Package: korganizer
Version: 4:4.14.1-1nograb
Severity: important
Tags: patch upstream
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
While it can make it easier to dismiss (if it grabs focus through the
activateWindow call), it also means if you are typing and a reminder
comes in it will both get those keystrokes and a space or return will
dismiss the reminder before you have a chance to ever see what the
reminder was about, which assumes you are even looking at your screen
to see the reminder box flash up, if you are typing from paper you
might not even know.
This patch will call raiseWindow instead of activateWindow, but adds a
dock menu item to grab focus if someone actually wants that behavior.
While I was add it I added a dock menu item to show the reminder
window, which was useful in debugging, and lets you get at items that
have been suspended, alloing to view or dismiss them. This might
satisfy Bug 302865 - Inaccessible reminders
There is a code comment Try to keep the dialog small and
non-obtrusive. I've made it smaller by default, and set the minimum
size even smaller than reasonable, but this is better than the
previous which wouldn't let you size it smaller than the default.
I added more points to save the position and improve the logic, now it
will save and restore the position and size, and then show the window
so it will no longer jump.
Patch is against Debian 4.14.1 source tree. The korgac in the
previous Debian release, 4.4.11 does not grab the keyboard when the
notification dialog appears.
Reproducible: Always
Steps to Reproduce:
1. set korganizer reminder
2. start typing a paragraph
3. continue typing as the notification goes off
Actual Results:
watch korgac reminder appear grab keyboard focus and vanish at the
next space, depending on the timing you have no chance to stop typing
before it is gone
Expected Results:
The notifier window to appear at the last location it was dismissed at
and only get focus when the window manager directs focus to it.
I'm flagging the severity at important, because it was so disruptive I
had stopped using it until I fixed it.
From bb8f84deeefaaf74bc285fc2534111a78a5f12ff Mon Sep 17 00:00:00 2001
From: David Fries da...@fries.net
Date: Sat, 9 May 2015 10:48:10 -0500
Subject: [PATCH 1/5] add an option to not grab keyboard focus when a reminder
is displayed
While it can make it easier to dismiss (if it grabs focus through the
activateWindow call), it also means if you are typing and a reminder
comes in it will both get those keystrokes and a space or return will
dismiss the reminder before you have a chance to ever see what the
reminder was about, which assumes you are even looking at your screen
to see the reminder box flash up, if you are typing in a paper you
might not even know.
---
korgac/alarmdialog.cpp | 12 +++-
korgac/alarmdialog.h | 1 +
korgac/alarmdockwindow.cpp | 15 +++
korgac/alarmdockwindow.h | 7 +++
4 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/korgac/alarmdialog.cpp b/korgac/alarmdialog.cpp
index 6bbd867..59c5790 100644
--- a/korgac/alarmdialog.cpp
+++ b/korgac/alarmdialog.cpp
@@ -567,7 +567,11 @@ void AlarmDialog::show()
KWindowSystem::unminimizeWindow( winId(), false );
KWindowSystem::setState( winId(), NET::KeepAbove | NET::DemandsAttention );
KWindowSystem::setOnAllDesktops( winId(), true );
- KWindowSystem::activateWindow( winId() );
+ if ( grabFocus( ) ) {
+KWindowSystem::activateWindow( winId() );
+ } else {
+KWindowSystem::raiseWindow( winId() );
+ }
// Audio, Procedure, and EMail alarms
eventNotification();
@@ -1036,3 +1040,9 @@ void AlarmDialog::removeFromConfig( const
QListAkonadi::Item::Id ids )
genGroup.sync();
}
+bool AlarmDialog::grabFocus( )
+{
+ KSharedConfig::Ptr config = KGlobal::config();
+ KConfigGroup generalConfig( config, General );
+ return generalConfig.readEntry( GrabFocus, false );
+}
diff --git a/korgac/alarmdialog.h b/korgac/alarmdialog.h
index 41acee6..8f298d4 100644
--- a/korgac/alarmdialog.h
+++ b/korgac/alarmdialog.h
@@ -123,6 +123,7 @@ class AlarmDialog : public KDialog
void updateButtons();
void toggleDetails( QTreeWidgetItem *item );
void showDetails( QTreeWidgetItem *item );
+static bool grabFocus( );
Akonadi::ETMCalendar::Ptr mCalendar;
QTreeWidget *mIncidenceTree;
diff --git a/korgac/alarmdockwindow.cpp b/korgac/alarmdockwindow.cpp
index 35343be..8fe6ecf 100644
--- a/korgac/alarmdockwindow.cpp
+++ b/korgac/alarmdockwindow.cpp
@@ -45,6 +45,7 @@ AlarmDockWindow::AlarmDockWindow()
KConfigGroup config( KGlobal::config(), General );
bool
Bug#765941: minitube: TOns of missing icons
For me this seemed to be caused by switching from GNOME to a minimal tiling WM desktop. As outlined in a [GitHub Issue][1], the solution for me was to [get Qt to recognize GTK+ Icons][2] by setting an environment variable in ~/.xinitrc as follows: export DESKTOP_SESSION=gnome I'm not sure what other effects this variable may have, but the icons are back. Best, David [1]: https://github.com/flaviotordini/minitube/issues/11 [2]: https://wiki.archlinux.org/index.php/Uniform_Look_for_QT_and_GTK_Applications#Using_a_GTK.2B_icon_theme_in_Qt_apps -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
