Bug#784148: base-installer: NTP daemon should be installed on any system missing an RTC

[Wouter Verhelst]

On Sun, May 03, 2015 at 06:55:51PM +0200, Geert Stappers wrote:
> embedded systems, cheap embedded systems that have no real time clock,
> those are the ones that I expect to be without network connection.
> Example given: stand-alone mediaplayers.

Isn't it possible to configure systemd so that it only starts certain
daemons if there's network? Having an NTP daemon installed on such
networks, and configured so that it does that, would alleviate that
concern.

(That would not fix the issue for non-systemd installs, but that
shouldn't be too much of a problem)

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


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

Bug#785431: python-apt: Set Standards-Version to 3.9.6

[von]

Package: python-apt
Version: 0.9.4
Severity: normal
Tags: patch

Standards-Version should be upgraded from 3.9.5 to 3.9.6

Looking at https://www.debian.org/doc/debian-policy/upgrading-checklist

we see that no items impact python-apt

A patch is added to do the upgrade.
>From 62f8e04ab92c07921054e6bb3a5ca417e65afb0f Mon Sep 17 00:00:00 2001
From: von 
Date: Sat, 16 May 2015 00:52:49 +0200
Subject: [PATCH] Set Standards-Version to 3.9.6

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 9d11264..38065c2 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: python
 Priority: standard
 Maintainer: APT Development Team 
 Uploaders: Michael Vogt , Julian Andres Klode 
-Standards-Version: 3.9.5
+Standards-Version: 3.9.6
 X-Python-Version: >= 2.7
 X-Python3-Version: >= 3.3
 Build-Depends: apt (>= 0.9.6),
-- 
2.1.4

Bug#783308: RFS: mediagoblin/0.7.1+dfsg1-1 [ITP]

[Paul Wise]

On Fri, May 15, 2015 at 9:27 PM, Simon Fondrie-Teitler wrote:

> I looked into packaging them separately, but couldn't find good
> documentation on how to package css or javascript files. A few Debian
> developers I talked recommended not packaging them on their own.

For JavaScript, check out the many libjs-* examples in the archive.
For CSS, it would just be a matter of installing the files in
/usr/share/ somewhere and having mediagoblin refer to them. Embedded
code copies are against policy. The world of web software however
often plays fast and loose with APIs, often very specific versions are
required. I guess that is why people are recommending embedded code
copies. Personally I recommend packaging those versions separately, as
we do for GCC or Python itself.

https://wiki.debian.org/EmbeddedCodeCopies

> I've talked to upstream about the files, and some will be removed in the
> new release, like the binary translation files. Others need to be
> there to make it easy for people installing via pip or a git checkout,
> like the javascript.

Thanks. Hmm, ok.

> That's a good idea, although the version in README.Debian is closer to
> an example of one possible setup, rather than a suggested way of running
> it. I'm still thinking about the best way of doing this. I'm assuming
> it's not a blocking issue for package upload?

Not a blocking issue.

> I tried doing this, but the script won't even succeed showing help
> output when run without mediagoblin/tools/common.py somewhere on the
> python path. I'm not sure if it's a good idea to modify the python path
> during build.

It would be fine to set/modify PYTHONPATH for the manual page build
command, probably not other stuff though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#785198: transition: GStreamer 0.10 removal

[Emilio Pozuelo Monfort]

Hi Sebastian,

On 13/05/15 13:09, Sebastian Dröge wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> see rationale in this mailing list thread:
> https://lists.debian.org/debian-devel/2015/05/msg00335.html
> 
> It was suggested in that thread to also set up a transition tracker for
> this. The main package involved here would be libgstreamer0.10-0, which
> should go away and has libgstreamer1.0-0 as replacement already.
> 
> The qt-gstreamer transition (#760003) already clears part of the
> remaining GStreamer 0.10 dependencies. Additionally there are further
> GStreamer 0.10 bindings:
> 
> python-gst0.10 is replaced by python-gst1.0 / python3-gst1.0
> 
> libgstreamer0.9-cil is replaced by libgstreamer1.0-cil
>   (which is not yet uploaded, upstream release exists)
> 
> libgstreamermm-0.10-2 would be replaced by libgstreamermm-1.0-XXX
>   (which is also not yet uploaded, upstream release exists)
> 
> libgstreamer-perl, haskell-gstreamer
>   I'm not aware what the plans there are, the latter also has nothing
>   depending on it.

I don't want to have hundreds of RC bugs just for this. You can file bugs at say
important severity though, and when the list of rdeps gets down significantly,
they can be raised to serious. Also sending a dd-list to debian-devel can be 
useful.

Cheers,
Emilio


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

Bug#785198: transition: GStreamer 0.10 removal

[Emilio Pozuelo Monfort]

Hi Sebastian,

On 13/05/15 13:09, Sebastian Dröge wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> see rationale in this mailing list thread:
> https://lists.debian.org/debian-devel/2015/05/msg00335.html
> 
> It was suggested in that thread to also set up a transition tracker for
> this. The main package involved here would be libgstreamer0.10-0, which
> should go away and has libgstreamer1.0-0 as replacement already.
> 
> The qt-gstreamer transition (#760003) already clears part of the
> remaining GStreamer 0.10 dependencies. Additionally there are further
> GStreamer 0.10 bindings:
> 
> python-gst0.10 is replaced by python-gst1.0 / python3-gst1.0
> 
> libgstreamer0.9-cil is replaced by libgstreamer1.0-cil
>   (which is not yet uploaded, upstream release exists)
> 
> libgstreamermm-0.10-2 would be replaced by libgstreamermm-1.0-XXX
>   (which is also not yet uploaded, upstream release exists)
> 
> libgstreamer-perl, haskell-gstreamer
>   I'm not aware what the plans there are, the latter also has nothing
>   depending on it.

I don't want to have hundreds of RC bugs just for this. You can file bugs at say
important severity though, and when the list of rdeps gets down significantly,
they can be raised to serious. Also sending a dd-list to debian-devel can be 
useful.

Cheers,
Emilio


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

Bug#785430: RM: clutter-gst -- ROM; superseded by clutter-gst-2.0

[Emilio Pozuelo Monfort]

Package: ftp.debian.org
Severity: normal

Please remove clutter-gst. It is old and superseded by clutter-gst-2.0.

There is one rdep. I'm filing a bug and will make it block this.

Emilio


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

Bug#725303: Please port to clutter-gst 2.0

[Emilio Pozuelo Monfort]

Control: block 785430 by -1
Control: severity -1 serious

On Thu, 03 Oct 2013 22:55:11 +0200 Michael Biebl  wrote:
> libclutter-gst-1.0-0 has been deprecated and we'd like to remove it from
> the archive.
> 
> Please port snappy to libclutter-gst-2.0-0

This is the last rdep. I've requested the removal of clutter-gst, so please port
this to clutter-gst-2.0.

Thanks,
Emilio


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

Bug#785432: quodlibet: gstreamer1.0-pulseaudio must be installed

[Romain Vimont]

Package: quodlibet
Version: 3.2.2-1
Severity: important

Dear Maintainer,

On a fresh Debian Jessie with XFCE, quodlibet is installed but the sound
does not work (while it works in VLC for instance):

$ quodlibet
0:00:00.913873828  6629  0x1581010 ERROR jackclient
gstjackaudioclient.c:35:jack_log_error: Cannot connect to server socket
err = No such file or directory

Installing gstreamer1.0-pulseaudio solves the problem.

$ apt-cache show quodlibet | grep ^Depends:
Depends: python (>= 2.7.3-4+deb7u1), exfalso (= 3.2.2-1),
gir1.2-gstreamer-1.0, gir1.2-gst-plugins-base-1.0,
gstreamer1.0-plugins-base, gstreamer1.0-plugins-good,
gstreamer1.0-plugins-ugly, gstreamer1.0-pulseaudio |
gstreamer1.0-audiosink

$ apt-cache showpkg gstreamer1.0-audiosink |
sed -n '/Reverse Provides/,$p'
Reverse Provides: 
gstreamer1.0-pulseaudio 1.4.4-2
gstreamer1.0-plugins-good 1.4.4-2
gstreamer1.0-alsa 1.4.4-2
gstreamer1.0-plugins-bad 1.4.4-2.1+b1

My guess is that since gstreamer1.0-plugins-good is installed, quodlibet
does not install gstreamer1.0-pulseaudio.

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

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

Versions of packages quodlibet depends on:
ii  exfalso 3.2.2-1
ii  gir1.2-gst-plugins-base-1.0 1.4.4-2
ii  gir1.2-gstreamer-1.01.4.4-2
ii  gstreamer1.0-plugins-base   1.4.4-2
ii  gstreamer1.0-plugins-good [gstreamer1.0-audiosink]  1.4.4-2
ii  gstreamer1.0-plugins-ugly   1.4.4-2+b1
ii  gstreamer1.0-pulseaudio [gstreamer1.0-audiosink]1.4.4-2
ii  python  2.7.9-1

Versions of packages quodlibet recommends:
ii  gir1.2-gtksource-3.0 3.14.1-1
ii  gir1.2-keybinder-3.0 0.3.0-1
ii  libgpod4 0.8.3-1.1+b1
ii  media-player-info22-2
ii  notification-daemon  0.7.6-2
ii  python-dbus  1.2.0-2+b3
ii  python-feedparser5.1.3-3
ii  python-pyinotify 0.9.4-1
ii  udisks2  2.1.3-5
ii  xfce4-notifyd [notification-daemon]  0.2.4-3

Versions of packages quodlibet suggests:
pn  gstreamer1.0-plugins-bad  

-- 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#711108: linux-image-* should suggest linux-tools-*

[Piotr Engelking]

tags 711108 + patch
thanks

Untested patch attached.

It may also be interesting to notice that apt already attempts to
prevent automatic removal of linux-tools matching an installed kernel,
but fails, since it assumes a version format which is no longer in use:

  /etc/kernel/postinst.d/apt-auto-removal
  /etc/apt/apt.conf.d/01autoremove

On 4 June 2013 at 21:03, Ben Hutchings  wrote:
> On Tue, Jun 04, 2013 at 08:46:50PM +0200, Piotr Engelking wrote:
>> Source: linux
>> Severity: wishlist
>>
>> Please consider having the linux-image-${version}-* packages suggesting
>> the matching linux-tools-${version} package. This would help users to keep
>> them in sync.
>
> It might be a useful hint.  However the linux-tools meta-package is
> a more effective way to keep linux-tools-* up to date (unless you
> install the kernel from experimental).
>
> Ben.
>
> --
> Ben Hutchings
> We get into the habit of living before acquiring the habit of thinking.
>   - Albert Camus
diff --git a/debian/templates/control.image.type-plain.in b/debian/templates/control.image.type-plain.in
index 29306e3..0c29b32 100644
--- a/debian/templates/control.image.type-plain.in
+++ b/debian/templates/control.image.type-plain.in
@@ -3,7 +3,7 @@ Provides: linux-modules-@abiname@@localversion@
 Pre-Depends: debconf | debconf-2.0
 Depends: kmod | module-init-tools, linux-base (>= 3~), ${misc:Depends}
 Recommends: firmware-linux-free (>= 3~), ${kernel:Recommends}
-Suggests: linux-doc-@version@, debian-kernel-handbook
+Suggests: linux-tools-@version@, linux-doc-@version@, debian-kernel-handbook
 Breaks: at (<< 3.1.12-1+squeeze1)
 Description: Linux @upstreamversion@ for @class@
  The Linux kernel @upstreamversion@ and modules for use on @longclass@.

Bug#785198: transition: GStreamer 0.10 removal

[Sebastian Dröge]

On Sa, 2015-05-16 at 09:31 +0200, Emilio Pozuelo Monfort wrote:
> Hi Sebastian,
> 
> On 13/05/15 13:09, Sebastian Dröge wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Hi,
> > 
> > see rationale in this mailing list thread:
> > https://lists.debian.org/debian-devel/2015/05/msg00335.html
> > 
> > It was suggested in that thread to also set up a transition tracker for
> > this. The main package involved here would be libgstreamer0.10-0, which
> > should go away and has libgstreamer1.0-0 as replacement already.
> > 
> > The qt-gstreamer transition (#760003) already clears part of the
> > remaining GStreamer 0.10 dependencies. Additionally there are further
> > GStreamer 0.10 bindings:
> > 
> > python-gst0.10 is replaced by python-gst1.0 / python3-gst1.0
> > 
> > libgstreamer0.9-cil is replaced by libgstreamer1.0-cil
> >   (which is not yet uploaded, upstream release exists)
> > 
> > libgstreamermm-0.10-2 would be replaced by libgstreamermm-1.0-XXX
> >   (which is also not yet uploaded, upstream release exists)
> > 
> > libgstreamer-perl, haskell-gstreamer
> >   I'm not aware what the plans there are, the latter also has nothing
> >   depending on it.
> 
> I don't want to have hundreds of RC bugs just for this. You can file bugs at 
> say
> important severity though, and when the list of rdeps gets down significantly,
> they can be raised to serious. Also sending a dd-list to debian-devel can be 
> useful.

I'll send a follow-up with dd-list to debian-devel later.

As nobody did any porting of any of these packages over the last 3
years, I doubt that any porting will happen just because I file non-RC
bugs for them :) But if you prefer that, I'm going to just file bugs
with important severity. Not sure if I should also orphan the GStreamer
0.10 packages on the next uploads, might be the most sensible thing to
do though.


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

Bug#784009: want to back out to get wget working again

[積丹尼 Dan Jacobson]

OK thanks. This worked, /var/log/aptitude:
[REMOVE, NOT USED] libhogweed3:i386
[REMOVE, NOT USED] libnettle5:i386
[DOWNGRADE] libgnutls-deb0-28:i386 3.3.15-3 -> 3.3.15-2
[DOWNGRADE] libgnutls-openssl27:i386 3.3.15-3 -> 3.3.15-2


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

Bug#784005: postgresql-9.4: Cluster upgrade from 9.1 to 9.4 results in broken configuration

[Christoph Berg]

Re: Gunnar Wolf 2015-05-15 <20150515035332.ga62...@gwolf.org>
> Christoph Berg dijo [Thu, May 14, 2015 at 10:11:44PM +0200]:
> > Hi Gunnar,
> > 
> > I'd call it a LXC bug if it doesn't support POSIX shared memory.
> > That said, I've been bitten by this problem as well - in my case,
> > /dev/shm was simply not mounted and a cluster with no explicit
> > dynamic_shared_memory_type setting defaulted to "posix" didn't start.
> > If you create a new cluster in such an environment, initdb will probe
> > the various shared memory types and pick one that works. I'm not
> > really happy with this auto-probing because it hides the real problem,
> > but atm that's what upstream has designed.
> > 
> > We'll document the gotcha in README.Debian.
> 
> Hi!
> 
> I asked a PostgreSQL developer friend of mine, and he answered (in
> Spanish, translation bugs are mine):
> 
> Hmm, if I understand correctly, the problem is that the
> postgresql.conf is copied from the old server to the new one,
> right? I think that, by itself, is a bug... The configuration
> files are attempted to be kept reasonably compatible, but there is
> no promise that it will always work.

Hi Gunnar,

of course pg_upgrade takes care of upgrading any non-compatible old
settings to new ones (or removing them).

> Particularly, with parameters such as the shared memory type,
> initdb should take care of setting the right values.
> 
> I think it's a pg_upgradecluster bug (which is part of the Debian
> packaging, not of Postgres)

After sleeping over it, I think we should indeed make
pg_upgradecluster add some dynamic_shared_memory_type parameter to the
old config file.

Fwiw, the first complaints about the upstream part of the problem are
from exactly one year ago...

http://www.postgresql.org/message-id/CAOtHd0A5KQHL5Zv9V0c9i98i7otuwOhk=pm3grxuugh4tr3...@mail.gmail.com

> I guess LXC does provide shared memory, but it might be that my
> configuration does not allow it. I am newbie-ish on its specifics.

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


signature.asc
Description: Digital signature

Bug#772138: sngrep in Debian

[Victor Seva]

Hi Ivan,

I would like to see sngrep entering Debian repositories. I saw that
you're still looking for a sponsor for it [1]. Are you willing to
maintain it under the Debian pkg-voip [0] umbrella?


Cheers,
Victor

[0] https://wiki.debian.org/Teams/VoIP
[1] http://mentors.debian.net/package/sngrep




signature.asc
Description: OpenPGP digital signature

Bug#785405: closed by Don Armstrong (reply to ow...@bugs.debian.org) (Re: Bug#785405: bugs.debian.org: SOAP interface often fails with error message about undefined value as a subrou

[Francesco Poli]

On Fri, 15 May 2015 16:22:37 -0700 Don Armstrong wrote:

[...]
> Figured this out; basically, the new version of SOAP::Lite changed how
> they were doing the ordering (probably for the better) and broke my
> hack.
> 
> I fixed up the hack to just work, though I should probably check to make
> sure if it's even still necessary

Great job, thanks a lot!
I confirm that the issue seems to have disappeared.

Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp57Ww660_vA.pgp
Description: PGP signature

Bug#784732: RFS: liquidprompt/1.9-1 [ITP]

[Vincent Cheng]

Control: tag -1 + moreinfo
Control: owner -1 !

Hi Arturo,

On Fri, May 8, 2015 at 1:08 AM, Arturo Borrero Gonzalez
 wrote:
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "liquidprompt"
>
> * Package name: liquidprompt
> * Version : 1.9
> * Upstream Author : Nojhan 
> * URL : https://github.com/nojhan/liquidprompt
> * License : AGPL-3
> * Programming Lang: shell
> * Section : misc
>
> It builds those binary packages:
>  liquidprompt - adaptative prompt for bash & zsh
>
> To access further information about this package, please visit the
> following URL:
>  http://mentors.debian.net/package/liquidprompt
>
> Alternatively, one can download the package with dget using this command:
>  dget -x 
> http://mentors.debian.net/debian/pool/main/l/liquidprompt/liquidprompt_1.9-1.dsc
>
> More information about hello can be obtained from
> https://github.com/nojhan/liquidprompt.

Just a few more things to add to Andrey's earlier review:

- Don't hardcode a reference to $HOME/.config in
liquidprompt_activate, use $XDG_CONFIG_HOME instead [1].
- If your package is covered by a license that does not have the full
text stored in /usr/share/common-licenses, you should include the full
text yourself in d/copyright.

I also share Andrey's concern about the multiple invocations of
liquidprompt_activate polluting bashrc/zshrc, although I don't
consider that a blocker for an upload.

Regards,
Vincent

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html


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

Bug#785433: grub2-common: Boot failure if GRUB_SERIAL_COMMAND includes --speed=0

[Jan Ceuleers]

Package: grub2-common
Version: 2.02~beta2-22
Severity: minor

Dear Maintainer,

After upgrading a Wheezy system to Jessie it fails to boot. Symptom is that
as soon as the BIOS hands over control to the boot loader it restarts without
screen output that I can see.

Eyeballing /etc/default/grub revealed that the GRUB_SERIAL_COMMAND line included
--speed=0, which is an error, but which worked OK with the Wheezy version of
grub (at least in that it did not prevent the boot).

So I would understand if you decide not to fix this, in which case the added
value of this report is that it will hopefully help others to fix their
systems if they happen to run into this as well.

So the fix I applied was to change the --speed parameter to 9600 and now the
system boots.


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda1 / ext4 rw,noatime,nodiratime,errors=remount-ro,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-QEMU_HARDDISK_QM1
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal_input serial
terminal_output serial
if [ "${recordfail}" = 1 ] ; then
  set timeout=-1
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-1ce6e006-e67c-4b1e-89e7-a0885d16b2a2' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  
1ce6e006-e67c-4b1e-89e7-a0885d16b2a2
else
  search --no-floppy --fs-uuid --set=root 
1ce6e006-e67c-4b1e-89e7-a0885d16b2a2
fi
echo'Loading Linux 3.16.0-4-586 ...'
linux   /boot/vmlinuz-3.16.0-4-586 
root=UUID=1ce6e006-e67c-4b1e-89e7-a0885d16b2a2 ro console=ttyS0,9600n8 
ipv6.disable=1 quiet
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-3.16.0-4-586
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-1ce6e006-e67c-4b1e-89e7-a0885d16b2a2' {
menuentry 'Debian GNU/Linux, with Linux 3.16.0-4-586' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-3.16.0-4-586-advanced-1ce6e006-e67c-4b1e-89e7-a0885d16b2a2' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 
--hint='hd0,msdos1'  1ce6e006-e67c-4b1e-89e7-a0885d16b2a2
else
  search --no-floppy --fs-uuid --set=root 
1ce6e006-e67c-4b1e-89e7-a0885d16b2a2
fi
echo'Loading Linux 3.16.0-4-586 ...'
linux   /boot/vmlinuz-3.16.0-4-586 
root

Bug#749288: raspbian support patch provided is too complicated for me to port to libv8 3.28

[Jérémy Lal]

Hi,

i'm working on updating libv8 to 3.28 (see collab-maint), and unfortunately
this patch
isn't obvious at all to adapt to that new version.

You might want to submit a new patch, hence this notification.

Jérémy.

Bug#785434: please document --tab option

[Tomas Pospisek]

Package: pavucontrol
Version: 2.0-3
Severity: wishlist
Tags: patch

Hello pavucontrol maintainers!

could you please apply the following patch before your next upload?


--- pavucontrol.1.txt.orig  2015-05-16 10:22:59.964031775 +0200
+++ pavucontrol.1.txt   2015-05-16 10:34:19.812034169 +0200
@@ -23,7 +23,8 @@
 
 Options
 ---
-_pavucontrol_ does not accept any options.
+*-t, --tab* 'NUMBER'::
+Select tab 'NUMBER' on load
 
 
 See Also


I use that option to always open pavucontrol on the 'Output' tab when
launching pavucontrol from my GUI dock, since what I need most often
to do with pavucontrol is to tune the volume...

Thanks a lot to you all for maintaining pavucontrol!
*t

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

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

Versions of packages pavucontrol depends on:
ii  libatk1.0-0  2.14.0-1
ii  libatkmm-1.6-1   2.22.7-2.1
ii  libc62.19-18
ii  libcairo-gobject21.14.0-2.1
ii  libcairo21.14.0-2.1
ii  libcairomm-1.0-1 1.10.0-1.1
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libgcc1  1:4.9.2-10
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libglib2.0-0 2.42.1-1
ii  libglibmm-2.4-1c2a   2.42.0-1
ii  libgtk-3-0   3.14.5-1
ii  libgtkmm-3.0-1   3.14.0-1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangomm-1.4-1 2.34.0-1.1
ii  libpulse-mainloop-glib0  5.0-13
ii  libpulse05.0-13
ii  libsigc++-2.0-0c2a   2.4.0-1
ii  libstdc++6   4.9.2-10
ii  libx11-6 2:1.6.2-3

Versions of packages pavucontrol recommends:
ii  pulseaudio  5.0-13

pavucontrol 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#783529: RFS: spacenavd/0.6-1 [ITA]

[Vincent Cheng]

Control: tag -1 + moreinfo
Control: owner -1 !

Hi Rodolphe,

On Mon, Apr 27, 2015 at 11:10 AM, Rodolphe PELLOUX-PRAYER
 wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
>   I am looking for a sponsor for my package "spacenavd"
>
>  * Package name: spacenavd
>Version : 0.6-1
>Upstream Author : John Tsiombikas 
>  * URL : http://spacenav.sourceforge.net
>  * License : GPL-3.0+
>Section : utils
>
>   It builds those binary packages:
>
> spacenavd  - daemon for using 3D input devices from 3Dconnexion
>
>   To access further information about this package, please visit the 
> following URL:
>
>   http://mentors.debian.net/package/spacenavd
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x 
> http://mentors.debian.net/debian/pool/main/s/spacenavd/spacenavd_0.6-1.dsc
>
>   Changes since the last upload:
>   * Imported Upstream version 0.6
>   * Remove initfile patch. We use debian/spacenavd.init anyway.
>   * Remove makefile patch and change spacenavd path in init file.
>   * Use DEP-5 copyright format.
>   * Add upstream example config file.
>   * Source init-functions in init script.
>   * Bump standards version to 3.9.6 and remove obsolete DM-Upload-Allowed 
> field.
>   * Switch to debhelper > 9.
>   * Remove quilt and autotools-dev dependencies.
>   * Set architecture linux-any. Closes: #745177.
>   * Enable systemd service file.
>   * Patch to use /run instead of /var/run.
>   * Enable hardenings flags.
>   * New maintainer. Closes: #781184.
>   * Add Vcs-* fields.
>

debian/copyright is missing a few entries:
- src/serial/*: Copyright 1997-2001 John E. Stone (j.st...@acm.org),
3-clause BSD (+ upstream author)

debian/stamp-patched is useless and can be removed.

debian/patches/run.patch is rather redundant; /var/run is not going to
be removed from Debian in the foreseeable future and will likely be
kept around for compatibility reasons for a long time. If you do
decide to keep it though, please look into adding DEP-3 [1] headers
for it (and any future patch you add).

Your package isn't actually hardened. "export DEB_BUILD_MAINT_OPTIONS
= hardening=+all" in d/rules isn't going to do anything if your
package's build system ignores the hardening flags set by
dpkg-buildflags.

Regards,
Vincent

[1] http://dep.debian.net/deps/dep3/


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

Bug#785435: init: touch not found

[積丹尼 Dan Jacobson]

Package: initramfs-tools
Version: 0.120
Severity: wishlist

I swear I saw something about init: touch not found fly past on my
screen, but I have no log file to prove it.

I wish there was a log file.


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

Bug#768983: [Pkg-graphite-maint] ITP: carbon-c-relay -- status?

[Filippo Giunchedi]

On Wed, May 13, 2015 at 09:43:30PM +0200, Jonas Genannt wrote:
> > Happy to hear other opinions if people are interested since it is just 
> > harder
> > to transition after the upload. (+Jonas and pkg-graphite-maint)
> 
> I would also suggest to use a other configuration directory. because 
> /etc/carbon can be
> have more configuration files:

ok I've switched back to /etc/carbon-c-relay.conf in 7f6bed754f
Bernd if that looks good I think we're fine to upload

> @Filippo: thanks for doing the work of carbon-c :)

you are welcome! we needed it anyway at wikimedia :)

filippo
-- 
http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵


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

Bug#785436: apparmor: Should apparmor have a versioned dependency for python3-apparmor?

[u]

Package: apparmor
Version: 2.9.2-3
Severity: minor

Here is my initial bug report:
https://bugs.launchpad.net/apparmor/+bug/1455236
I installed the latest version of apparmor from sid and was wondering if
there shouldn't be a versioned dependency for python3-apparmor, as the
Jessie version does not function with the latest apparmor version (2.9.2).

But maybe i should have installed both manually, simply. In that case
please close this bug :)

Thanks!


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

Bug#784565: [pkg-x2go-devel] Bug#784565: Bug#784565: nx-libs-lite: parts are derived from non-free code

[Mike Gabriel]

Hi all, esp. Kevin,

On  Do 14 Mai 2015 06:58:09 CEST, Mike Gabriel wrote:

I looked at dxpc releases (I obtained upstream tarballs from  
snapshot.debian.org).


I currently have:

"""
[mike@minobo dxpc.nxrebase (upstream-nxrebase)]$ git log
commit 0676a768a96383641a73a72ecd2e1083322e6abe
Author: Mike Gabriel 
Date:   Sat May 16 10:52:24 2015 +0200

Imported Upstream version 3.9.2

commit 4ccf34b2c4763dfb01dceb8588b204b0d029cc3d
Author: Mike Gabriel 
Date:   Sat May 16 10:51:04 2015 +0200

Imported Upstream version 3.9.1

commit dd8f60ce63c70ed605a2e1717feb7128e59fb8e6
Author: Mike Gabriel 
Date:   Sat May 16 10:49:19 2015 +0200

Imported Upstream version 3.9.0

commit 01c990099aea802405f8d39c0b819ee1742c185c
Author: Mike Gabriel 
Date:   Sat May 16 10:32:06 2015 +0200

Imported Upstream version 3.8.2

commit 48df60b3b946a08541ee48371634f074e875adda
Author: Mike Gabriel 
Date:   Sat May 16 10:31:57 2015 +0200

Imported Upstream version 3.8.0

commit 11d81444d0f86a67f9b8483cbfa33343714b26e9
Author: Mike Gabriel 
Date:   Sat May 16 10:31:53 2015 +0200

Imported Upstream version 3.7.0

commit e4f550abd4cd49ecc2381e717a55a9940087a376
Author: Mike Gabriel 
Date:   Sat May 16 10:31:44 2015 +0200

Imported Upstream version 3.5.0
"""

@Kevin: I will take you off this mail thread's Cc: field with my  
next post. Feel free to follow-up via #784565 [1] on the Debian bug  
tracker. Thanks a lot for being so responsive and generous with  
providing information.


With this post I actually reincluded you because it becomes technical  
from here on and I probably will need your expertise on DXPC. Not sure  
if you have time or prio or are willing to provide that. Would you be  
open for answering technical questions on DXPC and esp. the changes  
between 3.7.0 and 3.8.1/3.8.2? I'd highly appreciate that.


As I have not heard back neither from Brian Pane, Zachary Vonler nor  
Gian Filippo Pinzari (we had Ascension Day and maybe a prolonged  
weekend that people used for going on VAC), I will try looking at the  
DXPC changes between 3.7.0 and 3.8.1. Obviously, NoMachine forked  
NXCOMP from DXPC some time between DXPC 3.7.0 and DXPC 3.8.0.


Questions to Kevin:

  o Is there any SVN upstream repo still online
(I saw it in one of the tarballs, that SVN was
used for 3.9.0).
  o Do you have any tarballs documenting the
changes between 3.7.0 and 3.8.0? Do you also
have the 3.8.1 tarball?
  o Did the 3.8.0 version of DXPC break proto
compatibility (i.e., you could not use client
3.7.0 and server 3.8.0 and vice versa with
each other)?

Any help on this is appreciated. Thanks.

Mike


--

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

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

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


pgpDTIh1qhnIl.pgp
Description: Digitale PGP-Signatur

Bug#785198: transition: GStreamer 0.10 removal

[Emilio Pozuelo Monfort]

On 16/05/15 09:50, Sebastian Dröge wrote:
> On Sa, 2015-05-16 at 09:31 +0200, Emilio Pozuelo Monfort wrote:
>> Hi Sebastian,
>>
>> On 13/05/15 13:09, Sebastian Dröge wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>>
>>> Hi,
>>>
>>> see rationale in this mailing list thread:
>>> https://lists.debian.org/debian-devel/2015/05/msg00335.html
>>>
>>> It was suggested in that thread to also set up a transition tracker for
>>> this. The main package involved here would be libgstreamer0.10-0, which
>>> should go away and has libgstreamer1.0-0 as replacement already.
>>>
>>> The qt-gstreamer transition (#760003) already clears part of the
>>> remaining GStreamer 0.10 dependencies. Additionally there are further
>>> GStreamer 0.10 bindings:
>>>
>>> python-gst0.10 is replaced by python-gst1.0 / python3-gst1.0
>>>
>>> libgstreamer0.9-cil is replaced by libgstreamer1.0-cil
>>>   (which is not yet uploaded, upstream release exists)
>>>
>>> libgstreamermm-0.10-2 would be replaced by libgstreamermm-1.0-XXX
>>>   (which is also not yet uploaded, upstream release exists)
>>>
>>> libgstreamer-perl, haskell-gstreamer
>>>   I'm not aware what the plans there are, the latter also has nothing
>>>   depending on it.
>>
>> I don't want to have hundreds of RC bugs just for this. You can file bugs at 
>> say
>> important severity though, and when the list of rdeps gets down 
>> significantly,
>> they can be raised to serious. Also sending a dd-list to debian-devel can be 
>> useful.
> 
> I'll send a follow-up with dd-list to debian-devel later.
> 
> As nobody did any porting of any of these packages over the last 3
> years, I doubt that any porting will happen just because I file non-RC
> bugs for them :) But if you prefer that, I'm going to just file bugs
> with important severity.

You can warn that the goal is to remove gst 0.10 before the Stretch release and
that if $package isn't ported, it is very likely to be removed from testing and
not be included in Stretch.

Also please usertag them so it's easy to track progress.

> Not sure if I should also orphan the GStreamer
> 0.10 packages on the next uploads, might be the most sensible thing to
> do though.

Your call.

Cheers,
Emilio


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

Bug#785437: packagekit: Offline update notification not dismissed

[Daniel Goß]

Package: gnome-settings-daemon
Version: 3.14.2-3
Severity: normal

After installing an offline update via the gpk-update-viewer the success 
notification is shown on ever reboot. When clicking the OK-button of the 
notification message the following error message is logged:
gnome-session[978]: Error accessing 
/usr/lib/gnome-settings-daemon/pk-clear-offline-update: No such file or 
directory

The file /var/lib/PackageKit/offline-update-completed is not removed.

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

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

Versions of packages gnome-settings-daemon depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  gsettings-desktop-schemas3.14.1-1
ii  libc62.19-18
ii  libcairo21.14.0-2.1
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libcolord2   1.2.1-1+b2
ii  libcups2 1.7.5-11
ii  libfontconfig1   2.11.0-6.3
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libgeocode-glib0 3.14.0-1
ii  libglib2.0-0 2.44.0-2
ii  libgnome-desktop-3-103.14.1-1
ii  libgtk-3-0   3.14.5-1
ii  libgudev-1.0-0   215-17
ii  libgweather-3-6  3.14.1-1
ii  liblcms2-2   2.6-3+b3
ii  libnm-glib4  1.0.2-2
ii  libnm-util2  1.0.2-2
ii  libnotify4   0.7.6-2
ii  libnspr4 2:4.10.8-1
ii  libnss3  2:3.17.2-1.1
ii  libpackagekit-glib2-18   1.0.1-2
ii  libpam-systemd   215-17
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpolkit-gobject-1-00.105-8
ii  libpulse-mainloop-glib0  6.0-2
ii  libpulse06.0-2
ii  librsvg2-2   2.40.5-1
ii  libupower-glib3  0.99.2-3
ii  libwacom20.8-1
ii  libwayland-client0   1.6.0-2
ii  libx11-6 2:1.6.3-1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.1-2+b2
ii  libxi6   2:1.7.4-1+b2
ii  libxtst6 2:1.2.2-1+b1
ii  nautilus-data3.14.1-2

Versions of packages gnome-settings-daemon recommends:
ii  pulseaudio  6.0-2

Versions of packages gnome-settings-daemon suggests:
pn  gnome-screensaver
ii  metacity [x-window-manager]  1:3.14.3-1
ii  mutter [x-window-manager]3.14.4-2
ii  x11-xserver-utils7.7+4

-- no debconf information


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

Bug#780224: imagemagick: compare no longer terminates output with \n

[Bastien ROUCARIES]

control: tags -1 + wontfix
control: tags -1 + patch
control: retitle -1 [wontfix][workarround] change of behovior compare
no longer terminates output with \n

At some point, the developers decided that the default output of the
command line tools would be for consumption by other programs or
scripts-- and any command with the -verbose option would be for human
consumption. As a result, non-verbose command-line program output does
not include a newline. For the -format option, you can insert a
newline with \n but unfortunately you cannot with the compare program
other than returning verbose info.

As a workarround if you want an added newline, you can have it:
compare -format "\n" -metric RMSE rose: rose: NULL

Bastien


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

Bug#785438: RM: libepc -- ROM; unused, unmaintained upstream

[Emilio Pozuelo Monfort]

Package: ftp.debian.org
Severity: normal

libepc no longer has any rdeps. Since it is dead upstream, there's no
point in us shipping it anymore. Please remove it.

Emilio


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

Bug#772138: ITP: sngrep -- Ncurses SIP Messages flow viewer

[Victor Seva]

Hi,

I've created [0] the git repo and commit some changes in order to get
sngrep built.


Cheers,
Victor

[0] http://anonscm.debian.org/cgit/pkg-voip/sngrep.git/



signature.asc
Description: OpenPGP digital signature

Bug#781782: iceweasel crashes when trying to go to https://mentors.debian.net/python-wget

[Jérémy Bobbio]

Control: tag 781782 + confirmed forwaded-upstream

Axel Beckert:
> shirish शिरीष wrote:
> > Iceweasel crashed when I clicked on
> > https://mentors.debian.net/package/python-wget as shared at
> > https://lists.debian.org/debian-python/2015/04/msg2.html .
> 
> I can confirm that. For me, conkeror using iceweasel 37.0.1-1 as
> application engine crashes upon accessing
> https://mentors.debian.net/package/klatexformula for one or two weeks,
> too. Had to view that page in a different browser instead.

Thank you both for the report. I have successfully reproduced the issue
with Iceweasel 38 and HTTPS Everywhere 5.0.4. I've pointed upstream at
the issue and hope they'll figure it out.

In the meantime, you can select “Enable / disable rules” in the HTTPS
Everywhere menu and disable the “Debian (self-signed)” ruleset.

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


signature.asc
Description: Digital signature

Bug#785436: [pkg-apparmor] Bug#785436: apparmor: Should apparmor have a versioned dependency for python3-apparmor?

[intrigeri]

Control: severity -1 important

Hi,

u wrote (16 May 2015 09:07:12 GMT) :
> Here is my initial bug report:
> https://bugs.launchpad.net/apparmor/+bug/1455236
> I installed the latest version of apparmor from sid and was wondering if
> there shouldn't be a versioned dependency for python3-apparmor, as the
> Jessie version does not function with the latest apparmor version (2.9.2).

Thanks! Too bad we're realizing now that your 2.9.2 testing feedback
wasn't actually about the full 2.9.2 stack, but that's my fault :)

> But maybe i should have installed both manually, simply. In that case
> please close this bug :)

Debian kinda supports partial upgrades, so this needs to be fixed.
Also, I believe the lack of this versioned dependency is violating
policy somehow, so raising severity.

Cheers,
-- 
intrigeri


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

Bug#785393: gramps: crash after closing detached gramplet

[Ross Gammon]

Control: severity important
Control: tags -1 confirmed upstream fixed-upstream pending

Hi,

I can confirm this for Gramps 4.1.1 in Jessie. I can also confirm that
the version of Gramps that I am about to upload to unstable (4.1.3)
contains a fix for it.

The upstream bug was:
https://gramps-project.org/bugs/view.php?id=7865

The commit that fixed it looks pretty simple, so I will ask the
stable-release team if they would accept a patch.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#763799: move to texlive-latex-base

[Bastien ROUCARIES]

control: retitle -1 jpegs created by imagemagick cannot be used by
latex (overflow in graphics package?)
control: affects -1 src:imagemagick
control: notforwarded -1

Dear texlive maintainer,

It seems that graphics package overflow with perfectly valid jpeg
image. It seems also we need to set resolution of about 75dpi. If we
use a 1 dpi resolution (perfectly valid) we get:

pdfTeX warning: pdflatex: arithmetic: number too big

! Package graphics Error: Division by 0.
See the graphics package documentation for explanation.
Type  H   for immediate help.
 ...
l.4 ...theight,keepaspectratio]{test_gradient.jpg}


Could you get a glimpse ?

Morevover could you also not close this bug because it need to be in
debian bts in order to keep affects imagemagick, for avoiding spurious
bug report in imagemagick

Thank you

Bastien


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

Bug#785439: screenlets: recommends python-gmenu which is about to be removed

[Emilio Pozuelo Monfort]

Source: screenlets
Version: 0.1.2-8
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gnome-menus2

Your package recommends python-gmenu which we plan to remove RSN.

You should use gir1.2-gmenu-3.0. See this if you don't know about
gir (GObject Introspection):

https://wiki.gnome.org/action/show/Projects/GObjectIntrospection
https://wiki.gnome.org/action/show/Projects/PyGObject


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

Bug#785440: RM: gnome-menus2 -- ROM; unmaintained, obsoleted by gnome-menus

[Emilio Pozuelo Monfort]

Package: ftp.debian.org
Severity: normal
Control: block -1 by 785439

Hi,

Please remove gnome-menus2. It is long obsoleted by gnome-menus. I have
opened a bug screenlets, but that only recommends python-gmenu so it should
not be a blocker.

Thanks,
Emilio


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

Bug#785441: Support maintainer name and email address

[Viktor Szepe]

Package: checkinstall
Version: 1.6.2-4
Severity: important
Tags: patch

MAINTAINER="`eval "echo '$1'"`"

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

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

Versions of packages checkinstall depends on:
ii  dpkg-dev  1.17.25
ii  file  1:5.22+15-2
ii  libc6 2.19-18

Versions of packages checkinstall recommends:
ii  make  4.0-8.1

Versions of packages checkinstall suggests:
ii  gettext  0.19.3-2

-- no debconf information


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

Bug#780793: RFS: hovercraft/2.0~b1+dfsg-1 [ITP] --- impress.js presentations by reStructuredText

[Daniel Stender]

I've injected Hovercraft to the group's SVN repo [1] now. It'll
take part in the upcoming svn-git migration procedure then and will
find itself in the proper git repo automatically.

DS

[1] svn+ssh://lo...@svn.debian.org/svn/python-apps/packages/hovercraft

-- 
http://qa.debian.org/developer.php?login=debian%40danielstender.com
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8


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

Bug#774498: closed by Santiago Vila (Bug#774498: fixed in base-files 9.1)

[Santiago Vila]

On Sat, May 16, 2015 at 12:38:50AM +0200, Jérémy Bobbio wrote:
> Sorry but since we are now testing umask variations as well, the new
> version is not considered reproducible. The attached patch will fix the
> issue.

Oh my FSM. This is the neverending story. I am really considering
switching all my packages to dh, but in this case:

Is there a reason why a standard, sane umask can't be set by
dpkg-buildpackage and be part of what a package may take it for granted?


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

Bug#785442: DKMS build fails at linux-4.0.0

[Robert Schmitz]

Package: nvidia-legacy-304xx-kernel-dkms
Version: 304.125-1
Severity: important

Hello,

I found out that updating to kernel version 4.0.0 breaks the nvidia legacy
module. The dkms build fails, possibly because deprecated structures in the
code.

Thanks,
Robert


*** /var/lib/dkms/nvidia-legacy-304xx/304.125/build/make.log
DKMS make.log for nvidia-legacy-304xx-304.125 for kernel 4.0.0-1-amd64 (x86_64)
Sat May 16 12:38:06 IDT 2015
make: Entering directory '/var/lib/dkms/nvidia-legacy-304xx/304.125/build'
make KBUILD_VERBOSE=1 -C /lib/modules/4.0.0-1-amd64/build M=/var/lib/dkms
/nvidia-legacy-304xx/304.125/build modules
make[1]: Entering directory '/usr/src/linux-headers-4.0.0-1-amd64'
Makefile:10: *** mixed implicit and normal rules: deprecated syntax
make -C /usr/src/linux-headers-4.0.0-1-amd64 KBUILD_SRC=/usr/src/linux-
headers-4.0.0-1-common \
-f /usr/src/linux-headers-4.0.0-1-common/Makefile modules
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (
\
echo >&2;   \
echo >&2 "  ERROR: Kernel configuration is invalid.";   \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are
missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix
it.";  \
echo >&2 ;  \
/bin/false)
mkdir -p /var/lib/dkms/nvidia-legacy-304xx/304.125/build/.tmp_versions ; rm -f
/var/lib/dkms/nvidia-legacy-304xx/304.125/build/.tmp_versions/*
make -f /usr/src/linux-headers-4.0.0-1-common/scripts/Makefile.build
obj=/var/lib/dkms/nvidia-legacy-304xx/304.125/build
echo \#define NV_COMPILER \"` gcc-4.9 -v 2>&1 | tail -n 1`\" > /var/lib/dkms
/nvidia-legacy-304xx/304.125/build/nv_compiler.h
   gcc-4.9 -Wp,-MD,/var/lib/dkms/nvidia-legacy-304xx/304.125/build/.nv.o.d
-nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.9/include -I/usr/src/linux-
headers-4.0.0-1-common/arch/x86/include -Iarch/x86/include/generated/uapi
-Iarch/x86/include/generated  -I/usr/src/linux-headers-4.0.0-1-common/include
-Iinclude -I/usr/src/linux-headers-4.0.0-1-common/arch/x86/include/uapi
-Iarch/x86/include/generated/uapi -I/usr/src/linux-
headers-4.0.0-1-common/include/uapi -Iinclude/generated/uapi -include /usr/src
/linux-headers-4.0.0-1-common/include/linux/kconfig.h   -I/var/lib/dkms/nvidia-
legacy-304xx/304.125/build -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-
trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-
declaration -Wno-format-security -std=gnu89 -m64 -mno-80387 -mno-fp-ret-in-387
-mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-
outgoing-args -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1
-DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1
-pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-
sse2 -mno-3dnow -mno-avx -fno-delete-null-pointer-checks -O2 --param=allow-
store-data-races=0 -Wframe-larger-than=2048 -fstack-protector -Wno-unused-but-
set-variable -fno-var-tracking-assignments -g -pg -mfentry -DCC_USING_FENTRY
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-
time -DCC_HAVE_ASM_GOTO   -I/var/lib/dkms/nvidia-legacy-304xx/304.125/build
-Wall -MD -Wsign-compare -Wno-cast-qual -Wno-error -D__KERNEL__ -DMODULE -DNVRM
-DNV_VERSION_STRING=\"304.125\" -Wno-unused-function -Wuninitialized -mno-red-
zone -mcmodel=kernel -UDEBUG -U_DEBUG -DNDEBUG  -DMODULE  -D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(nv)"  -D"KBUILD_MODNAME=KBUILD_STR(nvidia)" -c -o
/var/lib/dkms/nvidia-legacy-304xx/304.125/build/.tmp_nv.o /var/lib/dkms/nvidia-
legacy-304xx/304.125/build/nv.c
In file included from /usr/src/linux-
headers-4.0.0-1-common/include/uapi/linux/stddef.h:1:0,
 from /usr/src/linux-
headers-4.0.0-1-common/include/linux/stddef.h:4,
 from /usr/src/linux-
headers-4.0.0-1-common/include/uapi/linux/posix_types.h:4,
 from /usr/src/linux-
headers-4.0.0-1-common/include/uapi/linux/types.h:13,
 from /usr/src/linux-
headers-4.0.0-1-common/include/linux/types.h:5,
 from /usr/src/linux-
headers-4.0.0-1-common/include/uapi/linux/capability.h:16,
 from /usr/src/linux-
headers-4.0.0-1-common/include/linux/capability.h:15,
 from /usr/src/linux-
headers-4.0.0-1-common/include/linux/sched.h:15,
 from /usr/src/linux-
headers-4.0.0-1-common/include/linux/utsname.h:5,
 from /var/lib/dkms/nvidia-legacy-304xx/304.125/build/nv-
linux.h:42,
 from /var/lib/dkms/nvidia-legacy-304xx/304.125/build/nv.c:13:
/usr/src/linux-headers-4.0.0-1-common/include/asm-generic/qrwlock.h: In
function ‘queue_write_trylock’:
/usr/src/linux-headers-4.0.0-1-common/include/asm-generic/qrwlock.h:

Bug#678340: gnome-packagekit: gpk-update-viewer fails listing available updates

[Alan Jenkins]

On Sun, 09 Jun 2013 16:58:41 +0200 =?utf-8?q?Andrzej_Zi=C4=99ba?= 
 wrote:

>
> When I run "pkcon refresh" the package cache is refreshed and the 
gpk-update-

> viewer shows all the available updates.
>
> So "pkcon refresh" is fine but is probably never used.


I agree, you can see it in the logs.  Debian's gnome runs 'get-updates' 
but never 'refresh':


# cd /var/log && zgrep "PackageKit" syslog syslog.*
syslog:May 16 10:42:10 debian-test PackageKit: get-updates transaction 
/113_eecabaaa from uid 1000 finished with success after 548ms

...

Whereas Fedora runs PackageKit refresh as intended:

# journalctl /usr/libexec/packagekitd
-- Reboot --
May 14 07:59:27 volcano.localdomain PackageKit[1486]: daemon start
May 14 08:00:37 volcano.localdomain PackageKit[1486]: uid 1000 is trying 
to obtain org.freedesktop.packagekit.system-sources-refresh auth (o
May 14 08:00:38 volcano.localdomain PackageKit[1486]: uid 1000 obtained 
auth for org.freedesktop.packagekit.system-sources-refresh
May 14 08:01:32 volcano.localdomain PackageKit[1486]: refresh-cache 
transaction /2330_cccdedbe from uid 1000 finished with success after 546
May 14 08:01:33 volcano.localdomain PackageKit[1486]: get-updates 
transaction /2331_ebccabab from uid 1000 finished with success after 270ms

-- Reboot --

Alan


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

Bug#774498: closed by Santiago Vila (Bug#774498: fixed in base-files 9.1)

[Jérémy Bobbio]

Santiago Vila:
> On Sat, May 16, 2015 at 12:38:50AM +0200, Jérémy Bobbio wrote:
> > Sorry but since we are now testing umask variations as well, the new
> > version is not considered reproducible. The attached patch will fix the
> > issue.
> 
> Oh my FSM. This is the neverending story.

Kinda, kinda not, thankfully. :) We are now covering almost all possible
variations we could think of. The remaining ones should be add to the
tests soon: CPU type, available memory and filesystem.

> I am really considering switching all my packages to dh, but in this
> case:
> 
> Is there a reason why a standard, sane umask can't be set by
> dpkg-buildpackage and be part of what a package may take it for granted?

`debuild` already sets the umask to 002:
https://sources.debian.net/src/devscripts/2.15.4/scripts/debuild.pl/hl=622#L622

Maybe that could be moved to `dpkg-buildpackage`?

But in any cases, using `dpkg-buildpackage` is not mandatory to build
Debian packages.

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


signature.asc
Description: Digital signature

Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot

[Ian Campbell]

On Fri, 2015-05-15 at 17:55 -0700, Rick Thomas wrote:
[...]
> There does not seem to be any way to over-ride this.  There's code in 
> /etc/default/hwclock
> that would do part of the work in a sysvinit setup, but it seems to be 
> ignored under systemd.
[...]
> Presumably, there is systemd magic that could do the same thing as was 
> available under
> sysvinit.  Is there anybody out there with enough systemd foo to tell me how 
> to do that?

I think that if systemd is not supporting /etc/default/hwclock and the
replacement mechanism is not apparent after some searching of the docs
etc then this should be considered a systemd bug (either in the docs if
not an actual code bug or missing feature).

Perhaps someone on the pkg-systemd-maintainers@alioth list will be
better able to advise on if/how systemd solves this problem?

Ian.


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

Bug#702241: gnome-packagekit: Update information is not refreshed

[Alan Jenkins]

On Fri, 7 Nov 2014 19:33:16 +0100 Matthias Klumpp  wrote:
>
> have to configure the Apt cronjob to do the updating for you (GNOME
> will do that on it's own, depending on the system's state (e.g.
> network availability, or if the system is running on battery power).
>

GNOME isn't refreshing the packagekit cache (syslog shows PackageKit 
'get-updates' but never a 'refresh').  You still have to configure 
Apt::Periodic::Update-Package-Lists manually (and hope your internet 
connection is available at the right time :), or you never see any 
updates in gnome.


I noticed the bug on Jessie stable - I think it was the same in Wheezy 
stable too.  I think people didn't see the bug when they upgraded 
earlier systems, because the old update-notifier configured 
Apt::Periodic and that got left over.


Alan


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

Bug#772138: sngrep in Debian

[Ivan Alonso [Kaian]]

Hi Victor,

  Of course!

  Right now I have some repositories with version 0.3.1-1 [1] and I'll soon 
  release 0.3.2 which will solve a couple of minor bugs.

  It will be nice if users can download it from official repositories but
  I will need some kind of guidance. Feel free to point me what can I do to
  help with the packaging/releasing proccess.

Best regads, 
Kaian

[1] https://github.com/irontec/sngrep/wiki/Installing-Binaries#debian--ubuntu

-- 
Ivan Alonso [aka Kaian]


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

Bug#683372: squeeze update of dnsmasq?

[Santiago Ruano Rincón]

Hi Simon,

On Fri, May 15, 2015 at 04:24:30PM +0200, Santiago Ruano Rincón wrote:
...
> I'm attaching the clean patch to fix CVE-2015-3294.

These other CVEs are related each other and still affect dnsmasq in
squeeze and wheeze:
https://security-tracker.debian.org/tracker/CVE-2012-3411
https://security-tracker.debian.org/tracker/CVE-2013-0198

As far as I understand, your fix to those bugs introduces the new
--bind-dynamic option in dnsmasq. This fix also depends on libvirt, that
needs to be modified to pass --bind-dynamic instead of
--bind-interfaces. Please, correct me if I'm wrong.

Given that in Debian they have been classified as low priority, do you
think it's worth to do adapt those changes into squeeze and wheeze?

Best regards,

Santiago


signature.asc
Description: Digital signature

Bug#780610: Intent to NMU python-potr [Was: Bug#780610: python-potr: convertkey.py is missing]

[intrigeri]

Control: tag -1 + patch

Hi,

I've pushed my proposed changes to the bug780610 branch in the
packaging Git repository, and am attaching the corresponding diff.
Should I go ahead with a NMU, or do the maintainers prefer to handle
it themselves?

Cheers!
--
intrigeri

diff --git a/debian/changelog b/debian/changelog
index a3397e1..70ba6cf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+python-potr (1.0.1-1.1~1.gbpcbf370) UNRELEASED; urgency=medium
+
+  ** SNAPSHOT build @cbf3705b8cf44dccb5f05b581716405363648099 **
+
+  * Non-maintainer upload.
+  * Install the convertkey script in python-potr (Closes: #780610).
+  * debian/control: don't pretend that python3-potr ships the convertkey script.
+
+ -- intrigeri   Sat, 16 May 2015 12:26:21 +0200
+
 python-potr (1.0.1-1) unstable; urgency=low
 
   * new upstream version, 1.0.1
diff --git a/debian/control b/debian/control
index 479b9e6..64bd82e 100644
--- a/debian/control
+++ b/debian/control
@@ -44,7 +44,4 @@ Description: Pure Python implementation of the OTR protocol (Python 3)
  gajim-otr plugin will be available in the next major Gajim release to
  provide IM encryption independently of the underlying chat protocol.
  .
- This package also includes the command line utility 'convertkey' for
- converting the old OTR file format to the new one.
- .
  This is the Python 3 version of the package.
diff --git a/debian/python-potr.dirs b/debian/python-potr.dirs
new file mode 100644
index 000..e772481
--- /dev/null
+++ b/debian/python-potr.dirs
@@ -0,0 +1 @@
+usr/bin
diff --git a/debian/rules b/debian/rules
index d8d54b4..89fbece 100755
--- a/debian/rules
+++ b/debian/rules
@@ -24,6 +24,7 @@ install-python%:
 
 override_dh_auto_install: $(PYTHON3:%=install-python%)
 	dh_auto_install
+	install -m0755 src/tools/convertkey.py debian/python-potr/usr/bin/convertkey
 
 override_dh_auto_clean:
 	dh_auto_clean

Bug#784666: nghttp2: new upstream release v0.7.13

[Alessandro Ghedini]

Control: retitle -1 nghttp2: new upstream release v1.0.0

On Thu, May 07, 2015 at 06:08:47PM +0200, Alessandro Ghedini wrote:
> Source: nghttp2
> Version: 0.6.7-1
> Severity: wishlist
> 
> Hello,
> 
> upstream has released several new upstream versions, would it be possible to
> update the Debian package?

It seems a new version has been released not long ago.

Anyway, to expand on my original report, I was looking to enable the HTTP/2
support in curl, which requires nghttp2. Unfortunately the current nghttp2
version in Debian doesn't work very well with some sites, and future curl
releases will probably require nghttp2 1.0.0 [0].

If needed I can help update the package.

Cheers

[0] https://github.com/bagder/curl/pull/271


signature.asc
Description: Digital signature

Bug#678340: gnome-packagekit: gpk-update-viewer fails listing available updates

[Matthias Klumpp]

2015-05-16 12:11 GMT+02:00 Alan Jenkins :
> On Sun, 09 Jun 2013 16:58:41 +0200 =?utf-8?q?Andrzej_Zi=C4=99ba?=
>  wrote:
>>
>> When I run "pkcon refresh" the package cache is refreshed and the
>> gpk-update-
>> viewer shows all the available updates.
>>
>> So "pkcon refresh" is fine but is probably never used.
>
>
> I agree, you can see it in the logs.  Debian's gnome runs 'get-updates' but
> never 'refresh':

The component which runs the refresh-action on GNOME is not
GNOME-PackageKit, but gnome-settings-daemon.
Can you check in gpk-prefs that the automatic update-checks are enabled?
All people not using GNOME or KDE need to ask their desktops to
integrate PackageKit, or install the package "apt-config-auto-update"
to get the cache updated.
Cheers,
Matthias


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

Bug#683372: squeeze update of dnsmasq?

[Santiago Ruano Rincón]

On Sat, May 16, 2015 at 12:26:51PM +0200, Santiago Ruano Rincón wrote:
> Hi Simon,
> 
> On Fri, May 15, 2015 at 04:24:30PM +0200, Santiago Ruano Rincón wrote:
> ...
> > I'm attaching the clean patch to fix CVE-2015-3294.
> 
> These other CVEs are related each other and still affect dnsmasq in
> squeeze and wheeze:
> https://security-tracker.debian.org/tracker/CVE-2012-3411
> https://security-tracker.debian.org/tracker/CVE-2013-0198
> 
> As far as I understand, your fix to those bugs introduces the new
> --bind-dynamic option in dnsmasq. This fix also depends on libvirt, that
> needs to be modified to pass --bind-dynamic instead of
> --bind-interfaces. Please, correct me if I'm wrong.
> 
> Given that in Debian they have been classified as low priority, do you
> think it's worth to do adapt those changes into squeeze and wheeze?

Note: libvirt has not support by Squeeze LTS


signature.asc
Description: Digital signature

Bug#785443: vpnc: VPN disconnects every hour

[Hans Yntema]

Package: vpnc
Version: 0.5.3r550-2
Severity: important

Dear Maintainer,



I am using a FritzBox modem as endpoint. 
vpnc disconnects every hour.

syslog:
May 16 09:07:09 rijs-svr kernel: [821056.494059] CIFS VFS: Server 192.168.1.1 
has not responded in 120 seconds. Reconnecting...

May 16 09:07:53 rijs-svr vpnc[12282]: HMAC mismatch in ESP mode
 
May 16 09:11:35 rijs-svr vpnc[12282]: HMAC mismatch in ESP mode
May 16 09:13:32 rijs-svr vpnc[12282]: connection terminated by dead peer 
detection

I have disconnect detecton in place. VPN restarts. Same issue occurs again 
after exactly 1 hour.

Issue seems similar to Bug#496718; I have checked the source code, patches seem 
to be applied.


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

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

Versions of packages vpnc depends on:
ii  dpkg   1.17.25
ii  libc6  2.19-18
ii  libgcrypt201.6.3-2
ii  libgnutls-deb0-28  3.3.8-6
ii  perl   5.20.2-3
ii  vpnc-scripts   0.1~git20140806-1

Versions of packages vpnc recommends:
ii  iproute  1:3.16.0-2

Versions of packages vpnc suggests:
pn  resolvconf  

-- Configuration Files:
/etc/vpnc/fritzbox.conf 

IPSec gateway x
IPSec ID x
IPSec secret x
NAT Traversal Mode force-natt
Xauth username x
Xauth password x


-- 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#785444: ITP: ruby-omniauth-gitlab -- OAuth2 strategy for authenticating to GitLab service

[Balasankar C]

Package: wnpp
Severity: wishlist
Owner: Balasankar C 

* Package name: ruby-omniauth-gitlab
  Version : 1.0.0
  Upstream Author : Sergey Sein
* URL : https://github.com/linchus/omniauth-gitlab
* License : Expat
  Programming Lang: Ruby
  Description : OAuth2 strategy for authenticating to GitLab service


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

Bug#785349: transition: hiredis

[Tom Lee]

Confirmed the webdis segfault is due to an ABI change.

On Fri, May 15, 2015 at 10:07 PM, Tom Lee  wrote:

>
>
> On Fri, May 15, 2015 at 1:36 AM, Emilio Pozuelo Monfort 
> wrote:
>
>> On 15/05/15 06:10, Tom Lee wrote:
>> > Package: release.debian.org
>> > Severity: normal
>> > User: release.debian@packages.debian.org
>> > Usertags: transition
>> >
>> > Hello, I'd like to request a transition slot from the release team.
>> >
>> > The libhiredis SONAME changed in the latest release from upstream,
>> > indicating ABI-incompatible changes to the library. Updating the binary
>> > package to reflect the new SONAME. libhiredis0.13 has been uploaded to
>> > experimental by my sponsor.
>> >
>> > I couldn't quite figure out how to get the Ben file reportbug generated
>> > for me below to give me a list of dependent packages (this is my first
>> > request for a transition), but I pulled this list from apt-cache
>> > rdepends if that's at all useful:
>> >
>> > zmap
>> > webdis
>> > syslog-ng-mod-redis
>> > ruby-hiredis
>> > rspamd
>> > rfc5766-turn-server
>> > python-hiredis
>> > ntopng
>> > kamailio-redis-modules
>> > libhiredis-dev
>> > libhiredis-dbg
>> > coturn
>>
>> Have you tested that they build fine against the new version of the
>> library?
>>
>
> All seem to build just fine except for webdis, which segfaults during
> tests. There are no segfaults when building against libhiredis0.10, so
> looks like it's running afoul of something in the latest release.
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee 
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#772138: sngrep in Debian

[Victor Seva]

On 05/16/2015 12:11 PM, Ivan Alonso [Kaian] wrote:
> Hi Victor,
> 
>   Of course!
> 
>   Right now I have some repositories with version 0.3.1-1 [1] and I'll soon 
>   release 0.3.2 which will solve a couple of minor bugs.

Ok. Upgrading. Please ping me when 0.3.2 is released.

>   It will be nice if users can download it from official repositories but
>   I will need some kind of guidance. Feel free to point me what can I do to
>   help with the packaging/releasing proccess.

I'm going to try to find a sponsor, sadly I'm not yet a DD. I will keep
you inform.

Cheers,
Victor




signature.asc
Description: OpenPGP digital signature

Bug#785436: [pkg-apparmor] Bug#785436: Bug#785436: apparmor: Should apparmor have a versioned dependency for python3-apparmor?

[u]

intrigeri:
> Control: severity -1 important
> 
> Hi,
> 
> u wrote (16 May 2015 09:07:12 GMT) :
>> Here is my initial bug report:
>> https://bugs.launchpad.net/apparmor/+bug/1455236
>> I installed the latest version of apparmor from sid and was wondering if
>> there shouldn't be a versioned dependency for python3-apparmor, as the
>> Jessie version does not function with the latest apparmor version (2.9.2).
> 
> Thanks! Too bad we're realizing now that your 2.9.2 testing feedback
> wasn't actually about the full 2.9.2 stack, but that's my fault :)

since i installed the missing parts, everything still works great though :)

cheers!


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

Bug#785446: PEAR: Please reduce automatic names from sourceforge

[Mathieu Parent]

Package: pkg-php-tools
Version: 1.29
Severity: minor

Hello,

Example: phpseclib.sourceforge.net/File_ASN1 becomes 
php-phpseclib-sourceforge-file-asn1.

Should be php-phpseclib-file-asn1, i.e consider sf as a TLD.

Regards

Mathieu Parent


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

Bug#785407: Reportbug still crashes

[Felix Lechner]

The problem still exists with reportbug 6.6.3 on testing.


Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2211, in 
main()
  File "/usr/bin/reportbug", line 1081, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1703, in user_interface
latest_first=self.options.latest_first)
  File "/usr/lib/python2.7/dist-packages/reportbug/ui/gtk2_ui.py", line
1505, in func
args, kwargs = op.sync_pre_operation (*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/reportbug/ui/gtk2_ui.py", line
886, in sync_pre_operation
http_proxy=http_proxy, archived=archived, source=source)
  File "/usr/lib/python2.7/dist-packages/reportbug/debbugs.py", line 1275,
in get_reports
stats = debianbts.get_status(bugs)
  File "/usr/lib/pymodules/python2.7/debianbts.py", line 179, in get_status
reply = server.get_status(*nr)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 545, in
__call__
return self.__r_call(*args, **kw)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 567, in
__r_call
self.__hd, self.__ma)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 430, in
__call
timeout = self.timeout)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 318, in
call
raise HTTPError(code, msg)
SOAPpy.Errors.HTTPError: 

Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot

[Rick Thomas]

On May 16, 2015, at 3:13 AM, Ian Campbell  wrote:

> On Fri, 2015-05-15 at 17:55 -0700, Rick Thomas wrote:
> [...]
>> There does not seem to be any way to over-ride this.  There's code in 
>> /etc/default/hwclock
>> that would do part of the work in a sysvinit setup, but it seems to be 
>> ignored under systemd.
> [...]
>> Presumably, there is systemd magic that could do the same thing as was 
>> available under
>> sysvinit.  Is there anybody out there with enough systemd foo to tell me how 
>> to do that?
> 
> I think that if systemd is not supporting /etc/default/hwclock and the
> replacement mechanism is not apparent after some searching of the docs
> etc then this should be considered a systemd bug (either in the docs if
> not an actual code bug or missing feature).
> 
> Perhaps someone on the pkg-systemd-maintainers@alioth list will be
> better able to advise on if/how systemd solves this problem?
> 
> Ian.

Thanks, Ian, for the prompt response.  I’ve submitted a separate bug to systemd 
asking for a fix.  However, it may not be possible to do this with systemd…  
Looking at the dmesg output, it looks like the decision to use /dev/rtc0 is 
being made at the kernel level, before systemd even gets started.  If that’s 
correct, I’m not sure if even sysvinit with /etc/default/hwclock could have 
done the right thing in my case.

Do you happen to know why the patch I came across never made it into the kernel?

Thanks, again!
Rick


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

Bug#785281: Split phpseclib?

[Mathieu Parent]

Hello David,

phpseclib is provided upstream in two shapes: Composer (monolithic)
and PEAR (splitted, see PS).

Debian currently ships one binary package built from composer.

Some PEAR packages may depend on one particular package (this is
currently the case for php-horde-imp which recommends FIle_ASN1, and
for php-horde-mapi which depends on Math_BigInteger, see #785281).

There are three problems here:
1./ The PEAR calculated package name is weird:
phpseclib.sourceforge.net/File_ASN1 -> php-phpseclib-sourceforge-file-asn1

I will fix this in pkg-php-tools, to consider sourceforge.net like a
TLD (we'll have php-phpseclib-file-asn1).

This is #785446.

2./ The current package name from composer should be php-phpseclib
instead. I will file a bug about this.

3./ The php-phpseclib should "provide" all the libraries it ships.
This would be the proper fix for #785281.



Regards
-- 
Mathieu Parent

PS: Here are the splitted packages

$ sudo pear channel-add http://phpseclib.sourceforge.net/channel.xml
Adding Channel "phpseclib.sourceforge.net" succeeded

$ pear  list-all -c phpseclib
All packages [Channel phpseclib]:
=
PackageLatest Local
phpseclib/Crypt_AES0.3.10   Pure-PHP implementation of AES
phpseclib/Crypt_Base   0.3.10   Base class for symmetric key
cryptographic algorithms
phpseclib/Crypt_Blowfish   0.3.10   Pure-PHP implementation of Blowfish
phpseclib/Crypt_DES0.3.10   Pure-PHP implementation of DES
phpseclib/Crypt_Hash   0.3.10   Pure-PHP implementations of
keyed-hash message authentication codes (HMACs) and various
cryptographic hashing functions
phpseclib/Crypt_Random 0.3.10   Random Number Generator
phpseclib/Crypt_RC40.3.10   Pure-PHP implementation of RC4
phpseclib/Crypt_Rijndael   0.3.10   Pure-PHP implementation of Rijndael
phpseclib/Crypt_RSA0.3.10   Pure-PHP PKCS#1 (v2.1)
compliant implementation of RSA
phpseclib/Crypt_TripleDES  0.3.10   Pure-PHP implementation of Triple DES
phpseclib/Crypt_Twofish0.3.10   Pure-PHP implementation of Twofish
phpseclib/File_ANSI0.3.10   Pure-PHP ANSI decoder
phpseclib/File_ASN10.3.10   Pure-PHP ASN1 parser
phpseclib/File_X5090.3.10   Pure-PHP X.509 encoder / decoder
phpseclib/Math_BigInteger  0.3.10   Pure-PHP arbitrary precision
integer arithmetic library
phpseclib/Net_SFTP 0.3.10   Pure-PHP implementation of SFTP
phpseclib/Net_SSH1 0.3.10   Pure-PHP implementation of SSHv1
phpseclib/Net_SSH2 0.3.10   Pure-PHP implementation of SSHv2
phpseclib/System_SSH_Agent 0.3.10   Pure-PHP ssh-agent client


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

Bug#785447: python-pampy: please package newer upstream release

[Jonas Smedegaard]

Package: python-pampy
Severity: wishlist
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Upstream is many versions ahead of Debian - currently at 1.8.1:
https://pypi.python.org/pypi/python-pam/1.8.1

Please upgrade Debian package to newer upstream release.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVVzURAAoJECx8MUbBoAEh/8AP+wRsy5AjzOWr8nlRH/R1M0Yx
elNrRg9NStCKwouE9CH8/TQci1jNC7hCT09JAFFoo5JFgVkuV4dw+vQpl/B9HDmX
B29vfDmFDWSgD71ez5E+thetYSlPw0YQrx8wLsqPmkXOVhPJL0yRczqRF44lAGCi
YoNL74rnOynJ9SF6uPKhzSozRxiTXBPBP1BV4z34/XyvybdFWOO0fyxGwtziuRmF
5hTAu24V9PDhOzSxhgP0Fsg5vw/kaYuPZZucFAGbLIydrVZXdV5xmYKtvWa21aEb
mgsauaPVRdDv2hSb5HbVHCy0nRzEAAaYk/Rmm1WY7BvQo2uLvkjWtvv+EQfJ+seJ
FTdzSG44qIXxH22oxDuRhNhlBLjo+a3or32qdoXNAFLvxItNoW3DDXFuFACw+cGt
2qqlustsI7iVn4vsoSKzhNixGsbrq4+vCmoAwHw1ONw6NDCwkPDye49H5pisPVjE
Des9az87motcpkeg49aDryS7PTb2H7POHGYx1B2ag2DQ1D6CsZK22ays0WOLY9L1
YS3p6JQdLUy9S7lLXWcmSIVX+st2KXgVt4EkzPDDYikdmiLcP8haHLhsMgWbosj3
ccZXYM9Mx0UPW7ji47tF6fNEDI7JbHqxOTzk0jjKWr39pI/RgbHn2680QnIO7hN6
xV80QvP6sGlYCLHMRcuG
=sMg2
-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#785448: xserver-xorg-video-ati: Screen is badly tinged with green when using the open source driver

[Owen Riddy]

Package: xserver-xorg-video-ati
Version: 1:7.5.0-1+b1
Severity: important

Dear Maintainer,

I'm using the open source ati graphics with a 3-screen setup. After upgrading 
to unstable after the release of Jessie everything ran without issue.

I booted into a seperate install of Jessie on the same computer that had flgrx 
installed, and after rebooting into unstable one of the screens (connected by a 
HDMI cable) has acquired a distinct green tinge that obscures whatever the 
screen is trying to show. It is a sort of neon green.

This image is a graphical corruption bug - I took a screenshot using ksnapshot 
and on my other two screens the image dispaled withouth the green tinge.

The tinge is not present:
  * In the BIOS
  * When GRUB is active
  * Early in the boot process when the kernel is still printing text
  * On a separate Debian install on the same hardware, using fglrx

I tried changing the gamma settings of the screen and poking at the backlight 
settings but this did not help. Changing the gamma made a very slight 
difference but the tinge does nto seem to be caused by a rogue gamma setting.

At some points during, eg, shutdown my screens go blank - usually this is black 
but at present the green tinged screen goes straight green.

I can't test it because it will not go away, but I think this problem was 
caused by using the card with fglrx then restarting the computer.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Jun 17  2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2384712 May  5 09:24 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 250X] [1002:683d]

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.0.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 
(Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 72560 May 16 21:35 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[ 2.955] 
X.Org X Server 1.17.1
Release Date: 2015-02-10
[ 2.956] X Protocol Version 11, Revision 0
[ 2.956] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[ 2.956] Current Operating System: Linux cyclone 4.0.0-1-amd64 #1 SMP 
Debian 4.0.2-1 (2015-05-11) x86_64
[ 2.956] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.0.0-1-amd64 
root=UUID=b83e383f-49aa-4f43-bf09-93f7238eff15 ro quiet
[ 2.956] Build Date: 04 May 2015  11:22:06PM
[ 2.956] xorg-server 2:1.17.1-2 (http://www.debian.org/support) 
[ 2.956] Current version of pixman: 0.32.6
[ 2.956]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 2.956] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 2.956] (==) Log file: "/var/log/Xorg.0.log", Time: Sat May 16 21:35:12 
2015
[ 2.961] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 2.965] (==) No Layout section.  Using the first Screen section.
[ 2.965] (==) No screen section available. Using defaults.
[ 2.965] (**) |-->Screen "Default Screen Section" (0)
[ 2.965] (**) |   |-->Monitor ""
[ 2.965] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 2.965] (==) Automatically adding devices
[ 2.965] (==) Automatically enabling devices
[ 2.965] (==) Automatically adding GPU devices
[ 2.967] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 2.967]Entry deleted from font path.
[ 2.967] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[ 2.967]Entry deleted from font path.
[ 2.967] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[ 2.967]Entry deleted from font path.
[ 2.969] (WW) `fonts.dir' not found (or not valid) in 
"/usr/share/fonts/X11/Type1".
[ 2.969]Entry deleted from font path.
[ 2.969](Run 'mkfontdir' on "/usr/share/fonts/X11/Type1").
[ 2.969] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[ 2.969]Entry deleted from font path.
[ 2.969] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[ 2.969]Entry deleted from font path.
[ 2.969] (==) FontPath set to:
/usr/share/fonts/X11/misc,
built-ins
[ 2.969] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 2.969] (II) The serve

Bug#785449: [network-manager] NM daemon crashes after 4G dongle remove and plug again.

[IANSAV]

Package: network-manager
Version: 1.0.2-2
Severity: serious

--- Please enter the report below this line. ---
Dear Maintainer, if I remove then plug my Huawei E3272 4G dongle and
try to connect, I get a lighting led on dongle (like a connection is
up) and "connecting" look of applet icon. Permanently. I can't turn off
connection by using an applet and I can't access to Inet. 

Moreower. I can't restart it via systemctl or even REBOOT MY LAPTOP
(when a try it, I get black screen and when I press Ctrl+Alt+F1 I see
login promt, but I can't type anything. Keyboard is disabled!)

Please, fix this strange bug.

P. S. Sorry for my English. It isn't my native language.

Look at syslog.




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

Debian Release: stretch/sid
  500 unstableftp.debian.org 
  500 stable  dl.google.com 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.
May 16 13:19:33 ente NetworkManager[539]:   (cdc-wdm0): device state 
change: activated -> deactivating (reason 'connection-removed') [100 110 38]
May 16 13:19:33 ente NetworkManager[539]:   NetworkManager state is now 
DISCONNECTING
May 16 13:19:33 ente dhclient: receive_packet failed on wwan0: Network is down
May 16 13:19:33 ente NetworkManager[539]:   (cdc-wdm0): modem state 
changed, 'connected' --> 'disconnecting' (reason: user-requested)
May 16 13:19:34 ente NetworkManager[539]:   (cdc-wdm0): modem state 
changed, 'disconnecting' --> 'registered' (reason: user-requested)
May 16 13:19:34 ente NetworkManager[539]:   (cdc-wdm0): device state 
change: deactivating -> disconnected (reason 'connection-removed') [110 30 38]
May 16 13:19:34 ente NetworkManager[539]:   (cdc-wdm0): deactivating 
device (reason 'connection-removed') [38]
May 16 13:19:34 ente NetworkManager[539]:   (wwan0): canceled DHCP 
transaction, DHCP client pid 1490
May 16 13:19:34 ente NetworkManager[539]:   (wwan0): DHCPv4 state changed 
bound -> done
May 16 13:19:34 ente NetworkManager[539]:   NetworkManager state is now 
DISCONNECTED
May 16 13:19:34 ente gnome-session[2926]: (gnome-shell:2954): 
libnm-glib-WARNING **: async_got_type: could not read properties for 
/org/freedesktop/NetworkManager/ActiveConnection/1: Method "Get" with signature 
"ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
May 16 13:19:52 ente blueman-mechanism: loading Network
May 16 13:20:22 ente org.blueman.Mechanism[554]: loading Network
May 16 13:23:37 ente blueman-mechanism: loading Network
May 16 13:24:07 ente org.blueman.Mechanism[554]: loading Network
May 16 13:39:45 ente NetworkManager[539]:   caught signal 15, shutting 
down normally.
May 16 13:39:45 ente NetworkManager[539]:   (eth0): device state change: 
unavailable -> unmanaged (reason 'unmanaged') [20 10 3]
May 16 13:39:55 ente avahi-daemon[592]: Network interface enumeration completed.
May 16 13:39:55 ente NetworkManager[570]:   NetworkManager (version 
1.0.2) is starting...
May 16 13:39:55 ente NetworkManager[570]:   Read config: 
/etc/NetworkManager/NetworkManager.conf
May 16 13:39:55 ente NetworkManager[570]:   WEXT support is enabled
May 16 13:39:55 ente NetworkManager[570]:   init!
May 16 13:39:55 ente NetworkManager[570]:   update_system_hostname
May 16 13:39:55 ente NetworkManager[570]: interface-parser: 
parsing file /etc/network/interfaces
May 16 13:39:55 ente NetworkManager[570]: interface-parser: 
source line includes interfaces file(s) /etc/network/interfaces.d/*
May 16 13:39:55 ente NetworkManager[570]:   interfaces file 
/etc/network/interfaces.d/* doesn't exist
May 16 13:39:55 ente NetworkManager[570]: interface-parser: 
finished parsing file /etc/network/interfaces
May 16 13:39:55 ente NetworkManager[570]:   management mode: unmanaged
May 16 13:39:55 ente NetworkManager[570]:   devices added (path: 
/sys/devices/pci:00/:00:1c.0/:02:00.0/net/eth0, iface: eth0)
May 16 13:39:55 ente NetworkManager[570]:   device added (path: 
/sys/devices/pci:00/:00:1c.0/:02:00.0/net/eth0, iface: eth0): no 
ifupdown configuration found.
May 16 13:39:55 ente NetworkManager[570]:   devices added (path: 
/sys/devices/pci:00/:00:1c.1/:03:00.0/bcma0:1/net/wlan0, iface: 
wlan0)
May 16 13:39:55 ente NetworkManager[570]:   device added (path: 
/sys/devices/pci:00/:00:1c.1/:03:00.0/bcma0:1/net/wlan0, iface: 
wlan0): no ifupdown configuration found.
May 16 13:39:55 ente NetworkManager[570]:   devices added (path: 
/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.4/net/wwan0, iface: 
wwan0)
May 16 13:39:55 ente NetworkManager[570]:   device added (path: 
/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.4/net/wwan0, iface: 
wwan0): no ifupdown configuration found.
May 16 13:39:55 ente NetworkManager[570]:   devices added (path: 
/sys/devices/virtual/net/lo, iface: lo)
May 16 13:39:55 ente NetworkManager[570]:   

Bug#785417: josm: please update josm to atleast svn 8339

[Sebastiaan Couwenberg]

Control: block -1 by 783538

Hi shirish,

I've updated JOSM in git, but upstream has switched the JCS which is not
packaged for Debian yet. See the discussion on the debian-gis list:

https://lists.debian.org/debian-gis/2015/04/msg00029.html

Some JCS build dependencies are missing too, so it's not easy to get it
packaged. I need some help getting these new dependencies packaged.

In the mean time you can use the josm-tested from upstream:

http://josm.openstreetmap.de/

Kind Regards,

Bas

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


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

Bug#785450: ITP: ruby-rubyntlm -- Ruby/NTLM library

[Balasankar C]

Package: wnpp
Severity: wishlist
Owner: Balasankar C 

* Package name: ruby-rubyntlm
  Version : 0.5.0
  Upstream Author : Paul Morton
* URL : https://github.com/WinRb/rubyntlm
* License : Expat
  Programming Lang: Ruby
  Description : Ruby/NTLM library


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

Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot

[Ben Hutchings]

On Sat, 2015-05-16 at 05:01 -0700, Rick Thomas wrote:
> On May 16, 2015, at 3:13 AM, Ian Campbell  wrote:
> 
> > On Fri, 2015-05-15 at 17:55 -0700, Rick Thomas wrote:
> > [...]
> >> There does not seem to be any way to over-ride this.  There's code in 
> >> /etc/default/hwclock
> >> that would do part of the work in a sysvinit setup, but it seems to be 
> >> ignored under systemd.
> > [...]
> >> Presumably, there is systemd magic that could do the same thing as was 
> >> available under
> >> sysvinit.  Is there anybody out there with enough systemd foo to tell me 
> >> how to do that?
> > 
> > I think that if systemd is not supporting /etc/default/hwclock and the
> > replacement mechanism is not apparent after some searching of the docs
> > etc then this should be considered a systemd bug (either in the docs if
> > not an actual code bug or missing feature).
> > 
> > Perhaps someone on the pkg-systemd-maintainers@alioth list will be
> > better able to advise on if/how systemd solves this problem?
> > 
> > Ian.
> 
> Thanks, Ian, for the prompt response.  I’ve submitted a separate bug
> to systemd asking for a fix.  However, it may not be possible to do
> this with systemd…  Looking at the dmesg output, it looks like the
> decision to use /dev/rtc0 is being made at the kernel level, before
> systemd even gets started.

That's right, the kernel optionally reads an RTC into the system time at
boot (CONFIG_RTC_HCTOSYS) and the name of the RTC to use is also part of
the kernel configuration (CONFIG_RTC_HCTOSYS_DEVICE).

> If that’s correct, I’m not sure if even sysvinit
> with /etc/default/hwclock could have done the right thing in my case.

This is not implemented directly by the init system.  util-linux
installs the script /lib/udev/hwclock-set and a udev rule that runs it
for each RTC device.  However, the hwclock-set script does nothing if
systemd is running.

> Do you happen to know why the patch I came across never made it into
> the kernel?

Don't know.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates


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

Bug#711108: linux-image-* should suggest linux-tools-*

[Ben Hutchings]

On Sat, 2015-05-16 at 09:50 +0200, Piotr Engelking wrote:
> tags 711108 + patch
> thanks
> 
> Untested patch attached.
> 
> It may also be interesting to notice that apt already attempts to
> prevent automatic removal of linux-tools matching an installed kernel,
> but fails, since it assumes a version format which is no longer in use:
> 
>   /etc/kernel/postinst.d/apt-auto-removal
>   /etc/apt/apt.conf.d/01autoremove
[...]

That's an Ubuntu-ism.  They use the wrong version format for their
linux-tools package.

Anyway, there's no reason to prevent auto-removal of this package as
it's obviously not required to boot.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates


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

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Sebastian Ramacher]

On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
> On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
> > Version: 6:11.3-1
> > 
> > On 2015-05-14 20:41:15, Arne Wichmann wrote:
> > > Package: libavcodec56
> > > Version: 6:11.3-2
> > > Severity: grave
> > > Tags: security
> > > Justification: user security hole
> > > 
> > > Hi, as far as I can see this has not yet been reported or fixed:
> > > 
> > > CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c in
> > > FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, allow
> > > remote attackers to cause a denial of service (use-after-free) or possibly
> > > have unspecified other impact via crafted Vorbis I data [1]
> > > 
> > > I marked this as grave as the impact is unclear and might include 
> > > arbitrary
> > > code execution. Feel free do downgrade if this can be ruled out.
> > > 
> > > (Actually I would like to have a look at the test case to check a bit more
> > > thoroughly, but AFAICS I would need to talk to google for this.)
> > > 
> > > [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
> > >   https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
> > 
> > A similar commit to the one maintained in this mailing list post was 
> > applied to
> > 11.3. So closing with that version.
> 
> Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg patch 
> at
> all, and the commit message doesn't even mention the bug fix. How can you be 
> so
> sure that the bug is fixed?

I might have read the commit wrong. Do you have a sample for this CVE?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Bug#781888: [pkg-cinnamon] Bug#781888: cinnamon-session: session does not start

[Frederik Himpe]

I am experiencing this bug on two different systems now.

I have opened an upstream bug:
https://github.com/linuxmint/Cinnamon/issues/4156


-- 
Frederik Himpe 


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

Bug#658452: apt-transport-https: apt-get update gets stuck when using https

[chris_blues]

Package: apt-transport-https
Version: 1.0.9.9
Followup-For: Bug #658452

Dear Maintainer,

   * What led up to the situation?
I installed apt-transport-https, edited /etc/apt/sources.list to point the 
debian mirrors to https.
Then apt-get update
then the process stops. No network traffic, no progress...

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
see above

   * What was the outcome of this action?
Program stopped working

   * What outcome did you expect instead?
a nice apt-get update


-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages apt-transport-https depends on:
ii  libapt-pkg4.12   1.0.9.9
ii  libc62.19-18
ii  libcurl3-gnutls  7.42.1-2
ii  libgcc1  1:5.1.1-5
ii  libstdc++6   5.1.1-5

apt-transport-https recommends no packages.

apt-transport-https 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#785451: cinnamon-control-center: Incompatible with network-manager >= 1.0

[Philipp Trulson]

Package: cinnamon-control-center
Version: 2.4.2+betsy
Severity: normal

Dear Maintainer,

I set up Debian 8 Cinnamon with afterwards upgrading to testing and unstable. 
Now I wanted to start a 802.1x WiFi-connection (eduroam at my university) but a 
message pops up saying the system's network services are not compatible with 
this version.

I upgraded to Cinnamon 2.4 from the Linux Mint repos, but that didn't help. The 
problem is a version check in the control center which doesn't work with 
network-manager >= 1.0, see here:
https://github.com/linuxmint/cinnamon-control-center/pull/107

I don't know how to apply such a patch, please fix this.


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

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

Versions of packages cinnamon-control-center depends on:
ii  accountsservice   0.6.37-3+b1
ii  apg   2.2.3.dfsg.1-2
ii  cinnamon-control-center-data  2.4.2+betsy
ii  cinnamon-desktop-data 2.4.2+betsy
ii  cinnamon-settings-daemon  2.4.3.betsy1+betsy
ii  cinnamon-translations 2.4.4+betsy
ii  desktop-file-utils0.22-1
ii  gnome-icon-theme  3.12.0-1
ii  gnome-icon-theme-symbolic 3.12.0-1
ii  libatk1.0-0   2.16.0-2
ii  libc6 2.19-18
ii  libcairo-gobject2 1.14.2-2
ii  libcairo2 1.14.2-2
ii  libcanberra-gtk3-00.30-2.1
ii  libcanberra-pulse 0.30-2.1
ii  libcanberra0  0.30-2.1
ii  libcinnamon-control-center1   2.4.2+rebecca
ii  libcinnamon-desktop0  2.4.2+betsy
ii  libcinnamon-menu-3-0  2.4.0+betsy
ii  libcolord21.2.1-1+b2
ii  libdbus-1-3   1.8.18-1
ii  libdbus-glib-1-2  0.102-1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-4
ii  libgdk-pixbuf2.0-02.31.1-2+b1
ii  libglib2.0-0  2.44.0-3
ii  libgnomekbd8  3.6.0-1
ii  libgtk-3-03.14.5+4
ii  libmm-glib0   1.4.8-1
ii  libnm-glib-vpn1   1.0.2-2
ii  libnm-glib4   1.0.2-2
ii  libnm-gtk01.0.2-1
ii  libnm-util2   1.0.2-2
ii  libnotify40.7.6-2
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpolkit-gobject-1-0 0.105-8
ii  libpulse-mainloop-glib0   6.0-2
ii  libpulse0 6.0-2
ii  libupower-glib3   0.99.2-3
ii  libwacom2 0.8-1
ii  libx11-6  2:1.6.3-1
ii  libxi62:1.7.4-1+b2
ii  libxklavier16 5.2.1-1
ii  libxml2   2.9.2+dfsg1-3

Versions of packages cinnamon-control-center recommends:
ii  cups-pk-helper 0.2.5-2+b1
ii  iso-codes  3.57-1
ii  mesa-utils 8.2.0-1
ii  mousetweaks3.12.0-1
ii  policykit-1-gnome  0.105-2

Versions of packages cinnamon-control-center suggests:
ii  gstreamer0.10-pulseaudio  0.10.31-3+nmu4+b1
pn  libcanberra-gtk-module
ii  x11-xserver-utils 7.7+4

-- Configuration Files:
/etc/xdg/autostart/cinnamon-sound-applet.desktop 
33ec8b1b6c4ce98aa2300cf0971e9922 [Errno 2] Datei oder Verzeichnis nicht 
gefunden: u'/etc/xdg/autostart/cinnamon-sound-applet.desktop 
33ec8b1b6c4ce98aa2300cf0971e9922'

-- 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#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Sebastian Ramacher]

On 2015-05-16 15:28:44, Arne Wichmann wrote:
> begin  quotation  from Sebastian Ramacher (in 
> <20150516130757.ga21...@ramacher.at>):
> > On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
> > > On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
> > > > Version: 6:11.3-1
> > > > 
> > > > On 2015-05-14 20:41:15, Arne Wichmann wrote:
> > > > > Package: libavcodec56
> > > > > Version: 6:11.3-2
> > > > > Severity: grave
> > > > > Tags: security
> > > > > Justification: user security hole
> > > > > 
> > > > > Hi, as far as I can see this has not yet been reported or fixed:
> > > > > 
> > > > > CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c 
> > > > > in
> > > > > FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, 
> > > > > allow
> > > > > remote attackers to cause a denial of service (use-after-free) or 
> > > > > possibly
> > > > > have unspecified other impact via crafted Vorbis I data [1]
> > > > > 
> > > > > I marked this as grave as the impact is unclear and might include 
> > > > > arbitrary
> > > > > code execution. Feel free do downgrade if this can be ruled out.
> > > > > 
> > > > > (Actually I would like to have a look at the test case to check a bit 
> > > > > more
> > > > > thoroughly, but AFAICS I would need to talk to google for this.)
> > > > > 
> > > > > [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
> > > > >   
> > > > > https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
> > > > 
> > > > A similar commit to the one maintained in this mailing list post was 
> > > > applied to
> > > > 11.3. So closing with that version.
> > > 
> > > Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg 
> > > patch at
> > > all, and the commit message doesn't even mention the bug fix. How can you 
> > > be so
> > > sure that the bug is fixed?
> > 
> > I might have read the commit wrong. Do you have a sample for this CVE?
> 
> There is one referenced in various messages relating to CVE-2014-7937:
> asan_heap-uaf_18dac2b_9_asan_heap-uaf_22eb375_208_beta3_test_small.ogg
> unfortunately it is not publicly available AFAICS. You might ask upstream
> about it.

I did. libav developers do not seem to have it. So please provide a sample.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Arne Wichmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

begin  quotation  from Sebastian Ramacher (in 
<20150516130757.ga21...@ramacher.at>):
> On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
> > On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
> > > Version: 6:11.3-1
> > > 
> > > On 2015-05-14 20:41:15, Arne Wichmann wrote:
> > > > Package: libavcodec56
> > > > Version: 6:11.3-2
> > > > Severity: grave
> > > > Tags: security
> > > > Justification: user security hole
> > > > 
> > > > Hi, as far as I can see this has not yet been reported or fixed:
> > > > 
> > > > CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c in
> > > > FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, allow
> > > > remote attackers to cause a denial of service (use-after-free) or 
> > > > possibly
> > > > have unspecified other impact via crafted Vorbis I data [1]
> > > > 
> > > > I marked this as grave as the impact is unclear and might include 
> > > > arbitrary
> > > > code execution. Feel free do downgrade if this can be ruled out.
> > > > 
> > > > (Actually I would like to have a look at the test case to check a bit 
> > > > more
> > > > thoroughly, but AFAICS I would need to talk to google for this.)
> > > > 
> > > > [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
> > > >   https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
> > > 
> > > A similar commit to the one maintained in this mailing list post was 
> > > applied to
> > > 11.3. So closing with that version.
> > 
> > Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg 
> > patch at
> > all, and the commit message doesn't even mention the bug fix. How can you 
> > be so
> > sure that the bug is fixed?
> 
> I might have read the commit wrong. Do you have a sample for this CVE?

There is one referenced in various messages relating to CVE-2014-7937:
asan_heap-uaf_18dac2b_9_asan_heap-uaf_22eb375_208_beta3_test_small.ogg
unfortunately it is not publicly available AFAICS. You might ask upstream
about it.

cu

AW
- -- 
[...] If you don't want to be restricted, don't agree to it. If you are
coerced, comply as much as you must to protect yourself, just don't support
it. Noone can free you but yourself. (crag, on Debian Planet)
Arne Wichmann (a...@linux.de)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVV0YMAAoJEENYfBy4DUs++FAP/j6NA8gP37qu4hHTFK9rKc+3
ddj3sClTKQ3d8aC2xq3+rgxjUo35YiPgY3sdcTb4Sni5rm8acHpo0NdDlkpPdFS4
gR3nx3t0GEAqe55aLzUls6Rq9U9fWwHrhjl+Kbhr6zNR+XtXoDMj12GA3ICcJp7J
ucvMZtpbJhaTJwvqsljn7IAvjgdikAdtxiRqPXHbeAAwKYJkU5Bdlu9eB+YtXABF
IAHU8Qyc4PaJ4o/kbv+C5IBk8ILqhZPjTNSdljJryJTPBkH/R5P9VFjJs/rcSh8O
nB2bUmXcRX/+tw5GFcLvYrpivylCpQPLebp2gQjoAUuj8ARS931pGEiFxThqffP+
53F+lG/tIXpO53Yn/CpoOkGm0sjgApSRDgCwJsgy2HkUi8CN66mBt03nciEfPvG6
om60Oa0Mj+BoevtiQeaXRgXI/bsKDz57sUuhOlGY6LbfNbAWew90ns+q1CWTDW/8
uAsi8SgKjVKp3lM8f3TR73GIOMVn8lNAgnSyrbVVGke7nHO0AjwdeV/Ld6So6fWG
1ELvZyzkn/BI6V3W29IjcKlo7ncS9bv6CU1z+vToW2FPUitazS3P2cdr069KyKyH
bU8hQPkqDp2jwMMk4DDojS5ue8VhFj0yazhMKYJB7KSzjf57qgegjipEvKQlN5HT
FFVJBtD94jGVHzspGh0s
=lqqu
-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#785452: openjdk-7-jre-headless: not really headless, indirectly depends on libx11-6 and others

[Antoine Amarilli]

Package: openjdk-7-jre-headless
Severity: normal

Dear Maintainer,

openjdk-7-jre-headless depends (in version 7u79-2.5.5-1~deb8u1) on libpulse0,
which depends (in version 5.0-13) on libx11-6, libx11-xcb1, libxcb1, libxtst6,
themselves depending on other X-related packages. Hence the
openjdk-7-jre-headless package is not really "headless" -- I cannot install it
on my headless server without installing loads of GUI-related packages.

I am not sure how to solve this, but I guess one should check whether there is
good reason for these dependencies, or whether one could package separately a
headless" version of libpulse0?

Thanks!

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

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


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

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Alessandro Ghedini]

On Sat, May 16, 2015 at 03:07:57PM +0200, Sebastian Ramacher wrote:
> On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
> > On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
> > > Version: 6:11.3-1
> > > 
> > > On 2015-05-14 20:41:15, Arne Wichmann wrote:
> > > > Package: libavcodec56
> > > > Version: 6:11.3-2
> > > > Severity: grave
> > > > Tags: security
> > > > Justification: user security hole
> > > > 
> > > > Hi, as far as I can see this has not yet been reported or fixed:
> > > > 
> > > > CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c in
> > > > FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, allow
> > > > remote attackers to cause a denial of service (use-after-free) or 
> > > > possibly
> > > > have unspecified other impact via crafted Vorbis I data [1]
> > > > 
> > > > I marked this as grave as the impact is unclear and might include 
> > > > arbitrary
> > > > code execution. Feel free do downgrade if this can be ruled out.
> > > > 
> > > > (Actually I would like to have a look at the test case to check a bit 
> > > > more
> > > > thoroughly, but AFAICS I would need to talk to google for this.)
> > > > 
> > > > [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
> > > >   https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
> > > 
> > > A similar commit to the one maintained in this mailing list post was 
> > > applied to
> > > 11.3. So closing with that version.
> > 
> > Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg 
> > patch at
> > all, and the commit message doesn't even mention the bug fix. How can you 
> > be so
> > sure that the bug is fixed?
> 
> I might have read the commit wrong. Do you have a sample for this CVE?

Unfortunately the reproducer isn't public. I contacted ffmpeg-security about
it, I'll keep you posted.

Cheers


signature.asc
Description: Digital signature

Bug#785422: amd64: Please enable CONFIG_SND_SOC_INTEL_BROADWELL_MACH

[Yves-Alexis Perez]

On Sat, 16 May 2015 05:41:40 +0200 Sebastian Reichel  wrote:
> Source: linux
> Version: 4.0.2-1
> Severity: wishlist
> 
> Hi,
> 
> Please enable CONFIG_SND_SOC_INTEL_BROADWELL_MACH. Broadwell processors
> are built into e.g. the Lenovo Thinkpad X250, which is available since
> February.

I'm not speaking for the kernel team (which I'm not part of) but I own
a X250 and wrote a page [1] about Linux support. I'm unsure what
CONFIG_SND_SOC_INTEL_BROADWELL_MACH is supposed to be used for, but
it's not needed for sound support on X250.

At first sight this option looks related to Intel Smart Sound Technology
(Intel SST) which looks to be a specific DSP for usages a bit like Siri
on the iOS platforms.

I don't think the CPU in the X250 has this technology, althought it
might be useful for Core M Broadwell ultrabooks.

In any case, loading the modules on my X250 doesn't do anything and
don't show anything in dmesg either.

So I don't say enabling it is bad, but I don't think it'll improve the
experience on your ThinkPad.

[1] http://www.corsac.net/X250/

Regards,
-- 
Yves-Alexis


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

Bug#785453: ITP: postgresql-mysql-fdw -- an extension for Postgres to access MySQL

[Markus Wanner]

Subject: ITP: postgresql-mysql-fdw -- an extension for Postgres to access MySQL
Package: wnpp
Severity: wishlist
Owner: Markus Wanner 

* Package name: postgresql-mysql-fdw
  Version : 2.0.1
  Upstream Author : EnterpriseDB Corporation 
* URL : https://github.com/EnterpriseDB/mysql_fdw
* License : PostgreSQL (modified)
  Programming Lang: C
  Description : MySQL Foreign Data Wrapper for PostgreSQL

postgresql-mysql-fdw is a PostgreSQL extension implementing a Foreign Data
Wrapper (FDW) to access MySQL data from PostgreSQL.

Regards

Markus Wanner



signature.asc
Description: OpenPGP digital signature

Bug#784619: [creepy] Qt4's WebKit removal

[Ross Gammon]

Control: tags -1 upstream
Control: forwarded 784619 https://github.com/jkakavas/creepy/issues/9

Hi,

I have asked upstream about the state of QT4/5 support in Creepy.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#785454: update package description

[Osamu Aoki]

Source: fonts-ipafont
Version: 00303-12
Severity: normal

For ordinary people, the differences between:
 fonts-ipafont-mincho
 fonts-ipaexfont-mincho
 fonts-ipamj-mincho
are difficult to figure out from their package description since they
are not synchronized.  I read the upstream web site and summarized them
in the consistent set of the description.  I hope the differences are
clear from this updated package description.

I attach my patch against the jessie package.

(Excuse me, I also swapped order of Mincho and Gothic in debian/control to
make this consistent with upstream web site and all other part of
documentation.)

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

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

-- no debconf information
diff -Nru fonts-ipafont-00303.orig/debian/control fonts-ipafont-00303/debian/control
--- fonts-ipafont-00303.orig/debian/control	2013-06-16 03:23:02.0 +0900
+++ fonts-ipafont-00303/debian/control	2015-05-16 21:26:38.635730136 +0900
@@ -16,39 +16,13 @@
 Depends: ${misc:Depends}, fonts-ipafont-gothic, fonts-ipafont-mincho
 Breaks: ttf-ipafont (<= 00203-13), otf-ipafont (<< 00303-1)
 Replaces: otf-ipafont (<< 00303-1)
-Description: Japanese OpenType font set, IPAfont
- IPAfont is a Japanese OpenType, a scalable font which was developed to 
- supersede both the TrueType and the Type 1 ("PostScript") font formats,
- font set that is provided by Information-technology Promotion Agency, 
- Japan (IPA).
+Description: Japanese OpenType font set, all IPA Fonts
+ IPA Fonts are JIS X 0213:2004 compliant OpenType fonts based on TrueType
+ outlines provided by Information-technology Promotion Agency, Japan
+ (IPA) from 2003.  These are suitable for both display and printing.
  .
- IPAfont is an outline font set suitable for both display and printing.
- .
- This is metapackage that depends on gothic and mincho font packages.
-
-Package: fonts-ipafont-gothic
-Architecture: all
-Multi-Arch: foreign
-Pre-Depends: dpkg (>= 1.15.6~), ${misc:Pre-Depends}
-Depends: ${misc:Depends}
-Recommends: fonts-ipafont-mincho
-Breaks: ttf-ipafont (<= 00203-13), otf-ipafont (<= 00301-4), otf-ipafont-gothic (<< 00303-1)
-Replaces: otf-ipafont-gothic (<< 00303-1)
-Provides: fonts-japanese-gothic
-Description: Japanese OpenType font set, IPA Gothic font
- IPAfont is a Japanese OpenType, a scalable font which was developed to 
- supersede both the TrueType and the Type 1 ("PostScript") font formats,
- font set that is provided by Information-technology Promotion Agency, 
- Japan (IPA).
- .
- IPAfont is an outline font set suitable for both display and printing.
- .
- It comes with 2 styles in it. Equal-width and propotional styles are 
- provided for Gothic (san-serif) styles.  It is known for its quality and 
- formal style and consists of IPA Gothic and IPA P Gothic.
- .
- It covers practically every characters used in Japanese business
- environments, i.e. about 11,000 characters based on JIS X 0213:2004.
+ This metapackage depends on fonts-ipafont-{mincho,gothic} packages to
+ provide IPA Mincho, IPA P Mincho, IPA Gothic, and IPA P Gothic Fonts.
 
 Package: fonts-ipafont-mincho
 Architecture: all
@@ -59,18 +33,36 @@
 Breaks: ttf-ipafont (<= 00203-13), otf-ipafont (<= 00301-4), otf-ipafont-mincho (<< 00303-1)
 Replaces: otf-ipafont-mincho (<< 00303-1)
 Provides: fonts-japanese-mincho
-Description: Japanese OpenType font set, IPA Mincho font
- IPAfont is a Japanese OpenType, a scalable font which was developed to 
- supersede both the TrueType and the Type 1 ("PostScript") font formats,
- font set that is provided by Information-technology Promotion Agency, 
- Japan (IPA).
- .
- IPAfont is an outline font set suitable for both display and printing.
- .
- It comes with 2 styles in it. Equal-width and propotional styles
- are provided for Mincho (serif) style.  It is known for its quality and 
- formal style and consists of IPA Mincho and IPA P Mincho.
- .
- It covers practically every characters used in Japanese business
- environments, i.e. about 11,000 characters based on JIS X 0213:2004.
+Description: Japanese OpenType font set, IPA Mincho and IPA P Mincho Fonts
+ IPA Fonts are JIS X 0213:2004 compliant OpenType fonts based on TrueType
+ outlines provided by Information-technology Promotion Agency, Japan
+ (IPA) from 2003.  These are suitable for both display and printing.
+ .
+ This package provides Mincho (serif) style fonts.  IPA Mincho Font
+ is the equal-width font.  IPA P Mincho Font is the propotional font.
+ .
+ In the equal-width font, the fullwidth characters (most CJK characters)
+ occupy exactly twice as much width of the halfwidth characters (normal
+ alphabets and numbers).
+
+Package: fonts-ipafont-gothic
+Architecture: all
+Multi-Arch

Bug#785455: update package description

[Osamu Aoki]

Source: fonts-ipaexfont
Version: 00201-4
Severity: normal

For ordinary people, the differences between:
 fonts-ipafont-mincho
 fonts-ipaexfont-mincho
 fonts-ipamj-mincho
are difficult to figure out from their package description since they
are not synchronized.  I read the upstream web site and summarized them
in the consistent set of the description.  I hope the differences are
clear from this updated package description.

I attach my patch against the jessie package.

The use of IPAex Mincho over IPAexMincho is the intentional one
following upstream web site.

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

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

-- no debconf information
diff -Nru fonts-ipaexfont-00201.orig/debian/control fonts-ipaexfont-00201/debian/control
--- fonts-ipaexfont-00201.orig/debian/control	2013-06-16 03:18:59.0 +0900
+++ fonts-ipaexfont-00201/debian/control	2015-05-16 22:31:06.383748830 +0900
@@ -16,15 +16,21 @@
 Depends: ${misc:Depends}, fonts-ipaexfont-gothic, fonts-ipaexfont-mincho
 Breaks: otf-ipaexfont (<< 00103-4)
 Replaces: otf-ipaexfont (<< 00103-4)
-Description: Japanese OpenType font, IPAexFont (IPAexGothic/Mincho)
+Description: Japanese OpenType font, all IPAex Fonts
  IPAex Fonts are JIS X 0213:2004 compliant OpenType fonts based on TrueType
- outlines.
+ outlines provided by Information-technology Promotion Agency, Japan
+ (IPA) from 2010.  The older JIS X 0213:2000 font gliphs are also
+ supported via IVS (Ideographic Variation Sequence).  These are suitable
+ for both display and printing.
+ .
+ These new fonts are developed from IPA Fonts to provide the best balance
+ for the Japanese documentation mixed with Western characters by following
+ Japanese printing tradition.  Japanese characters (Kanji, Kana and
+ punctuation marks) are full width mono-space pitch, and Western characters
+ are proportional pitch.
  .
- IPAexFont pursues the optimized quality for document readability. Western
- characters are proportional style and Japanese Kana, Kanji characters and 
- symbols are full width fixed width style.
- .
- This is metapackage, depends on fonts-ipaexfont-{mincho,gothic} packages.
+ This metapackage depends on fonts-ipaexfont-{mincho,gothic} packages to
+ provide IPAex Mincho and IPAex Gothic Fonts.
 
 Package: fonts-ipaexfont-mincho
 Architecture: all
@@ -35,15 +41,18 @@
 Provides: fonts-japanese-mincho
 Breaks: otf-ipaexfont-mincho (<< 00103-4)
 Replaces: otf-ipaexfont-mincho (<< 00103-4)
-Description: Japanese OpenType font, IPAexFont (IPAexMincho)
+Description: Japanese OpenType font, IPAex Mincho Font
  IPAex Fonts are JIS X 0213:2004 compliant OpenType fonts based on TrueType
- outlines.
+ outlines provided by Information-technology Promotion Agency, Japan
+ (IPA) from 2010.  These are suitable for both display and printing.
  .
- IPAexFont pursues the optimized quality for document readability. Western
- characters are proportional style and Japanese Kana, Kanji characters and 
- symbols are full width fixed width style.
+ These new fonts are developed from IPA Fonts to provide the best balance
+ for the Japanese documentation mixed with Western characters by following
+ Japanese printing tradition.  Japanese characters (Kanji, Kana and
+ punctuation marks) are full width mono-space pitch, and Western characters
+ are proportional pitch.
  .
- This package contains IPAexMincho font.
+ This package provides IPAex Mincho Font in the Mincho (serif) style.
 
 Package: fonts-ipaexfont-gothic
 Architecture: all
@@ -54,13 +63,16 @@
 Provides: fonts-japanese-gothic
 Breaks: otf-ipaexfont-gothic (<< 00103-4)
 Replaces: otf-ipaexfont-gothic (<< 00103-4)
-Description: Japanese OpenType font, IPAexFont (IPAexGothic)
+Description: Japanese OpenType font, IPAex Gothic Font
  IPAex Fonts are JIS X 0213:2004 compliant OpenType fonts based on TrueType
- outlines.
+ outlines provided by Information-technology Promotion Agency, Japan
+ (IPA) from 2010.  These are suitable for both display and printing.
  .
- IPAexFont pursues the optimized quality for document readability. Western
- characters are proportional style and Japanese Kana, Kanji characters and 
- symbols are full width fixed width style.
+ These new fonts are developed from IPA Fonts to provide the best balance
+ for the Japanese documentation mixed with Western characters by following
+ Japanese printing tradition.  Japanese characters (Kanji, Kana and
+ punctuation marks) are full width mono-space pitch, and Western characters
+ are proportional pitch.
  .
- This package contains IPAexGothic font.
+ This package provides IPAex Gothic Font in the Gothic (san-serif) style.
 

Bug#785456: update package description

[Osamu Aoki]

Source: fonts-ipamj-mincho
Version: 003.01-1
Severity: normal

For ordinary people, the differences between:
 fonts-ipafont-mincho
 fonts-ipaexfont-mincho
 fonts-ipamj-mincho
are difficult to figure out from their package description since they
are not synchronized.  I read the upstream web site and summarized them
in the consistent set of the description.  I hope the differences are
clear from this updated package description.

I attach my patch against the jessie package.

FYI: I filed bug report for other packages too.

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

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

-- no debconf information
diff -Nru fonts-ipamj-mincho-003.01.orig/debian/control fonts-ipamj-mincho-003.01/debian/control
--- fonts-ipamj-mincho-003.01.orig/debian/control	2014-10-01 11:30:32.0 +0900
+++ fonts-ipamj-mincho-003.01/debian/control	2015-05-16 22:57:02.803756352 +0900
@@ -13,6 +13,16 @@
 Architecture: all
 Depends: ${misc:Depends}
 Multi-Arch: foreign
-Description: Japanese OpenType font, IPAmj Mincho font
- IPAmj Mincho font is an OpenType font of the TrueType base 
- based on ISO/IEC10646.
+Description: Japanese OpenType font, IPAmj Mincho Font
+ IPAmj Mincho Font is ISO/IEC10646:2014 compliant OpenType font based on
+ TrueType outlines supporting IVS (Ideographic Variation Sequence)
+ provided by Information-technology Promotion Agency, Japan (IPA) from
+ 2014.
+ .
+ IPAmj Mincho Font is designed to distinguish minute gliph differences of
+ the person's name etc.  This font requires to use applications which are
+ compatible with the UCS code point beyond 16 bits and IVS.  For the normal
+ use, any one of IPAex fonts that conforms to JIS X 0213:2004 is
+ recommended.
+ .
+ There is no IPAmj Gothic Font.

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Bálint Réczey]

2015-05-16 15:31 GMT+02:00 Sebastian Ramacher :
> On 2015-05-16 15:28:44, Arne Wichmann wrote:
>> begin  quotation  from Sebastian Ramacher (in 
>> <20150516130757.ga21...@ramacher.at>):
>> > On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
>> > > On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
>> > > > Version: 6:11.3-1
>> > > >
>> > > > On 2015-05-14 20:41:15, Arne Wichmann wrote:
>> > > > > Package: libavcodec56
>> > > > > Version: 6:11.3-2
>> > > > > Severity: grave
>> > > > > Tags: security
>> > > > > Justification: user security hole
>> > > > >
>> > > > > Hi, as far as I can see this has not yet been reported or fixed:
>> > > > >
>> > > > > CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c 
>> > > > > in
>> > > > > FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, 
>> > > > > allow
>> > > > > remote attackers to cause a denial of service (use-after-free) or 
>> > > > > possibly
>> > > > > have unspecified other impact via crafted Vorbis I data [1]
>> > > > >
>> > > > > I marked this as grave as the impact is unclear and might include 
>> > > > > arbitrary
>> > > > > code execution. Feel free do downgrade if this can be ruled out.
>> > > > >
>> > > > > (Actually I would like to have a look at the test case to check a 
>> > > > > bit more
>> > > > > thoroughly, but AFAICS I would need to talk to google for this.)
>> > > > >
>> > > > > [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
>> > > > >   
>> > > > > https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
>> > > >
>> > > > A similar commit to the one maintained in this mailing list post was 
>> > > > applied to
>> > > > 11.3. So closing with that version.
>> > >
>> > > Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg 
>> > > patch at
>> > > all, and the commit message doesn't even mention the bug fix. How can 
>> > > you be so
>> > > sure that the bug is fixed?
>> >
>> > I might have read the commit wrong. Do you have a sample for this CVE?
>>
>> There is one referenced in various messages relating to CVE-2014-7937:
>> asan_heap-uaf_18dac2b_9_asan_heap-uaf_22eb375_208_beta3_test_small.ogg
>> unfortunately it is not publicly available AFAICS. You might ask upstream
>> about it.
>
> I did. libav developers do not seem to have it. So please provide a sample.
Why don't you/they ask FFmpeg upstream directly?

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#766867: On "NameError: global name 'SSLContext' is not defined"

[eular frank]

The bug still remains in 1.0.1-2, but could be easily fixed. I've attached
the patch file. Hope it's fixed by the maintainer as soon as possible.

Best wishes!
Sincerely,
--- ssl.py.old	2015-05-16 22:21:40.976210265 +0800
+++ ssl.py	2015-05-16 22:19:30.268996051 +0800
@@ -81,7 +81,7 @@ class SSLSocket(socket):
 self._sslobj = None
 else:
 # yes, create the SSL object
-ctx = SSLContext(ssl_version)
+ctx = __ssl__.SSLContext(ssl_version)
 if keyfile or certfile:
 ctx.load_cert_chain(certfile, keyfile)
 if ca_certs:

Bug#706305: Amazon AMI HVM images already available

[Ognyan Kulev]

I think this bug should be closed. There are official HVM images: 
https://aws.amazon.com/marketplace/pp/B00WUNJIEE/


All the best,
Ognyan



signature.asc
Description: OpenPGP digital signature

Bug#785451: [pkg-cinnamon] Bug#785451: cinnamon-control-center: Incompatible with network-manager >= 1.0

[Fabio Fantoni]

Il 16/05/2015 15:24, Philipp Trulson ha scritto:
> Package: cinnamon-control-center
> Version: 2.4.2+betsy
> Severity: normal
>
> Dear Maintainer,
>
> I set up Debian 8 Cinnamon with afterwards upgrading to testing and unstable. 
> Now I wanted to start a 802.1x WiFi-connection (eduroam at my university) but 
> a message pops up saying the system's network services are not compatible 
> with this version.
>
> I upgraded to Cinnamon 2.4 from the Linux Mint repos, but that didn't help. 
> The problem is a version check in the control center which doesn't work with 
> network-manager >= 1.0, see here:
> https://github.com/linuxmint/cinnamon-control-center/pull/107
>
> I don't know how to apply such a patch, please fix this.

Debian official packages from experimental should works correctly
because I already fixed it including this patch:
http://anonscm.debian.org/cgit/pkg-cinnamon/cinnamon-control-center.git/tree/debian/patches/Remove-the-NetworkManager-version-checking.patch?h=experimental
You instead seems are using other packages without this patch (that make
c-c-c working with newer network-manager), upstream applied it only for 2.6.

>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages cinnamon-control-center depends on:
> ii  accountsservice   0.6.37-3+b1
> ii  apg   2.2.3.dfsg.1-2
> ii  cinnamon-control-center-data  2.4.2+betsy
> ii  cinnamon-desktop-data 2.4.2+betsy
> ii  cinnamon-settings-daemon  2.4.3.betsy1+betsy
> ii  cinnamon-translations 2.4.4+betsy
> ii  desktop-file-utils0.22-1
> ii  gnome-icon-theme  3.12.0-1
> ii  gnome-icon-theme-symbolic 3.12.0-1
> ii  libatk1.0-0   2.16.0-2
> ii  libc6 2.19-18
> ii  libcairo-gobject2 1.14.2-2
> ii  libcairo2 1.14.2-2
> ii  libcanberra-gtk3-00.30-2.1
> ii  libcanberra-pulse 0.30-2.1
> ii  libcanberra0  0.30-2.1
> ii  libcinnamon-control-center1   2.4.2+rebecca
> ii  libcinnamon-desktop0  2.4.2+betsy
> ii  libcinnamon-menu-3-0  2.4.0+betsy
> ii  libcolord21.2.1-1+b2
> ii  libdbus-1-3   1.8.18-1
> ii  libdbus-glib-1-2  0.102-1
> ii  libfontconfig12.11.0-6.3
> ii  libfreetype6  2.5.2-4
> ii  libgdk-pixbuf2.0-02.31.1-2+b1
> ii  libglib2.0-0  2.44.0-3
> ii  libgnomekbd8  3.6.0-1
> ii  libgtk-3-03.14.5+4
> ii  libmm-glib0   1.4.8-1
> ii  libnm-glib-vpn1   1.0.2-2
> ii  libnm-glib4   1.0.2-2
> ii  libnm-gtk01.0.2-1
> ii  libnm-util2   1.0.2-2
> ii  libnotify40.7.6-2
> ii  libpango-1.0-01.36.8-3
> ii  libpangocairo-1.0-0   1.36.8-3
> ii  libpolkit-gobject-1-0 0.105-8
> ii  libpulse-mainloop-glib0   6.0-2
> ii  libpulse0 6.0-2
> ii  libupower-glib3   0.99.2-3
> ii  libwacom2 0.8-1
> ii  libx11-6  2:1.6.3-1
> ii  libxi62:1.7.4-1+b2
> ii  libxklavier16 5.2.1-1
> ii  libxml2   2.9.2+dfsg1-3
>
> Versions of packages cinnamon-control-center recommends:
> ii  cups-pk-helper 0.2.5-2+b1
> ii  iso-codes  3.57-1
> ii  mesa-utils 8.2.0-1
> ii  mousetweaks3.12.0-1
> ii  policykit-1-gnome  0.105-2
>
> Versions of packages cinnamon-control-center suggests:
> ii  gstreamer0.10-pulseaudio  0.10.31-3+nmu4+b1
> pn  libcanberra-gtk-module
> ii  x11-xserver-utils 7.7+4
>
> -- Configuration Files:
> /etc/xdg/autostart/cinnamon-sound-applet.desktop 
> 33ec8b1b6c4ce98aa2300cf0971e9922 [Errno 2] Datei oder Verzeichnis nicht 
> gefunden: u'/etc/xdg/autostart/cinnamon-sound-applet.desktop 
> 33ec8b1b6c4ce98aa2300cf0971e9922'
>
> -- no debconf information
>
> https://lists.alioth.debian.org/mailman/listinfo/pkg-cinnamon-team
> to unsubscribe: 
> mailto:pkg-cinnamon-team-requ...@lists.alioth.debian.org?subject=unsubscribe
>
>
> -
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2014.0.4800 / Database dei virus: 4311/9789 -  Data di rilascio: 
> 16/05/2015
>
>




smime.p7s
Description: Firma crittografica S/MIME

Bug#785457: cloud.debian.org: AMI don't need getty

[Ognyan Kulev]

Package: cloud.debian.org
Severity: wishlist
User: cloud.debian@packages.debian.org
Usertags: image
Usertags: aws

Hi,

While fine-tuning the Debian 8.0.0 HVM AMI, I noticed that getty 
processes fill up space in the otherwise short default process list, so 
I disabled these with:


systemctl mask getty@tty{1,2,3,4,5,6}.service
systemctl mask serial-getty@{hvc0,ttyS0}.service
systemctl mask getty-static.service

I don't see any reason for having getty support in AMI. I think these 
should be disabled.


All the best,
Ognyan



signature.asc
Description: OpenPGP digital signature

Bug#785458: xserver-xorg-video-intel: corrupted rendering of xfonts-terminus-oblique in rxvt-unicode

[Giuseppe Bilotta]

Package: xserver-xorg-video-intel
Version: 2:2.99.917-1
Severity: normal

I've recently upgraded to the latest Xorg and Xorg intel driver in sid,
and I've noticd corrupted rendering of the terminus-oblique
font in my terminal (rxvt-unicode-256color). The problem is consistent,
in the form of missing pixels in the upper right areas of each glyph,
manifests right from the start of the session, is independent of the
kernel version (linux 3.16 or 4.0), and does not present itself when I
force xorg to use the modesetting driver instead.

The rendering issue only seems to appear in rxvt-unicode and
rxvt-unicode-256color though (e.g. not in konsole or gnome-terminal, nor
in xterm or xfontsel).


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Aug  9  2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2384712 May  5 01:24 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so 
by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv

Bug#751498: python-greenlet FTBFS on arm* is fixed in Sid as well

[GCS]

Control: -1 - sid stretch

Hi Ivo,

It was fixed a while ago for Sid as well.

Regards,
Laszlo/GCS


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

Bug#785459: stopmotion: crashes when launching vgrabbj in daemon mode

[Georges Khaznadar]

Package: stopmotion
Version: 0.8.0-4
Severity: important
Tags: patch

Dear Maintainer,

stopmotion sadly crashes when I try to activate the camera input.
The error message states that the command "vgrabbj" triggered some error.

However I can see than vgrabbj remains launched in daemon mode when
stopmotion is closed.

I could fix this issue by accepting a return code 256, which vgrabbj
spits out when it forks.



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

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

Versions of packages stopmotion depends on:
ii  libc62.19-13
ii  libgcc1  1:4.9.1-19
ii  libqtcore4   4:4.8.6+git155-g716fbae+dfsg-2
ii  libqtgui44:4.8.6+git155-g716fbae+dfsg-2
ii  libsdl-image1.2  1.2.12-5+b5
ii  libsdl1.2debian  1.2.15-10
ii  libstdc++6   4.9.1-19
ii  libtar0  1.2.20-4+b1
ii  libvorbisfile3   1.3.4-1
ii  libx11-6 2:1.6.2-3
ii  libxml2  2.9.1+dfsg1-5

Versions of packages stopmotion recommends:
ii  dvgrab   3.5-2+b2
ii  ffmpeg   10:2.6-dmo1
ii  vgrabbj  0.9.8-3+b1

Versions of packages stopmotion suggests:
ii  gimp  2.8.14-1+b1

-- no debconf information
--- stopmotion-0.8.0.orig/src/technical/audio/ossdriver.cpp
+++ stopmotion-0.8.0/src/technical/audio/ossdriver.cpp
@@ -119,7 +119,7 @@ bool OSSDriver::initialize()
 	// Storing the request and its argument
 	int initValues[2][4] = 
 	{ 
-		{SNDCTL_DSP_RESET, SNDCTL_DSP_SETFMT, SOUND_PCM_WRITE_CHANNELS, SOUND_PCM_WRITE_RATE},
+		{SNDCTL_DSP_RESET, SNDCTL_DSP_SETFMT, SNDCTL_DSP_CHANNELS, SNDCTL_DSP_SPEED},
 		{1, AFMT_S16_LE, 2, 44100} 
 	};
 	
--- stopmotion-0.8.0.orig/src/technical/grabber/commandlinegrabber.cpp
+++ stopmotion-0.8.0/src/technical/grabber/commandlinegrabber.cpp
@@ -82,10 +82,12 @@ bool CommandLineGrabber::init() {
 		if (startProcess != "") {
 			Logger::get().logDebug("Attempting to start process");
 			int r = system(startProcess.c_str());
-			if (r != 0) {
+			if ((r != 0) && (r != 256)) {
+			// r==256 is possible for vgrabbj in daemon mode
 Logger::get().logFatal(
 		"Grab start process '%s' returned code %d",
 		startProcess.c_str(), r);
+return true;
 			} else {
 return true;
 			}

Bug#751498: python-greenlet FTBFS on arm* is fixed in Sid as well

[GCS]

Control: tags -1 - sid stretch


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

Bug#776232: RFS: xcffib/0.1.10-2

[Andrey Rahmatullin]

Having Description: in the source package stanza in d/control is
incorrect, and dpkg-source warns about it.

You don't need to prepend debian/tmp to paths in *.install. Though with pybuild
you usually don't need *.install at all.

The package FTBFS in sbuild:

dh build --with python2,python3 --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:170: python2.7 setup.py config 
running config
I: pybuild base:170: python3.4 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/«PKGBUILDDIR»'
make xcffib
make[2]: Entering directory '/«PKGBUILDDIR»'
cabal configure --enable-tests
Config file path source is default config file.
Config file /sbuild-nonexistent/.cabal/config not found.
Writing default configuration to /sbuild-nonexistent/.cabal/config
cabal: /sbuild-nonexistent/.cabal: does not exist
make[2]: *** [dist] Error 1


-- 
WBR, wRAR


signature.asc
Description: Digital signature

Bug#785407: Now it works

[Felix Lechner]

Now it works. Thank you!

Bug#750743: gspiceui: Please update to use wxwidgets3.0

[Olly Betts]

On Fri, May 15, 2015 at 07:40:46PM +0200, Gudjon I. Gudjonsson wrote:
> Thanks, in fact I do need some assistance.
> I have compiled version 1.1.00 and the source can be found at
> dget http://gudjon.org/debian/source/gspiceui_1.1.00+dfsg-1.dsc

http://gudjon.org/debian/source/gspiceui_1.1.00+dfsg.orig.tar.gz is
404...

Cheers,
Olly


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

Bug#766352: transition: libplist

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On 2014-10-22 14:18, Chow Loong Jin wrote:
libplist recently has had an ABI bump with the new upstream release, 
changing

libplist.so.2 -> libplist.so.3 and libplist++.so.2 -> libplist++.so.3.


Do all reverse dependencies build successfully with the new SONAME? The 
list can be found at 
https://release.debian.org/transitions/html/libplist.html


Thanks,

--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits


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

Bug#776539: RFS: scythe/0.994-1 [ITP] -- Bayesian adaptor trimmer for sequencing reads

[Andrey Rahmatullin]

Your changelog entry has UNRELEASED as a distribution, you shoudl change
that before publishing if you ask for sponsorship and not just a review
(though it's not a problem for a sponsor to edit that before uploading).

You should have a section for debian/* in d/copyright.

You don't need to use DPKG_EXPORT_BUILDFLAGS and
/usr/share/dpkg/buildflags.mk when using dh_auto_* in compat levels 9+.

You are creating debian/scythe.1 but not cleaning it so it ends up in
debian.tar which is wrong.

Your d/watch doesn't work.

You should use
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ as the
copyright format URL (lintian detects this).

The upstream Makefile ignores CPPFLAGS from the environment so fortify
dpkg-buildflags feature doesn't work (lintian detects this).

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Bug#785460: regression: screen brightness no longer saved on logout or restart

[Robert Lange]

Package: xorg
Version: 1:7.7+9
Severity: normal

Dear Maintainer,

I have a Thinkpad w540. I use the Intel graphics and have the Nvidia card off.
I usually leave the screen at 50% brightness to conserve battery, and because
the screen to very bright.

I use testing and run apt-get dist-upgrade daily. Yesterday (2015-05-15) I got
an upgrade to Xorg. A few hours later, I rebooted and immediately noticed that
the screen was at 100% brightness. As a test, I reset the brightness to 50% and
logged out of my session. Sure enough, as soon as the login screen appeared,
the screen was back up to 100% brightness.

I will stress that this is a regression, because prior to yesterday, the screen
brightness was saved between sessions. I will also point out that the
brightness controls still work properly, it's just that the brightness setting
is no longer saved on logout or restart.



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 May  9  2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2384712 May  4 19:24 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so 
by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libG

Bug#777586: RFS: crosswalk/11.40.277.2-1 [ITP]

[Andrey Rahmatullin]

On Tue, Feb 10, 2015 at 05:06:49PM +0800, Xinchao He wrote:
> It builds those binary packages:
> 
> crosswalk  - HTML5 web runtime
That's probably too short/vague.

> To access further information about this package, please visit the following 
> URL:
> 
>   http://mentors.debian.net/package/crosswalk
Even that page shows you have a lot of lintian-detected problems, some of
them errors. Please don't publish packages before checking them with
lintian and fixing problems reported by it.

> More information about Crosswalk can be obtained from 
> https://crosswalk-project.org/.
From
https://github.com/crosswalk-project/crosswalk-website/wiki/Downstream-Chromium 
:

"Crosswalk uses forked versions of Chromium repositories (for example
Blink and Chromium)"

We do not allow such things in the archive, unfortunately.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Bug#785281: Split phpseclib?

[David Prévot]

[ Following up to #785281 only, all recipient should get the message
  from it (once). ]

Hi Mathieu,

Le 16/05/2015 08:07, Mathieu Parent a écrit :

> There are three problems here:
[…]
> 2./ The current package name from composer should be php-phpseclib
> instead. I will file a bug about this.

There is already #757537. If that’s enough, I can try and work on it.

> 3./ The php-phpseclib should "provide" all the libraries it ships.
> This would be the proper fix for #785281.

I can prepare that (with a temporary workaround for #757537 too). Since
php-horde-mapi currently depends on php-math-biginteger (>= 1.0.2),
php-math-biginteger (<< 2.0.0) (i.e. the older version from PEAR, but
with a higher version), I’m not sure how we should move forward.

A priori, versionless provides won’t be enough to satisfy the
php-horde-mapi dependency, so just adding versionless provides for all
the packages available from the phpseclib channel won’t be enough to fix
this issue.

Since versionless provides is not enough, using the phpseclib version
(currently lower than 1) for all provided packages will not help
satisfying the current php-horde-mapi dependency either. I could also
add another fake “provides: php-math-biginteger (= 1.0.2-3)” for example
(i.e., a bit higher than the current php-math-biginteger real package),
or you could patch php-horde-mapi to drop the versionned dependency for
php-math-biginteger.

Please let me know if you prefer me to add this additional hack into
phpseclib, or if you’re willing to drop the versionned dependency from
php-horde-mapi.

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#785461: ITP: bzrtp -- Library for the ZRTP key exchange protocol

[Felix Lechner]

Package: wnpp
Severity: wishlist
Owner: Felix Lechner 

* Package name: bzrtp
  Version : 1.0.2
  Upstream Author : Simon Morlat 
* URL : http://www.linphone.org/
* License : GPL-2+
  Programming Lang: C
  Description : Library for the ZRTP key exchange protocol

This package is part of Linphone, but is packaged separately. Like Linphone it
will be maintained by the Debian VOIP Team.

This new library enables certain encrypted communications in Linphone.


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

Bug#775876: ITP: crosswalk -- Crosswalk is an app runtime based on Chromium/Blink

[Andrey Rahmatullin]

On Wed, Jan 21, 2015 at 10:16:58AM +0800, Xinchao He wrote:
>   Description : Crosswalk is an app runtime based on Chromium/Blink
Looks like it's "based" on it by embedding a patched code copy, which is
not acceptable in Debian, especially for copies of Chromium/Blink.
See
https://github.com/crosswalk-project/crosswalk-website/wiki/Downstream-Chromium

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Bug#785349: transition: hiredis

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On 2015-05-16 12:23, Tom Lee wrote:

Confirmed the webdis segfault is due to an ABI change.


That'll need sorting out before the transition begins please.

Thanks,

--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits


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

Bug#785462: RFP: node-os-tmpdir -- Node.js os.tmpdir() ponyfill

[Bas Couwenberg]

Package: wnpp
Severity: wishlist

* Package name: node-os-tmpdir
  Version : 1.0.1
  Upstream Author : Sindre Sorhus  (sindresorhus.com)
* URL : https://github.com/sindresorhus/os-tmpdir
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js os.tmpdir() ponyfill

os-tmpdir is a Node.js module providing os.tmpdir() ponyfill.

Ponyfill: A polyfill that doesn't overwrite the native method.

Use this instead of require('os').tmpdir() to get a consistent behaviour
on different Node.js versions (even 0.8).


node-os-tmpdir is required for node-tmp >= 0.0.26.


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

Bug#785460: (no subject)

[Robert Lange]

When I set the brightness manually, I run the following and see:

$ ls -1 /sys/class/backlight/*/*brightness | xargs -I % sh -c "echo % ;
cat %"

/sys/class/backlight/intel_backlight/actual_brightness
2219
/sys/class/backlight/intel_backlight/brightness
2219
/sys/class/backlight/intel_backlight/max_brightness
4438

However, when I logout and log back in (or reboot) and run the command,
I see:

$ ls -1 /sys/class/backlight/*/*brightness | xargs -I % sh -c "echo % ;
cat %"

/sys/class/backlight/intel_backlight/actual_brightness
4438
/sys/class/backlight/intel_backlight/brightness
4438
/sys/class/backlight/intel_backlight/max_brightness
4438

There is a systemd file which apparently stores the brightness for
restoration during reboot.

$ cat
/var/lib/systemd/backlight/pci-\:00\:02.0\:backlight\:intel_backlight
4438

I tried manually editing the file to 2219, but upon logout and login or
reboot, the brightness was still restored to maximum and the file was
restored to 4438.


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