date:20141219

On Fri, 2014-12-19 at 13:38 +0800, Chen Baozi wrote:
 I’ve only booted the system by ‘bootz’ without initrd. If I load the raw
 initrd image (rather than ‘uInitrd”), when I use bootz, it would output:
 
 Wrong Ramdisk Image Format
 Ramdisk image is corrupt or invalid
 
 This is the reason that I’m still using bootm when initrd is needed.

bootz requires you to give the filesize for the raw initrd. e.g.
load $kernel_addr_r kernel
load $fdt_addr_r
load $ramdisk_addr_r
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

The :${filesize} is what I mean, it is implicitly set by load (and
similar commands) which is why initrd is loaded last in the above, so it
doesn't get clobbered.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773309: CONFIG_PSTORE not enabled for arm64

On Thu, 2014-12-18 at 20:13 +, Leif Lindholm wrote:
 *grumble, accidental send*

:-)

 On Thu, Dec 18, 2014 at 08:08:31PM +, Leif Lindholm wrote:
 (I don't have an x86 EFI system available to poke around and answer
 these for myself).
 
 I'm wondering if we ought to figure out how to load it automatically
 independent of the pstore stuff, for all arches.

I'd be happy for it not to be autoloaded, as long as it was consistent
across architectures.
   
   I think (although I'm somewhat inferring some pieces) that the right
   answer here is to have something (mountkernfs.sh/systemd/pixies) mount
   efivarfs and to ignore the deprecated efivars thing on non-x86. The
   pstore stuff should be considered a separate feature request in its own
   right.
 
 Well, that was the actual thing I asked for in this bug, so let's keep
 the pstore aspect here.

Right.

   I could clone this bug and retitle+reassign the other half into a bug to
   handle the efi half, but TBH I think conflating the EFI variable access
   from userspace requirement with enabling pstore in the kernel is just
   going to end up causing confusion, so a separate report to get efivarfs
   mounted would probably be best.
 
 Fair point.
 Coming up.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773309: CONFIG_PSTORE not enabled for arm64

On Thu, 2014-12-18 at 20:08 +, Leif Lindholm wrote:
 On Thu, Dec 18, 2014 at 06:35:25PM +, Ian Campbell wrote:
Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what
pstore is, so sorry if this is a silly question).
   
   I am actually not concerned about pstore itself, but rather by the
   lack of similarity between platforms.
  
  Consistency is a worthwhile goal, but not at the expense of enabling
  legacy x86 junk on new architectures where it can never have any
  relevance. I don't know if pstore fits that bill, which is why I was
  asking about it.
  
  If pstore is going to be a useful thing on arm64 then of course we
  should enable it. We should *not* enable it purely to gain the side
  effect of loading efivars (the more so since as discussed below it seems
  like efivars itself is a legacy interface).
 
 pstore is not legacy nonsense (it's for storing system crash
 information persistently). I don't actively care only since I've also
 not heard anyone screaming for it.

Thanks, it does sound useful rather than legacy. Given what Ben said it
does seem like it would be worthwhile to enable.

 Ok, so I had a peek in codesearch.debian.net, to see what current
 users we have. elilo can be ignored, dracut probably doesn't matter
 (?), mdadm has it in platform-intel.c so still wouldn't matter, kernel
 doesn't matter and grub2 will work anyway.
 
 Which leaves us with the risk of out-of-tree software making use of it.

My inclination is towards suggesting that if people are running
out-of-tree software which needs the efivars interface then they should
arrange for it to be loaded themselves (e.g. by adding to /etc/modules).

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773501: wheezy-pu: package gosa/2.7.4-4.3~deb7u2

Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu

This (2.7.4-4.3~deb7u2) upload of the gosa package fixes a regression
introduced by providing a fix for DSA-3064-1 in php5.

On systems that have php5 (= 5.4.34-0+deb7u1) installed (on Debian
wheezy), it is not possible to log into the GOsa² webUI anymore. This
upload fixes this.

Furthermore, we got notified by upstream a while back about an XSS
vulnerability (which had been fixed in unstable at that time). This
upload also fixes this issue (no CVE got ever assigned for this).

-- System Information:
Debian Release: 8.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 
'testing-proposed-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773501: debdiff for gosa wheezy-pu


Sorry, forgot to attach the .debdiff...

Upload to stable-updates comes in a minute.

Mike

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
diff -Nru gosa-2.7.4/debian/changelog gosa-2.7.4/debian/changelog
--- gosa-2.7.4/debian/changelog	2013-07-12 17:10:09.0 +0200
+++ gosa-2.7.4/debian/changelog	2014-12-19 09:23:50.0 +0100
@@ -1,3 +1,24 @@
+gosa (2.7.4-4.3~deb7u2) stable-updates; urgency=medium
+
+  * debian/control:
++ Update Maintainer: Debian Edu Packaging Team.
++ Drop from Uploaders: Cajus Pollmeier (retired DD).
++ Add to Uploaders: Mike Gabriel (current maintainer of gosa in
+  Debian unstable).
+  * debian/patches:
++ Add 0003_xss-vulnerability-on-login-screen.patch. Fix XSS issue
+  during login. Picked from GOsa² upstream and from the gosa package
+  in Debian unstable.
++ Add 1002_trim-decrypt.patch. Fix authentication of GOsa² against
+  the underlying LDAP server(s) via the gosa-admin DN. (Closes:
+  #768509). The issue has been fixed in Debian unstable a while back
+  (see Debian bug #748065) and currently only affects the gosa
+  package in Debian wheezy (a fix has recently been uploaded to
+  squeeze-lts). The bug is a regression caused by fixing DSA 3064-1
+  in php5
+
+ -- Mike Gabriel sunwea...@debian.org  Fri, 19 Dec 2014 09:22:48 +0100
+
 gosa (2.7.4-4.3~deb7u1) stable-updates; urgency=low
 
   * Upload to stable updates.
diff -Nru gosa-2.7.4/debian/control gosa-2.7.4/debian/control
--- gosa-2.7.4/debian/control	2012-06-19 10:04:53.0 +0200
+++ gosa-2.7.4/debian/control	2014-12-19 09:17:45.0 +0100
@@ -1,8 +1,8 @@
 Source: gosa
 Section: web
 Priority: optional
-Maintainer: GOsa packages maintainers group gosa-...@oss.gonicus.de
-Uploaders: Cajus Pollmeier ca...@debian.org
+Maintainer: Debian Edu Packaging Team debian-edu-pkg-t...@lists.alioth.debian.org
+Uploaders: Mike Gabriel sunwea...@debian.org
 Build-Depends: debhelper (= 7.0.50~)
 Build-Depends-Indep: po-debconf
 Standards-Version: 3.9.3
diff -Nru gosa-2.7.4/debian/patches/0003_xss-vulnerability-on-login-screen.patch gosa-2.7.4/debian/patches/0003_xss-vulnerability-on-login-screen.patch
--- gosa-2.7.4/debian/patches/0003_xss-vulnerability-on-login-screen.patch	1970-01-01 01:00:00.0 +0100
+++ gosa-2.7.4/debian/patches/0003_xss-vulnerability-on-login-screen.patch	2014-08-12 16:40:22.0 +0200
@@ -0,0 +1,14 @@
+Description: Escape html entities to fix xss at the login screen
+Author: Benjamin Zapiec
+
+Index: gosa-core/html/index.php
+===
+--- a/gosa-core/html/index.php	(revision 21273)
 b/gosa-core/html/index.php	(revision 21276)
+@@ -389,5 +389,5 @@
+ /* Fill template with required values */
+ $smarty-assign ('date', gmdate(D, d M Y H:i:s));
+-$smarty-assign ('username', $username);
++$smarty-assign ('username', set_post($username));
+ $smarty-assign ('personal_img', get_template_path('images/login-head.png'));
+ $smarty-assign ('password_img', get_template_path('images/password.png'));
diff -Nru gosa-2.7.4/debian/patches/1002_trim-decrypt.patch gosa-2.7.4/debian/patches/1002_trim-decrypt.patch
--- gosa-2.7.4/debian/patches/1002_trim-decrypt.patch	1970-01-01 01:00:00.0 +0100
+++ gosa-2.7.4/debian/patches/1002_trim-decrypt.patch	2014-08-12 16:47:45.0 +0200
@@ -0,0 +1,29 @@
+Author: Andreas B. Mundt andi.mu...@web.de
+Description: Decryption of LDAP password fails (encrypted with gosa-encrypt-passwords)
+Abstract:
+ The decryption of the LDAP password (which has been encrypted by
+ gosa-encrypt-passwords) seems to fail.
+ .
+ When trying to login at the GOsa web interface, an error regarding the
+ LDAP connection happens ('Error while connecting to LDAP: Could not
+ bind to ... ').
+ .
+ After copying gosa.conf.orig to gosa.conf (with read permissions for
+ group www-data), things work again as expected.
+ .
+ So the decryption of the LDAP password which has been encrypted by
+ running gosa-encrypt-passwords does not seem to work.
+
+Index: gosa-core/include/functions.inc
+===
+--- a/gosa-core/include/functions.inc
 b/gosa-core/include/functions.inc
+@@ -3334,7 +3334,7 @@ function cred_decrypt($input,$password)
+   $size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC);
+   $iv = mcrypt_create_iv($size, MCRYPT_DEV_RANDOM);
+ 
+-  return mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $password, pack(H*, $input), MCRYPT_MODE_ECB, $iv);
++  return rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $password, pack(H*, $input), MCRYPT_MODE_ECB, $iv), \0\3\4\n);
+ }
+ 
+ 
diff -Nru gosa-2.7.4/debian/patches/series gosa-2.7.4/debian/patches/series
--- gosa-2.7.4/debian/patches/series

Bug#773502: off-by-one memory assignment

Package: gnupg2
Version: 2.1.1
Severity: normal

in app-nks.c on line 1242, data is assigned the memory of 'datalen', which is 
calculated using oldpinlen + newpinlen.
The problem is, it doesn't account for the terminating null byte, so it should 
be datalen + 1(or, +2?, will need to check.)

Thanks

-- 
-- Joshua Rogers https://internot.info/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773501: debdiff for gosa wheezy-pu

2014-12-19 Thread Adam D. Barratt


On 2014-12-19 8:41, Mike Gabriel wrote:

Sorry, forgot to attach the .debdiff...

Upload to stable-updates comes in a minute.


Although dak should DTRT, stable-updates isn't what one should be 
using as an upload target; it's a suite whose contents are set by hand 
by the Release Team.


(Also in general we'd prefer that you get an ack before proceeding with 
the upload.)


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773419: xserver-xorg-video-intel: bpo package breaks on newer Intel machines

2014-12-19 Thread Kai Hendry

Hi there Julien,

On Fri, 19 Dec 2014, at 02:26 PM, Julien Cristau wrote:
 Seems like you're using an old unsupported kernel.

3.16 from backports doesn't seem to make a difference.
http://s.natalian.org/2014-12-19/3-16.Xorg.0.log
https://github.com/Webconverger/webc/commits/kernelupgrade

How do I figure out which kernels are supported by this intel driver?

Many thanks,


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773501: debdiff for gosa wheezy-pu


Hi Adam,

On  Fr 19 Dez 2014 09:58:50 CET, Adam D. Barratt wrote:


On 2014-12-19 8:41, Mike Gabriel wrote:

Sorry, forgot to attach the .debdiff...

Upload to stable-updates comes in a minute.


Although dak should DTRT, stable-updates isn't what one should be  
using as an upload target; it's a suite whose contents are set by  
hand by the Release Team.


Yeah, I noticed that. The upload has stable-proposed-updates in the  
first changelog line. (Because dput-ng wouldn't let me upload).


(Also in general we'd prefer that you get an ack before proceeding  
with the upload.)


Ack. Sorry about that. I thought for fixing a grave RC bug it would be  
ok. Next time, I'll seek for pre-approval.


Mike

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpyP3nUx6iER.pgp
Description: Digitale PGP-Signatur

Bug#773501: debdiff for gosa wheezy-pu

2014-12-19 Thread Adam D. Barratt


Hi,

On 2014-12-19 9:12, Mike Gabriel wrote:

Hi Adam,

On  Fr 19 Dez 2014 09:58:50 CET, Adam D. Barratt wrote:


On 2014-12-19 8:41, Mike Gabriel wrote:

Sorry, forgot to attach the .debdiff...

Upload to stable-updates comes in a minute.


Although dak should DTRT, stable-updates isn't what one should be  
using as an upload target; it's a suite whose contents are set by  
hand by the Release Team.


Yeah, I noticed that. The upload has stable-proposed-updates in the
first changelog line. (Because dput-ng wouldn't let me upload).


Heh.

(Also in general we'd prefer that you get an ack before proceeding  
with the upload.)


Ack. Sorry about that. I thought for fixing a grave RC bug it would be
 ok. Next time, I'll seek for pre-approval.


No worries. In this case it looks fine from a quick glance (I'll look 
properly when I next do a p-u catchup), it's just that if there are any 
issues then we end up having to reject the package and round-trip back 
to the submitter and it's generally easier for both parties if we agree 
on the diff first.


Regards.

Adam


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773323: perl: Wheezy-Jessie upgrade breaks wheezy pdl

2014-12-19 Thread Niko Tyni

On Tue, Dec 16, 2014 at 11:06:25PM +0100, Henning Glawe wrote:
 Control: clone 729220 -1
 Control: reassign -1 perl
 Control: retitle -1 perl: Wheezy-Jessie upgrade breaks wheezy pdl
 
 There is a problem in wheezy's version of pdl, showing during the
 wheezy - jessie update.
 
 Could you please add a 'Breaks: pdl (1:2.007)' to jessies perl
 packages ?

Sure. Just a few points/notes:

- is (1:2.007) correct? I see 1:2.007-2.1+b1 was the first one on i386
  that got built against perl 5.20, so technically the jessie perl breaks
  all the earlier ones, right? Also, AIUI the actual source change that
  fixes the breakage going forward is in 1:2.007-4 so it seems using
  that would be the most robust (think downstream distributions that
  might be upgrading their perl versions in a different schedule.)

  So is ( 1:2.007-4) OK with you?

- which perl packages need this?

  The minimal recipe I could come up for this is
   # wheezy base chroot
   apt-get install libpdl-stats-perl
   dpkg --unpack perl-modules_5.20.1-3_all.deb # from jessie
   dpkg --remove libpdl-stats-perl

  or, alternatively,
   # wheezy base chroot
   apt-get install libpdl-stats-perl
   dpkg -i libc6_2.19-13_amd64.deb
   dpkg --unpack perl-base_5.20.1-3_amd64.deb 
   dpkg --remove libpdl-stats-perl

  Interestingly, unpacking the new 'perl' package alone doesn't trigger the
  failure.

  So it looks like we need the Breaks in both perl-base and perl-modules.

- is Breaks sufficient, or do we need Conflicts?

  Dependency guarantees around 'postinst triggered' are not quite clear to me.
  I assume 'postinst triggered' will not be called before the package is
  configured, in which case I expect Breaks should be enough (as it will
  guarantee that the old pdl package gets deconfigured, and the new pdl package
  won't be configured before its dependencies are installed.)

  Will test this, but any advice is appreciated.

I hope to be able to upload a fix this weekend, assuming the version number
thing above is confirmed one way or another.
-- 
Niko Tyni   nt...@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#773501: debdiff for gosa wheezy-pu


On  Fr 19 Dez 2014 10:18:54 CET, Adam D. Barratt wrote:


Ack. Sorry about that. I thought for fixing a grave RC bug it would be
ok. Next time, I'll seek for pre-approval.


No worries. In this case it looks fine from a quick glance (I'll  
look properly when I next do a p-u catchup), it's just that if there  
are any issues then we end up having to reject the package and  
round-trip back to the submitter and it's generally easier for both  
parties if we agree on the diff first.


OK. Thanks! I get that.

light+love,
Mike


--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpKJ5KZdznKl.pgp
Description: Digitale PGP-Signatur

Bug#773503: libvirt-daemon: segfault in libvirtd on qemu live migration

2014-12-19 Thread Eckebrecht von Pappenheim

Package: libvirt-daemon
Version: 1.2.9-6
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Running openstack on jessie with live migration
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Live migration of guests leads to segfault in libvirtd

Fix exists upstream:
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=52691f99fa016ac46c9546c37706e57a5180d4c6;hp=aca0ae1faa163bbd60ee8df4b93ae870aa820746

   * What was the outcome of this action?

After applying the patch live migration works.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/32 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libvirt-daemon depends on:
ii  libapparmor12.9.0-3
ii  libaudit1   1:2.4-1+b1
ii  libavahi-client30.6.31-4+b2
ii  libavahi-common30.6.31-4+b2
ii  libblkid1   2.25.2-4
ii  libc6   2.19-13
ii  libcap-ng0  0.7.4-2
ii  libdbus-1-3 1.8.12-1
ii  libdevmapper1.02.1  2:1.02.90-2
ii  libfuse22.9.3-15+b1
ii  libgnutls-deb0-28   3.3.8-5
ii  libnetcf1   1:0.2.3-4.1
ii  libnl-3-200 3.2.24-2
ii  libnl-route-3-200   3.2.24-2
ii  libnuma12.0.10-1
ii  libparted2  3.2-6
ii  libpcap0.8  1.6.2-2
ii  libpciaccess0   0.13.2-3+b1
ii  librados2   0.80.7-2
ii  librbd1 0.80.7-2
ii  libsasl2-2  2.1.26.dfsg1-12
ii  libselinux1 2.3-2
ii  libssh2-1   1.4.3-4
ii  libsystemd0 215-7
ii  libudev1215-7
ii  libvirt01.2.9-6
ii  libxen-4.4  4.4.1-6
ii  libxenstore3.0  4.4.1-6
ii  libxml2 2.9.1+dfsg1-4
ii  libyajl22.1.0-2

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.1+dfsg1-4
ii  netcat-openbsd  1.105-7
ii  qemu-kvm1:2.1+dfsg-11

Versions of packages libvirt-daemon suggests:
ii  libvirt-daemon-system  1.2.9-6

-- 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#773504: python-nova: nwfilter-problem with libvirt = 1.2.7

2014-12-19 Thread Eckebrecht von Pappenheim

Package: python-nova
Version: 2014.1.3-6
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Running openstack on jessie. Starting or migrating VMs leads to errors like

libvirtError: operation failed: filter 
'nova-instance-instance-0012-fa163e8eb435' already exists with uuid 
6b2b71c1-486c-4ef2-b0e3-1c0918bd317f

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Including patch from https://review.openstack.org/#/c/122721/


*** firewall.py.origThu Dec 18 14:20:43 2014
--- firewall.py Thu Dec 18 14:19:55 2014
***
*** 15,20 
--- 15,23 
  #License for the specific language governing permissions and limitations
  #under the License.
  
+ import uuid
+ 
+ from lxml import etree
  from oslo.config import cfg
  
  from nova.cloudpipe import pipelib
***
*** 59,89 
  return self._libvirt_get_connection()
  _conn = property(_get_connection)
  
! @staticmethod
! def nova_no_nd_reflection_filter():
  This filter protects false positives on IPv6 Duplicate Address
  Detection(DAD).
  
  return '''filter name='nova-no-nd-reflection' chain='ipv6'
!-- no nd reflection --
!-- drop if destination mac is v6 mcast mac addr and
 we sent it. --
! 
rule action='drop' direction='in'
mac dstmacaddr='33:33:00:00:00:00'
 dstmacmask='ff:ff:00:00:00:00' srcmacaddr='$MAC'/
/rule
!   /filter'''
  
! @staticmethod
! def nova_dhcp_filter():
  The standard allow-dhcp-server filter is an ip one, so it uses
 ebtables to allow traffic through. Without a corresponding rule in
 iptables, it'll get blocked anyway.
  
! 
  return '''filter name='nova-allow-dhcp-server' chain='ipv4'
! uuid891e4787-e5c0-d59b-cbd6-41bc3c6b36fc/uuid
  rule action='accept' direction='out'
priority='100'
udp srcipaddr='0.0.0.0'
--- 62,91 
  return self._libvirt_get_connection()
  _conn = property(_get_connection)
  
! def nova_no_nd_reflection_filter(self):
  This filter protects false positives on IPv6 Duplicate Address
  Detection(DAD).
  
+ uuid = self._get_filter_uuid('nova-no-nd-reflection')
  return '''filter name='nova-no-nd-reflection' chain='ipv6'
!-- no nd reflection --
!-- drop if destination mac is v6 mcast mac addr and
 we sent it. --
!   uuid%s/uuid
rule action='drop' direction='in'
mac dstmacaddr='33:33:00:00:00:00'
 dstmacmask='ff:ff:00:00:00:00' srcmacaddr='$MAC'/
/rule
!   /filter''' % uuid
  
! def nova_dhcp_filter(self):
  The standard allow-dhcp-server filter is an ip one, so it uses
 ebtables to allow traffic through. Without a corresponding rule in
 iptables, it'll get blocked anyway.
  
! uuid = self._get_filter_uuid('nova-allow-dhcp-server')
  return '''filter name='nova-allow-dhcp-server' chain='ipv4'
! uuid%s/uuid
  rule action='accept' direction='out'
priority='100'
udp srcipaddr='0.0.0.0'
***
*** 97,103 
 srcportstart='67'
 dstportstart='68'/
  /rule
!   /filter'''
  
  def setup_basic_filtering(self, instance, network_info):
  Set up basic filtering (MAC, IP, and ARP spoofing protection).
--- 99,105 
 srcportstart='67'
 dstportstart='68'/
  /rule
!   /filter''' % uuid
  
  def setup_basic_filtering(self, instance, network_info):
  Set up basic filtering (MAC, IP, and ARP spoofing protection).
***
*** 172,178 
--- 174,182 
  nic_id = vif['address'].replace(':', '')
  instance_filter_name = self._instance_filter_name(instance, nic_id)
  parameters = self._get_instance_filter_parameters(vif)
+ uuid = self._get_filter_uuid(instance_filter_name)
  xml = '''filter name='%s' chain='root % instance_filter_name
+ xml += 'uuid%s/uuid' % uuid
  for f in filters:
  xml += '''filterref filter='%s % f
  xml += ''.join(parameters)
***
*** 210,232 
  filter_set = ['no-mac-spoofing',

Bug#769537: fixed in gcc-h8300-hms 1:3.4.6+dfsg2-3

2014-12-19 Thread Edmund Grimley Evans

Almost! Instead of arm64-linux-gnu it should be aarch64-linux-gnu
in debian/rules:

-ifeq ($(DEB_HOST_GNU_TYPE),arm64-linux-gnu)
+ifeq ($(DEB_HOST_GNU_TYPE),aarch64-linux-gnu)

Thanks!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773505: python-descartes/1.0.1-1 [ITP]

2014-12-19 Thread Johan Van de Wauw

X-Debbugs-CC: pkg-grass-de...@lists.alioth.debian.org
Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for reviews/a sponsor for my package python-descartes

 * Package name: python-descartes
   Version : 1.0.1-1
   Upstream Author :  Sean Gillies, descartesdevelopers
* URL :
https://pypi.python.org/pypi/descartes,https://bitbucket.org/sgillies/descartes
* License : BSD-3
  Programming Lang: Python

python-descartes - Matplotlib extension to work with geometric
objects (Python2)
 python3-descartes - Matplotlib extension to work with geometric
objects (Python3)

  To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/python-descartes


  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/p/python-descartes/python-descartes_1.0.1-1.dsc


  Changes since the last upload:

Initial upload


  Regards,
   Johan Van de Wauw


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773419: xserver-xorg-video-intel: bpo package breaks on newer Intel machines

2014-12-19 Thread Kai Hendry

libdrm-intel1 2.4.58-2 from jessie seems to have solved the issue. At
least get X to start!

Can I hassle someone from a backport I wonder? :)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773442: gstreamer1.0-plugins-good: fail to playback AVI file with uncompressed PCM audio

2014-12-19 Thread Fabian Greffrath

Am Donnerstag, den 18.12.2014, 13:31 +0100 schrieb Sebastian Dröge: 
 The audio parts are fixed with this commit:
 http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=5ecbc9eea25f3a5e36b00662ed7412070e3298d7

Great, thanks!

 For the future it would be great if you could file such bugs directly at
 http://bugzilla.gnome.org against GStreamer, then we won't have to track
 it in two places :)

Sure, will do.

Thank you !

Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773506: libflite1: build should check for texi2any

2014-12-19 Thread Faheem Mitha

Package: libflite1
Version: 1.4-release-6
Severity: normal

Dear Maintainer,

The build exits with the following error for texinfo
4.13a.dfsg.1-10. This is only present in more recent versions of
texinfo. It is present in 5.2.

(cd html; texi2any --set-customization-variable TEXI2HTML=1  --split=chapter 
../flite.texi)
/bin/sh: 1: texi2any: not found
make[1]: *** [flite.html] Error 127

It should possibly check for texi2anyd directly, perhaps in configure.

This probably should be an upstream bug, but I'm filing it here
anyway. Please forward upstream if appropriate. If I figure out how to
file an upstream bug, I may post it upstream as well.

 Regards, Faheem Mitha

-- System Information:
Debian Release: 7.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), 
(50, 'unstable'), (50, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 libflite1 depends on:
ii  libasound2 1.0.25-4
ii  libc6  2.13-38+deb7u6
ii  multiarch-support  2.13-38+deb7u6

libflite1 recommends no packages.

Versions of packages libflite1 suggests:
ii  alsa-base  1.0.25+3~deb7u1

-- no debconf information
 dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: source package flite
dpkg-buildpackage: source version 1.4-release-12
dpkg-buildpackage: source changed by Samuel Thibault sthiba...@debian.org
 dpkg-source --before-build flite-1.4-release
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp
for i in aux cp dvi fn info ky log pdf pg ps toc tp vr; do \
rm -f doc/flite.$i; \
done
cp /usr/share/misc/config.guess .
cp /usr/share/misc/config.sub   .
autoconf
/usr/bin/make clean
*** 
*** Making default config file ***
*** 
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for ranlib... ranlib
checking for a BSD-compatible install... /usr/bin/install -c
checking for ar... ar
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for mmap... yes
checking sys/soundcard.h usability... yes
checking sys/soundcard.h presence... yes
checking for sys/soundcard.h... yes
checking machine/soundcard.h usability... no
checking machine/soundcard.h presence... no
checking for machine/soundcard.h... no
checking sys/audioio.h usability... no
checking sys/audioio.h presence... no
checking for sys/audioio.h... no
checking mmsystem.h usability... no
checking mmsystem.h presence... no
checking for mmsystem.h... no
configure: creating ./config.status
config.status: creating config/config
config.status: creating config/system.mak
make[1]: Entering directory `/usr/local/src/libflite1/flite-1.4-release'
make clean in ...
make clean in config ...
make clean in include ...
make clean in src ...
make clean in src/audio ...
make clean in src/utils ...
make clean in src/regex ...
make clean in src/hrg ...
make clean in src/stats ...
make clean in src/speech ...
make clean in src/lexicon ...
make clean in src/synth ...
make clean in src/wavesynth ...
make clean in src/cg ...
make clean in lang ...
make clean in lang/cmulex ...
make clean in lang/usenglish ...
make clean in lang/cmu_us_kal ...
make clean in lang/cmu_time_awb ...
make clean in lang/cmu_us_kal16 ...
make clean in lang/cmu_us_awb ...
make clean in lang/cmu_us_rms ...
make clean in lang/cmu_us_slt ...
make clean in doc ...
make clean in testsuite ...
make clean in sapi ...
make clean in sapi/FliteCMUKalDiphone ...
make clean in sapi/FliteCMUKalDiphone/register_vox ...
make clean in sapi/FliteTTSEngineObj ...
make clean in sapi/cmu_us_kal ...
make clean in sapi/cmulex ...
make clean in sapi/flite ...
make clean in sapi/usenglish ...
make clean in palm ...
po_MemPtrNew.c:44:20: fatal error: pocore.h: No such file or directory

Bug#773447: closed by Adam D. Barratt a...@adam-barratt.org.uk (Re: Bug#773447: unblock: keystone/2014.1.3-4)

On 12/19/2014 02:21 AM, Debian Bug Tracking System wrote:
 Unblocked, but...
 
 +  * Manually activates keystone.service since we're not using
 #DEBHELPER#.
 
 Why not?
 
 Regards,
 
 Adam

Thanks for the unblocks.

FYI, that's because the postinst needs to do stuff *after* invoke-rc.d,
so I didn't want to let #DEBHELPER# do it for me.

Thomas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773507: explicit buffer overrun

Package: gnupg2
Version: 2.1.1
Severity: normal

in dirmngr/ldap.c on line 617, argv may be overflowed.

617: argv[argc++] = url;

a check is made on line 591 that checks to see whether argv is less than or 
email to 399, and if it does, exit.
But argv is char *argv[50], while argc is a normal int.
If argc is 398, it will pass that check.

Thanks,

-- 
-- Joshua Rogers https://internot.info/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771863: [ovs-dev] Bug#771863: Bug#771863: Service does not start or parse interfaces correctly, updating severity

2014-12-19 Thread Stig Sandbeck Mathisen

Joe Stringer joestrin...@nicira.com writes:

 I agree that this should be treated as a separate bug, yes please (I'm
 just following up as it wasn't clear to me whether you're working on
 this or not).

Ok, I'll report it as a new bug.

-- 
Stig Sandbeck Mathisen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#769421: NEW queue

On 12/18/2014 11:43 PM, Yaroslav Halchenko wrote:
 awesome -- THANKS!
 
 would you mind sharing/pointing to the source package interim?
 may be it would be worth uploading backport to NeuroDebian ;)

Sure!

http://anonscm.debian.org/cgit/openstack/python-pygit2.git

Thomas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772730: python3.4: pyvenv created virtual environments are missing their .whl files

2014-12-19 Thread Matthias Klose

On 12/19/2014 07:40 AM, Donald Stufft wrote:
 
 On Dec 19, 2014, at 1:16 AM, Matthias Klose d...@debian.org wrote:

 On 12/19/2014 06:57 AM, Donald Stufft wrote:
 Ok, I hope I did this right. I made a sid system and updated/upgraded it 
 then I
 did apt-get source python3.4 and used quilt to edit ensurepip-wheels.diff 
 in order
 to fix pip inside of a virtual environment and then I added a new patch
 ensurepip-disabled.diff which I adapted from the one you have on Python 2.7 
 to
 disable ensurepip when running outside of a virtual environment.

 Output: https://bpaste.net/show/821a977c5f3c
 ensurepip-wheels.diff: https://bpaste.net/show/4e5852496eae
 ensurepip-disabled.diff: https://bpaste.net/show/5ed93f1df2fa

 I built the package, installed it and tested it (that’s what you see in the 
 output
 link).

 this patch restores the behaviour to install the wheels twice, one time into 
 a
 temporary directory, and one time into a directory in the venv? why is this
 double copy needed? If you require the wheels permanently in the virtual
 environment, why would you need the copy in the tempdir?

 
 It doesn’t copy them twice, it copies the wheels named in
 /usr/share/python-wheels/%s.dependencies of which there is only currently the
 one file, pip.dependencies whose contents are:
 
 chardet
 colorama
 distlib
 html5lib
 requests
 setuptools
 six
 urllib3
 
 Those are the dependencies that pip itself has, but importantly it’s not pip
 itself.
 
 Then it copies the projects named in the variable _PROJECTS, which is 
 currently
 setuptools and pip, into a temporary directory. This isn’t strictly required
 for Debian I think,

so they are copied twice.

 upstream ensurepip copies the bundled pip/setuptools wheels
 into a temporary directory because the stdlib might be zipped but I don’t 
 think
 Debian ships a zipped stdlib.

correct.

 Anyways, once you have the pip and the setuptools wheels copied it then does 
 the
 normal ensurepip logical which is basically
 ``pip install —no-index —find-links /tmp/dir/ pip setuptools`` to actually 
 install
 pip and setuptools into the virtual environment.

I don't see the pip wheel itself copied into the venv. the current loop only
iterates over the project's (pip and setuptools) dependency wheels, not the pip
and setuptools wheels itself. These two wheels are only copied into the
temporary directory. Yes, setuptools is in pip's dependency list, so it is 
copied.

 Essentially the first copy, into sys.prefix/lib/python-wheels is there to 
 approximate
 the bundled dependencies that pip normally has (we don’t want to install 
 these into
 the virtual environment because then ``pip uninstall requests`` inside of a 
 virtual
 env would break pip without a good way to fix it which is one of the reasons 
 pip
 bundles to begin with), and the second copy is just there to give pip a 
 directory
 with a pip and setuptools wheels in it so it can install pip and setuptools 
 into
 the virtual environment normally.

 Does that make sense?

I'm still unsure why you make the distinction between the temporary and the
permanent directory. as it looks like, the setuptools in python-wheels will
never be used.

Matthias


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771863: [PKG-Openstack-devel] [ovs-dev] Bug#771863: Service does not start or parse interfaces correctly

On 12/19/2014 11:50 AM, Simon Horman wrote:
 On Thu, Dec 18, 2014 at 05:30:42PM -0800, Joe Stringer wrote:
 On 18 December 2014 at 01:00, Fabio Fantoni fabio.fant...@m2r.biz wrote:
 One maintainer or debian developer can do a new build of ovs with the fix
 available in 2.3.1 please?

   * Version 2.3.0+git20140819-2 of openvswitch is marked for
 autoremoval from testing on 2015-01-15.
   * It is affected by RC bug #771863 https://bugs.debian.org/771863.


 Without this fix openvswitch will be removed from Jessie and I think this
 would be a bad thing.

 Thanks for any reply and sorry for my bad english.

 Ben usually takes care of this sort of thing, but he is out on holiday
 through to Christmas.

 Simon, would you be able to take care of this?
 
 Sure, I have uploaded a fresh package which attempts to do so.
 It contains no other changes.

Simon,

Did you ask for an unblock to the release team?

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773508: [I18N:sl] Updated Slovenian translation of debconf templates

Package: src:grub2
Severity: wishlist
Tags: patch, l10n
---BeginMessage---
Hello,
here is the updated file.

Regards
Vanja

2014-12-11 20:59 GMT+01:00 Ian Campbell i...@debian.org:
Hi,

You are noted as the last translator of the debconf translation for
grub2. The English template has been changed, and now some messages
are marked fuzzy in your translation or are missing.
I would be grateful if you could take the time and update it.
Please send the updated file to me, or submit it as a wishlist bug
against grub2.

The deadline for receiving the updated translation is
Sun, 21 Dec 2014 19:58:50 +.

Thanks in advance,
Ian.

--
Vanja Cvelbar

Work: +39 040 3756456
FAX:+39 040 9890668
GSM: +39 348 2241352

Follow your Euro notes in their tracks
http://www.eurobilltracker.eu/?referer=63885

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR EMAIL@ADDRESS, YEAR.
#
msgid
msgstr
Project-Id-Version: grub2\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-07 16:09+\n
PO-Revision-Date: 2014-12-19 11:34+0100\n
Last-Translator: Vanja Cvelbar cvel...@gmail.com\n
Language-Team: Slovenian s...@li.org\n
Language: sl\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=utf-8\n
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=4; plural=(n%100==1 ? 1 : n%100==2 ? 2 : n%100==3 || n%100==4 ? 3 : 0);\n
X-Poedit-Language: Slovenian\n
X-Poedit-Country: SLOVENIA\n
X-Poedit-SourceCharset: utf-8\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Verižno nalaganje iz menu.lst?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr Skript za nadgradnjo je zaznal namestitev GRUB Legacy v /boot/grub.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid In order to replace the Legacy version of GRUB in your system, it is recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image from your existing GRUB Legacy setup. This step can be automatically performed now.
msgstr Da zamenjate različico GRUB Legacy na vašem sistemu vam priporočamo, da se /boot/grub/menu.lst spremeni tako, da verižno naloži GRUB 2 iz vaše obstoječe namestitve GRUB Legacy. To dejanje lahko zdaj izvedete samodejno.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid It's recommended that you accept chainloading GRUB 2 from menu.lst, and verify that the new GRUB 2 setup works before it is written to the MBR (Master Boot Record).
msgstr Priporočamo vam, da sprejmete verižno nalaganje GRUB 2 iz datoteke menu.lst in preverite delovanje namestitve GRUB2 preden ga namestite na MBR (Master Boot Record).

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Whatever your decision, you can replace the old MBR image with GRUB 2 later by issuing the following command as root:
msgstr Kakorkoli se odločite, stari MBR lahko kasneje vedno zamenjate z GRUB 2, če izvedete kot root sledeči ukaz:

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
#: ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr Namestitvene naprave za GRUB:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid The grub-pc package is being upgraded. This menu allows you to select which devices you'd like grub-install to be automatically run for, if any.
msgstr Nadgrajevanje paketa grub-pc. Ta meni vam omogoči izbiro naprav za katere želite samodejno zagnati grub-install.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid Running grub-install automatically is recommended in most situations, to prevent the installed GRUB core image from getting out of sync with GRUB modules or grub.cfg.
msgstr V večini primerov je priporočen samodejni zagon grub-install, da preprečite neskladja med jedrom GRUBa in moduli ali grub.cfg.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
#: ../grub-pc.templates.in:4001
msgid If you're unsure which drive is designated as boot drive by your BIOS, it is often a good idea to install GRUB to all of them.
msgstr V primeru, da niste prepričani kateri pogon je označuje vaš BIOS za zagonskega, je ponavadi dobro, da namestite GRUB kar na vse.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
#: ../grub-pc.templates.in:4001
msgid Note: it is possible to install GRUB to partition boot records as well, and some appropriate partitions are offered here. However, this forces GRUB to use the blocklist mechanism, which makes it less reliable, and therefore is not recommended.
msgstr Opomba: GRUB je mogoče namestiti tudi na zagonski zapis razdelka. Primerni razdelki so na tem spisku. To pa

Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created

On 11/27/2014 04:20 PM, Stig Sandbeck Mathisen wrote:
 Mikaël Cluseau mclus...@isi.nc writes:
 
 Do we agree that with systemd the pid-file logic becomes useless, and
 thus the proper fix would be to get rid of them, or do you it would be
 better to keep them, meaning the proper logic becomes the one of
 tmpfiles.d ?
 
 As long as the systemd units run the init scripts, which then fork the
 daemon, and the daemon makes a PID file, I think PIDFile= should be
 defined in the systemd unit.

Which isn't the case currently, with the latest upload of
openstack-pkg-tools = 20 and the latest Keystone that I just uploaded
to Sid.

Thomas


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#672858:

Control: reassign -1 libtiff5-dev 4.0.3-10+b4


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768127: Fails to build the index when invalid UTF-8 is met

2014-12-19 Thread Antonio Terceiro

Control: severity 773485 normal

On Thu, Dec 18, 2014 at 11:19:31PM +0100, gregor herrmann wrote:
 Probably the severity in the cloned bug in ruby-debian shoule be
 lowered; the problem might not be present if a non-UTF-9 file is not
 opened as UTF-8 ...

yes

-- 
Antonio Terceiro terce...@debian.org


signature.asc
Description: Digital signature

Bug#773508: grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2

On Fri, 2014-12-19 at 11:36 +0100, Vanja Cvelbar wrote:
 Hello,
 here is the updated file.

Thanks, I've forwarded to the BTS for tracking.

Did you see the updated Call-For-Translations which followed this one
(text below)? I'm afraid there were some changes to the English which
would have fuzzied the translation. If it doesn't affect you translation
please let me know and I'll unfuzzy it.

Ian.

 Hi,

 You are noted as the last translator of the debconf translation for
 grub2.

 Thank you to those of you who have already submitted translation updates.

 It has been brought to my attention that the phrase EFI removable path in 
 the
 previous English version is confusing and wrong and should really be EFI
 removable media path. Therefore I am sending out an updated po file (see
 attached) with this fixed.

 I'm afraid this will have marked any existing translations as fuzzy.

 Please send the updated file to me, or submit it as a wishlist bug against
 grub2. If you have already translated this template and the above change does
 not invalidate your translation then please let me know and I will un-fuzz it
 for you.

 At the same time some minor tweaks have been made to the English grammar. I
 think these should not affect translations.

 The complete wdiff for the English updates vs last time is:
 8--
 Template: grub2/force_efi_extra_removable
 Type: boolean
 Default: false
 _Description: Force extra installation to the EFI removable {+media+} path?
  Some EFI-based systems are buggy and do not handle new bootloaders correctly.
  If you force {+an+} extra installation of GRUB to the EFI removable 
 {+media+} path, [-it-]
  {+this+} should
  [-make sure-] {+ensure+} that this system will boot Debian correctly despite 
 such a
  problem. However, [-this-] {+it+} may remove the ability to boot any other 
 operating
  systems that also depend on this path. If so, you will need to [-ensure-] 
 {+make sure+} that
  GRUB is configured successfully to be able {+to+} boot any other OS 
 installations
  correctly.
 8--

 The deadline for receiving the updated translation is still
 Sun, 21 Dec 2014 19:58:50 +.

 Thanks in advance, and sorry for the inconvenience.

 Ian.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#769537: fixed in gcc-h8300-hms 1:3.4.6+dfsg2-3

2014-12-19 Thread Michael Tautschnig

On Fri, Dec 19, 2014 at  9:38:45 +, Edmund Grimley Evans wrote:
 Almost! Instead of arm64-linux-gnu it should be aarch64-linux-gnu
 in debian/rules:
 
 -ifeq ($(DEB_HOST_GNU_TYPE),arm64-linux-gnu)
 +ifeq ($(DEB_HOST_GNU_TYPE),aarch64-linux-gnu)
 

Yep, sorry, that's what I realised soon thereafter. It's fixed in -4.

Thanks again for your report and the helpful info,
Michael



pgpBmbw_Qo_49.pgp
Description: PGP signature

Bug#773498: libcrypt-ssleay-perl: Virtual Depenedency block

2014-12-19 Thread Ansgar Burchardt

Hi,

On 12/19/2014 08:36 AM, Sanjeev wrote:
 Package: libcrypt-ssleay-perl
 Version: 0.58-1+b2
[...]
   When trying to install throught apt-get, it reports 
  libcrypt-ssleay-perl : Depends: perlapi-5.14.2 but it is not installable
   
   since perlapi-5.14.2 is virtual package and only exist in 
 wheezy ,
   it also blocks gnucash from installing from sid (not jessie)

libcrypt-ssleay-perl_0.58-1+b2 on amd64 has

  Depends: libc6 (= 2.2.5), libssl1.0.0 (= 1.0.0),
   perl (= 5.20.0-4), perlapi-5.20.0

so I suspect you are trying to install a different version. What does

  apt-cache policy libcrypt-ssleay-perl

say?

Ansgar


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773510: RFS: readosm/1.0.0d-1~exp1

2014-12-19 Thread Bas Couwenberg

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package readosm

 Package name: readosm
 Version : 1.0.0d-1~exp1
 Upstream Author : Alessandro Furieri a.furi...@lqt.it
 URL : https://www.gaia-gis.it/fossil/readosm/index
 License : MPL-1.1 or GPL-2.0+ or LGPL-2.1+
 Section : libs

It builds those binary packages:

 libreadosm-dev  - simple library to parse OpenStreetMap files - headers
 libreadosm1 - simple library to parse OpenStreetMap files
 libreadosm1-dbg - simple library to parse OpenStreetMap files - debug symbols
 libreadosm-doc  - simple library to parse OpenStreetMap files - documentation

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/readosm


Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/r/readosm/readosm_1.0.0d-1~exp1.dsc

More information about ReadOSM can be obtained from 
https://www.gaia-gis.it/fossil/readosm/index.

Changes since the last upload:

  * New upstream release.
  * Update copyright file, update Autotools files.
  * Refresh patches.


Regards,
 Bas Couwenberg


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773509: mono-runtime-dbg: missing debug symbols from mono-runtime-dbg

2014-12-19 Thread Jo Shields

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Source: mono-runtime-dbg
Version: 3.2.1+dfsg-1
Justification: renders package unusable
Severity: grave

When mono-runtime-common was split out from mono-runtime, debian/rules
wasn't
updated to handle the new package names, so the debug symbols for
mono-runtime-
boehm are discarded rather than stored in mono-runtime-dbg as they
should be.



- -- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500,
'trusty'), (100, 'trusty-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.0-43-generic (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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUlATdAAoJEMkPnLkOH60MqnoH/jK53a7pm6ZMcry7FGixq5F6
YeLn5j+44tkxRqrj9vazuTx2KSKSIqDQS3XkSxcL0OfHB2TLjuYcuvBYuBvIXZ6B
f1K5Kx5hT0YGnkq5Tr8CeCKLBTKC8J/SxsDRIsuCmVoviMuggP0/rDD6JbHW6uKU
5ptQlbog3g2LRtm+k4BYjb5DMKEe/L2tFgRpSa+33xk4O/9lRWgyDNrOYrx3mB4h
HbhX7JRaPC+2OBzNwowc8IA/3sNLdaVD//MJ5EibDq/XrG4AA1kmzNMmB1J39lJT
qAH43nKaztUxXV35L4sUwzaULTu9X0kxXNZgiNc6toezDsfoLmvipDnzlEsha8I=
=3EJF
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773508: grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2

2014-12-19 Thread Vanja Cvelbar

No, sorry I did saw that, but toook the previous file - here is the
update. I changed the wording slightly to clear the meaning.

Regards
Vanja

2014-12-19 11:46 GMT+01:00 Ian Campbell i...@debian.org:
On Fri, 2014-12-19 at 11:36 +0100, Vanja Cvelbar wrote:
Hello,
here is the updated file.

Thanks, I've forwarded to the BTS for tracking.

Did you see the updated Call-For-Translations which followed this one
(text below)? I'm afraid there were some changes to the English which
would have fuzzied the translation. If it doesn't affect you translation
please let me know and I'll unfuzzy it.

Ian.

Hi,

You are noted as the last translator of the debconf translation for
grub2.

Thank you to those of you who have already submitted translation updates.

It has been brought to my attention that the phrase EFI removable path in
the
previous English version is confusing and wrong and should really be EFI
removable media path. Therefore I am sending out an updated po file (see
attached) with this fixed.

I'm afraid this will have marked any existing translations as fuzzy.

Please send the updated file to me, or submit it as a wishlist bug against
grub2. If you have already translated this template and the above change does
not invalidate your translation then please let me know and I will un-fuzz it
for you.

At the same time some minor tweaks have been made to the English grammar. I
think these should not affect translations.

The complete wdiff for the English updates vs last time is:
8--
Template: grub2/force_efi_extra_removable
Type: boolean
Default: false
_Description: Force extra installation to the EFI removable {+media+} path?
Some EFI-based systems are buggy and do not handle new bootloaders
correctly.
If you force {+an+} extra installation of GRUB to the EFI removable
{+media+} path, [-it-]
{+this+} should
[-make sure-] {+ensure+} that this system will boot Debian correctly
despite such a
problem. However, [-this-] {+it+} may remove the ability to boot any other
operating
systems that also depend on this path. If so, you will need to [-ensure-]
{+make sure+} that
GRUB is configured successfully to be able {+to+} boot any other OS
installations
correctly.
8--

The deadline for receiving the updated translation is still
Sun, 21 Dec 2014 19:58:50 +.

Thanks in advance, and sorry for the inconvenience.

Ian.

--
Vanja Cvelbar

Work: +39 040 3756456
FAX:+39 040 9890668
GSM: +39 348 2241352

Follow your Euro notes in their tracks
http://www.eurobilltracker.eu/?referer=63885
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR EMAIL@ADDRESS, YEAR.
#
msgid
msgstr
Project-Id-Version: grub2\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-19 11:58+0100\n
Last-Translator: Vanja Cvelbar cvel...@gmail.com\n
Language-Team: Slovenian s...@li.org\n
Language: sl\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=utf-8\n
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=4; plural=(n%100==1 ? 1 : n%100==2 ? 2 : n%100==3 || n%100==4 ? 3 : 0);\n
X-Poedit-Language: Slovenian\n
X-Poedit-Country: SLOVENIA\n
X-Poedit-SourceCharset: utf-8\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Verižno nalaganje iz menu.lst?

Bug#772740: xserver-xorg-video-nvidia-legacy-304xx: No glXSwapIntervalSGI despite reported GLX_SGI_swap_control in socket-based connections

2014-12-19 Thread Ilya Anfimov

On Wed, Dec 17, 2014 at 01:03:46AM +0100, Andreas Beckmann wrote:
 On 2014-12-10 16:32, Ilya Anfimov wrote:
  Dear  Maintainer,  I'm trying to run OpenGL acceleration in indi-
  rect GLX mode on an old NVidia graphics card. The OpenGL  library
  is  set to mesa, as it should have sufficient GLX implementation,
  it works fine with other X-servers  (cygwin/intel)  and  it  will
  definitely  not  support  direct rendering to server with propri-
  etary nvidia driver.

 I'm not sure that is a supported setup ...

 You have a lot of nvidia related cruft on that historically grown machine:

  Thanks for your interest in this issue.

  After  investigation,  it  looks  partially true: nvidia_drv.so
symlink in /usr/lib/xorg/modules/drivers is made by hand, as

update-alternatives  --set  glx /usr/lib/mesa-diverted

 removes this symlink.
 Hoever, while README states that this configuration is official-
ly unsupported (which is sad), the bug also could be triggered by
connecting to the nvidia-driven X-server from machine  with  mesa
or ATI libGL drivers.


 * some 340.xx driver packages are installed, but that does not support
 your card, remove them

 OK,  I'll  try  that  on fresh debian this weekend (when I could
boot it from usb flash for experiments).
 However, I think that nvidia-alternative is exactly for  keeping
both versions on one machine.


 * lots of files from older .run driver installations have been left on
 your box, move them aside or delete them:

 Thanks, I removed this old stuff.

 This  didn't change anything (started another X server for test-
ing).
 btw, I've written small C example demonstrating problem and  at-
tached it.

[skipped]


 you explicitly disabled the nvidia module:

   /etc/modprobe.d/nvidia-kernel-common.conf 
  alias char-major-195* nvidia
  options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44 
  NVreg_DeviceFileMode=0660
  # To enable FastWrites and Sidebus addressing, uncomment these lines
  # options nvidia NVreg_EnableAGPSBA=1
  # options nvidia NVreg_EnableAGPFW=1
 
  # see #580894
  #blacklist nouveau
  options nouveau modeset=1
  blacklist nvidia
  ^^ /etc/modprobe.d/nvidia-kernel-common.conf ^^


 nevertheless, nvidia is loaded:

0_ilan@azor /tmp%lsmod |grep nvidia
nvidia  11285975  56
i2c_core   15803  13 
i2c_piix4,nvidia,videodev,v4l2_common,tveeprom,saa7134,tuner,tda8290,tda9887,tea5767,tuner_simple,i2c_nforce2,eeprom
0_ilan@azor /tmp%lsmod |grep nouveau
1_ilan@azor /tmp%

 I  don't  know why -- is it because the nvidia xorg driver loads
it via insmod, skipping modprobe rules, or because nvidia  is  an
alias of nvidia-legacy-304xx:

0_ilan@azor /etc/modprobe.d%cat nvidia.conf
alias nvidia nvidia-legacy-304xx
remove nvidia-legacy-304xx rmmod nvidia
0_ilan@azor /etc/modprobe.d%

 Unfortunately the bug script did not collect information about the
 nvidia things in /usr/lib/xorg/modules (this will be fixed in
 304.125-1), I would expect that there are even more files from old versions.

  There really was libnvidia-wfb.so* . Removing it and starting X
server with buggy glx driver doesn't change anything.
 Also, I had attached ls -l on all  those  directories,  just  in
case you'll want to see it.


 In the end you probably loaded a mix of incompatible versions resulting
 in your failures.

 Server version is definitely 304.123 -- nvidia driver and nvidia
glx module are linked to specific libraries, and they scream when
they are of diffirent versions or when kernel module is different
version.  Attached mmap of X-server, proving that.

 Client is Mesa (without any dri installed), it should  not  take
any touch of nvidia libraries.

 Also,  I've  taken  some  experiments,  and  found  that  nvidia
libGL.so.1 works fine. It works in both direct and indirect mode.
It  also  works  fine  with -340  version of client library (only
indirect mode, of course).
 Wireshark view of indirect mode traffic shows,  that  in  nvidia
glx  library  glXSwapIntervalSGI is made by some NV-GLX extension
requests, undecoded as there is no NV-GLX decode support in wire-
shark. I don't know simple ways to disable usage of NV-GLX, so  I
don't know what this client library will do when it will not find
NV-GLX extension on server.
  ATI's  libgl1-fglrx-glx  libGL.so.1  library fails, nearly  the
same way as MESA one.


 Andreas
#include stdio.h
#include string.h
#include GL/glx.h
#include GL/gl.h


GLboolean checkglx(Display *dpy, int scr, char *extension) {
static char *glxexts = NULL;
char *start, *next;
int extlen = strlen(extension);

if (!glxexts) {
glxexts = (char *)glXQueryExtensionsString(dpy, scr);
};
if (glxexts) {
for (next = start = glxexts; next; start=next) {
if ((next = strstr(start, extension))) {
if ( ((start == glxexts) ||
 (*(start-1) == ' '))
  
  ((*(next + extlen) == '\0')
   ||

Bug#773511: mono-runtime-sgen: /usr/bin/mono-sgen is not stripped

2014-12-19 Thread Jo Shields

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: mono-runtime-sgen
Version: 2.10.1-1
Severity: normal

/usr/bin/mono-sgen is not stripped, whether or not nostrip is defined.



- -- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500,
'trusty'), (100, 'trusty-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.0-43-generic (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 mono-runtime-sgen depends on:
ii  libc62.19-0ubuntu6.4
ii  mono-runtime-common  3.10.0-0xamarin2

mono-runtime-sgen recommends no packages.

mono-runtime-sgen suggests no packages.

- -- no debconf information
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUlAa1AAoJEMkPnLkOH60MmRcIAI4X3SNVpxzxtZqj0gK62BD8
6BMi9UGGNCtVQeXPqjMpjtIk6RJkxk8yXh+eHJi8CqRpdW263pvYce/X32eJcnBs
1hwXcQ5HSn7I2jLlqy1PagUbRMdM4vm26RHJulwiuEdkAC2jz+gI7fBxJUJIFmPg
3wMTHZ8/I67MRJqcb7kZkjdfbhvlOHh4ngcrSr4ESbmlNKvhA4Jc1rWovuClA3i2
43foluc17gVIW8s4WR6ZHZBv/66UJ+W2WLEyR+rr62lr7yIQe+4VzJPXGsrZpAls
Wr1gWUEPrGV2fulFut4+rKeeRZyr8w8a3TfyUV7BaYNmqwoSUGA5WMZfoMNOVZw=
=hXjW
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773274: more d-i encryption testing

2014-12-19 Thread Matt Taggart

I had some time to try a couple more tests for #773274 and observed a few 
more things.

* In my set of steps to repeat the bug I said to setup two partitions for 
encryption. I just tested and it doesn't seem to matter if one of them is 
going to be for swap (which d-i defaults to if you choose random 
passphrase). I'm not sure if that's relevant but I thought it was worth 
mentioning.

* If I only initially create one encrypted partition, set it up and mark it 
for LVM, then set LVM up, there is no segfault upon returning from LVM. 
Then I can proceed to setup additional encrypted volumes and it appears to 
work until I finish partitioning and then I get the segfault. So I think 
this means it has something to do with whatever parted_server is doing when 
it reinitializes while more than one encrypted partition is present.

-- 
Matt Taggart
tagg...@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#773498: Fixed

2014-12-19 Thread Sanjeev

Sorry, didn't notice another version existed from different 
repo(tizen), it works now after removing it and this bug can be closed.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773512: nautilus: segfault at 7ff85cb2d510 ip 00007ffb50d17d87 sp 00007ffb26eaa6a8 error 4 in libgdk_pixbuf-2.0.so.0.3100.1[7ffb50d03000+20000]

Package: nautilus
Version: 3.14.1-2
Severity: important

Dear Maintainer,

Most of my time, I am dealing with very large JP2 file stored on disk. However 
the default behavior for nautilus is to crash when the thumbnail generation 
fails. It would be super nice to have another behavior (gracefully handle 
subprocess crash). It makes nautilus hardly usable to navigate filesystem, when 
I need to skip any directory that could contains a JP2 file.

Steps to reproduce:

$ cd /tmp
$ mkdir JP2
$ cd JP2
$ wget 
http://kakadusoftware.com/wp-content/uploads/2014/10/KDU74_Demo_Apps_for_Linux-x86-32_140513.zip
$ unzip *.zip
$ cd KDU*
$ sudo truncate -s 4G white.raw
$ export LD_LIBRARY_PATH=`pwd`
$ ./kdu_compress -i white.raw -o white.jp2  Sdims={65536,65536} Sprecision=8 
Ssigned=no
$ nautilus .


As a side note a slightly smaller file, just freeze the whole system:

$ sudo truncate -s 1G white.raw
$ ./kdu_compress -i white.raw -o white.jp2  Sdims={32768,32768} Sprecision=8 
Ssigned=no
$ nautilus .

dmesg actually shows two types of crashes:

[69727.744833] nautilus[11822]: segfault at 7ff85cb2d510 ip 7ffb50d17d87 sp 
7ffb26eaa6a8 error 4 in libgdk_pixbuf-2.0.so.0.3100.1[7ffb50d03000+2]
[71582.118170] nautilus[13187]: segfault at 0 ip 7f60f1f56785 sp 
7f610c0c55b0 error 6 in libjasper.so.1.0.0[7f60f1f27000+4f000]

Thanks

-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.22-1
ii  gsettings-desktop-schemas  3.14.1-1
ii  gvfs   1.22.2-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-13
ii  libcairo-gobject2  1.14.0-2.1
ii  libcairo2  1.14.0-2.1
ii  libexempi3 2.2.1-2
ii  libexif12  0.6.21-2
ii  libgail-3-03.14.5-1
ii  libgdk-pixbuf2.0-0 2.31.1-2+b1
ii  libglib2.0-0   2.42.1-1
ii  libglib2.0-data2.42.1-1
ii  libgnome-desktop-3-10  3.14.1-1
ii  libgtk-3-0 3.14.5-1
ii  libnautilus-extension1a3.14.1-2
ii  libnotify4 0.7.6-2
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libselinux12.3-2
ii  libtracker-sparql-1.0-01.2.4-1
ii  libx11-6   2:1.6.2-3
ii  libxml22.9.1+dfsg1-4
ii  nautilus-data  3.14.1-2
ii  shared-mime-info   1.3-1

Versions of packages nautilus recommends:
ii  eject  2.1.5+deb1+cvs20081104-13.1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  gnome-sushi3.12.0-2+b1
ii  gvfs-backends  1.22.2-1
ii  librsvg2-common2.40.5-1

Versions of packages nautilus suggests:
ii  atril [pdf-viewer] 1.8.1+dfsg1-3
ii  brasero3.11.4-1
ii  eog3.14.1-1
ii  evince [pdf-viewer]3.14.1-1
ii  gv [pdf-viewer]1:3.7.4-1
ii  mupdf [pdf-viewer] 1.5-1+b2
ii  totem  3.14.0-2
ii  tracker1.2.4-1
ii  vlc [mp3-decoder]  2.2.0~rc2-1
ii  vlc-nox [mp3-decoder]  2.2.0~rc2-1
ii  xdg-user-dirs  0.15-2
ii  xpdf [pdf-viewer]  3.03-17+b1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773513: mention when 'eval' is needed

2014-12-19 Thread 積丹尼 Dan Jacobson

Package: cron
Version: 3.0pl1-127
Severity: wishlist
File: /usr/share/man/man5/crontab.5.gz

Please mention on the man page when 'eval' will be needed.
E.g.,

CONTENT_TYPE=text/plain; charset=UTF-8
d=eval LANG=zh_TW.UTF-8 w3m -dump
26 22 16 1-12 * $d https://www.ptt.cc/bbs/transgender/index.html

won't work without the eval. Saying
d=LANG=zh_TW.UTF-8 w3m -dump
will get
/bin/sh: LANG=zh_TW.UTF-8: command not found


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773000:

Control: tags -1 fixed-upstream patch pending


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772740: xserver-xorg-video-nvidia-legacy-304xx: No glXSwapIntervalSGI despite reported GLX_SGI_swap_control in socket-based connections

2014-12-19 Thread Andreas Beckmann

On 2014-12-19 12:01, Ilya Anfimov wrote:
   After  investigation,  it  looks  partially true: nvidia_drv.so
 symlink in /usr/lib/xorg/modules/drivers is made by hand, as

but that link alone is not sufficient ...

 update-alternatives  --set  glx /usr/lib/mesa-diverted
 
  removes this symlink.
  Hoever, while README states that this configuration is official-
 ly unsupported (which is sad), the bug also could be triggered by
 connecting to the nvidia-driven X-server from machine  with  mesa
 or ATI libGL drivers.

Can you run the X-server machine with the supported configuration from
update-alternatives  --set  glx /usr/lib/nvidia

also /usr/lib/xorg/modules/extensions/libglx.so, libnvglx.so are manual
symlinks, get rid of them, too
reinstall xserver-xorg-core to get back the xorg libglx.so

and maybe try a minimal xorg.conf as describd in the README.Debian

 * some 340.xx driver packages are installed, but that does not support
 your card, remove them
 
  OK,  I'll  try  that  on fresh debian this weekend (when I could
 boot it from usb flash for experiments).
  However, I think that nvidia-alternative is exactly for  keeping
 both versions on one machine.

Correct, but with all the cruft around previously I want to rule out any
potential error source.

   There really was libnvidia-wfb.so* . Removing it and starting X
 server with buggy glx driver doesn't change anything.
  Also, I had attached ls -l on all  those  directories,  just  in
 case you'll want to see it.

More cruft:

 + ls -l /usr/lib/xorg/modules/extensions
 -rw-r--r-- 1 root root 2502561 Mar  7  2007 libGLcore.so
 -rw-r--r-- 1 root root  421696 Sep 23  2009 libglx.so-xorg

 In the end you probably loaded a mix of incompatible versions resulting
 in your failures.
 
  Server version is definitely 304.123 -- nvidia driver and nvidia
 glx module are linked to specific libraries, and they scream when
 they are of diffirent versions or when kernel module is different
 version.  Attached mmap of X-server, proving that.

please update to 304.125

  Client is Mesa (without any dri installed), it should  not  take
 any touch of nvidia libraries.

So X is tunneled (via ssh)? This increases the fun ... :-)

Are things working *locally*?

  Also,  I've  taken  some  experiments,  and  found  that  nvidia
 libGL.so.1 works fine. It works in both direct and indirect mode.
 It  also  works  fine  with -340  version of client library (only
 indirect mode, of course).
  Wireshark view of indirect mode traffic shows,  that  in  nvidia
 glx  library  glXSwapIntervalSGI is made by some NV-GLX extension
 requests, undecoded as there is no NV-GLX decode support in wire-
 shark. I don't know simple ways to disable usage of NV-GLX, so  I
 don't know what this client library will do when it will not find
 NV-GLX extension on server.
   ATI's  libgl1-fglrx-glx  libGL.so.1  library fails, nearly  the
 same way as MESA one.

Need to think more about this ...

Andreas

PS: I'll be mostly offline over the holidays


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773505: RFS: python-descartes/1.0.1-1 [ITP]

2014-12-19 Thread Sebastiaan Couwenberg

Do you intent to add this RFS to SoB wiki page?

https://wiki.debian.org/DebianPureBlends/SoB

Both python-descartes and python-geopandas were added to the Debian GIS
Blend.

http://blends.debian.org/gis/tasks/workstation#python-descartes
http://blends.debian.org/gis/tasks/workstation#python-geopandas

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#744128: network-manager-openvpn-gnome: Segfault in any configuration dialog

2014-12-19 Thread Dominik George

Package: network-manager-openvpn-gnome
Version: 0.9.10.0-1
Followup-For: Bug #744128

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The connection edito crashes upon opening, or sometimes saving, an
OpenVPN connection. Right now, it always crashes in a segmentation fault
right after importing an OpenVPN configuration when spawning the
configuration dialog.

Attached is a backtrace and the OpenVPN config in question; however, I
deem that irrelevant because empty dialogs for new connections crash as
well.

- -- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (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
Init: systemd (via /run/systemd/system)

Versions of packages network-manager-openvpn-gnome depends on:
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-13
ii  libcairo-gobject21.14.0-2.1
ii  libcairo21.14.0-2.1
ii  libdbus-1-3  1.8.12-1
ii  libdbus-glib-1-2 0.102-1
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libglib2.0-0 2.42.1-1
ii  libgtk-3-0   3.14.5-1
ii  libnm-glib-vpn1  0.9.10.0-4
ii  libnm-glib4  0.9.10.0-4
ii  libnm-gtk0   0.9.10.0-2
ii  libnm-util2  0.9.10.0-4
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libsecret-1-00.18-1+b1
ii  network-manager-openvpn  0.9.10.0-1

network-manager-openvpn-gnome recommends no packages.

network-manager-openvpn-gnome suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUlA+AAAoJELeaPBagxPKWinkQALhtimw9iwYKz116LCZVT+AF
xJQoMrs1tBFIjYniVgTcPfu1aRql0thKdGw1TeEy5AltQD6Cn9pAb5x3/+orVkZ7
aQarwfrIsacGgZpGRNwb3244PfKEv/SGR6Gbut7iyU/LdLaNkif2CuIAnEwkx6ld
Qgvsgrjowpvd+l0YFTbOz2V+7ddwO60s2NK24Y4T1GscMLkV+dQ/DcgnE4dcINzE
9oN9Aq8YrlzApBocFq61CAH4jXZJxqlh37+Z373n1TowM5Yv6bOUj7hOPqhrjsiz
ZNpRBy8h1NBtFwsJY+2J1Q6U8uN/YVr9HXAxRAlx/LSqueZdax/UKSrs5zkTfFYK
KcsAF4iUE0q+SQP877oLtN7kp03FbkZlTNJJ+vUQuFXaT6Y/Sf1VBM6+mikueTxf
7F6fNu4EMt85rDuFm4wv77zN1ClYuD0HlENPCntPxxEfY/mtSqlJoKnj/68DAtH6
HP91IizJjvgIDc3AHv/z3D7XpoI+Q8HpCaAuv3v8s+SCa1ot7Tojfgj9YhJm+J64
aR/qnqjcjf4eAdSxdnsE10pzW8lWdFTWW8VaRZPLuFnqZCWhKZ83ULnRAf+Eun7C
9vVxlDEAYeQEX5lKfE61HPVnhkyFqo/3w8JOn9Pw95ngEb0+SEYP0CQ/6ykHxIN+
F+Zw6MpokfEggFMPb6gG
=8GsC
-END PGP SIGNATURE-
backtrace:
#0  0x00762010 in ?? ()
No symbol table info available.
#1  0x00429698 in ?? ()
No symbol table info available.
#2  0x004318ed in ?? ()
No symbol table info available.
#3  0x75f44245 in g_closure_invoke (closure=0xce06b0, return_value=0x0, 
n_param_values=2, param_values=0x7fffd820, invocation_hint=0x7fffd7c0) 
at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:768
marshal = optimized out
marshal_data = optimized out
in_marshal = 0
real_closure = 0xce0690
__FUNCTION__ = g_closure_invoke
#4  0x75f55f6c in signal_emit_unlocked_R (node=node@entry=0x6a0890, 
detail=detail@entry=0, instance=instance@entry=0xc9a270, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffd820) at 
/tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3553
tmp = optimized out
handler = 0xcded20
accumulator = 0x0
emission = {next = 0x7fffdbb0, instance = 0xc9a270, ihint = 
{signal_id = 148, detail = 0, run_type = G_SIGNAL_RUN_FIRST}, state = 
EMISSION_RUN, chain_type = 4}
handler_list = optimized out
return_accu = 0x0
accu = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong 
= 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, 
{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, 
v_float = 0, v_double = 0, v_pointer = 0x0}}}
signal_id = 148
max_sequential_handler_number = 3710
return_value_altered = 1
#5  0x75f5e778 in g_signal_emit_valist (instance=optimized out, 
signal_id=optimized out, detail=optimized out, 
var_args=var_args@entry=0x7fffd9b0) at 
/tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3309
instance_and_params = 0x7fffd820
signal_return_type = optimized out
param_values = 0x7fffd838
i = optimized out
n_params = optimized out
__FUNCTION__ = g_signal_emit_valist
#6  0x75f5e9df in g_signal_emit (instance=optimized out, 
signal_id=optimized out, detail=optimized out) at 
/tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
var_args = {{gp_offset = 32, fp_offset = 48, overflow_arg_area = 
0x7fffda90, reg_save_area = 0x7fffd9d0}}
#7  0x75f44474 in _g_closure_invoke_va (closure=0x7fffe001f140, 
closure@entry=0xce04a0,

Bug#773515: unblock: mono/3.2.8+dfsg-9

2014-12-19 Thread Jo Shields

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Please unblock package mono

There are a couple of long-standing bugs in the Mono package, which
are fixed by this proposed upload to Unstable.

#771389 prevents IPv6 from working in Mono-based apps
#773509 and #773511 relate to the mono-runtime-dbg package not being
correctly populated (and currently being useless)

diff --git a/data/net_1_1/machine.config b/data/net_1_1/machine.config
index 2e346ad..c44f11f 100644
- --- a/data/net_1_1/machine.config
+++ b/data/net_1_1/machine.config
@@ -75,7 +75,7 @@
add prefix=file
type=System.Net.FileWebRequestCreator, System, Version=1.0.5000.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089 /
/webRequestModules
settings
- -   ipv6 enabled=false/
+   ipv6 enabled=true/
/settings
/system.net
system.web
diff --git a/data/net_2_0/machine.config b/data/net_2_0/machine.config
index c6d1b2c..9da7be9 100644
- --- a/data/net_2_0/machine.config
+++ b/data/net_2_0/machine.config
@@ -119,7 +119,7 @@
add prefix=ftp
type=System.Net.FtpRequestCreator,
System, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089 /
/webRequestModules
settings
- -   ipv6 enabled=false/
+   ipv6 enabled=true/
/settings
/system.net

diff --git a/data/net_4_0/machine.config b/data/net_4_0/machine.config
index b98a4d3..12839c1 100644
- --- a/data/net_4_0/machine.config
+++ b/data/net_4_0/machine.config
@@ -136,7 +136,7 @@
add prefix=ftp
type=System.Net.FtpRequestCreator,
System, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089 /
/webRequestModules
settings
- -   ipv6 enabled=false/
+   ipv6 enabled=true/
/settings
/system.net

diff --git a/data/net_4_5/machine.config b/data/net_4_5/machine.config
index b98a4d3..12839c1 100644
- --- a/data/net_4_5/machine.config
+++ b/data/net_4_5/machine.config
@@ -136,7 +136,7 @@
add prefix=ftp
type=System.Net.FtpRequestCreator,
System, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089 /
/webRequestModules
settings
- -   ipv6 enabled=false/
+   ipv6 enabled=true/
/settings
/system.net

diff --git a/debian/changelog b/debian/changelog
index bfdd9f5..bc81216 100644
- --- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+mono (3.2.8+dfsg-9) unstable; urgency=medium
+
+  [ Mirco Bauer ]
+  * [c8efb3b] Enable IPv6 support by default (closes: #771389)
+
+  [ Jo Shields ]
+  * [0d67f80] Fix missing contents in mono-runtime-dbg package
+(Closes: #773509, #773511)
+
+ -- Mirco Bauer mee...@meebey.net  Fri, 19 Dec 2014 11:47:22 +
+
 mono (3.2.8+dfsg-7) unstable; urgency=medium

   * [10016c2] Build libmono-2.0-1 and libmono-2.0-dev for mipsel
diff --git a/debian/rules b/debian/rules
index ac1c33b..f2cc3b7 100755
- --- a/debian/rules
+++ b/debian/rules
@@ -367,10 +367,10 @@ binary-arch: build-stamp install-stamp test-stamp
dh_installman -s
dh_installexamples -s
dh_installexamples -pmono-jay $(CURDIR)/mcs/jay/skeleton.cs
- -   dh_strip -pmono-runtime --dbg-package=mono-runtime-dbg
+   dh_strip -pmono-runtime-sgen -pmono-runtime-boehm
- --dbg-package=mono-runtime-dbg
dh_strip -plibmonoboehm-2.0-1 --dbg-package=libmonoboehm-2.0-1-dbg
dh_strip -plibmonosgen-2.0-1 --dbg-package=libmonosgen-2.0-1-dbg
- -   dh_strip -s -Xbin/mono-sgen
+   dh_strip -s -Xbin/mono-sgen -Xbin/mono-boehm
dh_compress -s -Xskeleton.cs

dh_fixperms -s


unblock mono/3.2.8+dfsg-9

- -- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500,
'trusty'), (100, 'trusty-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.0-43-generic (SMP w/4 CPU cores)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUlBIUAAoJEMkPnLkOH60Mmc0IAKHl2qh3S0bbtUz8I/UtNPAC
vl6B5x/VTcV1Ec+8ikuj+7G2OuVBG+36TWwPnlJUIT7a+3Vwre4jJ1YblzOshoPE
quLmEqAXjRAzbYgdqQGHNl5yU+de1wcJRlZOIdq5z29gnhC4QiEXWQP3nG036Z99
ULSK7vn8v1Ee4GAtDUUvLoe2Cbk2yFPcds9uzjv7kHu/LWLLOlwM0HuM2ndFUhD6
7b7f3rtBfzgLsC0TP9AQpqruRRyID9Vi006JiIjXgqMVn3OnvYqpfioJif1o3zLT
cupp+xL4pdLDXWlY7XsjuS0mNkADGdwuCDoW2HdSlEyzLpZwmonYjBzy/4lqZw0=
=4hN4
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#744128: [Pkg-utopia-maintainers] Bug#744128: network-manager-openvpn-gnome: Segfault in any configuration dialog

Am 19.12.2014 um 12:44 schrieb Dominik George:
 Attached is a backtrace and the OpenVPN config in question; however, I
 deem that irrelevant because empty dialogs for new connections crash as
 well.

I can't confirm that. I can create new OpenVPN connections in
nm-connection-editor just fine. Not sure what you mean with empty
dialogs, but unless you enter some minimal information (like gateway),
the save button is greyed out and you can't save the connection.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#773516: RFS: mkgmap/0.0.0+svn3383-1~exp1

2014-12-19 Thread Bas Couwenberg

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package mkgmap

 Package name: mkgmap
 Version : 0.0.0+svn3383-1~exp1
 Upstream Author : Steve Ratcliffe s...@parabola.me.uk
 URL : http://www.mkgmap.org.uk
 License : GPL-2+
 Section : utils

It builds those binary packages:

 mkgmap - Generate Garmin maps from OpenStreetMap data

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/mkgmap


Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/m/mkgmap/mkgmap_0.0.0+svn3383-1~exp1.dsc

More information about mkgmap can be obtained from http://www.mkgmap.org.uk.

Changes since the last upload:

  * New upstream SVN snapshot.
  * Mangle upstream version in watch file to properly rename orig.tar.gz.
  * Drop man page patches, applied upstream.
  * Simplify docs file with wildcards.


Regards,
 Bas Couwenberg


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773517: unblock: nvidia-graphics-drivers/340.65-2, nvidia-graphics-modules/340.65+3.16.0+1

2014-12-19 Thread Andreas Beckmann

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package nvidia-graphics-drivers

New upstream release fixing CVE-2014-8298.

the changelog diff is rather big since it adds missing history bits and
syncs with wheezy as well as the new upstreams inbetween

nvidia-graphics-modules has been rebuilt against the new driver

Andreas

unblock nvidia-graphics-drivers/340.65-2
unblock nvidia-graphics-modules/340.65+3.16.0+1
diff -Nru --exclude '*.run' nvidia-graphics-drivers-340.46/debian/changelog nvidia-graphics-drivers-340.65/debian/changelog
--- nvidia-graphics-drivers-340.46/debian/changelog	2014-11-30 20:08:09.0 +0100
+++ nvidia-graphics-drivers-340.65/debian/changelog	2014-12-16 22:57:34.0 +0100
@@ -1,3 +1,54 @@
+nvidia-graphics-drivers (340.65-2) unstable; urgency=medium
+
+  * Merge changes from 304.125-1.
+
+ -- Andreas Beckmann a...@debian.org  Tue, 16 Dec 2014 22:10:14 +0100
+
+nvidia-graphics-drivers (340.65-1) unstable; urgency=medium
+
+  * New upstream legacy 340xx branch release 340.65 (2014-12-08).
+* Fixes CVE-2014-8298.  (Closes: #772971)
+- Fixed a bug that prevented internal 4K panels on some laptops from being
+  driven at a sufficient bandwidth to support their native resolutions.
+- Fixed a regression that prevented the NVIDIA kernel module from loading
+  in some virtualized environments such as Amazon Web Services.
+- Fixed a regression that caused displays to be detected incorrectly on
+  some notebook systems.  (Closes: #770798, #765726)
+- Fixed a bug that could cause X to freeze when using Base Mosaic.
+- Fixed a regression that prevented the NVIDIA X driver from recognizing
+  Base Mosaic layouts generated by the nvidia-settings control panel.
+  * Merge changes from 304.125 (UNRELEASED).
+  * Add xorg-video-abi-19 as alternative dependency.
+
+ -- Andreas Beckmann a...@debian.org  Fri, 12 Dec 2014 21:10:11 +0100
+
+nvidia-graphics-drivers (340.58-1) unstable; urgency=medium
+
+  * New upstream legacy 340xx branch release 340.58 (2014-11-05).
+- Added support for the following GPUs: GeForce GT820M, GeForce GTX 760A,
+  GeForce GTX 850A, GeForce 810A, GeForce 820A, GeForce 840A, Tesla K8.
+- Fixed a bug that could cause VT-switching to fail following a
+  suspend, resume, and driver reload sequence.
+- Fixed a bug that caused incorrect colors to be displayed on X screens
+  running at depth 8 on some GPUs.
+- Fixed a bug that prevented GPUs from being correctly recognized in
+  MetaMode strings when identified by UUID.
+- Implemented support for disabling indirect GLX context creation using
+  the -iglx option available on X.Org server release 1.16 and newer.  Note
+  that future X.Org server releases may make the -iglx option the default.
+  To re-enable support for indirect GLX on such servers, use the +iglx
+  option.
+- Added the AllowIndirectGLXProtocol X config option.  This option can
+  be used to disallow use of GLX protocol.  See Appendix B. X Config
+  Options in the README for more details.
+  * Update nv-readme.ids.
+  * conftest.h:
+- Implement check for drm/drm_gem.h (340.58).
+- Implement new conftest.sh functions pci_save_state (340.58), follow_pfn,
+  fault_flags, atomic64_type (346.16).
+
+ -- Andreas Beckmann a...@debian.org  Wed, 10 Dec 2014 01:21:29 +0100
+
 nvidia-graphics-drivers (340.46-6) unstable; urgency=medium
 
   * nvidia-kernel-dkms: Switch to Recommends: nvidia-driver | libcuda1
@@ -55,8 +106,10 @@
 made available in jessie-backports (and experimental).
   * d/rules: Correctly parse PCI ID lists from upstream README of release
 343xx onwards.
-  * conftest.h: Implement extensions to conftest.sh function
-vm_operations_struct (343.13).
+  * conftest.h:
+- DRM is only supported on Linux = 3.9.  (Closes: #765679)
+- Implement extensions to conftest.sh function vm_operations_struct
+  (343.13).
   * bug-script: Collect more information.
   * Update lintian overrides.
   * nvidia-vdpau-driver: Support switching via nvidia-alternative.
@@ -70,7 +123,6 @@
   * d/rules{,.defs}: Drop MULTIARCH switch - this is always enabled nowadays.
   * libgl1-nvidia-glx.preinst: Rework the legacy check. Use more debconf
 variable substitutions for easy reuse of the translations.
-  * conftest.h: DRM is only supported on Linux = 3.9.  (Closes: #765679)
 
  -- Andreas Beckmann a...@debian.org  Mon, 20 Oct 2014 10:30:50 +0200
 
@@ -78,6 +130,8 @@
 
   [ Vincent Cheng ]
   * New upstream long lived branch release 340.46 (2014-09-30).
+- Fixed a crash with UnrealEngine 4 when the application was started
+  with the -opengl4 commandline switch.
 - Fixed an OpenGL issue that could cause glReadPixels() operations to
   be improperly clipped when resizing composited application windows,
   potentially leading to momentary X

Bug#771098: libjavascriptcoregtk-3.0-0: webkit browsers unusable on 32-bit powerpc

2014-12-19 Thread Paul Garlick


On 08/12 12:56, Alberto Garcia wrote:

Did you have the chance to try this? Thanks!

Berto


I have tested the browsers with 2.4.7-3 (without the patch) and the 
results are the same (immediate segmentation fault).  I will keep a look 
out for the first version that includes the patch and re-test then.


Cheers,

Paul.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772730: python3.4: pyvenv created virtual environments are missing their .whl files

2014-12-19 Thread Donald Stufft


 On Dec 19, 2014, at 5:36 AM, Matthias Klose d...@debian.org wrote:
 
 On 12/19/2014 07:40 AM, Donald Stufft wrote:
 
 On Dec 19, 2014, at 1:16 AM, Matthias Klose d...@debian.org wrote:
 
 On 12/19/2014 06:57 AM, Donald Stufft wrote:
 Ok, I hope I did this right. I made a sid system and updated/upgraded it 
 then I
 did apt-get source python3.4 and used quilt to edit ensurepip-wheels.diff 
 in order
 to fix pip inside of a virtual environment and then I added a new patch
 ensurepip-disabled.diff which I adapted from the one you have on Python 
 2.7 to
 disable ensurepip when running outside of a virtual environment.
 
 Output: https://bpaste.net/show/821a977c5f3c
 ensurepip-wheels.diff: https://bpaste.net/show/4e5852496eae
 ensurepip-disabled.diff: https://bpaste.net/show/5ed93f1df2fa
 
 I built the package, installed it and tested it (that’s what you see in 
 the output
 link).
 
 this patch restores the behaviour to install the wheels twice, one time 
 into a
 temporary directory, and one time into a directory in the venv? why is this
 double copy needed? If you require the wheels permanently in the virtual
 environment, why would you need the copy in the tempdir?
 
 
 It doesn’t copy them twice, it copies the wheels named in
 /usr/share/python-wheels/%s.dependencies of which there is only currently the
 one file, pip.dependencies whose contents are:
 
 chardet
 colorama
 distlib
 html5lib
 requests
 setuptools
 six
 urllib3
 
 Those are the dependencies that pip itself has, but importantly it’s not pip
 itself.
 
 Then it copies the projects named in the variable _PROJECTS, which is 
 currently
 setuptools and pip, into a temporary directory. This isn’t strictly required
 for Debian I think,
 
 so they are copied twice.

The only thing copied twice is the setuptools wheel. Everything else is copied 
once.
The setuptools wheel is copied twice because it is both desired to be installed 
into
the virtual environment AND we want it in the private python-wheel directory. 
It’s
two distinct lists of wheels copied into two different directories for two 
different
purposes. The *only* overlap is the setuptools Wheel because it serves two 
purposes.

 
 upstream ensurepip copies the bundled pip/setuptools wheels
 into a temporary directory because the stdlib might be zipped but I don’t 
 think
 Debian ships a zipped stdlib.
 
 correct.
 
 Anyways, once you have the pip and the setuptools wheels copied it then does 
 the
 normal ensurepip logical which is basically
 ``pip install —no-index —find-links /tmp/dir/ pip setuptools`` to actually 
 install
 pip and setuptools into the virtual environment.
 
 I don't see the pip wheel itself copied into the venv. the current loop only
 iterates over the project's (pip and setuptools) dependency wheels, not the 
 pip
 and setuptools wheels itself. These two wheels are only copied into the
 temporary directory. Yes, setuptools is in pip's dependency list, so it is 
 copied.

setuptools is in both lists because we want to install it into the virtual 
environment
so that other people can use it (such as importing it into their setup.py) and 
we want
it to be available to pip (because pip uses it) without people being able to 
break
pip by upgrading / downgrading / uninstalling setuptools.

 
 Essentially the first copy, into sys.prefix/lib/python-wheels is there to 
 approximate
 the bundled dependencies that pip normally has (we don’t want to install 
 these into
 the virtual environment because then ``pip uninstall requests`` inside of a 
 virtual
 env would break pip without a good way to fix it which is one of the reasons 
 pip
 bundles to begin with), and the second copy is just there to give pip a 
 directory
 with a pip and setuptools wheels in it so it can install pip and setuptools 
 into
 the virtual environment normally.
 
 Does that make sense?
 
 I'm still unsure why you make the distinction between the temporary and the
 permanent directory. as it looks like, the setuptools in python-wheels will
 never be used.
 

The distinction is this:

The permanent directory Wheels are never installed, pip has been modified by 
Debian to
add all of the .whl files from sys.prefix/lib/python-wheels to the front of 
sys.path so
that when pip does ``import requests`` or ``import pkg_resources`` it’ll use 
the copy
that is inside of the .whl files sitting in sys.prefix/lib/python-wheels and it 
doesn’t
depend what’s actually installed into the virtual environment. You can think of 
the
permanent wheel directory as a sort of static linking for pip inside of a 
virtual
environment, it’s Debian making pip work like pip was designed to work inside 
of a
virtual environment even though Debian has patched it to change that in the 
system.

The temporary directory is used by ensurepip to work around the fact that the 
standard
library can be zipped because we *need* to have the pip and the setuptools 
wheels
inside of a directory so that ensurepip can shell out to pip and tell it to

Bug#773518: explicit use-after-free

Package: gnupg2
Version: 2.1.1
Severity: normal

in gpgsm.c on line 861-867, there is an explicit use-after-free, if 'fail' is 
true.
keyserver_list_free does not return the function, leaving it to then return the 
freed value.

Thanks,

-- 
-- Joshua Rogers https://internot.info/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773519: libvte9: depends on transitional package libpango1.0-0

2014-12-19 Thread Wilfried Klaebe

Package: libvte9
Version: 1:0.28.2-5
Severity: minor

Dear Maintainer,

the current version of libvte9 in testing/unstable still depends on the
transitional package libpango1.0-0. Please update it to depend on the
appropriate newer packages, so that people can get rid of libpango1.0-0
and libpangox1.0-0.

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'testing'), (990, 'stable'), (900, 
'testing-updates'), (90, 'unstable'), (9, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libvte9 depends on:
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-13
ii  libcairo2   1.14.0-2.1
ii  libfontconfig1  2.11.0-6.3
ii  libfreetype62.5.2-2
ii  libgdk-pixbuf2.0-0  2.31.1-2+b1
ii  libglib2.0-02.42.1-1
ii  libgtk2.0-0 2.24.25-1
ii  libncurses5 5.9+20140913-1+b1
ii  libpango1.0-0   1.36.8-3
ii  libtinfo5   5.9+20140913-1+b1
ii  libvte-common   1:0.28.2-5
ii  libx11-62:1.6.2-3

libvte9 recommends no packages.

libvte9 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#773520: use-after-free

Package: gnupg2
Version: 2.1.1
Severity: normal


In ks-engine-hkp.c on line 509 'reftbl' is freed, but it is then used on line 
511. I'm guessing this is a missing return;.


Thanks,

-- 
-- Joshua Rogers https://internot.info/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773518: use-after-free

Sorry, I already reported this before:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773473

Please close.

Thanks,






-- 
-- Joshua Rogers https://internot.info/

Bug#773521: incorrect memset

Package: gnupg2
Version: 2.1.1
Severity: normal


on line 253 of ecdh.c, memset is called with a 0 fill value, which will do 
nothing. what's the point?

Thanks,

-- 
-- Joshua Rogers https://internot.info/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773522: info: H key does not show tutorial as documented

2014-12-19 Thread Sam Morris

Package: info
Version: 5.2.0.dfsg.1-6
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

H is supposed to show the info tutorial, but it instead opens the man
page for info.

- -- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (540, 'testing'), (530, 'unstable'), (520, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages info depends on:
ii  install-info  5.2.0.dfsg.1-6
ii  libc6 2.19-13
ii  libtinfo5 5.9+20140913-1+b1

info recommends no packages.

Versions of packages info suggests:
pn  texinfo-doc-nonfree  none

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUlCJjAAoJENILQgJc2ie5b1kP/1MsruC0AfMU92b+HPqHpCkI
Iz+Qde4/qJ6d3C7kAAlI0euQafoz6a/5rjE/OwncRVmhNngdhjj42zr8N7Nchhsu
reLG3BDJJmBMZ/Dd6sr4jL19ErYKlMrsOm+FDtK0YBIMHiErzIZP99EBYn/8x3C1
+NaeHVMCncbUkj2/TDuoYDB02Jsey/s8FRVXDrxt5pyaa3viayoHO1tKG/WB5zYb
tkifprd8WwUGdzFWAo7XjrDW1IeCMrJXfe11XP9mZKzkRHnQuzJ2AOvrtnAMkqLW
F42n89cHSCI9Zm/n8yKHF+j7VoDbVuPUNGhYqTALmmf0QQWjPKY4I0KV9htXzoaw
UJ1Uc8QzU/ictGdywWj1LSAlENtDXIwqnplgIgGynkfimlI92IycqUhFZ6N0Rkat
9//EmyjMBOI9hR4uhyWrnF9a+Zn0R4X7qj9UiZQMAO5q/PoKJLznF1CA3m6+coHI
Q0IvIw+/BHmpuMuPoiGA7feXxsEXlAqXtWxuGdr0BvhyKdAuTCPJhavlK/TqbuOb
sQNWa0LKnTn+zqmpWzEdJYdo94YN7G8rmYPRgYbQvthrz+QV4onQKoNxOHaqOyaN
d0KAaG5Y8S8x+wmBWvO4IySY0pzMAHYSZ9xROvn04sTA9e6UVEHSKVg+wxb3GJpl
Gg2kNV2eaAM6D7MsGorL
=3Vq7
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773523: use-after-free v2

Package: gnupg2
Version: 2.1.1
Severity: normal


In ldapserver.c on line 127, 'server' is freed, but it is then returned on line 
130.
This code looks like a copy and paste from gpgsm.c (see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773473)

Thanks,

-- 
-- Joshua Rogers https://internot.info/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773524: macchanger: [l10n:cs] Initial Czech PO debconf template translation

2014-12-19 Thread Michal Simunek

Package: macchanger
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

In attachment there is initial Czech translation of PO debconf template (cs.po)
for package macchanger, please include it.

Thanks for cooperation



-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), 
(500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=cs_CZ.utf8, LC_CTYPE=cs_CZ.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
# Czech PO debconf template translation of macchanger.
# Copyright (C) 2014 Michal Simunek michal.simu...@gmail.com
# This file is distributed under the same license as the macchanger package.
# Michal Simunek michal.simu...@gmail.com, 2014.
#
msgid 
msgstr 
Project-Id-Version: macchanger\n
Report-Msgid-Bugs-To: macchan...@packages.debian.org\n
POT-Creation-Date: 2014-12-18 13:38+0100\n
PO-Revision-Date: 2014-12-19 09:15+0200\n
Last-Translator: Michal Simunek michal.simu...@gmail.com\n
Language-Team: Czech debian-l10n-cz...@lists.debian.org\n
Language: cs\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=utf-8\n
Content-Transfer-Encoding: 8bit\n

#. Type: boolean
#. Description
#: ../templates:1001
msgid Change MAC automatically?
msgstr Změnit automaticky MAC adresu?

#. Type: boolean
#. Description
#: ../templates:1001
msgid 
Please specify whether macchanger should be set up to run automatically 
every time a network device is brought up or down. This gives a new MAC 
address whenever you attach an ethernet cable or reenable wifi.
msgstr 
Uveďte prosím, zda se má macchanger nastavit tak, aby se spouštěl pokaždé, 
když je připojeno, nebo odpojeno, síťové zařízení. Tím se pokaždé, když 
připojíte ethernetový kabel, nebo znovu zapnete wifi, získá nová MAC adresa.

Bug#773269: Computer crash when installing cups-daemon

Am 19.12.2014 um 08:32 schrieb Jos van Wolput:
 On 12/19/2014 06:28 AM, Michael Biebl wrote:
 Please enable persistent logging (see
 /usr/share/doc/systemd/README.Debian) and/or use something like SSH,
 which should allow you to access the system and then boot the system with
 systemd.log_level=debug on the kernel command line.

 If you can access the system via SSH, the output of journalctl -alb
 would be helpful. Is systemd still functional at this point, i.e. can
 you run systemctl status for example?

 
 As you asked I booted with systemd.log_level=debug on the kernel command
 line.
 Please see the attached daemon.log and kern.log.
 I swiched to tty1 (at 13:30) and started apt-get --reinstall install
 cups-daemon,
 soon screen output, keys and mouse stopped working.
 At 13.35 I started a hard reset.
 
 While I only have one computer I can't do SSH as suggested.
 Hopefully you can find a clue to solve this issue!

I couldn't find anything in the log which would indicate a crash or
malfunction of systemd. It seems to be running correctly up until the
time you force-reset the system.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#773286: Info received (It looks like a conspiracy between libvirt and kvm)


Well, I've upgraded to:

# dpkg -l libvirt* qemu* | grep '^ii'
ii  libvirt-bin 1.2.9-6~bpo70+1amd64
programs for the libvirt library
ii  libvirt-clients 1.2.9-6~bpo70+1amd64
programs for the libvirt library
ii  libvirt-daemon 1.2.9-6~bpo70+1amd64
programs for the libvirt library
ii  libvirt-daemon-system 1.2.9-6~bpo70+1
amd64Libvirt daemon configuration files
ii  libvirt0 1.2.9-6~bpo70+1amd64library 
for interfacing with different virtualization systems
ii  qemu-kvm 2.1+dfsg-9~bpo70+1 amd64QEMU 
Full virtualization on x86 hardware
ii  qemu-system-common 2.1+dfsg-9~bpo70+1 
amd64QEMU full system emulation binaries (common files)
ii  qemu-system-x86 2.1+dfsg-9~bpo70+1 amd64
QEMU full system emulation binaries (x86)
ii  qemu-utils 2.1+dfsg-9~bpo70+1 amd64QEMU 
utilities



But I get the same results:

adriatic:~# virsh attach-device cedric.CalvaEDI.COM zz.xml
error: Failed to attach device from zz.xml
error: internal error: unable to execute QEMU command 'device_add': Bus 
'pci.0' does not support hotplugging


However, I have found a clue:

cedric:~# dmesg | grep -i ACPI
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI BIOS Error (bug): A valid RSDP was not found 
(20140424/tbxfroot-211)

[0.245347] ACPI: Interpreter disabled.
[0.351414] pnp: PnP ACPI: disabled


And, looking on the host syststem I see:


adriatic:~# ps -ef | grep qemu | grep --color=always acpi
107   3088 1  1 12:38 ?00:01:27 qemu-system-x86_64 
-enable-kvm -name cedric.CalvaEDI.COM -S -machine 
pc-1.1,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 
1,sockets=1,cores=1,threads=1 -uuid 99cfca83-cf28-ce9b-86a4-947debc202b5 
-nographic -no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/cedric.CalvaEDI.COM.monitor,server,nowait 
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc 
-no-shutdown -no-acpi -boot strict=on -device 
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 
file=/dev/disk/by-id/md-name-cedric:root,if=none,id=drive-virtio-disk0,format=raw,cache=none 
-device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 
-drive 
file=/dev/disk/by-id/md-name-belgic:archive,if=none,id=drive-virtio-disk1,format=raw 
-device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 
-netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:16:3e:65:2d:8e,bus=pci.0,addr=0x3 
-chardev pty,id=charserial0 -device 
isa-serial,chardev=charserial0,id=serial0 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on



Note:

... -no-acpi ...

No ACPI, no hotplug?


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773417: heirloom-mailx: CVE-2004-2771 CVE-2014-7844

2014-12-19 Thread Hilko Bengen

* Salvatore Bonaccorso:

 the following vulnerabilities were published for heirloom-mailx.

  * CVE-2004-2771[0]
  * CVE-2014-7844[1]

I cannot update the package right now. If somebody wants to do prepare
an NMU for jessie and sid, please do so.

Cheers,
-Hilko


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773269: Computer crash when installing cups-daemon

Am 19.12.2014 um 14:48 schrieb Michael Biebl:
 Am 19.12.2014 um 08:32 schrieb Jos van Wolput:
 On 12/19/2014 06:28 AM, Michael Biebl wrote:
 Please enable persistent logging (see
 /usr/share/doc/systemd/README.Debian) and/or use something like SSH,
 which should allow you to access the system and then boot the system with
 systemd.log_level=debug on the kernel command line.

 If you can access the system via SSH, the output of journalctl -alb
 would be helpful. Is systemd still functional at this point, i.e. can
 you run systemctl status for example?


 As you asked I booted with systemd.log_level=debug on the kernel command
 line.
 Please see the attached daemon.log and kern.log.
 I swiched to tty1 (at 13:30) and started apt-get --reinstall install
 cups-daemon,
 soon screen output, keys and mouse stopped working.
 At 13.35 I started a hard reset.

 While I only have one computer I can't do SSH as suggested.
 Hopefully you can find a clue to solve this issue!
 
 I couldn't find anything in the log which would indicate a crash or
 malfunction of systemd. It seems to be running correctly up until the
 time you force-reset the system.

Could you also provide the requested journalctl output.
To get persistent logs, follow the instructions in
/usr/share/doc/README.Debian and create /var/log/journal.

This would you should have access the journal log after a reboot.
To get the logs of the previous, the following command should work

journalctl -alb -1

It would also help, if you can test with systemd from testing/unstable
and the Debian kernel from testing/unstable.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#773286:

2014-12-19 Thread Michael Tokarev

19.12.2014 16:50, John Hughes wrote:

 Note:
 
 ... -no-acpi ...
 
 No ACPI, no hotplug?

The linux guest-side module to handle hotplug is acpiphp.
I think the name speaks for itself.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773286:

2014-12-19 Thread Michael Tokarev

19.12.2014 16:59, Michael Tokarev wrote:
 19.12.2014 16:50, John Hughes wrote:
 
 Note:

 ... -no-acpi ...

 No ACPI, no hotplug?
 
 The linux guest-side module to handle hotplug is acpiphp.
 I think the name speaks for itself.

Also, libvirt isn't right (IMHO) to stick with particular
machine version (in your case, -M pc-1.1).  It is needed
for certain guest OS types, for example windows, to keep
its activation changes (so that hw should not change).
Linux is much more tolerant for hw changes.  And even for
windows it does not help in all cases (provided you don't
use corporate version of this OS where hw changes are not
relevant).

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773174: unblock: debdelta/0.55 , or discuss on the matter

2014-12-19 Thread A Mennucc1

Dear Jonathan Wiltshire,

I attach the debdiff (both for changes and for dsc)

thanks a lot

a.

File lists identical (after any substitutions)

Control files of package debdelta: lines which differ (wdiff format)

Installed-Size: [-408-] {+410+}
Version: [-0.50+2-] {+0.50+3+}

Control files of package debdelta-doc: lines which differ (wdiff format)

Version: [-0.50+2-] {+0.50+3+}
diff -Nru debdelta-0.50+2/debian/changelog debdelta-0.50+3/debian/changelog
--- debdelta-0.50+2/debian/changelog	2012-11-07 13:33:08.0 +0100
+++ debdelta-0.50+3/debian/changelog	2014-12-19 14:42:36.0 +0100
@@ -1,3 +1,14 @@
+debdelta (0.50+3) testing-proposed-updates; urgency=medium
+
+  * Ship new GPG key
+  * Bug fix: owned and unowned files after purge (policy 6.8 + 10.7.3),
+ (Closes: #617481).
+  * Portuguese translation, thanks to AmÃ©rico Monteiro  (Closes: #760731).
+  * Add a stanza in etc/sources.conf to find deltas for backports
+  * Thanks to Jonathan Wiltshire for T-P-U assistance
+
+ -- A Mennucc1 mennu...@debian.org  Fri, 19 Dec 2014 14:42:17 +0100
+
 debdelta (0.50+2) unstable; urgency=high
 
   * debdelta-upgrade: uses incorrect URL when requesting
diff -Nru debdelta-0.50+2/debian/postinst debdelta-0.50+3/debian/postinst
--- debdelta-0.50+2/debian/postinst	2011-03-31 11:32:26.0 +0200
+++ debdelta-0.50+3/debian/postinst	2014-12-19 14:10:08.0 +0100
@@ -1,19 +1,47 @@
-#!/bin/sh -e
+#!/bin/sh
+
+set  -e
+
+umask 0077
 
 GPG_MASTER_PUB_KEYRING=/usr/share/keyrings/debian-debdelta-archive-keyring.gpg
 GPG_HOME=/etc/debdelta/gnupg
 
+sha1it () {
+ (
+cd ${GPG_HOME}
+echo '#if this file is deleted or it does not match, then  '  sha1_hashes.txt
+echo '# these files will not be removed when purging debdelta  '  sha1_hashes.txt
+sha1sum pubring.gpg  secring.gpg  sha1_hashes.txt
+if test -f trustdb.gpg ; then sha1sum trustdb.gpg  sha1_hashes.txt ; fi
+ )
+}
+
+check1it () {
+ (
+  cd ${GPG_HOME}
+  test -f sha1_hashes.txt  sha1sum -c --quiet sha1_hashes.txt
+ )
+}
+
 case $1 in
   configure|reconfigure)
 if test ! -r ${GPG_HOME} ; then
+  echo Debdelta: creating ${GPG_HOME}
+  mkdir ${GPG_HOME}
+fi
+if test ! -r ${GPG_HOME}/pubring.gpg -a \
+! -r ${GPG_HOME}/secring.gpg   ; then
   echo Debdelta: creating keyrings in ${GPG_HOME}
-  mkdir  ${GPG_HOME}
-  chmod 0700  ${GPG_HOME}
-  touch   ${GPG_HOME}/secring.gpg   ${GPG_HOME}/pubring.gpg 
-  chmod 0600  ${GPG_HOME}/secring.gpg  ${GPG_HOME}/pubring.gpg
+  touch ${GPG_HOME}/secring.gpg  ${GPG_HOME}/pubring.gpg
+  sha1it
 else
   echo Debdelta: updating public keyring in ${GPG_HOME}
 fi
-gpg --no-tty --batch --no-options --no-auto-check-trustdb --homedir ${GPG_HOME} --import ${GPG_MASTER_PUB_KEYRING} || true 
+
+c=0 ;  if  check1it ; then   c=1 ;  fi
+gpg --no-tty --batch --no-options --no-auto-check-trustdb --homedir ${GPG_HOME} --import ${GPG_MASTER_PUB_KEYRING} || true
+if test $c = 1 ; then sha1it ; fi
+
 ;;
 esac
diff -Nru debdelta-0.50+2/debian/postrm debdelta-0.50+3/debian/postrm
--- debdelta-0.50+2/debian/postrm	2011-03-31 11:32:26.0 +0200
+++ debdelta-0.50+3/debian/postrm	2014-12-19 14:10:08.0 +0100
@@ -3,32 +3,28 @@
 
 GPG_HOME=/etc/debdelta/gnupg
 
+check1it () {
+ (
+  cd ${GPG_HOME}
+  test -f sha1_hashes.txt  sha1sum -c --quiet sha1_hashes.txt
+ )
+}
+
 if [ $1 = purge ] ; then
   if  [ -r /var/lib/debdelta ] ; then
 rm -r /var/lib/debdelta
   fi
 
-  if test -f ${GPG_HOME}/secring.gpg ; then 
-if test -s ${GPG_HOME}/secring.gpg ; then
-  echo debdelta: does not delete nonempty  ${GPG_HOME}/secring.gpg
-else
-  rm ${GPG_HOME}/secring.gpg 
-fi
-  fi
-
-  if test -f ${GPG_HOME}/pubring.gpg ; then
-  if  echo 4509b7260dc7aee6ec8dac68263bc662  ${GPG_HOME}/pubring.gpg | md5sum -c --quiet ; then 
-  rm ${GPG_HOME}/pubring.gpg 
-else
-  echo debdelta: does not delete modified  ${GPG_HOME}/pubring.gpg
-fi
+  if check1it ; then
+(
+  cd ${GPG_HOME}
+  rm -f pubring.gpg  secring.gpg  trustdb.gpg
+  if test -f pubring.gpg~ ; then
+  rm -f pubring.gpg~
+  fi
+  rm -f sha1_hashes.txt
+)
+rmdir ${GPG_HOME} || true
   fi
 
-  if test -f ${GPG_HOME}/pubring.gpg~ ; then
-rm ${GPG_HOME}/pubring.gpg~
-  fi
-
-  #unfortunately I could not spot a good way to detect if the
-  # trustdb does contain useful info
-
 fi
diff -Nru debdelta-0.50+2/etc/sources.conf debdelta-0.50+3/etc/sources.conf
--- debdelta-0.50+2/etc/sources.conf	2011-03-31 11:32:26.0 +0200
+++ debdelta-0.50+3/etc/sources.conf	2014-12-19 14:11:11.0 +0100
@@ -23,6 +23,11 @@
 Label=Debian
 delta_uri=http://debdeltas.debian.net/debian-deltas
 
+[backports debian archive]
+Origin=Debian Backports
+Label=Debian Backports

Bug#771485: installation-reports: Installation disk scan hangs at 81% with LVM inside crypt partition

2014-12-19 Thread Reto Buerki

Hi,

I encountered the same issue when trying to setup LVM inside a crypt
partition. The reason for the hanging partitioner is a crashing
'parted_server' process:

kernel: [  422.613251] parted_server[15630]: segfault at 8 ip
0040b4b1 sp 7fff35d63ee0 error 4 in parted_server[40+12000]

Disassembly:

 40b47d:   75 24   jne40b4a3
ped_disk_set_flag@plt+0x8ab3
  40b47f:   48 8b 35 4a 70 20 00mov0x20704a(%rip),%rsi#
6124d0 stderr+0x38
  40b486:   bf 8f fd 40 00  mov$0x40fd8f,%edi
  40b48b:   e8 10 70 ff ff  callq  4024a0 fputs@plt
  40b490:   48 8b 3d 39 70 20 00mov0x207039(%rip),%rdi#
6124d0 stderr+0x38
  40b497:   e8 54 72 ff ff  callq  4026f0 fflush@plt
  40b49c:   bf 8f fd 40 00  mov$0x40fd8f,%edi
  40b4a1:   eb 3d   jmp40b4e0
ped_disk_set_flag@plt+0x8af0
  40b4a3:   48 8b 43 40 mov0x40(%rbx),%rax
  40b4a7:   ba 0a 00 00 00  mov$0xa,%edx
  40b4ac:   be 03 f4 40 00  mov$0x40f403,%esi
 *40b4b1:   48 8b 78 08 mov0x8(%rax),%rdi*
  40b4b5:   e8 06 6f ff ff  callq  4023c0 strncmp@plt
  40b4ba:   85 c0   test   %eax,%eax
  40b4bc:   75 2b   jne40b4e9
ped_disk_set_flag@plt+0x8af9
  40b4be:   48 8b 35 0b 70 20 00mov0x20700b(%rip),%rsi#
6124d0 stderr+0x38
  40b4c5:   bf 95 fd 40 00  mov$0x40fd95,%edi

Boot method: USB
Image version: c5ce40b4e74f00ad94865c59b7bec2269e636955
debian-testing-amd64-netinst.iso (daily from 2014-12-19)

Please let me know if you need further information to debug the problem.

Kind regards,
- reto



signature.asc
Description: OpenPGP digital signature

Bug#768127: Fails to build the index when invalid UTF-8 is met

2014-12-19 Thread gregor herrmann

On Fri, 19 Dec 2014 07:57:15 +0200, Yavor Doganov wrote:

  Right, cloning+reassigning to ruby-debian might make sense.
  Let's do this :)
  (And close the original bug since it does fix another problem.)
 Thanks.  I used dpkg --update-avail to get rid of that ancient
 package and now dhelp works as expected.  (Thought dpkg was doing this
 automatically these days...)

Great!
 
  Probably the severity in the cloned bug in ruby-debian shoule be
  lowered; the problem might not be present if a non-UTF-9 file is not
  opened as UTF-8 ...
 You're probably right; it's up to the ruby-debian maintainers.

Already done by Antonio in the meantime, thanks.
 
 Thanks to both of you for your efforts.

Thanks for your patience :)


Cheers,
gregor 

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#771863: [ovs-dev] Bug#771863: [PKG-Openstack-devel] Bug#771863: Service does not start or parse interfaces correctly

2014-12-19 Thread Simon Horman

On Fri, Dec 19, 2014 at 06:39:39PM +0800, Thomas Goirand wrote:
 On 12/19/2014 11:50 AM, Simon Horman wrote:
  On Thu, Dec 18, 2014 at 05:30:42PM -0800, Joe Stringer wrote:
  On 18 December 2014 at 01:00, Fabio Fantoni fabio.fant...@m2r.biz wrote:
  One maintainer or debian developer can do a new build of ovs with the fix
  available in 2.3.1 please?
 
* Version 2.3.0+git20140819-2 of openvswitch is marked for
  autoremoval from testing on 2015-01-15.
* It is affected by RC bug #771863 https://bugs.debian.org/771863.
 
 
  Without this fix openvswitch will be removed from Jessie and I think this
  would be a bad thing.
 
  Thanks for any reply and sorry for my bad english.
 
  Ben usually takes care of this sort of thing, but he is out on holiday
  through to Christmas.
 
  Simon, would you be able to take care of this?
  
  Sure, I have uploaded a fresh package which attempts to do so.
  It contains no other changes.
 
 Simon,
 
 Did you ask for an unblock to the release team?

Hi Thomas,

I would be grateful for some assistance understanding what needs to
be done there. At this point I have not made any unblock requests.
But the intention of this upload was to provide something to
be included in Jessie and thus it needs to migrate to testing somehow.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#770788: [pkg-apparmor] Bug#770788: Patch: updated usr.bin.passwd profile

2014-12-19 Thread intrigeri

Hi,

seems to have been fixed upstream:
https://bazaar.launchpad.net/~apparmor-dev/apparmor/master/revision/2809

parspes, may you please check if it's working for you?

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773526: Please package new version 1.8.2

2014-12-19 Thread martin f krafft

Package: ansible
Version: 1.7.2+dfsg-2
Severity: wishlist

Subject says it all.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#773525: Randomly excludes available connections [when there are too many?]

2014-12-19 Thread Pietro Battiston

Package: network-manager
Version: 0.9.10.0-4
Severity: grave

Copypasted from a shell:

pietro@debiousci:~$ for i in `seq 1 10`; do nmcli c | wc; done
127 637   12827
127 637   12827
127 627   12827
126 628   12726
127 629   12573
127 634   12828
127 629   12827
127 630   12319
127 631   12827
127 627   12827


I am clearly not changing my list of available connections (so quick!). So what
is happening is that network-manager is dropping some of my registered
connections, in a random way. Initially I though it is unable to handle more
than 127, but then I saw that sometimes it only lists 126. The output of
nmcli c is otherwise almost sane (see below).

Some connections show up more frequently, some less. Consider for instance:

pietro@debiousci:~$ for i in `seq 1 10`; do nmcli c | grep -i condividi; done |
sort
Condividi 8a006f93-95ac-4683-a683-56413cbb95bb
802-3-ethernet   --
Condividi 8a006f93-95ac-4683-a683-56413cbb95bb
802-3-ethernet   --
Condividi 8a006f93-95ac-4683-a683-56413cbb95bb
802-3-ethernet   --
Condividi cab18fac-376f-42cf-9349-d9b4170dacce
802-3-ethernet   --
condividi con dnsmasq d54c2a91-f654-4d52-bdbd-cf9d8efdd9e5
802-3-ethernet   --
condividi  daa501b5-87eb-4a3f-a6d5-4fa73d042a66
802-3-ethernet   --
condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
802-3-ethernet   --
condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
802-3-ethernet   --
condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
802-3-ethernet   --
condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
802-3-ethernet   --
condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
802-3-ethernet   --
condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
802-3-ethernet   --
condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
802-3-ethernet   --
condividi   daa501b5-87eb-4a3f-a6d5-4fa73d042a66
802-3-ethernet   --

So
- one connection, Condividi, is shown 3 times out of 10
- one connection, condividi con dnsmasq, is shown 1 time only
- one connection, condividi, is shown most of the times... with different
space paddings

Different runs of the above command will clearly give different results, but
some connections are indeed more rare - i.e. condividi con dnsmasq usually
shows in none of the 10 tries - and some exhibit (even more than 2) different
space paddings. The wireless connection I need to use at work shows up more or
less once every 100 tries. Which, by the way, is very annoying: it usually
disables autoconnect, makes it virtually impossible to use gnome-control-center
(or the GNOME 3 drop-down menu) to connect, and makes it very hard and time
consuming also with nmcli c up (nm-connection-editor is also affected).

This is why the bug is grave: in particular, if a remote server relies on
network-manager in order to connect at startup... you'd better hope it is not
too remote.

The bug was present also with 0.9.10.0-3. My rough guess is that the
problematic upgrade was located between July and September.

P.S: just for info: _most_ of the connections are dropped:
pietro@debiousci:~$ ls /etc/NetworkManager/system-connections | wc
431 8918594



-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages network-manager depends on:
ii  adduser3.113+nmu3
ii  dbus   1.8.12-1
ii  init-system-helpers1.22
ii  isc-dhcp-client4.3.1-5
ii  libc6  2.19-13
ii  libdbus-1-31.8.12-1
ii  libdbus-glib-1-2   0.102-1
ii  libgcrypt201.6.2-4+b1
ii  libglib2.0-0   2.42.1-1
ii  libgnutls-deb0-28  3.3.8-5
ii  libgudev-1.0-0 215-7
ii  libmm-glib01.4.0-1
ii  libndp01.4-2
ii  libnewt0.520.52.17-1+b1
ii  libnl-3-2003.2.24-2
ii  libnl-genl-3-200   3.2.24-2
ii  libnl-route-3-200  3.2.24-2
ii  libnm-glib40.9.10.0-3
ii  libnm-util20.9.10.0-3
ii  libpam-systemd 215-7
ii  libpolkit-gobject-1-0  0.105-8
ii  libreadline6   6.3-8+b1
ii  libsoup2.4-1   2.48.0-1
ii  libsystemd0215-7
ii  libteamdctl0   1.12-1
ii  libuuid1   2.25.2-3
ii  lsb-base   4.1+Debian13+nmu1
ii  policykit-10.105-8
ii  udev   215-7
ii  wpasupplicant  2.3-1

Versions of packages network-manager recommends:

Bug#773323: perl: Wheezy-Jessie upgrade breaks wheezy pdl

2014-12-19 Thread Henning Glawe

On Fri, Dec 19, 2014 at 11:19:17AM +0200, Niko Tyni wrote:
   all the earlier ones, right? Also, AIUI the actual source change that
   fixes the breakage going forward is in 1:2.007-4 so it seems using
   that would be the most robust (think downstream distributions that
   might be upgrading their perl versions in a different schedule.)
 
   So is ( 1:2.007-4) OK with you?

Agreed.

 - which perl packages need this?
 
   The minimal recipe I could come up for this is
# wheezy base chroot
apt-get install libpdl-stats-perl
dpkg --unpack perl-modules_5.20.1-3_all.deb # from jessie
dpkg --remove libpdl-stats-perl
 
   or, alternatively,
# wheezy base chroot
apt-get install libpdl-stats-perl
dpkg -i libc6_2.19-13_amd64.deb
dpkg --unpack perl-base_5.20.1-3_amd64.deb 
dpkg --remove libpdl-stats-perl
 
   Interestingly, unpacking the new 'perl' package alone doesn't trigger the
   failure.

the 'guilty' dpkg-trigger is called whenever files are changed within
/usr/lib/perl5/PDL, which happens on installation/update/removal of optional
PDL submodules (in the reports, it was either hdf5 or stats).

The trigger itself relies on having the pdl main distribution modules
accessible from /usr/bin/perl (which is not the case if /usr/bin/perl
has been replaced by 5.20 packages, while installed pdl modules are only in
the searchpath of 5.14.

   So it looks like we need the Breaks in both perl-base and perl-modules.

That would be a safe choice, yes.

 - is Breaks sufficient, or do we need Conflicts?
 
   Dependency guarantees around 'postinst triggered' are not quite clear to me.
   I assume 'postinst triggered' will not be called before the package is
   configured, in which case I expect Breaks should be enough (as it will
   guarantee that the old pdl package gets deconfigured, and the new pdl 
 package
   won't be configured before its dependencies are installed.)

My knowledge of triggers is also rather limited... while writing the
offending code, I assumed that the same rules would apply for triggers as for
postinst configure, i.e. they could be only called if all dependencies are
fulfilled (and configured).

   Will test this, but any advice is appreciated.
 
 I hope to be able to upload a fix this weekend, assuming the version number
 thing above is confirmed one way or another.

thanks a lot, this one really costed me some nerves...

-- 
c u
henning


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771863: [ovs-dev] Bug#771863: [PKG-Openstack-devel] Bug#771863: Service does not start or parse interfaces correctly

2014-12-19 Thread Fabio Fantoni


Il 19/12/2014 15:25, Simon Horman ha scritto:

On Fri, Dec 19, 2014 at 06:39:39PM +0800, Thomas Goirand wrote:

On 12/19/2014 11:50 AM, Simon Horman wrote:

On Thu, Dec 18, 2014 at 05:30:42PM -0800, Joe Stringer wrote:

On 18 December 2014 at 01:00, Fabio Fantoni fabio.fant...@m2r.biz wrote:

One maintainer or debian developer can do a new build of ovs with the fix
available in 2.3.1 please?


   * Version 2.3.0+git20140819-2 of openvswitch is marked for
 autoremoval from testing on 2015-01-15.
   * It is affected by RC bug #771863 https://bugs.debian.org/771863.


Without this fix openvswitch will be removed from Jessie and I think this
would be a bad thing.

Thanks for any reply and sorry for my bad english.

Ben usually takes care of this sort of thing, but he is out on holiday
through to Christmas.

Simon, would you be able to take care of this?

Sure, I have uploaded a fresh package which attempts to do so.
It contains no other changes.

Simon,

Did you ask for an unblock to the release team?

Hi Thomas,

I would be grateful for some assistance understanding what needs to
be done there. At this point I have not made any unblock requests.
But the intention of this upload was to provide something to
be included in Jessie and thus it needs to migrate to testing somehow.

Thanks for the upload.
These information I think should be useful:
https://release.debian.org/jessie/freeze_policy.html
And here an example of unblock request:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771931


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773527: unblock: transmission/2.84-0.2

2014-12-19 Thread Markus Koschany

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Dear release team,

Please unblock package transmission.

The home directory of transmission-daemon's user debian-transmission
was set to the wrong directory. The error was exposed when systemd became the
default init system and transmission-daemon crashed since the required
configuration files were unavailable. The last NMU was incomplete
because removing Type=notify in transmission-daemon's service file only
suppressed the error but did not fix #718624.

The new revision fixes the issue by changing the home directory to
/var/lib/transmission-daemon, adjusting the permissions to debian-transmission
where necessary and creating symlinks to the old 
/var/lib/transmission-daemon/info
directory to ensure compatibility with the old sysV-init setup.

I am attaching the debdiff against the current version in testing.

unblock transmission/2.84-0.2

Regards,

Markus
diff -Nru transmission-2.84/debian/changelog transmission-2.84/debian/changelog
--- transmission-2.84/debian/changelog	2014-08-30 08:31:07.0 +0200
+++ transmission-2.84/debian/changelog	2014-12-10 08:20:54.0 +0100
@@ -1,3 +1,34 @@
+transmission (2.84-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * transmission-daemon.postinst:
+- Change home directory of transmission-daemon to
+  /var/lib/transmission-daemon from /home/debian-transmission.
+  Thanks to Alex Peters for the report. (Closes: #734467)
+- Disable password authentication for debian-transmission user for
+  improved security. Logins with e.g. SSH RSA keys are still possible.
+- Check existence of debian-transmission user with getent passwd
+  debian-transmission instead of id.
+  * Add transmission-daemon.preinst:
+- Fix permissions in /var/lib/transmission-daemon and use
+  /var/lib/transmission-daemon as the new home directory.
+- Move old configuration files to appropriate config directory
+  /var/lib/transmission-daemon/.config/transmission-daemon.
+  All together this ensures that transmission-daemon will not segfault
+  when systemd is the default init system.
+  Thanks to Andrei Popescu and Antoine Legonidec for the report and
+  additional tests. (Closes: #718624)
+  * transmission-daemon.links:
+- Link settings.json from /etc/transmission-daemon/settings.json to
+  /var/lib/transmission-daemon/.config/transmission-daemon.
+- Link /var/lib/transmission-daemon/.config/transmission-daemon to
+  /var/lib/transmission-daemon/info due to compatibility reasons with
+  the old sysv-rc init script settings.
+  * transmission-daemon.dirs:
+- Do not create /var/lib/transmission-daemon/info anymore.
+
+ -- Markus Koschany a...@gambaru.de  Wed, 10 Dec 2014 08:16:13 +0100
+
 transmission (2.84-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru transmission-2.84/debian/patches/systemd_service_fixes.patch transmission-2.84/debian/patches/systemd_service_fixes.patch
--- transmission-2.84/debian/patches/systemd_service_fixes.patch	2014-08-30 08:30:08.0 +0200
+++ transmission-2.84/debian/patches/systemd_service_fixes.patch	2014-12-10 08:20:54.0 +0100
@@ -1,27 +1,29 @@
 Description: fix segfaults due to wrong systemd service file
  The service file has the following line:
-  User=transmission
+ User=transmission
  .
  It should be replaced with:
-  User=debian-transmission
+ User=debian-transmission
  .
- Moreover, the type is set to notify, but it never sends a signal, so systemd
- kills it. Until this has been explained, this line should be removed.
-Author: Adrien CLERC bugs-deb...@antipoul.fr
-Bug-Debian: https://bugs.debian.org/718624
-Origin: other, https://bugs.debian.org/718624
-Forwarded: no
-Last-Update: 2014-07-18
+ Bug-Debian: https://bugs.debian.org/718624
+ Origin: other, https://bugs.debian.org/718624
+ Forwarded: no
+ Last-Update: 2014-10-16
 
 transmission-2.84.orig/daemon/transmission-daemon.service
-+++ transmission-2.84/daemon/transmission-daemon.service
-@@ -3,8 +3,7 @@ Description=Transmission BitTorrent Daem
+---
+ daemon/transmission-daemon.service | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/daemon/transmission-daemon.service b/daemon/transmission-daemon.service
+index 8a1d429..3687cf3 100644
+--- a/daemon/transmission-daemon.service
 b/daemon/transmission-daemon.service
+@@ -3,7 +3,7 @@ Description=Transmission BitTorrent Daemon
  After=network.target
  
  [Service]
 -User=transmission
--Type=notify
 +User=debian-transmission
+ Type=notify
  ExecStart=/usr/bin/transmission-daemon -f --log-error
  ExecReload=/bin/kill -s HUP $MAINPID
- 
diff -Nru transmission-2.84/debian/transmission-daemon.dirs transmission-2.84/debian/transmission-daemon.dirs
--- transmission-2.84/debian/transmission-daemon.dirs	2014-08-30 08:29:16.0 +0200
+++ transmission-2.84/debian/transmission-daemon.dirs

Bug#773528: systemd: enables audit without any hint on how to disable it

2014-12-19 Thread Martin Steigerwald

Package: systemd
Version: 218-2
Severity: normal

Dear Maintainer,

I wondered about the huge lot of audit messages in dmesg and syslog.

The following is just after a fresh boot:

merkaba:~ dmesg | grep audit | wc -l
38
merkaba:~ dmesg | grep audit | grep suppr
[   11.835476] audit_printk_skb: 282 callbacks suppressed


I am not interested in these whatsoever. They spam my logs and make it
more difficult for me to find important things in my log.

Do I really have to set the kernel parameter audit=0 to disable those?


Or can I override

merkaba:~ dpkg -L systemd | grep audit
/lib/systemd/system/systemd-journald-audit.socket
/lib/systemd/system/sockets.target.wants/systemd-journald-audit.socket

in order to get rid of it.

It might be nice to place something about this in Jessie releasenotes.

Users will find this unexpected log messages in their logs and wonder what
they are about.

I´d really prefer if more additional features that systemd enables would
be opt-in rather then opt-out. I still want to feel in control about what
is happening on my machines.

Ciao,
Martin

-- Package-specific info:

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.18.0-tp520 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-58
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-4
ii  libc6   2.19-13
ii  libcap2 1:2.24-6
ii  libcap2-bin 1:2.24-6
ii  libcryptsetup4  2:1.6.6-4
ii  libgcrypt20 1.6.2-4+b1
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libmount1   2.25.2-4
ii  libpam0g1.1.8-3.1
ii  libselinux1 2.3-2
ii  libsystemd0 218-2
ii  mount   2.25.2-4
ii  sysv-rc 2.88dsf-58
ii  udev215-8
ii  util-linux  2.25.2-4

Versions of packages systemd recommends:
ii  dbus1.8.12-1
ii  libpam-systemd  218-2

Versions of packages systemd suggests:
ii  systemd-ui  3-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738767: better upstream homepage URL

2014-12-19 Thread elfenlied

Changing the homepage field to http://www.anarchistfaq.org is better.
It points to a more recent version of the FAQ.

elfenlied


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773286:


On 19/12/14 14:59, Michael Tokarev wrote:

19.12.2014 16:50, John Hughes wrote:


Note:

... -no-acpi ...

No ACPI, no hotplug?

The linux guest-side module to handle hotplug is acpiphp.
I think the name speaks for itself.
When I can get my users to stop doing real work to let me play with my 
toy I'll try with featureacpi//feature.


If it works then I contend the bug is the error message -- it would be 
really helpful if it said You can't hotplug because you haven't got ACPI.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773529: new version of the FAQ available

2014-12-19 Thread elfenlied

Package: anarchism
Version: 14.0-3

Version 15.0 of An Anarchist FAQ is available at anarchistfaq.org
Please package it.

elfenlied


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773530: imagemagick: missing JPEG-2000 support

2014-12-19 Thread Yuriy Yevtukhov

Package: imagemagick
Version: 8:6.8.9.9-3
Severity: important

Missing JPEG-2000 support in ImageMagick package. List of delegates:
bzlib djvu mpeg fftw fontconfig freetype jbig jng jpeg lcms lqr lzma openexr 
pango png ps tiff wmf x xml zlib

List of formats:
.
  IPL* IPL   rw+   IPL Image Sequence
   ISOBRL* BRAILLE   -w-   ISO/TR 11548-1 format
  JBG* JBIG  rw+   Joint Bi-level Image experts Group interchange 
format (2.1)
 JBIG* JBIG  rw+   Joint Bi-level Image experts Group interchange 
format (2.1)
  JNG* PNG   rw-   JPEG Network Graphics
   See http://www.libpng.org/pub/mng/ for details about the JNG
   format.
  JNX* JNX   r--   Garmin tile format
 JPEG* JPEG  rw-   Joint Photographic Experts Group JFIF format (62)
  JPG* JPEG  rw-   Joint Photographic Experts Group JFIF format (62)
 JSON  JSON  -w+   The image format and characteristics
  K25  DNG   r--   Kodak Digital Camera Raw Image Format
..


It seems that support was not configured:
 ../../configure  '--build=x86_64-linux-gnu' '--includedir=${prefix}/include' 
'--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' 
'--localstatedir=/var' 
'--libdir=${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--prefix=/usr' 
'--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc' 
'--with-includearch-dir=/usr/include/x86_64-linux-gnu/' 
'--mandir=/usr/share/man' '--infodir=/usr/share/info' 
'--docdir=/usr/share/doc/imagemagick' '--with-modules' 
'--with-gs-font-dir=/usr/share/fonts/type1/gsfonts' '--with-magick-plus-plus' 
'--with-djvu' '--with-wmf' 
'--without-gvc' '--enable-shared' '--without-dps' '--without-fpx' '--with-perl' 
'--with-perl-options=INSTALLDIRS=vendor' '--x-includes=/usr/include/X11' 
'--x-libraries=/usr/lib/X11' '--without-rsvg' '--cache-file=../../config.cache' 
'--without-gcc-arch' '--disable-silent-rules' '--with-quantum-depth=16' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed' 
'CPPFLAGS=-D_FORTIFY_SOURCE=2' 
'CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security'


-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.8.9-9 Q16 x86_64 2014-11-15 http://www.imagemagick.org
compare:  ImageMagick 6.8.9-9 Q16 x86_64 2014-11-15 http://www.imagemagick.org
convert:  ImageMagick 6.8.9-9 Q16 x86_64 2014-11-15 http://www.imagemagick.org
composite:  ImageMagick 6.8.9-9 Q16 x86_64 2014-11-15 http://www.imagemagick.org
conjure:  ImageMagick 6.8.9-9 Q16 x86_64 2014-11-15 http://www.imagemagick.org
display:  ImageMagick 6.8.9-9 Q16 x86_64 2014-11-15 http://www.imagemagick.org
identify:  ImageMagick 6.8.9-9 Q16 x86_64 2014-11-15 http://www.imagemagick.org
import:  ImageMagick 6.8.9-9 Q16 x86_64 2014-11-15 http://www.imagemagick.org
mogrify:  ImageMagick 6.8.9-9 Q16 x86_64 2014-11-15 http://www.imagemagick.org
montage:  ImageMagick 6.8.9-9 Q16 x86_64 2014-11-15 http://www.imagemagick.org
stream:  ImageMagick 6.8.9-9 Q16 x86_64 2014-11-15 http://www.imagemagick.org

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32.59 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages imagemagick depends on:
ii  imagemagick-6.q168:6.8.9.9-3 image manipulation programs -- qua

imagemagick recommends no packages.

imagemagick 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#773525: [Pkg-utopia-maintainers] Bug#773525: Randomly excludes available connections [when there are too many?]

Control: severity -1 important
Control: tags -1 moreinfo

Am 19.12.2014 um 15:32 schrieb Pietro Battiston:
 Package: network-manager
 Version: 0.9.10.0-4
 Severity: grave
 
 Copypasted from a shell:
 
 pietro@debiousci:~$ for i in `seq 1 10`; do nmcli c | wc; done
 127 637   12827
 127 637   12827
 127 627   12827
 126 628   12726
 127 629   12573
 127 634   12828
 127 629   12827
 127 630   12319
 127 631   12827
 127 627   12827
 
 
 I am clearly not changing my list of available connections (so quick!). So 
 what
 is happening is that network-manager is dropping some of my registered
 connections, in a random way. Initially I though it is unable to handle more
 than 127, but then I saw that sometimes it only lists 126. The output of
 nmcli c is otherwise almost sane (see below).
 
 Some connections show up more frequently, some less. Consider for instance:
 
 pietro@debiousci:~$ for i in `seq 1 10`; do nmcli c | grep -i condividi; done 
 |
 sort
 Condividi 8a006f93-95ac-4683-a683-56413cbb95bb
 802-3-ethernet   --
 Condividi 8a006f93-95ac-4683-a683-56413cbb95bb
 802-3-ethernet   --
 Condividi 8a006f93-95ac-4683-a683-56413cbb95bb
 802-3-ethernet   --
 Condividi cab18fac-376f-42cf-9349-d9b4170dacce
 802-3-ethernet   --
 condividi con dnsmasq d54c2a91-f654-4d52-bdbd-cf9d8efdd9e5
 802-3-ethernet   --
 condividi  daa501b5-87eb-4a3f-a6d5-4fa73d042a66
 802-3-ethernet   --
 condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
 802-3-ethernet   --
 condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
 802-3-ethernet   --
 condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
 802-3-ethernet   --
 condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
 802-3-ethernet   --
 condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
 802-3-ethernet   --
 condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
 802-3-ethernet   --
 condividi daa501b5-87eb-4a3f-a6d5-4fa73d042a66
 802-3-ethernet   --
 condividi   daa501b5-87eb-4a3f-a6d5-4fa73d042a66
 802-3-ethernet   --
 
 So
 - one connection, Condividi, is shown 3 times out of 10
 - one connection, condividi con dnsmasq, is shown 1 time only
 - one connection, condividi, is shown most of the times... with different
 space paddings
 
 Different runs of the above command will clearly give different results, but
 some connections are indeed more rare - i.e. condividi con dnsmasq usually
 shows in none of the 10 tries - and some exhibit (even more than 2) different
 space paddings. The wireless connection I need to use at work shows up more or
 less once every 100 tries. Which, by the way, is very annoying: it usually
 disables autoconnect, makes it virtually impossible to use 
 gnome-control-center
 (or the GNOME 3 drop-down menu) to connect, and makes it very hard and time
 consuming also with nmcli c up (nm-connection-editor is also affected).
 
 This is why the bug is grave: in particular, if a remote server relies on
 network-manager in order to connect at startup... you'd better hope it is not
 too remote.

Not really, grave means, the package is unusable, which it clearly i'snt.

 The bug was present also with 0.9.10.0-3. My rough guess is that the
 problematic upgrade was located between July and September.
 

Can you pinpoint the exact version please.


 pietro@debiousci:~$ ls /etc/NetworkManager/system-connections | wc
 431 8918594

How did you generate 431 connections? Did you copy files around?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#773528: systemd: enables audit without any hint on how to disable it

Am 19.12.2014 um 15:39 schrieb Martin Steigerwald:
 Package: systemd
 Version: 218-2
 Severity: normal
 
 Dear Maintainer,
 
 I wondered about the huge lot of audit messages in dmesg and syslog.
 
 The following is just after a fresh boot:
 
 merkaba:~ dmesg | grep audit | wc -l
 38
 merkaba:~ dmesg | grep audit | grep suppr
 [   11.835476] audit_printk_skb: 282 callbacks suppressed
 
 
 I am not interested in these whatsoever. They spam my logs and make it
 more difficult for me to find important things in my log.
 
 Do I really have to set the kernel parameter audit=0 to disable those?
 
 
 Or can I override
 
 merkaba:~ dpkg -L systemd | grep audit
 /lib/systemd/system/systemd-journald-audit.socket
 /lib/systemd/system/sockets.target.wants/systemd-journald-audit.socket
 
 in order to get rid of it.
 
 It might be nice to place something about this in Jessie releasenotes.
 

How is that relevant for jessie which has v215?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#773531: vim-doc: typo in vim-policy

2014-12-19 Thread Jakukyo Friel

Package: vim-doc
Version: 2:7.4.488-3
Severity: minor
Tags: patch

There is a typo in vim-policy.
Below is a patch for vim-policy.txt.
(This typo appears in the html version also.)

--- vim-policy.txt.orig 2014-12-19 21:57:15.388753388 +0800
+++ vim-policy.txt  2014-12-19 22:13:20.296553799 +0800
@@ -177,7 +177,7 @@
according to the convention PKGNAME.yaml, where PKGNAME is the
name of the Debian package shipping it. There is no need to
create the file in postinst, you can ship it normally as a file
-   contained in a your package.[2]
+   contained in your package.[2]
  __
 
 3.3. Registry Entries


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773286:

2014-12-19 Thread Michael Tokarev

19.12.2014 17:42, John Hughes wrote:
[]
 If it works then I contend the bug is the error message -- it would be really 
 helpful if it said You can't hotplug because you haven't got ACPI.

acpi is not the only possible way.  More recent qemu (not pc-1.1 which
you used) also has pcie bus, which does support hotplugging without acpi.
But you used both pc-1.1 (old non-pcie machine) and no-acpi.

Also, I _think_ hotplug can be disabled by a command-line switch (not sure
but think).

All ways leads to bus-enable_hotplug property set to false, which is
being checked right before printing that error message.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773286:


On 19/12/14 15:10, Michael Tokarev wrote:

Also, libvirt isn't right (IMHO) to stick with particular
machine version (in your case, -M pc-1.1).  It is needed
for certain guest OS types, for example windows, to keep
its activation changes (so that hw should not change).
Linux is much more tolerant for hw changes.  And even for
windows it does not help in all cases (provided you don't
use corporate version of this OS where hw changes are not
relevant).


That's libvirt's translation of my previous Xen configuration.  (In fact 
I think that all of my problems have come about because of libvirt being 
rather dumb about converting from Xen to KVM).



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766708: counterfeiting the summary of the bootstrap sprint

2014-12-19 Thread YunQiang Su

I have a suggestion:

Wookey, can you use package name like cpp-4.9-armhf instead of
cpp-4.9-arm-linux-gnuabihf ?
Then we can have both schemes in archive?

Wookey, can you remove cross-gcc-* packages from archive temporarily?

Doko, can you merge the attached patches?

In 0006-gcc-pkg-rename.patch, and when define
with_deps_on_target_arch_pkgs, gcc-4.9-ARCH will be generated instead
of gcc-4.9-triplet.


On Fri, Dec 5, 2014 at 11:28 AM, YunQiang Su wzss...@gmail.com wrote:
 On Thu, 04 Dec 2014 20:41:57 +0100 Matthias Klose d...@debian.org wrote:
 So in the last email Wookey enumerates a lot of things what he did during the
 last months.  Maybe he should have mentioned his ballerina lessons used for 
 his
 performances during the DebConf talks too.  However ever all of these have in
 common, that this has nothing to do at all with the work he committed to do.

 Further he cites a paragraph from the debian-bootstrap sprint summary, which 
 reads:

 
 The report from that meeting
 https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results says:
 --
 3.13. Multiarch cross-toolchains vs single-arch cross-toolchains

 This contentious issue was discussed, and is partly covered under other
 headings. Wookey prefers the multiarch builds, Doko prefers the single-arch
 bootstrap builds. We agreed that either provides useful cross-toolchains. 
 It's
 not clear whether it's easier to fix the Ubuntu cross-toolchain-base packages
 to do a bootstrap build in Debian, or to fix the blockers for multiarch 
 builds
 in the archive. Whichever is working first should get uploaded.
 

 Good summery, and I also prefer multiarch builds and I also maintain
 it for mips64el.
 And more:

 multiarch builds can also bootstrap. I bootstrapped mips64el in this way,
 and now, it need some dirty hacks,while
 if we wish, we can make it much more clean.

 As I noticed that, the argument that to remove multiarch builds
 includes (wish I am right):

 1. multiarch builds make single-arch some more difficult, and maintain 2 way 
 is not a esay way.

 Yes, while it is more difficult not impossible.

 2. multiarch builds needs cross depends, which is hard for Debian 
 infrastructure

 Yes, this is a problem for now, while I think this is the direction we
 are stepping for.

 3. Bootstrap need single-arch

 No, this is wrong, we can bootstrap Debian with multiarch builds.
 The steps are:
  1. cross binutils  -  we have it in archive.
  2. stage1 gcc, with only C support, and libgcc is also disabled.
  3. stage1 glibc - it is a fake libc6, we can patch glibc to archive it.
  4. linux-libc-dev  -  we can use stage1 gcc to get it. src:linux
 support it now.
  5. stage2 gcc  - it has shared and static libraries support now
and libgcc etc are still disabled
  6. stage2 glibc - now we can use stage2 gcc to build glib, and we can get
   libc6(-dev) and multilib libc6.
  7. stage3 gcc, now we can build a gcc with C,C++,Go, D and fortran 
 support.

 In every step, we get some DEBs, and we can install some of them, and
 go to the next step.
 Of course, these steps may make some trouble for packages like
 gcc-4.8-armhf-cross.
 If we split it to more than one source packages, it is still possible when
 infrastructure support.
 If you repack these DEBs, it also can archive the goal of current
 gcc-4.8-armhf-cross.


 By the way, if we remove single-arch build, this package will be much
 more clean than now,
 lots of hacks can be removed from current gcc-4.9 and make life more happy.


 According to
 https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results?action=diffrev1=30rev2=31
 the last sentence was added on Aug 29 during DebConf, long after the sprint
 happened, with a commment must be almost the final review, without 
 mentioning
 anything. I call this counterfeiting the summary of the sprint.  I assume 
 this
 helped to convince other people to sneak in these packages into Debian. What 
 is
 this if not bad faith?

 Again, the rest of the email talking about willing to work together doesn't
 match the his actions at all.

 Matthias





-- 
YunQiang Su


0001-libgcc-4.9-dev-depends-equal.patch
Description: Binary data


0002-gcc_cross_multiarch.patch
Description: Binary data


0003-allow-no-biarch.patch
Description: Binary data


0004-gxx-crossbase-substvar.patch
Description: Binary data


0005-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch
Description: Binary data


0006-gcc-pkg-rename.patch
Description: Binary data

Bug#773528: systemd: enables audit without any hint on how to disable it

2014-12-19 Thread Martin Steigerwald

Am Freitag, 19. Dezember 2014, 15:47:28 schrieb Michael Biebl:
 Am 19.12.2014 um 15:39 schrieb Martin Steigerwald:
  Package: systemd
  Version: 218-2
  Severity: normal
  
  Dear Maintainer,
  
  I wondered about the huge lot of audit messages in dmesg and syslog.
  
  The following is just after a fresh boot:
  
  merkaba:~ dmesg | grep audit | wc -l
  38
  merkaba:~ dmesg | grep audit | grep suppr
  [   11.835476] audit_printk_skb: 282 callbacks suppressed
  
  
  I am not interested in these whatsoever. They spam my logs and make it
  more difficult for me to find important things in my log.
  
  Do I really have to set the kernel parameter audit=0 to disable those?
  
  
  Or can I override
  
  merkaba:~ dpkg -L systemd | grep audit
  /lib/systemd/system/systemd-journald-audit.socket
  /lib/systemd/system/sockets.target.wants/systemd-journald-audit.socket
  
  in order to get rid of it.
  
  It might be nice to place something about this in Jessie releasenotes.
 
 How is that relevant for jessie which has v215?

And with that question you dismiss the rest of my bug report? I asked some 
more question.

I was not aware on when this started to happen, if Jessie is not affected, all 
the better.

Still, I want it to stop. Now. So I am using the audit=0 kernel parameter as 
your answer didn´t provide any helpful hint on how else get rid of this audit 
crap. This is a desktop. My debian desktops have done for +10 years without 
this crap. No one ever intruded any of my desktops. So what gives? I am just 
not interested in that. I am just not *at all* interested in that crap.

And either this systemd thing will do what I want, or I will force it to do 
what I want, or I will kick it out of my systems. Its that easy.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

signature.asc
Description: This is a digitally signed message part.

Bug#773532: better upstream homepage URL

2014-12-19 Thread Holger Levsen

package: anarchism
severity: wishlist
owner: elfenl...@riseup.net
# thanks, elfenlied!  cheers!

--  Forwarded Message  --

Betreff: Bug#738767: better upstream homepage URL
Datum: Freitag, 19. Dezember 2014
Von: elfenl...@riseup.net
An: 738...@bugs.debian.org

Changing the homepage field to http://www.anarchistfaq.org is better.
It points to a more recent version of the FAQ.

elfenlied

---


signature.asc
Description: This is a digitally signed message part.

Bug#773286:


On 19/12/14 15:53, Michael Tokarev wrote:


acpi is not the only possible way.  More recent qemu (not pc-1.1 which
you used) also has pcie bus, which does support hotplugging without acpi.
But you used both pc-1.1 (old non-pcie machine) and no-acpi.


Ok, thanks.  Still waiting for people to stop work so I can try this.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773525: [Pkg-utopia-maintainers] Bug#773525: Randomly excludes available connections [when there are too many?]

2014-12-19 Thread Pietro Battiston

Il giorno ven, 19/12/2014 alle 15.45 +0100, Michael Biebl ha scritto:
 [...]
 Am 19.12.2014 um 15:32 schrieb Pietro Battiston:
 [...]
  This is why the bug is grave: in particular, if a remote server relies on
  network-manager in order to connect at startup... you'd better hope it is 
  not
  too remote.
 
 Not really, grave means, the package is unusable, which it clearly i'snt.
 

It is hardly usable for me - it would be totally unusable for me if at
work I did not (usually) have also a cable connection, which usually
works (or maybe I just created enough copies of it? don't know...).

Except that your question below seems to imply nobody except me has many
( 127, presumably?) connections. So, OK, if it's just me I understand.
My best guess is that computers on which many connections got remembered
along the years are statistically not the same ones which are updated to
testing, but I have no data to test this hypothesis.


  The bug was present also with 0.9.10.0-3. My rough guess is that the
  problematic upgrade was located between July and September.
  
 
 Can you pinpoint the exact version please.
 

(I'm not forgetting your request, but I don't think I will manage to do
it today)


  pietro@debiousci:~$ ls /etc/NetworkManager/system-connections | wc
  431 8918594
 
 How did you generate 431 connections? Did you copy files around?
 

Yeah, I enjoy copying files around!

No.

Looking at them, I certainly have some doubles, i.e. because one
connection did not show up so I recreated it thinking it had completely
disappeared. But mostly (300) they are real connections. The oldest
ones are from 2011, which means ~ 1.5 per week... given that I travel
quite a bit, I hack quite a bit, and when I am without Internet and see
some open wireless I often try to connect, this is not a particularly
strange number.

Pietro


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773512: Attaching file

If the generation of JP2 file is too complex, here is an example file.
It is 44K so I believe this is safe to attach it to the bug.

Bug#773533: efivarfs not mounted by default

2014-12-19 Thread Leif Lindholm

Package: systemd
Severity: normal

The efivarfs kernel module is built for all UEFI-capable platforms
(i386, amd64, arm64), but since systemd is build with --disable-efi,
the filesystem is not mounted at boot-time on
/sys/firmware/efi/efivars.

This makes the efivars package (used by commands like efibootmgr) fall
back to the legacy efivars interface (/sys/firmware/efi/vars), which
suffers from various limitations - the most obvious one being a hard
limit on 1024 bytes on any variable.

Could we build systemd without --disable-efi, please?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773512: Attaching file

Just for reference, chromium crashed:

[86573.137553] chromium[2233]: segfault at 0 ip 7fce4aeeb785 sp
7fff21991b20 error 6 in libjasper.so.1.0.0[7fce4aebc000+4f000]

You have to be very quick to attach the file before the thumbnail
generation (I passed the full path directly in the file dialog to
avoid this step completely).


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773512: Attaching file

On Fri, Dec 19, 2014 at 4:16 PM, Mathieu Malaterre ma...@debian.org wrote:
 If the generation of JP2 file is too complex, here is an example file.
 It is 44K so I believe this is safe to attach it to the bug.

While the filename claims the file is all white, it is in fact all
black... zero is actually black in JP2.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773525: [Pkg-utopia-maintainers] Bug#773525: Randomly excludes available connections [when there are too many?]

Am 19.12.2014 um 16:15 schrieb Pietro Battiston:
 Il giorno ven, 19/12/2014 alle 15.45 +0100, Michael Biebl ha scritto:
 Am 19.12.2014 um 15:32 schrieb Pietro Battiston:

 pietro@debiousci:~$ ls /etc/NetworkManager/system-connections | wc
 431 8918594

 How did you generate 431 connections? Did you copy files around?

 
 Yeah, I enjoy copying files around!
 
 No.
 
 Looking at them, I certainly have some doubles, i.e. because one
 connection did not show up so I recreated it thinking it had completely
 disappeared. 

The reason I was asking is, that by manually copying and creating files
in /etc/NetworkManager/system-connections, you might end up with
connection files, with non-unique UUIDs, not being valid/properly
formatted etc. which *might* confuse NetworkManager.

It might probably also be useful to get a debug log from NetworkManager. See
https://wiki.gnome.org/Projects/NetworkManager/Debugging


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#771863: [PKG-Openstack-devel] [ovs-dev] Bug#771863: Bug#771863: Service does not start or parse interfaces correctly

On 12/19/2014 10:25 PM, Simon Horman wrote:
 On Fri, Dec 19, 2014 at 06:39:39PM +0800, Thomas Goirand wrote:
 On 12/19/2014 11:50 AM, Simon Horman wrote:
 On Thu, Dec 18, 2014 at 05:30:42PM -0800, Joe Stringer wrote:
 On 18 December 2014 at 01:00, Fabio Fantoni fabio.fant...@m2r.biz wrote:
 One maintainer or debian developer can do a new build of ovs with the fix
 available in 2.3.1 please?

   * Version 2.3.0+git20140819-2 of openvswitch is marked for
 autoremoval from testing on 2015-01-15.
   * It is affected by RC bug #771863 https://bugs.debian.org/771863.


 Without this fix openvswitch will be removed from Jessie and I think this
 would be a bad thing.

 Thanks for any reply and sorry for my bad english.

 Ben usually takes care of this sort of thing, but he is out on holiday
 through to Christmas.

 Simon, would you be able to take care of this?

 Sure, I have uploaded a fresh package which attempts to do so.
 It contains no other changes.

 Simon,

 Did you ask for an unblock to the release team?
 
 Hi Thomas,
 
 I would be grateful for some assistance understanding what needs to
 be done there. At this point I have not made any unblock requests.
 But the intention of this upload was to provide something to
 be included in Jessie and thus it needs to migrate to testing somehow.

I'm sending the unblock request as we speak.

Thomas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773534: unblock: openvswitch/2.3.0+git20140819-3

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Dear release team,

As Simon Horman, the last uploader of openvswitch, wrote that he would like
some assistance, I'm writing this unblock requests on his behalf.

The latest upload of openvswitch fixes RC bug #771863:
Service does not start or parse interfaces correctly.

The debdiff (attached to this message) is very small, and deals only with
the init script.

Please unblock openvswitch/2.3.0+git20140819-3

Cheers,

Thomas Goirand (zigo)
diff -Nru openvswitch-2.3.0+git20140819/debian/changelog openvswitch-2.3.0+git20140819/debian/changelog
--- openvswitch-2.3.0+git20140819/debian/changelog	2014-08-20 15:35:32.0 +
+++ openvswitch-2.3.0+git20140819/debian/changelog	2014-12-19 03:32:53.0 +
@@ -1,3 +1,15 @@
+openvswitch (2.3.0+git20140819-3) unstable; urgency=medium
+
+  * Don't depened on $RUNLEVEL at startup to create bridges.
+This should allow Open vSwitch configuration through
+/etc/network/interfaces where $RUNLEVEL is not set.
+This change is upstream commit 238324bd73b031635
+(debian: Don't depened on $RUNLEVEL at startup to create bridges.)
+Closes: #771863
+  * 
+
+ -- Simon Horman ho...@debian.org  Fri, 19 Dec 2014 10:54:08 +0900
+
 openvswitch (2.3.0+git20140819-2) unstable; urgency=low
 
   * debian/rules: Rerun checks on tests that fail the first time.  Skip
diff -Nru openvswitch-2.3.0+git20140819/debian/openvswitch-switch.init openvswitch-2.3.0+git20140819/debian/openvswitch-switch.init
--- openvswitch-2.3.0+git20140819/debian/openvswitch-switch.init	2014-08-19 15:30:43.0 +
+++ openvswitch-2.3.0+git20140819/debian/openvswitch-switch.init	2014-12-19 02:18:44.0 +
@@ -31,7 +31,6 @@
 test -e /etc/default/openvswitch-switch  . /etc/default/openvswitch-switch
 
 network_interfaces () {
-[ -z ${RUNLEVEL} ]  return
 INTERFACES=/etc/network/interfaces
 [ -e ${INTERFACES} ] || return
 bridges=`awk '{ if ($1 == allow-ovs) { print $2; } }' ${INTERFACES}`
@@ -62,11 +61,13 @@
 fi
 set $@ $OVS_CTL_OPTS
 $@ || exit $?
-[ $2 = start ]  network_interfaces ifup
+if [ $2 = start ]  [ $READ_INTERFACES != no ]; then
+network_interfaces ifup
+fi
 }
 
 stop () {
-network_interfaces ifdown
+[ $READ_INTERFACES != no ]  network_interfaces ifdown
 ovs_ctl stop
 }
 
@@ -101,8 +102,8 @@
 start restart
 fi
 else
-stop
-start
+READ_INTERFACES=no stop
+READ_INTERFACES=no start
 fi
 }

Bug#773533: efivarfs not mounted by default