Bug#727708: init system coupling draft CFV
* Russ Allbery (r...@debian.org) [140221 06:15]: This includes the change I proposed to Andreas, although unfortunately Andreas hasn't had a chance to respond on whether that addressed his objection. It also makes it clearer that the point about not offering advice past jessie only applies to the sysvinit compatibility part. I think I'll be able to answer during the weekend, sorry for the delay. Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738909: Acknowledgement ([apt] Package System Broken, libc6 etc)
Here is the gist of it: If., due to whatever problem, at repo site or local internet or anywhere in between, one cannot access the site for desired distro, i.e. unstable, but can access experimental, apt will take packages from there. It should not do this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724116: resource-agents: diff for NMU version 1:3.9.3+git20121009-3.1
tags 724116 + pending patch
tags 739608 + pending patch
thanks
Dear maintainer,
I've prepared an NMU for resource-agents (versioned as
1:3.9.3+git20121009-3.1) and uploaded it to DELAYED/5. Please feel
free to tell me if I should delay it longer.
Regards,
Salvatore
diff -Nru resource-agents-3.9.3+git20121009/debian/changelog resource-agents-3.9.3+git20121009/debian/changelog
--- resource-agents-3.9.3+git20121009/debian/changelog 2012-11-22 11:19:32.0 +0100
+++ resource-agents-3.9.3+git20121009/debian/changelog 2014-02-21 09:02:44.0 +0100
@@ -1,3 +1,19 @@
+resource-agents (1:3.9.3+git20121009-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add 724116-fix-FTBFS.patch patch.
+Fixes resource-agents: FTBFS: /bin/bash: /install-sh: No such file or
+directory.
+Thanks to William Grant wgr...@ubuntu.com (Closes: #724116)
+ * Add 0001-Disable-HTTPS-SSL-certificate-hostname-checking-tidy.patch patch.
+Fixes ldirectord: fails to test HTTPS real servers. HTTPS checks with
+request/receive will fail under newer versions of the LWP module due to
+certificate name checking being enabled by default. This +disables the
+check again so that service checking by IP only still succeeds.
+(Closes: #739608)
+
+ -- Salvatore Bonaccorso car...@debian.org Thu, 20 Feb 2014 13:40:22 +0100
+
resource-agents (1:3.9.3+git20121009-3) unstable; urgency=low
* Fix the previous upload by including the proper patch this time.
diff -Nru resource-agents-3.9.3+git20121009/debian/patches/0001-Disable-HTTPS-SSL-certificate-hostname-checking-tidy.patch resource-agents-3.9.3+git20121009/debian/patches/0001-Disable-HTTPS-SSL-certificate-hostname-checking-tidy.patch
--- resource-agents-3.9.3+git20121009/debian/patches/0001-Disable-HTTPS-SSL-certificate-hostname-checking-tidy.patch 1970-01-01 01:00:00.0 +0100
+++ resource-agents-3.9.3+git20121009/debian/patches/0001-Disable-HTTPS-SSL-certificate-hostname-checking-tidy.patch 2014-02-21 09:02:44.0 +0100
@@ -0,0 +1,56 @@
+From 68fad38326b7c04efd6434e736e32fe395eafe02 Mon Sep 17 00:00:00 2001
+From: Matthew Newton m...@leicester.ac.uk
+Date: Fri, 11 Oct 2013 10:43:40 +0100
+Subject: [PATCH] Disable HTTPS SSL certificate hostname checking, tidy debug
+ output
+
+HTTPS checks with request/receive will fail under newer versions of the
+LWP module due to certificate name checking being enabled by default. This
+disables the check again so that service checking by IP only still succeeds.
+
+Additional debug output shows the Status line so that it is easier to find out
+why the service is down. Debug output tidied up when SSL values are not set
+(usually if there has been an error, or the host is unreachable).
+---
+ ldirectord/ldirectord.in | 16 +---
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+diff --git a/ldirectord/ldirectord.in b/ldirectord/ldirectord.in
+index 45a4204..6a46d97 100644
+--- a/ldirectord/ldirectord.in
b/ldirectord/ldirectord.in
+@@ -2835,7 +2835,7 @@ sub check_http
+ ld_debug(2, check_http: url=\$$r{url}\
+ . virtualhost=\$virtualhost\);
+
+- my $ua = new LWP::UserAgent();
++ my $ua = new LWP::UserAgent(ssl_opts = { verify_hostname = 0 });
+
+ my $h = undef;
+ if ($$v{service} eq http_proxy) {
+@@ -2876,14 +2876,16 @@ sub check_http
+ }
+
+ if ($$v{service} eq https) {
+- ld_debug(2, SSL-Cipher: .
+- $res-header('Client-SSL-Cipher'));
+- ld_debug(2, SSL-Cert-Subject: .
+- $res-header('Client-SSL-Cert-Subject'));
+- ld_debug(2, SSL-Cert-Issuer: .
+- $res-header('Client-SSL-Cert-Issuer'));
++ld_debug(2, SSL-Cipher: .
++($res-header('Client-SSL-Cipher') || 'not set'));
++ld_debug(2, SSL-Cert-Subject: .
++($res-header('Client-SSL-Cert-Subject') || 'not set'));
++ld_debug(2, SSL-Cert-Issuer: .
++($res-header('Client-SSL-Cert-Issuer') || 'not set'));
+ }
+
++ ld_debug(2, Return status: . $res-status_line);
++
+ my $recstr = $$r{receive};
+ if ($res-is_success (!($recstr =~ /.+/) ||
+ $res-content =~ /$recstr/)) {
+--
+1.9.0
+
diff -Nru resource-agents-3.9.3+git20121009/debian/patches/724116-fix-FTBFS.patch resource-agents-3.9.3+git20121009/debian/patches/724116-fix-FTBFS.patch
--- resource-agents-3.9.3+git20121009/debian/patches/724116-fix-FTBFS.patch 1970-01-01 01:00:00.0 +0100
+++ resource-agents-3.9.3+git20121009/debian/patches/724116-fix-FTBFS.patch 2014-02-21 09:02:44.0 +0100
@@ -0,0 +1,45 @@
+Description: Fix configure.ac to cope with new autoconf.
+ Recent autoconfs generate a bad configure when AM_INIT_AUTOMAKE is
+ called as late as it was, ending up thinking that the am_aux_dir is pwd
+ at the start of the build. Move it up to under AC_INIT to fix that.
+Author: William Grant wgr...@ubuntu.com
+
+Index: resource-agents-3.9.3+git20121009/configure.ac
Bug#739674: rpcbind: The rpcinfo -p command do not work on Debian Hurd
Package: rpcbind
Version: 0.2.1-3
File: /usr/sbin/rpcinfo
Severity: important
User: debian-h...@lists.debian.org
Usertags: hurd
After fixing libtirpc1 to build on Hurd (See
URL: http://bugs.debian.org/739557 for the patch), rpcbind also built
on hurd and the rpcbind daemon seem to work fine. At least I get a list
of services when connecting to it from a Linux machine:
% rpcinfo -p 192.168.122.17
program vers proto port
104 tcp111 portmapper
103 tcp111 portmapper
102 tcp111 portmapper
104 udp111 portmapper
103 udp111 portmapper
102 udp111 portmapper
%
But when running the rpcinfo command on the hurd machine itself, I get
this strange message instead:
root@hurdtest:~# rpcinfo -p 192.168.122.17
rpcinfo: can't contact portmapper: RPC: Success
root@hurdtest:~#
I find it very strange that the failure to contact portmapper is a
success. I'm not quite sure how to debug this, but this is the output
from rpctrace when running rpcinfo in case someone can make use of it:
root@hurdtest:~# rpctrace rpcinfo -p 192.168.122.17
task131(pid343)-vm_statistics () = 0 {4096 145161 40016 58893 13317 15643031 0
711059 560724 63163388 5838046 4400346 4313297}
task131(pid343)-vm_region (134217728) = 0 134512640 24576 5 7 1 0
138--135(pid343) 0
task131(pid343)-mach_port_deallocate (pn{ 3}) = 0
task131(pid343)-vm_region (134537216) = 0 134537216 4096 3 7 1 0
138--139(pid343) 20480
task131(pid343)-mach_port_deallocate (pn{ 3}) = 0
task131(pid343)-vm_region (134541312) = 0 134541312 4096 3 7 1 0
138--135(pid343) 0
task131(pid343)-mach_port_deallocate (pn{ 3}) = 0
task131(pid343)-vm_region (134545408) = 0x3 ((os/kern) no space available)
task131(pid343)-vm_map (134545408 2012938240 0 0 (null) 0 1 0 0 1) = 0
134545408
task131(pid343)-vm_map (0 4096 0 0 (null) 0 1 0 0 1) = 0 0
task131(pid343)-task_get_special_port (4) = 0138--139(pid343)
138--139(pid343)-exec_startup_get_info () = 0 134520926 134512692 288
172032 16777216 0 rpcinfo TERM=xterm { 90--135(pid343)
107--141(pid343) 83--142(pid343)} { 111--143(pid343) 109--144(pid343)
104--145(pid343) 140--146(pid343) 113--147(pid343) (null)} {18 0 0 0 0}
task131(pid343)-mach_port_deallocate (pn{ 3}) = 0
task131(pid343)-vm_deallocate (134545408 2012938240) = 0
task131(pid343)-vm_map (0 4096 0 1 (null) 0 0 3 7 1) = 0 16969728
109--144(pid343)-dir_lookup (etc/ld.so.cache 1 0) = 0 1
138--148(pid343)
138--148(pid343)-io_stat_request () = 0 {23 5 0 63033 0 1393029071 0 33188
1 0 0 33247 0 1392970123 0 1392970123 0 1392970123 0 8192 72 0 0 0 0 1392967406
0 8192 8 0 0 0}
138--148(pid343)-io_map_request () = 0149--139(pid343) (null)
task131(pid343)-mach_port_deallocate (pn{ 0}) = 0xf ((os/kern) invalid name)
task131(pid343)-vm_map (0 33247 0 1149--139(pid343) 0 32 1 7 1) = 0
16973824
task131(pid343)-mach_port_deallocate (pn{ 12}) = 0
task131(pid343)-mach_port_deallocate (pn{ 3}) = 0
109--144(pid343)-dir_lookup (lib/i386-gnu/libtirpc.so.1 1 0) = 0 1
138--150(pid343)
138--150(pid343)-io_read_request (-1 512) = 0 \x7fELF\x01\x01\x01
138--150(pid343)-io_stat_request () = 0 {23 5 0 119632 0 1393028797 0 33188
1 0 0 151024 0 1392970381 0 1392934752 0 1392970105 0 8192 304 0 0 0 0 0 0 0 0
0 0 0}
138--150(pid343)-io_map_request () = 0149--148(pid343) (null)
task131(pid343)-mach_port_deallocate (pn{ 0}) = 0xf ((os/kern) invalid name)
task131(pid343)-vm_map (0 151088 0 1149--148(pid343) 0 32 5 7 1) = 0
17010688
task131(pid343)-mach_port_deallocate (pn{ 12}) = 0
138--150(pid343)-io_map_request () = 0149--139(pid343) (null)
task131(pid343)-mach_port_deallocate (pn{ 0}) = 0xf ((os/kern) invalid name)
task131(pid343)-vm_map (17158144 4096 0 0149--139(pid343) 147456 32 3 7
1) = 0x3 ((os/kern) no space available)
task131(pid343)-vm_deallocate (17158144 4096) = 0
task131(pid343)-vm_map (17158144 4096 0 0149--139(pid343) 147456 32 3 7
1) = 0 17158144
task131(pid343)-mach_port_deallocate (pn{ 12}) = 0
task131(pid343)-mach_port_deallocate (pn{ 3}) = 0
109--144(pid343)-dir_lookup (lib/i386-gnu/libpthread.so.0.3 1 0) = 0 1
138--148(pid343)
138--148(pid343)-io_read_request (-1 512) = 0 \x7fELF\x01\x01\x01
138--148(pid343)-io_stat_request () = 0 {23 5 0 118256 0 1392806593 0 33261
1 0 0 76701 0 1392970381 0 1391991005 0 1392763294 0 8192 160 0 0 0 0 0 0 0 0 0
0 0}
138--148(pid343)-io_map_request () = 0149--150(pid343) (null)
task131(pid343)-mach_port_deallocate (pn{ 0}) = 0xf ((os/kern) invalid name)
task131(pid343)-vm_map (0 61984 0 1149--150(pid343) 0 32 5 7 1) = 0
17162240
task131(pid343)-mach_port_deallocate (pn{ 12}) = 0
138--148(pid343)-io_map_request () = 0149--139(pid343) (null)
task131(pid343)-mach_port_deallocate (pn{ 0}) = 0xf ((os/kern) invalid name)
task131(pid343)-vm_map (17219584 8192 0 0
Bug#739675: autofs: failed NIS-lookup seems to be cached forever
Package: autofs Version: 5.0.7-3 Severity: normal Hi! Problem description: autofs is configured to read an auto.home map from NIS. The NIS-server was down when the client booted. Then the NIS-server was restored. = automount fails to mount everything from auto.home, forever. It seems to cache the negative NIS-lookup forever. Restart of autofs solved the problem. This problem is similar to bug #597304 and bug #710490 . / Anders -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (300, 'proposed-updates'), (90, 'testing'), (70, 'testing-proposed-updates'), (60, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to sv_SE.UTF8) Shell: /bin/sh linked to /bin/dash Versions of packages autofs depends on: ii libc6 2.13-38+deb7u1 ii libxml22.8.0+dfsg1-7+nmu2 ii multiarch-support 2.13-38+deb7u1 ii ucf3.0025+nmu3 Versions of packages autofs recommends: ii kmod 9-3 ii module-init-tools 9-3 ii nfs-common 1:1.2.6-4 autofs suggests no packages. -- debconf information: * autofs/upgrade-from-broken-version: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738946: [DSE-Dev] Bug#738946: selinux-policy-default: Bind's ndc_t denied block_suspend on epollwakeup
This is possibly being triggered by an inherent quirk of ISC's libraries;
since host(1) triggers it too, even from unconfined_t:
type=AVC msg=audit(1392969683.579:1590): avc: denied { block_suspend } for
pid=14446 comm=host capability=36
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=capability2
--
Devin \ aqua(at)devin.com, IRC:Requiem; http://www.devin.com
Carraway \ 4096R/9197B5F9: 9C64 37CD 1B7B 029D 0933 49EA 1E52 7672 9197 B5F9
signature.asc
Description: Digital signature
Bug#739676: libpam-mount: Does not unmount encrypted home directory when logging out with lightdm
Package: libpam-mount Version: 2.14-1 Severity: important Dear Maintainer, On a brand-new debian installation, I modified /etc/security/pam_mount.conf.xml to automatically mount a luks-encrypted home partition when I logged in. However, when I tested this out, I found that it worked properly when i logged into the virtual terminal (CTRL ALT F1), but when I logged into xfce using lightdm, it would properly mount my home directory, but failed to unmount it when I logged out. This is a security issue, as it leaves encrypted drives vulnerable. The /var/log/auth log indicates that it still thinks I have an open session when I log out. Here is the relevant section Feb 21 01:48:47 jeremy-laptop lightdm: pam_unix(lightdm:session): session closed for user jeremy Feb 21 01:48:47 jeremy-laptop lightdm: (pam_mount.c:706): received order to close things Feb 21 01:48:47 jeremy-laptop lightdm: command: 'pmvarrun' '-u' 'jeremy' '-o' '-1' Feb 21 01:48:47 jeremy-laptop lightdm: (pam_mount.c:441): pmvarrun says login count is 1 Feb 21 01:48:47 jeremy-laptop lightdm: (pam_mount.c:735): jeremy seems to have other remaining open sessions Feb 21 01:48:47 jeremy-laptop lightdm: (pam_mount.c:743): pam_mount execution complete Feb 21 01:48:47 jeremy-laptop lightdm: (pam_mount.c:116): Clean global config (0) Feb 21 01:48:47 jeremy-laptop lightdm: (pam_mount.c:133): clean system authtok=0x7fda75bba760 (0) Feb 21 01:48:47 jeremy-laptop polkitd(authority=local): Unregistered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session6 (system bus name :1.40, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.utf8) (disconnected from bus) -- 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/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpam-mount depends on: ii base-files 7.2 ii libc6 2.17-97 ii libcryptsetup4 2:1.6.1-1 ii libhx28 3.18-1 ii libmount1 2.20.1-5.6 ii libpam-runtime 1.1.8-2 ii libpam0g1.1.8-2 ii libpcre31:8.31-2 ii libssl1.0.0 1.0.1f-1 ii libxml2 2.9.1+dfsg1-3 ii mount 2.20.1-5.6 libpam-mount recommends no packages. Versions of packages libpam-mount suggests: pn cifs-utils none pn davfs2 none ii fuse2.9.2-4 ii lsof4.86+dfsg-1 pn ncpfs none ii openssl 1.0.1f-1 ii psmisc 22.20-1 pn sshfs none pn tc-utilsnone pn xfsprogsnone -- Configuration Files: /etc/security/pam_mount.conf.xml changed: ?xml version=1.0 encoding=utf-8 ? !DOCTYPE pam_mount SYSTEM pam_mount.conf.xml.dtd !-- See pam_mount.conf(5) for a description. -- pam_mount !-- debug should come before everything else, since this file is still processed in a single pass from top-to-bottom -- debug enable=2 / !-- Volume definitions -- volume user=jeremy fstype=auto path=/dev/disk/by-uuid/fc77339f-a9b8-4048-a93e-ff9d7f9b7440 mountpoint=/home options=fsck,noatime / !-- pam_mount parameters: General tunables -- !-- luserconf name=.pam_mount.conf.xml / -- !-- Note that commenting out mntoptions will give you the defaults. You will need to explicitly initialize it with the empty string to reset the defaults to nothing. -- mntoptions allow=nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other / !-- mntoptions deny=suid,dev / mntoptions allow=* / mntoptions deny=* / -- mntoptions require=nosuid,nodev / logout wait=2000 hup=0 term=1 kill=1 / !-- pam_mount parameters: Volume-related -- mkmountpoint enable=1 remove=true / /pam_mount -- 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#704283: Hurd: fix calculation of elapsed time
Hi. Any change to have time fixed on hurd in Jessie? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718981: Review of your ruby-colorator package
On Thursday 20 February 2014 16:07:08 Dominique Dumont wrote: * fix debian/watch file: this file points to alioth even though upstream is on github. My bad. I was wrong about this point. I'll fix copyright file and resume review -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739489: spamassassin: Failed to update
Il gio, feb 20, 2014 at 10:18:47 +0100, To Noah Meyerhans scrisse: [cut] and no more errors! /var/cache/apt/archives -su # /etc/init.d/amavis status [ ok ] amavisd is running. gio feb 20 09:51:32 @hpdv5: /var/cache/apt/archives -su # /etc/init.d/spamassassin status [ ok ] spamd is running. gio feb 20 09:51:44 @hpdv5: Please, don't ask me why ... :) Maybe before have I tried to update spamassassin and spamc but now only spamassassin (spamc has been updated yesterday)? [cut] No luck... This morning spamassassin and thus amavis haven't started at boot. Some logs ~ -su # /etc/init.d/spamassassin status [FAIL] spamd is not running ... failed! ven feb 21 09:11:51 @hpdv5: ~ -su # /etc/init.d/spamassassin start Starting SpamAssassin Mail Filter Daemon: child process [22102] exited or timed out without signaling production of a PID file: exit 255 at /usr/sbin/spamd line 2960. ven feb 21 09:12:01 @hpdv5: ~ -su # spamd -D Feb 21 09:12:22.704 [22110] dbg: logger: adding facilities: all Feb 21 09:12:22.704 [22110] dbg: logger: logging level is DBG Feb 21 09:12:22.717 [22110] dbg: logger: calling setlogsock(unix) Feb 21 09:12:22.717 [22110] dbg: logger: opening syslog with unix socket Feb 21 09:12:22.717 [22110] dbg: logger: successfully connected to syslog/unix Feb 21 09:12:22.717 [22110] dbg: logger: successfully added syslog method Feb 21 09:12:22.717 [22110] dbg: spamd: will perform setuids? 1 Feb 21 09:12:22.718 [22110] dbg: spamd: socket module of choice: IO::Socket::INET6 2.71, Socket 2.009, have PF_INET, have PF_INET6, using Socket::getaddrinfo, AI_ADDRCONFIG is supported Feb 21 09:12:22.718 [22110] dbg: spamd: socket specification: localhost, IP address: localhost, port: 783 Feb 21 09:12:22.718 [22110] dbg: spamd: attempting to listen on IP addresses: 127.0.0.1, ::1, port 783 Feb 21 09:12:22.718 [22110] dbg: spamd: creating IO::Socket::INET6 socket: Listen: 128, LocalAddr: 127.0.0.1, LocalPort: 783, Proto: tcp, ReuseAddr: 1, Type: 1 Feb 21 09:12:22.719 [22110] dbg: spamd: creating IO::Socket::INET6 socket: Listen: 128, LocalAddr: ::1, LocalPort: 783, Proto: tcp, ReuseAddr: 1, Type: 1 Feb 21 09:12:22.719 [22110] dbg: spamd: server listen sockets fd bit field: 0110 Feb 21 09:12:22.719 [22110] dbg: logger: adding facilities: all Feb 21 09:12:22.720 [22110] dbg: logger: logging level is DBG Feb 21 09:12:22.720 [22110] dbg: generic: SpamAssassin version 3.4.0 Feb 21 09:12:22.720 [22110] dbg: generic: Perl 5.018002, PREFIX=/usr, DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/etc/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin Feb 21 09:12:22.720 [22110] dbg: config: timing enabled Feb 21 09:12:22.721 [22110] dbg: config: score set 0 chosen. Feb 21 09:12:22.728 [22110] dbg: spamd: Preloading modules with HOME=/tmp/spamd-22110-init Feb 21 09:12:22.729 [22110] dbg: config: using /etc/spamassassin for site rules pre files Feb 21 09:12:22.729 [22110] dbg: config: read file /etc/spamassassin/init.pre Feb 21 09:12:22.729 [22110] dbg: config: read file /etc/spamassassin/sa-compile.pre Feb 21 09:12:22.729 [22110] dbg: config: read file /etc/spamassassin/v310.pre Feb 21 09:12:22.730 [22110] dbg: config: read file /etc/spamassassin/v312.pre Feb 21 09:12:22.730 [22110] dbg: config: read file /etc/spamassassin/v320.pre Feb 21 09:12:22.730 [22110] dbg: config: read file /etc/spamassassin/v330.pre Feb 21 09:12:22.730 [22110] dbg: config: read file /etc/spamassassin/v340.pre Feb 21 09:12:22.731 [22110] dbg: config: using /var/lib/spamassassin/3.004000 for sys rules pre files Feb 21 09:12:22.731 [22110] dbg: config: using /var/lib/spamassassin/3.004000 for default rules dir Feb 21 09:12:22.731 [22110] error: config: no rules were found! Do you need to run 'sa-update'? config: no rules were found! Do you need to run 'sa-update'? ven feb 21 09:12:22 @hpdv5: From /var/log/mail.log [...] Feb 21 08:56:04 hpdv5 amavis[5010]: (!!)TROUBLE in pre_loop_hook: config: no rules were found! Do you need to run 'sa-update'? Feb 21 08:56:04 hpdv5 amavis[5010]: (!)_DIE: Suicide () TROUBLE in pre_loop_hook: config: no rules were found! Do you need to run 'sa-update'? Feb 21 08:57:04 hpdv5 spamd[8226]: logger: removing stderr method Feb 21 08:57:07 hpdv5 spamd[8257]: config: no rules were found! Do you need to run 'sa-update'? Feb 21 08:57:07 hpdv5 spamd[8226]: child process [8257] exited or timed out without signaling production of a PID file: exit 255 at /usr/sbin/spamd line 2960. [...] Feb 21 09:12:00 hpdv5 spamd[22100]: logger: removing stderr method Feb 21 09:12:00 hpdv5 spamd[22102]: config: no rules were found! Do you need to run 'sa-update'? Feb 21 09:12:01 hpdv5 spamd[22100]: child process [22102] exited or timed out without signaling production of a PID file: exit 255 at /usr/sbin/spamd line 2960. Feb 21 09:12:22 hpdv5 spamd[22110]: logger: successfully added syslog method Feb 21 09:12:22 hpdv5 spamd[22110]: spamd: will perform setuids? 1 Feb 21 09:12:22 hpdv5 spamd[22110]: spamd:
Bug#562906: mklibs: fails on libc on hurd-i386
[Samuel Thibault 2009-12-29] On hurd-i386, when applying mklibs on libc, link fails with /usr/lib//libc_pic.a(dtable.os): In function `init_dtable': (.text+0x192): undefined reference to `__start__hurd_fd_subinit' This is due to the DEFINE_HOOK() mecanism that uses symbols which only eventually get defined in the shlib.lds script. Linux kfreebsd are lucky that d-i seemingly never uses atexit and thus doesn't need it, but hurd-i386 does. How can this issue be reproduced? I tried, but failed: # mkdir foo; mklibs -d foo /bin/ls I: Using /lib/ld.so as dynamic linker. I: library reduction pass 1 108 symbols, 108 unresolved I: library reduction pass 2 291 symbols, 178 unresolved I: library reduction pass 3 325 symbols, 9 unresolved I: library reduction pass 4 325 symbols, 9 unresolved # ls foo/ ld.so.1 libc.so.0.3 libhurduser.so.0.3 libmachuser.so.1 # Is the issue fixed, or is something else needed to reproduce it? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739677: ITP: trac-navadd -- Add custom items to main and meta navigation bar in Trac web application
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor d...@fifthhorseman.net * Package name: trac-navadd Version : 0.3 Upstream Author : Ryan J. Ollos ryan.j.ol...@gmail.com * URL : https://trac-hacks.org/wiki/NavAddPlugin * License : BSD Programming Lang: Python Description : Add custom items to main and meta navigation bar in Trac webapp This plugin allows customization of the Trac web application's navigation bars by adding custom links, either to main or meta navbars. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739614: Fwd: Re: Bug#739614: [apache2] unable to execute apache2
Original Message From: marco.ri...@gmail.com Fri Feb 21 09:50:06 2014 Return-Path: marco.ri...@gmail.com X-Original-To: deb...@toell.net Delivered-To: deb...@toell.net Received: by smart.knallkopp.de (Postfix, from userid 6061) id 5362C16419A; Fri, 21 Feb 2014 09:50:06 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on smart.knallkopp.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=disabled version=3.3.2 X-policyd-weight: using cached result; rate: -5.5 Received: from muffat.debian.org (muffat.debian.org [206.12.19.146]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smart.knallkopp.de (Postfix) with ESMTPS id B18AD164178 for deb...@toell.net; Fri, 21 Feb 2014 09:50:00 +0100 (CET) Received: from mail-ee0-x22a.google.com ([2a00:1450:4013:c00::22a]) by muffat.debian.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from marco.ri...@gmail.com) id 1WGlny-0002UE-Jp for deb...@toell.net; Fri, 21 Feb 2014 08:49:59 + Received: by mail-ee0-f42.google.com with SMTP id b15so1451736eek.1 for a...@debian.org; Fri, 21 Feb 2014 00:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MnCfXMdLIR8yfrFpVOsC73jng1WPi2xW1MQ0+AGzT2Y=; b=FlCUSqX90YmXIVCaTpes6szFuydunoaEmZTyIBe0w06rBj/p7fqTiFz+f6+pdtFyGs asQeTAIph/zaIR5F/aFZM222ZWkWJvPotko/1KECj9cvzCLZmi76dIxwZOWBOVKFML2Z +OzdQ6GnV+Yepph4qALDfwhnJzMapwbnHu+TLKKBU9bw6Y57kRK8falB0QI7eRr8VAms SFFomsT1rM0BHI+NztKIoQReas4eyEu7Zb6ORDTG5uCK3OS5ZaRftDcz1WH0xUFcx0EW zdCH0cyZGn3nxKW6QdXLwH05DL+bZJ1pF1zJf9wKUpjxlpDnu3k7mcg+svOWQZrr2kvt IFMw== X-Received: by 10.14.175.2 with SMTP id y2mr6817847eel.75.1392972590781; Fri, 21 Feb 2014 00:49:50 -0800 (PST) Received: from [146.48.81.142] (pc-thesaurus1.isti.cnr.it. [146.48.81.142])by mx.google.com with ESMTPSA id 46sm24014582ees.4.2014.02.21.00.49.50for a...@debian.org (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);Fri, 21 Feb 2014 00:49:50 -0800 (PST) Message-ID: 5307132d.8030...@gmail.com Date: Fri, 21 Feb 2014 09:49:49 +0100 From: Marco Righi marco.ri...@gmail.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Arno Töll a...@debian.org Subject: Re: Bug#739614: [apache2] unable to execute apache2 References: 53060663.7050...@gmail.com 5306157d.6020...@debian.org In-Reply-To: 5306157d.6020...@debian.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit apachectl start Command 593 of 97 #apachectl start sh: 0: getcwd() failed: No such file or directory AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 2a00:1620:c0:50:f66d:4ff:fe74:f12c. Set the 'ServerName' directive globally to suppress this message (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80 (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down AH00015: Unable to open logs Action 'start' failed. The Apache error log may have more information. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703575: asciidoc: Broken rendering of URLs which contain e-mail addresses == Answer
Dear Alex, Please find bellow the upstream answer: -- This is normal macro behaviour. Macros can nest, so after processing the http:... macro, the bare email address is recognised and replaced as well. Basically allowing bare email addresses to be recognised is fragile, it might have been better not to recognise them, or to implement it another way. But thats hindsight :) The backslash goes before the whole macro (not something inside it like the @) to prevent recognition, usually thats the xxx: but for emails again its dependent on what it recognised. Again bare emails are fragile :( But http://example.org/?l=\exam...@example.com works ok. Or your %40 can also be used. -- If that answer to your question, please close the bug report. Thanks in advance, Joseph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738607: developers-reference: Change contact preferences to the security-team in 5.8.5.
On Tue, 11 Feb 2014, Salvatore Bonaccorso wrote: At the Security team sprint meeting in Essen we concluded that working trough the request tracker does not fit well with our workflows when handling issues. We would thus like to change the paragraph on how to contact the security-team in the developers-reference in paragraph 5.8.5. The change consist to make the email contact the only point of contact removing the reference to the Request Tracker. Attached patch addresses this, could you apply it for your next update of the dev-ref? Thanks, applied in svn. 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#739678: wheezy-pu: package resource-agents/1:3.9.2-5+deb7u2
Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu
[Martin Loschwitz madk...@debian.org (CC'ed via X-Debbugs-CC), as
this my request is quite short timeframe between firstly opening the
bugreport and aksing for also a pu]
When migrating from Squeeze to Wheezy, using ldirectord fails to test
HTTPS real servers due to LWP::UserAgent's hostname_verification
beeing enabled by default (from Wheezy on).
This is reported in the BTS as https://bugs.debian.org/739608
As there was also a longerstanding RC bug #724116 I have uploaded a
NMU (to delayed/5 queue!) also fixing #739608 to unstable, but has not
entered the archive yet.
The fix takes upstream commit, which disables hostname verification
again, allowing checking by IP only again.
Attached is proposed debdiff for wheezy. Could it be included for the
next wheezy point release?
Regards,
Salvatore
diff -Nru resource-agents-3.9.2/debian/changelog resource-agents-3.9.2/debian/changelog
--- resource-agents-3.9.2/debian/changelog 2013-01-06 23:49:52.0 +0100
+++ resource-agents-3.9.2/debian/changelog 2014-02-21 10:35:08.0 +0100
@@ -1,3 +1,15 @@
+resource-agents (1:3.9.2-5+deb7u2) wheezy; urgency=medium
+
+ * Non-maintainer upload.
+ * Add 0001-Disable-HTTPS-SSL-certificate-hostname-checking-tidy.patch patch.
+Fixes ldirectord: fails to test HTTPS real servers. HTTPS checks with
+request/receive will fail under newer versions of the LWP module due to
+certificate name checking being enabled by default. This disables the
+check again so that service checking by IP only still succeeds.
+(Closes: #739608)
+
+ -- Salvatore Bonaccorso car...@debian.org Fri, 21 Feb 2014 10:33:52 +0100
+
resource-agents (1:3.9.2-5+deb7u1) testing-proposed-updates; urgency=low
* Non-maintainer upload.
diff -Nru resource-agents-3.9.2/debian/patches/0001-Disable-HTTPS-SSL-certificate-hostname-checking-tidy.patch resource-agents-3.9.2/debian/patches/0001-Disable-HTTPS-SSL-certificate-hostname-checking-tidy.patch
--- resource-agents-3.9.2/debian/patches/0001-Disable-HTTPS-SSL-certificate-hostname-checking-tidy.patch 1970-01-01 01:00:00.0 +0100
+++ resource-agents-3.9.2/debian/patches/0001-Disable-HTTPS-SSL-certificate-hostname-checking-tidy.patch 2014-02-21 10:35:08.0 +0100
@@ -0,0 +1,51 @@
+From 68fad38326b7c04efd6434e736e32fe395eafe02 Mon Sep 17 00:00:00 2001
+From: Matthew Newton m...@leicester.ac.uk
+Date: Fri, 11 Oct 2013 10:43:40 +0100
+Subject: [PATCH] Disable HTTPS SSL certificate hostname checking, tidy debug
+ output
+
+HTTPS checks with request/receive will fail under newer versions of the
+LWP module due to certificate name checking being enabled by default. This
+disables the check again so that service checking by IP only still succeeds.
+
+Additional debug output shows the Status line so that it is easier to find out
+why the service is down. Debug output tidied up when SSL values are not set
+(usually if there has been an error, or the host is unreachable).
+---
+ ldirectord/ldirectord.in | 16 +---
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+--- a/ldirectord/ldirectord.in
b/ldirectord/ldirectord.in
+@@ -2816,7 +2816,7 @@
+ ld_debug(2, check_http: url=\$$r{url}\
+ . virtualhost=\$virtualhost\);
+
+- my $ua = new LWP::UserAgent();
++ my $ua = new LWP::UserAgent(ssl_opts = { verify_hostname = 0 });
+
+ my $h = undef;
+ if ($$v{service} eq http_proxy) {
+@@ -2857,14 +2857,16 @@
+ }
+
+ if ($$v{service} eq https) {
+- ld_debug(2, SSL-Cipher: .
+- $res-header('Client-SSL-Cipher'));
+- ld_debug(2, SSL-Cert-Subject: .
+- $res-header('Client-SSL-Cert-Subject'));
+- ld_debug(2, SSL-Cert-Issuer: .
+- $res-header('Client-SSL-Cert-Issuer'));
++ld_debug(2, SSL-Cipher: .
++($res-header('Client-SSL-Cipher') || 'not set'));
++ld_debug(2, SSL-Cert-Subject: .
++($res-header('Client-SSL-Cert-Subject') || 'not set'));
++ld_debug(2, SSL-Cert-Issuer: .
++($res-header('Client-SSL-Cert-Issuer') || 'not set'));
+ }
+
++ ld_debug(2, Return status: . $res-status_line);
++
+ my $recstr = $$r{receive};
+ if ($res-is_success (!($recstr =~ /.+/) ||
+ $res-content =~ /$recstr/)) {
diff -Nru resource-agents-3.9.2/debian/patches/series resource-agents-3.9.2/debian/patches/series
--- resource-agents-3.9.2/debian/patches/series 2013-01-02 04:35:00.0 +0100
+++ resource-agents-3.9.2/debian/patches/series 2014-02-21 10:35:08.0 +0100
@@ -3,3 +3,4 @@
CVE-2010-3389--bug598549.patch
mysql-path.patch
fix-gethostinfo-v2.patch
+0001-Disable-HTTPS-SSL-certificate-hostname-checking-tidy.patch
Bug#739679: systemd: probably shouldn't be co-installable with file-rc
Package: systemd Version: 204-7 Severity: normal systemd Depends: initscripts, which Depends: sysv-rc|file-rc. However, sysv-rc's update-rc.d and invoke-rc.d have specific support for systemd (and Upstart), whereas I doubt file-rc's versions have that. Upstart has an explicit dependency on sysv-rc; perhaps systemd (or at least systemd-sysv) should do the same. The other possibility is for update-rc.d and invoke-rc.d to move to sysvinit-utils or init-system-helpers, which would mean file-rc would need to switch to using diversions or something, at which point systemd and Upstart should probably declare Conflicts or Breaks on it. S -- System Information: Debian Release: jessie/sid APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 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-51 ii libacl1 2.2.52-1 ii libaudit11:2.3.3-4 ii libc62.17-97 ii libcap2 1:2.22-1.2 ii libcryptsetup4 2:1.6.1-1 ii libdbus-1-3 1.8.0-1 ii libgcrypt11 1.5.3-3 ii libkmod2 16-2 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.8-2 ii libselinux1 2.2.2-1 ii libsystemd-daemon0 204-7 ii libsystemd-journal0 204-7 ii libsystemd-login0204-7 ii libudev1 204-7 ii libwrap0 7.6.q-25 ii udev 204-7 ii util-linux 2.20.1-5.6 Versions of packages systemd recommends: ii libpam-systemd 204-7 Versions of packages systemd suggests: ii systemd-ui 3-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736712: apt-listchanges: dpkg-architecture: warning: couldn't type, falling back to default (native compilation)
Package: apt-listchanges Version: 2.85.13 Followup-For: Bug #736712 I see this problem too, on two machine on which gcc is not installed, because i don't need it. The couldn't determine gcc system type message is displayed for every package you are about to install. For example: 12 packages, 12 warning messages. If you launch dpkg-architecture alone, you'll get the same message on the first line of the output: --- # dpkg-architecture sh: gcc: command not found dpkg-architecture: warning: couldn't determine gcc system type, falling back to default (native compilation) DEB_BUILD_ARCH=i386 DEB_BUILD_ARCH_BITS=32 DEB_BUILD_ARCH_CPU=i386 DEB_BUILD_ARCH_ENDIAN=little DEB_BUILD_ARCH_OS=linux DEB_BUILD_GNU_CPU=i486 DEB_BUILD_GNU_SYSTEM=linux-gnu DEB_BUILD_GNU_TYPE=i486-linux-gnu DEB_BUILD_MULTIARCH=i386-linux-gnu DEB_HOST_ARCH=i386 DEB_HOST_ARCH_BITS=32 DEB_HOST_ARCH_CPU=i386 DEB_HOST_ARCH_ENDIAN=little DEB_HOST_ARCH_OS=linux DEB_HOST_GNU_CPU=i486 DEB_HOST_GNU_SYSTEM=linux-gnu DEB_HOST_GNU_TYPE=i486-linux-gnu DEB_HOST_MULTIARCH=i386-linux-gnu --- So looks like this bug should be redirected to dpkg-dev. Cesare. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.13-trunk-486 Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages apt-listchanges depends on: ii apt0.9.15.3 ii debconf [debconf-2.0] 1.5.52 ii debianutils4.4 ii dpkg-dev 1.17.6 ii python 2.7.5-5 ii python-apt 0.9.2 ii python-support 1.0.15 ii ucf3.0027+nmu1 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii chromium [www-browser]32.0.1700.123-1 ii gnome-terminal [x-terminal-emulator] 3.10.1-1 ii iceweasel [www-browser] 24.3.0esr-1 ii lynx-cur [www-browser]2.8.8pre5-1 ii midori [www-browser] 0.4.3+dfsg-0.1 ii postfix [mail-transport-agent]2.11.0-1 ii python-glade2 2.24.0-3+b1 ii python-gtk2 2.24.0-3+b1 ii w3m [www-browser] 0.5.3-15 ii xfce4-terminal [x-terminal-emulator] 0.6.3-1 ii xterm [x-terminal-emulator] 301-1 -- debconf information: * apt-listchanges/frontend: pager apt-listchanges/confirm: false apt-listchanges/which: news apt-listchanges/email-address: root apt-listchanges/save-seen: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738326: live-build installs extra packages (suggests or based on source package instead of binary)
On Thursday 20 February 2014 20:23:17 Daniel Dickinson wrote: I still suspect a bug because NONE of the Recommends on or Depends packages for gnuplot are shown as being installed Maybe I'm overlooking something, but have you started/booted your image and then did an aptitude why gnuplot ? It should tell you why gnuplot is/was installed. -- GPG: 0x138E41915C7EFED6 signature.asc Description: This is a digitally signed message part.
Bug#619244: /etc/machine-id
On Sun, 21 Jul 2013 at 13:23:48 +0200, Michael Stapelberg wrote: Programs may use this ID to identify the host with a globally unique ID in the network, which does not change even if the local network configuration changes. Due to this and its greater length, it is a more useful replacement for the gethostid(3) call that POSIX specifies. I've wondered whether to ask base-files or some similarly core package to provide /etc/machine-id so that it exists even on non-systemd systems; it would be easy to populate from something like sed s/-// /proc/sys/kernel/random/uuid on Linux, and perhaps /dev/[u]random on non-Linux. Do you think that's a good idea? It would have the side-effect of resolving this bug. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739680: [synaptic] sh: 0: getcwd() failed: No such file or directory
Package: synaptic Version: 0.80.4 Severity: normal --- Please enter the report below this line. --- --- System information. --- Architecture: amd64 Kernel: Linux 3.12-1-amd64 Debian Release: jessie/sid 500 testing-updates ftp.it.debian.org 500 testing www.deb-multimedia.org 500 testing security.debian.org 500 testing ftp.it.debian.org 500 testing apt.jenslody.de 500 stable repo.wuala.com 500 stable apt.spideroak.com 500 sid linux.dropbox.com 500 debian packages.linuxmint.com 100 jessie-backports ftp.it.debian.org --- Package information. --- Depends (Version) | Installed =-+-== libapt-inst1.5 (= 0.8.16~exp12) | 0.9.15.2 libapt-pkg4.12 (= 0.9.11.3) | 0.9.15.2 libatk1.0-0 (= 1.12.4) | libc6 (= 2.14) | libcairo-gobject2 (= 1.10.0) | libcairo2 (= 1.2.4) | libept1.4.12 (= 1.0.9) | libgcc1 (= 1:4.1.1) | libgdk-pixbuf2.0-0(= 2.22.0) | libglib2.0-0 (= 2.16.0) | libgtk-3-0 (= 3.0.0) | libpango-1.0-0(= 1.14.0) | libpangocairo-1.0-0 (= 1.14.0) | libstdc++6 (= 4.6) | libvte-2.90-9 (= 1:0.27.2) | libx11-6 | libxapian22 | libxext6 | zlib1g (= 1:1.1.4) | hicolor-icon-theme| Recommends (Version) | Installed ==-+-= gksu | 2.0.2-6 OR kdebase-bin| 4:4.11.3-1 OR policykit-1| 0.105-4 libgtk2-perl (= 1:1.130) | 2:1.249-1 rarian-compat | 0.8.1-5 Suggests (Version) | Installed ==-+-=== dwww | menu | 2.1.46 deborphan | 1.7.28.8 apt-xapian-index | 0.46 tasksel| 3.20 software-properties-gtk| 0.92.25debian1 -- Think Marco, think different web site:http://www.di.unipi.it/~righi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739634: dpkg-maintscript-helper supports always returns 1
On 20/02/14 21:38, Guillem Jover wrote: Hi! On Thu, 2014-02-20 at 18:23:59 +0100, Eugen Dedu wrote: Package: dpkg Version: 1.17.6 Severity: normal I need to use dir_to_symlink and see in 'man dpkg-maintscript-helper': [...] we can call the program only if we know that the required command is supported by the currently installed dpkg: if dpkg-maintscript-helper supports command; then dpkg-maintscript-helper command ... fi On my computer dpkg-maintscript-helper supports always returns 1: snoopy:~$ dpkg-maintscript-helper supports dir_to_symlink; echo $? dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_NAME missing dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing 1 snoopy:~$ dpkg-maintscript-helper supports fasdfa; echo $? dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_NAME missing dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing 1 snoopy:~$ dpkg-maintscript-helper supports xyz; echo $? dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_NAME missing dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing 1 Tha's because the mentioned variables are not defined in the environment, as dpkg does. Check this instead: $ env DPKG_MAINTSCRIPT_NAME=postinst DPKG_MAINTSCRIPT_PACKAGE=pkg \ dpkg-maintscript-helper supports dir_to_symlink $ echo $? 0 I'm thus closing this bug report. May I suggest to add this information on the man page? I think it is not evident to see that the program might give different results depending on the environment variables. (By the way, I myself do not see why it gives different results.) -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739681: qa.debian.org: Debian Maintainer Dashboard: out-of-date data in the VCS column
Package: qa.debian.org Severity: normal User: qa.debian@packages.debian.org Usertags: udd Hi, since a few months (possibly more), the VCS column on my dashboard page has been displaying outdated information. E.g. it believes that the VCS for libtest-bdd-cucumber-perl only has 0.15-1 Ready for upload to unstable, while it really has 0.17-1, just like the testing/sid archive. Thanks for the DMD! :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736427: [bug #41331] spurious errors if some files in the cert directory are not certificates
Follow-up Comment #1, bug #41331 (project wget): I'm unable to reproduce this bug on the current git HEAD and on the v1.15 tag. I set up my wgetrc file to have a ca_directory which has one cert file and a bunch of other random text files. Trying to download an https page gave me no spurious error messages at all. ___ Reply to this item at: http://savannah.gnu.org/bugs/?41331 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739683: simple-scan should honour page size settings and remember page crop setting
Package: simple-scan Version: 3.10.0-1 Severity: normal Dear Maintainer, In the settings dialogue I have set page size to A4. In spite of that, scan area/page size seems to be larger. So I crop the pages manually and move the crop to the left edge when scanning. And while a crop set to the first of a series of scans is remembered during that scan session, starting a new scan (series) will reset that again. I wish simple-scan would remember and honour the page size selections of the settings dialogue. It gets quite annoying to have to set this manually again and again when one only ever scans A4 pages. Kind regards Andreas -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages simple-scan depends on: ii dconf-gsettings-backend [gsettings-backend] 0.18.0-1 ii gnome-icon-theme 3.10.0-1 ii libc62.17-97 ii libcairo21.12.16-2 ii libcolord1 1.0.6-1 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-0 2.36.4-1 ii libgtk-3-0 3.8.6-1 ii libgudev-1.0-0 204-6 ii libsane 1.0.24-1.1+b1 ii libsqlite3-0 3.8.2-1 ii xdg-utils1.1.0~rc1+git20111210-7 ii zlib1g 1:1.2.8.dfsg-1 simple-scan recommends no packages. simple-scan 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#738642: python-lxml 2.3.5-1
I have upgraded to python-lxml 2.3.5-1 from http://snapshot.debian.org/package/lxml/2.3.5-1/ , which is readily installable in wheezy, and as expected the conversion works. I will continue to test and use calibre with this version and report any problems here. Pavel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739684: ITP: r-other-nitpick -- peak identification for mass spectrometry data
Package: wnpp Severity: wishlist Owner: Andreas Tille ti...@debian.org * Package name: r-other-nitpick Version : 2.0 Upstream Author : Marc Kirchner marc.kirch...@iwr.uni-heidelberg.de * URL : http://hci.iwr.uni-heidelberg.de/MIP/Software/nitpick.php * License : LGPL Programming Lang: R Description : peak identification for mass spectrometry data This R package allows reliable extraction of features from mass spectra and helps in the automated analysis of proteomic mass spectrometry (MS) experiments. . This is the NITPICK implementation for peak picking in MS spectra. This package is maintained by the DebiChem team at git://anonscm.debian.org/debichem/packages/r-other-nitpick.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739657: gnuhealth-server: fails to install: gnuhealth-server.postinst: sudo: not found
Hi Emilien, looking at the gnuhealth-server.*inst files I guess you mean su instead of sudo. You are just root and want to execute the command as dbc_dbuser, right? Kind regards Andreas. On Fri, Feb 21, 2014 at 02:13:54AM +0100, Andreas Beckmann wrote: Package: gnuhealth-server Version: 2.4.1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. From the attached log (scroll to the bottom...): Selecting previously unselected package gnuhealth-server. (Reading database ... 12363 files and directories currently installed.) Preparing to unpack .../gnuhealth-server_2.4.1-1_all.deb ... Unpacking gnuhealth-server (2.4.1-1) ... Setting up gnuhealth-server (2.4.1-1) ... dbconfig-common: writing config to /etc/dbconfig-common/gnuhealth-server.conf Creating config file /etc/dbconfig-common/gnuhealth-server.conf with new version creating postgres user gnuhealth: success. verifying creation of user: success. creating database gnuhealth: success. verifying database gnuhealth exists: success. populating database via scriptfile... error encountered populating database: /usr/share/dbconfig-common/scripts/gnuhealth-server/install/pgsql exited with non-zero status dbconfig-common: gnuhealth-server configure: noninteractive fail. dbconfig-common: gnuhealth-server configure: ignoring errors from here forwards done. dbconfig-common: flushing administrative password Updating the 'gnuhealth' database /var/lib/dpkg/info/gnuhealth-server.postinst: 59: /var/lib/dpkg/info/gnuhealth-server.postinst: sudo: not found dpkg: error processing package gnuhealth-server (--configure): subprocess installed post-installation script returned error exit status 127 Errors were encountered while processing: gnuhealth-server cheers, Andreas ___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739685: flashplugin-nonfree: updater fails to download fp.11.2.202.341.sha512.i386.pgp.asc
Package: flashplugin-nonfree Version: 1:3.4 Severity: critical Tags: security Justification: root security hole Dear Maintainer, seems checksum file is missing again. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? # update-flashplugin-nonfree --status Flash Player version installed on this system : 11.2.202.336 Flash Player version available on upstream site: 11.2.202.341 flash-mozilla.so - auto mode link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50 Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.so'. root@lintower:~# update-flashplugin-nonfree -iv options : -i -v -- temporary directory: /tmp/flashplugin-nonfree.zzzwdR94s3 importing public key ... selected action = --install installed version = 11.2.202.336 upstream version = 11.2.202.341 wgetoptions= -nd -P . -v --progress=dot:default downloading http://people.debian.org/~bartm/flashplugin- nonfree/fp.11.2.202.341.sha512.i386.pgp.asc ... --2014-02-21 11:39:01-- http://people.debian.org/~bartm/flashplugin- nonfree/fp.11.2.202.341.sha512.i386.pgp.asc Auflösen des Hostnamen »people.debian.org (people.debian.org)«... 206.12.19.5, 2607:f8f0:610:4000:214:38ff:feee:b65a Verbindungsaufbau zu people.debian.org (people.debian.org)|206.12.19.5|:80... verbunden. HTTP-Anforderung gesendet, warte auf Antwort... 404 Not Found 2014-02-21 11:39:01 FEHLER 404: Not Found. * What outcome did you expect instead? Installation of new flashplungin-nonfree. -- Package-specific info: Debian version: jessie/sid Architecture: i386 Package version: 1:3.4 Adobe Flash Player version: LNX 11,2,202,336 MD5 checksums: 208968bb1109e8627fa3c08b43814bee /var/cache/flashplugin-nonfree/get-upstream-version.pl bd7f77dfd0a03bbbd5d124febb8c83d5 /var/cache/flashplugin-nonfree/install_flash_player_11_linux.i386.tar.gz bb65bbfca69eb7da3dcdbf4693ea352c /usr/lib/flashplugin-nonfree/libflashplayer.so Alternatives: flash-mozilla.so - auto mode link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50 Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.so'. lrwxrwxrwx 1 root root 34 Dec 9 15:46 /usr/lib/mozilla/plugins/flash-mozilla.so - /etc/alternatives/flash-mozilla.so /usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to `/etc/alternatives/flash-mozilla.so' -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.13-0.towo.3-siduction-686 (SMP w/1 CPU core; PREEMPT) 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 flashplugin-nonfree depends on: ii binutils 2.24-3 ii debconf [debconf-2.0] 1.5.52 ii gnupg 1.4.16-1 ii libatk1.0-02.10.0-2 ii libcairo2 1.12.16-2 ii libcurl3-gnutls7.35.0-1 ii libfontconfig1 2.11.0-2 ii libfreetype6 2.5.2-1 ii libgcc11:4.8.2-15 ii libglib2.0-0 2.37.5+really2.36.4-0r0 ii libgtk2.0-02.24.22-1 ii libnspr4 2:4.10.3-1 ii libnss32:3.15.4-2+fix1 ii libpango1.0-0 1.36.0-1+b1 ii libstdc++6 4.8.2-15 ii libx11-6 2:1.6.2-1 ii libxext6 2:1.3.2-1 ii libxt6 1:1.1.4-1 ii wget 1.15-1 flashplugin-nonfree recommends no packages. Versions of packages flashplugin-nonfree suggests: ii flashplugin-nonfree-extrasound 0.0.svn2431-3 ii fonts-dejavu2.34-1 ii hal 0.5.14-8 ii iceweasel 24.3.0esr-1 pn konqueror-nsplugins none ii ttf-mscorefonts-installer 3.5 ii ttf-xfree86-nonfree 4.2.1-3.1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668544: [Aptitude-devel] Bug#668544: Unreproducible
2014-02-21 07:48 Raúl Sánchez Siles: Hello: Fortunately I found the bundle I created by then. I run it with: aptitude-run-state-bundle aptitude-bundle And behaviour was as expected now, no indefinite high CPU usage. Resolver just throws a solution. If you still want the bundle, let me know. Version 0.6.10-1 here. Therefore I'll be closing this one in a few days if nobody objects. From what I understood in the original report, it was happening for you all of the time. Was it doing the same operation always (e.g., safe-upgrade), or with different ones? Since this bug is somewhat recent and so the versions of all components involved didn't diverge too much, perhaps you could temporarily install 0.6.6-1 and try to run the bundle again? http://snapshot.debian.org/package/aptitude/0.6.6-1/ Or alternatively, send the bundle for inspection, with instructions about the commands that you ran and so on (if you can recall them). Thanks for the report and the quick follow-up. Cheers. -- Manuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739686: rabbitvcs-nautilus: wrong status icon for filenames containing spaces
Package: rabbitvcs-nautilus Version: 0.15.2-1 Severity: normal Tags: upstream Dear Maintainer, I noticed that rabbitvcs-nautilus continuously displays the green hook symbol for files with blanks in their filename, even if the contents were changed. Steps to reproduce the problem: 1) create file some file - status icon: blue questionmark 2) git add some\ file - status icon: green hook, but should be blue plus sign The same applies if contents of some file are modified; the displayed symbol always shows green hook. Christoph -- 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/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rabbitvcs-nautilus depends on: ii nautilus 3.8.2-2 ii python-gobject 3.10.2-2 ii python-nautilus 1.1-4 ii rabbitvcs-core 0.15.2-1 rabbitvcs-nautilus recommends no packages. rabbitvcs-nautilus 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#739188: gnome-orca: python-speechd is gone
On 18/02/14 21:06, Paul Gevers wrote: On 16-02-14 20:07, Emilio Pozuelo Monfort wrote: It is basically done in svn. Just to check with everybody. Are there any objections uploading the current svn version + enabling python3-speechd? If not, I will do a final check and upload if I don't find anything. I have updated svn (locally) to 3.10 and tried it and it doesn't work at all (the orca process runs but doesn't emit any sound). I haven't had the time to debug this yet though. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739687: flashplugin-nonfree: update-flashplugin-nonfree does not work
Package: flashplugin-nonfree Version: 1:3.4 Severity: important I wanted to update to the new flash-plugin version 341: $ update-flashplugin-nonfree --status Flash Player version installed on this system : 11.2.202.336 Flash Player version available on upstream site: 11.2.202.341 flash-mozilla.so - auto mode link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50 Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.so'. So version 341 was recognised, but not as the 'best'. Consequently update-flashplugin-nonfree --install did not install the new version. -- Package-specific info: Debian version: jessie/sid Architecture: amd64 Package version: 1:3.4 Adobe Flash Player version: LNX 11,2,202,336 MD5 checksums: 208968bb1109e8627fa3c08b43814bee /var/cache/flashplugin-nonfree/get-ups= tream-version.pl 63d0a9b141f5a52cf9c7a71bd4f785f2 /var/cache/flashplugin-nonfree/install= _flash_player_11_linux.x86_64.tar.gz 2fa4c0ec54b0130d13ff931ab9abe52f /usr/lib/flashplugin-nonfree/libflashp= layer.so Alternatives: flash-mozilla.so - auto mode link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.s= o /usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50 Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.s= o'. lrwxrwxrwx 1 root root 34 Dec 10 23:33 /usr/lib/mozilla/plugins/flash-mo= zilla.so - /etc/alternatives/flash-mozilla.so /usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to `/etc/altern= atives/flash-mozilla.so' -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14.0-rc3-00022-g48c1260 (SMP w/4 CPU cores) Locale: LANG=3Dde_DE, LC_CTYPE=3Dde_DE (charmap=3DISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages flashplugin-nonfree depends on: ii binutils 2.24-3 ii debconf [debconf-2.0] 1.5.52 ii gnupg 1.4.16-1 ii libatk1.0-02.10.0-2 ii libcairo2 1.12.16-2 ii libcurl3-gnutls7.35.0-1 ii libfontconfig1 2.11.0-2 ii libfreetype6 2.4.9-1.1 ii libgcc11:4.8.2-15 ii libglib2.0-0 2.38.2-5 ii libgtk2.0-02.24.22-1 ii libnspr4 2:4.10.3-1 ii libnss32:3.15.4-2 ii libpango1.0-0 1.36.0-1+b1 ii libstdc++6 4.8.2-15 ii libx11-6 2:1.6.2-1 ii libxext6 2:1.3.2-1 ii libxt6 1:1.1.4-1 ii wget 1.15-1 flashplugin-nonfree recommends no packages. Versions of packages flashplugin-nonfree suggests: ii fonts-dejavu 2.34-1 pn halnone ii iceweasel 24.3.0esr-1 pn konqueror-nspluginsnone pn ttf-mscorefonts-installer none pn ttf-xfree86-nonfreenone -- no debconf information --=20 To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmaster@lists.debian= .org
Bug#739188: gnome-orca: python-speechd is gone
On 21-02-14 12:07, Emilio Pozuelo Monfort wrote: On 18/02/14 21:06, Paul Gevers wrote: On 16-02-14 20:07, Emilio Pozuelo Monfort wrote: It is basically done in svn. Just to check with everybody. Are there any objections uploading the current svn version + enabling python3-speechd? If not, I will do a final check and upload if I don't find anything. I have updated svn (locally) to 3.10 and tried it and it doesn't work at all (the orca process runs but doesn't emit any sound). I haven't had the time to debug this yet though. I am working on the latest 3.8. If it runs, I will upload that for now and we can have some time to get 3.10 working. I expect I can get this finished this weekend... Paul signature.asc Description: OpenPGP digital signature
Bug#739688: Manpages not utf-8 encoded
Package: sensible-utils Version: 0.0.9 Packaging sensible-utils for Fedora, rpmlint told me: sensible-utils.noarch: W: file-not-utf8 /usr/share/man/de/man1/sensible-editor.1.gz sensible-utils.noarch: W: file-not-utf8 /usr/share/man/fr/man1/sensible-editor.1.gz sensible-utils.noarch: W: file-not-utf8 /usr/share/man/es/man1/sensible-editor.1.gz Specifically: $ file de/man1/sensible-editor.1 de/man1/sensible-editor.1: troff or preprocessor input, Non-ISO extended-ASCII text $ file fr/man1/sensible-editor.1 fr/man1/sensible-editor.1: troff or preprocessor input, ISO-8859 text $ file es/man1/sensible-editor.1 es/man1/sensible-editor.1: troff or preprocessor input, Non-ISO extended-ASCII text de/man1/sensible-editor.1 and es/man1/sensible-editor.1 contain garbage characters. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739628: clasp: 3.0 cannot solve some problems solved by 2.1.4
On 02/21/2014 07:29 AM, Thomas Krennwallner wrote: On Thu Feb 20, 2014 05:14:53PM +0100, Julian Andres Klode wrote: Package: clasp Version: 3.0.0-1 Severity: normal clasp 2.1.4-1 can solve the attached problems, and clasp 3.0.0 cannot. Both times using --opt-heuristic=3. I previously also used --opt-hierarch=3, but that's not available anymore. So I only used --opt-heuristic=3 for both tests. These are real world problems, namely 3 steps of upgrading a Debian sid installation from 2014-02-02 to 2014-02-20. The transformation of package dependencies is sub-optimal, as it contains unneeded packages, but clasp 2 was fine solving it, so 3.0 should handle it as well. I've forwarded your bug report to the clasp and aspcud upstream maintainers (in CC). Best, This is a bug in the PB front-end of clasp-3.0.0. It will be fixed in the next release. Regards, Ben -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling draft CFV
Andreas Barth writes (Bug#727708: init system coupling draft CFV): * Russ Allbery (r...@debian.org) [140221 06:15]: This includes the change I proposed to Andreas, although unfortunately Andreas hasn't had a chance to respond on whether that addressed his objection. It also makes it clearer that the point about not offering advice past jessie only applies to the sysvinit compatibility part. I think I'll be able to answer during the weekend, sorry for the delay. I'm afraid that I still intend to call for votes at 18:00 UTC today, so if you want Russ to take your comments into account in his draft, you will have to reply sooner. Apologies, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739664: libavg: FTBFS with libav 10
On 21 February 2014 01:51, Sebastian Ramacher sramac...@debian.org wrote: Source: libavg Version: 1.8.0-1 Severity: important Tags: sid jessie User: j...@debian.org Usertags: libav10 libavg fails to build from source gainst libav 10 (currently available in experimental): | In file included from AudioDecoderThread.cpp:24:0: | AudioDecoderThread.h:72:9: error: 'ReSampleContext' does not name a type | ReSampleContext * m_pResampleContext; | ^ snip Full build log is available at http://people.debian.org/~sramacher/logs/libav10/libavg_1.8.0-1_amd64-20140221-0241.log It appears the builds are aborted on first error, which is not helpful in this situation. Please consider executing build with -k option to make, such that more errors are seen from other parts of the codebase, since the highlighted issue is not the only porting problem in this package. Ditto other packages may benefit from -k to better assess the scope of breakage. This bug will become release-critical at some point when the libav10 transition starts. Migration documentation can be found at https://wiki.libav.org/Migration/10. When is libav10 going to be released? When is libav10 planned to be uploaded into unstable? Are you planning to have both available in jessie? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739689: PubMed ID metadata loop-up fails
Package: referencer Version: 1.2.1-1+b1 Severity: normal Any reference lookup involving PMID fails for me. (Documents - Add reference with ID - Pubmed ID). Get metadata does not import anything. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') 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 referencer depends on: ii libatkmm-1.6-12.22.7-2 ii libboost-regex1.54.0 1.54.0-4+b1 ii libc6 2.17-97 ii libgcc1 1:4.8.2-16 ii libgconfmm-2.6-1c22.28.0-1 ii libgdk-pixbuf2.0-02.30.5-1 ii libglib2.0-0 2.38.2-5 ii libglibmm-2.4-1c2a2.36.2-1 ii libgtk2.0-0 2.24.22-1 ii libgtkmm-2.4-1c2a 1:2.24.4-1 ii libpangomm-1.4-1 2.34.0-1 ii libpoppler-glib8 0.22.5-4 ii libpython2.7 2.7.6-5 ii libsigc++-2.0-0c2a2.2.11-3 ii libstdc++64.8.2-16 ii libxml2 2.9.1+dfsg1-3 referencer recommends no packages. referencer suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736427: [bug #41331] spurious errors if some files in the cert directory are not certificates
Follow-up Comment #2, bug #41331 (project wget):
In my case, a strace shows, e.g. for an empty file empty:
10268 stat(/home/vinc17/wd/config/cacert/empty, {st_mode=S_IFREG|0644,
st_size=0, ...}) = 0
10268 open(/home/vinc17/wd/config/cacert/empty, O_RDONLY) = 6
10268 fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
10268 fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
10268 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f28e046b000
10268 lseek(6, 0, SEEK_CUR) = 0
10268 read(6, , 8192) = 0
10268 close(6) = 0
10268 munmap(0x7f28e046b000, 4096) = 0
10268 write(2, ERROR: Failed to open cert /home..., 69) = 69
In Debian, wget is built with:
+digest +https +ipv6 +iri +large-file +nls +ntlm +opie +ssl/gnutls
Darshit, is wget built with gnutls or openssl in your case?
The problem comes from:
if ((rc = gnutls_certificate_set_x509_trust_file (credentials, ca_file,
GNUTLS_X509_FMT_PEM)) =
0)
logprintf (LOG_NOTQUIET, _(ERROR: Failed to open cert %s: (%d).n),
ca_file, rc);
else
ncerts += rc;
while in wget 1.13, the return value of gnutls_certificate_set_x509_trust_file
was not checked. This error message serves no purpose since the failure
doesn't prevent the URL from being opened (using the right certificates).
___
Reply to this item at:
http://savannah.gnu.org/bugs/?41331
___
Message posté via/par Savannah
http://savannah.gnu.org/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
Keith Packard writes (Re: Bug#727708: init system coupling etc.): Ian Jackson ijack...@chiark.greenend.org.uk writes: Perhaps you would like to change this to something like: The TC chooses to not pass a resolution at the current time about whether software may require specific init systems. ... Thanks, yes, this looks better than my original version. Would you like me to commit the change, or would you like to? I've done so, thanks. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739690: RFS: liblas/1.7.0+dfsg-4
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package liblas Package name: liblas Version : 1.7.0+dfsg-4 Upstream Author : Howard Butler, Mateusz Loskot, Phil Vachon, Martin Vales Frank Warmerdam URL : http://liblas.org/ License : BSD-4-Clause Section : science It builds those binary packages: liblas-bin- ASPRS LiDAR data translation toolset liblas-c-dev - ASPRS LiDAR data translation library - C development files liblas-c2 - ASPRS LiDAR data translation library - C version liblas-dev- ASPRS LiDAR data translation library - C++ development files liblas2 - ASPRS LiDAR data translation library - C++ version python-liblas - Python module to use the ASPRS LiDAR data translation library To access further information about this package, please visit the following URL: http://mentors.debian.net/package/liblas Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libl/liblas/liblas_1.7.0+dfsg-4.dsc More information about libLAS can be obtained from http://liblas.org/. Changes since the last upload: * Move python dependencies from Build-Depends-Indep to Build-Depends. 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#727708: init system coupling draft CFV
Russ Allbery writes (Bug#727708: init system coupling draft CFV): Here is the new draft of my ballot option. I think this addresses all of the issues that were raised. I didn't rewrite the whole thing to avoid all the shoulds; I thought about it, but it felt like it made it a bit too hard to read. I did try a few different wordings of the bit about upgrades, and hopefully what I came up with will work. This includes the change I proposed to Andreas, although unfortunately Andreas hasn't had a chance to respond on whether that addressed his objection. It also makes it clearer that the point about not offering advice past jessie only applies to the sysvinit compatibility part. This has also been committed to Git. I don't see it. Perhaps you failed to push. I have transposed it into git myself and pushed. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
]] Colin Watson So, in my amendment, I intended this to be the cooperating groups of packages intended for use with specific init systems, which language I think I borrowed from your proposal. If logind-208 Depends: systemd (or indeed if it's part of systemd), then that's fine, as long as it doesn't end up being required by something else that isn't so intimately related to the init system; in other words, a dependency on systemd doesn't become any less a dependency on systemd just because it happens to be spelled Depends: logind and there's only one provider available. To be honest, I'm not sure why init systems are being singled out here. It's not really feasible to run both kdm and gdm at the same time, or run multiple window managers at the same time or a whole host of other software. Or would you be as strongly opposed to having a tool (say an accessibility tool) depend on GDM because it provided interfaces that KDM doesn't? (I'm not sure this is actually true, but I could easily see it being true.) I also find it curious how A depending on interface B provided by packages C and D becomes RC buggy because D is unmaintained and gets removed from the archive. It's not how we usually treat bugs. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739691: libgl1-mesa-glx:amd64: Upgrade to Xserver 1.15 broke kwin and others: Invalid GLXFBConfig returned
Package: libgl1-mesa-glx Version: 9.2.2-1 Severity: important Dear Maintainer, after upgrading to XServer 1.15, compositing in KWin does not work anymore. Downgrading X back to 1.14 confirmed that indeed the issue was introduced by the upgrade. However, further research indicates that this is actually a bug in Mesa, which has been reported against Ubuntu at [1] and upstream at [2]. Upstream has patches [3][4]. It's not only kwin showing the bug, but also my small GL test application [5]: glXChooseFBConfig returns a GLXFBConfig that, when passed to glXGetVisualFromFBConfig, just yields NULL. The patch [3] indicates that the problem is incorrect default values for GLX_DRAWABLE_TYPE, and indeed if I explicitly request a GLX_DRAWABLE_TYPE of GLX_WINDOW_BIT in my test application, the bug is gone. $ sudo lspci -nn |grep -i vga 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108M [GeForce GT 630M] [10de:0de9] (rev ff) Kind regards Ralf [1] https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1278168 [2] https://bugs.freedesktop.org/show_bug.cgi?id=70706 [3] http://patchwork.freedesktop.org/patch/20458/ [4] http://patchwork.freedesktop.org/patch/20464/ [5] http://www.ralfj.de/git/gltest.git -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgl1-mesa-glx:amd64 depends on: ii libc6 2.17-97 ii libdrm22.4.52-1 ii libglapi-mesa 9.2.2-1 ii libx11-6 2:1.6.2-1 ii libx11-xcb12:1.6.2-1 ii libxcb-dri2-0 1.10-2 ii libxcb-glx01.10-2 ii libxcb11.10-2 ii libxdamage11:1.1.4-1 ii libxext6 2:1.3.2-1 ii libxfixes3 1:5.0.1-1 ii libxxf86vm11:1.1.3-1 ii multiarch-support 2.17-97 Versions of packages libgl1-mesa-glx:amd64 recommends: ii libgl1-mesa-dri 9.2.2-1 libgl1-mesa-glx:amd64 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#739585: RFS: qjoypad/4.1.0-1 ITP
Hi, I would like to give my suggestion of categories for the desktop file. How about Categories=Settings;HardwareSettings;? Categories=Utility;Game; If the categories include two main categories, such as Game and Utility, the program may appear two times in the menu. http://standards.freedesktop.org/menu-spec/latest/apa.html Regards, Juhani -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739692: debmake: -d is broken in 4.0.8
Package: debmake Version: 4.0.8-1 Severity: normal -d is broken in 4.0.8 (4.0.7 works). Osamu -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debmake depends on: ii dpkg-dev 1.17.6 ii python3 3.3.4-1 pn python3:any none ii rsync3.1.0-2 Versions of packages debmake recommends: ii build-essential 11.6 ii curl 7.35.0-1 ii devscripts 2.14.1 ii wget 1.15-1 Versions of packages debmake suggests: ii autotools-dev 20130810.1 ii cmake 2.8.12.1-1.1 ii dh-autoreconf 9 ii gem2deb0.7.0 ii javahelper 0.45 -- 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#727708: init system coupling etc.
* Russ Allbery (r...@debian.org) [140219 19:24]: Andreas Barth a...@ayous.org writes: * Russ Allbery (r...@debian.org) [140214 04:36]: That's a much stronger statement than we've made about support for the non-Linux ports in the past, where they're treated at most like another release architecture, which means that packages that have never worked on that architecture are not expected to do so and packages that used to work but stopped are sometimes removed from just that architecture rather than ported depending on the situation. My expectation of packages is indeed that they work on as many architectures as reasonable possible, and this includes that they support the default init system there. (The question of which severity does a bug have is a different question, for a release architecture that bug would be serious according to https://release.debian.org/jessie/rc_policy.txt section 4 paragraph 4 and I don't think we should lower the bar.) I don't think that this expectation is wrong. That's a very good point. How does this sound to you? Packages should normally support the default init system on all architectures for which they are built. There are some exceptional cases where lack of support for the default init system may be appropriate, such as alternative init system implementations, special-use packages such as managers for non-default init systems, and cooperating groups of packages intended for use with non-default init systems. However, package maintainers should be aware that a requirement for a non-default init system will mean the package will be unusable for most Debian users and should normally be avoided. Better but I think we should also point out that supporting different architectures is a good thing. So the first sentence rather as | Packages should support as many architectures as reasonably possible, | and they should normally ... Also I'd like to amend the last sentence with , and could constitute an serious bug of the package. (which is a correct observation according to the current RC policy) Because I currently don't see why we should say that (or: whats in there which is not already said elsewhere), and in that case, less text is better. Given that the previous paragraph contains a lot of specific advice for the jessie release, I feel like it adds some clarity to say explicitly that we don't have advice to offer for the next release after jessie at this time. Well, the paragraph cited above does apply not only to jessie (but it's meaning could change depending on which architectures debian supports in which way). So I propose to change the text: The Technical Committee offers no advice at this time on requirements or package dependencies on specific init systems after the jessie release. There are too many variables at this point to know what the correct course of action will be. to | The Technical Committee offers no advice regarding sysvinit | compatibility at this time after the jessie release. There are too | many variables at this point to know what the correct course of action | will be. (the empty line above is there by purpose, i.e. it also merges this paragraph with the previous one) To avoid any doubt, this is a formal proposal for an amendment to Russ's text, i.e. I would like to see it on the ballot. I'll try to check my mail before 18:00 UTC but I cannot promise. Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739693: Add homepage for mt-st
Package: mt-st It would be nice to have the Homepage set in d/control and/or in the debian/watch file. For example: ftp://ftp.ibiblio.org/pub/linux/system/backup/mt-st-1.1.tar.gz Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739694: Invalid file ref in documentation (man page)
Package: mt-st man page refers to: [...] Otherwise, a default device defined in the file /usr/include/sys/mtio.h is used. [...] I believe this is inacurate as it does not exists at least on my system. Maybe instead: /usr/include/linux/mtio.h or /usr/include/x86_64-linux-gnu/sys/mtio.h Thanks -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
Andreas Barth writes (Bug#727708: init system coupling etc.): So I propose to change the text: The Technical Committee offers no advice at this time on requirements or package dependencies on specific init systems after the jessie release. There are too many variables at this point to know what the correct course of action will be. to | The Technical Committee offers no advice regarding sysvinit | compatibility at this time after the jessie release. There are too | many variables at this point to know what the correct course of action | will be. (the empty line above is there by purpose, i.e. it also merges this paragraph with the previous one) I will transpose this into git. As an observation from a native English speaker, the language is rather odd. It is not conventional to have two time clauses next to each other like that. I would suggest (but do not formally propose): The Technical Committee offers no advice at this time regarding sysvinit compatibility after the jessie release. There are too many variables at this point to know what the correct course of action will be. Ie, move at this time to after advice. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739695: Convenient copy of mtio.h in source
Package: mt-st
It is not clear what the impact would be, but I think it would be
easier to maintain this package if the mtio.h copy would not be used
and instead the system installed one would be used instead.
Here are the diff (as of today on wheezy):
$ diff -u mtio.h /usr/include/linux/mtio.h
--- mtio.h 2008-02-20 20:31:49.0 +0100
+++ /usr/include/linux/mtio.h 2014-01-11 01:15:51.0 +0100
@@ -1,9 +1,8 @@
/*
* linux/mtio.h header file for Linux. Written by H. Bergman
*
- * Sanitized version for mt/stinit (definitions not used by these
- * programs have been removed) 7 Oct 2007/Kai M�kisara
- *
+ * Modified for special ioctls provided by zftape in September 1997
+ * by C.-J. Heine.
*/
#ifndef _LINUX_MTIO_H
@@ -64,6 +63,7 @@
#define MTCOMPRESSION 32/* control compression with SCSI mode page 15 */
#define MTSETPART 33 /* Change the active tape partition */
#define MTMKPART 34 /* Format the tape with one or two partitions */
+#define MTWEOFI 35 /* write an end-of-file record (mark) in immediate mode */
/* structure for MTIOCGET - mag tape get status command */
@@ -110,6 +110,12 @@
#define MT_ISSCSI1 0x71 /* Generic ANSI SCSI-1 tape unit */
#define MT_ISSCSI2 0x72 /* Generic ANSI SCSI-2 tape unit */
+/* QIC-40/80/3010/3020 ftape supported drives.
+ * 20bit vendor ID + 0x80 (see ftape-vendors.h)
+ */
+#define MT_ISFTAPE_UNKNOWN 0x80 /* obsolete */
+#define MT_ISFTAPE_FLAG 0x80
+
/* structure for MTIOCPOS - mag tape get position command */
@@ -117,26 +123,12 @@
long mt_blkno; /* current block number */
};
+
/* mag tape io control commands */
#define MTIOCTOP _IOW('m', 1, struct mtop) /* do a mag tape op */
#define MTIOCGET _IOR('m', 2, struct mtget) /* get tape status */
#define MTIOCPOS _IOR('m', 3, struct mtpos) /* get tape position */
-/* The next two are used by the QIC-02 driver for runtime reconfiguration.
- * See tpqic02.h for struct mtconfiginfo.
- */
-#define MTIOCGETCONFIG _IOR('m', 4, struct mtconfiginfo) /* get tape config */
-#define MTIOCSETCONFIG _IOW('m', 5, struct mtconfiginfo) /* set tape config */
-
-/* the next six are used by the floppy ftape drivers and its frontends
- * sorry, but MTIOCTOP commands are write only.
- */
-#define MTIOCRDFTSEG_IOWR('m', 6, struct mtftseg) /* read a segment */
-#define MTIOCWRFTSEG_IOWR('m', 7, struct mtftseg) /* write a segment */
-#define MTIOCVOLINFO _IOR('m', 8, struct mtvolinfo) /* info about volume */
-#define MTIOCGETSIZE_IOR('m', 9, struct mttapesize)/* get cartridge size*/
-#define MTIOCFTFORMAT _IOWR('m', 10, struct mtftformat) /* format ftape */
-#define MTIOCFTCMD _IOWR('m', 11, struct mtftcmd) /* send QIC-117 cmd */
/* Generic Mag Tape (device independent) status macros for examining
* mt_gstat -- HP-UX compatible.
@@ -202,6 +194,7 @@
#define MT_ST_SYSV 0x1000
#define MT_ST_NOWAIT0x2000
#define MT_ST_SILI 0x4000
+#define MT_ST_NOWAIT_EOF 0x8000
/* The mode parameters to be controlled. Parameter chosen with bits 20-28 */
#define MT_ST_CLEAR_DEFAULT 0xf
Thanks
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
Andreas Barth writes (Bug#727708: init system coupling etc.): Russ Allbery (r...@debian.org) [140219 19:24]: How does this sound to you? Packages should normally support the default init system on all architectures for which they are built. There are some exceptional cases where lack of support for the default init system may be appropriate, such as alternative init system implementations, special-use packages such as managers for non-default init systems, and cooperating groups of packages intended for use with non-default init systems. However, package maintainers should be aware that a requirement for a non-default init system will mean the package will be unusable for most Debian users and should normally be avoided. Better but I think we should also point out that supporting different architectures is a good thing. So the first sentence rather as | Packages should support as many architectures as reasonably possible, | and they should normally ... Also I'd like to amend the last sentence with , and could constitute an serious bug of the package. (which is a correct observation according to the current RC policy) Russ has already amended his text to say Software should So when transposing your amendment onto Russ's new text, I have to decide between using your new text verbatim (effectively reverting that change), or treating your proposal as a request to change only the parts you are actually aiming at. I'm going to do the latter because it appears to best reflect your intent. This results in Software should support as many architectures as reasonably possible, and it should normally support the default [...] (changing they to it to agree gramatically with software rather than packages). To avoid any doubt, this is a formal proposal for an amendment to Russ's text, i.e. I would like to see it on the ballot. Thanks for being clear. Regards, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739682: installation-report: Installation hangs with 'pkgsel: finishing up'
Hi, The problem does not occur, when I perform an offline install with the same ISO. So maybe some packages have been updated recently that cause now problems. regards, Florian signature.asc Description: OpenPGP digital signature
Bug#727708: init system coupling etc.
Andreas Barth writes (Bug#727708: init system coupling etc.): Russ Allbery (r...@debian.org) [140219 19:24]: So I propose to change the text: The Technical Committee offers no advice at this time on requirements or package dependencies on specific init systems after the jessie release. There are too many variables at this point to know what the correct course of action will be. to | The Technical Committee offers no advice regarding sysvinit | compatibility at this time after the jessie release. There are too | many variables at this point to know what the correct course of action | will be. (the empty line above is there by purpose, i.e. it also merges this paragraph with the previous one) Looking at Russ's draft, he has already made an effectively identical change. Russ's wording is: The Technical Committee offers no advice at this time on sysvinit support beyond the jessie release. There are too many variables at this point to know what the correct course of action will be. This differs from yours in the placement of at this time (see my previous mail) and in that it uses beyond the jessie release rather than after the jessie release. These don't seem to change the meaning much for me but improve the way it reads. You may wish to adopt Russ's wording. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736105: Sourceless file
Control: tags -1 patch New revision without the sourceless file is available at mentors: http://mentors.debian.net/debian/pool/main/f/freemind/freemind_0.9.0+dfsg2-1.dsc See also this discussion on the debian-java mailing list https://lists.debian.org/debian-java/2014/02/msg00057.html Markus signature.asc Description: OpenPGP digital signature
Bug#711984: Status
For the record, ruby-rdoc is a dependency of jekyll. Prateeshka, what's the status on this package ? Have you begun working on it ? All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719590: libc6:amd64: C.UTF-8 locales should be regarded like C w.r.t. $LANGUAGE precedence
Control: tags -1 upstream Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=16621 Control: found -1 2.18-1 Reported upstream at it still applies to 2.18. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703188: Offer to sponsor ruby-pygments.rb
Axel, if you're willing to take over packaging of ruby-pygments.rb, I'll find the time to sponsor this package. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739696: python testsuite failure when run with the python-dbg interpreter
Package: subversion Version: 1.8.5-2 Severity: important Tags: sid jessie When running the testsuite for the python bindings using the python-dbg interpreter the testsuite doesn't pass, failing at Test svn_client_info on working copy file and remote files. ... ok test_inherited_props (client.SubversionClientTestCase) Test inherited props ... Fatal Python error: subversion/bindings/swig/python/svn_client.c:23155 object at 0x8e78654 has negative ref count -606348326 /bin/bash: line 2: 8710 Aborted python2.7-dbg /scratch/packages/tmp/subversion-1.8.5/subversion/bindings/swig/python/tests/run_all.py --verbose make[2]: *** [check-swig-py] Error 134 this is the second Py_XDECREF(_global_py_pool); failing in _wrap_svn_client_propget5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735047: [Xcb] Bug#735047: fglrx-driver: openGL applications segfaults on igpu configuration
Hi,
On 02.02.2014 17:41, Julien Cristau wrote:
[...]
On 2014-02-01 23:18, Alexander V. Kudrevatykh wrote:
В Чтв, 30/01/2014 в 01:05 +0100, Andreas Beckmann пишет:
First step of debugging would be to run glxinfo inside gdb and get a
backtrace
after the crash. And maybe running it under strace, too.
In attachment you can find gdb and strace output for glxinfo
Program received signal SIGSEGV, Segmentation fault.
xcb_glx_query_server_string_string_length (R=R@entry=0x0) at glx.c:2460
Null-pointer dereference in libxcb-glx0.
The caller seems to be
http://sources.debian.net/src/mesa/9.2.2-1/src/glx/glx_query.c?hl=55#L55
(but this is code from sid, codesearch.d.n does not have wheezy)
Reassigning to libxcb since I don't know how to debug further.
There is no bug in xcb-glx here. Mesa doesn't do the necessary error checking
for this request (as evident by the reply = 0x0 in gdb output).
The GLX QueryServerString request failed, the error for this was ignored (NULL
argument to xcb_glx_query_server_string_reply()) and the caller then tried to
extract data from the NULL pointer reply.
From the strace output, the last request sent is this one:
writev(3, [{\232\23\3\0\0\0\0\0\2\0\0\0, 12}], 1) = 12
This is a request with length 3*4=12 (third and fourth byte, little endian),
major number 0232 = 154 and minor number 023 = 19. Major numbers are assigned
dynamically, thus no idea what the 154 means (but xdpyinfo -ext all | grep
opcode: 154 would tell us), but the minor number 19 could help. GLX
QueryServerString has minor 19, which would mean the request contains screen=0
and name=2 which maches the output from gdb
__glXQueryServerString (dpy=dpy@entry=0x608010, opcode=optimized out,
screen=screen@entry=0, name=name@entry=2)
(Also I just looked up the GLX QueryExtension request from the strace output and
0232 is indeed GLX...)
The reply to this seems to be:
recvmsg(3, {msg_name(0)=NULL,
msg_iov(1)=[{\0\1\17\0\27\0\0\0\23\0\232\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 32
This is an error (\0) with error code 1 and sequence number 15 (\17\0). The
fields are: resource_id = \27\0\0\0 = 23, minor_code = \23\0 = 19, major_code =
\232 = 154 and all following fields being zero.
Error code 1 is a request error. From Xlib's src/XErrorDB this is described as
BadRequest (invalid request code or no such operation). Some other docs[1] say
The major or minor opcode does not specify a valid request.. I am confused...
TL;DR: No bug in anything xcb-related here, but there is (a) a bug in mesa where
it doesn't handle a request failure correctly and (b) some weirdness that I
don't understand that makes the server claim to support GLX, but not support GLX
QueryServerString.
Cheers,
Uli
[0]: http://cgit.freedesktop.org/xorg/xserver/tree/glx/glxcmds.c#n2390
[1]: http://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.html#errors
--
99 little bugs in the code
99 little bugs in the code
Take one down, patch it around
117 little bugs in the code
-- @irqed
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739697: src:dolfin: FTBFS on armhf and mips: virtual memory exhausted: Cannot allocate memory
Package: src:dolfin Version: 1.3.0+dfsg-1 Severity: serious Dear Maintainer, dolfin currently FTBFS on armhf and mips: [ 70%] Building CXX object dolfin/CMakeFiles/dolfin.dir/generation/PolyhedralMeshGenerator.cpp.o cd /«BUILDDIR»/dolfin-1.3.0+dfsg/debian/build-python2.7/dolfin /usr/bin/c++ -DBOOST_UBLAS_NDEBUG -DDOLFIN_GIT_COMMIT_HASH=\unknown\ -DDOLFIN_VERSION=\1.3.0\ -DHAS_CGAL -DHAS_CHOLMOD -DHAS_HDF5 -DHAS_MPI -DHAS_OPENMP -DHAS_PETSC -DHAS_QT4 -DHAS_QVTK -DHAS_SCOTCH -DHAS_SLEPC -DHAS_UMFPACK -DHAS_VTK -DHAS_ZLIB -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -D_BSD_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -Ddolfin_EXPORTS -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wno-deprecated -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -frounding-math -fopenmp -O2 -g -DNDEBUG -fPIC -isystem /usr/include/qt4 -isystem /usr/include/qt4/QtGui -isystem /usr/include/qt4/QtCore -isystem /usr/include/vtk-5.8 -I/«BUILDDIR»/dolfin-1.3.0+dfsg -I/usr/include/libxml2 -I/usr/lib/slepcdir/3.4.2 -I/usr/lib/slepcdir/3.4.2/linux-gnueabihf-c-opt/include -I/usr/lib/slepcdir/3.4.2/include -isystem /usr/include/suitesparse -isystem /usr/include/scotch -isystem /usr/lib/openmpi/include -isystem /usr/lib/openmpi/include/openmpi -isystem /usr/include/eigen3 -isystem /usr/lib/petscdir/3.4.2/include -isystem /usr/lib/petscdir/3.4.2/linux-gnueabihf-c-opt/include-o CMakeFiles/dolfin.dir/generation/PolyhedralMeshGenerator.cpp.o -c /«BUILDDIR»/dolfin-1.3.0+dfsg/dolfin/generation/PolyhedralMeshGenerator.cpp virtual memory exhausted: Cannot allocate memory Apparently the C++ compiler cannot deal with that source file within reasonable memory bounds. There are various possible solutions among which: simplifying the source file, deactivating the corresponding functionality on those archs, trying another compiler or compiler version, removing dolfin from those archs… Cheers, -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: Digital signature
Bug#733352: Should we create a seqan1.3 package for bowtie and tophat
Hi, since both packages bowtie (1.0!) and tophat stopped building from source since we switched to seqan 1.4 (both bug reports in CC) and upstream of both programs did not responded since three weeks I wonder whether we should reintroduce a seqan 1.3 package to be able to build the packages again. As far as I understood both have some relevance in several workflows and we should not leave these with release critical bugs. Any opinions? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739698: openstack-dashboard: should compress css and js during postinst
Source: openstack-dashboard Version: 2013.2.2-1 Severity: normal Dear Maintainer, Horizon expects the CSS and JS to be compressed by python-lesscpy. This can be done offline ( COMPRESS_OFFLINE=True) or on the fly. In the second case, the compession is rather long (=~ between 10s and 30s) and happens on every pages until the caches are ready. The following command can be used to refresh the case: /usr/share/openstack-dashboard/manage.py compress Best regards, -- Gonéri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739663: Processed: libboinc7: fails to upgrade from 'wheezy' - trying to overwrite /usr/lib/libboinc_zip.so.7
Hi Andreas, I tried to add a Break+Replaces, but it didn't work, I think because now boinc-dev is not a real package anymore, just a transition virtual package. For this reason I only added a breaks on libboinc7, and I tested on a virtual machine. It seems to be working, but this is the first time I play with breaks/replaces fields, so I might be wrong somewhere. this is the commit, I'll upload a version in the next few days if no answer, since I think this bug is pretty serious. http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc.git;a=commitdiff;h=c993dd1d92d58a03562c52c3d2f8b180303eb84f Can I kindly ask you to review the patch? many thanks, Gianfranco Il Venerdì 21 Febbraio 2014 2:51, Debian Bug Tracking System ow...@bugs.debian.org ha scritto: Processing control commands: affects -1 + boinc-dev Bug #739663 [libboinc7] libboinc7: fails to upgrade from 'wheezy' - trying to overwrite /usr/lib/libboinc_zip.so.7 Added indication that 739663 affects boinc-dev -- 739663: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739663 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- pkg-boinc-devel mailing list pkg-boinc-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel
Bug#727708: init system coupling etc.
On Thu, Feb 20, 2014 at 05:20:22AM +0100, Tollef Fog Heen wrote: ]] Colin Watson So, in my amendment, I intended this to be the cooperating groups of packages intended for use with specific init systems, which language I think I borrowed from your proposal. If logind-208 Depends: systemd (or indeed if it's part of systemd), then that's fine, as long as it doesn't end up being required by something else that isn't so intimately related to the init system; in other words, a dependency on systemd doesn't become any less a dependency on systemd just because it happens to be spelled Depends: logind and there's only one provider available. To be honest, I'm not sure why init systems are being singled out here. It's not really feasible to run both kdm and gdm at the same time, or run multiple window managers at the same time or a whole host of other software. Or would you be as strongly opposed to having a tool (say an accessibility tool) depend on GDM because it provided interfaces that KDM doesn't? (I'm not sure this is actually true, but I could easily see it being true.) They're being singled out because this is actually something people have been proposing to do, and other people have objected. Regarding the hypothetical about display managers, I can *conceive* of situations where this might be an issue. It's less clear than with init systems, though, because desktop software tends to naturally go with a display manager in ways that it doesn't so naturally go with a particular init system: assuming that grandomaccessibilitytool has a visible interface, it's probably themed the same way as GDM, most of its users will probably be using GDM already (or maybe LightDM, I suppose), and so on. It's technically possible but pretty unlikely that a KDE tool will suddenly decide that it really needs GDM and thus conflict with the rest of your KDE desktop, or in general that you'd end up wanting to install multiple packages that require different display managers, just because most people tend to stick within a cooperating set of packages for their desktop environment. I also find it curious how A depending on interface B provided by packages C and D becomes RC buggy because D is unmaintained and gets removed from the archive. It's not how we usually treat bugs. I don't view this ballot option as stating that a particular package becomes RC-buggy. It's making a statement about how our software ought to be structured, not specifically assigning problems to one end or other of a dependency arc. I still hold out some hope that maintainers will actually cooperate and talk to each other about this kind of problem ... If part of an init system (whether packaged monolithically or as an add-on) that's essential for the operation of other software in the archive with that init system used to work but then ceases to be maintained enough to be shippable, then that's a serious regression for that init system and we would want to look at whether it's still viable at all or perhaps whether the component in question can be resurrected. It shouldn't be just a mindlessly static approach where package A becomes RC-buggy and we don't think about the underlying reasons that led up to it. I think that situation is quite different, though, from the situation where package A introduces a new interface dependency in a way that's known to have only limited support. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732858: is mysql java driver compatible
The Java MySQL driver is used. Is it fully compatible with MariaDB and will it remain ? Or will we have a driver per MySQL/MariaDB ? Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739631: [Help] Bug#739631: python-pysam: FTBFS: ImportError: No module named pysam
/me continues promoting pybuild:
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
diff --git a/debian/control b/debian/control
index 8699486..c9acaaf 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,7 @@ Section: python
XS-Testsuite: autopkgtest
Priority: optional
Build-Depends: debhelper (= 9),
+ dh-python,
python-all-dev,
python-setuptools,
cython,
diff --git a/debian/rules b/debian/rules
index 50d4cad..aaf270f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,19 +1,12 @@
#!/usr/bin/make -f
-# Hint:
-# https://wiki.debian.org/Python/LibraryStyleGuide
-# suggests:
export PYBUILD_NAME=pysam
-# which probably does not harm but due to the fact that there is
-# some additional binary package a debian/python-pysam.install
-# file is definitely needed.
DEBPKGNAME := $(shell dpkg-parsechangelog | awk '/^Source:/ {print $$2}')
TESTPKG:= $(DEBPKGNAME)-tests
-pybuilddir := $(CURDIR)/build/lib.$(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)-$(shell dpkg-architecture -qDEB_BUILD_GNU_CPU)
%:
- dh $@ --with python2
+ dh $@ --with python2 --buildsystem=pybuild
# Cython is recreating some c-files. To enable building twice in a row these
# will be saved in advance and restored afterwards
@@ -33,14 +26,10 @@ override_dh_auto_build: debian/savefiles
dh_auto_build
override_dh_auto_test:
- dh_auto_test
- chmod a+x tests/pysam_test_offline.py
-ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
- set -e -x;\
- for pyv in `pyversions -dv` ; do \
- cd tests env PYTHONPATH=$(pybuilddir)-$${pyv} ./pysam_test_offline.py ; \
- done
-endif
+ dh_auto_test # default tests
+ PYBUILD_SYSTEM=custom \
+ PYBUILD_TEST_ARGS=cd tests PYTHONPATH={build_dir} {interpreter} ./pysam_test_offline.py \
+ dh_auto_test --buildsystem=pybuild
override_dh_install-indep:
dh_install -p $(TESTPKG)
Bug#739663: Processed: libboinc7: fails to upgrade from 'wheezy' - trying to overwrite /usr/lib/libboinc_zip.so.7
On 2014-02-21 14:37, Gianfranco Costamagna wrote: Hi Andreas, I tried to add a Break+Replaces, but it didn't work, How did this look like? And how did it fail? I think because now boinc-dev is not a real package anymore, just a transition virtual package. Since the B+R you add are versioned, they only match against real packages. And the old one is a real package. For this reason I only added a breaks on libboinc7, and I tested on a virtual machine. It seems to be working, but this is the first time I play with breaks/replaces fields, so I might be wrong somewhere. This probably breaks if I torture-test it :-) And it will definitely break in case you add a transitional boing-dev package. this is the commit, I'll upload a version in the next few days if no answer, since I think this bug is pretty serious. http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc.git;a=commitdiff;h=c993dd1d92d58a03562c52c3d2f8b180303eb84f Can I kindly ask you to review the patch? 7.0.39+dfsg-1 is the version that split up boinc-dev? And this was the first upload of the new 7.0.39+dfsg upstream, i.e. there have not been any 7.0.39+dfsg-1~experimental0 or similar versions? So each package that got a bit of the previous content (and ships it at the same location) should have Breaks: boinc-dev ( 7.0.39+dfsg) Replaces: boinc-dev ( 7.0.39+dfsg) (in addition to other B+R it might already have). (this review is based solely on your reply and the commitdiff you linked, I haven't looked at the boinc package in more detail, but I might take a further look at the weekend) Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619244: [Pkg-systemd-maintainers] Bug#619244: /etc/machine-id
Hello all, Simon McVittie [2014-02-21 10:05 +]: I've wondered whether to ask base-files or some similarly core package to provide /etc/machine-id so that it exists even on non-systemd systems; it would be easy to populate from something like sed s/-// /proc/sys/kernel/random/uuid on Linux, and perhaps /dev/[u]random on non-Linux. Do you think that's a good idea? I don't think it's a bad idea. But are non-systemd systems going to care about this file at all? I've never quite liked this file as it isn't really configuration but state; it should be in /var/lib somewhere IMHO. But aside from that: if we don't get it in base-files, we could at least do either of: * change systemd to read /var/lib/dbus/machine-id if /etc/machine-id does not exist (my preferred solution), or * change dbus-1 to create a symlink of /var/lib/dbus/machine-id to /etc/machine-id, if /etc/machine-id does not already exist. With upcoming kdbus we might be able to drop dbus-1 in a few releases, and then need to revisit this. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739700: ITP: python-smstrade -- Python library and command line tool to send SMS via the smstrade service
Package: wnpp Severity: wishlist Owner: Jan Dittberner ja...@debian.org * Package name: python-smstrade Version : 0.2.1 Upstream Author : Jan Dittberner j...@dittberner.info * URL : https://pypi.python.org/pypi/smstrade/ * License : MIT Programming Lang: Python Description : Python library and command line tool to send SMS via the smstrade service This library implements a wrapper for the SMS sending API of smstrade.eu. The package also provides command line tools to send SMS as well as get the current account balance. The package can be used in scenarios such as alerting from monitoring tools. -- Jan Dittberner - Debian Developer GPG-key: 4096R/558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD http://portfolio.debian.net/ - http://people.debian.org/~jandd/ signature.asc Description: Digital signature
Bug#739687: update-flashplugin-nonfree --install downloads the old version
Here is the output of update-flashplugin-nonfree --install --verbose -- root@zertz:~# update-flashplugin-nonfree --install --verbose options : --install --verbose -- temporary directory: /tmp/flashplugin-nonfree.QGVd30oHoZ importing public key ... selected action = --install installed version = 11.2.202.336 upstream version = 11.2.202.341 wgetoptions= -nd -P . -v --progress=dot:default downloading http://people.debian.org/~bartm/flashplugin-nonfree/fp.11.2.202.341.sha512.amd64.pgp.asc ... --2014-02-21 14:39:47-- http://people.debian.org/~bartm/flashplugin-nonfree/fp.11.2.202.341.sha512.amd64.pgp.asc Auflösen des Hostnamen »people.debian.org (people.debian.org)«... 206.12.19.5, 2607:f8f0:610:4000:214:38ff:feee:b65a Verbindungsaufbau zu people.debian.org (people.debian.org)|206.12.19.5|:80... verbunden. HTTP-Anforderung gesendet, warte auf Antwort... 404 Not Found wget failed to download http://people.debian.org/~bartm/flashplugin-nonfree/fp.11.2.202.341.sha512.amd64.pgp.asc downloading http://people.debian.org/~bartm/flashplugin-nonfree/fp10.sha512.amd64.pgp.asc ... --2014-02-21 14:39:48-- http://people.debian.org/~bartm/flashplugin-nonfree/fp10.sha512.amd64.pgp.asc Auflösen des Hostnamen »people.debian.org (people.debian.org)«... 206.12.19.5, 2607:f8f0:610:4000:214:38ff:feee:b65a Verbindungsaufbau zu people.debian.org (people.debian.org)|206.12.19.5|:80... verbunden. HTTP-Anforderung gesendet, warte auf Antwort... 200 OK Länge: 1273 (1,2K) [text/plain] In »»./fp10.sha512.amd64.pgp.asc«« speichern. 0K . 100% 95,1M=0s 2014-02-21 14:39:48 (95,1 MB/s) - »»./fp10.sha512.amd64.pgp.asc«« gespeichert [1273/1273] verifying PGP fp10.sha512.amd64.pgp.asc ... copying /var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz ... verifying checksum install_flash_player_11_linux.x86_64.tar.gz ... wgetoptions= -nd -P . -v --progress=dot:default -O /tmp/flashplugin-nonfree.QGVd30oHoZ/install_flash_player_11_linux.x86_64.tar.gz downloading http://fpdownload.macromedia.com/get/flashplayer/pdc/11.2.202.336/install_flash_player_11_linux.x86_64.tar.gz ... verifying checksum install_flash_player_11_linux.x86_64.tar.gz ... unpacking install_flash_player_11_linux.x86_64.tar.gz ... verifying checksum contents of install_flash_player_11_linux.x86_64.tar.gz ... moving libflashplayer.so to /usr/lib/flashplugin-nonfree ... setting permissions and ownership of /usr/lib/flashplugin-nonfree/libflashplayer.so ... Flash Player version: 11.2.202.336 moving install_flash_player_11_linux.x86_64.tar.gz to /var/cache/flashplugin-nonfree ... flash-mozilla.so - Auto-Modus Link verweist zur Zeit auf /usr/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplayer.so - Priorität 50 Gegenwärtig »beste« Version ist »/usr/lib/flashplugin-nonfree/libflashplayer.so«. calling update-alternatives ... flash-mozilla.so - Auto-Modus Link verweist zur Zeit auf /usr/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplayer.so - Priorität 50 Gegenwärtig »beste« Version ist »/usr/lib/flashplugin-nonfree/libflashplayer.so«. removing /usr/bin/flash-player-properties removing /usr/share/applications/flash-player-properties.desktop removing /usr/share/icons/hicolor/16x16/apps/flash-player-properties.png removing /usr/share/icons/hicolor/22x22/apps/flash-player-properties.png removing /usr/share/icons/hicolor/24x24/apps/flash-player-properties.png removing /usr/share/icons/hicolor/32x32/apps/flash-player-properties.png removing /usr/share/icons/hicolor/48x48/apps/flash-player-properties.png removing /usr/share/pixmaps/flash-player-properties.png installing /usr/bin/flash-player-properties installing /usr/share/applications/flash-player-properties.desktop installing /usr/share/icons/hicolor/16x16/apps/flash-player-properties.png installing /usr/share/icons/hicolor/22x22/apps/flash-player-properties.png installing /usr/share/icons/hicolor/24x24/apps/flash-player-properties.png installing /usr/share/icons/hicolor/32x32/apps/flash-player-properties.png installing /usr/share/icons/hicolor/48x48/apps/flash-player-properties.png installing /usr/share/pixmaps/flash-player-properties.png end of action --install cleaning up temporary directory /tmp/flashplugin-nonfree.QGVd30oHoZ ... end of update-flashplugin-nonfree root@zertz:~# --- The downloaded file /var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz does not contain the new version 11.2.202.341 but rather the old version 11.2.202.336. (aktually this file was there before. But if I delete the file, update-flashplugin-nonfree will download it again.) (Martin Ziegler) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Bug#737770: Duplicate
forcemerge 714296 737770 severity 714296 serious thanks #737770 is a duplicate of #714296. Moreover, I think this is a serious problem in dia that heavily impacts is usability, next to making it useless (how useful is a diagram drawing tool where you can't use labels whatsoever?). Thus, I'm raising the severity. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#733352: [Debian-med-packaging] Bug#733398: Should we create a seqan1.3 package for bowtie and tophat
On 02/21/2014 02:21 PM, Andreas Tille wrote: Hi, since both packages bowtie (1.0!) and tophat stopped building from source since we switched to seqan 1.4 (both bug reports in CC) and upstream of both programs did not responded since three weeks I wonder whether we should reintroduce a seqan 1.3 package to be able to build the packages again. As far as I understood both have some relevance in several workflows and we should not leave these with release critical bugs. those programs are indeed commonly used in bioinformatics and are really necessary. Keeping an older version of seqan would be a good idea. Olivier Any opinions? Kind regards Andreas. -- Olivier Sallou IRISA / University of Rennes 1 Campus de Beaulieu, 35000 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619244: /etc/machine-id
On Fri, Feb 21, 2014 at 10:05:52AM +, Simon McVittie wrote: On Sun, 21 Jul 2013 at 13:23:48 +0200, Michael Stapelberg wrote: Programs may use this ID to identify the host with a globally unique ID in the network, which does not change even if the local network configuration changes. Due to this and its greater length, it is a more useful replacement for the gethostid(3) call that POSIX specifies. I've wondered whether to ask base-files or some similarly core package to provide /etc/machine-id so that it exists even on non-systemd systems; it would be easy to populate from something like sed s/-// /proc/sys/kernel/random/uuid on Linux, and perhaps /dev/[u]random on non-Linux. Do you think that's a good idea? It would have the side-effect of resolving this bug. That seems like a great idea. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619244: [Pkg-systemd-maintainers] Bug#619244: /etc/machine-id
On Fri, Feb 21, 2014 at 06:04:42AM -0800, Martin Pitt wrote: Simon McVittie [2014-02-21 10:05 +]: I've wondered whether to ask base-files or some similarly core package to provide /etc/machine-id so that it exists even on non-systemd systems; it would be easy to populate from something like sed s/-// /proc/sys/kernel/random/uuid on Linux, and perhaps /dev/[u]random on non-Linux. Do you think that's a good idea? I don't think it's a bad idea. But are non-systemd systems going to care about this file at all? I've never quite liked this file as it isn't really configuration but state; it should be in /var/lib somewhere IMHO. I agree that it it provides state rather than configuration, but /var/lib won't work, for much the same reason that led to making /run to replace /var/run: /var can legitimately be a separately mounted filesystem, and machine-id may well be needed early. Unfortunately, there's no /var-like persistent guaranteed-to-be-on-/ filesystem to use here. You could put machine-id in lib (/lib/machine-id), though that doesn't really fit, but in any case you'll need a symlink from /etc. At which point you might as well just put it in /etc. But aside from that: if we don't get it in base-files, we could at least do either of: * change systemd to read /var/lib/dbus/machine-id if /etc/machine-id does not exist (my preferred solution), or See above: /var is too late. * change dbus-1 to create a symlink of /var/lib/dbus/machine-id to /etc/machine-id, if /etc/machine-id does not already exist. Likewise. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739079: transition: libav10
Hi, (a libav developer responsible for most of the breaks here) I do not think bringing back the CODEC_ID_* stuff is such a great idea. The reasons are: - keeping compatibility in this case requires a rather ugly hack (because in c++ different enums are not compatible), which has to my knowledge broken at least one program (this is also the reason the change was made -- CODEC_ID is a very generic identifier, so there's a rather high chance of conflicts) - experience tells us that the downstreams generally do not adapt until they have to, so this would just postpone the breakage for a time, we'd still have to deal with it eventually - adapting to this specific change in Debian is a trivial replacement that can be done with sed (since only one libav version needs to be supported). Fixing downstreams that want to support older libav versions is a little more involved, but still no rocket science; I've already sent patches to a number of downstreams, but some are slow to respond, or want to support very old versions. If you don't mind carrying some patches until the downstreams fix their stuff, I can write Debian-specific patches that only work with latest Libav (jitsi comes to mind here, most other complex breakage should be fixed already) Finally, I'm sorry that the changes are causing so much pain to our downstreams, but I believe they are necessary and must be made sooner or later. Regards -- Anton Khirnov -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739634: dpkg-maintscript-helper supports always returns 1
Control: reopen -1 On Fri, 2014-02-21 at 11:07:38 +0100, Eugen Dedu wrote: On 20/02/14 21:38, Guillem Jover wrote: On Thu, 2014-02-20 at 18:23:59 +0100, Eugen Dedu wrote: I need to use dir_to_symlink and see in 'man dpkg-maintscript-helper': [...] we can call the program only if we know that the required command is supported by the currently installed dpkg: if dpkg-maintscript-helper supports command; then dpkg-maintscript-helper command ... fi On my computer dpkg-maintscript-helper supports always returns 1: snoopy:~$ dpkg-maintscript-helper supports dir_to_symlink; echo $? dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_NAME missing dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing 1 snoopy:~$ dpkg-maintscript-helper supports fasdfa; echo $? dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_NAME missing dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing 1 snoopy:~$ dpkg-maintscript-helper supports xyz; echo $? dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_NAME missing dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing 1 Tha's because the mentioned variables are not defined in the environment, as dpkg does. Check this instead: $ env DPKG_MAINTSCRIPT_NAME=postinst DPKG_MAINTSCRIPT_PACKAGE=pkg \ dpkg-maintscript-helper supports dir_to_symlink $ echo $? 0 I'm thus closing this bug report. May I suggest to add this information on the man page? I think it is not evident to see that the program might give different results depending on the environment variables. (By the way, I myself do not see why it gives different results.) Ok, I'm adding that explicitly, although it's implicitly already there, when mentioning the environment variables and given that the program is a maintscript helper, but I guess it might not be obvious. If gives different results, because if those envvars are not defined then the commands will always fail, which is the equivalent of not supporting them. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739702: xfce4-power-manager: 2 power manager icons in system tray
Package: xfce4-power-manager Version: 1.2.0-3 Severity: normal Dear Maintainer, * What led up to the situation? regular apt-get update / apt-get dist-upgrade * What exactly did you do (or not do) that was effective (or ineffective)? tried rebooting * What was the outcome of this action? no change * What outcome did you expect instead? a single power manager icon in the system tray :) -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xfce4-power-manager depends on: ii libc6 2.17-97 ii libdbus-1-3 1.8.0-1 ii libdbus-glib-1-2 0.100.2-1 ii libgdk-pixbuf2.0-02.28.2-1+b1 ii libglib2.0-0 2.38.2-5 ii libgtk2.0-0 2.24.22-1 ii libnotify40.7.6-1 ii libx11-6 2:1.6.2-1 ii libxext6 2:1.3.2-1 ii libxfce4ui-1-04.10.0-5 ii libxfce4util6 4.10.1-1 ii libxfconf-0-2 4.10.0-2 ii libxrandr22:1.4.2-1 ii upower0.9.23-2+b1 ii xfce4-power-manager-data 1.2.0-3 Versions of packages xfce4-power-manager recommends: ii consolekit 0.4.6-3+b1 Versions of packages xfce4-power-manager suggests: ii udisks 1.0.4-8+b1 ii xfce4-power-manager-plugins 1.2.0-3 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739634: dpkg-maintscript-helper supports always returns 1
On 21/02/14 16:10, Guillem Jover wrote: Control: reopen -1 On Fri, 2014-02-21 at 11:07:38 +0100, Eugen Dedu wrote: On 20/02/14 21:38, Guillem Jover wrote: On Thu, 2014-02-20 at 18:23:59 +0100, Eugen Dedu wrote: I need to use dir_to_symlink and see in 'man dpkg-maintscript-helper': [...] we can call the program only if we know that the required command is supported by the currently installed dpkg: if dpkg-maintscript-helper supports command; then dpkg-maintscript-helper command ... fi On my computer dpkg-maintscript-helper supports always returns 1: snoopy:~$ dpkg-maintscript-helper supports dir_to_symlink; echo $? dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_NAME missing dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing 1 snoopy:~$ dpkg-maintscript-helper supports fasdfa; echo $? dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_NAME missing dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing 1 snoopy:~$ dpkg-maintscript-helper supports xyz; echo $? dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_NAME missing dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing 1 Tha's because the mentioned variables are not defined in the environment, as dpkg does. Check this instead: $ env DPKG_MAINTSCRIPT_NAME=postinst DPKG_MAINTSCRIPT_PACKAGE=pkg \ dpkg-maintscript-helper supports dir_to_symlink $ echo $? 0 I'm thus closing this bug report. May I suggest to add this information on the man page? I think it is not evident to see that the program might give different results depending on the environment variables. (By the way, I myself do not see why it gives different results.) Ok, I'm adding that explicitly, although it's implicitly already there, when mentioning the environment variables and given that the program is a maintscript helper, but I guess it might not be obvious. If gives different results, because if those envvars are not defined then the commands will always fail, which is the equivalent of not supporting them. Sorry to ask again: why do these commands fail if no env var is set? It is a matter of checking if dpkg supports some command or not. Is this done voluntarily (why?) or it is a limitation (bug) in the program? Perhaps I miss something here? -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739703: openrc: slow shutdown on current git snapshot
Package: openrc Version: 0.12.4+20131230-9~gg1 Severity: normal [ bug in git snapshot, not yet released ] e3b710b introduced a slower shutdown. It takes almost one minute between Mounting root filesystem read-only...mount: cannot remount /: Device or resource busy failed. from /etc/init.d/umountroot and * reboot runlevel... ...Will now restart. messages. e3b710b New version of the lsb2rcconf (LSB header support) patch. -- System Information: Debian Release: jessie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable'), (1, 'experimental') Architecture: hurd-i386 (i686-AT386) Kernel: GNU-Mach 1.4-486-dbg/Hurd-0.5 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 openrc depends on: ii insserv1.14.0-5 ii libc0.32.17-98~1+hurd.0+rbraun.1 ii libeinfo1 0.12.4+20131230-9~gg1 ii librc1 0.12.4+20131230-9~gg1 openrc recommends no packages. openrc 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#739704: RM: dotur -- ROM; Package is deprecated by upstream
Package: ftp.debian.org Severity: normal Hi, upstream has deprecated dotur and the expected user audience has stoped using it. See for instance here: https://lists.debian.org/debian-med/2014/02/msg00214.html So please remove this package from Debian testing + unstable. I see no specific reason to also remove it from stable - in the best case it will be simply ignored there. Thanks for your work as ftpmaster Andreas. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
* Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:41]: Andreas Barth writes (Bug#727708: init system coupling etc.): Russ Allbery (r...@debian.org) [140219 19:24]: So I propose to change the text: The Technical Committee offers no advice at this time on requirements or package dependencies on specific init systems after the jessie release. There are too many variables at this point to know what the correct course of action will be. to | The Technical Committee offers no advice regarding sysvinit | compatibility at this time after the jessie release. There are too | many variables at this point to know what the correct course of action | will be. (the empty line above is there by purpose, i.e. it also merges this paragraph with the previous one) Looking at Russ's draft, he has already made an effectively identical change. Russ's wording is: The Technical Committee offers no advice at this time on sysvinit support beyond the jessie release. There are too many variables at this point to know what the correct course of action will be. This differs from yours in the placement of at this time (see my previous mail) and in that it uses beyond the jessie release rather than after the jessie release. These don't seem to change the meaning much for me but improve the way it reads. You may wish to adopt Russ's wording. I do. Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
* Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:37]: Andreas Barth writes (Bug#727708: init system coupling etc.): Russ Allbery (r...@debian.org) [140219 19:24]: How does this sound to you? Packages should normally support the default init system on all architectures for which they are built. There are some exceptional cases where lack of support for the default init system may be appropriate, such as alternative init system implementations, special-use packages such as managers for non-default init systems, and cooperating groups of packages intended for use with non-default init systems. However, package maintainers should be aware that a requirement for a non-default init system will mean the package will be unusable for most Debian users and should normally be avoided. Better but I think we should also point out that supporting different architectures is a good thing. So the first sentence rather as | Packages should support as many architectures as reasonably possible, | and they should normally ... Also I'd like to amend the last sentence with , and could constitute an serious bug of the package. (which is a correct observation according to the current RC policy) Russ has already amended his text to say Software should So when transposing your amendment onto Russ's new text, I have to decide between using your new text verbatim (effectively reverting that change), or treating your proposal as a request to change only the parts you are actually aiming at. I'm going to do the latter because it appears to best reflect your intent. This results in Yes, that was the intention (basically it was a patch). Thanks. Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
Ian Jackson ijack...@chiark.greenend.org.uk writes: I've done so, thanks. Looks good. -- keith.pack...@intel.com pgpGCVcBThsUQ.pgp Description: PGP signature
Bug#727708: init system coupling etc.
* Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:29]: Andreas Barth writes (Bug#727708: init system coupling etc.): So I propose to change the text: The Technical Committee offers no advice at this time on requirements or package dependencies on specific init systems after the jessie release. There are too many variables at this point to know what the correct course of action will be. to | The Technical Committee offers no advice regarding sysvinit | compatibility at this time after the jessie release. There are too | many variables at this point to know what the correct course of action | will be. (the empty line above is there by purpose, i.e. it also merges this paragraph with the previous one) I will transpose this into git. As an observation from a native English speaker, the language is rather odd. It is not conventional to have two time clauses next to each other like that. I would suggest (but do not formally propose): The Technical Committee offers no advice at this time regarding sysvinit compatibility after the jessie release. There are too many variables at this point to know what the correct course of action will be. Ie, move at this time to after advice. Thanks, accepted. Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739705: ITP: python-pretend -- Library for stubbing in Python
Package: wnpp Severity: wishlist Owner: Tristan Seligmann mithra...@mithrandi.net * Package name: python-pretend Version : 1.0.7 Upstream Author : Alex Gaynor * URL : https://pypi.python.org/pypi/pretend * License : BSD Programming Lang: Python Description : Library for stubbing in Python Pretend is a library to make stubbing with Python easier. Stubbing is a technique for writing tests. You may hear the term mixed up with mocks, fakes, or doubles. Basically a stub is an object that returns pre-canned responses, rather than doing any computation. This package is a dependency of the python-cryptography test suite, I will be maintaining it in the Debian Python Modules Team SVN repository. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739706: ITP: python-iso8601 -- Simple module to parse ISO 8601 dates
Package: wnpp Severity: wishlist Owner: Tristan Seligmann mithra...@mithrandi.net * Package name: python-iso8601 Version : 0.1.8 Upstream Author : Michael Twomey * URL : https://pypi.python.org/pypi/iso8601 * License : MIT (Expat) Programming Lang: Python Description : Simple module to parse ISO 8601 dates This module parses the most common forms of ISO 8601 date strings (e.g. 2007-01-14T20:34:22+00:00) into datetime objects. For a more featureful parser, look at python-dateutil instead. This package is a dependency of the python-cryptography test suite; I will be maintaining it in the Debian Python Modules Team SVN repository. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
Andreas Barth writes (Re: Bug#727708: init system coupling etc.): Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:41]: Looking at Russ's draft, he has already made an effectively identical change. Russ's wording is: The Technical Committee offers no advice at this time on sysvinit support beyond the jessie release. There are too many variables at this point to know what the correct course of action will be. This differs from yours in the placement of at this time (see my previous mail) and in that it uses beyond the jessie release rather than after the jessie release. These don't seem to change the meaning much for me but improve the way it reads. You may wish to adopt Russ's wording. I do. Thanks, transferred to git. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733556:
Just FYI, here is how to fix the current package: $ wget http://ftp.de.debian.org/debian/pool/main/w/wine/wine-bin_1.4.1-4_i386.deb $ dpkg-deb -x wine-bin_1.4.1-4_i386.deb bla $ sudo cp bla/usr/share/binfmts/wine /usr/share/binfmts $ sudo /usr/sbin/update-binfmts --import wine Enjoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739530: systemd support for monit
Hi, Am 20.02.2014 10:44, schrieb Sergey Kirpichev: Regarding other stuff in the patch, does it work for hurd/kfreebsd? E.g. doesn't break builds, installation and so on. The patch was created with the current recommendations[0] of the systemd maintainer on how to add systemd support to packages (they looked at the patch before I filed this bug report). I cannot guarantee, that it will not break stuff on hurd/kfreebsd, but I do not think that it will. Other packages like colord seem to work fine with it. Is this patch was tested, if so - how? I tested the patch on a VM with Debian testing. Under sysvinit the init script will be used, so there is no difference. Under systemd the service file will be used. I looked, if monit starts, stops and reloads correctly. For this I also added a simple service check in monit, that works correctly under systemd. There is currently a difference for /etc/default/monit, because it does not use the variables there. With systemd it is not recommended to disable a service there (START variable), because systemd has its own mechanism (systemctl enable monit/systemctl disable monit). I could add support for the MONIT_OPTS variable. Currently the trend seems to be to drop the default file, but it is probably better to have support for MONIT_OPTS as long as the init script supports it. What do you think? If I should add it, I will update the patch. If you have any further questions or if I should test some other use cases, I would happily look into it. [0] https://wiki.debian.org/systemd/Packaging -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703188: Offer to sponsor ruby-pygments.rb
Hi Dominique, Dominique Dumont d...@debian.org writes: Axel, if you're willing to take over packaging of ruby-pygments.rb, I'll find the time to sponsor this package. thanks, that is very kind. If I'm correct the way to move forward would be addressing the issues raised in [1]? I will have a look at that tomorrow then. Best, Axel [1] http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/2013-July/015643.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738326: live-build installs extra packages (suggests or based on source package instead of binary)
On 21/02/14 05:04 AM, Diederik de Haas wrote: On Thursday 20 February 2014 20:23:17 Daniel Dickinson wrote: I still suspect a bug because NONE of the Recommends on or Depends packages for gnuplot are shown as being installed Maybe I'm overlooking something, but have you started/booted your image and then did an aptitude why gnuplot ? It should tell you why gnuplot is/was installed. Apparently for all that I have been using Debian for years (but am not a developer or hard core) there are still lots of things for me to learn. I didn't know about either aptitude why or debtree. In any event aptitude why says: i amanda-client Suggests gnuplot which give credence to my theory that there is bug. Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#727708: init system coupling etc.
For Andi's version of Russ's text I have written this summary line into the git repo: B Advice: sysvinit compatibility in jessie and multi init, arch, support The difference between Russ's (A) and Andi's (B) is precisely this: Software should normally support the default init system on all --- Software should support as many architectures as reasonably possible, and it should normally support the default init system on all If Russ does not accept this amendment then both A and B will be on the ballot. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686869: BinkD upstream v1.0 now available
Package: binkd Followup-For: Bug #686869 Please notice that version 1.0.2 was released 2013/06/29. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738326: live-build installs extra packages (suggests or based on source package instead of binary)
On 21/02/14 11:06 AM, Daniel Dickinson wrote: On 21/02/14 05:04 AM, Diederik de Haas wrote: On Thursday 20 February 2014 20:23:17 Daniel Dickinson wrote: I still suspect a bug because NONE of the Recommends on or Depends packages for gnuplot are shown as being installed Maybe I'm overlooking something, but have you started/booted your image and then did an aptitude why gnuplot ? It should tell you why gnuplot is/was installed. Apparently for all that I have been using Debian for years (but am not a developer or hard core) there are still lots of things for me to learn. I didn't know about either aptitude why or debtree. In any event aptitude why says: i amanda-client Suggests gnuplot which give credence to my theory that there is bug. I've a attached the list of packages that are in my package lists, after removing any conditionals and extraneous whitespace or comments. I you can see something other than amanda-client Suggests gnuplot from that list, I'd love to know what it is. BTW debtree doesn't do what I had gathered from the suggestion to use it (take a list of package and show their dependencies, while on the build system) Regards, Daniel vlan tcptraceroute tcptrack tcpdump tcpstat stunnel4 socat sshfs rsync ntp ssh molly-guard nbtscan btscanner ndpmon netcat-openbsd netdiag netdiscover netstat-nat lldpd libnss-gw-name libnss-mdns libnss-myhostname ifmetric ifstat iftop iputils-tracepath httping fail2ban sshguard fping ethstatus avahi-autoipd unison-all cifs-utils samba samba-tools smbclient avahi-daemon avahi-utils xz-utils zip unzip rar unrar pbzip2 plzip lzip cabextract linuxlogo picocom unrtf unsort tmux gamin sharutils strace sudo realpath mg zile emacs23-nox members md5deep mcrypt ccrypt lsof gnupg gnupg-agent fortune-mod fortunes-bofh-excuses fortunes-debian-hints etckeeper debconf-utils debianutils configure-debian byobu aespipe amanda-client anacron apt-show-versions apt-listchanges clamav pinentry-curses zerofree scrub partclone partimage ntfsdoc ntfsprogs fsarchiver dosfstools cryptsetup cryptsetup-bin ntfs-3g pciutils lm-sensors sensord scsitools sdparm hdparm nictools-pci mesa-utils mii-diag memtest86 memtest86+ lsscsi lshw firmware-linux ethtool cmospwd hddtemp smartmontools alsa-utils syslog-ng logwatch fwanalog iotop bootlogd sysstat rkhunter debsums tofrodos dos2unix live-manual live-tools live-boot wbritish wcanadian wcanadian-small task-english console-tools memtest86+ zerofree testdisk parted syslinux mbr scrub wipe fuse-utils zfs-fuse partclone partimage fsarchiver cdrdao fuseiso growisofs iotop bootlogd logtail logwatch nut-client aespipe amanda-client boxbackup-client apg arc arj plzip pbzip2 zoo unar unalz unp xz-utils ascii bsd-mailx fakeroot ldap-utils mutt patch patchutils pax pax-utils realpath reportbug sharutils unrtf unsort uuid bcrelay avahi-autoipd conntrack davfs2 fping fusedav libnss-myhostname libnss-gw-name lrzsz netstat-nat ndpmon openresolv shorewall shorewall6 sshfs stunnel4 tcpstat tftp-hpa tftpd-hpa avahi-utils libnss-mdns avahi-daemon btscanner bluez-firmware bluez-hcidump ifmetric ifstat iperf iw wavemon kismet kismet binstats binutils elfutils strace mcrypt ccrypt pinentry-curses pwgen unhide.rb molly-guard sshguard haveged cmospwd devio i2c-tools lm-sensors mesa-utils nictools-pci read-edid regionset scsitools sensord sg3-utils sdparm vbetool usbutils db-util db5.1-util diffutils wdiff dctrl-tools debconf-utils debianutils debsums zile mg ncurses-hexedit vim members scalpel syslinux-common grub lilo mbr syslinux extlinux gnupg dash discover gawk htop less lsof ltrace psmisc screen strace units pstack tcsh vlock mailutils moreutils aview mc nano-tiny mg vim wdiff hexedit nvi tweak dvd+rw-tools genisoimage sdparm hdparm blktool parted partimage secure-delete scsitools smartmontools testdisk wodim wipe hddtemp bonnie++ par2 dvd+rw-tools fsarchiver chiark-utils-bin dmidecode mcelog cpuburn lshw pciutils procinfo usbutils sysstat stress read-edid lynx links2 w3m arj bzip2 lzma p7zip-full unace unrar-free unzip zip lzop ncompress unace pax rar unrar sl-modem-daemon b43-fwcutter dar gddrescue dump dcfldd mt-st rdiff rsnapshot colordiff chrootuid cpio cryptcat etherwake ftp ifrename ethtool ipcalc mii-diag gkermit netcat netcat6 netmask openssl openvpn sipcalc socat ssh telnet whois pv manpages acl symlinks bsdmainutils denyhosts fail2ban iptables knockd portsentry vlan netbase ntpdate isc-dhcp-client ppp pppconfig pppoe pppoeconf atm-tools bridge-utils ebtables parprouted br2684ctl cutter iproute iproute-doc iputils-tracepath mtr-tiny tcptraceroute traceroute spinner arpalert arpwatch atsar bmon ethstatus geoip-bin hp-search-mac icmpinfo ifstat iftop ipgrab iptstate iptraf lft nast nbtscan netdiscover nload nstreams saidar scanssh sntop ssldump tcpdump tcpreen tcpreplay tshark crashme dbench doscan dsniff hping3 icmpush macchanger medusa netdiag netpipe-tcp ndisc6 ngrep p0f packit xprobe fwanalog libgd2-noxpm fwlogwatch
Bug#739707: binkd: init script produces warning if inetd not installed
Package: binkd Version: 0.9.9+rel-2 Severity: normal Hi, the binkd init script produces a warning message when called telling me that /etc/inetd.conf is missing. This is perfectly true, since I don't run inetd. Replacing the line: grep -q '^binkp[[:space:]]' /etc/inetd.conf exit 0 with [ -f /etc/inetd.conf ] \ grep -q '^binkp[[:space:]]' /etc/inetd.conf exit 0 in /etc/init.d/binkd makes the warning disappear. It is worth considering to remove this check completely, since the client and server part of binkd can be run independently. Please notice that the bug report is written on a different machine. Regards, Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
On Fri, Feb 21, 2014 at 01:29:40AM +, peter green wrote: Thomas Orgis wrote: So, I got conversion to float implemented now and tested with the generic_nofpu decoder on x86-64. It _should_ of course work with ARM, too;-) If you'd like to check the current snapshot of mpg123, http://mpg123.org/snapshot/mpg123-20140220132548.tar.bz2 , you hopefull will find that any normal build of mpg123 (unless specifying --disable-float explicitly) now offers all usual formats. As a bonus, I even implemented the 8 Bit A-Law output, which has always just been a placeholder (nobody missed it, apparently). I'd be interested on some timings of mpg123 -t -e s16 test.mp3 mpg123 -t -e f32 test.mp3 with the various builds you'll do for the ARM variants. Best would be running perl scripts/benchmark-cpu.pl src/mpg123 convergence_-_points_of_view/*.mp3 with http://mpg123.orgis.org/convergence_-_points_of_view.tar.gz as reference album, as mentioned on http://mpg123.orgis.org/benchmarking.shtml to be able to compare the performance of the code and machine to others. This yields output like this: #mpg123 benchmark (user CPU time in seconds for decoding) #decoder t_s16/s t_f32/s x86-64 3.394.05 generic 6.156.01 generic_dither 6.365.97 ... or this, with --with-cpu=generic_fpu: #mpg123 benchmark (user CPU time in seconds for decoding) #decoder t_s16/s t_f32/s generic 6.146.29 (on a Core2Duo machine) Ok, on a 1GHz freescale IMX53 (cortex A8) in a (probablly somewhat out of date) debian sid armhf chroot I tested with perl scripts/benchmark-cpu.pl src/mpg123 convergence_-_points_of_view/*.mp3 in the following configurations. Built with ./configure --with-cpu=arm_nofpu #mpg123 benchmark (user CPU time in seconds for decoding) #decodert_s16/s t_f32/s ARM 30.36 34.26 Built with ./configure --with-cpu=generic_fpu #mpg123 benchmark (user CPU time in seconds for decoding) #decodert_s16/s t_f32/s generic 148.66 138.49 Build with CFLAGS=-mfpu=neon ./configure --with-cpu=neon #mpg123 benchmark (user CPU time in seconds for decoding) #decodert_s16/s t_f32/s NEON0.030.04 I found the neon result unbelivable so I decided to run the test program you mentioned to me in my private mail asking about how to run the benchmarks. root@plugwash:/mpg123-test# LD_LIBRARY_PATH=/mpg123-20140220132548-arm_nofpu/src/libmpg123/.libs/ perl compliance.pl /mpg123-20140220132548-arm_nofpu/src/mpg123 Layer 1 -- 16 bit signed integer output fl1.bit:RMS=3.486054e-02 (FAIL) maxdiff=5.002832e-02 (FAIL) fl2.bit:RMS=3.485670e-02 (FAIL) maxdiff=5.008233e-02 (FAIL) fl3.bit:RMS=3.485293e-02 (FAIL) maxdiff=5.008245e-02 (FAIL) fl4.bit:RMS=1.510105e-01 (FAIL) maxdiff=5.277658e-01 (FAIL) fl5.bit:RMS=3.109439e-01 (FAIL) maxdiff=4.475173e-01 (FAIL) fl6.bit:RMS=1.649138e-01 (FAIL) maxdiff=4.589995e-01 (FAIL) fl7.bit:RMS=2.211659e-02 (FAIL) maxdiff=2.959942e-01 (FAIL) fl8.bit:RMS=3.484906e-02 (FAIL) maxdiff=5.002034e-02 (FAIL) -- 32 bit integer output fl1.bit:RMS=3.486054e-02 (FAIL) maxdiff=5.002832e-02 (FAIL) fl2.bit:RMS=3.485670e-02 (FAIL) maxdiff=5.008233e-02 (FAIL) fl3.bit:RMS=3.485293e-02 (FAIL) maxdiff=5.008245e-02 (FAIL) fl4.bit:RMS=1.513207e-01 (FAIL) maxdiff=4.787517e-01 (FAIL) fl5.bit:RMS=3.109439e-01 (FAIL) maxdiff=4.475173e-01 (FAIL) fl6.bit:RMS=1.649138e-01 (FAIL) maxdiff=4.589995e-01 (FAIL) fl7.bit:RMS=2.211659e-02 (FAIL) maxdiff=2.959942e-01 (FAIL) fl8.bit:RMS=3.484906e-02 (FAIL) maxdiff=5.002034e-02 (FAIL) -- 24 bit integer output fl1.bit:RMS=3.486054e-02 (FAIL) maxdiff=5.002832e-02 (FAIL) fl2.bit:RMS=3.485670e-02 (FAIL) maxdiff=5.008233e-02 (FAIL) fl3.bit:RMS=3.485293e-02 (FAIL) maxdiff=5.008245e-02 (FAIL) fl4.bit:RMS=1.494715e-01 (FAIL) maxdiff=4.984906e-01 (FAIL) fl5.bit:RMS=3.109439e-01 (FAIL) maxdiff=4.475173e-01 (FAIL) fl6.bit:RMS=1.649138e-01 (FAIL) maxdiff=4.589995e-01 (FAIL) fl7.bit:RMS=2.211659e-02 (FAIL) maxdiff=2.959942e-01 (FAIL) fl8.bit:RMS=3.484906e-02 (FAIL) maxdiff=5.002034e-02 (FAIL) -- 32 bit floating point output fl1.bit:RMS=3.486054e-02 (FAIL) maxdiff=5.002832e-02 (FAIL) fl2.bit:RMS=3.485670e-02 (FAIL) maxdiff=5.008233e-02 (FAIL) fl3.bit:RMS=3.485293e-02 (FAIL) maxdiff=5.008245e-02 (FAIL) fl4.bit:RMS=1.137037e-01 (FAIL) maxdiff=4.459082e-01 (FAIL) fl5.bit:RMS=3.109439e-01 (FAIL) maxdiff=4.475173e-01 (FAIL) fl6.bit:RMS=1.649138e-01 (FAIL) maxdiff=4.589995e-01 (FAIL) fl7.bit:RMS=2.211659e-02 (FAIL) maxdiff=2.959942e-01 (FAIL) fl8.bit:RMS=3.484906e-02 (FAIL) maxdiff=5.002034e-02 (FAIL) Layer 2 -- 16 bit signed integer output fl10.bit:
Bug#727708: Linux Security, Red Hat and Systemd Conspiracy
Hi! Debian user here. This is my first and last letter about the bug #727708. I feel this is important to share. Quote from Soylent News [1]. Former cypherpunk shares his conspiratorial view on Linux security [1] : Since then, more has happened to reveal the true story here, the depth of which surprised even me. The GTK development story and the systemd debate on Debian revealed much corporate pressure being brought to bear in Linux. [...] Some really startling facts about Red Hat came to light. For me the biggest was the fact that the US military is Red Hat's largest customer: When we rolled into Baghdad, we did it using open source, General Justice continued. It may come as a surprise to many of you, but the U.S. Army is 'the' single largest install base for Red Hat Linux. I'm their largest customer . ( 2008 ) [3] This is pretty much what I had figured. I'm not exactly new to this, and I figured that in some way the military-industrial/corporate/intelligence complex was in control of Red Hat and Linux. [...] But I didn't expect it to be stated so plainly. Any fool should realize that biggest customer doesn't mean tallest or widest, it means the most money. In other words, most of Red Hat's money comes from the military and, as a result, they have significant pull in its development. In that respect, the connection between the military and spying agencies, etc. should be obvious. Next, the FOSDEM: NSA Operation ORCHESTRA Annual Status Report is well worth watching in its entirety (including the QA at the end). To me, this turned out to be a road-map detailing how Red Hat is operating on Linux! Linus Torvalds about Lennart Poettering: “Two-faced lying weasel” would be the most polite thing I could say. But it almost certainly will involve a lot of cursing. Systemd propaganda: It's a crap! - Gentoo Dev Patrick Lauer [5] [1] http://soylentnews.org/article.pl?sid=14/02/20/031231 [2] http://igurublog.wordpress.com/2014/02/17/biography-of-a-cypherpunk-and-how-cryptography-affects-your-life/ [3] http://archive09.linux.com/feed/61302 [4] http://video.fosdem.org/2014/Janson/Sunday/NSA_operation_ORCHESTRA_Annual_Status_Report.webm [5] http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt
Bug#727708: init system - achieving diversity
I'm taking off my secretarial hat for a moment and presenting a short polemic in favour of my proposal over Russ's (whether as amended by Andi or not). I'm addressing myself primarily to the members of the TC who are in favour of diversity in init systems, and in architectures, and who think that the freedom and autonomy of our users and downstreams is more important than the convenience of us or our upstreams. Do not think that Russ's text does anything to support these goals. Nothing in it goes beyond the obvious and even that is purely advice. It doesn't explicitly address the key question: is it OK to require a specific init system. But, implicitly, it says yes, that is OK. We need to send a clear signal about our commitment to diversity that will be received not just in Debian, but also in the upstream communities where key decisions are being made - specifically, about whether it is OK to require systemd. Russ's text does not contain any kind of decision or statement that could be used as a part of a strong argument by systemd sceptics in the GNOME community, for example. And, we need to make a commitment internally that we intend to continue to support and encourage diversity and choice for the foreseeable future. Russ's proposal is worse than no decision now. At least Keith's text clearly ducks the critical question. Russ answers it the wrong way. The fact that Russ's resolution text doesn't make its own unpleasant consequences explicit is effective politics, but it makes for a bad TC ruling. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
