Bug#737259: util-linux block linux update
Package: util-linux Version: 2.20.1-5.5 Severity: important Dear Maintainer, * What led up to the situation? After apt-get update and apt-get dist-upgrade I got this situation Debian E: util-linux: il sottoprocesso installato script di post-installation ha restituito lo stato di errore 1 PLEASE WRITE ME IF YOU NEED MORE INFORMATION Thanks Marco Righi -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages util-linux depends on: ii debconf [debconf-2.0] 1.5.52 ii dpkg 1.17.6 ii initscripts2.88dsf-45 ii install-info 5.2.0.dfsg.1-2 ii libblkid1 2.20.1-5.5 ii libc6 2.17-97 ii libncurses55.9+20140118-1 ii libselinux12.2.2-1 ii libslang2 2.2.4-16 ii libtinfo5 5.9+20140118-1 ii libuuid1 2.20.1-5.5 ii lsb-base 4.1+Debian12 ii tzdata 2013i-1 ii zlib1g 1:1.2.8.dfsg-1 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 3.0.16-2 ii kbd 1.15.5-1 pn util-linux-locales none -- debconf information: util-linux/noauto-with-nonzero-passnum: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736812: open-vm-tools: drag-and-drop doesnt block and files are transfered incomplete
Hello, After some research and alot more trial and error, I found that there are multiple Issues: 1. the vmblock filesystem is never started 2. the file /usr/bin/vmware-user-suid-wrapper is missing the apparently critical suid bit (I never knew about this bit before) 3. the vmtoolsd instances spawned by vmware-user-suid-wrapper dont handle SIGUSR1 and SIGUSR2 as they should. Maybe its good to exlpain that there are multiple vmtoolsd instances, one is the system daemon start/stopped by init. the others are started via X11/Gnome autostart - vmware-user-suid-wrapper creates a file-descriptor for the vmblock device (with elevated rights), then starts a vmtoolsd user instance which uses this descriptor. So there is the system daemon and any number of user daemons. For Point 1 I attached a fixed etc/init.d/open-vm-tools. It has some things commented out because of Point 3. Point 2 is easily fixed with chmod 04555 /usr/bin/vmware-user-suid-wrapper. Point 3 is likely for upstream? The issue here is that you cant stop/start the vmblock filesystem as long as anyone is using it. Supposedly you would send a signal to the user daemons, telling them to give up any references to it - but its not handled and instead the user daemon terminates. As it its now Drag and Drop works, but stopping the system daemon will fail as vmblock cant be stopped. And another bug would be that the vmxnet driver is not picked up automatically, for this to work you would need to add the module to the initital ramdisk. Along with other m0dules which should have the same problem, but I cant verify it: vmxnet3 vmw_pvscsi vmxnet open-vm-tools Description: Binary data
Bug#737093: thermald: daemon eats 100 percent CPU time
No bug with a locally recompiled package. # aptitude purge thermald # aptitude install thermald # 1.1~rc2-4 ... thermald process uses 100% cpu # aptitude purge thermald # apt-get source thermald # 1.1~rc2-4 # pdebuild # dpkg -i $localpackage ... no bug # debdiff $officialpackage $localpackage File lists identical (after any substitutions) No differences were encountered between the control files Just in case, a debug log *without* the bug is attached. I produced it by recompiling the package with DEB_BUILD_OPTIONS=noopt pdebuild and modifying the start command in the init script. # start-stop-daemon --start --quiet --oknodo \ --background --no-close \ --exec /usr/sbin/thermald -- \ --no-daemon --loglevel=debug /tmp/debug.log 21 Any idea to produce debug output right after installation of the official package? 10 CPUID levels; family:model:stepping 0x6:17:6 (6:23:6) No support RAPL and Intel P state driver Polling mode is enabled: 4 thd_read_default_thermal_sensors sensor_update: type acpitz thd_read_default_thermal_sensors loaded 1 sensors Dumping parsed XML Data *** Index 0 *** Name: Generic X86 Laptop Device UUID: type: 0 Sensor 0 Name: TSKN Path: Async Capable: 1 Zone 0 Name: SKIN Trip Point 0 temp id 44000 trip type 2 hyst id 0 Trip id 0 type rapl_controller influence 100 SamplingPeriod 16 Trip id 1 type intel_powerclamp influence 100 SamplingPeriod 12 *** Index 1 *** Name: Example Platform Name UUID: Example UUID type: 0 Sensor 0 Name: TSKN Path: Async Capable: 1 Sensor 1 Name: example_sensor_1 Path: /some_path Async Capable: 0 Sensor 2 Name: example_thermal_sysfs_sensor Path: Async Capable: 1 Zone 0 Name: Example Zone type Trip Point 0 temp id 75000 trip type 1 hyst id 0 Trip id 0 type example_cooling_device influence 100 SamplingPeriod 12 Cooling Dev 0 Type: example_cooling_device Path: Min: 0 Max: 50 Step: 10 AutoDownControl: 0 PID: Kp 0,00 PID: Ki 0,00 PID: Kd 0,00 checking UUID UUID is [947B9900-C08E-11DD-8021-B059A8017255] checking product name product name is[TECRA R10] config product name * Product Name matched [wildcard] sensor id 3: No temp sysfs for reading raw temp sensor index:0 acpitz Async:0 sensor index:1 temp2_input Async:0 sensor index:2 temp3_input Async:0 thd_read_default_cooling devices cooling dev 0:0:3:Processor cooling dev 1:0:3:Processor cooling dev 2:7:7:LCD thd_read_default_cooling devices loaded 3 cdevs powercap RAPL no long term time window checking UUID UUID is [947B9900-C08E-11DD-8021-B059A8017255] checking product name product name is[TECRA R10] config product name * Product Name matched [wildcard] pstate CPU present 0-1 cpu freq max 2261000 min 80 cpu freq Add 0: 2261000 cpu freq Add 1: 226 cpu freq Add 2: 160 cpu freq Add 3: 80 cpu freq 0: 2261000 cpu freq 1: 226 cpu freq 2: 160 cpu freq 3: 80 0: Processor, C:0 MN: 0 MX:3 ST:1 pt:/sys/class/thermal/ rd_bk 1 1: Processor, C:0 MN: 0 MX:3 ST:1 pt:/sys/class/thermal/ rd_bk 1 2: LCD, C:7 MN: 0 MX:7 ST:1 pt:/sys/class/thermal/ rd_bk 1 3: cpufreq, C:0 MN: 0 MX:0 ST:1 pt:/sys/devices/system/cpu/ rd_bk 1 thd_read_default_thermal_zones Added zone index:0 Thermal Zone look for 0/type Thermal Zone 0:acpitz read_trip_points 0/trip_point_0_type:critical read_trip_points 0/trip_point_0_temp:107000 Add trip pt 0:0:0x0:107000:1 read_trip_points Added 1 trips trip type: 0 temp: 107000 read_cdev_trip_points for cthd_sysfs_zone::read_cdev_trip_points: ZONE bound to CDEV status 0 thd_read_default_thermal_zones loaded 1 zones checking UUID UUID is [947B9900-C08E-11DD-8021-B059A8017255] checking product name product name is[TECRA R10] config product name * Product Name matched [wildcard] Added zone index:1 XML zone: invalid sensor type Zone update failed: unable to bind zone cpu will be created Added zone index:1 zone dts syfs: /sys/devices/platform/coretemp.0/, package id 0 Core temp DTS :critical 105000, max 105000 Buggy max temp: to close to critical 95000 Read set point 0 node type: Element, name: CoolingDevice value: rapl_controller node type: Element, name: CoolingDevice value: intel_pstate node type: Element, name: CoolingDevice value: intel_powerclamp node type: Element, name: CoolingDevice value:
Bug#729289: transition: openscenegraph
[trimmed Cc:] On Friday, 31. January 2014 21:44:44 Sebastiaan Couwenberg wrote: The updated libcitygml package is not uploaded yet, but I intent to ask for sponshorship at the end of the weekend if YunQiang Su hasn't replied My NMU got uploaded yesterday and is built successfully. @release team: can you reactivate the tracker? Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737251: pu: package localepurge/0.6.2+nmu1+squeeze1
On 2014-01-31 22:21, Adam D. Barratt wrote: Control: tags -1 + confirmed On Fri, 2014-01-31 at 20:45 +0100, Niels Thykier wrote: I would like to fix #736359 / CVE-2014-1638 in Squeeze. According to the security tracker, the security team has classified the bug as minor and declared it does not need a DSA[1]. The problem is that localepurge would create tmp files in an unsafe way. This allows a local user to have root destroy arbitrary files on the system (via a race-condition) during upgrades and purge of localepurge. Please go ahead; thanks. Regards, Adam Uploaded, thanks. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657116: libtar: FTBFS on hurd-i386
Hi.
This libtar build failure on hurd block vlc and a few other packages
from building on Debian/Hurd. Any chance to get a added to the Debian
package while we wait for upstream to fix it?
I've attached an updated patch solving some of the issues upstream
commented on in the last patch. I have not had time to update all of
it yet, but thought it best to check if it would get accepted into
Debian even if upstream refuse to include it.
--
Happy hacking
Petter Reinholdtsen
diff --git a/compat/basename.c b/compat/basename.c
index 2ac1e13..1ec6f51 100644
--- a/compat/basename.c
+++ b/compat/basename.c
@@ -34,17 +34,29 @@ static char rcsid[] = $OpenBSD: basename.c,v 1.4
1999/05/30 17:10:30 espie Exp
#include errno.h
#include string.h
#include sys/param.h
+#include stdlib.h
char *
openbsd_basename(path)
const char *path;
{
- static char bname[MAXPATHLEN];
+ static char *bname = NULL;
+ static size_t allocated = 0;
register const char *endp, *startp;
+ int len = 0;
+
+ if (!allocated) {
+ allocated = 64;
+ bname = malloc(allocated);
+ if (!bname) {
+ allocated = 0;
+ return NULL;
+ }
+ }
/* Empty or NULL string gets treated as . */
if (path == NULL || *path == '\0') {
- (void)strcpy(bname, .);
+ strcpy(bname, .);
return(bname);
}
@@ -53,7 +65,7 @@ openbsd_basename(path)
while (endp path *endp == '/')
endp--;
- /* All slashes becomes / */
+ /* The base of / is / */
if (endp == path *endp == '/') {
(void)strcpy(bname, /);
return(bname);
@@ -64,11 +76,19 @@ openbsd_basename(path)
while (startp path *(startp - 1) != '/')
startp--;
- if (endp - startp + 1 sizeof(bname)) {
- errno = ENAMETOOLONG;
- return(NULL);
+ len = endp - startp + 1;
+
+ if (len + 1 allocated) {
+ size_t new_allocated = 2*(len+1);
+ void *new_bname = malloc(new_allocated);
+ if (!new_bname)
+ return NULL;
+ allocated = new_allocated;
+ free(bname);
+ bname = new_bname;
}
- (void)strncpy(bname, startp, endp - startp + 1);
- bname[endp - startp + 1] = '\0';
+
+ (void)strncpy(bname, startp, len);
+ bname[len] = '\0';
return(bname);
}
diff --git a/compat/dirname.c b/compat/dirname.c
index 986db4a..407ad47 100644
--- a/compat/dirname.c
+++ b/compat/dirname.c
@@ -34,17 +34,29 @@ static char rcsid[] = $OpenBSD: dirname.c,v 1.4 1999/05/30
17:10:30 espie Exp $
#include errno.h
#include string.h
#include sys/param.h
+#include stdlib.h
char *
openbsd_dirname(path)
const char *path;
{
- static char bname[MAXPATHLEN];
+ static char *bname = NULL;
+ static size_t allocated = 0;
register const char *endp;
+ int len;
+
+ if (!allocated) {
+ allocated = 64;
+ bname = malloc(allocated);
+ if (!bname) {
+ allocated = 0;
+ return NULL;
+ }
+ }
/* Empty or NULL string gets treated as . */
if (path == NULL || *path == '\0') {
- (void)strcpy(bname, .);
+ strcpy(bname, .);
return(bname);
}
@@ -67,11 +79,18 @@ openbsd_dirname(path)
} while (endp path *endp == '/');
}
- if (endp - path + 1 sizeof(bname)) {
- errno = ENAMETOOLONG;
- return(NULL);
+ len = endp - path + 1;
+ if (len + 1 allocated) {
+ size_t new_allocated = 2*(len+1);
+ void *new_bname = malloc(new_allocated);
+ if (!new_bname)
+ return NULL;
+ allocated = new_allocated;
+ free(bname);
+ bname = new_bname;
}
- (void)strncpy(bname, path, endp - path + 1);
- bname[endp - path + 1] = '\0';
+
+ (void)strncpy(bname, path, len);
+ bname[len] = '\0';
return(bname);
}
diff --git a/lib/append.c b/lib/append.c
index 32622f3..4d857ae 100644
--- a/lib/append.c
+++ b/lib/append.c
@@ -40,7 +40,7 @@ typedef struct tar_dev tar_dev_t;
struct tar_ino
{
ino_t ti_ino;
- char ti_name[MAXPATHLEN];
+ char ti_name[];
};
typedef struct tar_ino tar_ino_t;
@@ -63,7 +63,7 @@ tar_append_file(TAR *t, const char *realname, const char
*savename)
libtar_hashptr_t hp;
tar_dev_t *td = NULL;
tar_ino_t *ti = NULL;
- char path[MAXPATHLEN];
+ char *path = NULL;
#ifdef DEBUG
printf(== tar_append_file(TAR=0x%lx (\%s\), realname=\%s\,
@@ -128,34 +128,39 @@ tar_append_file(TAR *t, const char
Bug#736812: Re
And here is a fixed version of the file. open-vm-tools Description: Binary data
Bug#736203: [lintian] pending
Package: lintian Version: 2.5.21 control: tags -1 + pending -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736203: More info
According to https://github.com/supermihi/pytaglib/issues/5 Probably they just looked at the tags which I'd agree look a little suspicious (COMMENT=ripped by [...]). But you are right, it might be best to simply follow their wish. I hope I'll find some time later to take care about the issue. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737260: [prosody] New upstream release
Package: prosody Severity: normal Dear maintainer, A new upstream release of Prosody has been out recently that has a much better security default approach in what respects to ciphers from both client and server side. In what respects to instant messaging software, this changes are of extreme relevance since this piece of software is intended to provide the best security over communications possible, that's why I'm leaving the severity as normal instead of wishlist. Please consider uploading it. Thanks in advance. Dererk -- BOFH excuse #143: had to use hammer to free stuck disk drive heads. signature.asc Description: OpenPGP digital signature
Bug#736711: [lintian] pending
Package: lintian Version: 2.5.21 control: tag -1 + pending -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735040: [lintian] moreinfo on confusing tag name: debian-watch-may-check-gpg-signature
Package: lintian Version: 2.5.21 control: tags -1 + moreinfo Do you have a better naming idea ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736797: pu: package debian-handbook/7.20140126~deb7u1
Control: tags -1 + pending On Thu, 2014-01-30 at 22:20 +0100, Raphael Hertzog wrote: On Thu, 30 Jan 2014, Adam D. Barratt wrote: On Sun, 2014-01-26 at 22:00 +0100, Raphael Hertzog wrote: I would like to update the debian-handbook in Wheezy so that it actually documents Wheezy and not Squeeze. We finished the update in late december. Please go ahead; thanks. Thanks, uploaded debian-handbook_7.20140126~deb7u1_amd64.changes. Flagged for acceptance; thanks. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732358: pu: package lxc/0.8.0~rc1-8+deb7u2
On Thu, 2014-01-30 at 22:01 +0100, Raphael Hertzog wrote: On Thu, 30 Jan 2014, Adam D. Barratt wrote: It's a one-liner that fix issues with containers running with glibc = 2.18. Would this be acceptable as well ? It appears this issue isn't fixed in unstable yet; is that correct? Looks like so, the fix seems to be only in 0.9.0-18 which had been uploaded to experimental. I really wish lxc had a better maintainer... That said this precise fix has made its way upstream: https://github.com/lxc/lxc/commit/67e5a20ad1b5579a571f43f7dd8a1556a8bea7a1 So it should be safe to apply IMO. I've been arguing with myself a little, but on balance I'd prefer to stick with the template change for now. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737239: pu: package localepurge/0.6.3+deb7u1
Control: tags -1 + pending On Fri, 2014-01-31 at 19:36 +0100, Niels Thykier wrote: On 2014-01-31 19:28, Adam D. Barratt wrote: On Fri, 2014-01-31 at 19:01 +0100, Niels Thykier wrote: I would like to fix #736359 / CVE-2014-1638 in Wheezy and Squeeze[0]. According to the security tracker, the security team has classified the bug as minor and declared it does not need a DSA[1]. The problem is that localepurge would create tmp files in an unsafe way. This allows a local user to have root destroy arbitrary files on the system (via a race-condition) during upgrades and purge of localepurge. Please go ahead; thanks. (Bearing in mind the impending window close for 7.4 this weekend.) [...] Thank you, I have dput'ed the package to FTP. Flagged for acceptance; thanks. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736757: pu: package ruby-opengl/0.60.1+dfsg2-1~wheezy1
Control: tags -1 + pending On Thu, 2014-01-30 at 20:17 +, Adam D. Barratt wrote: On Sun, 2014-01-26 at 16:02 +0100, Cédric Boutillier wrote: I would like to propose an update of ruby-opengl for wheezy to remove documentation without clear license. Please go ahead; thanks. Flagged for acceptance. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736676: pu: package ruby-gsl/1.14.7+dfsg-1
Control: tags -1 + pending On Thu, 2014-01-30 at 20:23 +, Adam D. Barratt wrote: On Sun, 2014-01-26 at 01:10 +0100, Cédric Boutillier wrote: I am proposing an update of ruby-gsl for Wheezy in order to get rid of non-free documentation present in the rdoc/ directory. The modification is mainly a backport of the changed pushed to unstable to solve the same issue. [Note that the initial bug report did not reach debian-release@ldo, most likely due to the size of the debdiff.] Please go ahead; thanks. Flagged for acceptance. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737261: ITP: nghttp2 -- HTTP/2 library
Package: wnpp Severity: wishlist Owner: Dave Beckett daj...@debian.org Package name: nghttp2 Version : 0.2.0 Upstream Author : Tatsuhiro Tsujikawa t-tujik...@users.sourceforge.net URL : http://tatsuhiro-t.github.io/nghttp2/ License : MIT/X Programming Lang: C Description : HTTP/2 library A library that provides an experimental implementation of Hypertext Transfer Protocol version 2.0 including a server (nghttpd), client (nghttp) and reverse proxy (nghttpx) for fronting other HTTP servers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728186: (no subject)
Hi, I don't have this problem on debian 7 stable Max -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
On 01/31/2014 10:57 PM, Andreas Beckmann wrote: On Friday, 31. January 2014 21:44:44 Sebastiaan Couwenberg wrote: The updated libcitygml package is not uploaded yet, but I intent to ask for sponshorship at the end of the weekend if YunQiang Su hasn't replied My NMU got uploaded yesterday and is built successfully. Thanks, that's good to know. I've merged your changes into the packaging in the Debian GIS git repository. A rebuild of the package with my additional changes is running as we speak. Kind Regards, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737262: systemd: Possible memory leak in systemd-journald
Package: systemd Version: 44-11+deb7u4 Severity: normal Hi, I think there is a small memory leak in wheezy's systemd-journald. I have two systems that are almost exactly the same. They run the same software (Postfix, Amavis, ...), have the same configuration (managed by Puppet) and have almost the same load (two same-priority MXes for the same domains) . One of them is running sysvinit, one is running systemd. The system running systemd slowly but surely leaks memory. I will attach the check_mk graphs after the bug confirmation. The leak isn't big, but it definitely is there. Unfortunately the server was booted the last time it happened, since it was heavily swapping. I do rember however that systemd-journal process was big, more than 1GB VIRT and more than 300MB RSS. It is a lot smaller after reboot, as you probably know :-) I ran the following script (while true; do date | tr -d '\n'; echo -n; sudo pmap -d $(pidof systemd-journald) | grep mapped; sleep 10; done) to map the process memory. You can see that writable/private increases in chunks of 132K, and it's obviously not at the same time the journal is rotated. The system generates around 130MB syslog per day, which is much more than the typical desktop. I haven't observed any memory leak there. I also haven't observed the problem on Jessie. Any idea how to debug this situation? Bernhard -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii dpkg 1.16.12 ii initscripts 2.88dsf-41+deb7u1 ii libacl1 2.2.51-8 ii libaudit01:1.7.18-1.1 ii libc62.13-38 ii libcap2 1:2.22-1.2 ii libcryptsetup4 2:1.4.3-4 ii libdbus-1-3 1.6.8-1+deb7u1 ii libkmod2 9-3 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.3-7.1 ii libselinux1 2.1.9-5 ii libsystemd-daemon0 44-11+deb7u4 ii libsystemd-id128-0 44-11+deb7u4 ii libsystemd-journal0 44-11+deb7u4 ii libsystemd-login044-11+deb7u4 ii libudev0 175-7.2 ii libwrap0 7.6.q-24 ii udev 175-7.2 ii util-linux 2.20.1-5.3 Versions of packages systemd recommends: ii libpam-systemd 44-11+deb7u4 Versions of packages systemd suggests: ii python2.7.3-4+deb7u1 pn python-cairo none pn python-dbus none pn systemd-gui none -- no debconf information Fr 31. Jan 22:49:48 CET 2014 mapped: 105704Kwriteable/private: 68016K shared: K Fr 31. Jan 22:49:58 CET 2014 mapped: 105768Kwriteable/private: 68016K shared: 4508K Fr 31. Jan 22:50:08 CET 2014 mapped: 106152Kwriteable/private: 68016K shared: 4892K Fr 31. Jan 22:50:18 CET 2014 mapped: 106552Kwriteable/private: 68016K shared: 5292K Fr 31. Jan 22:50:28 CET 2014 mapped: 106744Kwriteable/private: 68016K shared: 5484K Fr 31. Jan 22:50:38 CET 2014 mapped: 106824Kwriteable/private: 68016K shared: 5564K Fr 31. Jan 22:50:48 CET 2014 mapped: 106984Kwriteable/private: 68016K shared: 5724K Fr 31. Jan 22:50:58 CET 2014 mapped: 107064Kwriteable/private: 68016K shared: 5804K Fr 31. Jan 22:51:08 CET 2014 mapped: 107340Kwriteable/private: 68148K shared: 5948K Fr 31. Jan 22:51:18 CET 2014 mapped: 107484Kwriteable/private: 68148K shared: 6092K Fr 31. Jan 22:51:28 CET 2014 mapped: 107516Kwriteable/private: 68148K shared: 6124K Fr 31. Jan 22:51:38 CET 2014 mapped: 107628Kwriteable/private: 68148K shared: 6236K Fr 31. Jan 22:51:48 CET 2014 mapped: 107804Kwriteable/private: 68148K shared: 6412K Fr 31. Jan 22:51:58 CET 2014 mapped: 107916Kwriteable/private: 68148K shared: 6524K Fr 31. Jan 22:52:08 CET 2014 mapped: 108060Kwriteable/private: 68148K shared: 6668K Fr 31. Jan 22:52:18 CET 2014 mapped: 108124Kwriteable/private: 68148K shared: 6732K Fr 31. Jan 22:52:28 CET 2014 mapped: 108204Kwriteable/private: 68148K shared: 6812K Fr 31. Jan 22:52:38 CET 2014 mapped: 108388Kwriteable/private: 68148K shared: 6996K Fr 31. Jan 22:52:48 CET 2014 mapped: 108556Kwriteable/private: 68148K shared: 7164K Fr 31. Jan 22:52:58 CET 2014 mapped: 108700Kwriteable/private: 68148K shared: 7308K Fr 31. Jan 22:53:08 CET 2014 mapped: 108748Kwriteable/private: 68148K shared: 7356K Fr 31. Jan 22:53:18 CET 2014 mapped: 108796Kwriteable/private: 68148K shared: 7404K Fr 31. Jan 22:53:28 CET 2014 mapped: 109020Kwriteable/private: 68148K shared: 7628K Fr 31. Jan 22:53:38 CET 2014 mapped: 109100Kwriteable/private: 68148K shared: 7708K Fr 31. Jan 22:53:48 CET 2014 mapped:
Bug#614761: Ping
Solveig wrote: Hi! Do you still encounter this bug with latest versions? If yes, please provide up-to-date data, and if not, this bug report might be closed, so let us know :) I haven't seen this in some time. It can be closed. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737263: RFS: libcitygml/0.14+svn134-1+3p2p0
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package libcitygml Package name: libcitygml Version : 0.14+svn134-1+3p2p0 Upstream Author : Joachim Pouderoux jpouder...@gmail.com URL : http://code.google.com/p/libcitygml/ License : LGPL-2.1+ Section : libs It builds those binary packages: libcitygml0 - Open source C++ library for parsing CityGML files libcitygml0-bin - Utils of libcitygml - citygml2vrml and citygmltest libcitygml0-dev - Static and header files of libcitygml openscenegraph-plugin-citygml-shared - libcitygml OpenSceneGraph plugin (shared version) openscenegraph-plugin-citygml-static - libcitygml OpenSceneGraph plugin (static version) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libcitygml Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libc/libcitygml/libcitygml_0.14+svn134-1+3p2p0.dsc More information about libcitygml can be obtained from http://code.google.com/p/libcitygml/. Changes since the last upload: * Team upload. * Make Debian GIS Project Maintainer and YunQiang Su Uploader. * Drop obsolete DM-Upload-Allowed, permissions are granted in dak. * Use canonical URLs for Vcs-* fields. * Use copyright-format 1.0 instead of dep5 URL. * Fix libopenscenegraph version detection. * Fix 'information' typo in manpage, add patch to fix the typo in the code. * Update watch file for Subversion revisions. * Update to latest upstream Subversion revision. * Add symbols file using pkgkde-symbolshelper. * Bump Standards-Version to 3.9.5, changes: DM-Upload-Allowed, Vcs-* fields, copyright format, symbols file. Regards, Sebastiaan Couwenberg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737264: /usr/share/man/man7/systemd.directives.7.gz: systemd.directives(7) is empty
Package: systemd Version: 204-6 Severity: minor File: /usr/share/man/man7/systemd.directives.7.gz -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The contents of systemd.directives(7) are missing. AFAIR they were present in version 204-5. - -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (540, 'testing'), (530, 'unstable'), (520, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-1 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-45 ii libacl1 2.2.52-1 ii libaudit11:2.3.3-3 ii libc62.17-97 ii libcap2 1:2.22-1.2 ii libcryptsetup4 2:1.6.1-1 ii libdbus-1-3 1.7.10-2 ii libgcrypt11 1.5.3-3 ii libkmod2 16-2 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.3-9 ii libselinux1 2.2.2-1 ii libsystemd-daemon0 204-6 ii libsystemd-journal0 204-6 ii libsystemd-login0204-6 ii libudev1 204-6 ii libwrap0 7.6.q-25 ii udev 204-6 ii util-linux 2.20.1-5.5 Versions of packages systemd recommends: ii libpam-systemd 204-6 Versions of packages systemd suggests: ii systemd-ui 2-2 - -- Configuration Files: /etc/systemd/system.conf changed [not included] - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlLsJ3kACgkQshl/216gEHhLuwCgtgCtVhm55fXrIc3rGY4/tl5D hWEAnRGWusRZ4BFbFumYUsMhpqyObcM6 =KuOX -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#737265: libdatetime-timezone-perl: DateTime::TimeZone::Local malfunctions under taint mode (perl -T)
Package: libdatetime-timezone-perl
Version: 1.63-1+2013h
Severity: normal
Tags: upstream patch
Dear Maintainer,
Bugzilla versions 4.2 and 4.4 both malfunction under the latest Perl (5.18.2-2)
and libdatetime-timezone-perl (1.63-1+2013h) with the message Cannot determine
local time zone.
This occurs because Bugzilla runs under Taint Mode, where values from
untrusted sources are marked as 'tainted'; certain risky operations (eval,
exec/system, open file for writing) will fail when their arguments are tainted.
This includes the mechanism used by the constructor for DateTime::TimeZone.
When DateTime::TimeZone::Local::Unix loads the time zone name from
/etc/timezone, the zone name is tainted; then, when the name is passed to
DateTime::TimeZone-new, it fails.
DateTime::TimeZone-new already securely validates the zone name before using
it. Attached is a patch (created using quilt) that modifies that validation
code such that it also untaints the zone name at the same time. It also adds a
new test to the test suite to verify correct operation.
An equivalent patch has been submitted directly to the author of
DateTime::TimeZone.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/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
--- /dev/null
+++ b/t/22taintmode.t
@@ -0,0 +1,9 @@
+#!perl -wT
+use strict;
+use warnings;
+use Test::More 0.88;
+
+use_ok('DateTime::TimeZone::Local');
+ok( ref DateTime::TimeZone::Local-TimeZone );
+
+done_testing();
--- a/lib/DateTime/TimeZone.pm
+++ b/lib/DateTime/TimeZone.pm
@@ -70,7 +70,7 @@
my $real_class = DateTime::TimeZone::$subclass;
die The timezone '$p{name}' in an invalid name.\n
-unless $real_class =~ /^\w+(::\w+)*$/;
+unless ($real_class) = ($real_class =~ /^(\w+(?:::\w+)*)$/);
unless ( $real_class-can('instance') ) {
my $e = do {
Bug#737217: nvidia-detect: incorrect detection for 304xx and current nvidia devices when using wheezy-backports nvidia-detect
On Friday 31 January 2014 22:46:47 Andreas Beckmann wrote: What brought this up is I've created a script to install the nvidia driver, and it uses nvidia-detect to select the correct nvidia driver package. Glad to see someone is using nvidia-detect for some autodetection work, maybe you can share your scripts for others to benefit from. Debian Live also does some detection, albeit not just for nvidia. Would be great if we all could share/integrate things so we'd all benefit and avoid duplication of work. http://live.debian.net/gitweb/?p=live-config.git;a=blob;f=components/1140-xserver-xorg Diederik -- GPG: 0x138E41915C7EFED6 signature.asc Description: This is a digitally signed message part.
Bug#726230: Mozilla Location Service
Changing /geo.wifi.uri/ to /https://location.services.mozilla.com/v1/geolocate/ seems to work fine. The only problem is that coverage is not really good for now. Regards,
Bug#737266: uim-mozc: libuim-mozc.so cannot load. Causes Segmentation fault.
Package: uim-mozc Version: 1.13.1651.102-1+b1 Severity: important Dear Maintainer, When I try to update uim-mozc package, I've got this error message. libuim: [fatal] dynlib: /usr/lib/x86_64-linux-gnu/uim/plugin/libuim-mozc.so: undefined symbol: _ZN6google8protobuf18GoogleOnceInitImplEPlPNS0_7ClosureE: Load failed. Segmentation fault -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-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 uim-mozc depends on: ii libc6 2.17-97 ii libprotobuf8 2.5.0-7 ii libstdc++64.8.2-14 ii libuim-scm0 1:1.8.6-4 ii libuim8 1:1.8.6-4 ii mozc-data 1.13.1651.102-1 ii mozc-server 1.13.1651.102-1+b1 ii uim-utils 1:1.8.6-4 Versions of packages uim-mozc recommends: ii mozc-utils-gui 1.13.1651.102-1+b1 uim-mozc 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#736964: ive not be able to reproduced it
This bug hit me, but after upgrade to 1.8.6-1 it did not happened again I guess is fixed? : -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735873:
I just installed zathura from testing, and I'm also affected by this issue. Previous version (from stable) worked fine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
The updated libcitygml package is not uploaded yet, It was NMUd about a week ago, fixing the FTBFS bug, but I don't know if all your planned changes were included. (By OK I meant OK for transition, ie built against latest openscenegraph and no RC bugs.) Making unrelated changes to OK-for-transition packages during a transition is normally discouraged due to the risk of accidentally breaking them, but I think that's only a problem if they are currently in testing, which these aren't; can anyone confirm? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516718: Freshly installed ejabberd fails to start
Package: ejabberd Version: 2.1.10-4+deb7u1 Followup-For: Bug #516718 Dear Maintainer, I have experienced this or a related problem today when installing ejabberd. At the setup stage, the following is shown: Setting up ejabberd (2.1.10-4+deb7u1) ... adduser: Warning: The home directory `/var/lib/ejabberd' does not belong to the user you are currently creating. Generating SSL certificate /etc/ejabberd/ejabberd.pem... Creating config file /etc/ejabberd/ejabberd.cfg with new version Starting jabber server: ejabberdFailed to set thread main status: Invalid argument (22) Aborted The latter message is repeated over and over, with only Ctrl-Z usable to stop the process (for subsequent manual termination). Running dpkg --configure -a just repeats the same problem: Setting up ejabberd (2.1.10-4+deb7u1) ... Starting jabber server: ejabberdFailed to set thread main status: Invalid argument (22) Aborted Failed to set thread main status: Invalid argument (22) Aborted Performing an apt-get remove successfully removes the package (the error loop above does not occur - the script just gives up), and an apt-get install repeats the situation, albeit without the warning about /var/lib/ejabberd. I'm running this system under User Mode Linux, but this doesn't usually cause problems with other network-related software. With a broken package, it does seem to be possible to invoke the daemon manually using the command from the init script, and as pointed out in another bug (#709754), an epmd daemon gets started, but the package state does not seem to be fixable. I hope this provides useful information. It's rare to see a Debian package fail in this way. Paul -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.52 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages ejabberd depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 ii erlang-asn11:15.b.1-dfsg-4 ii erlang-base [erlang-abi-15.b] 1:15.b.1-dfsg-4 ii erlang-crypto 1:15.b.1-dfsg-4 ii erlang-inets 1:15.b.1-dfsg-4 ii erlang-mnesia 1:15.b.1-dfsg-4 ii erlang-odbc1:15.b.1-dfsg-4 ii erlang-public-key 1:15.b.1-dfsg-4 ii erlang-ssl 1:15.b.1-dfsg-4 ii erlang-syntax-tools1:15.b.1-dfsg-4 ii libc6 2.13-38 ii libexpat1 2.1.0-1+deb7u1 ii libpam0g 1.1.3-7.1 ii libssl1.0.01.0.1e-2+deb7u3 ii openssl1.0.1e-2+deb7u3 ii ucf3.0025+nmu3 ii zlib1g 1:1.2.7.dfsg-13 ejabberd recommends no packages. Versions of packages ejabberd suggests: pn imagemagick | graphicsmagick-imagemagick-compat none ii libunix-syslog-perl 1.1-2+b2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737267: libvirt-bin: libvirtd-1.2.1 crash/abort in libnl3 at startup (but libvirtd-1.2.0-2 don't)
Package: libvirt-bin Version: 1.2.1-1~bpo70+1 Severity: grave Justification: renders package unusable Hello, When upgrade libvirt from 1.2.0-2 to 1.2.1-1 it no longer start. An assert fail in libnl3. I've upgrade libnl3 to the latest version from testing with the same result. So I've patched the assert in libnl3 as it test twi things. # libvirtd -v OK lib/route/tc.c:978 : ops-to_type = 2, RTNL_TC_TYPE_MAX = 2 OK lib/route/tc.c:978 : ops-to_type = 2, RTNL_TC_TYPE_MAX = 2 OK lib/route/tc.c:978 : ops-to_type = 2, RTNL_TC_TYPE_MAX = 2 OK lib/route/tc.c:978 : ops-to_type = 2, RTNL_TC_TYPE_MAX = 2 lib/route/tc.c:978 : ops-to_type = 650356128, RTNL_TC_TYPE_MAX = 2 libvirtd: /usr/src/tmp/libnl3-3.2.21/./lib/route/tc.c:980: rtnl_tc_register: Assertion `0' failed. Caught abort signal dumping internal log buffer: == start of log = 2014-01-31 22:16:10.698+: 17795: debug : virLogParseOutputs:1346 : outputs=3:stderr 2014-01-31 22:16:10.698+: 17795: debug : virObjectNew:199 : OBJECT_NEW: obj=0x7f13328351b0 classname=virAccessManagerClass 2014-01-31 22:16:10.698+: 17795: debug : virAccessManagerNewDriver:105 : Initialized with stack 2014-01-31 22:16:10.698+: 17795: debug : virObjectNew:199 : OBJECT_NEW: obj=0x7f1332836380 classname=virAccessManagerClass 2014-01-31 22:16:10.698+: 17795: debug : virAccessManagerNewDriver:105 : Initialized with none 2014-01-31 22:16:10.698+: 17795: debug : virObjectRef:293 : OBJECT_REF: obj=0x7f13328351b0 2014-01-31 22:16:10.698+: 17795: debug : virObjectUnref:256 : OBJECT_UNREF: obj=0x7f13328351b0 2014-01-31 22:16:10.698+: 17795: debug : main:1299 : Decided on pid file path '/var/run/libvirtd.pid' 2014-01-31 22:16:10.698+: 17795: debug : main:1309 : Decided on socket paths '/var/run/libvirt/libvirt-sock' and '/var/run/libvirt/libvirt-sock-ro' 2014-01-31 22:16:10.698+: 17795: debug : main:1345 : Ensuring run dir '/var/run/libvirt' exists 2014-01-31 22:16:10.698+: 17795: debug : virFileMakePathHelper:2279 : path=/var/run/libvirt mode=0777 2014-01-31 22:16:10.698+: 17795: debug : virNetlinkStartup:136 : Running global netlink initialization 2014-01-31 22:16:10.698+: 17795: debug : virObjectNew:199 : OBJECT_NEW: obj=0x7f1332836770 classname=virNetServer 2014-01-31 22:16:10.699+: 17795: debug : virEventRegisterDefaultImpl:259 : registering default event implementation 2014-01-31 22:16:10.699+: 17795: debug : virEventPollAddHandle:111 : Used 0 handle slots, adding at least 10 more 2014-01-31 22:16:10.699+: 17795: debug : virEventPollInterruptLocked:713 : Skip interrupt, 0 0 2014-01-31 22:16:10.699+: 17795: debug : virEventPollAddHandle:136 : EVENT_POLL_ADD_HANDLE: watch=1 fd=6 events=1 cb=0x7f1331786080 opaque=(nil) ff=(nil) 2014-01-31 22:16:10.699+: 17795: debug : virEventRegisterImpl:229 : addHandle=0x7f1331786e70 updateHandle=0x7f1331786cf0 removeHandle=0x7f1331786560 addTimeout=0x7f13317866f0 updateTimeout=0x7f1331786920 removeTimeout=0x7f1331786af0 2014-01-31 22:16:10.699+: 17795: debug : main:1385 : Dropping privileges (if required) 2014-01-31 22:16:10.699+: 17795: debug : virDriverModuleInitialize:54 : Module dir /usr/lib/libvirt/connection-driver 2014-01-31 22:16:10.699+: 17795: debug : virDriverLoadModule:67 : Module load network 2014-01-31 22:16:10.699+: 17795: debug : virRegisterNetworkDriver:554 : registering Network as network driver 2 2014-01-31 22:16:10.699+: 17795: debug : virDriverLoadModule:67 : Module load storage 2014-01-31 22:16:10.701+: 17795: debug : virRegisterStorageDriver:610 : registering storage as storage driver 2 2014-01-31 22:16:10.701+: 17795: debug : virDriverLoadModule:67 : Module load nodedev 2014-01-31 22:16:10.702+: 17795: debug : udevNodeRegister:1823 : Registering udev node device backend 2014-01-31 22:16:10.702+: 17795: debug : virRegisterNodeDeviceDriver:638 : registering udevNodeDeviceDriver as device driver 2 2014-01-31 22:16:10.702+: 17795: debug : virDriverLoadModule:67 : Module load secret 2014-01-31 22:16:10.703+: 17795: debug : virRegisterSecretDriver:666 : registering secret as secret driver 2 2014-01-31 22:16:10.703+: 17795: debug : virDriverLoadModule:67 : Module load nwfilter 2014-01-31 22:16:10.704+: 17795: debug : virRegisterNWFilterDriver:694 : registering nwfilter as network filter driver 2 2014-01-31 22:16:10.704+: 17795: debug : virDriverLoadModule:67 : Module load interface == end of log = Aborted (gdb) run - Starting program: /usr/sbin/libvirtd - [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x735bb700 (LWP 21795)] [New Thread 0x72dba700 (LWP 21796)] [New Thread 0x725b9700 (LWP 21797)] [New Thread 0x71db8700 (LWP 21798)] [New Thread 0x715b7700 (LWP 21799)] [New Thread 0x70db6700 (LWP 21800)] [New Thread 0x705b5700 (LWP 21801)] [New Thread
Bug#737268: apt-cacher-ng: Cannot delete unreferenced files from the Show unreferenced page
Package: apt-cacher-ng Version: 0.7.25-1 Severity: normal Tags: upstream patch Dear Maintainer, When you attempt to delete unreferenced files through the Delete all listed files link on the Show unreferenced page, the operation fails because the URL is incorrect. Specifically, the acng-report.html part of the URL gets treated as the host name. I have included a patch to fix the problem. -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apt-cacher-ng depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.52 ii dpkg 1.17.1 ii init-system-helpers1.14 ii libbz2-1.0 1.0.6-5 ii libc6 2.17-97 ii libgcc11:4.8.1-10 ii liblzma5 5.1.1alpha+20120614-2 ii libssl1.0.01.0.1e-3 ii libstdc++6 4.8.1-10 ii libwrap0 7.6.q-25 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages apt-cacher-ng recommends: ii avahi-daemon 0.6.31-4 ii ed1.9-2 Versions of packages apt-cacher-ng suggests: ii curl 7.32.0-1 ii doc-base 0.10.5 ii libfuse2 2.9.2-4 ii wget 1.14-4 -- Configuration Files: /etc/apt-cacher-ng/acng.conf changed: CacheDir: /var/cache/apt-cacher-ng LogDir: /var/log/apt-cacher-ng Port:3142 BindAddress: 192.168.0.1 Remap-debrep: file:deb_mirror*.gz file:deb_mirrors /debian ; file:backends_debian # Debian Archives Remap-uburep: file:ubuntu_mirrors security.ubuntu.com/ubuntu /ubuntu ; file:backends_ubuntu # Ubuntu Archives Remap-debvol: file:debvol_mirror*.gz /debian-volatile ; file:backends_debvol # Debian Volatile Archives Remap-debmul: file:debmul_mirrors /debian-multimedia ; file:backends_debmul Remap-medibuntu: file:medibuntu_mirrors /medibuntu ; file:backends_medibuntu Remap-getdeb: file:getdeb_mirrors /getdeb ; file:backends_getdeb Remap-mate: http://packages.mate-desktop.org/repo/ Remap-opera: http://deb.opera.com/opera/ Remap-cygwin: file:cygwin_mirrors /cygwin # ; file:backends_cygwin # incomplete, please create this file or specify preferred mirrors here Remap-sfnet: file:sfnet_mirrors http://downloads.sourceforge.net/ # ; file:backends_sfnet # incomplete, please create this file or specify preferred mirrors here Remap-alxrep: file:archlx_mirrors /archlinux # ; file:backend_archlx # Arch Linux Remap-fedora: file:fedora_mirrors # Fedora Linux Remap-epel: file:epel_mirrors # Fedora EPEL Remap-slrep: file:sl_mirrors # Scientific Linux Remap-gentoo: file:gentoo_mirrors.gz /gentoo ; file:backends_gentoo # Gentoo Archives ReportPage: acng-report.html ExTreshold: 4 VfilePattern = (^|.*/)(Index|Packages(\.gz|\.bz2|\.lzma|\.xz)?|InRelease|Release|Release\.gpg|custom\.gpg|mirrors.txt|Sources(\.gz|\.bz2|\.lzma|\.xz)?|release|index\.db-.*\.gz|Contents-[^/]*(\.gz|\.bz2|\.lzma|\.xz)?|pkglist[^/]*\.bz2|rclist[^/]*\.bz2|meta-release[^/]*|Translation[^/]*(\.gz|\.bz2|\.lzma|\.xz)?|MD5SUMS|SHA1SUMS|((setup|setup-legacy)(\.ini|\.bz2|\.hint)(\.sig)?)|mirrors\.lst|repo(index|md)\.xml(\.asc|\.key)?|directory\.yast|products|content(\.asc|\.key)?|media|filelists\.xml\.gz|filelists\.sqlite\.bz2|repomd\.xml|packages\.[a-zA-Z][a-zA-Z]\.gz|info\.txt|license\.tar\.gz|license\.zip|.*\.(db|files|abs)(\.tar(\.gz|\.bz2|\.lzma|\.xz))?|metalink\?repo|.*prestodelta\.xml\.gz|repodata/.*\.(xml|sqlite)(\.gz|\.bz2|\.lzma|\.xz))$|/dists/.*/installer-[^/]+/[^0-9][^/]+/images/.*|^.*(\.vps|\.md5|\.exe|\.cab|\.msi|\.zip|\.bin|\.psf|\.7z|\.iso|\.msu|\.apf|\.pdf|\.swf|\.f4v|\.flv|\.xml|\.png|\.dae|\.jpg|\.css|\.js|\.gif|\.wof|\.apm)$ WfilePattern = (^|.*/)(Release|InRelease|Release\.gpg|custom\.gpg|(Packages|Sources)(\.gz|\.bz2|\.lzma|\.xz)?|Translation[^/]*(\.gz|\.bz2|\.lzma|\.xz)?|MD5SUMS|SHA1SUMS|.*\.xml|.*\.(db|files|abs)(\.tar(\.gz|\.bz2|\.lzma|\.xz))?|[a-z]+32.exe)$|/dists/.*/installer-.*/images/.*|^static/.* RecompBz2: 1 DontCache: carlitos 192.168.0.1 DirPerms: 02755 FilePerms: 00644 LocalDirs: acng-doc /usr/share/doc/apt-cacher-ng PassThroughPattern: private-ppa\.launchpad\.net:443$ /etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: u'/etc/apt-cacher-ng/security.conf' /etc/default/apt-cacher-ng changed: umask 022 DAEMON_OPTS= -c /etc/apt-cacher-ng -- debconf information: apt-cacher-ng/proxy: keep apt-cacher-ng/cachedir: keep apt-cacher-ng/gentargetmode: No automated setup apt-cacher-ng/bindaddress: keep apt-cacher-ng/port: keep From df55066f460a3b2da7ee05d013c65b8f6342fd78 Mon Sep 17 00:00:00 2001 From: Carlos Maddela madd...@labyrinth.net.au Date: Sat, 1 Feb 2014 09:14:40 +1100 Subject: fix delete link Description: Fix Delete all listed files link for unreferenced files. Patch-Name:
Bug#699185: upstream support is incomplete
Daniel Schepler wrote: (It's strange that there seems to be no way to configure for compiling to an x32 target in upstream when the x32 support is definitely there in pr/include/md/_linux.cfg.) That's because some guys already partially added it, but didn't finish the job: https://bugzilla.mozilla.org/show_bug.cgi?id=767759 I took the liberty of posting Daniel's patch there. It needs replacing mozilla/nsprpub - nspr because of source tree's layout change, but after that, it works for me (for the values of works being allows compiling nss against it, but if it compiles, ship it, right?). As for this patch in Debian: after amending the path, it works, you can ignore hunks that fail to apply as they touch comments in a generated file(!). The two hunks that do matter happen to apply successfully. -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737245: Wheezy kernel fails to browse NFS export with 64 bits inode
Control: reassign src:linux On Vi, 31 ian 14, 19:58:18, Emmanuel Florac wrote: Package: linux-image Mounting an NFS export from a large XFS filesystem, either using NFS3 or NFS4, on a freshly installed wheezy : # uname -a Linux violon 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux # mount 10.1.2.3:/mnt/export /mnt/nfs # ls /mnt/nfs Stale NFS handle. # umount /mnt/nfs # mount -o vers=3 10.1.2.3:/mnt/export /mnt/nfs # ls /mnt/nfs Stale NFS handle. This is if the inode number on the /mnt/export XFS fs on the server is 64 bits. If the inode is smaller and fits in 32 bits, it works perfectly fine. This is a very annoying bug. There are no errors in dmesg or /var/log/messages. Running on the file server Wheezy with a custom kernel (plain vanilla source from kernel.org). -- Emmanuel Florac | Direction technique | Intellique | eflo...@intellique.com | +33 1 78 94 84 02 -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Bug#737183: pu: package kfreebsd-8/8.3-6+deb7u1
On 31/01/14 05:42, Adam D. Barratt wrote: Please go ahead, bearing in mind that the window for 7.4 closes this weekend. This should now be in your queue. Many thanks. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737269: tex-gyre: should only (at most) recommend fonts-texgyre
Package: tex-gyre Version: 2.004.2-4 Severity: normal OpenType fonts cannot be embedded in PDF files prior to PDF 1.5. Unfortunately some of the most prominent of Free Software PDF producers for professional grade desktop publishing - Ghostscript and Scribus - only supports PDF 1.4, forcing these tools to convert OpenType fonts to vectors with loss of quality as a consequence: http://wiki.scribus.net/canvas/Help:Manual_Fontsconfig#Other_notes_about_fonts_and_font_management: Tex Gyre is a high quality font, interesting for professional DtP, but on Debian the fonts-texgyre package provides the OpenType flavor of the fonts, and the alternative Type1 fonts is included only in the tex-gyre package which depends on fonts-texgyre. Additionally fonts-texgyre ships with a fontconfig config snippet to suppress the Type1 flavor. I argue that this is a genuine use-case for having tex-gyre installed _without_ fonts-texgyre, and ask that the relation therefore should be relaxed to only recommend fonts-texgyre. - Jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737223: Bug#737246: libprotobuf8: 2.5.0-7 breaks mumble
On Friday, January 31, 2014 15:21:53 Robert Edmonds wrote: Chris Knadle wrote: severity 737246 grave thanks It's probably related to #736801 I guess. Unfortunately this is not related to #736801 as best I can tell; recompiling mumble locally with libprotobuf8 2.5.0-7 has the same result. This means mumble is currently borked. :-( -- Chris In that case, it looks like my changes in 2.5.0-6 / -7 are just broken. Yes. 2.5.0-3 and -5 work, -6 and -7 don't. Most likely we need to revert back to the approach in 2.5.0-5 but fix the atomic code so that it works on the architectures with older default gcc versions. I'll see if I can get that done in the next day or so. Doing a 'debdiff' between the -5 and -6 version I see what you're talking about. [No code differences between -6 and -7.] The -488 patch removes the GoogleOnceInitImpl() function and references to it but somehow this symbol _ZN6google8protobuf18GoogleOnceInitImplEPlPNS0_7ClosureE is still expected by mumble even when building it anew. Anyway if there's a way in which I can lend a hand, let me know. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718432: Debian bug 718432
On 2014-01-30 18:22, gregor herrmann wrote: On Thu, 30 Jan 2014 17:42:49 +0100, Fernando Santagata wrote: Sorry for my lack of interaction: after some time everything started to work fine again. I saw that the bug was in state closed and I didn't think to write back to you. #718432 isn't closed in the Debian BTS [0], but if you don't see the issues anymore, we should probably close it :) I don't think anyone objects. I don't think this would have been an Apache::AuthCookie bug anyway. I'll close it out. Cheers, gregor [0] and neither is the upstream bug at https://rt.cpan.org/Public/Bug/Display.html?id=91740 [1] Links: -- [1] https://rt.cpan.org/Public/Bug/Display.html?id=91740 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737231: [claws-mail] Fails to send mesages on google account
tags 737231 moreinfo thanks Hi, On Fri, 31 Jan 2014 18:50:36 +0200 Corcodel Marian corcodel.mar...@gmail.com wrote: I have two attachments ,is result on tcpdump a same server smtp .On icedove working to send message and claws-mail break to send send mss 1460 an this it. What is the error reported by Claws Mail? Also, please attach network dialog between Claws Mail and the server of a failing session. You can found it in “Tools” menu, “Network Log” option. regards, P.S.: please keep bug address in Cc. -- Ricardo Mones http://people.debian.org/~mones «Were these parsnips CORRECTLY MARINATED in TACO SAUCE?» signature.asc Description: PGP signature
Bug#737168: apt-listbugs breaks, preventing package installation
If I get the time to do so, I may attempt to trace the dependencies for apt-listbugs to find out why it broke on my system. Until then, I'd be happy for this bug to be marked invalid. On 1/02/2014 7:58 AM, Francesco Poli invernom...@paranoici.org wrote: On Fri, 31 Jan 2014 13:09:36 +1300 Brendon Green wrote: On 31 January 2014 12:04, Francesco Poli invernom...@paranoici.org wrote: [...] Anyway, please read http://bugs.debian.org/735116#10 for the suggested procedure to fix the issue. Thank you. I found it sufficient to install ruby1.9.1/1.9.3.194-8.1+deb7u2 from stable. I could not remove ruby1.8, as it is pulled in as a dependency of apt-listbugs/0.1.8+deb7u1. Well, I thought you wanted to upgrade to apt-listbugs/0.1.12 ... At least, that's what you stated in the original bug report. But anyway... Since apt-listbugs/0.1.8+deb7u1 does not appear to work with the interpreter that was provided by ruby1.8/1.8.7.358-7.1+deb7u1, this is perhaps a packaging bug that requires fixing? I tested apt-listbugs/0.1.8+deb7u1 in a stable chroot environment and it definitely seemed to work for me. If you are experiencing any difficulty with apt-listbugs/0.1.8+deb7u1 in an up-to-date *purely* stable system, please do not hesitate to report bugs. Otherwise, on a mixed testing/stable system, I suspect that the issue may be caused by the fact that ruby1.8/1.8.7.358-7.1+deb7u1 still Provides ruby-interpreter and may be selected as system-wide default Ruby interpreter, but ruby-debian/0.3.8+b2 (installed from testing) no longer supports ruby1.8 ... Antonio, any thoughts about this partial-upgrade scenario? Is there a way to avoid this? Maybe architecture-dependent Ruby libraries (such as ruby-debian) should really conflict with libruby1.8, as soon as they drop support for the obsolete ruby1.8 (as I initially suggested)? Any simpler solution? -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Bug#737270: ITP: chealpix -- C language interface for Hierarchical Equal Area isoLatitude Pixelization
Package: wnpp Severity: wishlist Owner: Leo Singer leo.sin...@ligo.org X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: chealpix Version : 3.11.2 Upstream Author : Martin Reinecke mar...@mpa-garching.mpg.de * URL : http://healpix.sourceforge.net * License : GPL-2+ Programming Lang: C Description : C language interface for Hierarchical Equal Area isoLatitude Pixelization This is the C language implementation of HEALPix (Hierarchical Equal Area isoLatitude Pixelization). It is a map projection and indexing scheme for representing data on the unit sphere, commonly used to store all-sky astronomical images or databases, including cosmic microwave background maps and all-sky survey images. This is the first of three ITPs for the C, C++, and Python interfaces (chealpix, healpix-cxx, and healpy). I have contributed build-related code upstream for all three packages and I maintain their respective Mac OS packages in MacPorts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737271: ITP: healpix-cxx -- C++ language interface for Hierarchical Equal Area isoLatitude Pixelization
Package: wnpp Severity: wishlist Owner: Leo Singer leo.sin...@ligo.org X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: healpix-cxx Version : 3.11.2 Upstream Author : Martin Reinecke mar...@mpa-garching.mpg.de * URL : http://healpix.sourceforge.net * License : GPL-2+ Programming Lang: C++ Description : C++ language interface for Hierarchical Equal Area isoLatitude Pixelization This is the C++ language implementation of HEALPix (Hierarchical Equal Area isoLatitude Pixelization). It is a map projection and indexing scheme for representing data on the unit sphere, commonly used to store all-sky astronomical images or databases, including cosmic microwave background maps and all-sky survey images. This is the second of three ITPs for the C, C++, and Python interfaces (chealpix, healpix-cxx, and healpy). I have contributed build-related code upstream for all three packages and I maintain their respective Mac OS packages in MacPorts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737272: ITP: healpy -- Python language interface for Hierarchical Equal Area isoLatitude Pixelization
Package: wnpp Severity: wishlist Owner: Leo Singer leo.sin...@ligo.org X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: healpy Version : 1.7.3 Upstream Author : Andrea Zonca zo...@deepspace.ucsb.edu * URL : http://healpy.readthedocs.org * License : GPL-2+ Programming Lang: Python Description : Python language interface for Hierarchical Equal Area isoLatitude Pixelization This is the Python language implementation of HEALPix (Hierarchical Equal Area isoLatitude Pixelization). It is a map projection and indexing scheme for representing data on the unit sphere, commonly used to store all-sky astronomical images or databases, including cosmic microwave background maps and all-sky survey images. This is the third of three ITPs for the C, C++, and Python interfaces (chealpix, healpix-cxx, and healpy). I have contributed build-related code upstream for all three packages and I maintain their respective Mac OS packages in MacPorts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737273: ITP: libepoxy -- a library for handling OpenGL function pointer management for you.
Package: wnpp Severity: wishlist Owner: Eric Anholt e...@anholt.net * Package name: libepoxy Version : 1.0 Upstream Author : Eric Anholt e...@anholt.net * URL : https://github.com/anholt/libepoxy * License : MIT/X Programming Lang: C, Python Description : a library for handling OpenGL function pointer management for you. I am the upstream developer and the aspiring debian packager. The 1.16 X Server is probably going to depend on this library, as well as the piglit GL testing suite (which is mostly run by Mesa developers working on either debian or ubuntu) once my patch series lands. So, while we have no software depending on it at the moment, I'd like to make it easier for people when the time comes. My plan is to host the debian packaging on a branch of the upstream repo (github). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: whatever you want to call this: openscenegraph
2014-01-31 Markus Wanner mar...@bluegap.ch: On 01/31/2014 07:28 PM, Niels Thykier wrote: On the topic of 99-100, do you know if that will happen any time soon? I am wondering whether we should go for finishing the 80-99 and do a separate 99-100 or wait and jump directly from 80-100. If 100 is coming soon, it is probably easiest to do 80-100 (will save us a couple of rebuilds and we waiting for other things right now anyway). On the other hand, I would hate for this transition to drag on waiting for a new version that isn't happening while blocking other packages from reaching testing. IIUC release 3.2.0 (as opposed to the rc) already brings SOVERSION 100. So we could release that and transition to 100 right away. What Markus says is right. What happened was that they did some important/nasty code changes just before the the ~rc1, which we/I didn't relalise that it would be bad (because upstream didn't expect any major problems). But adapting other packages to it was not as easy/smooth as upstream expected. Then they changed 99-100 between version 3.2.0~rc1 (current package in Debian) and the final 3.2.0, so updating Debian would cause again a round of rebuilds and maybe more source changes; and while pondering whether to upgrade the package in Debian to the final upstream version, they released 3.2.1~rc1 very shortly afterwards, planning to release 3.2.1 within the same month. But that was in October, with expectations every now and then that the release would be imminent, but it didn't happen. So we wanted to jump from 3.2.0~rc1 with SOVERSION 99 to 3.2.1 final with SOVERSION unknown), to avoid the problems that Niels mentions (despite what Markus said later, I thought that it can be higher than 100 before 3.2.1 final). (There were other problems and the package was unbuildable for quite some time, mostly my fault, but in truth related with other pressing issues in my Debian duties and due to expecting to have the 3.2.1 upstream released and fixing everything together without more disturbances to rdeps... which didn't happen, so we recently decided to not wait any longer and fix 3.2.0~rc1). Also note that release 3.2.1 is due as well (for quite some time now, though. RC2 has been released, recently). However, according to their website [1], it should be binary compatible. (And their current 3.2 branch still has a SOVERSION of 100.) So going straight through to 100 seems reasonable to me. Seeing that back in summer we took a similar decision based on similar premises, which later were not fulfilled and led to the situation that we have now, I am not sure that we should jump to 3.2.1, or even that it's going to be released before March or April. But I am open to any suggestion really, I just want to avoid more problems for rdeps. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
Yikes, looks like gparted has an off by one: it set the partition size one sector two small. Do you have any thoughts on this Curtis? On 01/31/2014 02:16 PM, ano...@users.sourceforge.net wrote: Package: gparted Version: 0.17.0-4 I tried to shrink-and-move a partition on an external hard drive. It seems that gparted shrunk the parition to 93768726 4K blocks, but then resized the parition to only 750149807 512-byte sectors (93768725.875 4K blocks). The post-shrink e2fsck then errored out before the partition could be moved. gparted log attached. Title: GParted Details GParted 0.17.0 --enable-libparted-dmraid --enable-online-resize Libparted 2.3 Move /dev/sdb1 to the right and shrink it from 1.82 TiB to 357.70 GiB00:34:04( ERROR ) calibrate /dev/sdb100:00:00( SUCCESS ) path: /dev/sdb1start: 2048end: 3907029166size: 3907027119 (1.82 TiB) check file system on /dev/sdb1 for errors and (if possible) fix them00:12:59( SUCCESS ) e2fsck -f -y -v -C 0 /dev/sdb1 Pass 1: Checking inodes, blocks, and sizesPass 2: Checking directory structure Pass 3: Checking directory connectivityPass 4: Checking reference counts Pass 5: Checking group summary information 720259 inodes used (0.59%, out of 122101760)1666 non-contiguous files (0.2%) 256 non-contiguous directories (0.0%) # of inodes with ind/dind/tind blocks: 54238/1153/481366570 blocks used (16.66%, out of 488378389) 0 bad blocks 51 large files 576227 regular files 134638 directories1120 character device files 740 block device files 24 fifos 0 links7472 symbolic links (6954 fast symbolic links) 29 sockets 720250 files e2fsck 1.42.9 (28-Dec-2013) shrink file system00:21:05( SUCCESS ) resize2fs -p /dev/sdb1 375074904K Resizing the filesystem on /dev/sdb1 to 93768726 (4k) blocks.Begin pass 2 (max = 2011620)Relocating blocks Begin pass 3 (max = 14905)Scanning inode table Begin pass 4 (max = 135768)Updating inode references The filesystem on /dev/sdb1 is now 93768726 blocks long. resize2fs 1.42.9 (28-Dec-2013) shrink partition from 1.82 TiB to 357.70 GiB00:00:00( SUCCESS ) old start: 2048old end: 3907029166old size: 3907027119 (1.82 TiB) new start: 2048new end: 750151854new size: 750149807 (357.70 GiB) check file system on /dev/sdb1 for errors and (if possible) fix them00:00:00( ERROR ) e2fsck -f -y -v -C 0 /dev/sdb1 The filesystem size (according to the superblock) is 93768726 blocksThe physical size of the device is 93768725 blocksEither the superblock or the partition table is likely to be corrupt!Abort? yes e2fsck 1.42.9 (28-Dec-2013) signature.asc Description: OpenPGP digital signature
Bug#737274: gnucash: No suitable backend for postgres
Package: gnucash Version: 1:2.6.1-1 Severity: normal Dear Maintainer, * What led up to the situation? Not sure. (Checked dpkg.log and did not see gnucash or dbd recently upgraded.) * What exactly did you do (or not do) that was effective (or ineffective)? 1) ineffective: upgrade gnucash:i386 1:2.6.0-1 1:2.6.1-1 2) effective: upgrade libdbd-pgsql:i386 0.8.3-1+s-5+b1 0.9.0-2 * What was the outcome of this action? 1) backend not found 2) backend was found Please update package suggestions to include version numbers as required. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'stable'), (600, 'experimental'), (600, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.11-2-686-pae (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnucash depends on: ii gnucash-common 1:2.6.1-1 ii guile-2.0 2.0.9+1-1 ii guile-2.0-libs 2.0.9+1-1 ii libaqbanking34 5.3.1beta-2 ii libc6 2.17-97 ii libcairo2 1.12.16-2 ii libcrypt-ssleay-perl 0.58-1+b1 ii libdate-manip-perl 6.42-1 ii libdbi10.9.0-1 ii libfinance-quote-perl 1.18-1 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-0 2.36.4-1 ii libgnome-keyring0 3.8.0-2 ii libgnomecanvas2-0 2.30.3-2 ii libgoffice-0.8-8 0.8.17-3 ii libgtk2.0-02.24.22-1 ii libgwengui-gtk2-0 4.9.0beta-1 ii libgwenhywfar604.9.0beta-1 ii libhtml-tableextract-perl 2.11-1 ii libhtml-tree-perl 5.03-1 ii libktoblzcheck1c2a 1.44-1 ii libofx41:0.9.4-2.1 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-01.36.0-1+b1 ii libpython2.7 2.7.6-5 ii libwebkitgtk-1.0-0 2.2.3-1 ii libwww-perl6.05-2 ii libx11-6 2:1.6.2-1 ii libxml22.9.1+dfsg1-3 ii libxslt1.1 1.1.28-2 ii perl 5.18.2-2 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages gnucash recommends: pn gnucash-docs none ii yelp 3.10.1-1 Versions of packages gnucash suggests: ii libdbd-mysql0.8.3-1+s-5+b1 ii libdbd-pgsql0.9.0-2 ii libdbd-sqlite3 0.8.3-1+s-5+b1 -- 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#737275: Clang crashes on SPARC
Package: clang Version: 1.3.0-6.2 Invoking clang on any 'c' file including stdlib.h crashes the compiler with a Bus Error and a backtrace. Crash log is below. -Richard rsaxvc@home:~/code$ cat test.c #include stdlib.h rsaxvc@home:~/code$ clang test.c clang: warning: unknown platform, assuming -mfloat-abi=soft 0 libLLVM-3.0.so.1 0xf7704cd0 1 libpthread.so.0 0xf69850b8 2 clang0x00998bb8 3 clang0x00999d3c 4 clang0x00999f58 clang::Expr::Evaluate(clang::Expr::EvalResult, clang::ASTContext const) const + 24 5 clang0x0099b144 clang::Expr::isIntegerConstantExpr(llvm::APSInt, clang::ASTContext, clang::SourceLocation*, bool) const + 100 6 clang0x009880dc clang::Expr::isNullPointerConstant(clang::ASTContext, clang::Expr::NullPointerConstantValueDependence) const + 604 7 clang0x00550440 clang::Sema::PrepareScalarCast(clang::ActionResultclang::Expr*, true, clang::QualType) + 1184 8 clang0x0046e3e8 clang::Sema::BuildCStyleCastExpr(clang::SourceLocation, clang::TypeSourceInfo*, clang::SourceLocation, clang::Expr*) + 2952 9 clang0x00565838 clang::Sema::ActOnCastExpr(clang::Scope*, clang::SourceLocation, clang::Declarator, clang::OpaquePtrclang::QualType, clang::SourceLocation, clang::Expr*) + 344 10 clang0x00430968 clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption, bool, bool, clang::OpaquePtrclang::QualType, clang::SourceLocation) + 2696 11 clang0x0042c288 clang::Parser::ParseCastExpression(bool, bool, bool, bool) + 1608 12 clang0x0042e768 clang::Parser::ParseCastExpression(bool, bool, bool) + 40 13 clang0x0042f0f8 clang::Parser::ParseAssignmentExpression() + 56 14 clang0x0042fe94 clang::Parser::ParseExpression() + 20 15 clang0x004306b4 clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption, bool, bool, clang::OpaquePtrclang::QualType, clang::SourceLocation) + 2004 16 clang0x0042c288 clang::Parser::ParseCastExpression(bool, bool, bool, bool) + 1608 17 clang0x0042e768 clang::Parser::ParseCastExpression(bool, bool, bool) + 40 18 clang0x0042f0f8 clang::Parser::ParseAssignmentExpression() + 56 19 clang0x0042fe94 clang::Parser::ParseExpression() + 20 20 clang0x004306b4 clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption, bool, bool, clang::OpaquePtrclang::QualType, clang::SourceLocation) + 2004 21 clang0x00432044 clang::Parser::ParseExprAfterUnaryExprOrTypeTrait(clang::Token const, bool, clang::OpaquePtrclang::QualType, clang::SourceRange) + 420 22 clang0x00411594 clang::Parser::ParseTypeofSpecifier(clang::DeclSpec) + 84 23 clang0x00417098 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec, clang::Parser::ParsedTemplateInfo const, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 728 24 clang0x004188fc clang::Parser::ParseSimpleDeclaration(clang::ASTOwningVectorclang::Stmt*, 32u, unsigned int, clang::SourceLocation, clang::ParsedAttributes, bool, clang::Parser::ForRangeInit*) + 348 25 clang0x00418b54 clang::Parser::ParseDeclaration(clang::ASTOwningVectorclang::Stmt*, 32u, unsigned int, clang::SourceLocation, clang::Parser::ParsedAttributesWithRange) + 116 26 clang0x00402700 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange, clang::Parser::ParsingDeclSpec*) + 1024 27 clang0x004033b0 clang::Parser::ParseTopLevelDecl(clang::OpaquePtrclang::DeclGroupRef) + 176 28 clang0x003d97f8 clang::ParseAST(clang::Sema, bool) + 248 29 clang0x002b7b60 clang::CodeGenAction::ExecuteAction() + 32 30 clang0x001c3c04 clang::FrontendAction::Execute() + 292 31 clang0x001a9fe4 clang::CompilerInstance::ExecuteAction(clang::FrontendAction) + 356 32 clang0x001915c8 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1032 33 clang0x00189a7c cc1_main(char const**, char const**, char const*, void*) + 924 34 clang0x00187a34 main + 2228 35 libc.so.60xf65b8e4c __libc_start_main + 268 36 clang0x0018954c _start + 44 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple sparc-unknown-linux-gnu -S -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -msoft-float -target-feature +soft-float -target-linker-version 2.22 -momit-leaf-frame-pointer -resource-dir /usr/bin/../lib/clang/3.0 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.0/include -internal-externc-isystem /usr/include/sparc-linux-gnu -internal-externc-isystem /usr/include -ferror-limit 19 -fmessage-length 112 -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option
Bug#736892: CPU family
On Fri, 31 Jan 2014 04:48:47 -0500 (EST), Henrique de Moraes Holschuh wrote: The file is for family 15h, that h stands for hexadecimal base. 15 in the hexadecimal base is 21 in the decimal base. It is working correctly. Of course. How did I miss that? Doh! OK, you may close this bug report at your leisure. Despite the fact that /proc/cpuid reports only 2 cores instead of 4, it appears that all four CPUs do get their microcode updated. A kernel message something like skipping microcode upgrade for CPU #1: already up to date would be nice, but the lack of such a message is not, strictly speaking, a bug. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729977: vim-gtk: gvim fails with SIGSEV
Hmm, I seem to have missed this initally. Sorry about that. On Tue, Nov 19, 2013 at 12:04:49PM -0800, J C wrote: Running gvim fails with SIGSEV. Terminal vim runs fine. I'll need more information to be able to do anything with this bug. Could you install the vim-dbg and gdb packages? Then use gdb[0] to get a backtrace when running gvim with the -f arg. [0]: https://wiki.debian.org/HowToGetABacktrace#Running_gdb Hopefully that reproduces the problem and I'll have some information to work with. Also, can you try running gvim -u NONE to see if it's possibly related to some of your user configuration? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
Bug#737256: asymptote: FTBFS: nonstopmode; input ecrm1095' failed to make ecrm1095.tfm.
kpathsea: Running mktextfm ecrm1095 Indeed, recent texlive packages moved these fonts to fonts-recommended. Will be in the next upload. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713066: yaml indentation is faulty, could use improvement
Control: tag -1 unreproducible On Sat, Jun 22, 2013 at 11:56:32AM +0200, martin f krafft wrote: It is possible to place these into a list as well, i.e. a list of hashes: --- - a: b c: d - 1: 2 3: 4 Unfortunately, when entering this, the list's indentation level is not preserved, e.g. (▮ is cursor position, ▯ is where I think it should be): --- - a: breturn ▮ ▯ The behavior you describe is what I see with Vim. The YAML indent file was introduced around 7.3.753 and hasn't changed since. Are you sure you aren't using a third party indent script? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
Bug#726591: vim-common: mailcap vim -R
On Thu, Oct 17, 2013 at 10:24:14AM +1100, Kevin Ryde wrote: /usr/lib/mime/packages/vim-common contains text/plain; view %s; edit=vim %s; compose=vim %s; test=test -x /usr/bin/vim; needsterminal; priority=4 text/*; view %s; edit=vim %s; compose=vim %s; test=test -x /usr/bin/vim; needsterminal; priority=2 I think the view %s in each might better be vim -R %s There was some discussion about the view alternative on debian-devel last year and the mime-support maintainer had agreed that /usr/bin/see shouldn't be part of that alternative set. It doesn't seem like that change has happened yet, though. I'd prefer to just leave things be and let things settle out on their own once the see alternative is gone. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
Bug#729924: vim: Add Python 3 support
On Mon, Nov 18, 2013 at 05:59:02PM -0500, Barry Warsaw wrote:
I'm not a vim user but I'm am very interested in porting the world to
Python 3. To that end, I see that the current version of upstream vim
supports Python 3, but building that is not currently enabled in the
Debian package.
This is due to two things.
First, the way Debian builds Python prevents loading both libpython2 and
libpython3 in the same process, since Debian's builds necessitate
passing RTLD_GLOBAL to dlopen(). This means that when Vim is built to
support both Python 2 3, one has to choose between using plugins that
target Python 2 or Python 3 instead of the user being able to use both.
At the time, this meant I had to choose one and I went with Python 2 due
to the much higher prevalence of plugins targeting it. While Python 3
has gained a lot of ground since then and it's much more easy to write
code that works in both versions, my understanding is that the
RTLD_GLOBAL issue still exists. This means I still need to choose one
version and, while it's more of a toss up now, I think Python 2 is still
the right call here.
Second, I'm not keen on the state of dependency tracking with software
that dynamically loads libraries instead of linking against them. If
Vim dynamically loaded its own code that provides the language bindings,
and those were linked against the proper language libraries, then I
could easily provide vim-{lua,perl,python,ruby,tcl}-bindings packages
which expressed proper relationships on the corresponding language
libraries.
Since that isn't the case, we can then run into situations where bad
things happen during a library transition due to nothing telling the
transition trackers that Vim should actually be rebuilt or forcing the
users to upgrade Vim in sync with the library. See #611573 for some
previous discussion about this related to Vim's Perl support.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org
signature.asc
Description: Digital signature
Bug#737276: rpcbind config file /etc/default/rpcbind not mentioned anywhere in manpages/package documentation
Package: rpcbind Version: 0.2.0-8 Severity: normal Hi, although /etc/init.d/rpcbind does parse /etc/default/rpcbind if it exists (and as a fallback also /etc/rpcbind.conf), no template for this config file exists, nor is its existance and location mentioned anywhere in the documentation - neither in the manpages nor in /usr/share/doc/portmap. This is annoying and will be even more so for new but security aware users, since various security resources recommended by the debian project point out that the rpc service should be restricted to localhost if only used by local applications such as the (standard) Gnome Desktop. New users can not be expected to look into and understand /etc/init.d/rpcbind to find out whether config files are parsed, Maybe the /etc/default/rpcbind config file could look something like this: snip # Default settings for rpcbind. This file is sourced by /bin/sh from # /etc/init.d/rpcbind # Cause rpcbind to do a warm start utilizing a state file (default) OPTIONS=-w # Uncomment the following line to restrict rpcbind to localhost only for UDP requests #OPTIONS+=-h 127.0.0.1 # Uncomment the following line to enable libwrap TCP-Wrapper connection logging #OPTIONS+=-l /snip As for the manpages; I would suggest adding an appropriate files section to rpcbind (8) as well as a short README.Debian or similar note in /usr/share/doc, which might also mention the use of /etc/hosts.allow and /etc/hosts.deny and/or iptables rules to further control rpc access (see http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec- services.en.html#s-rpc). Thanks for all your work! luka -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-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 rpcbind depends on: ii initscripts 2.88dsf-41+deb7u1 ii insserv 1.14.0-5 ii libc62.13-38 ii libtirpc10.2.2-5 ii libwrap0 7.6.q-24 ii lsb-base 4.1+Debian8+deb7u1 rpcbind recommends no packages. rpcbind 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#734267: [Debian add-on] setting distribution only works when distro is known
On Sun, Jan 05, 2014 at 12:34:36PM +0100, Eduard Bloch wrote: When I try to set the distribution via the Changelog menu in gvim, it fails when the head line looks like this: foo-pkg (0.7.25-1) UNRELEASED; urgency=low But it works when there is some known release branch like frozen instead of UNRELEASED. Indeed. Thanks for the report. Looks like a simple fix. This looks like a regression, I remember having used this feature to change UNRELEASED many times in the last years. This functionality hasn't been touched in years (as evidenced by still referencing frozen :). Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
Bug#737276: Small correction
I meant /usr/share/doc/rpcbind of course, not /usr/share/doc/portmap. Regards, luka -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621807: Feature is available
In 0.2.0-8 this is (now?) configurable, just not documented. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737276 which also includes a config file suggestion. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737246: libprotobuf8: 2.5.0-7 breaks mumble
On Friday, January 31, 2014 15:21:53 Robert Edmonds wrote: Chris Knadle wrote: severity 737246 grave thanks It's probably related to #736801 I guess. Unfortunately this is not related to #736801 as best I can tell; recompiling mumble locally with libprotobuf8 2.5.0-7 has the same result. This means mumble is currently borked. :-( -- Chris In that case, it looks like my changes in 2.5.0-6 / -7 are just broken. Yes -3 and -5 work, -6 / -7 do not. However concerning the changes made to fix #736801 (build failures on ia64 and sparc), as of Wednesday (2014-01-29) it was announced in [debian-devel-announce] that ia64 and sparc are no longer release architectures. sparc is apparently still using gcc-4.6 as the default compiler, and the kernel in stable does not work. This means that Britney will allow package migrations into Testing regardless if packages for these two architectures are broken. Today it was announced the ia64 architecture was removed from Testing, and is likely to be removed from Sid as well soon. Most likely we need to revert back to the approach in 2.5.0-5 but fix the atomic code so that it works on the architectures with older default gcc versions. I'll see if I can get that done in the next day or so. Issues with ia64 can be ignored now, and under the circumstances sparc is questionable. I think you have the option of using the 2.5.0-5 package as it was if you wish. I'm not trying to rush a fix here though -- I'm mainly mentioning this because I'm wondering from the maintainer point of view if the effort to patch the protobuf source specifically for these two architectures is worth the effort. Obviously I didn't know these architecture changes were coming when I filed #736801 on the 26th. ;-) Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731563: git-stuff: Use shell parameter expansion whenever it is possible
close 731563 thanks thank you for your patch. however, in two cases the patch is incorrect since the existing command does more then the 'simplified' version you propose. then, one more has gone entirely and is not needed anymore, and finally, the other two i prefer to use the 'long one' for better readability, performance is hardly an issue here anyway. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717849: output lines doubled up
reassign 717849 virtualbox thanks this seems to be an issue specific to vbox, reassigning. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735357: vsftpd: seccomp generates audit syslog messages
close 735357 thanks this doesn't happen with recent enough kernel (=3.11). -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713066: yaml indentation is faulty, could use improvement
also sprach James McCoy james...@debian.org [2014-02-01 04:22 +0100]: The behavior you describe is what I see with Vim. The YAML indent file was introduced around 7.3.753 and hasn't changed since. Are you sure you aren't using a third party indent script? I am fairly sure I am not using a third party script. So when you enter - a: b c: it does not amend the indenting for you just as you hit that colon? Gosh, my initial report is quite bad, isn't it? The problem isn't the return, it's when entering the colon on the next line. Thanks for taking the time to look into this! -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems heisenberg may have been here. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#728653: login fails with too long password
close 728653 3.0.2-12 thanks i cannot reproduce that with the current version of vsftpd, it works just fine for me with 150 character passwords. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539978: marked as done (show says an installed package is not installed)
Control: reopen -1 Control: tags -1 = confirmed Control: severity -1 minor Control: owner -1 ! Control: retitle -1 [cmdline] show UPGRADE misleads by reporting not installed [To clarify this report. Also, taking ownership as it is entangled with wip-cmdline.] Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: # aptitude versions '^apt$' Package apt: i 0.9.14.2100 p 0.9.15unstable 500 # aptitude show apt Package: apt Essential: yes State: installed Automatically installed: no Version: 0.9.14.2 The package details shown above are for the installed version. The manual states that show displays the candidate version, which is presently not the case due to open issues with version selection on the command line [1]. Details for the candidate version still show not installed: $ aptitude show acpi | grep '^\(Pac\|Ver\|Sta\)' Package: acpi State: installed Version: 1.6-1 $ aptitude show acpi=CANDIDATE | grep '^\(Pac\|Ver\|Sta\)' Package: acpi State: not installed Version: 1.7-1 The concern being that it is misleading to report not installed for upgrades, though it may be technically correct, in a sense. It has been suggested to make things more clear by changing the state field to say not installed, upgrade or similar. An alternative is for aptitude show PKG to display both the candidate and installed versions, as apt-cache does. The wip-cmdline branch resolves the version selection issues and will make this issue with State more prominent again. The issue will be tended to in a continuation of that work. Regards Daniel Hartwig [1] http://bugs.debian.org/687474 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734241: Dimitri John Ledkov x...@debian.org
Hi Dimitri,
As per https://wiki.ubuntu.com/UpstartCompatibleInitScripts and the
debian policy on alternative init systems, init.d scripts and upstart
jobs should have a one-to-one mapping by name.
It appears that ceph-all.conf is shipped, but no equivalent init.d
script is present (even a dummy one), therefore the postinstall is
failing if the host system's pid one at the time is not upstart.
Either guard the calls in the postinst, to check for upstart, or
provide dummy / empty ceph-all initscript.
Is it okay to raise the severity of this issue to serious? It leaves my
package manager in unconsistent state I'm not able to successfully
install or uninstall this package and on each upgrade I get an error
saying ceph configure failed. Also its been a month and I'm not seeing
any activity on this bug probably because mail is not making it to the
moderated list of ceph team.
And yes I'm using systemd.
--
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4 C96B 6C8F 74AE 8770 0B7E
signature.asc
Description: PGP signature
Bug#737137: game-data-packager: patch to support hexdd
Isn't that a PWAD? Yes, but it's an *official* expansion - just like hexdd.wad (also a PWAD to the Hexen IWAD), which this bug was initially about. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737137: game-data-packager: patch to support hexdd
I'm not sure how to handle PWADs. I would like to see some packaged. I had a grand scheme to data-mine the doomworld.com/idgames DB for PWADs with a DFSG-free license, correlating with the community reviews/score to get the best ones. I suspect that, if that was ever done, someone should package the results up into one ZIP somewhere and that could be packaged as a first-class Debian archive package. Honestly, I am afraid the list of DSFG-free high-rated PWADs will be rather short. Instead, I think we should package some of the classics [1], or at least add support to download and package them with game-data-packager. Its purpose is to package non-free game data anyway. I think that rather than try to add individual PWAD support to g-d-p I'd like to see someone package and/or write-and-package a half decent doom launcher. Such a thing could handle downloading PWADs and storing them somewhere itself. (Of course, I'm not fixed in my opinions!) Yes, this would of course be better, but I am afraid that someone has to write this before. ;) - Fabian [1] E.g. the 6 Compet-N PWADs plus Icarus and Eternal Doom. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#248426: S'il vous plaît ouvrir la pièce jointe.
S'il vous plaît ouvrir la pièce jointe. WEBMASTER.rtf Description: RTF file
Bug#737277: lightdm: Does not remove /etc/X11/default-display-manager file on uninstall
Package: lightdm Severity: minor I uninstalled lightdm. I stopped lightdm before using aptitude to uninstall. I also removed X11 related packages and xorg. I also uninstalled related programs like dbus-x11 and some other things so this would be a console only box. This file was the only thing left behind. I did a dpkg -S on this system as well as on a system that still has all the gui programs still working(running). Nothing claims this file. It has the lightdm name in it so I figured I'd start here (lightdm) reporting it. Thanks for your time and attention. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (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 lightdm depends on: ii adduser3.113+nmu3 pn consolekit none ii dbus 1.8.0-1 ii debconf [debconf-2.0] 1.5.52 ii libc6 2.17-97 ii libgcrypt111.5.3-3 ii libglib2.0-0 2.36.4-1 ii libpam0g 1.1.3-9 ii libxcb11.10-2 ii libxdmcp6 1:1.1.1-1 pn lightdm-gtk-greeter | lightdm-greeter none Versions of packages lightdm recommends: pn xserver-xorg none Versions of packages lightdm suggests: pn accountsservice none ii upower 0.9.23-2+b1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711284: RM: electricsheep -- RoQA; orphaned, RC-buggy, licence problems
severity 669356 serious reassign 728296 ftp.debian.org retitle 728296 RM: electricsheep -- RoQA; orphaned, RC-buggy, licence problems thanks electricsheep is orphaned, and it has an RC bug (#728296) that might (or might not) be fixed by the new upstream version available. But the real problem is #669356, and getting that sorted out doesn't seem to be worth the hassle considering the current state of the package. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734763: Please update libjs-jquery-cookie and use upstream numbering
Hi, On Fri, 31 Jan 2014, Jerome Charaoui wrote: Le 2014-01-31 12:12, Daniel James a écrit : I think switching to upstream numbering is still possible. by using an epoch number. The new version number for libjs-jquery-cookie would be 1:1.4.0 (epoch 1) which would be more recent than 8-2 (epoch 0). It may not be necessary to use an epoch just for galette, as galette appears to bundle its own copy of libjs-jquery-cookie in /usr/share/galette/includes/jquery/jquery.cookie.js - according to: http://packages.debian.org/sid/all/galette/filelist While a number of web app maintainers in Debian seem to choose to do that, it's explicitly discouraged by the Debian Policy, see section 4.13 (http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles) So this is actually a bug in galette (especially so once jquery-cookie 1.4.0 makes it in the archive). $ dpkg -c galette_0.7.6.1-2_all.deb |grep cookie lrwxrwxrwx root/root 0 2013-11-05 10:03 ./usr/share/galette/includes/jquery/jquery.cookie.js - ../../../javascript/jquery-cookie/jquery.cookie.js So there's no bug here regarding jquery-cookie. And galette has a dependency on libjs-jquery-cookie (= 8) so you have to use the epoch. There might be other local packages with similar dependencies that you should not ignore. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732358: pu: package lxc/0.8.0~rc1-8+deb7u2
Hi, On Fri, 31 Jan 2014, Adam D. Barratt wrote: I've been arguing with myself a little, but on balance I'd prefer to stick with the template change for now. Thanks, uploaded. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737006: [Pkg-systemd-maintainers] Bug#737006: systemd: When init=/lib/systemd/systemd, selinux no longer works
Am 31.01.2014 15:47, schrieb Laurent Bigonville: Le Fri, 31 Jan 2014 06:56:49 +0100, Michael Biebl bi...@debian.org a écrit : Sounds like a bug in the selinux policy package to me, not in systemd itself. That said, I basically know nothing about selinux. bigon, can you comment on this bug report? Let us know whether we should re-assing it to one of the selinux-policy-* packages or if there is something which needs to be addressed in systemd. Yes you are correct, this is a bug in the policy and it should be reassigned to it. Which package should we re-assign this bug to: selinux-policy-default, src:refpolicy? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#737264: /usr/share/man/man7/systemd.directives.7.gz: systemd.directives(7) is empty
Am 31.01.2014 23:45, schrieb Sam Morris: Package: systemd Version: 204-6 Severity: minor File: /usr/share/man/man7/systemd.directives.7.gz The contents of systemd.directives(7) are missing. AFAIR they were present in version 204-5. I cannot reproduce this. Got this file corrupted on your hard disk maybe? Can you try to re-install, please I pulled the package from [1] and extracted the relevant file. It is attached for completeness sake. You can inspect it via: man -l systemd.directives.7.gz which produces the desired results Michael [1] http://ftp.de.debian.org/debian/pool/main/s/systemd/systemd_204-6_amd64.deb -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? systemd.directives.7.gz Description: GNU Zip compressed data signature.asc Description: OpenPGP digital signature
Bug#737006: [Pkg-systemd-maintainers] Bug#737006: systemd: When init=/lib/systemd/systemd, selinux no longer works
Le Sat, 01 Feb 2014 08:37:25 +0100, Michael Biebl bi...@debian.org a écrit : Am 31.01.2014 15:47, schrieb Laurent Bigonville: Le Fri, 31 Jan 2014 06:56:49 +0100, Michael Biebl bi...@debian.org a écrit : Sounds like a bug in the selinux policy package to me, not in systemd itself. That said, I basically know nothing about selinux. bigon, can you comment on this bug report? Let us know whether we should re-assing it to one of the selinux-policy-* packages or if there is something which needs to be addressed in systemd. Yes you are correct, this is a bug in the policy and it should be reassigned to it. Which package should we re-assign this bug to: selinux-policy-default, src:refpolicy? src:refpolicy is ok I guess :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539978: marked as done (show says an installed package is not installed)
On 1 February 2014 13:58, Daniel Hartwig mand...@gmail.com wrote: The concern being that it is misleading to report not installed for upgrades, though it may be technically correct, in a sense. It has been suggested to make things more clear by changing the state field to say not installed, upgrade or similar. The same concern is valid for multi-arch alternates, especially in the case of M-A: foreign packages that have an installed equivalent. An alternative is for aptitude show PKG to display both the candidate and installed versions, as apt-cache does. Another alternate is to handle this similar to how the curses interface does, including a list of versions at the end. Such an approach has to be clear about informing the user which version is providing the details, as dependencies, etc. are prone to change. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733035: clamav: FTBFS on powerpcspe
On Tuesday, December 24, 2013 12:51:59 Roland Stigge wrote: Source: clamav Version: 0.97.8+dfsg-1 Severity: wishlist Tags: patch User: debian-powerpc...@breakpoint.cc Usertags: powerpcspe Hi, clamav FTBFS on powerpcspe like this: Looking at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737119#10 I suspect an additional change is needed for powerpcspe now that I've uploaded 0.98. Please have a look and let me know what revisions are required. Scott K -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
