Bug#740565: redeclipse-data: should be in main
On Sun, Jul 27, 2014 at 6:30 AM, Markus Koschany a...@gambaru.de wrote: On 27.07.2014 10:23, Martin Erik Werner wrote: [...] As far as I see it, it is still uncertain whether redeclipse-data belonging in main is a correct assumption, a re-review of the content would be needed, from the previous discussion I think it is indeed *probable* that it would be found fit for main. I have reviewed redeclipse and redeclipse-data file-by-file. The patches are now attached to this bug report. The licenses are DFSG-free and there is not a single file that wouldn't abide by the rules. The only thing I noticed was a missing license paragraph about a few public domain images which I have added to debian/copyright. The paragraph about the Play* fonts could be removed because it appears you moved the font to a separate package, fonts-play. Otherwise the copyright file was accurate. Great, thanks for the patches! I'm sure you've realized by now that the fastest way to get stuff done in Debian is to do it yourself. ;) I don't think this is an RC bug, since keeping it in nonfree is actually the safer option (albeit a bad one should it be deemed unnecessary). No, this is, was and always will be RC. Fixing this issue during a regular upload was preferable but it seems there won't be another release in time before the freeze thus it was necessary to finally take action. No, it's not RC; see below. Imagine the gnome-shell maintainers decided to put their package into non-free because they felt it is safer. It would make all dependencies suddenly uninstallable. You simply can't make arbitrary decisions about the archive sections. Just because Red Eclipse is just a game makes the issue not smaller or less important. Yes, the gnome-shell maintainers can decide to put their packages into non-free if they so wish; doing so is not a Policy violation, even if it sounds ridiculous. And yes, it would make their dependencies uninstallable, which would indeed lead to RC bugs being filed against it and/or its dependencies (and would likely be followed by some heated flamewars on certain mailing lists). It's completely hypothetical, but the gnome-shell maintainers can move their package to non-free at any time, and only the CTTE can override them. There is no documented Policy about the term safer but the Policy is very precise about Debian's archive areas. [1] If your package is compliant with the DFSG it must be in main because this area comprises the Debian distribution. Otherwise other software, like my games-fps metapackage from the Debian Games Pure Blend, is not allowed to depend or recommend Red Eclipse. Since Red Eclipse is DFSG-free it is a Policy violation. Thus the severity must be serious. No, Policy §2.2 explicitly states that non DFSG compliant packages must go in non-free, but nothing about DFSG compliant packages being forced to be distributed in main. 2.2.1 only says that Every package in main must comply with the DFSG (Debian Free Software Guidelines), i.e. package in main - DFSG-compliant, _not_ the reverse. Policy doesn't forbid placing DFSG packages in contrib or non-free, as silly as it may sound, so this simply isn't a RC bug. Just to be clear, I don't object to placing DFSG-free packages in main; what I'm arguing against is inflating bug severity to accomplish your own personal release goals when the bug doesn't violate Policy. It may be important to you, but if it doesn't meet the definition of a RC bug, it's not a RC bug, and it's definitely not a release blocker. Now, just imagine if every maintainer and user decided to inflate the priority of their own pet bugs... Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521391: O: ifrench -- The French dictionary for ispell (Hydro-Quebec version)
[Ryan Kavanagh 2012-11-29] Until then, it'll have to stay as an ITA; only changing the maintainer field isn't worth an upload. I believe it is. When the package is orphaned, it show up as a package in need of help on all machines running how-can-i-help, as well as a package in distress on the package pages for all packages depending/recommending/suggesting ifrench. This causes unneeded work checking the status and drag focus away from people that would be better off spending that time elsewhere. If you plan to take over the package, please upload a new one with the updated maintainer. :) Perhaps you can add a test for ci.debian.net too in the process, if you want some functional change in the upload. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740565: redeclipse-data: should be in main
On Sun, Jul 27, 2014 at 9:46 AM, Martin Erik Werner martinerikwer...@gmail.com wrote: On Sun, 2014-07-27 at 15:30 +0200, Markus Koschany wrote: On 27.07.2014 10:23, Martin Erik Werner wrote: [...] As far as I see it, it is still uncertain whether redeclipse-data belonging in main is a correct assumption, a re-review of the content would be needed, from the previous discussion I think it is indeed *probable* that it would be found fit for main. I have reviewed redeclipse and redeclipse-data file-by-file. The patches are now attached to this bug report. The licenses are DFSG-free and there is not a single file that wouldn't abide by the rules. The only thing I noticed was a missing license paragraph about a few public domain images which I have added to debian/copyright. The paragraph about the Play* fonts could be removed because it appears you moved the font to a separate package, fonts-play. Otherwise the copyright file was accurate. Thank you for the review, it is very much appreciated! Both font and P-D corrections looks correct (I previously think I let the P-D stuff fall through to the Files: * CC-BY-SA glob since they had been modified in Red Eclipse), but I think this makes more sense on second thought. I have pushed your changes to the git repos for redeclipse. Anyone up for sponsoring redeclipse and redeclipse-data for this change? Sure, put it on the team sponsor queue [1] and I'll take a look at it eventually (before the freeze, at worst) if nobody else does. Regards, Vincent [1] https://wiki.debian.org/Games/Sponsors/Queue -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756240: nvidia-settings: nvidia-settings removed when upgrading to nvidia-driver 340.24-2 and xserver 1.16
Hi Vincent, that's great, thank you very much for the links, and also for all your work on the nvidia packages! - B I already built and uploaded it a week or so ago; it's currently sitting in the NEW queue awaiting ftpmaster approval [1]. You can find the actual packaging files by checking out [2] (which you can use to build your own set of packages in the meantime), or fetch the source+binaries I uploaded to ftpmaster that I'm hosting on my own website temporarily [3]. Regards, Vincent [1] https://ftp-master.debian.org/new/nvidia-settings_340.24-1.html [2] svn://anonscm.debian.org/pkg-nvidia/packages/nvidia-graphics-drivers/trunk [3] http://www.vcheng.org/nvidia-settings/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756355: nmu: openchange_1:2.1-1~bpo70+1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear release team, Please binNMU the current version of openchange in wheezy-backports; it has a dependency on libc6 = 2.14, which makes it uninstallable on wheezy. Jelmer, please take care to build backported packages in a clean wheezy chroot next time. nmu openchange_1:2.1-1~bpo70+1 . ALL . -m rebuild against eglibc 2.13 Regards, Vincent -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (700, 'testing'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15-2-vclaptop-amd64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747077: nodm: please ack NMUs and apply various pending patches
I like nodm too, and hope you have time to update before Jessie. :) I would love it if you were able to fix bug #579215 (nodm: Please make it a display-manager alternative) too, to allow nodm to be enabled the same way the other display managers are enabled. :) Btw, the 0006-Build-without-Werror.patch change you propose seem like a wrong approach to me. Is it not better to fix the warnings than making warnings less serious? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756334: question
Do you have an alternative solution? Maybe this could be extracted directly to source package and updated with an script? --- Henri Salo signature.asc Description: Digital signature
Bug#754805: tracker.debian.org: no info about where the package has been accepted (e.g. unstable or experimental)
Hi Raphael, On Tue, 15 Jul 2014, Raphael Hertzog wrote: Ftpmasters, could you maybe improve those mails to include the relevant information ? does the subject line look better now? Thorsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756355: nmu: openchange_1:2.1-1~bpo70+1
On Mon, Jul 28, 2014 at 11:21 PM, Vincent Cheng vch...@debian.org wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear release team, Please binNMU the current version of openchange in wheezy-backports; it has a dependency on libc6 = 2.14, which makes it uninstallable on wheezy. Jelmer, please take care to build backported packages in a clean wheezy chroot next time. nmu openchange_1:2.1-1~bpo70+1 . ALL . -m rebuild against eglibc 2.13 Err, sorry, I meant amd64...this should be correct: nmu openchange_1:2.1-1~bpo70+1 . amd64 . -m rebuild against eglibc 2.13 Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752804: Perl 5.20 transition imminent
Hi, On 28/07/2014 22:37, Damyan Ivanov wrote: Control: severity -1 serious Perl 5.20 is planned to hit unstable around the 12th of August, at which point your package will become unbuildable and/or uninstallable. We plan to start doing NMUs to DELAYED/5 of all the packages which have a patch attached on or about 2nd of August, but a maintainer upload would be warmly appreciated. I will take care of the upload this WE (together with a new upstream version). The package is nearly ready. Regards, Vincent -- dam Debian Perl Group -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752804: Perl 5.20 transition imminent
Control: tags -1 pending -=| Vincent Danjean, 29.07.2014 08:49:34 +0200 |=- Hi, On 28/07/2014 22:37, Damyan Ivanov wrote: Control: severity -1 serious Perl 5.20 is planned to hit unstable around the 12th of August, at which point your package will become unbuildable and/or uninstallable. We plan to start doing NMUs to DELAYED/5 of all the packages which have a patch attached on or about 2nd of August, but a maintainer upload would be warmly appreciated. I will take care of the upload this WE (together with a new upstream version). The package is nearly ready. That's great! Marking as pending so that we skip it in the NMU campaign. -- dam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752348: NMU diff for libhdate 1.6-2.1
Control: tags -1 pending
Attached is the NMU diff for the just uploaded libhdate 1.6-2.1,
produced by 'git diff'.
Note that debian/libhdate-perl.dirs and debian/libhdate-perl.install are
made executable, which may not be honoured by the 'patch' program when
applying the patch.
Cheers,
dam
diff --git a/debian/changelog b/debian/changelog
index 785cb63..dd174b6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+libhdate (1.6-2.1) unstable; urgency=medium
+
+ [ Damyan Ivanov ]
+ * Non-maintainer upload with maintainer's permission
+
+ [ gregor herrmann ]
+ * Fix hardcodes /usr/lib/perl5
+- use $Config{vendorarch} in debian/rules and debian/libhdate-perl.*
+- make the latter two executable
+(Closes: #752348)
+
+ -- Damyan Ivanov d...@debian.org Tue, 29 Jul 2014 06:38:35 +
+
libhdate (1.6-2) unstable; urgency=low
* Patch fix_3: fix an endless loop with hcal -3 (Closes: #692039).
diff --git a/debian/libhdate-perl.dirs b/debian/libhdate-perl.dirs
old mode 100644
new mode 100755
index 92105be..105d79d
--- a/debian/libhdate-perl.dirs
+++ b/debian/libhdate-perl.dirs
@@ -1 +1,3 @@
-usr/lib/perl5
+#!/usr/bin/perl -w
+use Config;
+print substr($Config{vendorarch}, 1) . \n;
diff --git a/debian/libhdate-perl.install b/debian/libhdate-perl.install
old mode 100644
new mode 100755
index c1a78d7..105d79d
--- a/debian/libhdate-perl.install
+++ b/debian/libhdate-perl.install
@@ -1 +1,3 @@
-usr/lib/perl5/*
+#!/usr/bin/perl -w
+use Config;
+print substr($Config{vendorarch}, 1) . \n;
diff --git a/debian/rules b/debian/rules
index 9900396..7593636 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,10 +1,12 @@
#!/usr/bin/make -f
+ARCHLIB := $(shell perl -MConfig -e 'print $$Config{vendorarch}')
+
%:
dh $* --with python2,autotools_dev
override_dh_auto_configure:
- dh_auto_configure -- --with-perl-sitelib-dir=/usr/lib/perl5
+ dh_auto_configure -- --with-perl-sitelib-dir=$(ARCHLIB)
override_dh_python2:
dh_python2 -s --no-guessing-versions
Bug#747077: nodm: please ack NMUs and apply various pending patches
On 29/07/14 07:26, Petter Reinholdtsen wrote: Btw, the 0006-Build-without-Werror.patch change you propose seem like a wrong approach to me. Is it not better to fix the warnings than making warnings less serious? Ideally, it is better to fix the warnings *and* make them less serious. For distributions, the next best thing is to build without -Werror. New compiler versions frequently introduce new warnings (usually because the compiler has improved and now warns about more bad things, or occasionally because it has new false positives) and it doesn't help anyone if previously-working code starts failing to build. For upstream development, sure, -Werror all the way. In the Telepathy project we have configure.ac set up so releases build with non-fatal warnings by default, but random snapshots from git build with fatal warnings by default (apart from a couple of undesired warnings which we explicitly silence) - in practice this means the people who get the warnings are exactly those who are well-placed to fix them. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756323: [Pkg-mailman-hackers] Bug#756323: mailman: why does mailman now include original From header in Reply-to?
tags 756323 upstream thanks On Mon, 28 Jul 2014, Joe Pfeiffer wrote: mailman's Reply-to header. Before calling this a bug, I'm curious as to why (if it's in the changelog, I missed it). Uhm, ask the people who know, that is, upstream? bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756351: libanjuta-3-0: gtkpod 2.1.4-3 segfaults on initialization in anjuta_plugin_handle_get_description
On 29/07/14 05:05, Fred Korz wrote: Package: libanjuta-3-0 Version: 2:3.8.4-3+b1 Severity: important Does it still happen with anjuta 3.12? Emilio Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Starting /usr/bin/gtkpod * What exactly did you do (or not do) that was effective (or ineffective)? Ran gtkpod from the Applications Menu. Found segfault report in logs. Ran gtkpod from Bash, segfaulted as well. Went on to gdb to localize segfault. * What was the outcome of this action? $ gdb /usr/bin/gtkpod GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1.1+b1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/gtkpod...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/gtkpod warning: Could not load shared library symbols for linux-vdso.so.1. Do you need set solib-search-path or set sysroot? [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. ** (gtkpod:17971): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. [New Thread 0x7fffe6024700 (LWP 17975)] [New Thread 0x7fffe4f40700 (LWP 17976)] [New Thread 0x7fffd700 (LWP 17977)] Program received signal SIGSEGV, Segmentation fault. 0x7790e326 in anjuta_plugin_handle_get_description () from /usr/lib/libanjuta-3.so.0 (gdb) where #0 0x7790e326 in anjuta_plugin_handle_get_description () from /usr/lib/libanjuta-3.so.0 #1 0x00408b55 in about_create_plugins_submenu () #2 0x0040cd61 in ?? () #3 0x76016e3b in g_type_create_instance () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #4 0x75ffb355 in ?? () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #5 0x75ffd4c4 in g_object_new_valist () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #6 0x75ffd8a4 in g_object_new () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #7 0x0040aee4 in anjuta_window_new () #8 0x0040d73e in gtkpod_init () #9 0x004080ea in main () * What outcome did you expect instead? I expected the gtkpod UI to come up. Some details extending Other system information: # dpkg -l libanjuta* | cat Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---=== ii libanjuta-3-0 2:3.8.4-3+b1 amd64GNOME development IDE, for C/C++ - shared libraries root@korz2b:/home/korz# dpkg -l gtkpod* | cat Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---=== ii gtkpod 2.1.4-3 amd64manage songs and playlists on an Apple iPod ii gtkpod-data2.1.4-3 all architecture-independent files for gtkpod -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libanjuta-3-0 depends on: ii anjuta-common2:3.8.4-3 ii libc62.19-7 ii libcairo21.12.16-2 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libgdl-3-5 3.8.1-2 ii libglib2.0-0 2.40.0-3 ii libgtk-3-0 3.12.2-1+b1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libxml2 2.9.1+dfsg1-4 libanjuta-3-0 recommends no packages. libanjuta-3-0 suggests no packages. -- no debconf information ___ pkg-gnome-maintainers mailing list pkg-gnome-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gnome-maintainers -- To UNSUBSCRIBE, email to
Bug#612075: atq date format is not easily sortable
Could be this?
Index: at.c
===
--- at.c.orig 2014-07-25 10:59:06.264608764 +0200
+++ at.c 2014-07-25 11:00:04.036607665 +0200
@@ -132,9 +132,10 @@
char *namep;
char atfile[] = ATJOB_DIR /12345678901234;
-char *atinput = (char *) 0; /* where to get input from */
-char atqueue = 0; /* which queue to examine for jobs (atq) */
-char atverify = 0; /* verify time instead of queuing job */
+char *atinput = (char *) 0; /* where to get input from */
+char atqueue = 0; /* which queue to examine for jobs (atq) */
+char atverify = 0; /* verify time instead of queuing job */
+char *timeformat = TIMEFORMAT_POSIX; /* time format (atq) */
/* Function declarations */
@@ -494,7 +495,7 @@
runtime = localtime(runtimer);
-strftime(timestr, TIMESIZE, TIMEFORMAT_POSIX, runtime);
+strftime(timestr, TIMESIZE, timeformat, runtime);
fprintf(stderr, job %ld at %s\n, jobno, timestr);
/* Signal atd, if present. Usual precautions taken... */
@@ -608,7 +609,7 @@
runtimer = 60 * (time_t) ctm;
runtime = localtime(runtimer);
- strftime(timestr, TIMESIZE, TIMEFORMAT_POSIX, runtime);
+ strftime(timestr, TIMESIZE, timeformat, runtime);
if ((pwd = getpwuid(buf.st_uid)))
printf(%ld\t%s %c %s\n, jobno, timestr, queue, pwd-pw_name);
@@ -805,7 +806,7 @@
*/
if (strcmp(pgm, atq) == 0) {
program = ATQ;
- options = hq:V;
+ options = hq:Vo:;
} else if (strcmp(pgm, atrm) == 0) {
program = ATRM;
options = hV;
@@ -889,6 +890,10 @@
timer -= timer % 60;
break;
+ case 'o':
+ timeformat = optarg;
+break;
+
default:
usage();
break;
Index: at.1.in
===
--- at.1.in.orig 2014-07-25 10:59:06.204608765 +0200
+++ at.1.in 2014-07-25 11:17:27.828587820 +0200
@@ -29,6 +29,8 @@
.RB [ -V ]
.RB [ -q
.IR queue ]
+.RB [ -o
+.IR timeformat ]
.br
.B at
.RB [ -rd ]
@@ -254,6 +256,9 @@
.B
\-c
cats the jobs listed on the command line to standard output.
+.TP 8
+.BI \-o fmt
+strftime-like time format used for the job list
.SH FILES
.I @ATJBD@
.br
Index: panic.c
===
--- panic.c.orig 2014-07-25 10:59:06.168608765 +0200
+++ panic.c 2014-07-25 11:06:20.232600513 +0200
@@ -96,7 +96,7 @@
at [-V] [-q x] [-f file] [-mMlbv] -t time\n
at -c job ...\n
at [-V] -l [job ...]\n
- atq [-V] [-q x]\n
+ atq [-V] [-q x] [-o timeformat]\n
at [ -rd ] job ...\n
atrm [-V] job ...\n
batch\n);
signature.asc
Description: Digital signature
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Hi, Am Dienstag, den 29.07.2014, 00:22 -0400 schrieb Daniel Dickinson: Yeah but the guy claiming FQDN broken is the same Lennart who seems hell bent on destroying every *nix idiom. I wouldn't go by his opinion. and I won’t discuss technical issues on this level. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#756357: squid-deb-proxy: refresh_pattern for .tar.xz and .tar.bz2
Package: squid-deb-proxy Version: 0.8.8 Severity: wishlist Tags: patch squid-deb-proxy.conf sets a refresh_pattern on .tar.gz files, and it seems like it should also do so with .tar.xz and .tar.bz2 files as well, as these are now used by many source packages both upstream and within Debian. --- squid-deb-proxy.conf.dpkg-dist 2014-07-18 04:25:52.0 -0700 +++ squid-deb-proxy.conf2014-07-29 00:10:59.114247495 -0700 @@ -54,6 +54,8 @@ refresh_pattern deb$ 129600 100% 129600 refresh_pattern udeb$ 129600 100% 129600 refresh_pattern tar.gz$ 129600 100% 129600 +refresh_pattern tar.xz$ 129600 100% 129600 +refresh_pattern tar.bz2$ 129600 100% 129600 # always refresh Packages and Release files refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims live well, vagrant -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (120, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf Kernel: Linux 3.14-1-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 Versions of packages squid-deb-proxy depends on: ii debconf [debconf-2.0] 1.5.53 ii squid3 3.3.8-1.1+b1 Versions of packages squid-deb-proxy recommends: ii avahi-utils 0.6.31-4 squid-deb-proxy suggests no packages. signature.asc Description: Digital signature
Bug#592744: dragonplayer doesn't play dvd
Hi, This bug looks similar to https://bugs.kde.org/show_bug.cgi?id=209899 , sadly, I can't test this issue as I don't have any dvd discs arround. Happy hacking, -- : You are in a dark room with a compiler, emacs, an internet connection, : and a thermos of coffee. : Your move ? Saludos /\/\ /\ `/ signature.asc Description: Digital signature
Bug#756334: [Pkg-haskell-maintainers] Bug#756334: Configure script downloads files from the Internet
Control: tag -1 + upstream confirmed Hi, Iustin Pop is working on this, and finding a solution together with upstream: https://github.com/ndmitchell/hoogle/issues/76 Greetings, Joachim Am Montag, den 28.07.2014, 23:02 +0200 schrieb Evgeny Kapun: Package: hoogle Version: 4.2.33-1+b1 Severity: critical Tags: security During configuration, hoogle postinst script attempts to download a file from the URL http://hackage.haskell.org/packages/hoogle.tar.gz and subsequently unpack it. Moreover, the integrity of this file is not verified. This leads to the following possible attacks: * An attacker controlling the user's network connection may indefinitely delay the configuration of hoogle package by supplying data at a very low rate, even if package files themselves are available from local source. * The same attacker may supply bogus data instead of the file. This may not only lead to hoogle behaving in an erroneous manner, but may also lead to a full system compromise. For example, the archive may contain a malicious executable file marked SUID root, and local unprivileged user (who also participates in the attack) may run this file after it is extracted. The archive may also contain symlinks and device nodes, which can also be used for attack. * The same attacker may supply a very large file, filling the system partition and achieving denial of service. He may also supply a small file which becomes very large after un-gzipping. My suggestion is that downloading files in a secure manner is hard, and maintainer scripts probably shouldn't be doing it. ___ Pkg-haskell-maintainers mailing list pkg-haskell-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-haskell-maintainers -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#752974: xdotool: FTBFS - tests fail with EOFError: end of file reached
Is this failing test related to bug #740419 (Unreliable testsuite)? Should the bugs be merged? If the test suite is unreliable, perhaps running it during build should be optional, or at least not fatal when it fail? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756358: linux-image-3.14-1-amd64: Please add to default nouveau wo acceleration hardware due to multiple bugs
Package: src:linux Version: 3.14.12-1 Severity: normal Hi due to bugs wich appeait on nouveau driver i set boot parameter nouveau.noaccel=1. Please add this parameter on default instalation on debian. -- Package-specific info: ** Version: Linux version 3.14-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-4) ) #1 SMP Debian 3.14.12-1 (2014-07-11) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.14-1-amd64 root=/dev/mapper/debian-root ro quiet nouveau.noaccel=1 ** Not tainted ** Kernel log: [7.707455] snd-ca0106: Model 100a Rev Serial 100a1102 [7.784375] input: PC Speaker as /devices/platform/pcspkr/input/input5 [7.911636] snd_hda_intel :00:1b.0: irq 44 for MSI/MSI-X [8.053944] [drm] hdmi device not found 1 0 1 [8.054078] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x046f00a3 [8.054082] nouveau [ DEVICE][:01:00.0] Chipset: G72 (NV46) [8.054084] nouveau [ DEVICE][:01:00.0] Family : NV40 [8.055678] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... [8.133302] nouveau [ VBIOS][:01:00.0] ... appears to be valid [8.133308] nouveau [ VBIOS][:01:00.0] using image from PRAMIN [8.133442] nouveau [ VBIOS][:01:00.0] BIT signature found [8.133446] nouveau [ VBIOS][:01:00.0] version 05.72.22.43.00 [8.133741] nouveau :01:00.0: irq 45 for MSI/MSI-X [8.133752] nouveau [ PMC][:01:00.0] MSI interrupts enabled [8.133784] nouveau [ PFB][:01:00.0] RAM type: DDR2 [8.133786] nouveau [ PFB][:01:00.0] RAM size: 256 MiB [8.133789] nouveau [ PFB][:01:00.0]ZCOMP: 0 tags [8.176096] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input6 [8.176857] coretemp coretemp.0: Using relative temperature scale! [8.176872] coretemp coretemp.0: Using relative temperature scale! [8.185514] input: HDA Intel Front Headphone as /devices/pci:00/:00:1b.0/sound/card1/input14 [8.185624] input: HDA Intel Line Out Side as /devices/pci:00/:00:1b.0/sound/card1/input13 [8.185709] input: HDA Intel Line Out CLFE as /devices/pci:00/:00:1b.0/sound/card1/input12 [8.185790] input: HDA Intel Line Out Surround as /devices/pci:00/:00:1b.0/sound/card1/input11 [8.185869] input: HDA Intel Line Out Front as /devices/pci:00/:00:1b.0/sound/card1/input10 [8.185950] input: HDA Intel Line as /devices/pci:00/:00:1b.0/sound/card1/input9 [8.186029] input: HDA Intel Rear Mic as /devices/pci:00/:00:1b.0/sound/card1/input8 [8.186111] input: HDA Intel Front Mic as /devices/pci:00/:00:1b.0/sound/card1/input7 [8.187475] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro [8.324044] iTCO_vendor_support: vendor-support=0 [8.347493] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10 [8.347542] iTCO_wdt: Found a ICH9 TCO device (Version=2, TCOBASE=0x0860) [8.348855] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [8.532129] Adding 3903484k swap on /dev/mapper/debian-swap. Priority:-1 extents:1 across:3903484k [9.428041] nouveau [ PTHERM][:01:00.0] FAN control: none / external [9.428054] nouveau [ PTHERM][:01:00.0] fan management: automatic [9.428058] nouveau [ PTHERM][:01:00.0] internal sensor: yes [9.447907] nouveau [ PTHERM][:01:00.0] temperature (96 C) hit the 'fanboost' threshold [9.447913] nouveau [ PTHERM][:01:00.0] temperature (96 C) hit the 'downclock' threshold [9.447942] nouveau [ CLK][:01:00.0] 20: core 550 MHz shader 550 MHz memory 540 MHz [9.447951] nouveau [ CLK][:01:00.0] --: core 199 MHz memory 391 MHz [9.448157] [TTM] Zone kernel: Available graphics memory: 2029412 kiB [9.448160] [TTM] Initializing pool allocator [9.448167] [TTM] Initializing DMA pool allocator [9.448183] nouveau [ DRM] VRAM: 252 MiB [9.448185] nouveau [ DRM] GART: 512 MiB [9.448190] nouveau [ DRM] TMDS table version 1.1 [9.448192] nouveau W[ DRM] TMDS table script pointers not stubbed [9.448194] nouveau [ DRM] DCB version 3.0 [9.448197] nouveau [ DRM] DCB outp 00: 01000300 0028 [9.448200] nouveau [ DRM] DCB outp 01: 02011310 0028 [9.448202] nouveau [ DRM] DCB outp 02: 01011312 [9.448204] nouveau [ DRM] DCB outp 03: 020223f1 00c0c080 [9.448207] nouveau [ DRM] DCB conn 00: [9.448210] nouveau [ DRM] DCB conn 01: 1130 [9.448212] nouveau [ DRM] DCB conn 02: 0210 [9.448214] nouveau [ DRM] DCB conn 03: 0211 [9.448216] nouveau [ DRM] DCB conn 04: 0213 [9.448373] nouveau [ DRM] Saving VGA fonts [9.506276] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [9.506281] [drm] Driver supports precise vblank timestamp query. [9.506355] nouveau [ DRM] 0xD4A7: Parsing digital output
Bug#719740: dracut does not boot with an encrypted hard disk
On Tue, 29 Jul 2014 00:47:12 +0200, Claudio Clemens astu...@gmx.net said: Package: dracut Version: 020-2 It would be very nice, if you could try the newest version of dracut (038-2) from testing, which also can be used with wheezy. -- regards Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756359: RFP: compton-conf -- Qt configuration tool for X composite manager
Package: wnpp Severity: wishlist * Package name: compton-conf Version : 0.1.0 Upstream Author : Hong Jen Yee (PCMan) pcman...@gmail.com * URL : https://github.com/lxde/compton-conf * License : GPL-2 and LGPL-2.1+ Programming Lang: (C, C++) Description : Qt configuration tool for X composite manager This is one of the packages that will be used in LXQt desktop environment. Reference information: http://wiki.lxde.org/en/Build_LXDE-Qt_From_Source#compton-conf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756334: [Pkg-haskell-maintainers] Bug#756334: Configure script downloads files from the Internet
On Mon, Jul 28, 2014 at 11:02:53PM +0200, Evgeny Kapun wrote: My suggestion is that downloading files in a secure manner is hard, and maintainer scripts probably shouldn't be doing it. On Tue, Jul 29, 2014 at 09:27:34AM +0300, Henri Salo wrote: Do you have an alternative solution? Maybe this could be extracted directly to source package and updated with an script? Just to clarify both points above, if it's not clear from the discussion on the upstream bug: the current situation is not intended, it's just an accident resulting from the fact that upstream doesn't (yet) support an offline mode, and changes in the upstream behaviour resulted in our pre-unpacked files being ignored. Rest assured, this will get fixed, one way (better upstream support) or another (us patching upstream code so that it never downloads + pre-shipping). regards, iustin signature.asc Description: Digital signature
Bug#746765: Conflicting declarations of function libelektra_filesys_LTX_kdbBackendFactory
Hello, [...] It may be the case that no code actually uses the declaration of exported_symbols.h - if so, it shouldn't be included in the linking process either. I think this might have been fixed with elektra 0.7.2, which I uploaded yesterday. Could you please check? I'm afraid the situation persists, and the reason is this bit in the Makefile: http://sources.debian.net/src/elektra/0.7.2-2/src/libelektra/Makefile.am?hl=16#L15 I'm not quite sure why a list of exported symbols (with conflicting declarations) is included in the library? Maybe upstream can explain? Best, Michael pgpFO1ZGMIqQ3.pgp Description: PGP signature
Bug#755539: transition: hdf5
Emilio Pozuelo Monfort a écrit , Le 29/07/2014 00:16: Hi, On 27/07/14 01:12, Gilles Filippini wrote: Emilio Pozuelo Monfort a écrit , Le 25/07/2014 09:22: On 24/07/14 20:10, Gilles Filippini wrote: I am currently rebuilding every affected package to prepare debdiff patches. I'll need a week or so to complete this task. Let us know when that's done. It took less time than I thought. Here is the new status of affected packages: No action required: magics++ octave-bim octave-msh python-shogun vtk Useless bin dependency on hdf5: getdp #755973 insighttoolkit4 #756015 oasis3 #755681 slepc #755180 binNMU required: armadillo dolfin mathgl ovito(blocked by #756108) paraview (blocked by #756108) shogun vtk6 (blocked by #756108) Can't #756108 be fixed before the transition starts? (If not, why not?) Sure it could. It's an easy one. But I'm not sure how welcome could be an NMU for a bug which have severity=normal. I you think it's fine I can NMU it with delay=2. Fix required (patch proposal ready): adios aster cdo cmor code-saturne exodusii flann gdal gmsh gpiv gpivtools grads h5utils hdf-eos5 jhdf libcgns libgpiv libmatio libpdl-io-hdf5-perl libvigraimpex med-fichier meep meep-lam4 meep-mpich2 meep-mpi-default meep-openmpi minc mpb ncl netcdf nexus octave petsc pygpiv pytables r-cran-hdf5 ruby-hdfeos5 salome-kernel scilab stimfit syrthes tessa xdmf xmds2 yorick-hdf5 Can't these be fixed before the transition starts? If not, why not? Are all the patches similar? Can you put the patches somewhere (e.g. people.debian.org) so we can take a look? The fixes are mostly easy ones but should occur after the transition starts because they are related to paths changes in the libhdf5*-dev packages. I've put the patches there: https://people.debian.org/~pini/hdf5-transition/patches/ BTW I'd expect bugs to be filed before the transition starts. Would it be acceptable that I file these bugs with the patches attached plus a blocker on this transition bug? Depends on deprecated hdf5 mpi-posix API: h5py silo-llnl What does that mean? Is that API deprecated but not removed, so these still work? Do they need binNMUs then? Or is that API removed? If so, what's the plan here? The mpi-posix API was *removed*: http://www.hdfgroup.org/newsletters/newsletter140.html The fix for h5py is really easy: just remove the python bindings for this API. It should be easy for silo-llnl too but I'm not at ease with this application so I don't have a patch proposal at hand. I've opened a bug upstream: http://visitbugs.ornl.gov/issues/1915 With so many packages needing sourceful uploads after the transition starts, Because of the installation paths changes needed to allow the co-installation of libhdf5*-dev (see below). I'm unsure this is a good idea this close to the transition freeze. Also, you haven't explained why you want this update in Jessie. I see this is just a point release. Is there something new in 1.8.13 that we really want that isn't in 1.8.12? This is an upstream point release indeed. But on the package side this release introduces a long awaited major feature: it is now possible to co-install the different flavors (serial, mpich, openmpi) of the library; they were conflicting before that, leading to recurrent problems: #703439, #721202, #746955. It would really be great to have this solved for Jessie. Thanks, _g. Cheers, Emilio Others: gnudatalanguage FTBFS blocked by plplot signature.asc Description: OpenPGP digital signature
Bug#736787:
Hi, 2014-07-27 1:51 GMT+02:00 Balint Reczey bal...@balintreczey.hu: Control: tags -1 patch On 03/12/2014 09:54 PM, Mert Dirik wrote: Looks like it is fixed in upstream in commit 27420ad [1] by removing the offending files. New upstream version (1.5) should fix this bug. [1] https://github.com/mitchellh/vagrant/commit/27420ad2ee78caf1b1effc3eb27744ae2c288009 IMO the files still have to be removed from orig.tar.gz by repackaging it as 1.6.3+dfsg1 manually. I see 1.5.3 imported to packaging git, but it still has the files thus would not solve this RC bug. Antonio, do you plan releasing 1.6.3 with the problematic files removed from the source? The attached patch will remove the whole website dir from the source when using uscan --repack. I can push it to the packaging repository, but I did not want to do so before asking first. I have pushed the fix to the packaging repository and also created 1.5.3+dfsg1 with the website dir filtered out. Is there a package update in the plans? Cheers, Balint -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756008: postgresql-common: pg_upgradecluster 9.3 - 9.4 fails
On Mon, 28 Jul 2014, Christoph Berg wrote: So, how d̲o̲ I recover from this without making things worse, now? You can just start the old cluster again. (The only thing that could be changed there are the port number and start.conf, but judging from the errors you got it died way before that point.) OK, thank you. Starting needed me to *stop* the old cluster (using the init script) in the first place, judging from “ps ax” output… apparently, there were several Akonadi sessions still open. I could then successfully upgrade the cluster. The bug remains: pg_upgradecluster should not fail to upgrade the cluster (it’s called as root, so it could just use the same mechanism which the init script uses to stop it), and must not bring the DB into such an inconsistent state. Apparently, this is nothing new, but my (and others’) use of psql as KDE backend (instead of a non-database) will trigger it more often now. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752943: djangorestframework: FTBFS - Test label 'rest_framework.tests' does not refer to a test
Hi, Control: notfound -1 2.3.13-2 Control: close -1 Hi, On Wed, Jul 02, 2014 at 06:11:29AM +0900, Kouhei Maeda wrote: But this problem was unreproducible when I had created a new base.cow. (The other lintian errors occured.) I also cannot reproduce the problem in a clean, up-to-date chroot. Closing. My apologies for the late reply. Indeed this was an issue caused by my set up, even though there does seem to be a genuine problem here (but not an RC one; I'm leaving the bug closed for now and will let you judge). It's this bit of the code/configuration: http://sources.debian.net/src/djangorestframework/2.3.14-1/rest_framework/runtests/settings.py?hl=165,166#L166 As I had been building this from within jenkins, xmlrunner.extra.djangotestrunner.XMLTestRunner was used instead of the (default?) DiscoveryRunner. Apparently, however, the XMLTestRunner won't work for this test suite. Best, Michael pgp1_QrlgAaAj.pgp Description: PGP signature
Bug#755315: [PKG-Openstack-devel] Bug#755315: [openstack-dev] [Trove] Should we stop using wsgi-intercept, now that it imports from mechanize? this is really bad!
On 07/28/2014 04:04 AM, Chris Dent wrote: On Mon, 28 Jul 2014, Thomas Goirand wrote: That's exactly the version which I've been looking at. The thing is, when I run the unit test with that version, it just bombs on me because mechanize isn't there. How would you feel about it being optionally available and for the tests for mechanize to only run for it if someone has aleady preinstalled mechanize? That is the tests will skip if import mechanize is an ImportError? While I'm not in love with mechanize, if it is a tool that _some_ people use, then I don't want wsgi-intercept to not be useful to them. Please let me know if you can release a new version of wsgi-intercept cleaned from any trace of mechanize, or if you think this can't be done. Let me know if the above idea can't work. Depending on your answer I'll either release a version as described, or go ahead and flush it. If you get back to me by tomorrow morning (UTC) I can probably get the new version out tomorrow too. Hi, Sorry, I couldn't reply earlier. Well, if at least mechanize really becomes optional, which means: no issue when running unit tests without it, and no issue when using it, then it may be ok from my point of view (eg: I wouldn't complain that much about it). However, from *your* perspective, I wouldn't advise that you keep using such a dangerous, badly maintained Python module. Saying that it's optional may look like you think mechanize is ok and you are vouching for it, when it really shouldn't be the case. Having clean, well maintained dependencies, is IMO very important for a given python module. It shows that you care no bad module gets in. Let me know whenever you have a new release, without mechanize as new dependency, or with it being optional. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756360: gdevilspie: maintainer address bounces
Source: gdevilspie Severity: serious Tags: sid X-Debbugs-Cc: Bart Martens ba...@debian.org [ CC'ed the last sponsor for the package in case he knows the maintainer. ] The maintainer address for gdevilspie bounces, see below. Ansgar On 07/28/2014 21:49, Mail Delivery System wrote: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: rac...@makeworld.com SMTP error from remote mail server after RCPT TO:rac...@makeworld.com: host inbound.makeworld.com.netsolmail.net [206.188.198.64]: 550 5.0.0 rac...@makeworld.com... User unknown -- This is a copy of the message, including all the headers. -- Return-path: dak-unp...@franck.debian.org Received: from franck.debian.org ([138.16.160.12]) from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=franck.debian.org,EMAIL=hostmas...@franck.debian.org (verified) by muffat.debian.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from dak-unp...@franck.debian.org) id 1XBqvl-00075v-Hg for rac...@makeworld.com; Mon, 28 Jul 2014 19:49:57 + Received: from dak-unpriv by franck.debian.org with local (Exim 4.80) (envelope-from dak-unp...@franck.debian.org) id 1XBqvk-ug-DR for rac...@makeworld.com; Mon, 28 Jul 2014 19:49:56 + To: rac...@makeworld.com From: Debian FTP Masters ftpmas...@ftp-master.debian.org Subject: Processing of gdevilspie_0.5-3.1_amd64.changes Date: Mon, 28 Jul 2014 19:49:56 + X-Debian: DAK X-DAK: DAK Precedence: bulk Auto-Submitted: auto-generated X-Debian-Package: gdevilspie Message-Id: e1xbqvk-ug...@franck.debian.org Sender: unprivileged ftp-master role account dak-unp...@franck.debian.org gdevilspie_0.5-3.1_amd64.changes uploaded successfully to localhost along with the files: gdevilspie_0.5-3.1_all.deb gdevilspie_0.5-3.1.dsc gdevilspie_0.5-3.1.debian.tar.xz Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756361: The httpd virtual package should be provided by apache2, not apache2-bin
Package: apache2 Version: 2.4.10-1 Severity: important Currently the httpd virtual package is provided by apache2-bin, but apache2-bin does not include the configuration files and init scripts, so it doesn't provide a working web server. The apache2 package has those files and should be the package providing the httpd virtual package. This is also how it is in wheezy, where httpd is provided by the mpm packages which depend on apache2.2-common for the configuration files and init scripts. I set the severity to important because web applications that depend on httpd currently won't work with only apache2-bin installed. See also the following thread on debian-devel about this: https://lists.debian.org/debian-devel/2014/07/msg01065.html -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-32-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756362: python-trollius: no From in trollius module
Package: python-trollius Version: 0.1.4+20140210+git+6f1f9233b1-2 Severity: normal Dear Maintainer, impossible to do a: yield From From is trollius specific but there is no trollius module, only asyncio module sylvain -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-trollius depends on: ii dpkg 1.17.9 ii python 2.7.5-5 ii python-concurrent.futures 2.1.6-3 python-trollius recommends no packages. python-trollius 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#756363: ITP: sslsplit -- transparent and scalable SSL/TLS interception
Package: wnpp Owner: Hilko Bengen ben...@debian.org Severity: wishlist * Package name: sslsplit Version : 0.4.8 Upstream Author : Daniel Roethlisberger dan...@roe.ch * URL or Web page : http://www.roe.ch/SSLsplit * License : BSD-2-clause Description : transparent and scalable SSL/TLS interception SSLsplit is a tool for man-in-the-middle attacks against SSL/TLS encrypted network connections. Connections are transparently intercepted through a network address translation engine and redirected to SSLsplit. SSLsplit terminates SSL/TLS and initiates a new SSL/TLS connection to the original destination address, while logging all data transmitted. SSLsplit is intended to be useful for network forensics and penetration testing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756033: calendarserver: Can't create groups
Since Calendarserver 3.x, subscriptions to groups is no longer supported. On July 25, 2014 7:55:12 PM GMT+05:30, Davide Chiarini davide.chiar...@gmail.com wrote: Package: calendarserver Version: 3.2+dfsg-4+deb7u1 Severity: normal Tags: upstream Version 3.2 of calendarserver (current on stable) doesn't seem to create groups. Fresh install, using default example files from package (accounts.xml), with user test and group users. Subscribing to the user calendar via for example lightning or browsing to http://servername:8008/calendars/users/test/calendar/ returns no error, the calendar works and the corresponding directory structure is created under /var/spool/caldavd on first access. Access.log reports 192.168.0.7 - test [25/Jul/2014:16:04:00 +0200] GET /calendars/users/test/calendar/ HTTP/1.1 200 Doing the same thing with groups, subscribing for example to http://servername:8008/calendars/groups/users/calendar/ does not work, calendar cannot be subscribed under lightning, nothing is created under /var/spool/caldavd. Using a browser you get Not Found. Access.log reports 192.168.0.7 - - [25/Jul/2014:16:06:56 +0200] GET /calendars/groups/users/calendar/ HTTP/1.1 404 Nothing is reported in error.log -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-0.bpo.4-686-pae (SMP w/4 CPU cores) Locale: LANG=it_IT@euro, LC_CTYPE=it_IT@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages calendarserver depends on: ii adduser3.113+nmu3 ii libc6 2.13-38+deb7u3 ii lsb-base 4.1+Debian8+deb7u1 ii memcached 1.4.13-0.2+deb7u1 ii python 2.7.3-4+deb7u1 ii python-dateutil1.5+dfsg-0.1 ii python-kerberos1.1+svn4895-1+b2 ii python-openssl 0.13-2+deb7u1 ii python-plist 1.8-1 ii python-pycalendar 2.0~svn188-1 ii python-pygresql1:4.0-3 ii python-pysqlite2 2.6.3-3 ii python-sqlparse0.1.4-1 ii python-twisted-conch 1:12.0.0-1 ii python-twisted-core12.0.0-1 ii python-twisted-mail12.0.0-1 ii python-twisted-web 12.0.0-1 ii python-twisted-words 12.0.0-1 ii python-xattr 0.6.4-2 ii python-zope.interface 3.6.1-3 ii ssl-cert 1.0.32 Versions of packages calendarserver recommends: ii python-ldap 2.4.10-1 ii python-pam 0.4.2-13 calendarserver suggests no packages. -- Configuration Files: /etc/caldavd/accounts.xml changed: ?xml version=1.0 encoding=utf-8? !-- Copyright (c) 2006-2010 Apple Inc. All rights reserved. Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !DOCTYPE accounts SYSTEM accounts.dtd accounts realm=Test Realm user uidadmin/uid passwordadmin12345/password nameSuper User/name /user user uidtest/uid passwordtest12345/password nameTest User/name /user group uidusers/uid passwordusers/password nameUsers Group/name members member type=userstest/member /members /group location uidmercury/uid passwordmercury/password nameMecury Conference Room, Building 1, 2nd Floor/name /location /accounts /etc/caldavd/caldavd.plist changed: ?xml version=1.0 encoding=UTF-8? !-- Copyright (c) 2006-2011 Apple Inc. All rights reserved. Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 dict !-- Public network address information This is the server's public network address, which is provided to clients in URLs and the like. It may or may not be the network address that the server is listening to directly, though it is by default. For example, it may be the address of a load balancer or proxy which forwards connections to the server. -- !-- Network host name [empty = system host name] -- keyServerHostName/key
Bug#756364: gnome-control-center: Apply display properities fails due to DBus.Error.UnknownMethod
Package: gnome-control-center Version: 1:3.8.3-7+b2 Severity: important Dear Maintainer, if I try to deactivate an external screen with gnome-control-center 3.8.3-7+b2 I receive an error message: Konfiguration konnte nicht angewendet werden: %s GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Keine derartige Methode »ApplyConfiguration« (translation: Konfiguration konnte nicht angewendet werden = Could not apply configuration; Keine derartige Methode = No such method) Deactivating the screen with xrandr on terminal works fine. The error is reproducable, also if I try to change resolution of the internal screen without any external screen connected. With an older version (approx. one month ago) everything worked fine, too. If I upgrade to 3.12.1-4 from unstable, everything seems to work again. If you have further questions please do not hesitate to contact me. Best, Henning -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-control-center depends on: ii accountsservice0.6.37-2 ii apg2.2.3.dfsg.1-2 ii colord 1.2.1-1 ii desktop-file-utils 0.22-1 ii gnome-control-center-data 1:3.8.3-7 ii gnome-desktop3-data3.12.2-2 ii gnome-icon-theme 3.12.0-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii gnome-menus3.8.0-2 ii gnome-settings-daemon 3.12.2-1 ii gsettings-desktop-schemas 3.12.2-1 ii libaccountsservice00.6.37-2 ii libatk1.0-02.12.0-1 ii libc6 2.19-7 ii libcairo2 1.12.16-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libcheese-gtk233.12.2-1 ii libcheese7 3.12.2-1 ii libclutter-gtk-1.0-0 1.5.2-2 ii libcolord-gtk1 0.1.25-1.1+b1 ii libcolord2 1.2.1-1 ii libcups2 1.7.4-1 ii libdbus-glib-1-2 0.102-1 ii libfontconfig1 2.11.0-5 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libgl1-mesa-glx [libgl1] 10.2.4-1 ii libglib2.0-0 2.40.0-3 ii libgnome-bluetooth11 3.8.1-3 ii libgnome-desktop-3-7 3.8.4-2 ii libgoa-1.0-0b 3.12.2-1 ii libgoa-backend-1.0-1 3.12.2-1 ii libgtk-3-0 3.12.2-1+b1 ii libgtop2-7 2.28.5-2 ii libibus-1.0-5 1.5.7-1 ii libkrb5-3 1.12.1+dfsg-5 ii libmm-glib01.2.0-1 ii libnm-glib-vpn10.9.10.0-1 ii libnm-glib40.9.10.0-1 ii libnm-gtk0 0.9.10.0-2 ii libnm-util20.9.10.0-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-01.36.3-1 ii libpolkit-gobject-1-0 0.105-6.1 ii libpulse-mainloop-glib05.0-2 ii libpulse0 5.0-2 ii libpwquality1 1.2.3-1 ii libsmbclient 2:4.1.9+dfsg-2 ii libsocialweb-client2 0.25.20-6 ii libupower-glib10.9.23-2+b2 ii libwacom2 0.8-1 ii libx11-6 2:1.6.2-2 ii libxi6 2:1.7.2-1 ii libxml22.9.1+dfsg1-4 Versions of packages gnome-control-center recommends: ii cups-pk-helper 0.2.5-2 ii gkbd-capplet 3.6.0-1 ii gnome-online-accounts 3.12.2-1 pn gnome-user-guide none ii gnome-user-share 3.8.3-1 ii iso-codes 3.55-1 ii mesa-utils 8.2.0-1 ii mousetweaks3.12.0-1 ii network-manager-gnome 0.9.10.0-2 ii ntp1:4.2.6.p5+dfsg-3 ii policykit-1-gnome 0.105-2 ii rygel 0.22.2-2 ii system-config-printer 1.4.3-4 Versions of packages gnome-control-center suggests: ii gnome-screensaver3.6.1-1+b1 ii gstreamer1.0-pulseaudio 1.4.0-1 ii libcanberra-gtk-module 0.30-2 ii libcanberra-gtk3-module 0.30-2 ii x11-xserver-utils7.7+3 -- 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#756365: hyperic-sigar: FTBFS on MIPS/MIPSel
Package: hyperic-sigar Version: 1.6.4+dfsg-1 Severity: normal I'm going to upload a patch fixing this bug -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: mips (mips64) Kernel: Linux 3.14-1-5kc-malta Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756366: Add support for -X to dh_installman
Package: debhelper Version: 9.20120909 Severity: minor It would be super nice to add support for -X (as in other dh commands) for dh_installman. So that one can write: override_dh_installman: dh_installman -p$(pkg_1) -Xserver debian/*.1 dh_installman -p$(pkg_2) debian/*.1 Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756340: [systemd] Boot stops with certain (valid) tmpfs entries in /etc/fstab
On Tuesday 29 July 2014 00:07:41 you wrote: /var/run and /var/lock should be symlinks to /run and /run/lock nowadays and your system needs has been updated by the sysvinit package to support that. Also, 1777 is very much broken for /var/run. Let me add here: Since /var/run is a symlink to /run, what happened is, that /run was mounted early on, then /var/run was mounted over /run via the symlink, thus breaking any open sockets and pid files which were already in /run. Then the actual bug might have been in the /run migration script, or it was just my own fault. In any way, this would indeed be hard to detect or report for systemd. Thanks for your time and help Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756365: patch
TIOCGETC, etc. are not supported on MIPS.
This patch modifies several macros to make the package compile on MIPS.
--- hyperic-sigar-1.6.4+dfsg/src/sigar_getline.c 2013-01-27 22:39:57.0 +
+++ hyperic-sigar-1.6.4+dfsg.mine/src/sigar_getline.c 2014-07-29 09:17:56.888202734 +
@@ -362,7 +362,7 @@
#endif
#if defined(TIOCGETP) !defined(__sgi) !defined(R__MKLINUX) \
- !defined(R__ALPHALINUX) /* use BSD interface if possible */
+ !defined(R__ALPHALINUX) !defined(__mips__) /* use BSD interface if possible */
#include sgtty.h
static struct sgttyb new_tty, old_tty;
static struct tchars tch;
@@ -371,7 +371,7 @@
#ifdef SIGTSTP /* need POSIX interface to handle SUSP */
#include termios.h
#if defined(__sun) || defined(__sgi) || defined(R__MKLINUX) || \
-defined(R__ALPHALINUX)
+defined(R__ALPHALINUX) || defined(__mips__)
#undef TIOCGETP /* Solaris and SGI define TIOCGETP in termios.h */
#undef TIOCSETP
#endif
@@ -412,7 +412,7 @@
{
if (gl_notty) return;
#ifdef unix
-#ifdef TIOCGETP /* BSD */
+#if defined(TIOCGETP) !defined(__mips__) /* BSD */
ioctl(0, TIOCGETC, tch);
ioctl(0, TIOCGLTC, ltch);
gl_intrc = tch.t_intrc;
signature.asc
Description: Digital signature
Bug#722912: libclutter-1.0-0: apt does not find an upgrade path from wheezy to jessie
On Fri, 16 May 2014 at 12:26:10 +0200, Holger Levsen wrote: control: found -1 1.18.2-1 # see https://piuparts.debian.org/wheezy2jessie/fail/libclutter-1.0-0_1.18.2-1.log This appears to have been fixed in jessie's apt. Logs with wheezy's apt/0.9.7.9+deb7u2, and with jessie's apt/1.0.6 plus its dependencies (libc) on an otherwise wheezy system, follow. Does this look familiar to any apt maintainers? Looking at git history, I wonder whether propagate a negative score point along breaks/conflicts and/or check version before adding scores in resolver might be relevant? Should we be recommending that stable users upgrade to jessie's apt before upgrading to jessie, or should the relevant changes be backported into wheezy, or something? Or can the apt maintainers suggest a change to src:clutter-1.0 or src:cogl that would resolve this? I did try adding a local apt source in which I'd given libcogl20 a Breaks/Replaces on libcogl9 to try to prod apt in the right direction, but that wasn't effective. My test steps were: open a (mostly) minimal wheezy-amd64 chroot, apt-get update, apt-get install libclutter-1.0-0, change sources.list to point to jessie, apt-get update, apt-get dist-upgrade. (wheezy-amd64)% sudo apt-get -oDebug::pkgProblemResolver=true --dry-run dist-upgrade Reading package lists... Building dependency tree... Reading state information... Starting Starting 2 Investigating (0) libclutter-1.0-0 [ amd64 ] 1.10.8-2 - 1.18.2-2 ( libs ) Broken libclutter-1.0-0:amd64 Breaks on libcogl9 [ amd64 ] 1.10.2-7 ( libs ) Considering libcogl9:amd64 0 as a solution to libclutter-1.0-0:amd64 0 Holding Back libclutter-1.0-0:amd64 rather than change libcogl9:amd64 Investigating (1) libcogl20 [ amd64 ] none - 1.18.2-1 ( libs ) Broken libcogl20:amd64 Breaks on libclutter-1.0-0 [ amd64 ] 1.10.8-2 - 1.18.2-2 ( libs ) ( 1.17) Considering libclutter-1.0-0:amd64 0 as a solution to libcogl20:amd64 2 Upgrading libclutter-1.0-0:amd64 due to Breaks field in libcogl20:amd64 Investigating (1) libclutter-1.0-0 [ amd64 ] 1.10.8-2 - 1.18.2-2 ( libs ) Broken libclutter-1.0-0:amd64 Breaks on libcogl9 [ amd64 ] 1.10.2-7 ( libs ) Considering libcogl9:amd64 0 as a solution to libclutter-1.0-0:amd64 0 Holding Back libclutter-1.0-0:amd64 rather than change libcogl9:amd64 Investigating (2) libcogl20 [ amd64 ] none - 1.18.2-1 ( libs ) Broken libcogl20:amd64 Breaks on libclutter-1.0-0 [ amd64 ] 1.10.8-2 - 1.18.2-2 ( libs ) ( 1.17) Considering libclutter-1.0-0:amd64 0 as a solution to libcogl20:amd64 2 Upgrading libclutter-1.0-0:amd64 due to Breaks field in libcogl20:amd64 Investigating (2) libclutter-1.0-0 [ amd64 ] 1.10.8-2 - 1.18.2-2 ( libs ) Broken libclutter-1.0-0:amd64 Breaks on libcogl9 [ amd64 ] 1.10.2-7 ( libs ) Considering libcogl9:amd64 0 as a solution to libclutter-1.0-0:amd64 0 Holding Back libclutter-1.0-0:amd64 rather than change libcogl9:amd64 Investigating (3) libcogl20 [ amd64 ] none - 1.18.2-1 ( libs ) Broken libcogl20:amd64 Breaks on libclutter-1.0-0 [ amd64 ] 1.10.8-2 - 1.18.2-2 ( libs ) ( 1.17) Considering libclutter-1.0-0:amd64 0 as a solution to libcogl20:amd64 2 Upgrading libclutter-1.0-0:amd64 due to Breaks field in libcogl20:amd64 Investigating (3) libclutter-1.0-0 [ amd64 ] 1.10.8-2 - 1.18.2-2 ( libs ) Broken libclutter-1.0-0:amd64 Breaks on libcogl9 [ amd64 ] 1.10.2-7 ( libs ) Considering libcogl9:amd64 0 as a solution to libclutter-1.0-0:amd64 0 Holding Back libclutter-1.0-0:amd64 rather than change libcogl9:amd64 Investigating (4) libcogl20 [ amd64 ] none - 1.18.2-1 ( libs ) Broken libcogl20:amd64 Breaks on libclutter-1.0-0 [ amd64 ] 1.10.8-2 - 1.18.2-2 ( libs ) ( 1.17) Considering libclutter-1.0-0:amd64 0 as a solution to libcogl20:amd64 2 Upgrading libclutter-1.0-0:amd64 due to Breaks field in libcogl20:amd64 Investigating (4) libclutter-1.0-0 [ amd64 ] 1.10.8-2 - 1.18.2-2 ( libs ) Broken libclutter-1.0-0:amd64 Breaks on libcogl9 [ amd64 ] 1.10.2-7 ( libs ) Considering libcogl9:amd64 0 as a solution to libclutter-1.0-0:amd64 0 Holding Back libclutter-1.0-0:amd64 rather than change libcogl9:amd64 Investigating (5) libcogl20 [ amd64 ] none - 1.18.2-1 ( libs ) Broken libcogl20:amd64 Breaks on libclutter-1.0-0 [ amd64 ] 1.10.8-2 - 1.18.2-2 ( libs ) ( 1.17) Considering libclutter-1.0-0:amd64 0 as a solution to libcogl20:amd64 2 Upgrading libclutter-1.0-0:amd64 due to Breaks field in libcogl20:amd64 Investigating (5) libclutter-1.0-0 [ amd64 ] 1.10.8-2 - 1.18.2-2 ( libs ) Broken libclutter-1.0-0:amd64 Breaks on libcogl9 [ amd64 ] 1.10.2-7 ( libs ) Considering libcogl9:amd64 0 as a solution to libclutter-1.0-0:amd64 0 Holding Back libclutter-1.0-0:amd64 rather than change libcogl9:amd64 Investigating (6) libcogl20 [ amd64 ] none - 1.18.2-1 ( libs ) Broken libcogl20:amd64 Breaks on libclutter-1.0-0 [ amd64 ] 1.10.8-2 - 1.18.2-2 ( libs ) ( 1.17) Considering libclutter-1.0-0:amd64 0 as a solution to libcogl20:amd64
Bug#756367: global chokes/segfaults while parsing drupal 7
Package: global Version: 5.7.1-2 Severity: normal Tags: upstream Dear Maintainer, See the upstream bugreport here: http://comments.gmane.org/gmane.comp.gnu.global.bugs/1439 Main problem is that global/gtags segfaults during parsing of drupal7/modules/system/system.api.php due to a large block comment for function hook_menu(). Suggested solution: I haven't tried this, but the upstream report suggest the following change in libparser/php.c: - #define YY_BUF_SIZE 16384 + #define YY_BUF_SIZE 65536 or upgrade it to the latest version upstream, 6.3. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages global depends on: ii dpkg 1.17.10 ii install-info 5.2.0.dfsg.1-4 ii libc6 2.19-7 global recommends no packages. Versions of packages global suggests: ii apache2-bin [httpd] 2.4.10-1 ii chromium [www-browser] 35.0.1916.153-2 ii doxygen 1.8.7-2 ii iceweasel [www-browser] 30.0-2 ii id-utils 4.6+git20120811-4 -- 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#756368: postgresql-9.4 FTBFS on alpha: incorrect pg_read_barrier definition
Source: postgresql-9.4 Version: 9.4~beta2-1 Severity: wishlist Tags: patch User: debian-al...@lists.debian.org Usertags: alpha postgresql-9.4 FTBFS on alpha. From the build log [1]: cc -g -O2 -Wformat -Werror=format-security -I/usr/include/mit-krb5 -fPIC -pie -DLINUX_OOM_SCORE_ADJ=0 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I../../../src/include -I/«PKGBUILDDIR»/build/../src/include -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/tcl8.6 -c -o bgworker.o /«PKGBUILDDIR»/build/../src/backend/postmaster/bgworker.c /tmp/ccNKo8Fb.s: Assembler messages: /tmp/ccNKo8Fb.s:764: Error: unknown opcode `rmb' as: BFD (GNU Binutils for Debian) 2.24.51.20140709 internal error, aborting at ../../gas/write.c line 603 in size_seg This occurs because in src/include/storage/barrier.h the definition of pg_read_barrier() for Alpha maps to the CPU instruction rmb but there is no such CPU instruction on Alpha! I attach a patch that fixes the pg_read_barrier() definition to use the correct CPU instruction for a read memory barrier on Alpha. With that postgresql-9.4 builds to completion on Alpha. Cheers Michael. [1] http://buildd.debian-ports.org/status/fetch.php?pkg=postgresql-9.4arch=alphaver=9.4~beta2-1stamp=1406489832 Index: postgresql-9.4-9.4~beta2/src/include/storage/barrier.h === --- postgresql-9.4-9.4~beta2.orig/src/include/storage/barrier.h +++ postgresql-9.4-9.4~beta2/src/include/storage/barrier.h @@ -117,7 +117,7 @@ extern slock_t dummy_spinlock; * read barrier to cover that case. We might need to add that later. */ #define pg_memory_barrier() __asm__ __volatile__ (mb : : : memory) -#define pg_read_barrier() __asm__ __volatile__ (rmb : : : memory) +#define pg_read_barrier() __asm__ __volatile__ (mb : : : memory) #define pg_write_barrier() __asm__ __volatile__ (wmb : : : memory) #elif defined(__hppa) || defined(__hppa__) /* HP PA-RISC */
Bug#756369: parcimonie: Please provide statistics about key fetches
Package: parcimonie Version: 0.8.3-1 Severity: wishlist It would be good if parcimonie provided minimal stats about how many keys were fetched. If parcimonie's uptime information was attached to these stats, this would help users decide whether the default average lapse time value is adequate for their use case, or if they'd better use a custom one. Most likely, the best place to do so is in the log viewer that one can open from the applet (and then, the stats will be restricted to what happened since the applet was started, which is consistent with the other information displayed in the log viewer window). Perhaps it would be useful to go as far as counting successes and failures separately. Or maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555669: kdemultimedia-kio-plugins: some KDE apps (dolphin, amarok) are not able to read audio cds
Hi, I can't reproduce the issue in dolphin with the current jessie version, but amarok ignores my audio cd, either trying to use it as an action in the device notification panel or using the play media menu. This should probably be reassigned to amarok. Happy hacking, -- Executive ability is deciding quickly and getting somebody else to do the work. -- Pollard's Postulate Saludos /\/\ /\ `/ signature.asc Description: Digital signature
Bug#755315: [openstack-dev] [PKG-Openstack-devel] Bug#755315: [Trove] Should we stop using wsgi-intercept, now that it imports from mechanize? this is really bad!
On Tue, 29 Jul 2014, Thomas Goirand wrote: Sorry, I couldn't reply earlier. No problem. However, from *your* perspective, I wouldn't advise that you keep using such a dangerous, badly maintained Python module. Saying that it's optional may look like you think mechanize is ok and you are vouching for it, when it really shouldn't be the case. Having clean, well maintained dependencies, is IMO very important for a given python module. It shows that you care no bad module gets in. I've pointed a couple of the other wsgi-intercept contributors to this thread to get their opinions on which way is the best way forward, I'd prefer not to make the decision solo. Let me know whenever you have a new release, without mechanize as new dependency, or with it being optional. It will be soon (a day or so). -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756370: taskwarrior: unable to sync to taskd due to GnuTLS support.
Package: taskwarrior Version: 2.3.0+dfsg-3 Severity: normal Dear Maintainer, When you task sync, it advertise that GnuTLS support lacks. $ task sync init Taskwarrior was built without GnuTLS support. Sync is not available. You have to : - aptitude install libgnutls-dev - delete the DCMAKE_DISABLE_FIND_PACKAGE_GnuTLS=TRUE \ line in debian/rules in order to make the sync possible with taskd. Regards. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (30, 'testing'), (9, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages taskwarrior depends on: ii libc6 2.19-7 ii libgcc1 1:4.9.1-3 ii libreadline6 6.3-6 ii libstdc++64.9.1-3 ii libuuid1 2.20.1-5.8 taskwarrior recommends no packages. taskwarrior 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#756371: youtube-dl: youtube has changed their player (again) on 2014-07-25, need at least that version or higher
Package: youtube-dl Version: 2014.07.15-1 Severity: normal Dear Maintainer, It seems youtube has changed their player (again). See https://github.com/rg3/youtube-dl/issues/3396 So we need 2014.07.25 or higher version to continue to download videos from youtube. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'testing-updates'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages youtube-dl depends on: ii python2.7.8-1 ii python-pkg-resources 5.4.1-1 Versions of packages youtube-dl recommends: ii libav-tools 6:10.2-1 ii mplayer2 [mplayer] 2.0-728-g2c378c7-2+b1 ii rtmpdump2.4+20131018.git79459a2-4 youtube-dl suggests no packages. -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756370: taskwarrior: unable to sync to taskd due to GnuTLS support.
Control: forcemerge 741625 756370 $ task sync init Taskwarrior was built without GnuTLS support. Sync is not available. Known bug. :-) Merging. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756372: inputplug: in the copyright file, the Source URL is no longer valid
Package: inputplug Version: 0.2-2 Severity: normal /usr/share/doc/inputplug/copyright contains: Source: https://bitbucket.org/andrew_shadoura/inputplug/ but this URL is no longer valid (404 error). -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages inputplug depends on: ii libc6 2.19-7 ii libixp0 0.6~20121202+hg148-2 ii libx11-6 2:1.6.2-2 ii libxi62:1.7.4-1 inputplug recommends no packages. inputplug 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#756373: RFS: gnustep-examples/1:1.4.0-1 -- GNUstep example applications
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package gnustep-examples. It builds these binary packages: gnustep-examples - GNUstep example applications To access further information about this package, please visit the following URL: http://mentors.debian.net/package/gnustep-examples Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/g/gnustep-examples/gnustep-examples_1.4.0-1.dsc Changes since the last upload: * New upstream release: - Compatible with gnustep-gui/0.24 (Closes: #749747). * debian/watch: Update to look at usr-apps as well. Use pgpsigurlmangle. * debian/compat: Set to 9. * debian/control (Build-Depends): Require libgnustep-gui-dev (= 0.24) and debhelper (= 9). Drop dpkg-dev. (Vcs-Git): Use the canonical URI. (Standards-Version): Compliant with 3.9.5 as of this release. * debian/patches/typo-fix.patch: New. * debian/patches/series: Update. * debian/preinst: * debian/README.source: Delete. * debian/rules: Rewrite for modern dh. * debian/upstream/signing-key.pgp: * debian/source/include-binaries: * debian/install: New file. * debian/Calculator.desktop: * debian/Ink.Desktop: Add Keywords field. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755513: nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1
Control: found -1 ocl-icd-libopencl1/2.1.3-4 But nvidia-opencl-dev conflicts with opencl-dev, and ocl-icd-liopencl1 conflicts with libopencl1. There is no explicit conflict between each other. As long as ocl-icd-liopencl1 is providing a file that conflicts with nvidia-opencl-dev, they should conflict with each other. If you install ocl-icd-opencl-dev *after* nvidia-cuda-toolkit, the problem does not occur. That's because ocl-icd-libopencl1 has Replaces: nvidia-libopencl1-dev Both packages simply having Replaces, and no Conflicts/Breaks, could work. # dpkg-deb -c /var/cache/apt/archives/ocl-icd-libopencl1_2.1.3-4_amd64.deb | grep libOpenCL.so -rw-r--r-- root/root 35200 2014-02-07 00:38 ./usr/lib/x86_64-linux-gnu/libOpenCL.so.1.0.0 lrwxrwxrwx root/root 0 2014-02-07 00:38 ./usr/lib/x86_64-linux-gnu/libOpenCL.so - libOpenCL.so.1.0.0 lrwxrwxrwx root/root 0 2014-02-07 00:38 ./usr/lib/x86_64-linux-gnu/libOpenCL.so.1 - libOpenCL.so.1.0.0 # dpkg-deb -c /var/cache/apt/archives/nvidia-opencl-dev_5.5.22-4_amd64.deb | grep libOpenCL.so lrwxrwxrwx root/root 0 2014-05-25 01:36 ./usr/lib/x86_64-linux-gnu/libOpenCL.so - libOpenCL.so.1 # dpkg-deb -c /var/cache/apt/archives/nvidia-libopencl1_340.24-2_amd64.deb | grep libOpenCL -rw-r--r-- root/root 21712 2014-07-03 00:18 ./usr/lib/x86_64-linux-gnu/libOpenCL.so.1.0.0 lrwxrwxrwx root/root 0 2014-07-20 10:31 ./usr/lib/x86_64-linux-gnu/libOpenCL.so.1 - libOpenCL.so.1.0.0 So, Either nvidia-libopencl1-dev should gain a Replaces: ocl-icd-libopencl1. Or ocl-icd-libopencl1 should Conflict on nvidia-libopencl1-dev, instead of Replacing it. The first option allows higher installability. The second option keeps all the relationships confined to ocl-icd-libopencl1, which is the package breaking policy (#679228). SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756374: linux-image-3.14-1-amd64: Nouveau driver can't working good wirh all engines
Package: src:linux Version: 3.14.12-1 Severity: normal Hi I decided to return on free driver nouveau and after many try. Fore more informations see here http://nouveau.freedesktop.org/wiki/KernelModuleParameters/ On my fail to start X server with engine SW. On /etc/default/grub edit GRUB_CMDLINE_LINUX_DEFAULT=quiet nouveau.config=SW=0 on order to disable SW engine. When SW engine is enabled on default, break to start enlightenment, kde, gdm3, gnome3. -- Package-specific info: ** Version: Linux version 3.14-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-4) ) #1 SMP Debian 3.14.12-1 (2014-07-11) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.14-1-amd64 root=/dev/mapper/debian-root ro quiet nouveau.config=DEVICE=1 nouveau.config=DMAOBJ=1 nouveau.config=PBSP=1 nouveau.config=PCEO=1 nouveau.config=PCE1=1 nouveau.config=PCE2=1 nouveau.config=PCRYPT=1 nouveau.config=PDISP=1 nouveau.config=PFIFO=1 nouveau.config=PGRAPH=1 nouveau.config=PMPEG=1 nouveau.config=PPM=1 nouveau.config==1 nouveau.config=PVP=1 nouveau.config=SW=0 ** Not tainted ** Kernel log: [7.822850] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input5 [7.831427] input: HDA Intel Front Headphone as /devices/pci:00/:00:1b.0/sound/card0/input13 [7.831482] input: HDA Intel Line Out Side as /devices/pci:00/:00:1b.0/sound/card0/input12 [7.831532] input: HDA Intel Line Out CLFE as /devices/pci:00/:00:1b.0/sound/card0/input11 [7.831581] input: HDA Intel Line Out Surround as /devices/pci:00/:00:1b.0/sound/card0/input10 [7.831632] input: HDA Intel Line Out Front as /devices/pci:00/:00:1b.0/sound/card0/input9 [7.831682] input: HDA Intel Line as /devices/pci:00/:00:1b.0/sound/card0/input8 [7.831730] input: HDA Intel Rear Mic as /devices/pci:00/:00:1b.0/sound/card0/input7 [7.831779] input: HDA Intel Front Mic as /devices/pci:00/:00:1b.0/sound/card0/input6 [8.088546] input: PC Speaker as /devices/platform/pcspkr/input/input14 [8.099052] wmi: Mapper loaded [8.199563] snd-ca0106: Model 100a Rev Serial 100a1102 [8.229049] [drm] hdmi device not found 1 0 1 [8.229185] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x046f00a3 [8.229188] nouveau [ DEVICE][:01:00.0] Chipset: G72 (NV46) [8.229190] nouveau [ DEVICE][:01:00.0] Family : NV40 [8.230759] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... [8.307500] nouveau [ VBIOS][:01:00.0] ... appears to be valid [8.307506] nouveau [ VBIOS][:01:00.0] using image from PRAMIN [8.307640] nouveau [ VBIOS][:01:00.0] BIT signature found [8.307644] nouveau [ VBIOS][:01:00.0] version 05.72.22.43.00 [8.307679] iTCO_vendor_support: vendor-support=0 [8.308193] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10 [8.308240] iTCO_wdt: Found a ICH9 TCO device (Version=2, TCOBASE=0x0860) [8.308560] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [8.309455] nouveau :01:00.0: irq 45 for MSI/MSI-X [8.309470] nouveau [ PMC][:01:00.0] MSI interrupts enabled [8.309505] nouveau [ PFB][:01:00.0] RAM type: DDR2 [8.309508] nouveau [ PFB][:01:00.0] RAM size: 256 MiB [8.309510] nouveau [ PFB][:01:00.0]ZCOMP: 0 tags [8.403278] cdc_acm 7-6:1.1: This device cannot do calls on its own. It is not a modem. [8.403471] cdc_acm 7-6:1.1: ttyACM0: USB ACM device [8.404478] usbcore: registered new interface driver cdc_acm [8.404482] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters [8.443956] coretemp coretemp.0: Using relative temperature scale! [8.443974] coretemp coretemp.0: Using relative temperature scale! [9.596033] nouveau [ PTHERM][:01:00.0] FAN control: none / external [9.596045] nouveau [ PTHERM][:01:00.0] fan management: automatic [9.596049] nouveau [ PTHERM][:01:00.0] internal sensor: yes [9.615961] nouveau [ PTHERM][:01:00.0] temperature (94 C) hit the 'fanboost' threshold [9.616019] nouveau [ CLK][:01:00.0] 20: core 550 MHz shader 550 MHz memory 540 MHz [9.616030] nouveau [ CLK][:01:00.0] --: core 199 MHz memory 391 MHz [9.616143] [TTM] Zone kernel: Available graphics memory: 2029410 kiB [9.616146] [TTM] Initializing pool allocator [9.616153] [TTM] Initializing DMA pool allocator [9.616172] nouveau [ DRM] VRAM: 252 MiB [9.616174] nouveau [ DRM] GART: 512 MiB [9.616179] nouveau [ DRM] TMDS table version 1.1 [9.616182] nouveau W[ DRM] TMDS table script pointers not stubbed [9.616184] nouveau [ DRM] DCB version 3.0 [9.616187] nouveau [ DRM] DCB outp 00: 01000300 0028 [9.616190] nouveau [ DRM] DCB outp 01: 02011310 0028 [9.616192] nouveau [ DRM] DCB outp 02: 01011312 [9.616194]
Bug#756375: systemd-sysv: Can not normal shutdown with ulatencyd
Package: systemd-sysv Version: 208-6 Severity: normal Dear Maintainer, I want to reopen bug report (the old one number: 755375) When my system installed ulatencyd, my system can not normal shutdown, even as root. I opened the bug report, number: 755375, deveplor said: - I believe this is a configuration issue, not a bug. Please see (1) https://github.com/poelzi/ulatencyd/wiki/Faq#id4 Closing, please reopen if the problem persists after adjusting the systemd configuration as documented in the ulatencyd faq. - I tried remove /etc/ulatencyd, then reinstall ulatencyd with default setup/config (/etc/ulatencyd/*), but still can not normal shutdown. then I tried following the (1)Faq#id4 add 3 line to /etc/ulatencyd/system.conf --- DefaultControllers= JoinControllers= controllers= --- but still can not normal shutdown. then I remove ulatencyd (apt-get remove ulatencyd), my system can normal shutdown. So, I want to reopen this bug report. Thank you. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd-sysv depends on: ii systemd 208-6 systemd-sysv recommends no packages. systemd-sysv 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#756144: network-manager: DHCP client upgrade is handled poorly
Strange enough, today the situation was repeated after seemingly unrelated upgrade. Part of apt log is attached.Start-Date: 2014-07-29 13:23:22 Commandline: synaptic Install: libgvc6:i386 (2.38.0-4, automatic), libcgraph6:i386 (2.38.0-4, automatic), libgvpr2:i386 (2.38.0-4, automatic), libparted2:i386 (3.1-4, automatic), libcdt5:i386 (2.38.0-4, automatic) Upgrade: libraw1394-11:i386 (2.1.0-2, 2.1.0-3), libkpathsea6:i386 (2014.20140528.34243-4, 2014.20140528.34243-5), festvox-ru:i386 (0.5-6, 0.5+dfsg-1), libptexenc1:i386 (2014.20140528.34243-4, 2014.20140528.34243-5), libpathplan4:i386 (2.26.3-17.1, 2.38.0-4), graphviz:i386 (2.26.3-17.1, 2.38.0-4), libdc1394-22:i386 (2.2.2-1, 2.2.2-3), libpcre3:i386 (8.31-5, 8.35-3), libimobiledevice4:i386 (1.1.6+dfsg-2, 1.1.6+dfsg-3), parted:i386 (2.3-20, 3.1-4), alsa-oss:i386 (1.0.25-1, 1.0.28-1), libxdot4:i386 (2.26.3-17.1, 2.38.0-4), libtk8.6:i386 (8.6.1-5, 8.6.1-6), libgnutls-deb0-28:i386 (3.2.15-3, 3.2.16-1), poedit:i386 (1.5.4-2, 1.5.4-3), powertop:i386 (2.5-1, 2.6.1-1), tk8.6:i386 (8.6.1-5, 8.6.1-6), libfltk1.1:i386 (1.1.10-18, 1.1.10-19), libgnutls-openssl27:i386 (3.2.15-3, 3.2.16-1) Remove: libgvc5:i386 (2.26.3-17.1) End-Date: 2014-07-29 13:24:34 Start-Date: 2014-07-29 14:32:58 Commandline: synaptic Purge: libgraph4:i386 (2.26.3-17.1), libgvc5:i386 (), libcgraph5:i386 (2.26.3-17.1), libgvpr1:i386 (2.26.3-17.1), libcdt4:i386 (2.26.3-17.1), libmowgli2:i386 (1.0.0-4) End-Date: 2014-07-29 14:33:05
Bug#752075: daemontools-run: Add systemd support
Hi Michael, On Fri, Jul 18, 2014 at 08:06:11PM +0200, Michael Stapelberg wrote: Gerrit Pape p...@dbnbgs.smarden.org writes: I'm really not keen to add a dependency to daemontools-run, esp. not to the runit package, just for (un)installing and starting/stopping a service. I presume you mean init-system-helpers as the dependency you don???t want to add. Any dependency: $ apt-cache show runit |grep ^Depends $ apt-cache show daemontools-run |grep ^Depends Depends: daemontools ( 1:0.76) $ apt-cache show daemontools |grep ^Depends Depends: libc6 (= 2.7-1) $ Why isn't it as simple as installing the unit, and then?: systemd not installed || start service It is as simple as that. deb-systemd-invoke supports policy-rc.d, though, which your intended example (AIUI) does not. You???d make some users really unhappy if you break policy-rc.d with your package. I don't think so. The daemontools-run and runit packages don't include init scripts. policy-rc.d never had an effect on them, so nothing will break. systemd not installed || have service started by default When systemd is not installed, where does the logic for having the service started by default come from? While the actually relevant part of that is as simple as creating a symlink, there are some things make this entire process more complicated. Some of them come from the fact I hope this as simple as creating a symlink works out. that the enabled-state needs to be synchronized across init systems, i.e. what you do in systemd should also work for the sysvinit-fallback. This is not necessary for the packages in question. They have an inittab entry since many years SV:123456:respawn:/usr/sbin/runsvdir-start The whole purpose of the packages is to provide this service, no enabled-state is needed. $ apt-cache show runit |grep ^Description-en Description-en: system-wide service supervision $ apt-cache show daemontools-run |grep ^Description-en Description-en: daemontools service supervision $ Further, consider this (from the manpage of deb-systemd-helper): The enable action will only be performed once (when first installing the package). On the first enable, an state file is created which will be deleted upon purge. ???which enables administrators to disable units and not have them magically re-enabled on the next package upgrade. See above, I don't think this applies. Also, the dh-systemd/deb-systemd-helper combination properly handles mask-after-remove (i.e. remove but not purge). Anything wrong in this regard with my current implementation? In general, it???s hugely beneficial to Debian if packages use the same helpers/debhelper addons to build their maintainer scripts. Bugfixes and other improvements that we put into i-s-h will propagate to all packages without coordinating huge updates/fixes. You don???t need to think about all the intricacies of correctly handling unit files (in Debian!) because we already did it. We're different individuals in Debian and have different opinions. To me it's beneficial to Debian if there still exist packages not using debhelper, doing things differently than others, even than the masses, following KISS. I want to think about and understand how the inittab entry SV:123456:respawn:/usr/sbin/runsvdir-start translates most easily into a systemd service, now that I learned that this is necessary because systemd doesn't provide backward compatibility for such services. Let me also point out that _every_ system already has i-s-h installed these days, so there really is no cost in adding this dependency. That's not true. Just a few of my systems have this package pulled in, all of them have runit installed. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756376: kontact immediately crashes (SIGSEGV) on startup
Package: libkontactinterface4 Version: 4:4.13.3-1 Severity: serious Justification: breaks Kontact, should not migrate to testing Forwarded: https://bugs.kde.org/show_bug.cgi?id=337876 Hi, see below. Downgrading myself fixes the problem for me, too. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- Forwarded message -- From: t...@online.de Message-ID: bug-337876-159046-ewfv7xy...@http.bugs.kde.org/ Sender: bugzilla_nore...@kde.org To: t.gla...@tarent.de Date: Tue, 29 Jul 2014 11:01:38 + Subject: [kontact] [Bug 337876] kontact immediately crashes (SIGSEGV) on startup Reply-To: bug-cont...@bugs.kde.org https://bugs.kde.org/show_bug.cgi?id=337876 t...@online.de changed: What|Removed |Added CC||t...@online.de --- Comment #1 from t...@online.de --- I have a similar setup (Debian unstable, amd64) and faced the same problem after my last update. I noted that libkontactinterface4 was updated from 4:4.12.4-1 to 4:4.13.3-1. Downgrading it back to 4:4.12.4-1 (using the package from debian testing) helped. It seems to be a debian packaging problem mixing up kde 4.12 and kde 4.13 stuff... -- You are receiving this mail because: You reported the bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756083: dictionaries-common: Not updated, package attempts to create a symlink from non-existing file.
Control: tag 756083 + unreproducible On Sat, Jul 26, 2014 at 06:28:57PM -0400, Valdinilson L. Cunha wrote: Package: dictionaries-common Version: 1.23.10 Followup-For: Bug #756083 Hi, Had some time to debug this, and seems not a problem with triggers ordering. Which directory does not exists? The simlinks /usr/lib/ispell/brasileiro.hash was pointing to /var/lib/ispell/brasileiro.hash. The directory /var/lib/ispell/ does not exist on my system until that moment. Hi, thanks for the info, /var/lib/ispell/ should have been created by ibrazilian preinst and filled with an empty /var/lib/ispell/ibrazilian.compat file. Later in trigger (enabled from postinst) a ibrazilian.hash hash file had to be created and a version string written to that compat file. If above directory does not exists, ibrazilian postinst should have failed. Unluckily I did not found it in my tests, which already included some upgrades and installations from scratch. I am unable to reproduce the error too, but if there's any news will report here. I do not know if it helps, but put a little piece of the upgrade log that occurred when the error occurred. Start-Date: 2014-07-25 18:54:13 Upgrade: [...] dictionaries-common:amd64 (1.23.9, 1.23.10), [...] Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2014-07-25 19:03:23 Seems that neither ispell dictionaries nor wordlists are ugraded in this run, just dictionaries-common. I guess this was an one time problem due to something removing that /var/lib/ispell/ibrazilian.compat file and causing empty /var/lib/ispell/ removal. I tried to reproduce this problem also in wheezy to sid upgrades. No success. I am tagging this as unreproducible, but will wait for some time in case somebody else can reproduce this problem and provide more info. If not, I will close it, after trying harder not to remove empty /var/lib/ispell/ if ispell dictionaries are instaled. This will not fix the problem if it reappears, but should provide better info. Thanks again for all the feedback, Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
On Mon, Jul 28, 2014 at 02:36:06PM +0200, Michael Biebl wrote: Since you are going to do it your way anyway I'm not sure why you ask for feedback from us? It's like talking to a brick wall. Hi, I'm sorry that you feel this way. I also found our communication far from ideal, and after I refused to add a dependency to the daemontools-run and runit packages, it failed completely. To me this feels like do it your way, or no way. Since you're the specialists, there's still hope to get feedback other than On Tue, Jul 22, 2014 at 03:03:02PM +0200, Michael Biebl wrote: There is a reason, why we added the logic in a single place. On Tue, Jul 22, 2014 at 06:11:24PM +0200, Michael Stapelberg wrote: I'm not sure how we can state this more clearly: Use dh-systemd or you _will_ have bugs sooner or later. It is the most simple implementation that we could come up with. There also are reasons for my design choice. There are still various issues with the maintainer scripts code [1] Please tell me which ones. [1] aside from the fact that negative clauses make it unnecessarily hard to read. The fact is that people are different. To me this is most intuitively to read in set -e scripts. When does this script stop?: set -e true true false false || true false false false true || true false true false true || false true true || false true true false true false false and I see you dropped the .path unit again? Yes. I don't understand the question. On Tue, Jul 22, 2014 at 03:18:02PM +0200, Michael Biebl wrote: What about Ansgar's improvements/suggestions [1]? E.g. adding a Documentation= header, directly using svscan, etc? Thanks to Ansgar, I looked at them but currently don't want to do a bit more integration into systemd. KISS and provide the very same software experience to users of these packages under sysvinit, runit, and systemd. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756377: parallel(1) manpage: no examples in EXAMPLE
Package: moreutils Version: 0.51 Severity: minor There are no actual examples in the EXAMPLE section of the parallel(1) manpage. It reads only: This runs three subshells that each print a message, delay, and print another message. If your system has multiple CPUs, parallel will run some of the jobs in parallel, which should be clear from the order the messages are output. This runs three ufraw processes at the same time until all of the NEF files have been processed. This runs three independent commands in parallel. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
Hi Michael, On Tue, Jul 22, 2014 at 06:11:24PM +0200, Michael Stapelberg wrote: I'm not sure how we can state this more clearly: Use dh-systemd or you _will_ have bugs sooner or later. It is the most simple implementation that we could come up with. sorry, we have different points of view, and I will definitely not switch my packages to debhelper. Sure, most probably there will be bugs sooner or later, considering that systemd intergration is still under development. But also for packages utilizing debhelper, maybe even more more so because the implementation is more complex. They'll probably go through binary NMUs. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756379: xscorch: update config.{sub, guess} to fix FTBFS for ppc64le port
Package: xscorch Version: 0.2.1 Severity: normal Tags: patch User: debian-de...@lists.debian.org Usertags: autotools_dev ppc64el Dear Maintainer, In order to avoid FTBFS xscorch package on ppc64le arch, config.guess and config.sub need to be updated. Please consider the attached patch, which is tested on ppc64le internal build machine. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 3.13-1-powerpc64le (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --===1598097842726577918== Content-Type: text/x-diff; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=update-autotools.debpatch From 7d9a393c2803a2459196d91abd4039206b6de671 Mon Sep 17 00:00:00 2001 From: Ravindran Arani r...@linux.vnet.ibm.com Date: Tue, 29 Jul 2014 11:02:02 + Subject: [PATCH] autorecof --- debian/control | 2 +- debian/rules | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/debian/control b/debian/control index 72dc172..981f07e 100644 --- a/debian/control +++ b/debian/control @@ -4,7 +4,7 @@ Priority: optional Homepage: http://www.xscorch.org/ Maintainer: Jacob Luna Lundberg ja...@gnifty.net Standards-Version: 3.9.2 -Build-Depends: debhelper (= 7), groff, libglib2.0-dev, libgtk2.0-dev (= 2.20), libmikmod2-dev, libreadline-gplv2-dev | libreadline5-dev, libx11-dev, libxext-dev, libxi-dev +Build-Depends: debhelper (= 7), groff, libglib2.0-dev, libgtk2.0-dev (= 2.20), libmikmod2-dev, libreadline-gplv2-dev | libreadline5-dev, libx11-dev, libxext-dev, libxi-dev, autotools-dev Package: xscorch Architecture: any diff --git a/debian/rules b/debian/rules index 045b29c..3e5ad38 100755 --- a/debian/rules +++ b/debian/rules @@ -11,6 +11,7 @@ build-indep: build-stamp build-stamp: dh_testdir +dh_autotools-dev_updateconfig ./configure --prefix=/usr --bindir=/usr/games --mandir=/usr/share/man --datadir=/usr/share/games --without-gnome --enable-network $(MAKE) @@ -23,6 +24,7 @@ clean: [ ! -f Makefile ] || $(MAKE) distclean +dh_autotools-dev_restoreconfig dh_clean install: install-stamp -- 1.8.5.3 --===1598097842726577918==-- -- Ravindran IBM LinuxTechnologyCenter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756378: dh_python[23] doesn't parse 'Requires' attribute in egg info files generated by distutils
Package: dh-python Version: 1.20140511-1 Severity: important Seen with python-pyasn1-modules when building in a clean chroot without having setuptools installed. There is no dependency on pyasn1 added, because dh_python[23] only parses the requires.txt file in an egg info directory, but not the Requires attribute in an egg-info file. $ tail -1 debian/tmp/usr/lib/python3.4/dist-packages/pyasn1_modules-0.0.5.egg-info Requires: pyasn1(=0.1.4) $ cat debian/python3-pyasn1-modules.substvars python3:Depends=python3:any (= 3.3.2-2~) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Fair enough, but the argument seems to consist of 'if you don't obey the rules bad behaviour results, ergo the rule is bad' which is kind of like arguing that making people obey the law is bad because some people got to jail. Basically the arguments are political not technical, even if it is dressed up as technical, which is why the arguments end up being political. Regards, Daniel On 29/07/14 03:22 AM, Joachim Breitner wrote: Hi, Am Dienstag, den 29.07.2014, 00:22 -0400 schrieb Daniel Dickinson: Yeah but the guy claiming FQDN broken is the same Lennart who seems hell bent on destroying every *nix idiom. I wouldn't go by his opinion. and I won’t discuss technical issues on this level. Greetings, Joachim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756380: llvm-toolchain-3.5: Add support for ppc64el
Package: llvm-toolchain-3.5
Severity: normal
Tags: patch
Dear Maintainer,
Please consider adding support for ppc64el, as per below patch.
diff -Nru llvm-toolchain-3.5-3.5~+rc1/debian/rules llvm-toolchain-3.5-3.5~+rc1/debian/rules
--- llvm-toolchain-3.5-3.5~+rc1/debian/rules 2014-07-15 13:20:25.0 +
+++ llvm-toolchain-3.5-3.5~+rc1/debian/rules 2014-07-29 10:52:48.0 +
@@ -60,7 +60,7 @@
control_vars = '-Vdep:devlibs=libstdc++6-$(GCC_VERSION)-dev'
endif
-BINUTILS_GOLD_ARCHS := amd64 armhf i386 powerpc powerpcspe ppc64 sparc sparc64 x32
+BINUTILS_GOLD_ARCHS := amd64 armhf i386 powerpc powerpcspe ppc64 ppc64el sparc sparc64 x32
ifeq ($(shell dpkg --compare-versions $(shell dpkg-query -W -f '$${Version}' binutils) ge 2.23.1-1~exp3 ; echo $$?),0)
ifneq (,$(findstring $(DEB_HOST_ARCH),$(BINUTILS_GOLD_ARCHS)))
# -fused-ld=gold enables the gold linker (but is not supported by all archs / distro)
@@ -116,7 +116,7 @@
LLDB_ENABLE=yes
-LLDB_DISABLE_ARCHS := arm64 hurd-i386 mips mipsel ia64
+LLDB_DISABLE_ARCHS := arm64 hurd-i386 mips mipsel ia64 ppc64el
# hurd has threading issues
# mips* fails with undefined references to `__atomic_load_8'
ifeq (,$(filter-out $(LLDB_DISABLE_ARCHS), $(DEB_HOST_ARCH)))
Regards,
Dimitri.
Bug#755809: xorg.conf.5 man page mentions an incorrect Enable option for Monitors
Julien Cristau, 2014-07-28 23:56+0200: Note how the manpage says enable all connected monitors, not enable all monitors. Right, that was subtle but useful indeed. Here is an updated patch then. -- ,--. : /` ) ن Tanguy Ortoloxmpp:tan...@ortolo.eu | `-'Debian Developer irc://irc.oftc.net/Tanguy \_ Description: Complete the xorg.conf.5 manpage with Option Disable The xorg.conf.5 manpage mentions an Enable option to enable a monitor regardless of whether or not it is connected, but gives no indication of how to disable it. This patch corrects that by documenting the Disable option. Author: Tanguy Ortolo tanguy+deb...@ortolo.eu Last-Update: 2014-07-29 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ Index: xorg-server/hw/xfree86/man/xorg.conf.man === --- xorg-server.orig/hw/xfree86/man/xorg.conf.man +++ xorg-server/hw/xfree86/man/xorg.conf.man @@ -1812,6 +1812,12 @@ at startup. By default, the server will monitors. (RandR 1.2-supporting drivers only) .TP 7 +.BI Option \*qDisable\*q \*q bool \*q +This optional entry specifies whether the monitor should be turned off +at startup. By default, the server will attempt to enable all connected +monitors. +(RandR 1.2-supporting drivers only) +.TP 7 .BI Option \*qDefaultModes\*q \*q bool \*q This optional entry specifies whether the server should add supported default modes to the list of modes offered on this monitor. By default, the server signature.asc Description: Digital signature
Bug#725144: libvirt-bin: Please build with apparmor support.
Hi, AppArmor support works fine on current sid. Seems to have been the case since 1.2.1-2, and refined later for non-Linux. Shall we close this bug? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756381: RM: ruby-amrita2 -- ROM; upstream dead, does not work with newer rubies
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, could you please remove ruby-amrita2 (libamrita2-ruby1.8,libamrita2-ruby1.9.1,ruby-amrita2) from Debian? - - RC buggy - - upstream dead - - upstream homepage dead - - does not work with newer rubies - - no rdepends Thanks, Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJT14eJAAoJEPBM7/YBbP/QTegP/3LKLwxxdZVgTZEtoXv2rg/k LEgSjB+dLJvMxkEboiGq0N7J991V5WzxyKORyITMwauZzwZ/HX7C4yP94XRFLkBR +7/DfBcKn2UlfsflzT+1qOrLeyECryxdRPizFNBJRFr96afxAK3VVQSoyHYtpWQj H234fHKGNcJMbjFDlBgsA/PiEDtVyJeDry42vxHcCRWec8tetCstqADQE0ZO2DYq nFFPhxG+rSOaX11LihVIeoUGaI8t8WetS0aFt3vtar11b9gumb7iXFdzpRtdkJwZ ACpK6Aa0PzFlvXWm0cWjVTWmgLhqGGGRs7JVJXe/JRjWdOJuJfU9Fm6VVqCEbvGB f/z3bcKRwGIflZ74GR1iqovWSHyczp0cuom3kVT0HdTek66rIZbAfigqY0zIJNzc 2QhNx1q+1qevNkV76Z1hfXvmTZbsLj4Q3qlahpNcWqj+FMJxgu8oNrwAu1/RT+B3 +hLed/gvFUDlGwc1EUkgGWLbWjsKk+WXXxl4W+IIJOGmwcUzp1Bkp2RJ6RCH/Ugh ftwUputCA7NjYvrKPsV+gRxXJU5Fz6CL42YJRMXLl+2W0+cQgH7fuFXaoDS2zPfk 67knZigaFyaFbH9DC4I4F8a0Qa61qsSQc1bJ4MVCsqUDHnQgOXXvEph/0KOsoG+j vN6s1FeJ0F4A0NyxeWLg =Kurh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744139: palapeli: Crashes when creating puzzle
Control: tag -1 + unreproducible moreinfo Hi, I couldn't reproduce the issue neither with the wheezy version nor with the jessie version, maybe the issue is related to the picture you are trying to use, can you plublish a small image file that reproduces the issue? Happy hacking, -- Any change looks terrible at first. -- Principle of Design Inertia Saludos /\/\ /\ `/ signature.asc Description: Digital signature
Bug#756382: libembperl-perl: FTBFS: #236 EmbperlObject/epobase.htm test failure: Error in Line 8
Package: libembperl-perl Version: 2.5.0-1 Severity: serious Tags: patch This package fails to build on current sid/amd64: Testing mod_perl mode... [...] #235 EmbperlObject/errdoc/epoerrdoc2.htm...ok #236 EmbperlObject/epobase.htm... Error in Line 8 Is: /p Should: /BODY/HTML Input: test/html/EmbperlObject/epobase.htm Output: test/tmp/out.htm Compared to:test/cmp/epobase.htm Log:test/tmp/test.log Testparameter: errors = 1 offline = 0 cgi = 0 ERRORS detected! NOT all tests have been passed successfully Makefile:1613: recipe for target 'test_dynamic' failed make[1]: *** [test_dynamic] Error 8 This diff shows the problem: --- test/cmp/epobase.htm2014-07-29 14:16:55.223944564 +0300 +++ test/tmp/out.htm2014-07-29 14:18:46.785998659 +0300 @@ -1,10 +1,9 @@ !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN -HTMLHEAD -TITLE403 Forbidden/TITLE -/HEADBODY -H1Forbidden/H1 -^.*?You don't have permission to access /embperl/EmbperlObject/epobase.htm -^on this server -/BODY/HTML - - +htmlhead +title403 Forbidden/title +/headbody +h1Forbidden/h1 +pYou don't have permission to access /embperl/EmbperlObject/epobase.htm +on this server.br / +/p +/body/html The apache2 error page was changed slightly by this upstream commit: https://github.com/apache/httpd/commit/4f8fc53c8f6df76a42ccc89275fcede72f9e https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/http/http_protocol.c?r1=1487127r2=1610328 which was included in apache2 2.4.10, recently uploaded in sid. Patch attached, this works for me with both 2.4.9 and 2.4.10. -- Niko Tyni nt...@debian.org From bcce23a15de55a39478f83a7923d8a89f681cc19 Mon Sep 17 00:00:00 2001 From: Niko Tyni nt...@debian.org Date: Tue, 29 Jul 2014 14:34:35 +0300 Subject: [PATCH] Adapt to an Apache 2.4.10 error page change The Forbidden error page was slightly changed by Apache commit https://github.com/apache/httpd/commit/4f8fc53c8f6df76a42ccc89275fcede72f9e https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/http/http_protocol.c?r1=1487127r2=1610328 breaking the EmbperlObject/epobase.htm test. The fix works with both the old and the new page format. --- test/cmp/epobase.htm | 1 + 1 file changed, 1 insertion(+) diff --git a/test/cmp/epobase.htm b/test/cmp/epobase.htm index ba29386..9d0269c 100644 --- a/test/cmp/epobase.htm +++ b/test/cmp/epobase.htm @@ -5,6 +5,7 @@ H1Forbidden/H1 ^.*?You don't have permission to access /embperl/EmbperlObject/epobase.htm ^on this server +^-/p /BODY/HTML -- 2.0.1
Bug#755718: RFS: nltk/3.0.0b1-1 [ITP] -- Python Natural Language Toolkit
Hi Daniel, thanks for finalising nltk. I just sponsored the package since I it was fine in terms of packaging. Hint for the SoB[1] mechanism: I really want you to care for the injection of the package into the Blends framework. Since you do not have commit permissions I would have proxied the needed diff --git a/tasks/linguistics b/tasks/linguistics index 6526e84..bbcc7e8 100644 --- a/tasks/linguistics +++ b/tasks/linguistics @@ -52,3 +52,4 @@ Pkg-Description: SQL version of WordNet 3.0 Depends: travatar +Suggests: python-nltk, python3-nltk for you and I did it right now which has lead to the fact that it is just listed on the according sentinel page at http://blends.debian.org/science/tasks/linguistics#python-nltk I simply want to make people aware about the advantages of the Blends framework. Tomorrow (=after next cron job) this entry will propagate to the section Packages in new. Since you seem to be comfortable with linguistics I wonder what you think about a linguistics-dev task to develop linguistic applications (where we could turn the Suggests into Depends). I thinks all lib*-dev packages in this list are good candidates. What do you (and other readers) think? Kind regards Andreas. [1] https://wiki.debian.org/DebianPureBlends/SoB -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756383: missing license in debian/copyright
Package: adacgi Version: 1.6-18 Severity: serious User: alteh...@debian.org Usertags: ftp X-Debbugs-CC: ftpmas...@ftp-master.debian.org thanks Dear Maintainer, please add the missing licenses of: adacgi.spec to debian/copyright. Thanks! Thorsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756303: gmpc: Improvement to package description
* Reuben Thomas r...@sc3d.org [140728 17:53]: A GTK2 client for Music Player Daemon. Features include: Please, s/GTK2/graphical/: this kind of technical term doesn’t have its place inside the package description. Even better. I was about to note that in any case it will be a GTK3 app in its next release. Although, I think many users are interested in knowing whether an application is native to their favourite desktop (in particular, GNOME KDE users). Thanks for the suggestions, I will apply this change. As for the native aspect, I think that users that want this are used to the convention that g is a GTK application. -- Etienne Millon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756384: xprobe: update config.{sub, guess} to fix FTBFS for ppc64le port
Package: xprobe Version: 0.3-1.1 Severity: normal Tags: patch User: debian-de...@lists.debian.org Usertags: autotools_dev ppc64el Dear Maintainer, In order to avoid FTBFS xprobe package on ppc64le arch, config.guess and config.sub need to be updated. Please consider the attached patch, which is tested on ppc64le internal build machine. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 3.13-1-powerpc64le (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xprobe depends on: ii libc6 2.19-1 ii libgcc1 1:4.9.0-6 ii libpcap0.8 1.5.3-1 ii libstdc++6 4.9.0-6 xprobe recommends no packages. xprobe suggests no packages. -- no debconf information --===1710612676913310510== Content-Type: text/x-diff; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=update-autotools.debpatch From 974d3fec7b4c52ef285d507a0401694373b85daf Mon Sep 17 00:00:00 2001 From: Ravindran Arani r...@linux.vnet.ibm.com Date: Tue, 29 Jul 2014 11:46:36 + Subject: [PATCH] update-autotools.debpatch --- debian/control | 2 +- debian/rules | 8 ++-- 2 files changed, 3 insertions(+), 7 deletions(-) diff --git a/debian/control b/debian/control index ec968d5..31475ce 100644 --- a/debian/control +++ b/debian/control @@ -2,7 +2,7 @@ Source: xprobe Section: net Priority: extra Maintainer: Richard Atterer atte...@debian.org -Build-Depends: debhelper ( 4), libpcap-dev (= 0.7.1) +Build-Depends: debhelper ( 4), libpcap-dev (= 0.7.1), autotools-dev Standards-Version: 3.5.9 Package: xprobe diff --git a/debian/rules b/debian/rules index 3a1d277..ad3c591 100755 --- a/debian/rules +++ b/debian/rules @@ -6,8 +6,7 @@ configure: configure-stamp configure-stamp: dh_testdir src/xprobe.cc -ln -s ../../../../cfg-scripts/config.guess libs-external/USI++/src/cfgaux -ln -s ../../../../cfg-scripts/config.sub libs-external/USI++/src/cfgaux +dh_autotools-dev_updateconfig ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc touch configure-stamp @@ -17,15 +16,12 @@ build-stamp: $(MAKE) touch build-stamp -# Removing outdated config.guess/sub: -# dpkg-source will ignore the deletion when making the diff.gz clean: dh_testdir src/xprobe.cc dh_testroot rm -f build-stamp configure-stamp -$(MAKE) distclean -rm -f libs-external/USI++/src/cfgaux/config.guess -rm -f libs-external/USI++/src/cfgaux/config.sub +dh_autotools-dev_restoreconfig dh_clean install: build -- 1.8.5.3 --===1710612676913310510==-- -- Ravindran IBM LinuxTechnologyCenter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756385: missing license in debian/copyright
Package: adasockets Version: 1.8.11-1 Severity: serious User: alteh...@debian.org Usertags: ftp X-Debbugs-CC: ftpmas...@ftp-master.debian.org thanks Dear Maintainer, please add the missing licenses of: doc/adasockets.texi to debian/copyright. Thanks! Thorsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756386: dblatex: Wrong indexterm sorting order for Norwegian Bokmål (nb)
Package: dblatex Version: 0.3.4-2 I ran into this problem while using dblatex (and docbook-xsl/fop, see bug #686908) to generate a PDF for the translated version of the Free Culture book by Lawrence Lessig. See URL: https://github.com/petterreinholdtsen/free-culture-lessig/ for the complete source of that project. The indexterm sorting order is wrong for the nb language choice when using dblatex. See the included docbook file for an example demonstrating the sorting, and the correct sorting order. This sorting order make dblatex unfit for typesetting a Norwegian book with an index. :( I reported a related bug #685721 earlier (incorrect heading in index), but this is about the index ordering, not the heading. Using this docbook file demonstrate the problem: !DOCTYPE book PUBLIC -//OASIS//DTD DocBook V4.5//EN http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; !-- The nb indexterm sorting order should be Alle inne, Bare tull, Ærlig talt, Øvrigheta, Åndalsnes under separete letter A, B, Æ, Ø and Å. But dblatex sort it Symbols Ærlig talt Øvrigheten Åndalsnes A Alle inne B Bare tull This sorting order is wrong. Note also how it uses 'Symbols' instead of 'Symboler', which would be the correct Norwegian translation for that heading. -- book lang=nb bookinfo titleExample demonstrating wrong nb indexterm sorting/title /bookinfo preface titletest/title indextermprimaryAlle inne/primary/indexterm paratest/para indextermprimaryÆrlig talt/primary/indexterm indextermprimaryØvrigheten/primary/indexterm indextermprimaryÅndalsnes/primary/indexterm paratext is good/para indextermprimaryBare tull/primary/indexterm paratext is great/para /preface index/index /book Is there some way to get the correct index sorting order using dblatex? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756387: cinnamon-common: cinnamon-settings: Backgrounds shows no choices after wallpapers are added
Package: cinnamon-common Version: 2.2.14-3 Severity: normal Tags: upstream patch Dear Maintainer, The Backgrounds module in the Cinnamon System Settings program does not show any wallpaper previews, either by default (which is probably reasonable), or after the user has clicked on Add and added a valid wallaper image (which is not reasonable). This prevents this settings module from building up a library of background images, making it entirely useless. It's fixable by patching /usr/share/cinnamon/cinnamon-settings/bin/imtools.py to be a bit more careful with its checks - the guts of PIL can't compare Images with None right now. Currently an exception is caught, printed and discarded by cs_backgrounds.py when mangling the cached preview thumbnails for display. Symptom: no wallpapers visible in the list - and 8- $ cinnamon-settings Could not find bluetooth module; is the cinnamon-control-center package installed? __init__ took 81.983 ms Loading Backgrounds module Failed to convert /home/testuser/.cinnamon/backgrounds/Dark_Ivy.jpg: 'NoneType' object has no attribute 'mode' [...] 8- and so on dumped the terminal after image files have been added. Patch: 8- --- imtools.py.BAK 2014-07-29 12:32:57.256599508 +0100 +++ imtools.py 2014-07-29 13:04:51.216999888 +0100 @@ -860,5 +860,5 @@ # Paste on top -if source == mask: +if mask and (source == mask): if has_alpha(source): # invert_alpha = the transparant pixels of the destination 8- Should cinnamon-common also depend on python-pil? PIL is clearly being pulled in though some other route by installing cinnamon though. I've not gone digging through the dependencies to check from where. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cinnamon-common depends on: ii dconf-gsettings-backend [gsettings-backend] 0.20.0-2 ii gir1.2-meta-muffin-0.0 2.2.6-2 ii python 2.7.8-1 cinnamon-common recommends no packages. cinnamon-common 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#756154: RM: v4l-utils [kfreebsd-amd64 kfreebsd-i386] -- ANAIS; Upstream dropped support for V4L utilities on kFreeBSD
On Monday, July 28, 2014 18:39:09 Gregor Jasny wrote: Hello, On 28/07/14 14:49, Scott Kitterman wrote: On Saturday, July 26, 2014 21:14:55 Gregor Jasny wrote: Package: ftp.debian.org Severity: normal Please remove the binary packages v4l-utils, qv4l2, dvb-tools, ir-keytable on [kfreebsd-amd64 kfreebsd-i386]. There are significant rdepends that will have to be dealt with first. Please remove the moreinfo tag once these are addressed: # Broken Build-Depends: amsn: libv4l-dev ... zoneminder: libv4l-dev (= 0.8.3) What I want you to do is to remove the *binary* packages v4l-utils, qv4l2, dvb-tools, ir-keytable on [kfreebsd-amd64 kfreebsd-i386], not the source package v4l-utils. In the reportbug mask I could not find a way to distinguish source and binary packages. That's why I wrote my little comment into the bug report itself. I hope this clarifies my intents. For more background please have a look at: https://www.mail-archive.com/debian-release@lists.debian.org/msg75705.html That helped. I removed all but v4l-utils. It still has an rdepend: # Broken Depends: v4l2loopback: v4l2loopback-utils Please get that resolved and then file a new bug for v4l-utils removal. Scott K -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756388: ITP: python-idna -- Internationalized Domain Names in Applications (IDNA)
Package: wnpp A library optionally needed for python-service-identity. Description: Internationalized Domain Names in Applications (IDNA) A library to support the Internationalised Domain Names in Applications (IDNA) protocol as specified in RFC 5891. This version of the protocol is often referred to as “IDNA2008” and can produce different results from the earlier standard from 2003. License: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: . - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. . - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. . - Neither the name of the copyright holder nor the names of the contributors may be used to endorse or promote products derived from this software without specific prior written permission. . - THIS SOFTWARE IS PROVIDED BY THE CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756389: libndp: CVE-2014-3554: buffer overflow
Source: libndp Version: 1.3-1 Severity: grave Tags: security upstream patch Hi, the following vulnerability was published for libndp. CVE-2014-3554[0]: buffer overflow If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2014-3554 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1118583 Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704206: teem: FTBFS[any-i386]: testsuite failures
Hi, Based on the patch provided by Adam, the attached patch fixes FTBFS on ppc64el. It adds ppc64el to the arches using -ffp-contract=off. Hoping it helps, Erwan. diff -Naur a/debian/rules b/debian/rules --- a/debian/rules 2014-07-29 14:15:22.230885507 +0200 +++ b/debian/rules 2014-07-29 14:15:45.574884266 +0200 @@ -16,7 +16,7 @@ ifneq (,$(filter $(DEB_HOST_ARCH_CPU), i386)) CFLAGS += -ffloat-store endif -ifneq (,$(filter $(DEB_HOST_ARCH_CPU), powerpc ppc64 s390 s390x)) +ifneq (,$(filter $(DEB_HOST_ARCH_CPU), powerpc ppc64 ppc64el s390 s390x)) CFLAGS += -ffp-contract=off endif
Bug#756380: (no subject)
Thanks Dimitri, FWIW, LLVM version 3.5 has accepted the support for the ppc64el architecture -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747270: [Python-modules-team] Bug#747270: python-librabbitmq
On 2014-07-28 07:42, Brian May wrote: Seems like there was already an attempt to package 1.5.0 (1.5.2 is now current), based on changes in subversion. Did this not work out? It did work out to the point where one should be able to build the package, but I did not find the time to test it. I note that the debian/patches/fix_setup.patch has extensive changes to setup.py (this no longer applies cleanly). Cleaning should be relatively easy as this patch just drops all the unnecessary cruft required for building the embedded librabbitmq-c lib. In Debian all this is provided by the librabbitmq library. I also note that the version number was called 1.5.0+dfsg-1, which suggests you had to repackage the orig.tar.gz file - was this the case? See debian/copyright. I excluded the whole embedded librabbitmq-c library. Thus the +dfsg suffix. Cheers, -- Michael Fladischer Fladi.at signature.asc Description: OpenPGP digital signature
Bug#756390: ITP: dune-grid-glue -- toolbox for solving PDEs -- compute couplings between grids
Package: wnpp Severity: wishlist Owner: Ansgar Burchardt ans...@debian.org * Package name: dune-grid-glue Upstream Author : Christian Engwer christian.eng...@uni-muenster.de, Oliver Sander san...@igpm.rwth-aachen.de * URL : http://www.dune-project.org/modules/dune-grid-glue/ * License : likely GPL-2 with an exception or LGPL Programming Lang: C++ Description : toolbox for solving PDEs -- compute couplings between grids dune-grid-glue provides infrastructure for the coupling of two unrelated DUNE grids. The coupling may be overlapping or nonoverlapping, conforming or nonconforming. The two grids are not required to be of the same type, and they may even be of different dimensions. The package will be maintained in the Debian Science Team. Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754134: (no subject)
I think so, I just look at the powerpc documentation and those instructions seems to work on powerpc. http://cache.freescale.com/files/32bit/doc/app_note/AN2540.pdf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756391: No dep8 tests
Source: nginx Version: 1.6.0-1 Severity: wishlist Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu utopic ubuntu-patch Smoke dep8 test for nginx attached (http://dep.debian.net/deps/dep8/). This helps me quickly check that nothing is fundamentally broken in nginx packaging in Ubuntu. It should be useful for Debian as well. Since Debian doesn't currently have the nginx-core package, you probably want to s/nginx-core/nginx-full/ in debian/tests/control before applying this. From 8d0337fda6dcc9946ca0280a63634368cac6b007 Mon Sep 17 00:00:00 2001 From: Robie Basak robie.ba...@canonical.com Date: Tue, 29 Jul 2014 12:13:42 + Subject: [PATCH 4/8] * Add dep8 smoke test --- debian/control | 1 + debian/tests/control | 3 +++ debian/tests/smoke | 4 3 files changed, 8 insertions(+) create mode 100644 debian/tests/control create mode 100644 debian/tests/smoke diff --git a/debian/control b/debian/control index 1883c86..2194932 100644 --- a/debian/control +++ b/debian/control @@ -28,6 +28,7 @@ Standards-Version: 3.9.5 Homepage: http://nginx.net Vcs-Git: git://anonscm.debian.org/collab-maint/nginx.git Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/nginx.git;a=summary +XS-Testsuite: autopkgtest Package: nginx Architecture: all diff --git a/debian/tests/control b/debian/tests/control new file mode 100644 index 000..d662282 --- /dev/null +++ b/debian/tests/control @@ -0,0 +1,3 @@ +Tests: smoke +Depends: nginx-core, curl +Restrictions: allow-stderr breaks-testbed isolation-container diff --git a/debian/tests/smoke b/debian/tests/smoke new file mode 100644 index 000..f85dc7a --- /dev/null +++ b/debian/tests/smoke @@ -0,0 +1,4 @@ +#!/bin/sh +set -ex + +curl -sf http://localhost -- 1.9.rc1 signature.asc Description: Digital signature
Bug#756392: enable SIMD and threading support
Package: raxml Version: 7.2.8-2 Severity: wishlist Dear Maintainer, the current RAxML package contains only the vanilla version of RAxML compiled without support threading or SIMD. Given that typical use cases of RAxML require days of computation, enabling parallel processing would improve the utility of the package significantly. RAxML does not detect the available hardware at runtime. Instead, separate Makefiles build the various optimized versions. Supported SIMD variants are: (none), SSE3, AVX and AVX2. Supported threading variants are: (none), PTHREADS, MPI and HYBRID (both pthreads and MPI). The makefile names are Makefile.SIMD-TYPETHREAD-TYPEgcc. Since most users will have multi-core CPUs and only very few a MPI environment, focusing on the PTHREAD variants with SIMD extensions should be a good balance between package complexity and extra value. The AVX2 extensions apparently do not add much performance. Therefore, I would suggest building three versions: - Makefile.PTHREADS.gcc - Makefile.PTHREADS.SSE3.gcc - Makefile.PTHREADS.AVX.gcc (depends = gcc 4.6) A simple bash wrapper script could then be used to make the appropriate choice for the user. E.g.: #!/bin/bash if grep -q avx /proc/cpuinfo; then exec raxml.PTHREADS.AVX $@ elif grep -q sse3 /proc/cpuinfo; then exec raxml.PTHREADS.SSE3 $@ else exec raxml.PTHREADS.NOSIMD $@ fi best regards, Elmar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683197: : Bug#683197: fop: incorrect formatting of large footnote (body and footnote overlap)
According to URL: https://issues.apache.org/jira/browse/FOP-2106 this issue was fixed upstream last year. Is it also fixed in a version of fop in Debian? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754173: [Tech] Debian kernel fix for routing regression in 3.2.60
Please reply to the bug address (754...@bugs.debian.org, 754...@bugs.debian.org or 754...@bugs.debian.org) to let us know whether this resolves the regression for you. Probably I keep version 3.2.57-3+deb7u2 till a fixed i386 binary is released. Anyway... thanks for your efforts, Ben. Gabor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756393: erlang-cowboy: New version upstream: 0.10.0
Package: erlang-cowboy Version: 0.8.6+dfsg1-1 Severity: wishlist Dear Maintainer, Please update erlang-cowboy to latest upstream version. It contains numerous improvements: https://github.com/extend/cowboy/blob/master/CHANGELOG.md Cheers, Balint -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747653: grub2-common: update-grub adds both devices and a line feed for BTRFS RAID 1 setup
Am Montag, 2. Juni 2014, 19:39:22 schrieb Andrey Borzenkov:
В Sat, 10 May 2014 20:53:34 +0200
Martin Steigerwald mar...@lichtvoll.de пишет:
Package: grub2-common
Version: 2.02~beta2-10
Severity: normal
Dear Maintainer,
I am booting my Debian system via a BTRFS RAID 1 which spans a logical
volume on a Crucial MSATA and Intel SATA SSD each.
After running update-grub I am getting this in /boot/grub/grub.cfg:
echo'Linux 3.15.0-rc5-tp520 wird geladen …'
linux /vmlinuz-3.15.0-rc5-tp520
root=/dev/mapper/sata-debian
/dev/mapper/msata-debian ro rootflags=subvol=debian
init=/bin/systemd resume=/dev/mapper/sata-swap
echo'Initiale Ramdisk wird geladen …'
initrd /initrd.img-3.15.0-rc5-tp520
update-grub basically adds both devices of the BTRFS RAID 1 device
separated by a line feed. For mounting BTRFS RAID 1 tough one of them
is enough, once btrfs device scan is run, for which I currently use an
script for initramfs-tools as a work-around as it didn´t work out of
the box on my last tests[1].
This behaviour is due to grub-probe which is called by grub-mkconfig
at line 139
138 # Device containing our userland. Typically used for root= parameter.
139 GRUB_DEVICE=`${grub_probe} --target=device /`
140 GRUB_DEVICE_UUID=`${grub_probe} --device ${GRUB_DEVICE}
--target=fs_uuid 2 /dev/null` || true
which is called by update-grub returns both devices with a
linefeed:
merkaba:~ grub-probe --target=device /
/dev/mapper/sata-debian
/dev/mapper/msata-debian
grub-probe is an ELF binary.
The following little change workarounds the issue for me:
merkaba:~ diff -u /usr/sbin/grub-mkconfig.dist /usr/sbin/grub-mkconfig
--- /usr/sbin/grub-mkconfig.dist2014-05-08 14:35:25.0
+0200
+++ /usr/sbin/grub-mkconfig 2014-05-10 20:46:00.380096263 +0200
@@ -136,7 +136,7 @@
fi
# Device containing our userland. Typically used for root= parameter.
-GRUB_DEVICE=`${grub_probe} --target=device /`
+GRUB_DEVICE=`${grub_probe} --target=device / | head -1`
GRUB_DEVICE_UUID=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_uuid
2 /dev/null` || true
# Device containing our /boot partition. Usually the same as
GRUB_DEVICE.
But I suppose the real fix is to be made in the binary grub-probe.
No, grub-probe is correct; grub needs to know all devices so it can
have full information which drivers it requires to access them.
See also
https://lists.gnu.org/archive/html/grub-devel/2014-05/msg5.html
I suggest you discuss it with Colin, but for now I tend to think, fix
should go into 10_linux. May be always use UUID for btrfs.
But this sounds like new can of worms :(
Any oppinions here on how to take this forward?
I just applied my patch from above again after a GRUB update.
Colin?
Andrey, what new kind of worms have you in mind? :)
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754997: libembperl-perl: FTBFS with Perl 5.20: Test failures
tag 754997 patch
thanks
On Wed, Jul 16, 2014 at 09:50:09PM +0300, Niko Tyni wrote:
Package: libembperl-perl
Version: 2.5.0-1
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.20-transition
This package fails to build with Perl 5.20.0
(currently in experimental):
#113 includeerr2.htm...
Expected 2 more error(s) in logfile
Input: test/html/includeerr2.htm
Output: test/tmp/out.htm
Log:test/tmp/test.log
The attached patch adapts the test suite to a few Perl 5.20
diagnostics changes, fixing the build failure.
(I now notice that I didn't update MANIFEST for the new expected
output file, that should be probably done too for tidiness.)
--
Niko Tyni nt...@debian.org
From 5c9f464ab89a634dbc74369ac29c7c6e456fa5c8 Mon Sep 17 00:00:00 2001
From: Niko Tyni nt...@debian.org
Date: Tue, 29 Jul 2014 15:21:29 +0300
Subject: [PATCH 2/2] Add compatibility with Perl 5.20
Two error messages have changed slightly, dropping the 'Might be a
multi-line string' notes.
According to https://rt.cpan.org/Public/Bug/Display.html?id=95335
this is due to upstream commit v5.19.3-296-gffdb8b1 so the conditionals
now look for 5.19.4 although this has only been tested with 5.20.0.
Bug: https://rt.cpan.org/Public/Bug/Display.html?id=95335
Bug-Debian: https://bugs.debian.org/754997
---
test.pl | 9 +-
test/cmp/includeerr2.htm520 | 69 +
2 files changed, 77 insertions(+), 1 deletion(-)
create mode 100644 test/cmp/includeerr2.htm520
diff --git a/test.pl b/test.pl
index 9714453..f19445e 100644
--- a/test.pl
+++ b/test.pl
@@ -435,9 +435,16 @@
'errors' = 9,
'version'= 2,
'repeat' = 2,
-'condition' = '$] = 5.018000',
+'condition' = '$] = 5.018000 $] 5.019400',
'cmpext' = '518',
},
+'includeerr2.htm' = {
+'errors' = 7,
+'version'= 2,
+'repeat' = 2,
+'condition' = '$] = 5.019400',
+'cmpext' = '520',
+},
'includeerr3.htm' = {
'errors' = 2,
'condition' = '$] 5.014000',
diff --git a/test/cmp/includeerr2.htm520 b/test/cmp/includeerr2.htm520
new file mode 100644
index 000..a755c10
--- /dev/null
+++ b/test/cmp/includeerr2.htm520
@@ -0,0 +1,69 @@
+HTMLHEADTITLEEmbperl Error/TITLE/HEADBODY bgcolor=#FF
+H1Internal Server Error/H1
+The server encountered an internal error or misconfiguration and was unable to complete your request.P
+^Please contact the server administrator,.*?and inform them of the time the error occurred, and anything you might have done that may have caused the error.PP
+table cellspacing='2' cellpadding='5'
+tr bgcolor='#ee'td
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+^\[\d+\]ERR: 32: Warning in Perl code: Use of uninitialized value \$Embperl::__\d+::param\[0\] in concatenation \(\.\) or string at .+incsub.htm line 6.
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+/td/tr
+tr bgcolor='#ee'td
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+^\[\d+\]ERR: 32: Warning in Perl code: Use of uninitialized value \$Embperl::__\d+::param\[0\] in concatenation \(\.\) or string at .+incsub.htm line 6.
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+/td/tr
+tr bgcolor='#ee'td
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+^\[\d+\]ERR: 32: Warning in Perl code: Use of uninitialized value \$Embperl::__\d+::param\[0\] in concatenation \(\.\) or string at .+incsub.htm line 6.
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+/td/tr
+tr bgcolor='#ee'td
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+^\[\d+\]ERR: 32: Warning in Perl code: Use of uninitialized value \$Embperl::__\d+::param\[0\] in concatenation \(\.\) or string at .+incsub.htm line 6.
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+/td/tr
+tr bgcolor='#ee'td
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+^\[\d+\]ERR: 24: Error in Perl code: Can't locate object method quot;isquot; via package quot;herequot; \(perhaps you forgot to load quot;herequot;\?\) at .+incerr.htm line 6.
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+/td/tr
+tr bgcolor='#ee'td
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+^\[\d+\]ERR: 32: Warning in Perl code: Unquoted string quot;tablequot; may clash with future reserved word at .+incerr.htm line 6.
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+/td/tr
+tr bgcolor='#ee'td
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+^\[\d+\]ERR: 32: Warning in Perl code: Unquoted string quot;tdquot; may clash with future reserved word at .+incerr.htm line 8.
+!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
+/td/tr
+tr
Bug#755094: transition: harfbuzz
On Mon, Jul 28, 2014 at 10:20:14PM +0200, Emilio Pozuelo Monfort wrote: That function is trivial. I'm wondering if we couldn't reintroduce in a patch and avoid the package rename. Then 0.9.32 can go to unstable/testing right away. The next time upstream breaks the ABI (probably during jessie+1) we can remove the patch and thus the symbol. The reason why I'm thinking about avoiding the transition is that it won't be smooth, i.e. harfbuzz and all the rdeps need to transition *together*. So one FTBFS problem on any architecture will block the whole transition. And the affected packages include libreoffice, qtbase-opensource-src, chromium-browser, webkitgtk... which are huge. And e.g. chromium-browser has a FTBFS bug, which would block the transition. There may be others. If the transition was smooth (because there weren't conflicts on the old package) it would be ok. But this late on the cycle, with a few big transition coming up (one of them being librevenge/libreoffice) I wonder if we shouldn't revert the ABI break instead. Thoughts? ---end quoted text--- According to upstream changelog: Rename HB_VERSION_CHECK and hb_version_check to atleast HB_VERSION_CHECK's comparison was originally written wrongly by mistake. When API tests were written, they were also written wrongly to pass given the wrong implementation... Sigh. Given the purpose of this API, there's no point in fixing it without renaming it. As such, rename. API changes: HB_VERSION_CHECK - HB_VERSION_ATLEAST hb_version_check - hb_version_atleast My question, should I add HB_VERSION_CHECK as it was before 0.9.30 ? Or should I add it as an alias for HB_VERSION_ATLEAST ? -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Bug#755935: openslp-dfsg: Add multi-arch support
On Thu, 2014-07-24 at 19:09:23 +0200, Guillem Jover wrote: Source: openslp-dfsg Source-Version: 1.2.1-9 Severity: wishlist Due to the openal dependency on roaraudio, which depends on libslp1, this package needs to be multi-archified to be let the others be co-installable. I'm in the process of preparing fixed packages, just filing a bug report to let other people know. I uploaded this yesterday, but it seems to be stuck in the newly switched UploadQueue in coccia (from ravel). Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604093: Bug #604093: python-debian: iter_paragraphs: be more robust against RFC822 comments in unicoded files -- swallows the trailer
Hi Yaroslav, The only place where comments are defined in deb822 files that I can find is in policy §5.1 and they are only defined for debian/control files and comments are started by a # at the start of the line. if I get it right, I either saw (or found somewhere) a confirmation that deb822 is based on (not just inspired by) rfc822, and that is why I was expecting comments as defined in rfc822 be respected: https://www.ietf.org/rfc/rfc0822.txt 2.8. ; COMMENTS A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications. but if deb822 is not derived from rfc822, I guess my report was a moot ;) I can see where you're coming from here. Our definition of the format is Policy §5.1, which doesn't actually mention RFC822, defines some things that are not in that RFC and doesn't include other things that are. I suspect that our common description of this format as being pseudo-rfc822 is a (clumsy) shorthand that at times leads us astray. So, I think your bug report exposed some useful inconsistencies in deb822's handling of filehandles vs other generators and I think we're getting close to solving them. Adding handling to the parser for ;-comments, however, I think we should skip. cheers Stuart (thanks to juliank and others in #d-devel for confirming my suspicions) -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746394: Please consider shipping pre-built images in Debian packages
Hi. Charles Plessy ple...@debian.org writes: One reason why bootstrap-vz exists is that broader frameworks such as Debian-Installer have more constraints and are harder to learn and maintain. In particular, Debian-Installer does not run as a simple command that prepares a tarball on a user's hard drive; it is a minimal Debian system that runs by itself. But I think that attempts to build larger frameworks than bootstrap-vz will end up re-inventing an installer for Debian. So for a Grand Unification I recommend to work on Debian-Installer directly. With respect to docker (in the context of #746394), I think that the providing of images should be much lighter than what the Debian installer usually does. AFAIU, docker containers are meant to be very lightweight, compared to installing on real hardware, and whereas it would be sad to reinvent the wheels the d-i is already providing, I think that much of its work is to detect hardware and configure appropriately, which is completely useless in the context of docker, since there's no hardware emulation, no real virtual machine, just a chroot-like container (LXC based), at least in the usual use of docker containers based on LXC running over Linux. So bootstrap-vz running debootstrap is probably much of what we need for a bootstrap-vz Docker provider, I guess (and the devil which is in the details). Hope this makes sense. Best regards, -- Olivier BERGER olivier.ber...@it-sudparis.eu - OpenPGP: 5819D7E8 Ingénieur Recherche - Dept INF - TMSP (http://www.it-sudparis.eu) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746394: Docker provider for bootstrap-vz Was: Re: Bug#746394: Please consider shipping pre-built images in Debian packages
Hi. Is anyone working on adding Docker provider for bootstrap-vz (i.e. building Docker.io images containing a Debian install, ready to run in a docker container) ? It seems a GSOC 2014 was proposed for this [0], but I can't find evidence that anyone is working on it. If someone is, please respond in [1] with appropriate details ;) Thanks in advance. Best regards, [0] https://wiki.debian.org/SummerOfCode2014/Projects/bootstrap-vz [1] https://github.com/andsens/bootstrap-vz/issues/128 Miguel Landaeta nomad...@debian.org writes: On Tue, Apr 29, 2014 at 09:59:49PM +0200, Jan Wagner wrote: Did you have a look into /usr/share/docker.io/contrib/mkimage-debootstrap.sh? You can generate your own image via debootstrap. And what debian-cloud team? (CCing them) I don't know if that it's outside of the tasks of the team (what do you think guys?) but it would be nice if you can provide properly maintained and signed images? I'm a member of that team (I'm almost inactive although) but maybe we can contribute with that. For example, I have a very simple image in my web page[1] generated with debootstrap and signed with my key since is the only one I trust so far to play around with docker. 1. http://people.debian.org/~nomadium/docker/images/ -- Olivier BERGER olivier.ber...@it-sudparis.eu - OpenPGP: 5819D7E8 Ingénieur Recherche - Dept INF - TMSP (http://www.it-sudparis.eu) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756394: src:qof: use dh-autoreconf to fix FTBFS on ppc64el
Package: src:qof Version: 0.8.7-1 Severity: normal Tags: patch Dear Maintainer, While trying to build qof on ppc64el, it failed, due to libtool and configuration files not being updated. Please consider this patch, which uses dh-autoreconf to fulfill that need. Thanks in advance, Erwan. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 3.13-1-powerpc64le (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Naur a/debian/control b/debian/control --- a/debian/control 2014-07-29 15:30:43.886645185 +0200 +++ b/debian/control 2014-07-29 15:31:38.038642307 +0200 @@ -4,7 +4,7 @@ Maintainer: Neil Williams codeh...@debian.org Uploaders: Goedson Teixeira Paixao goed...@debian.org Build-Depends: cdbs (= 0.4.93~), debhelper (= 9), xsltproc, - libglib2.0-dev (= 2.9.0), libxml2-dev (= 2.5.10), libsqlite0-dev + libglib2.0-dev (= 2.9.0), libxml2-dev (= 2.5.10), libsqlite0-dev, dh-autoreconf Build-Depends-Indep: doxygen Standards-Version: 3.9.4 Homepage: http://alioth.debian.org/projects/qof/ diff -Naur a/debian/rules b/debian/rules --- a/debian/rules 2014-07-29 15:30:43.898645185 +0200 +++ b/debian/rules 2014-07-29 15:31:20.846643221 +0200 @@ -19,6 +19,7 @@ include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk +include /usr/share/cdbs/1/rules/autoreconf.mk # backends do not need ldconfig (anymore) DEB_DH_MAKESHLIBS_ARGS=-Xlibqof2-backend
Bug#673027: xkbcomp bad parsing of -w option
Control: tags -1 patch
On 2012-05-15 15:14:17 +0100, Zefram wrote:
xkbcomp's warning-level option only works if the numeric argument comes
in a separate command-line argument from the -w. E.g., xkbcomp -w 3
t0.xkb and xkbcomp -w 4 t0.xkb work, and produce different degrees
of verbosity. But xkbcomp -w3 t0.xkb and xkbcomp -w4 t0.xkb both
produce no warnings, as far as I can see.
The current code is:
else if (strncmp(argv[i], -w, 2) == 0)
{
if ((i = (argc - 1)) || (!isdigit(argv[i + 1][0])))
{
warningLevel = 0;
if (isdigit(argv[i][1]))
if (sscanf(argv[i][1], %i, itmp) == 1)
warningLevel = itmp;
}
else
{
if (sscanf(argv[++i], %i, itmp) == 1)
warningLevel = itmp;
}
}
There are several bugs:
* It looks at the next argument before detecting whether -w already
has a number attached to it, which yields an error when one uses
-wnumber and the input file starts with a digit.
* In both occurrences of argv[i][1], 1 should be replaced by 2.
* Options like -wfoo are regarded in the same way as -w.
I've attached a patch that fixes these errors, but doesn't check
everything (garbage after the number is ignored). Anyway, that's
much better than the current code.
--
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--- xkbcomp/xkbcomp.c~ 2013-12-25 13:01:29.0 +0100
+++ xkbcomp/xkbcomp.c 2014-07-29 15:31:07.233676040 +0200
@@ -579,17 +579,19 @@
}
else if (strncmp(argv[i], -w, 2) == 0)
{
-if ((i = (argc - 1)) || (!isdigit(argv[i + 1][0])))
+if (argv[i][2] == 0)
{
-warningLevel = 0;
-if (isdigit(argv[i][1]))
-if (sscanf(argv[i][1], %i, itmp) == 1)
-warningLevel = itmp;
+if (++i argc sscanf(argv[i], %i, itmp) == 1)
+warningLevel = itmp;
+else
+warningLevel = 0;
}
else
{
-if (sscanf(argv[++i], %i, itmp) == 1)
+if (sscanf(argv[i][2], %i, itmp) == 1)
warningLevel = itmp;
+else
+goto unknown_flag;
}
}
else if ((strcmp(argv[i], -xkb) == 0) (!xkblist))
@@ -622,6 +624,7 @@
}
else
{
+ unknown_flag:
ERROR1(Unknown flag \%s\ on command line\n, argv[i]);
Usage(argc, argv);
return False;
