Bug#736421: gnome-screenshot: Wrong Italian translation of the file name

[Massimo Barbieri]

Il 19/02/2014 18:54, althaser ha scritto:
> Could you try gnome's
> people: https://git.gnome.org/browse/gnome-screenshot/tree/po/it.po

Hi Althaser,
the bug is still present in line 286 and 294. "Schermata da" have to be
changed in "Schermata del".

Best regards,
Massimo

-- 
IM: mass...@jabber.fsfe.org - GnuPG Public Key-Id: 0x5D168FC1



signature.asc
Description: OpenPGP digital signature

Bug#727670: Please add calendar and carddav plugins

[pauli]

You can look at this: http://www.crash-override.net/carddav.html

It seems actively developed.


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

Bug#739554: qpdfview: please implement a zoom to selection option

[Benjamin Eltzner]

Hi Francesco,

thank you for sharing your suggestion. I pushed your feature request
upstream

https://bugs.launchpad.net/qpdfview/+bug/1282442

However, I must say that I personally do not miss this feature, as there
are a number of ways to adjust zoom in qpdfview, and the "drag and pan"
functionality (accessible by simply clicking and dragging) makes for a
quick and precise adjustment of the viewing area in my opinion. That is
to say, if Adam is very busy, this feature is not high on my priority
list so this may take indefinite time. :-)

Cheers,
Benjamin


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

Bug#739588: gnome-music crashes during start

[Michael Ott]

Package: gnome-music
Version: 3.11.90-1
Severity: important

Dear Maintainer,

When I try to start the app I got the following lines:
~$ gnome-music 
Traceback (most recent call last):
  File "/usr/bin/gnome-music", line 10, in 
from gi.repository import Gio, Gtk
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 27, in 
from ._gi import _API
ImportError: No module named 'gi._gi'


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (650, 'testing'), (600, 'stable'), (500, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armhf
armel

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

Versions of packages gnome-music depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.18.0-1
ii  gir1.2-glib-2.0  1.39.90-1
ii  gir1.2-grilo-0.2 0.2.9-1
ii  gir1.2-gst-plugins-base-1.0  1.2.3-1
ii  gir1.2-gstreamer-1.0 1.2.3-1
ii  gir1.2-gtk-3.0   3.11.7-1
ii  gir1.2-notify-0.70.7.6-1
ii  gir1.2-tracker-0.16  0.16.2-1+b1
ii  gnome-settings-daemon3.10.1-1
ii  grilo-plugins-0.20.2.11-1.1
ii  libatk1.0-0  2.11.6-1
ii  libc62.18-0experimental1
ii  libcairo-gobject21.12.16-2
ii  libcairo21.12.16-2
ii  libgdk-pixbuf2.0-0   2.30.4-1
ii  libglib2.0-0 2.39.90-1
ii  libgtk-3-0   3.11.7-1
ii  libpango-1.0-0   1.36.0-1+b1
ii  libpangocairo-1.0-0  1.36.0-1+b1
ii  python3  3.4~rc1-1
ii  python3-dbus 1.2.0-2+b1
ii  python3-gi   3.10.2-2
ii  python3-gi-cairo 3.10.2-2
pn  python3:any  
ii  tracker  0.16.2-1+b1

gnome-music recommends no packages.

gnome-music 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#739573: initscripts: RUN_SIZE is being ignored

[Petter Reinholdtsen]

Control: reassign -1 systemd

[Salvo Tomaselli]
> so I think that setting is being completely ignored.
> 
> I am using systemd as init.

I believe the /run size setting is ignored by systemd.  Reassigning.

-- 
Happy hacking
Petter Reinholdtsen


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

Bug#739487: python-mysql.connector: Trying to overwrite a file that belong to mysql-utilities

[Dmitry Smirnov]

Sorry for delay... I'm a bit confused as even after dropping 
"namespace.patch" build system of mysql-utilities still install empty file 
"/usr/share/pyshared/mysql/__init__.py". Is it safe just to dismiss (drop) 
it?

Thanks.

-- 
All the best,
 Dmitry Smirnov.


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

Bug#739589: qemu: Multiple security issues

[Moritz Muehlenhoff]

Package: qemu
Severity: grave
Tags: security

Hi,
multiple security issues were reported in qemu/KVM:

CVE-2013-4148
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00395.html

CVE-2013-4149
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00396.html

CVE-2013-4150
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00397.html

CVE-2013-4151
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00425.html

CVE-2013-4526
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00398.html

CVE-2013-4527
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00399.html

CVE-2013-4529
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00400.html

CVE-2013-4530
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00401.html

CVE-2013-4531
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00402.html

CVE-2013-4532
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00403.html
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00414.html
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00404.html

CVE-2013-4533
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00407.html

CVE-2013-4534
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00406.html

CVE-2013-4535
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00408.html

CVE-2013-4536
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00408.html

CVE-2013-4537
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00409.html

CVE-2013-4538
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00410.html

CVE-2013-4539
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00411.html

CVE-2013-4540
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00412.html

CVE-2013-4541
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00413.html

CVE-2013-4542
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00416.html

CVE-2013-6399
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00405.html

Cheers,
Moritz


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

Bug#739574: initscripts: No setting for the size of /run/user

[Petter Reinholdtsen]

Control: reassign -1 systemd

[Salvo Tomaselli]
> I've noticed that /run/user is being automatically mounted.
[...]
> I am using systemd as init.

initscripts is not mounting /run/user, so I suspect systemd.
Reassigning.

-- 
Happy hacking
Petter Reinholdtsen


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

Bug#704089: tzdata config script prevents non-interactive (re)configuration

[Paul Menzel]

Control: found -1 2013i-0wheezy1
Control: tags -1 patch


Dear Sébastien and Debian folks,


Am Mittwoch, den 27.03.2013, 18:41 + schrieb Sébastien Bocahu:
> Package: tzdata
> Version: 2012j-1
> 
> The configuration script of the tzdata package, wich uses debconf, prevents
> non-interactive (re)configuration of the package.
> 
> To reproduce:
> 
> - feed debconf with new values for tzdata keys (ex. debconf-set-selections)
> - run 'dpkg-reconfigure -fnoninteractive tzdata'
> - configuration is unchanged
> 
> I propose the following change which makes non-interactive reconfiguration 
> possible:
> 
>   
>   --- /var/lib/dpkg/info/tzdata.config.orig   2013-03-27 
> 18:58:53.0 +0100
>   +++ /var/lib/dpkg/info/tzdata.config2013-03-27 18:35:53.0 +0100
>   @@ -370,8 +370,10 @@
>
># Initializes debconf default values from the ones found in
># configuration files
>   -db_set tzdata/Areas "$AREA"
>   -db_set tzdata/Zones/$AREA "$ZONE"
>   +if [ -z "$DEBCONF_RECONFIGURE" ]; then
>   +  db_set tzdata/Areas "$AREA"
>   +  db_set tzdata/Zones/$AREA "$ZONE"
>   +fi
>
>STATE=1
>while [ "$STATE" -ge 0 ]; do
>   
> 
> Note: the comment could make us believe that keys are initialized with the
> current values of the debconf database, but it is not the case. These values
> are computed from /etc/timezone.

thank you for your report and patch.

I am able to reproduce this on Debian Wheezy. It would be great if the
patch could be applied to make non-interactive installations easier.


Thanks,

Paul


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

Bug#739590: selinux-policy-default: ssh & bind9 broken by removal of hotplug script initrc labelling

[Devin Carraway]

Package: selinux-policy-default
Version: 2:2.20140206-1
Severity: important

On a jessie system with refpolicy 2:2.20140206-1, and allow-hotplug
set on the primary network interface, sshd is left running in udev_t,
breaking it thoroughly (and in fact flooding the logs with socket
errors until the machine runs out of disk).  bind9, which also has a hotplug
trigger script, is broken by inability of rndc to access auth keys.

My guess as to why:

Removal of the debian-specific refpolicy patches in rev
853ebfe7118c3984ff2b53f51af6f5758d222cd7 had the effect of returning the
contents of /etc/network/if-{up,down}.d/ from initrc_exec_t to etc_t.  As
a result, on systems with allow-hotplug on their primary network interfaces
the sshd and any other network-using daemons aware of hotplug will be started
from udev rather than init, and with an etc_t startup script the usual domain
transition doesn't happen.

I'll test out restoring the labelling and see if there's more to this.

Years ago, thus was Bug#503941 at least as it impacted bind.

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

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

Versions of packages selinux-policy-default depends on:
ii  libpam-modules   1.1.8-2
ii  libselinux1  2.2.2-1
ii  libsepol12.2-1
ii  policycoreutils  2.2.5-1
ii  python   2.7.5-5
ii  selinux-utils2.2.2-1

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  2.2-1
ii  setools  3.3.8-3

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

-- Configuration Files:
/etc/selinux/default/modules/active/file_contexts.local [Errno 13] Permission 
denied: u'/etc/selinux/default/modules/active/file_contexts.local'

-- debconf-show failed


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

Bug#739591: libclosure-compiler-java: libguava-java dependency needs to be versioned

[Paul Wise]

Source: libclosure-compiler-java
Version: 20130227+dfsg1-4
Severity: normal

I tried to run libclosure-compiler-java from jessie with libguava-java
from wheezy but I got this error. After upgrading libguava-java to the
jessie version the crash no longer happens. Please change the
libguava-java dependency to (>= 15.0), according to these links that is
the needed version right now:

https://code.google.com/p/closure-compiler/source/browse/lib/guava.jar?name=v20140110
https://github.com/michaelklishin/urly/issues/8

java.lang.NoSuchMethodError: 
com.google.common.io.ByteStreams.limit(Ljava/io/InputStream;J)Ljava/io/InputStream;
at 
com.google.javascript.jscomp.CommandLineRunner.getDefaultExterns(CommandLineRunner.java:943)
at 
com.google.javascript.jscomp.CommandLineRunner.createExterns(CommandLineRunner.java:868)
at 
com.google.javascript.jscomp.AbstractCommandLineRunner.doRun(AbstractCommandLineRunner.java:739)
at 
com.google.javascript.jscomp.AbstractCommandLineRunner.run(AbstractCommandLineRunner.java:380)
at 
com.google.javascript.jscomp.CommandLineRunner.main(CommandLineRunner.java:980)

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#739589: qemu: Multiple security issues

[Michael Tokarev]

20.02.2014 12:24, Moritz Muehlenhoff wrote:
> Package: qemu
> Severity: grave
> Tags: security
> 
> Hi,
> multiple security issues were reported in qemu/KVM:
[...]

These are all about the same thing, with references to 23 patches
from the same thread starting there:

 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00394.html

It is about state loading issues, which is about migration between
two (hopefully) qemu instances or guest save/load functionality.
The first message in the series explains conditions when this can
happen.

In particular, this conclusion:

 Considering the preconditions, I think that the impact on typical
 qemu usage is low.  Still, I think these patches make sense for
 qemu-stable.

So it has even been questioned whenever those fixes are good for
the next qemu stable release or not.

But now I'm not really sure what to do with this bugreport.  It
is a good amount of work, especially to backport those to wheezy
(since code changed significantly since that), with quite low
outcome (because the whole thing does not seem very important,
even for qemu developers - note that this patchset hasn't been
applied still, which might be due to another issue in qemu
community).

So.. oh well.  I'd really love to not backport all this shit to
wheezy... ;)

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#728124: Bad erlang version

[Rodolphe Quiédeville]

Hi,

This problem occurs when using tsung with the wrong Erlang version. Try
to purge the package and re-install it, it will rebuil th eboot file
with correct Erlang version.

Regards,

-- 
Rodolphe Quiédeville
Expert Tsung - Consulting en performance des SI
Tel : 06 13 79 63 41
http://blog.rodolphe.quiedeville.org


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

Bug#739592: roundcube-plugins: Config files world readable

[Paul Menzel]

Package: roundcube-plugins
Version: 0.9.5-1~bpo70+1
Severity: important


Dear Debian folks,


it’s not a direct issue, but people copying over the example file, get a
world readable file, which is not a good idea, if passwords for
databases are stored in them.

# ls -lh /etc/roundcube/plugins/password/config.inc.php
-rw-r--r-- 1 root root 127 Nov  3 19:28 
/etc/roundcube/plugins/password/config.inc.php
# cp -a /usr/share/roundcube/plugins/password/config.inc.php.dist 
/etc/roundcube/plugins/password/config.inc.php
# ls -lh /etc/roundcube/plugins/password/config.inc.php
-rw-r--r-- 1 root root 14K Oct 21 19:39 
/etc/roundcube/plugins/password/config.inc.php

For example the database password is stored in the variable below.

$rcmail_config['password_db_dsn']

One could argue that the user/administrator should take care of that but
a note in the empty configuration file would be helpful so that this is
not overlooked. No idea if you can think of other ways.


Thanks,

Paul


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

Bug#739575: python-pysam-tests: world writable directory tree: /var/lib/pysam/tests

[Andreas Tille]

Hi Andreas,

the directory is intended to be written by the world since the whole
world should be able to run the test suite there ... this is the purpose
of this package at all:  Let everybody run the test (including
autopkgtest) and forget about the directory afterwards.

Do I need to mark this intention to not provoke any errors?

Kind regards

  Andreas.

On Thu, Feb 20, 2014 at 01:40:18AM +0100, Andreas Beckmann wrote:
> Package: python-pysam-tests
> Version: 0.7.5-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package ships a world
> writable directory and several world writable files in there.
> 
> >From the attached log (scroll to the bottom...):
> 
>   ERROR: BAD PERMISSIONS
>   drwxrwxrwx 3 root root680 Feb 19 16:28 /var/lib/pysam/tests
>   -rw-rw-rw- 1 root root 113194 Jan  3  2012 /var/lib/pysam/tests/ex1.sam.gz
>   -rw-rw-rw- 1 root root   1787 Jan  3  2012 /var/lib/pysam/tests/ex10.sam
>   -rw-rw-rw- 1 root root840 Jan  3  2012 /var/lib/pysam/tests/ex3.sam
>   -rw-rw-rw- 1 root root460 Jan  3  2012 /var/lib/pysam/tests/ex4.sam
>   -rw-rw-rw- 1 root root277 Jan  3  2012 /var/lib/pysam/tests/ex5.sam
>   -rw-rw-rw- 1 root root332 Jan  3  2012 /var/lib/pysam/tests/ex6.sam
>   -rw-rw-rw- 1 root root311 Jan  3  2012 /var/lib/pysam/tests/ex7.sam
>   -rw-rw-rw- 1 root root516 Jan  3  2012 /var/lib/pysam/tests/ex8.sam
>   -rw-rw-rw- 1 root root  10280 Jan  3  2012 /var/lib/pysam/tests/ex9_fail.bam
>   -rw-rw-rw- 1 root root  10270 Jan  3  2012 
> /var/lib/pysam/tests/ex9_nofail.bam
>   -rw-rw-rw- 1 root root771 Feb 18 19:16 
> /var/lib/pysam/tests/example_btag.bam
>   -rw-rw-rw- 1 root root   2933 Jan 14  2013 
> /var/lib/pysam/tests/example_btag.sam
>   -rw-rw-rw- 1 root root   7554 Jan 14  2013 
> /var/lib/pysam/tests/example_empty_header.bam
>   -rw-rw-rw- 1 root root239 Nov 20  2012 
> /var/lib/pysam/tests/example_unmapped_reads_no_sq.sam
>   -rw-rw-rw- 1 root root368 Nov 20  2012 
> /var/lib/pysam/tests/example_user_header.sam
>   -rw-rw-rw- 1 root root   4344 Nov 20  2012 /var/lib/pysam/tests/issue100.bam
>   -rw-rw-rw- 1 root root383 Jan  3  2012 /var/lib/pysam/tests/tag_bug.bam
>   -rw-rw-rw- 1 root root514 Jun 26  2013 
> /var/lib/pysam/tests/test_unaligned.bam
> 
> 
> Cheers,
> 
> Andreas


> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de


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

Bug#739590: [DSE-Dev] Bug#739590: selinux-policy-default: ssh & bind9 broken by removal of hotplug script initrc labelling

[Laurent Bigonville]

Le Thu, 20 Feb 2014 00:28:43 -0800,
Devin Carraway  a écrit :

> Package: selinux-policy-default
> Version: 2:2.20140206-1
> Severity: important
> 
> On a jessie system with refpolicy 2:2.20140206-1, and allow-hotplug
> set on the primary network interface, sshd is left running in udev_t,
> breaking it thoroughly (and in fact flooding the logs with socket
> errors until the machine runs out of disk).  bind9, which also has a
> hotplug trigger script, is broken by inability of rndc to access auth
> keys.
> 
> My guess as to why:
> 
> Removal of the debian-specific refpolicy patches in rev
> 853ebfe7118c3984ff2b53f51af6f5758d222cd7 had the effect of returning
> the contents of /etc/network/if-{up,down}.d/ from initrc_exec_t to
> etc_t.  As a result, on systems with allow-hotplug on their primary
> network interfaces the sshd and any other network-using daemons aware
> of hotplug will be started from udev rather than init, and with an
> etc_t startup script the usual domain transition doesn't happen.
> 
> I'll test out restoring the labelling and see if there's more to this.
> 
> Years ago, thus was Bug#503941 at least as it impacted bind.

Could you please attach the AVC denials to the bug.

Thanks!

Laurent Bigonville


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

Bug#739589: qemu: Multiple security issues

[Moritz Muehlenhoff]

Hi Michael,

On Thu, Feb 20, 2014 at 12:55:31PM +0400, Michael Tokarev wrote:
> > Hi,
> > multiple security issues were reported in qemu/KVM:
> [...]
> 
> These are all about the same thing, with references to 23 patches
> from the same thread starting there:
> 
>  http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00394.html
> 
> It is about state loading issues, which is about migration between
> two (hopefully) qemu instances or guest save/load functionality.
> The first message in the series explains conditions when this can
> happen.

I had missed the initial mail from the thread, that explains it well
enough. I agree that the attack scenario during migration between
nodes is negligable and a non-issue.

But I don't understand what is meant by the second part:

| * Saving/Loading state to/from file.
| For example:
| https://bugzilla.redhat.com/show_bug.cgi?id=588133#c8
| https://bugzilla.redhat.com/show_bug.cgi?id=588133#c9

The RH bugs are restricted and I don't understand what is meant with
"saving/loading state to/from file". Is this about snapshots or
malformed images? Do you have an idea?

> So.. oh well.  I'd really love to not backport all this shit to
> wheezy... ;)

If "Saving/Loading state to/from file" is negligable as well, 
I would mark it as a non-issue in the tracker.

> But now I'm not really sure what to do with this bugreport.  It
> is a good amount of work, especially to backport those to wheezy
> (since code changed significantly since that), with quite low
> outcome (because the whole thing does not seem very important,
> even for qemu developers - note that this patchset hasn't been
> applied still, which might be due to another issue in qemu
> community).

Feel free to downgrade to non-RC severity until the patches
are merged in 1.8.

Cheers,
Moritz


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

Bug#739489: spamassassin: Failed to update

[Stefano Callegari]

Il Thu, Feb 20, 2014 at 12:36:38AM -0500, Noah Meyerhans scrisse:
> On Wed, Feb 19, 2014 at 10:32:15AM +0100, Stefano wrote:
> > Feb 19 09:27:30 hpdv5 spamd[29307]: logger: removing stderr method
> > Feb 19 09:27:30 hpdv5 spamd[29310]: config: no rules were found! Do you
> > need to run 'sa-update'?
> 
> That's odd, since of course there are rules included in the package.
> Have you made any modifications to the system-wide config files? Notably
> /etc/default/spamassassin or /etc/spamassassin/*

I think yes: reportbug has asked me if copy these changes. 

You find them at the bottom of my first e-mail.

> 
> You might also try running spamassassin or spamd with the '-D' option to
> see if it logs any useful additional details. Note that this will keep
> spamd in the foreground.

>From /var/log/mail.log

aptitude stops the old:
[...] 
Feb 20 09:46:21 hpdv5 spamd[7664]: spamd: child [7865] killed successfully: inte
rrupted, signal 2 (0002)
Feb 20 09:46:21 hpdv5 spamd[7664]: spamd: child [7864] killed successfully: inte
rrupted, signal 2 (0002)
Feb 20 09:46:22 hpdv5 spamd[7664]: logger: removing stderr method
Feb 20 09:46:33 hpdv5 spamd[24140]: plugin: failed to parse plugin (from @INC): 
Can't locate Mail/SpamAssassin/Plugin/AskDNS.pm in @INC (you may need to install
 the Mail::SpamAssassin::Plugin::AskDNS module) (@INC contains: lib /usr/share/p
erl5 /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/
perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl) at (eval
 89) line 1.
Feb 20 09:46:35 hpdv5 spamd[24140]: zoom: able to use 361/361 'body_0' compiled 
rules (100%)
[...]

and no more errors!

/var/cache/apt/archives <-su> # /etc/init.d/amavis status
[ ok ] amavisd is running.

gio feb 20 09:51:32 @hpdv5: 
/var/cache/apt/archives <-su> # /etc/init.d/spamassassin status
[ ok ] spamd is running.

gio feb 20 09:51:44 @hpdv5: 

Please, don't ask me why ... :)

Maybe before have I tried to update spamassassin and spamc but now only
spamassassin (spamc has been updated yesterday)?

> 
> > /var/cache/apt/archives <-su> # sa-update
> > channel: could not find working mirror, channel failed
> 
> This is a known upstream bug; see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739373

It hasn't be my intention to give a new report but only show what happen. I
see it later.

> 
> noah
> 

Many thanks.

Stefano
-- 
Stefano Callegari 


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

Bug#739575: [Debian-med-packaging] Bug#739575: python-pysam-tests: world writable directory tree: /var/lib/pysam/tests

[Charles Plessy]

Le Thu, Feb 20, 2014 at 10:08:16AM +0100, Andreas Tille a écrit :
> Hi Andreas,
> 
> the directory is intended to be written by the world since the whole
> world should be able to run the test suite there ... this is the purpose
> of this package at all:  Let everybody run the test (including
> autopkgtest) and forget about the directory afterwards.
> 
> Do I need to mark this intention to not provoke any errors?

Hi Adreases,

I think that the expectation is that the package provides a directory tree to
be copied in a temporary location; this solves the problem of write
permissions.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


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

Bug#739590: [DSE-Dev] Bug#739590: selinux-policy-default: ssh & bind9 broken by removal of hotplug script initrc labelling

[Devin Carraway]

On Thu, Feb 20, 2014 at 10:15:54AM +0100, Laurent Bigonville wrote:
> Could you please attach the AVC denials to the bug.

Sure, here you are -- this was taken in permissive mode obviously.  The
openssh-server command referred to in the first ssh-related denial is
/etc/network/if-up.d/openssh-server (there's only one other file by
that name on the system, and that's nonexecutable under /etc/ufw/).

type=AVC msg=audit(1392875609.055:17): avc:  denied  { getattr } for  pid=2746 
comm="rndc" path="/etc/bind/rndc.key" dev="sda5" ino=76857 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:dnssec_t:s0 tclass=file
type=AVC msg=audit(1392875609.055:18): avc:  denied  { read } for  pid=2746 
comm="rndc" name="rndc.key" dev="sda5" ino=76857 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:dnssec_t:s0 tclass=file
type=AVC msg=audit(1392875609.055:18): avc:  denied  { open } for  pid=2746 
comm="rndc" path="/etc/bind/rndc.key" dev="sda5" ino=76857 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:dnssec_t:s0 tclass=file
type=AVC msg=audit(1392875609.055:19): avc:  denied  { node_bind } for  
pid=2748 comm="rndc" scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:node_t:s0 tclass=tcp_socket
type=AVC msg=audit(1392875609.055:20): avc:  denied  { name_connect } for  
pid=2748 comm="rndc" dest=953 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:rndc_port_t:s0 tclass=tcp_socket
...
type=AVC msg=audit(1392875609.071:21): avc:  denied  { getattr } for  pid=2759 
comm="openssh-server" path="/run/sshd.pid" dev="tmpfs" ino=4801 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:sshd_var_run_t:s0 tclass=file
type=AVC msg=audit(1392875609.071:22): avc:  denied  { read } for  pid=2761 
comm="cat" name="sshd.pid" dev="tmpfs" ino=4801 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:sshd_var_run_t:s0 tclass=file
type=AVC msg=audit(1392875609.071:22): avc:  denied  { open } for  pid=2761 
comm="cat" path="/run/sshd.pid" dev="tmpfs" ino=4801 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:sshd_var_run_t:s0 tclass=file
type=AVC msg=audit(1392875609.087:23): avc:  denied  { getattr } for  pid=2779 
comm="ssh" path="/run/sshd" dev="tmpfs" ino=7810 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:sshd_var_run_t:s0 tclass=dir
type=AVC msg=audit(1392875609.091:24): avc:  denied  { read } for  pid=2784 
comm="sshd" name="ssh_host_rsa_key" dev="sda5" ino=60118 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:sshd_key_t:s0 tclass=file
type=AVC msg=audit(1392875609.091:24): avc:  denied  { open } for  pid=2784 
comm="sshd" path="/etc/ssh/ssh_host_rsa_key" dev="sda5" ino=60118 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:sshd_key_t:s0 tclass=file
[and so forth until one runs out of disk or patience]

-- 
Devin  \ aqua(at)devin.com, IRC:Requiem; http://www.devin.com
Carraway \ 4096R/9197B5F9: 9C64 37CD 1B7B 029D 0933  49EA 1E52 7672 9197 B5F9


signature.asc
Description: Digital signature

Bug#739590: [DSE-Dev] Bug#739590: selinux-policy-default: ssh & bind9 broken by removal of hotplug script initrc labelling

[Devin Carraway]

On Thu, Feb 20, 2014 at 12:28:43AM -0800, Devin Carraway wrote:
> I'll test out restoring the labelling and see if there's more to this.

Slightly more -- udev_t also lost the ability to transition to initrc_t, which
it will do in the old wheezy refpolicy.  Labelling /etc/network/if-*d/* with
initrc_exec_t and adding

init_domtrans_script(udev_t)

To the local policy is enough to fix the problem, both for sshd and rndc.
That was originally done in
0090-udev-policy-adjustments-allow-udev_t-to-manage-etc_r.patch but from
cursory checking appears never to have been done upstream.


Devin
-- 
Devin  \ aqua(at)devin.com, IRC:Requiem; http://www.devin.com
Carraway \ 4096R/9197B5F9: 9C64 37CD 1B7B 029D 0933  49EA 1E52 7672 9197 B5F9


signature.asc
Description: Digital signature

Bug#739591: libclosure-compiler-java: libguava-java dependency needs to be versioned

[Andrei POPESCU]

Control: reassign -1 src:closure-compiler 20130227+dfsg1-4

On Jo, 20 feb 14, 16:50:08, Paul Wise wrote:
> Source: libclosure-compiler-java
> Version: 20130227+dfsg1-4
> Severity: normal
> 
> I tried to run libclosure-compiler-java from jessie with libguava-java
> from wheezy but I got this error. After upgrading libguava-java to the
> jessie version the crash no longer happens. Please change the
> libguava-java dependency to (>= 15.0), according to these links that is
> the needed version right now:
> 
> https://code.google.com/p/closure-compiler/source/browse/lib/guava.jar?name=v20140110
> https://github.com/michaelklishin/urly/issues/8
> 
> java.lang.NoSuchMethodError: 
> com.google.common.io.ByteStreams.limit(Ljava/io/InputStream;J)Ljava/io/InputStream;
>   at 
> com.google.javascript.jscomp.CommandLineRunner.getDefaultExterns(CommandLineRunner.java:943)
>   at 
> com.google.javascript.jscomp.CommandLineRunner.createExterns(CommandLineRunner.java:868)
>   at 
> com.google.javascript.jscomp.AbstractCommandLineRunner.doRun(AbstractCommandLineRunner.java:739)
>   at 
> com.google.javascript.jscomp.AbstractCommandLineRunner.run(AbstractCommandLineRunner.java:380)
>   at 
> com.google.javascript.jscomp.CommandLineRunner.main(CommandLineRunner.java:980)
> 
> -- 
> bye,
> pabs
> 
> http://wiki.debian.org/PaulWise



-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Bug#739593: unshare -m aka unshare(CLONE_NEWNS) mounts are visible globally

[Christoph Berg]

Source: linux
Version: 3.12.9-1
Severity: important

Mounts done in a unshare(CLONE_NEWNS) or unshare -m environment are
globally visible, and are not automatically removed once the process
exits:

$ mount | grep foobar
$ sudo unshare -m -- mount -t tmpfs foobar /tmp
$ mount | grep foobar
foobar on /tmp type tmpfs (rw,relatime)

This system is running systemd 204-6.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (700, 'testing'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


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

Bug#739575: Bug#739575: python-pysam-tests: world writable directory tree: /var/lib/pysam/tests

[Andreas Tille]

Hi Charles,

On Thu, Feb 20, 2014 at 06:26:36PM +0900, Charles Plessy wrote:
> Le Thu, Feb 20, 2014 at 10:08:16AM +0100, Andreas Tille a écrit :
> > Hi Andreas,
> > 
> > the directory is intended to be written by the world since the whole
> > world should be able to run the test suite there ... this is the purpose
> > of this package at all:  Let everybody run the test (including
> > autopkgtest) and forget about the directory afterwards.
> > 
> > Do I need to mark this intention to not provoke any errors?
> 
> Hi Adreases,
> 
> I think that the expectation is that the package provides a directory tree to
> be copied in a temporary location; this solves the problem of write
> permissions.

While I agree that this would solve this formal problem I think
providing (potentially large chunks of) data which are only to run a
test and force people to create various copies of them is an insane
consequence of the requirement to not have world writable directory
tries.

Kind regards

Andreas.

-- 
http://fam-tille.de


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

Bug#739530: systemd support for monit

[Sergey Kirpichev]

Hello,

On Thu, Feb 20, 2014 at 12:06 AM, Christian Dröge  
wrote:
> Am 19.02.2014 20:50, schrieb Sergey B Kirpichev:
> >> The dh_installinit line was dropped in this patch, because it is not
> >> needed anymore
> > Explain this, please.
> update-rc.d does not support the start and stop actions anymore (see
> below in the error message).

Ok, removed.  Thank you.

Regarding other stuff in the patch, does it work for
hurd/kfreebsd?  E.g. doesn't break builds, installation and
so on.

Is this patch was tested, if so - how?


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

Bug#568303: can-utils Debian package

[Uwe Kleine-König]

Hello Alexander, hello *,

On Thu, Jan 23, 2014 at 07:39:51PM +0100, Uwe Kleine-König wrote:
> On Wed, Jan 15, 2014 at 08:02:07PM +0400, Alexander GQ Gerasiov wrote:
> > > On Wednesday 15 January 2014 12:40:52 you wrote:
> > > > I've notice some progress on the issue:
> > > > 
> > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568303
> > > > 
> > > > If Alexander won't post anything to this bug, where can I find the
> > > > package archives, he was talking about?
> > > 
> > > He was talking about collab-maint:
> > > 
> > > http://anonscm.debian.org/gitweb/?p=collab-maint/can-modules.git;a=summary
> > > http://anonscm.debian.org/gitweb/?p=collab-maint/can-utils.git;a=summary
> > > 
> > > Anyone can join collab-maint, you don't need to be Debian developer.
> > > It would be good if you two coordinate. CCing Alexander therefore.
> > 
> > I'm in heavy reformatting package from the link above. (Only can-utils,
> > cause I use vanilla kernel's modules.)
> I started creating a debian package from scratch, too, before being
> aware of this bug. My plan was to sent the ITP bug once the package is
> ready together with an RFS (as I'm only DM).
>  
> > Right now I've asked my college to make clean-room rewrite of some
> > lines in slcand.c, because it has licensing issues. (Mix of GPL and
> > GFDL licensed code.)
> This is resolved upstream in commit
> 393a91c7d8f6 (slcand: reimplement daemonize routine).
> 
> > I think I'll do an upload this week or the next one. If you have any
> > ideas or want to join packaging on alioth, you're welcome. But please
> > contact me prior any work, because current version on alioth is very
> > different from one I'm working on. (And because of many changes I don't
> > see a reason to upload broken state into git repo right now.)
> I'll rebase my packaging stuff, fixup for the latest changes and will
> let you know. Maybe we can work together then and pick the best things
> from both approaches.
I finished my packaging stuff nearly a month ago and contacted Alexander
by private mail without response so far. My efforts are available at

http://git.pengutronix.de/?p=ukl/can-utils.git debian/sid

I'd like to get forward here. @Alexander: Maybe you can provide me with
the work you did already, then I'll merge our approaches. Are you still
interested in co-maintainance of can-utils? If not, are you OK when I
take ownership of this bug and start looking for a sponsor?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |


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

Bug#711135: Further investigation

[Chris Collins]

I believe I’ve traced this one down completely now.  

I’m currently waiting for the kernel packages to finish rebuilding on my build 
box so I can verify the fix.

Inspection of my ZX2000’s SAL crash logs show that the machine went down from a 
recoverable MCA (Cache poisoning).  The Wheezy kernel does not have the MCA 
recovery paths compiled in, but rather, compiled as module.  If the system is 
throwing the MCA early enough, it has no chance of recovery because of this.

All of the functional kernel configs Peter Chubb mentioned have the MCA 
Recovery code path linked in.

I’m building a kernel package set with MCA recovery linked in and will verify 
on my zx2000.  If this fixes it, I’ll post a patch to this bug.

Regards,
Chris.

--  
Chris Collins

Bug#739594: FD_SET / FD_ISSET warning: signed and unsigned type in conditional expression [-Wsign-compare]

[Jeroen Massar]

Package: libc6-dev
Version: 2.17-96
Severity: wishlist

Enabling HARDENING_FLAGS enables -Wsign-compare, this results in:

warning: signed and unsigned type in conditional expression [-Wsign-compare]

for the FD_SET and FD_ISSET macro as the include file forces 'int'
computation on an array:

current macro:
#define __NFDBITS   (8 * (int) sizeof (__fd_mask))
#define FD_SET(fd, fdsetp)  __FD_SET (fd, fdsetp)

replace it with:
#define __NFDBITS   (8 * (unsigned int) sizeof (__fd_mask))
#define FD_SET(fd, fdsetp)  __FD_SET (((unsigned int)fd), fdsetp)

And everything is fine.

Changes to be made in:
/usr/include/x86_64-linux-gnu/sys/select.h

This might also be the case on i386 and similar platforms.

Note that filedescriptors (fd) are typically defined as 'int', hence the
cast to (unsigned int) for FD_SET to force that into alignment too.
(yep, calling FD_SET with a -1/negative FD will cause strange issues,
but you will get those anyway, and they should in theory get caught by
the stack protectors)

Greets,
 Jeroen


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

Bug#739589: qemu: Multiple security issues

[Michael Tokarev]

20.02.2014 13:09, Moritz Muehlenhoff wrote:
> Hi Michael,
> 
> On Thu, Feb 20, 2014 at 12:55:31PM +0400, Michael Tokarev wrote:
>>> Hi,
>>> multiple security issues were reported in qemu/KVM:
>> [...]
>>
>> These are all about the same thing, with references to 23 patches
>> from the same thread starting there:
>>
>>  http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00394.html
>>
>> It is about state loading issues, which is about migration between
>> two (hopefully) qemu instances or guest save/load functionality.
>> The first message in the series explains conditions when this can
>> happen.
> 
> I had missed the initial mail from the thread, that explains it well
> enough. I agree that the attack scenario during migration between
> nodes is negligable and a non-issue.

It isn't exactly a non-issue really, or else it'd not be necessary to
assign (multiple) CVE IDs.  Even with migration scenario there are
possibilities to exploit these by using one of these vulnerabilities
together with some other vulnerability (and this is mentioned in
the first email in that thread).  Impact is quite low still.

> But I don't understand what is meant by the second part:
> 
> | * Saving/Loading state to/from file.
> | For example:
> | https://bugzilla.redhat.com/show_bug.cgi?id=588133#c8
> | https://bugzilla.redhat.com/show_bug.cgi?id=588133#c9
> 
> The RH bugs are restricted and I don't understand what is meant with
> "saving/loading state to/from file". Is this about snapshots or
> malformed images? Do you have an idea?

It is like snapshots, yes.  One can save a guest memory image into
a file and load it later.  It is pretty much like migration (and
implemented using the same mechanism), but with a delay between
saving and loading.

One of the bugs mentioned above is about giving developer such a
saved file from local qemu asking for help in diagnosing an apparent
bug, and that image will try to exploit developer's qemu by using
one of these flaws.  Something like that anyway -- see
http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00612.html

Another possible scenario is someone distributing virtual machines
for end-users, trying to exploit their qemu.

Unlike for, say, gif images or word documents or whatever, qemu
guest image _may_ come in one of 2 forms: it is just the drive
image (content of virtual hard drive), which you run and it boots
from the beginning as your regular PC will do.  Or this drive
image coupled with memory image, so when you run it, your system
is in some non-initial runtime state.  It is definitely unusual
to distribute something in the second form, together with the
memory state.

So I can imagine someone selling pre-loaded virtual machines
(doing it this way, together with memory state, is rare but can
have its reasons too, say, for a system which require significant
boot time).  Or, for example, your qemu/kvm hosting provider can
have a function to transfer whole your virtual machine (together
with the memory state) to you - either in terms of files like
that, or using online migration.

When you perform save/load locally in your usual environment where
you run qemu, you don't let stranger to modify the memory state
files created by qemu.  So locally this is not exploitable (unless
you use already hacked/modified qemu to create the images in the
first place, but that's obviously not very interesting case).

>> So.. oh well.  I'd really love to not backport all this shit to
>> wheezy... ;)
> 
> If "Saving/Loading state to/from file" is negligable as well, 
> I would mark it as a non-issue in the tracker.

Both ways to "use" one of these vulns are real, but both are quite
difficult to use, hence the probably-low-impact.

Basically we've two possible ways to use these vulns.

First is to "spread" a break-in to other machines by, after breaking
into one machine (using some other way) and hacking qemu on it, it
becomes possible to break into qemu on the receiving-migration machine.

And second is when someone gives whole guest image (together with the
memory state) to you, tricking you to run it one way or another.

That's what issues are all about.  Not very serious, but not a non-issue
either.

>> But now I'm not really sure what to do with this bugreport.  It
>> is a good amount of work, especially to backport those to wheezy
>> (since code changed significantly since that), with quite low
>> outcome (because the whole thing does not seem very important,
>> even for qemu developers - note that this patchset hasn't been
>> applied still, which might be due to another issue in qemu
>> community).
> 
> Feel free to downgrade to non-RC severity until the patches
> are merged in 1.8.

Note that, while many people has been involved in code audit and
patching, the series received quite good criticism from Peter
Maydell who offerent alternative ways to fix some of the issues
or questioned validity of the proposed fixes, with not much
discussion following.

I'll ping this thread again - i

Bug#723132: please prioritise...

[Dmitry Smirnov]

On Wed, 19 Feb 2014 21:35:49 Tomasz Rybak wrote:
> I'll update package during the weekend, and fix #739173 and #739176.
> As package will need to go through NEW queue, will you sponsor it?

Of course, just let me know when you're ready and allow me several days to 
reply if I'm busy...

-- 
Best wishes,
 Dmitry Smirnov.


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

Bug#738407: ulogd2: FTBFS: dh_install: ulogd2-dbi missing files (debian/tmp/usr/lib/*/ulogd/ulogd_output_DBI.so), aborting

[Chris Boot]

On 11/02/14 08:24, Hideki Yamane wrote:
> Hi,
> 
>  Specifying dbi.so directory fixes this FTBFS bug, see attached diff.
>  I'll upload it to 7-delayed queue, if you don't want it, please tell me.
>  
>  # git repo doesn't have "master" branch, so I'm not sure how to commit it.

Hi Hideki,

Thanks for picking up this bug and preparing an NMU, I really appreciate
it. I've recently had to revoke my GPG key, so I can't easily upload my
own updates until I get a new key sorted out - and this is taking time.

I've been waiting for your NMU to enter the archive but I haven't seen
it yet. Did you upload it to 7-delayed as you suggested? If there was an
issue with your upload, please feel free to re-upload without going
through delayed - your patch has my blessing.

I really should add a README.source that explains how I've been keeping
my packaging repo. In your case, please commit to the 'debian' branch if
you do an upload (and you feel like committing to git). I've been
keeping debian-next as a collection of commits pending the next upload,
please feel free to ignore this for now.

Thanks again,
Chris

-- 
Chris Boot
deb...@bootc.net
GPG: 8467 53CB 1921 3142 C56D  C918 F5C8 3C05 D9CE 


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

Bug#733112: [Pkg-systemd-maintainers] Bug#733112: Bug#733112: libsystemd-login0: logind not found by gdm3

[intrigeri]

Kjö Hansi Glaz wrote (19 Feb 2014 23:36:31 GMT) :
> I don't have access to the buggy system anymore. On a new jessie install
> the problem doesn't show up. This problem might still be an issue for
> wheezy to jessie migration.

Are you using hidepid on the new Jessie system?

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


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

Bug#739595: mcelog 100-1 does not recognize AMD CPUs properly

[sacrificial-spam-address]

Package: mcelog
Version: 100-1
Architecture: i386
Severity: important

I think this is what caused #738927 to be noticed, but this is a separate issue.

# strace -efile,read,ioctl,exit_group mcelog 
execve("/usr/sbin/mcelog", ["mcelog"], [/* 15 vars */]) = 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\213^B4\0\0\0"..., 
512) = 512
open("/etc/mcelog/mcelog.conf", O_RDONLY) = 3
read(3, "#\n# Example config file for mcel"..., 4096) = 4096
read(3, "the hardware does not report DIM"..., 4096) = 1966
read(3, "", 4096)   = 0
open("/proc/cpuinfo", O_RDONLY) = 3
read(3, "processor\t: 0\nvendor_id\t: Authen"..., 1024) = 1024
mcelog: AMD Processor family 16: Please load edac_mce_amd module.
: Success
CPU is unsupported
exit_group(1)   = ?

The error message appears to be bogus for three separate reasons:
1) The module is named amd64_edac_mod.ko
2) I have CONFIG_EDAC_AMD64=y, so don't need the module
3) It prints the error before doing anything that could theoretically
   detect the presence of such a module in the kernel, so loading
   the module wouldn't helo.

For comparison, specifying the CPU results in normal operation:
# strace -efile,read,ioctl,exit_group mcelog --cpu k8
execve("/usr/sbin/mcelog", ["mcelog", "--cpu", "k8"], [/* 15 vars */]) = 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\213^B4\0\0\0"..., 
512) = 512
open("/etc/mcelog/mcelog.conf", O_RDONLY) = 3
read(3, "#\n# Example config file for mcel"..., 4096) = 4096
read(3, "the hardware does not report DIM"..., 4096) = 1966
read(3, "", 4096)   = 0
open("/dev/mem", O_RDONLY)  = 3
open("/sys/firmware/efi/systab", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/proc/efi/systab", O_RDONLY)  = -1 ENOENT (No such file or directory)
access("/etc/mcelog", R_OK|X_OK)= 0
access("/etc/mcelog/cache-error-trigger", R_OK|X_OK) = 0
open("/dev/mcelog", O_RDONLY)   = 3
ioctl(3, MCE_GET_RECORD_LEN or MTRRIOC_SET_ENTRY, 0xfff90ca8) = 0
ioctl(3, MCE_GET_LOG_LEN or MTRRIOC_DEL_ENTRY, 0xfff90ca4) = 0
read(3, "", 2816)   = 0
exit_group(0)   = ?

FWIW, here's 1/4 of my /proc/cpuinfo:

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 2
model name  : AMD Phenom(tm) 9850 Quad-Core Processor
stepping: 3
microcode   : 0x183
cpu MHz : 2500.164
cache size  : 512 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni 
monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs hw_pstate npt lbrv svm_lock
bogomips: 5002.67
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate


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

Bug#707075: otrs2: fails to upgrade from testing due to storage engine change

[Patrick Matthäi]

Am 18.02.2014 01:33, schrieb Andreas Beckmann:

This is a wanted behaviour, from the 3.2.1+dfsg1-1 changelog:
* Drop patch 24-default-myisam and check with the new otrs.CheckDB.pl
script,
if the available tables and the used storage engine are equal. If it is not
the case the installation should abort, so that the administrator can fix
his MySQL server or the already created tables.
Closes: #690306


If it's too difficult to sort this out automatically, the package needs
to carry documentation how to solve this manually. (My first try was
README.Debian.) And ideally the error message should point to this
documentation.


Automagic is not possible. I have added the following to README.Debian:

Upgrading to MySQL >= 5.5:
--

Since MySQL 5.5 changed its default storage engine from MyISAM to InnoDB you
might encounter problems on upgrading OTRS from the otrs.CheckDB.pl script.

Here you will find additional notes about this problem:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707075

Here you will find a possible solution:

http://blog.otrs.org/2013/02/20/about-otrs-mysql-myisam-and-innodb-storage-engines/




And I wouldn't mind a receipe how I can fix this up easily in piuparts
in a scriptable way (either changing mysql config or doing some sql or
whatever).


For piuparts it might be a better idea to test it with Postgres as 
database backend, or while you upgrade your MySQL server adding 
default-storage-engine=MYISAM to the my.cnf, but this is ugly.



--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


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

Bug#739596: tlsdate: Will be broken once the SSL handshake does not include timestamps anymore?

[intrigeri]

Package: tlsdate
Version: 0.0.5-2
Severity: normal

Hi,

my understanding is that tlsdate will be broken once Nick's proposal
is accepted, and SSL handshakes don't include timestamps anymore.

Is this correct?
If it is, is including tlsdate in a stable Debian release a good idea?

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


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

Bug#734648: cyrus-nntpd-2.4: nntp not working after upgrade to wheezy

[Ondřej Surý]

Control: tags -1 +pending

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

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


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

Bug#739597: docx2txt: missing dependency on unzip

[Harald Geyer]

Package: docx2txt
Version: 1.2-1
Severity: serious
Justification: Policy 3.5

After trying to view a docx file I got the following error message:
Failed to locate unzip command '/usr/bin/unzip'!



-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 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#739598: pystache tests fail with python3.4

[Matthias Klose]

Package: pystache
Version: 0.5.3-2
Severity: important
Tags: sid jessie
User: debian-pyt...@lists.debian.org
Usertags: python3.4

python3.4 as the default python3 can be found in experimental.

   debian/rules override_dh_auto_test
make[1]: Entering directory `/build/buildd/pystache-0.5.3'
nosetests -d build2 && \
nosetests3 -d build3

--
Ran 0 tests in 0.000s

OK
..F..
==
FAIL: Test that the decode_errors attribute is respected.
--
Traceback (most recent call last):
  File
"/build/buildd/pystache-0.5.3/build3/lib/pystache/tests/test_renderer.py", line
222, in test_unicode__decode_errors
self.assertEqual(renderer.str(b), 'd\\ufffd\\ufffdf')
nose.proxy.AssertionError: 'd\ufffd\ufffdf' != 'd\\ufffd\\ufffdf'
- d\ufffd\ufffdf
+ d\ufffd\ufffdf

"""Fail immediately, with the given message."""
>>  raise self.failureException("'d\ufffd\ufffdf' != 'dufffdufffdf'\n-
d\ufffd\ufffdf\n+ d\\ufffd\\ufffdf\n")


--
Ran 253 tests in 0.336s

FAILED (failures=1)


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

Bug#739575: python-pysam-tests: world writable directory tree: /var/lib/pysam/tests

[Andreas Beckmann]

On 2014-02-20 10:08, Andreas Tille wrote:
> Hi Andreas,
> 
> the directory is intended to be written by the world since the whole
> world should be able to run the test suite there ... this is the purpose
> of this package at all:  Let everybody run the test (including
> autopkgtest) and forget about the directory afterwards.

This works for $everybody. But $everybody+1 finds only the leftovers
from his predecessor there (or nothing if he cleaned up "properly").

> Do I need to mark this intention to not provoke any errors?

If you convince me, I can add exceptions. But I need to dig into this
further.

Users are allowed to modify/delete the python scripts in that directory?
What is the expected bahavior on package updates and modified .sam files
there?


Andreas


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

Bug#731491: transition: oce

[Julien Cristau]

On Wed, Feb 19, 2014 at 11:51:37 +0100, D. Barbier wrote:

> Uploaded, thanks.
> 
Scheduled binNMUs for freecad and netgen.  I'll give gmsh 2.8.4 a couple
days to see if it gets in to testing first.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#733576: phpldapadmin: another function problem

[Emmanuel]

Package: phpldapadmin
Version: 1.2.2-5
Followup-For: Bug #733576

I ran into another already declared function
Fatal error: Cannot redeclare error() in 
/usr/share/phpldapadmin/lib/functions.php on line 641


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

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages phpldapadmin depends on:
ii  apache2  2.2.22-13.2
ii  apache2-mpm-prefork [httpd]  2.2.22-13.2
ii  apache2-mpm-worker [httpd]   2.2.22-13.2
ii  debconf [debconf-2.0]1.5.49
ii  libapache2-mod-php5  5.4.4-14+deb7u7
ii  php5-cli 5.4.4-14+deb7u7
ii  php5-ldap5.4.4-14+deb7u7
ii  ucf  3.0025+nmu3

phpldapadmin recommends no packages.

phpldapadmin suggests no packages.

-- debconf information excluded


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

Bug#739568: lightspeed: FTBFS with clang instead of gcc

[Boris Pek]

Hi Arthur,

> Using the rebuild infrastructure, your package fails to build with clang
> (instead of gcc).

Your fix changes program logic at first glance.

Have you tried to launch program built with fix patch and play the game?

Best regards,
Boris


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

Bug#736421: gnome-screenshot: Wrong Italian translation of the file name

[althaser]

Hey,

yeah I noticed, but it is easier to fix from upstream.

Please send an e-mail to Milo Casagrande -> m...@ubuntu.com asking that.

thanks
regards
althaser

Bug#739599: ITP: golang-goptlib -- library for Tor pluggable transports written in Go

[Ximin Luo]

Package: wnpp
Severity: wishlist
Owner: Ximin Luo 

* Package name: golang-goptlib
  Version : 0~git20140130
  Upstream Author : David Fifield 
* URL : 
https://gitweb.torproject.org/pluggable-transports/goptlib.git
* License : CC0
  Programming Lang: Go
  Description : library for Tor pluggable transports written in Go

goptlib is a little Go library which understands the Tor pluggable transport 
managed-proxy protocol. It is useful for developers writing Tor pluggable 
transports in Go.


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

Bug#739600: ITP: kprinter4 -- External KDE4 printing utility

[Michael Banck]

Package: wnpp
Severity: wishlist
Owner: Michael Banck 

* Package name: kprinter4
  Version : 9
  Upstream Author : Marco Nelles 
* URL : 
http://kde-apps.org/content/show.php/KPrinter4?content=163537
* License : GPL
  Programming Lang: C++
  Description : External KDE4 printing utility

Kprinter4 is a simple stand-alone document printer modelled after the
KDE4 print dialog. It can be used in place of /bin/lpr in order to
better control the print setup of legacy applications.
.
It is modelled after the KDE3-based kprinter application.


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

Bug#739601: Some programms complain about missing /usr/lib/sasl2 after update

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: libsasl2-modules
Version: 2.1.26.dfsg1-8
Severity: critical

I set the severity to critical as unrelated software is affekted.

After updating libsasl2-modules, I have the following log messages in
log:

   mutt: looking for plugins in '/usr/lib/sasl2', failed to open directory, 
error: Datei oder Verzeichnis nicht gefunden

I have no idea why this directory was removed but other software seems
to need it.

- -- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (600, 'oldstable'), (110, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.2 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) (ignored: LC_ALL set to 
de_DE)
Shell: /bin/sh linked to /bin/dash

Versions of packages libsasl2-modules depends on:
ii  libc62.17-97
ii  libssl1.0.0  1.0.1f-1

libsasl2-modules recommends no packages.

Versions of packages libsasl2-modules suggests:
pn  libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi-heimdal  
pn  libsasl2-modules-ldap  
pn  libsasl2-modules-otp   
pn  libsasl2-modules-sql   

- -- no debconf information

- -- 
Klaus Ethgen  http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQGcBAEBCgAGBQJTBeVeAAoJEKZ8CrGAGfasKJEMAJfU+sqfMOm4kuabG8jAiR3A
m2FEN5gu7dMRhVcJlMUlbPj18EfXjndvW7rl8OGHvt/7F+WEDx7slNu4iXp9V4zI
GgkC42rTQGNiaNihVUeuNWxQHxrNOL7Qr2Fc8Q0kdjBUCyyw4DFlvj4o61pitzl6
IK17ms9pjwMf/xwPu1aLA2HGqPBauSLch/hwTT6Z9Y+P2YzlCboU+JK+0kSi7aoD
nHlA9UQtEjG4+/Eq9v9FrvPBbtBsMehA4XpY0ZJvrqNopVP/hcTcKSkBUvjzWITW
ruuTjWVEkUxPJroLrFvsnYARQe4Apxp95+PQIglozOxXKe635odQQacBNOBIitva
HxOMEmc98owBEJsofglXtUfKC/+Yr/hlB5mQZR7hoEZ5jiPCfS04GucgIlPHV20p
nqjcxJU9+unT7TmRTmVLhJyFeXh2WPXLG4rJwYldLehZfs0eOEO78k70bzggV0Fn
xHHYYVZ0CTj1ybx01SgUHSRUhtSnVySoG0iIh6MOhg==
=BFSZ
-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#699809: cfengine3 packaging project on github

[Antonio Radici]

On Tue, Feb 18, 2014 at 04:08:15PM +0100, Thomas Koch wrote:
> Hi,
> 
> this is a reply to the debian bug report asking for a newer cfengine version, 
> CCing the members of the debian packaging team on github.
> 
> It seems there are people working on packaging a current cfengine version at 
> github:
> https://github.com/Webhuis/Cfengine-debian/wiki
> 
> I don't know, whether there have been trials to contact the current (MIA?) 
> maintainer of cfengine3, Antonio Radici. I'll send a MIA request to debian-
> devel right after this mail
> 
> @DebianPackagingTeam: Do you need any help? I'm not a DD, so I can't sponsor 
> your packages, but I might have some experience in packaging. Do you have an 
> estimation of when there might be an upload of cfengine 3.[56] to Debian?

Thomas, I have already had several meeting on hangouts with the members of the
cfengine3 packaging team on git and we agreed on what is the path forward: i.e.:
they will solve the current issues that we discussed already and then we will
start releasing that version, after a couple of releases we will transfer the
ownership of the debian package to a cfengine3 packaging team, so that the
burden will not lie on a single person.

If you have any questions let me know.


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

Bug#739602: octave-io: POI interface for XLS/XLSX files not working

[Sébastien Villemot]

Package: octave-io
Version: 1.2.5-1
Severity: normal

The POI interface for loading XLS/XLSX files does not work as expected. It
loads the file but no data is actually returned back.

As a workaround, the patch low-priority-for-POI.patch ensures that POI is not
used by default for XLS/XSLX files.

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://www.dynare.org/sebastien
  `-  GPG Key: 4096R/381A7594


signature.asc
Description: Digital signature

Bug#739603: RM: octave-java -- ROM; obsolete, supersed by similar functionality in octave 3.8

[Sébastien Villemot]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: pkg-octave-de...@lists.alioth.debian.org
Control: block 735557 by -1

Dear ftpmasters,

Since version 3.8, octave now incorporates the functionality formerly provided
by octave-java. As a consequence, please remove the latter from unstable.

Cheers,

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://www.dynare.org/sebastien
  `-  GPG Key: 4096R/381A7594


signature.asc
Description: Digital signature

Bug#739606: eclipse-subclipse: Upgrade to 1.10 for Subversion 1.8 (sid)

[Christian Holm Christensen]

Source: eclipse-subclipse
Version: 1.8.16-3
Severity: important

Dear Maintainer,

Current subversion in 'sid' is 1.8.  Subclipse (1.8) complains it needs
subversion 1.7 and fails to load.

According to
http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA
one need Subclipse 1.10 for this version of Subversion.

I can confirm that installing Subclipse 1.10 via update site makes it
work
again on 'sid'.

Please package 1.10 of subclipse.  Thank you and keep up the good work.



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

Kernel: Linux 3.12-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 
 ___  |  Christian Holm Christensen 
  |_| |  -
| |  Address: Sankt Hansgade 23, 1. th.  Phone:  (+45) 35 35 96 91
 _|   DK-2200 Copenhagen N   Cell:   (+45) 24 61 85 91
_|DenmarkOffice: (+45) 353  25 404
 |   Email:   ch...@nbi.dk   Web:www.nbi.dk/~cholm
 | |


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

Bug#739521: Please lower php-tcpdf to to Suggests or Recommends

[Thijs Kinkhorst]

On Wed, February 19, 2014 20:03, Michal Čihař wrote:
> As phpMyAdmin code does not check for it's presence (there is no
> need for that as it's distributed in upstream tarball), I don't think it
> good idea to do this.

It would be nice if phpMyAdmin could add such a check, it seems to me not
very expensive and it would help distributors such as us a lot.


Cheers,
Thijs


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

Bug#739605: pm-utils: sudo pm-hibernate does hibernate but when trying to wake it reboots

[Mariano Ignacio Baragiola]

Package: pm-utils
Version: 1.4.1-13
Severity: grave
Justification: causes non-serious data loss

When trying to pm-hibernate being root, there's no problem. But when you sudo
it, it hibernates; but then when trying to wake it crashes and reboots.



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

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

Versions of packages pm-utils depends on:
ii  powermgmt-base  1.31

Versions of packages pm-utils recommends:
ii  ethtool  1:3.13-1
ii  hdparm   9.43-1.1
ii  kbd  1.15.5-1
ii  procps   1:3.3.9-2
ii  vbetool  1.1-3

Versions of packages pm-utils suggests:
pn  cpufrequtils
pn  radeontool  
ii  wireless-tools  30~pre9-8

-- 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#739604: sysvinit: The new skeleton does not work on kFreeBSD

[Gergely Nagy]

Source: sysvinit
Version: 2.88dsf-50
Severity: serious

The change introduced in sysvinit 2.88dsf-50, which turns
/etc/init.d/skeleton into a script that has /lib/init/init-d-script as
interpreter fails on kFreeBSD, because on that platform, interpreters
cannot be other scripts.

To demonstrate:

,[ test.sh ]
| #!/lib/init/init-d-script
| DAEMON=/bin/uname
`

On linux, running ./test.sh prints the usage. On kFreeBSD (as tested
locally and on falla.d.o), it prints nothing, because the #! line will
be ignored, it being a script and all.

If you want to do this kind of thing, you will either need a binary
wrapper at least on kFreeBSD, or you'll need to use sourcing.

-- 
|8]


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

Bug#739557: [patch] Get libtirpc building on Hurd

[Petter Reinholdtsen]

Control: forwarded -1
Control: tag -1 upstream

Hi.  The attached patch fixes build problems on Hurd.  Please apply in
a future version.

I've just uploaded a new version to Debian with this patch applied.
The complete set of Debian patches can be found using
http://packages.qa.debian.org/libt/libtirpc.html >.

-- 
Happy hacking
Petter Reinholdtsen
Description: Get source building on Hurd
 - Look for  before using it.
 - Define MAXHOSTNAMELEN to 64 if missing.
 - Bind sockets on Hurd like on Linux.
Author: Petter Reinholdtsen 

--- libtirpc-0.2.2.orig/configure.ac
+++ libtirpc-0.2.2/configure.ac
@@ -21,7 +21,7 @@ AM_CONFIG_HEADER(config.h)
 AC_PROG_LIBTOOL
 AC_HEADER_DIRENT
 AC_PREFIX_DEFAULT(/usr)
-AC_CHECK_HEADERS([arpa/inet.h fcntl.h libintl.h limits.h locale.h netdb.h 
netinet/in.h stddef.h stdint.h stdlib.h string.h sys/ioctl.h sys/param.h 
sys/socket.h sys/time.h syslog.h unistd.h])
+AC_CHECK_HEADERS([arpa/inet.h fcntl.h libintl.h limits.h locale.h netdb.h 
netinet/in.h stddef.h stdint.h stdlib.h string.h sys/ioctl.h sys/param.h 
sys/socket.h sys/time.h syslog.h unistd.h sys/user.h])
 AC_CHECK_LIB([pthread], [pthread_create])
 
 
--- libtirpc-0.2.2.orig/src/auth_unix.c
+++ libtirpc-0.2.2/src/auth_unix.c
@@ -57,6 +57,11 @@
 #include 
 #include 
 
+/* Workaround for Hurd */
+#ifndef MAXHOSTNAMELEN
+#  define MAXHOSTNAMELEN   64
+#endif
+
 /* auth_unix.c */
 static void authunix_nextverf (AUTH *);
 static bool_t authunix_marshal (AUTH *, XDR *);
--- libtirpc-0.2.2.orig/src/bindresvport.c
+++ libtirpc-0.2.2/src/bindresvport.c
@@ -58,7 +58,7 @@ bindresvport(sd, sin)
 return bindresvport_sa(sd, (struct sockaddr *)sin);
 }
 
-#ifdef __linux__
+#if defined(__linux__) || defined(__GNU__)
 
 #define STARTPORT 600
 #define LOWPORT 512
--- libtirpc-0.2.2.orig/src/getpeereid.c
+++ libtirpc-0.2.2/src/getpeereid.c
@@ -29,7 +29,9 @@
 #include 
 #include 
 #include 
-#include 
+#ifdef HAVE_SYS_USER_H
+#  include 
+#endif /* HAVE_SYS_USER_H */
 
 #include 
 #include 
@@ -37,6 +39,9 @@
 int
 getpeereid(int s, uid_t *euid, gid_t *egid)
 {
+#ifndef HAVE_SYS_USER_H
+return(-1);
+#else
 #ifdef XUCRED_VERSION
struct xucred uc;
 #define uid  cr_uid
@@ -60,4 +65,5 @@ getpeereid(int s, uid_t *euid, gid_t *eg
*euid = uc.uid;
*egid = uc.gid;
return (0);
+#endif /* HAVE_SYS_USER_H */
  }

Bug#739009: gcc-arm-none-eabi: armv6 miscompilation

[Agustin Henze]

On 02/14/2014 06:41 PM, Andre Heider wrote:
> Hi,
> 
> I ran into this while cross compiling a kernel for the raspberry pi with this
> toolchain.

I'm very glad to know other people are testing the toolchain :)

> I reported weird kernel crashes upstream [0] and found out this is a due to a
> gcc v4.8 regression [1].
> It's fixed upstream on the v4.8 branch [2], but as of this writing still
> unreleased.
> 
> The official debian gcc-4.8 package comes with this fix (hidden in the huge
> svn-updates.diff patch it comes with).
> Additionally it has all the recent linaro patches on top (where this package
> only has a couple for m0/m3).
> 
> There're tons of other fixes and improvements in those patches, and they're
> already shipping as debian's native compilers on arm platforms.
> For this issue the mentioned upstream fix would suffice, but why is this neat
> bare metal cross compiler not build from that source package?

Currently this package is built from that source however you're right. I wasn't
applying the debian patches. I really appreciate your bug report, I'm uploading
a new version in a few minutes meanwhile you can take a look here[*].

Many thanks

[*] git://anonscm.debian.org/collab-maint/gcc-arm-none-eabi.git

-- 
TiN



signature.asc
Description: OpenPGP digital signature

Bug#739575: [Debian-med-packaging] Bug#739575: Bug#739575: python-pysam-tests: world writable directory tree: /var/lib/pysam/tests

[Charles Plessy]

Le Thu, Feb 20, 2014 at 10:36:57AM +0100, Andreas Tille a écrit :
> 
> While I agree that this would solve this formal problem I think
> providing (potentially large chunks of) data which are only to run a
> test and force people to create various copies of them is an insane
> consequence of the requirement to not have world writable directory
> tries.

Hi again,

while I do not have a better solution to propose, I would be surprised if
nobody had a deeper thought on the question before us.  Search engines did not
give me answers, but maybe you can ask for advice on -mentors or -devel ?

Cheers,

-- 
Charles


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

Bug#739604: sysvinit: The new skeleton does not work on kFreeBSD

[Petter Reinholdtsen]

[Gergely Nagy]
> The change introduced in sysvinit 2.88dsf-50, which turns
> /etc/init.d/skeleton into a script that has /lib/init/init-d-script
> as interpreter fails on kFreeBSD, because on that platform,
> interpreters cannot be other scripts.

Oh.  I tested on Linux and Hurd, and did not imagine that kFreeBSD was
that different from these two. :)

> If you want to do this kind of thing, you will either need a binary
> wrapper at least on kFreeBSD, or you'll need to use sourcing.

Right.  Back to the drawing board. :)

Can you test this construct instead of #!/lib/init/init-d-script:

  #!/bin/sh
  if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
set $0 $@; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
  fi
-- 
Happy hacking
Petter Reinholdtsen


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

Bug#739607: don't link the extension with the python library

[Matthias Klose]

Package: py3cairo
Version: 1.10.0+dfsg-3
Tags: patch

Please don't link the extension with the python library

patch at
http://launchpadlibrarian.net/166876566/py3cairo_1.10.0%2Bdfsg-3build2_1.10.0%2Bdfsg-3ubuntu1.diff.gz


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

Bug#739608: ldirectord: fails to test HTTPS real servers

[Salvatore Bonaccorso]

Package: ldirectord
Version: 1:3.9.2-5+deb7u1
Severity: important
Tags: upstream patch fixed-upstream
Control: found -1 1:3.9.3+git20121009-3

Hi,

In Wheezy hostname verification is enabled by default in
LWP::UserAgent, and so under Wheezy ldirectord fails to test HTTPS
real servers. The fixing commit disables the check again so that
service checking by IP only will still succeed.

   "verify_hostname" => $bool
   When TRUE LWP will for secure protocol schemes ensure it
   connects to servers that have a valid certificate
   matching the expected hostname. If FALSE no checks are
   made and you can't be sure that you communicate with the
   expected peer. The no checks behaviour was the default
   for libwww-perl-5.837 and earlier releases.

   This option is initialized from the
   PERL_LWP_SSL_VERIFY_HOSTNAME environment variable. If
   this environment variable isn't set; then
   "verify_hostname" defaults to 1.

This is reported both [1,2] with fixing commit is at [3]. I'm not sure
if this should be also RC, as this is a regression in ldirectord's
functionality when migrating from Squeeze to Wheezy.

 [1] https://github.com/ClusterLabs/resource-agents/pull/333
 [2] https://github.com/ClusterLabs/resource-agents/issues/361
 [3] 
https://github.com/mcnewton/resource-agents/commit/68fad38326b7c04efd6434e736e32fe395eafe02

In any case I could prepare both packages targetting unstable and
wheezy as we need ldirectord.

Regards,
Salvatore


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

Bug#739601: Some programms complain about missing /usr/lib/sasl2 after update

[Roberto C . Sánchez]

severity 739601 normal
retitle 739601 mutt: Fails ungracefully when /usr/lib/sasl2 is not present
reassign 739601 mutt
thanks

The directory /usr/lib/sasl2 was shipped for along time as an empty
directory in the libsasl2-2 directory.  This was removed for two
reasons:

 - It was empty, and therefore not useful
 - With multi-arch, all the libsasl2-modules-* binary packages are
   shipping their files in /usr/lib//sasl2

It appears that this is causing mutt to fail ungracefully.  The
existence of the directory should be tested for.

Regards,

-Roberto

On Thu, Feb 20, 2014 at 12:22:08PM +0100, Klaus Ethgen wrote:
> Package: libsasl2-modules
> Version: 2.1.26.dfsg1-8
> Severity: critical
> 
> I set the severity to critical as unrelated software is affekted.
> 
> After updating libsasl2-modules, I have the following log messages in
> log:
> 
>mutt: looking for plugins in '/usr/lib/sasl2', failed to open directory, 
> error: Datei oder Verzeichnis nicht gefunden
> 
> I have no idea why this directory was removed but other software seems
> to need it.
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable
>   APT policy: (800, 'unstable'), (600, 'oldstable'), (110, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.13.2 (SMP w/8 CPU cores; PREEMPT)
> Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) (ignored: LC_ALL set 
> to de_DE)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages libsasl2-modules depends on:
> ii  libc62.17-97
> ii  libssl1.0.0  1.0.1f-1
> 
> libsasl2-modules recommends no packages.
> 
> Versions of packages libsasl2-modules suggests:
> pn  libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi-heimdal  
> pn  libsasl2-modules-ldap  
> pn  libsasl2-modules-otp   
> pn  libsasl2-modules-sql   
> 
> -- no debconf information
> 
> -- 
> Klaus Ethgen  http://www.ethgen.ch/
> pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen 
> Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
> 
> ___
> Pkg-cyrus-sasl2-debian-devel mailing list
> pkg-cyrus-sasl2-debian-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-sasl2-debian-devel

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Bug#739609: ITP: ooniprobe -- probe for the Open Observatory of Network Interference (OONI)

[Jérémy Bobbio]

Package: wnpp
Severity: wishlist
Owner: Jérémy Bobbio 

* Package name: ooniprobe
  Version : 1.0.0-rc7
  Upstream Author : Open Observatory of Network Interference 

* URL : https://ooni.torproject.org/
* License : BSD-2-clause
  Programming Lang: Python
  Description : probe for the Open Observatory of Network Interference 
(OONI)

OONI, the Open Observatory of Network Interference, is a global
observation network which aims is to collect high quality data using
open methodologies and free software to share observations and data
about the various types, methods, and amounts of network tampering in
the world.

ooniprobe is a program to probe a network and collect data for the OONI
project. It will test the current network for signs of surveillance and
censorship.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#722348: same problem

[Philipp Marek]

Feb 20 10:36:57 cacao kernel: [ 5299.252749] traps: ld-linux-x32.so[25723] 
general protection ip:f7744eed sp:ff7fcec8 error:0 in ld-2.17.so[f772e000+21000]
Feb 20 10:36:57 cacao kernel: [ 5299.296045] traps: ld-linux-x32.so[25737] 
general protection ip:f7703eed sp:ffc83fd8 error:0 in ld-2.17.so[f76ed000+21000]
Feb 20 10:36:57 cacao kernel: [ 5299.374231] traps: ld-linux-x32.so[25751] 
general protection ip:f7790eed sp:ffa9abe8 error:0 in ld-2.17.so[f777a000+21000]
Feb 20 10:36:57 cacao kernel: [ 5299.393666] traps: ld-linux-x32.so[25765] 
general protection ip:f770feed sp:ffb3fea8 error:0 in ld-2.17.so[f76f9000+21000]
Feb 20 10:36:57 cacao kernel: [ 5299.416296] traps: ld-linux-x32.so[25779] 
general protection ip:f7782eed sp:ffec50c8 error:0 in ld-2.17.so[f776c000+21000]
Feb 20 10:36:57 cacao kernel: [ 5299.434557] traps: ld-linux-x32.so[25793] 
general protection ip:f7757eed sp:ffa995e8 error:0 in ld-2.17.so[f7741000+21000]
Feb 20 10:36:57 cacao kernel: [ 5299.452398] traps: ld-linux-x32.so[25807] 
general protection ip:f7746eed sp:ffa44b88 error:0 in ld-2.17.so[f773+21000]
Feb 20 10:36:57 cacao kernel: [ 5299.470434] traps: ld-linux-x32.so[25821] 
general protection ip:f77d7eed sp:ffb0f978 error:0 in ld-2.17.so[f77c1000+21000]
Feb 20 10:36:57 cacao kernel: [ 5299.495999] traps: ld-linux-x32.so[25835] 
general protection ip:f77f0eed sp:ffea4908 error:0 in ld-2.17.so[f77da000+21000]
Feb 20 10:36:57 cacao kernel: [ 5299.513835] traps: ld-linux-x32.so[25849] 
general protection ip:f779feed sp:ffeaba48 error:0 in ld-2.17.so[f7789000+21000]
Feb 20 10:37:03 cacao kernel: [ 5305.553176] do_general_protection: 38 
callbacks suppressed


Any ideas how to find out which program that is?


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

Bug#712545: xserver-xorg-core: Xorg crashes when displaying pictures

[Hilmar Preusse]

On 19.02.14 Sven Joachim (svenj...@gmx.de) wrote:

Hi,

> They will likely complain about your old kernel and mesa versions, but
> you can try (I don't think those matter in this case).  Please see
> http://nouveau.freedesktop.org/wiki/Bugs/ for instructions.
> 
https://bugs.freedesktop.org/show_bug.cgi?id=70510

Seems to describe my problem. Comment added.

H.
-- 
sigmentation fault


signature.asc
Description: Digital signature

Bug#739610: Drop dependency on python3.3 | python3-ipaddr

[Matthias Klose]

Package: pyspf
Version: 2.0.8-2
Tags: sid jessie patch
Severity: important
User: debian-pyt...@lists.debian.org
Usertags: python3.4

please drop the dependency on python3.3 | python3-ipaddr, not needed anymore and
doesn't help for python3.4.

patch at
http://launchpadlibrarian.net/166880245/pyspf_2.0.8-2ubuntu2_2.0.8-2ubuntu3.diff.gz


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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

[Thomas Orgis]

> >> > I see. In that case, I'll have to leave the package as it until
> >> > something along those lines is implemented.

So, I got conversion to float implemented now and tested with the
generic_nofpu decoder on x86-64. It _should_ of course work with ARM,
too;-) If you'd like to check the current snapshot of mpg123,

http://mpg123.org/snapshot/mpg123-20140220132548.tar.bz2 ,

you hopefull will find that any normal build of mpg123 (unless
specifying --disable-float explicitly) now offers all usual formats. As
a bonus, I even implemented the 8 Bit A-Law output, which has always
just been a placeholder (nobody missed it, apparently).

I'd be interested on some timings of

mpg123 -t -e s16 test.mp3
mpg123 -t -e f32 test.mp3

with the various builds you'll do for the ARM variants. Best would be running

perl scripts/benchmark-cpu.pl src/mpg123 
convergence_-_points_of_view/*.mp3

with

http://mpg123.orgis.org/convergence_-_points_of_view.tar.gz

as reference album, as mentioned on

http://mpg123.orgis.org/benchmarking.shtml

to be able to compare the performance of the code and machine to
others. This yields output like this:

#mpg123 benchmark (user CPU time in seconds for decoding)
#decodert_s16/s t_f32/s
x86-64  3.394.05
generic 6.156.01
generic_dither  6.365.97

... or this, with --with-cpu=generic_fpu:

#mpg123 benchmark (user CPU time in seconds for decoding)
#decodert_s16/s t_f32/s
generic 6.146.29

(on a Core2Duo machine).

> Yes, you can do that - build several copies of the library and use the
> hwcaps / auxv approach to pick the best one for the hardware at link
> time.
> 
> >NEON detection may come... but if we have linker selection, that would
> >be covered right now.
> 
> Yup.

Seconding the second part: Linker selection it is. NEON runtime
detection just isn't fun in user code.

The bright side: If the multiple builds are setup and tested, I can
safely release mpg123-1.19.0 with the changes and we finally have this
settled.


Alrighty then,

Thomas


signature.asc
Description: PGP signature

Bug#739596: tlsdate: Will be broken once the SSL handshake does not include timestamps anymore?

[Jacob Appelbaum]

That is incorrect.

tlsdate will continue to function, of course. There are already
non-compliant TLS servers that do not return time or return skewed
time. We attempt to compensate for that kind of server provided data
in a few different ways. There may also be new TLS servers that
implement Nick's TLS changes.

Furthermore, the next release of tlsdate to go into Debian will have
the added code (from Nick) to fetch the data/time via HTTP, not just
the SSL/TLS handshake data.

On 2/20/14, intrig...@debian.org  wrote:
> Package: tlsdate
> Version: 0.0.5-2
> Severity: normal
>
> Hi,
>
> my understanding is that tlsdate will be broken once Nick's proposal
> is accepted, and SSL handshakes don't include timestamps anymore.
>
> Is this correct?
> If it is, is including tlsdate in a stable Debian release a good idea?
>
> Cheers,
> --
>   intrigeri
>   | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
>   | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
>


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

Bug#739575: python-pysam-tests: world writable directory tree: /var/lib/pysam/tests

[Andreas Tille]

On Thu, Feb 20, 2014 at 11:47:51AM +0100, Andreas Beckmann wrote:
> On 2014-02-20 10:08, Andreas Tille wrote:
> > Hi Andreas,
> > 
> > the directory is intended to be written by the world since the whole
> > world should be able to run the test suite there ... this is the purpose
> > of this package at all:  Let everybody run the test (including
> > autopkgtest) and forget about the directory afterwards.
> 
> This works for $everybody. But $everybody+1 finds only the leftovers
> from his predecessor there (or nothing if he cleaned up "properly").

Yes, this might happen.  The main purpose of this package to provide
some larger chunks of data in a convinient way to run autopkgtest.  This
could for sure be approached by providing (compressed) files in a
readonly dir, uncompress them to `mktemp -d` and run the tests there.
However, I do simply see no reason to put this extra effort onto the
test running machines.

If human testers might test manually and somebody else has changed the
files for whatever reason - hey, the test will fail in the worst case.
That's a pity but I see no practical problem since in real life cases
people have their reason to play with the stuff and know about the
consequences.

> > Do I need to mark this intention to not provoke any errors?
> 
> If you convince me, I can add exceptions. But I need to dig into this
> further.
> 
> Users are allowed to modify/delete the python scripts in that directory?
> What is the expected bahavior on package updates and modified .sam files
> there?

If a new upstream release is issued the files should be overriden by the
content of the new test suite.  Everything of the current world writable
dir can go to the dustbin.

Kind regards

Andreas.

-- 
http://fam-tille.de


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

Bug#628654: xbindkeys: New release blocks seahorse

[anomie]

This should have been in the NEWS.Debian file, so apt-listchanges would
have flagged it on upgrade. I rebooted my laptop this morning and had to
track down why xbindkeys suddenly wasn't running.


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

Bug#731861: transition: miniupnc

[Boris Pek]

Hi,

> Nope - the transition isn't finished until libminiupnpc5 is no longer in
> testing. It's currently being kept there by transmission, which is in
> turn waiting for glib2.0.
>
> I was going to re-open the bug, but hopefully both transmission and
> glib2.0 will transition in tonight's britney run, at which point the
> transition really will be done.

Thanks for an explanation.

Best regards,
Boris


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

Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing

[Brad King]

On 02/19/2014 04:54 PM, Sylvestre Ledru wrote:
> this patch fixes it. I will upload it when I have more stuff to upload
> (except if you need it soon)

Thanks.  I will wait for the next update and then try it again.

-Brad


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

Bug#731861: transition: miniupnc

[Adam D. Barratt]

On 2014-02-20 12:42, Boris Pek wrote:

http://packages.qa.debian.org/m/miniupnpc/news/20140218T163916Z.html


Nope - the transition isn't finished until libminiupnpc5 is no longer in 
testing. It's currently being kept there by transmission, which is in 
turn waiting for glib2.0.


I was going to re-open the bug, but hopefully both transmission and 
glib2.0 will transition in tonight's britney run, at which point the 
transition really will be done.


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#739611: transition: ruby1.9.1 removal

[Antonio Terceiro]

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

The Ruby maintainers want to make sure ruby1.9.1 is not included in
Jessie.

Different from the ruby1.8 transition, which was huge and is almost
done, work on this one is just starting though it tends to be a lot
smoother.

We begin with ~140 packages in "bad" state, of which:

- ~120 will be able to be fixed with binNMU's once ruby-defaults is
  updated to not pull ruby1.9.1 anymore.

- ~20 seem to be explicitly (build-) depending on ruby1.9.1. We will
  investigate them individually, file bugs and when possible send
  patches. I don't expect this to be too much trouble, since packages
  that already work with ruby1.9.1 tend to not have problems with later
  versions.

Ben file:

title = "ruby1.9.1 removal";
is_affected = .depends ~ /ruby/ | .build-depends ~ /ruby/;
is_good = !(.depends ~ /ruby1.9.1/ | .build-depends ~ /ruby1.9.1/);
is_bad = .depends ~ /ruby1.9.1/ | .build-depends ~ /ruby1.9.1/;

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Bug#707075: otrs2: fails to upgrade from testing due to storage engine change

[Patrick Matthäi]

Am 20.02.2014 11:17, schrieb Patrick Matthäi:


Automagic is not possible. I have added the following to README.Debian:

Upgrading to MySQL >= 5.5:
--

Since MySQL 5.5 changed its default storage engine from MyISAM to InnoDB
you
might encounter problems on upgrading OTRS from the otrs.CheckDB.pl script.

Here you will find additional notes about this problem:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707075

Here you will find a possible solution:

http://blog.otrs.org/2013/02/20/about-otrs-mysql-myisam-and-innodb-storage-engines/





And I wouldn't mind a receipe how I can fix this up easily in piuparts
in a scriptable way (either changing mysql config or doing some sql or
whatever).


For piuparts it might be a better idea to test it with Postgres as
database backend, or while you upgrade your MySQL server adding
default-storage-engine=MYISAM to the my.cnf, but this is ugly.




Do you agree with re-closing with the next upload?

--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


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

Bug#736919: infinite loop in grep -P on some files with invalid UTF-8 sequences

[Vincent Lefevre]

Control: retitle -1 infinite loop or segmentation fault in grep -P on some 
files with invalid UTF-8

Another testcase, this time with a segmentation fault:

$ /usr/bin/printf "d\214\366u" | grep -P "d.?ru"
Segmentation fault (core dumped)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

Bug#739514: No proper handling uf UDAs

[Jakub Wilk]

Control: retitle -1 taskwarrior: cannot add UDA with underline in name
Control: tag -1 + confirmed

* Klaus Ethgen , 2014-02-20, 13:40:

Maybe it is the underline that makes the difference.


I think so.

--
Jakub Wilk


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

Bug#739612: ste-plugins: package description format problem

[Justin B Rye]

Package: ste-plugins
Version: 0.0.2-1
Severity: wishlist
Tags: patch

The long description for ste-plugins is obviously meant to be a
bulleted list; but it lacks the required indent, so it gets re-wrapped
on displays such as "https://packages.debian.org/sid/ste-plugins":

> A set of stereo plugins. * Stereo width * Stereo balance and panner

My patch adds the one-character indent; while I was doing that I've
also turned it into a punctuated sentence.

| Description: stereo LADPSA plugins
|  This package provides a set of stereo plugins:
|   * Stereo width;
|   * Stereo balance and panner.

(I assume there's some good reason that's two bulletpoints rather than
three... there's no sign of documentation on the upstream homepage.)

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (50, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.13-trunk-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ste-plugins depends on:
ii  libc6   2.17-97
ii  libgcc1 1:4.8.2-15
ii  libstdc++6  4.8.2-15

ste-plugins recommends no packages.

ste-plugins suggests no packages.

-- no debconf information

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff -ru ste-plugins-0.0.2.pristine/debian/control ste-plugins-0.0.2/debian/control
--- ste-plugins-0.0.2.pristine/debian/control	2014-02-17 15:39:21.0 +
+++ ste-plugins-0.0.2/debian/control	2014-02-20 13:05:36.326557818 +
@@ -21,6 +21,6 @@
 Provides:
  ladspa-plugin
 Description: stereo LADPSA plugins
- A set of stereo plugins.
- * Stereo width
- * Stereo balance and panner 
+ This package provides a set of stereo plugins:
+  * Stereo width;
+  * Stereo balance and panner.

Bug#739613: flac encode crashes if called as a python subprocess

[Cedric Andrieu]

Package: flac
Version: 1.3.0-2
Severity: normal

Dear Maintainer,

The jack CD ripper package in debian fails when calling the flac
encoder. This is logged in bug #720782.  This happens since the flac
package upgrade to upstream 1.3.0.x
Look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720782

After some digging, I believe the bug shall be corrected inside flac
which does a divide by zero when not called from a terminal.

file: src/flac/utils.c

function: get_console_width(void)

{
int width = 80;
#if defined _WIN32
width = win_get_console_width();
#elif defined __EMX__
int s[2];
_scrsize (s);
width = s[0];
#elif !defined __ANDROID__
struct winsize w;
if (ioctl(STDOUT_FILENO, TIOCGWINSZ, &w) != -1) width = w.ws_col;
#endif
return width;
}


shoudl be
int get_console_width(void)
{
int width = 80;
[...]
#elif !defined __ANDROID__
struct winsize w;
if (ioctl(STDOUT_FILENO, TIOCGWINSZ, &w) == -1 || w.ws_col == 0 )
width = 80;
  else
width = w.ws_col;
#endif
return width;
}

this way we always have a default at 80 chars.

Hope this helps,

Ced

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

Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages flac depends on:
ii  libc6 2.17-97
ii  libflac8  1.3.0-2

flac recommends no packages.

flac 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#739593: systemd makes / shared by default

[Bastian Blank]

system remounts / as shared with the following comment:

| Mark the root directory as shared in regards to mount
| propagation. The kernel defaults to "private", but we think
| it makes more sense to have a default of "shared" so that
| nspawn and the container tools work out of the box. If
| specific setups need other settings they can reset the
| propagation mode to private if needed.

Bastian

-- 
Bastian Blank
Berater   Durchwahl: +49 2161 / 4643-194
credativ GmbH, HRB Mönchengladbach 12080  Zentrale: +49 2161 / 4643-0
Hohenzollernstr. 133  Fax: +49 2161 / 4643-100
D-41061 Mönchengladbach   www: http://www.credativ.de
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer


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

Bug#739498: Test your package with libssh 0.6.x

[Bálint Réczey]

Hi Mike,

2014-02-19 13:08 GMT+01:00 Mike Gabriel :
> Package: xbmc-bin
>
> Dear maintainer,
>
> the libssh maintainers are planning the upload of libssh 0.6.x to unstable
> soon (4-6 weeks from now).
>
> Please test your package's functionality with libssh 0.6.1 as found in
> Debian experimental (currently: 0.6.1-1~exp1).
xbmc builds and runs fine with libssh 0.6.1.
Thanks for the heads-up.

Cheers,
Balint


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

Bug#568303: can-utils Debian package

[Alexander Gerasiov]

Sorry guys. I'm totally busy with other tasks last month :-(. As I remember 
your package is quite ready for upload, so I'll do it tomorrow (without my 
changes, just add myself as an uploader if you don't mind). Ok?



On February 20, 2014 1:52:19 PM Uwe Kleine-König 
 wrote:



Hello Alexander, hello *,

On Thu, Jan 23, 2014 at 07:39:51PM +0100, Uwe Kleine-König wrote:
> On Wed, Jan 15, 2014 at 08:02:07PM +0400, Alexander GQ Gerasiov wrote:
> > > On Wednesday 15 January 2014 12:40:52 you wrote:
> > > > I've notice some progress on the issue:
> > > > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568303
> > > > > > > If Alexander won't post anything to this bug, where can I 
find the

> > > > package archives, he was talking about?
> > > > > He was talking about collab-maint:
> > > > > 
http://anonscm.debian.org/gitweb/?p=collab-maint/can-modules.git;a=summary

> > > http://anonscm.debian.org/gitweb/?p=collab-maint/can-utils.git;a=summary
> > > > > Anyone can join collab-maint, you don't need to be Debian developer.
> > > It would be good if you two coordinate. CCing Alexander therefore.
> > > I'm in heavy reformatting package from the link above. (Only can-utils,
> > cause I use vanilla kernel's modules.)
> I started creating a debian package from scratch, too, before being
> aware of this bug. My plan was to sent the ITP bug once the package is
> ready together with an RFS (as I'm only DM).
> > Right now I've asked my college to make clean-room rewrite of some
> > lines in slcand.c, because it has licensing issues. (Mix of GPL and
> > GFDL licensed code.)
> This is resolved upstream in commit
> 393a91c7d8f6 (slcand: reimplement daemonize routine).
> > I think I'll do an upload this week or the next one. If you have any
> > ideas or want to join packaging on alioth, you're welcome. But please
> > contact me prior any work, because current version on alioth is very
> > different from one I'm working on. (And because of many changes I don't
> > see a reason to upload broken state into git repo right now.)
> I'll rebase my packaging stuff, fixup for the latest changes and will
> let you know. Maybe we can work together then and pick the best things
> from both approaches.
I finished my packaging stuff nearly a month ago and contacted Alexander
by private mail without response so far. My efforts are available at

http://git.pengutronix.de/?p=ukl/can-utils.git debian/sid

I'd like to get forward here. @Alexander: Maybe you can provide me with
the work you did already, then I'll merge our approaches. Are you still
interested in co-maintainance of can-utils? If not, are you OK when I
take ownership of this bug and start looking for a sponsor?

Best regards
Uwe

--
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |



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

Bug#733556:

[Mathieu Malaterre]

Control: tag -1 grave

Since this is a regression I am marking this as grave.

I also get the same behavior here:

$ ./zurg.exe
run-detectors: unable to find an interpreter for ./zurg.exe

$ file zurg.exe
zurg.exe: PE32 executable (console) Intel 80386, for MS Windows

$ sudo update-binfmts --display
llvm-3.0.binfmt (enabled):
 package = llvm
type = magic
  offset = 0
   magic = BC
mask =
 interpreter = /usr/bin/lli-3.0
detector =
python2.6 (enabled):
 package = python2.6
type = magic
  offset = 0
   magic = \xd1\xf2\x0d\x0a
mask =
 interpreter = /usr/bin/python2.6
detector =
python2.7 (enabled):
 package = python2.7
type = magic
  offset = 0
   magic = \x03\xf3\x0d\x0a
mask =
 interpreter = /usr/bin/python2.7
detector =
cli (enabled):
 package = mono-runtime
type = magic
  offset = 0
   magic = MZ
mask =
 interpreter = /usr/bin/cli
detector = /usr/lib/cli/binfmt-detector-cli
jar (enabled):
 package = openjdk-6
type = magic
  offset = 0
   magic = PK\x03\x04
mask =
 interpreter = /usr/bin/jexec
detector =
jarwrapper (enabled):
 package = 
type = magic
  offset = 0
   magic = PK\x03\x04
mask =
 interpreter = /usr/bin/jarwrapper
detector = /usr/bin/jardetector
python3.2 (enabled):
 package = python3.2
type = magic
  offset = 0
   magic = \x6c\x0c\x0d\x0a
mask =
 interpreter = /usr/bin/python3.2
detector =


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

Bug#737723: wrong codeset for the Bulgarian translation

[Peter Pentchev]

On Wed, Feb 05, 2014 at 02:41:29PM +0200, Peter Pentchev wrote:
[snip]
> I guess it's up to you now to decide whether to add this patch to the
> Debian package, wait for a new upstream release with it included, or at
> least wait for upstream to comment on it in SourceForge bug #169 :)

Just for the record, SourceForge bug #169 was resolved as 'fixed' and
the patch that I submitted there was integrated into the Fluxbox upstream
Git repository.  Now all we have to do is wait for a new release :)

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p.penc...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
Hey, out there - is it *you* reading me, or is it someone else?


signature.asc
Description: Digital signature

Bug#739614: [apache2] unable to execute apache2

[Marco Righi]

Package: apache2
Version: 2.4.7-1
Severity: grave

--- Please enter the report below this line. ---
It is impossible execute Apache2 and the log files are empty!
Apache has been installed using synaptic.

Please ask to me if you need more informaitons.

Thanks
Marco Righi

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.12-1-amd64

Debian Release: jessie/sid
  500 testing-updates ftp.it.debian.org
  500 testing www.deb-multimedia.org
  500 testing security.debian.org
  500 testing ftp.it.debian.org
  500 testing apt.jenslody.de
  500 stable  repo.wuala.com
  500 stable  apt.spideroak.com
  500 sid linux.dropbox.com
  500 debian  packages.linuxmint.com
  100 jessie-backports ftp.it.debian.org

--- Package information. ---
Depends(Version) | Installed
-+-=
lsb-base | 4.1+Debian12
procps   | 1:3.3.9-2
perl | 5.18.2-2
mime-support | 3.54
apache2-bin  (= 2.4.7-1) | 2.4.7-1
apache2-data (= 2.4.7-1) | 2.4.7-1
lsb-base | 4.1+Debian12
procps   | 1:3.3.9-2
perl | 5.18.2-2
mime-support | 3.54
apache2-bin  (= 2.4.7-1) | 2.4.7-1
apache2-data (= 2.4.7-1) | 2.4.7-1
libapr1   (>= 1.5.0) | 1.5.0-1
libaprutil1   (>= 1.5.0) | 1.5.3-1
libaprutil1-dbd-sqlite3  | 1.5.3-1
 OR libaprutil1-dbd-mysql|
 OR libaprutil1-dbd-odbc |
 OR libaprutil1-dbd-pgsql|
 OR libaprutil1-dbd-freetds  |
libaprutil1-ldap | 1.5.3-1
libc6  (>= 2.14) |
libldap-2.4-2 (>= 2.4.7) |
liblua5.1-0  |
libpcre3   (>= 8.10) |
libssl1.0.0   (>= 1.0.1) |
libxml2   (>= 2.7.4) |
zlib1g  (>= 1:1.1.4) |
perl | 5.18.2-2


Package Status  (Version) | Installed
=-+-===
apache2   | 2.4.7-1
apache2-bin   | 2.4.7-1


Recommends  (Version) | Installed
=-+-===
ssl-cert  | 1.0.33
ssl-cert  | 1.0.33


Suggests (Version) | Installed
==-+-===
www-browser|
apache2-doc|
apache2-suexec-pristine|
 OR apache2-suexec-custom  |
apache2-utils  | 2.4.7-1
www-browser|
apache2-doc|
apache2-suexec-pristine|
 OR apache2-suexec-custom  |
apache2-utils  | 2.4.7-1
www-browser|
apache2-doc|
apache2-suexec-pristine|
 OR apache2-suexec-custom  |



--- Output from package bug script ---


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

Bug#555613: cheese quits as soon as started

[althaser]

Hey,

Could you please still reproduce this issue with newer version of cheese
like 3.4.2-2 or 3.10.1-1sid1 ?

thanks
regards
althaser

Bug#727708: init system coupling etc.

[Ian Jackson]

Russ Allbery writes ("Bug#727708: init system coupling etc."):
> If you do mean that all packages with init system configuration have to
> ship sysvinit scripts, I wish the wording would actually say that.  This
> potentially matters in the long run.  For example, consider a hypothetical
> future world in which systemd, upstart, and OpenRC are packaged for Debian
> and sysvinit has gone away.  In that world, I would maintain separate
> configuration for systemd, upstart, and OpenRC, since I consider
> maintaining those three separate files to be easier than maintaining a
> sysvinit script.  Is that permitted?  If it is permitted, does my package
> become instantly buggy when someone packages openlaunchd for Debian?

The draft text in my option says:

   In general, software may not require a specific init system to be
^^
   pid 1.  The exceptions to this are as follows:

I think this leaves open the possibility that software might not work
with certain init systems.  I'm not trying to say that all software
must work properly with all init systems, no matter how experimental
or broken.  (Although that would be nice of course.)

In particular, I don't think this is imposing a requirement for
daemons to work with init systems which do not provide at least a
compatibility mode for common interfaces (at the moment, the common
interfaces for this include sysvinit scripts, inetd.conf and perhaps
something else I haven't thought of).

In practice what I would like to see is a kind of more powerful
compability mechanism that is better able to exploit the better
behaviours of more modern daemon supervisors.

But at the moment the main compatibility mechanism sysvinit scripts,
and all of our init systems support sysvinit scripts.  So that means
that all packages should ship sysvinit scripts.  Work is ongoing on
other kinds of compatibility approaches.  (It's not even necessary for
all daemon packages or all init systems to use the same compatibility
approach.)

I'm relaxed about the idea of packages having to ship sysvinit scripts
indefinitely.  Shipping sysvinit scripts does not mean that they have
to be handwritten.  It would be perfectly feasible for a daemon which
only supported a sensible non-forking startup approach to provide an
init script which is autogenerated from some kind of meta information
(and to use a helper tool for daemonisation).

I think there's a clear segment of opinion in the project and amongst
our users who want to keep the traditional sysvinit approach.  It's
not clear whether a minority or a majority will actually want to run
sysvinit indefinitely, but even if we think other approaches are
better that doesn't mean we should be forcing them on everyone.

> I think what you're trying to say, from the above, is:
> 
> All software that needs init system configuration must include
> sysvinit scripts.  Software may not require any functionality from the
> init system that cannot be provided via init scripts, although
> degraded operation is tolerable.  The exceptions to this are as
> follows:
> 
> Also, I assume that this language intends to say that this is forever.  In
> other words, no package is ever permitted to drop sysvinit scripts,
> regardless of what init systems are in use in Debian, at least until the
> TC issues another ruling.
> 
> If L passed, that's what I'd assume I was supposed to put in Policy.  If
> that's *not* what you mean, well, I think it's even more important to
> clarify this somehow.

For now, yes, you should put that into policy.  If we later come up
with a better compatibility approach, policy can be amended.  The TC
decision is defining the objectives, not the details.

Thanks,
Ian.


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

Bug#698375: gfs2-utils: fails to upgrade from squeeze: insserv: script gfs2-utils: service gfs2 already provided!

[Salvatore Bonaccorso]

Hi Andreas,

Do you have an idea how to solve this the right way?

Note: I'm not the mainainer, but due to the reverse dependencies I'm
interested in I hope to see this fixed for jessie (to not get them
removed).

Removal of redhat-cluster will also affect lvm2 and ocfs2-tools as an
example.

Regards,
Salvatore


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

Bug#739589: qemu: Multiple security issues

[Moritz Muehlenhoff]

On Thu, Feb 20, 2014 at 02:02:03PM +0400, Michael Tokarev wrote:
> > But I don't understand what is meant by the second part:
> > 
> > | * Saving/Loading state to/from file.
> > | For example:
> > | https://bugzilla.redhat.com/show_bug.cgi?id=588133#c8
> > | https://bugzilla.redhat.com/show_bug.cgi?id=588133#c9
> > 
> > The RH bugs are restricted and I don't understand what is meant with
> > "saving/loading state to/from file". Is this about snapshots or
> > malformed images? Do you have an idea?
> 
> It is like snapshots, yes.  One can save a guest memory image into
> a file and load it later.  It is pretty much like migration (and
> implemented using the same mechanism), but with a delay between
> saving and loading.
> 
> One of the bugs mentioned above is about giving developer such a
> saved file from local qemu asking for help in diagnosing an apparent
> bug, and that image will try to exploit developer's qemu by using
> one of these flaws.  Something like that anyway -- see
> http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00612.html
> 
> Another possible scenario is someone distributing virtual machines
> for end-users, trying to exploit their qemu.
> 
> Unlike for, say, gif images or word documents or whatever, qemu
> guest image _may_ come in one of 2 forms: it is just the drive
> image (content of virtual hard drive), which you run and it boots
> from the beginning as your regular PC will do.  Or this drive
> image coupled with memory image, so when you run it, your system
> is in some non-initial runtime state.  It is definitely unusual
> to distribute something in the second form, together with the
> memory state.
> 
> So I can imagine someone selling pre-loaded virtual machines
> (doing it this way, together with memory state, is rare but can
> have its reasons too, say, for a system which require significant
> boot time).  Or, for example, your qemu/kvm hosting provider can
> have a function to transfer whole your virtual machine (together
> with the memory state) to you - either in terms of files like
> that, or using online migration.
> 
> When you perform save/load locally in your usual environment where
> you run qemu, you don't let stranger to modify the memory state
> files created by qemu.  So locally this is not exploitable (unless
> you use already hacked/modified qemu to create the images in the
> first place, but that's obviously not very interesting case).
>
> >> So.. oh well.  I'd really love to not backport all this shit to
> >> wheezy... ;)
> > 
> > If "Saving/Loading state to/from file" is negligable as well, 
> > I would mark it as a non-issue in the tracker.
> 
> Both ways to "use" one of these vulns are real, but both are quite
> difficult to use, hence the probably-low-impact.
> 
> Basically we've two possible ways to use these vulns.
> 
> First is to "spread" a break-in to other machines by, after breaking
> into one machine (using some other way) and hacking qemu on it, it
> becomes possible to break into qemu on the receiving-migration machine.
> 
> And second is when someone gives whole guest image (together with the
> memory state) to you, tricking you to run it one way or another.
> 
> That's what issues are all about.  Not very serious, but not a non-issue
> either.

Thanks for the verbose explanation. Since both attacks as rather far-fetched,
I'll mark these as  in the security tracker. So we don't need a
Wheezy backport through security.debian.org

Cheers,
Moritz


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

Bug#637256: cheese: Cheese crashes when switching from photo- to videomode

[althaser]

Hey Daniel,

I can't reproduce it here with cheese-3.10.1-1sid1.

Could you please still reproduce this issue with newer version of cheese
like 3.4.2-2 or 3.10.1-1sid1 ?

thanks
regards
althaser

Bug#727708: init system coupling draft CFV

[Ian Jackson]

Ian Jackson writes ("Bug#727708: init system coupling draft CFV"):
> Here are the options which have been proposed so far, with the
> proposed amendments incorporated as applicable.
> 
> You can find the history (with messageids) in the tc git repo.
> 
> There are curently four options:
> 
>   Ian mark 2 (inclues amendments from Colin and Ian)
>   Keith
>   Russ (includes one thing that loos like an amendment)
>   Ian mark 1 (includes Colin's amendment, but likely to be dropped)

I hereby accept what I've called the "mark 2" amendment here, which
has the effect of dropping "mark 1" from the ballot.

(I'm about to make the corresponding change to the git repo.)

Ian.


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

Bug#739615: RM: fgfs-base [source] -- RoM; obsolete source package

[Markus Wanner]

Package: ftp.debian.org
Severity: normal

Dear FTP Masters,

the source package fgfs-base has been replaced by flightgear-data and
needs removal from unstable.

I'm not sure why, but this did not happen automatically (rene). The
cruft report doesn't show fgfs-base, either. See also bug #737519.

Regards

Markus Wanner



signature.asc
Description: OpenPGP digital signature

Bug#739616: missing license in debian/copyright

[Thorsten Alteholz]

Package: syncevolution
Severity: serious
User: alteh...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks

Dear Maintainer,

please add the missing license of
  syncevolution_1.3.99.7\src\gdbus\test\example.cpp
  syncevolution_1.3.99.7\src\gdbusxx\test\example.cpp 
to debian/copyright


Thanks!
  Thorsten


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

Bug#736087: [debian-mysql] Bug#736087: mysql-5.5: Please install AppArmor profile on Debian too

[Felix Geyer]

dh_apparmor is still only called on Ubuntu:
if [ "$(DISTRIBUTION)" = "Ubuntu" ]; then \
  dh_apparmor -pmysql-server-5.5 --profile-name=usr.sbin.mysqld; \
fi

That means all the postinst magic is missing to create 
/etc/apparmor.d/local/usr.sbin.mysqld and load the profile.


Cheers,
Felix


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

Bug#727708: init system coupling etc.

[Thorsten Glaser]

Ian Jackson dixit:

>(and to use a helper tool for daemonisation).

mksh -T- -c 'exec daemond arg1 …'

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)


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

Bug#733312: fuse permission problem

[Christopher Odenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi,

we also have a permission problem with fuse. We use udev to give
everybody permissions to /dev/fuse.

Unfortunately udev only gets triggered when the fuse module is loaded.

Unfortunately the module only gets loaded automatically if someone
accesses /dev/fuse which is impossible for ordinary users not in group
fuse.

A workaround in wheezy is to install the package fuse-utils which
provides an init script which loads the module at system boot.

Please set the default permission to 0666. If someone wants to
restrict permissions he can use the udev rule for this.

Christopher

- -- 
==
Dipl.-Ing. Christopher Odenbach
Zentrum fuer Informations- und Medientechnologien
Universitaet Paderborn
Raum N5.311
odenb...@uni-paderborn.de
Tel.: +49 5251 60 5315
==
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iD8DBQFTBgjYhxiCJKeLY0IRAj0vAJ0cq4VsGsAHmQOS1fJU4Hm15LvQRACfR+Lg
yzPrtEY3atBFiXU1gZuXmHU=
=vWE7
-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#739617: python-django-auth-openid: Unusable with django 1.6

[Neil Williams]

Package: python-django-auth-openid
Version: 0.5-1
Severity: important

I've recently updated a django app (not currently in Debian) to
support django1.6 but the app fails due to the use of django-auth-openid
using a deprecated import:

Traceback (most recent call last):

  File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 
101, in get_response
resolver_match = resolver.resolve(request.path_info)

  File "/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line 
318, in resolve
for pattern in self.url_patterns:

  File "/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line 
346, in url_patterns
patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)

  File "/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line 
341, in urlconf_module
self._urlconf_module = import_module(self.urlconf_name)

  File "/usr/lib/python2.7/dist-packages/django/utils/importlib.py", line 40, 
in import_module
__import__(name)

  File "/usr/lib/python2.7/dist-packages/lava_server/urls.py", line 80, in 

include('django_openid_auth.urls')),

  File "/usr/lib/python2.7/dist-packages/django/conf/urls/__init__.py", line 
26, in include
urlconf_module = import_module(urlconf_module)

  File "/usr/lib/python2.7/dist-packages/django/utils/importlib.py", line 40, 
in import_module
__import__(name)

  File "/usr/lib/pymodules/python2.7/django_openid_auth/urls.py", line 30, in 

from django.conf.urls.defaults import *

ImportError: No module named defaults

This line needs to be:

from django.conf.urls import *

Simple change but django1.6 is the current version in unstable, so it would be 
good to get
this fixed.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armel
armhf

Kernel: Linux 3.10-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-django-auth-openid depends on:
ii  python  2.7.5-5
ii  python-django   1.6.1-2
ii  python-openid   2.2.5-3
ii  python-support  1.0.15

python-django-auth-openid recommends no packages.

python-django-auth-openid suggests no packages.

-- no debconf information


-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Bug#739184: ray: FTBFS on mips/mipsel/s390x: error: 'memcpy' was not declared in this scope

[Dejan Latinovic]

Hello,

Apart form mips/mipsel architectures, the declaration of memcpy is reached 
through openmpi.
Since the mpi-defaults for mips/mipsel was build against mpich (not openmpi),
this issue appeared.
Therefore, package ray does build succsessfully on other architectures without 
changes.

New mpi-defaults version 1.0.2+nmu1 is build against openmpi for mips/mipsel.

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

Bug#727708: init system coupling etc.

[Ian Jackson]

I'm writing here in a purely secretarial capacity.

Russ Allbery writes ("Bug#727708: init system coupling etc."):
> Colin Watson  writes:
> > I agree.  Russ, how about this amendment?

Is that a formal proposal ?

> > diff --git a/727708_initsystem/coupling-russ.txt 
> > b/727708_initsystem/coupling-russ.txt
> > index 242505a..dfc1ded 100644
[etc]
> 
> This seems fine.

And is this an acceptance ?


As a matter of process, it would be very wise for everyone to at least
make all statements approving changes to these kind of resolutions as
formal proposals.  That way you don't risk not having time to
explicitly accept the formal amendment before the CFV.

Likewise if a TC member thinks a change is important enough that they
want to press for it, it would be better to propose it as a formal
amendment.  It can always be withdrawn or accepted later.  A TC member
would be well-advised to make such a formal proposal iff they want
something like their suggestion to be on the ballot.


I think in the absence of clarity, when preparing the CFV, I should
probably proceed on the following basis:

  - Statements from TC members suggesting changes but not explicitly
stating that they are formal proposals, are not formal proposals.

Rationale: This avoids the ballot being clogged up with a
profusion of suggested edits which the suggester probably didn't
want to put onto the ballot if not accepted.

  - Statements from TC members expressing unqualified approval of
suggested edits to their own texts are to be treated as formal
acceptance of amendments (including formal proposal of the
amendment if necessary).  Even if the TC member's message does
not contain an explicit "I hereby ..." statement.

Rationale: This avoids the ballot containing older versions of a
text in a situation where a TC member didn't get around to
whatever tidying up or redrafting they felt they were waiting for.

If anyone disagrees with this, please say.


So accordingly, I intend to treat Russ's "this seems fine" as an
acceptance of Colin's suggestion.

> > -For the jessie release, all packages that currently support being run
> > +For the jessie release, all software that currently supports being run
> >  under sysvinit should continue to support sysvinit unless there is no
> >  technically feasible way to do so.  Reasonable changes to preserve or
> >  improve sysvinit support should be accepted through the jessie
> >  release.  There may be some loss of functionality under sysvinit if
> 
> This looks good.

And this.

But not the other suggestions in Colin's mail, which Russ either
didn't quote or disagreed with.


But for now I'm not going to make these changes in git.  Instead I'm
going to drop the message-id of Russ's message into the git repo as a
note that it contains accepted amendments which need integrating.

That will save effort if Russ decides to rewrite or re-edit the file
himself.

I trust this meets with everyone's approval.  Sorry to be so
long-winded and pernickety about process, but I don't want to make
sure that we all agree on the process and the proprieties and I don't
want anyone to be taken by surprise.

Thanks,
Ian.


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

Bug#727708: init system coupling etc.

[Ian Jackson]

Ian Jackson writes ("Bug#727708: init system coupling etc."):
> Steve Langasek writes ("Bug#727708: init system coupling etc."):
> > So I don't think a 24 hour period between draft CfV and CfV is
> > adequate here.  There have been a lot of proposals discussed in
> > this thread, and it's not at all clear which are stillborn and
> > which people think warrant carrying forward.
> 
> I think this is in fact perfectly clear.  But I am prepared to commit
> to a further 24h extension if you promise that you will not ask for
> even more time beyond that.

I've not heard from Steve.  Under the circumstances I think it would
be entirely reasonable of me to call for votes at 18:30 UTC today as I
originally said I would.  However, I don't want to get into another
process row.

Also Russ and Colin do seem still to be working on final improvements
to Russ's text.  So, I'm going to wait another day.

I will Call for Votes at 18:00 UTC tomorrow, Friday.  I'm going to
send another Draft CFV this evening at around the same time, including
whatever amendments etc. have been put forward by then.

In the meantime I'm generally transferring formal actions into the git
repo so that I don't have to go through my mailbox again later looking
for them.

As I have previously said, there is nothing stopping anyone putting
forward amendments right up to the Call for Votes.  But I don't want
to delay this CFV again.

Ian.


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

Bug#739618: 'less' makes 'topal' paniced

[Gabor Kiss]

Package: topal
Version: 72-1
Severity: normal

On my system topal calls pager 'less' to show the signed mail
before sending. I use accented (non-ascii) chars therefore
less ask confirmation before really showing "binary" data.
If I answer "n" less returns with status 1 that causes panic
in topal.

Gabor

-- System Information:
Debian Release: 6.0.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages topal depends on:
ii  gnupg  1.4.10-4+squeeze4 GNU privacy guard - a free PGP rep
ii  less   436-1 pager program similar to more
ii  libc6  2.11.3-4  Embedded GNU C Library: Shared lib
ii  libgcc11:4.4.5-8 GCC support library
ii  libgnat-4.44.4.5-3   Runtime library for GNU Ada applic
ii  libreadline6   6.1-3 GNU readline and history libraries

Versions of packages topal recommends:
ii  alpine 2.00+dfsg-6.1 Text-based email client, friendly 
ii  gpgsm  2.0.14-2+squeeze2 GNU privacy guard - S/MIME version
ii  mime-support   3.48-1MIME files 'mime.types' & 'mailcap
ii  openssl0.9.8o-4squeeze14 Secure Socket Layer (SSL) binary a
ii  procmail   3.22-19   Versatile e-mail processor

Versions of packages topal suggests:
pn  metamail   (no description available)

-- 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#739604: sysvinit: The new skeleton does not work on kFreeBSD

[Gergely Nagy]

Petter Reinholdtsen  writes:

> [Gergely Nagy]
>> The change introduced in sysvinit 2.88dsf-50, which turns
>> /etc/init.d/skeleton into a script that has /lib/init/init-d-script
>> as interpreter fails on kFreeBSD, because on that platform,
>> interpreters cannot be other scripts.
>
> Oh.  I tested on Linux and Hurd, and did not imagine that kFreeBSD was
> that different from these two. :)

It's Linux (since 2.6), Hurd and Minix being different from anything
else :)

>> If you want to do this kind of thing, you will either need a binary
>> wrapper at least on kFreeBSD, or you'll need to use sourcing.
>
> Right.  Back to the drawing board. :)
>
> Can you test this construct instead of #!/lib/init/init-d-script:
>
>   #!/bin/sh
>   if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
> set $0 $@; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
>   fi

I can try it tomorrow or so. If you want, you can try it on the kfreebsd
porter boxes, it's easily reproducible there.

-- 
|8]


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