Bug#792864: ITA: node-minimist -- Argument options parsing for Node.js

[rossgammon]

Control: owner 792864 !

Bug#795933: ITP: astrometry-data-tycho2 -- Star catalogs for astrometry.net from Tycho-2

[Ole Streicher]

Package: wnpp
Owner: Ole Streicher 
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org

* Package name: astrometry-data-tycho2
  Version : 41
  Upstream Author : Dustin Lang
* URL : http://data.astrometry.net/
* License : To Be Investigated
  Description : Star catalogs for astrometry.net from Tycho-2
 Astrometry.net needs complete catalogs of star positions, which
 are provided with several resolutions in these packages.

This catalogue has a much smaller footprint than the 2MASS catalog
and may be packaged locally instead of downloaded. However, the license
is unclear; the catalog hoster (Centre de Données astronomiques de
Strasbourg [1]) seems to use a science-related,
commercial-restricted license for their catalogs, which already caused
a lengthy discussion about the same catalog for kstars [2]. However,
the discussion there was about the catalog hoster, not the catalog
itself For this, I started to contact the original author and will
start a dicussion within the astronomy community to see if and how we
can free the catalog (kstars will then benefit as well).

The package will be maintained within the Debian Astronomy Team.

Best regards

Ole

[1]  http://cds.u-strasbg.fr/
[2] https://bugs.debian.org/681654

Bug#791118: nmu diff for libetonyek 0.1.3-1.1

[Rene Engelhard]

Hi Julien,

On Mon, Aug 17, 2015 at 09:04:35PM +0200, Julien Cristau wrote:
> I've prepared a NMU for libetonyek, to deal with the libstdc++ transition,
> and will shortly upload it to the 1-day delayed queue.  Please find the
> debdiff below.

This is one of the import libs I talked about yesterday where the LO
import tests still pass with the not-rebuilt library. As also for libcdr,
where Steve said it's not needed (see #791102).

Same for libabw, libmwaw. (libpagemaker afaics isn't in the unit tests
yet although it has a data file)

Always wanted to reply to those bugs but then forgot, sorry..

Regards,

Rene

Bug#795932: dh-rebar: [arm64] unrecognized command line option '-m64'

[Philipp Huebner]

Package: dh-rebar
Version: 0.0.4
Severity: important

Hi,

if you look at [1], you see a pattern:
compilation on arm64 fails because the unrecognized command line option
'-m64' gets set.

I don't know where this comes from, so feel free to reassign this
bugreport to the correct package if you know / find out.

Regards,
Philipp


[1]
https://buildd.debian.org/status/package.php?p=erlang-p1-sip%2Cerlang-p1-tls%2Cerlang-p1-xml%2Cerlang-p1-yaml%2Cerlang-sqlite3

Bug#795931: www.debian.org: incorrect encoding in DPL Platform: Neil McGovern

[Edward Betts]

Package: www.debian.org
Severity: normal
Tags: patch

This page contains a '£' symbol encoded with latin-1, it should be 'utf-8':

https://www.debian.org/vote/2015/platforms/neilm

I've attached a patch for english/vote/2015/platforms/neilm.wml to fix it.

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

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

-- 
Edward.
diff --git a/english/vote/2015/platforms/neilm.wml.orig 
b/english/vote/2015/platforms/neilm.wml
index c984392..aa11628 100644
--- a/english/vote/2015/platforms/neilm.wml.orig
+++ b/english/vote/2015/platforms/neilm.wml
@@ -236,7 +236,7 @@ engage with teams and the project on public 
lists, as this is
 one of our fundamental priorities.
 
 I will spend some money we have horded. Debian currently
-holds approximately �200,000 at SPI alone. Our donators didn't give us money
+holds approximately £200,000 at SPI alone. Our donators didn't give us money
 for it to be sat around in a bank account, we should spend it to make the
 project more successful.
 

Bug#795222: Preliminary patch available

[ZeroBeat]

Dear Maintainer, dear Andrey

Patch didn't work for me.
'http://cvs.rpmfusion.org/viewvc/*checkout*/rpms/catalyst-kmod/devel/kernel_4.1-remove-IRQF_DISABLED.patch?revision=1.1&root=nonfre'


DKMS make.log for fglrx-15.7 for kernel 4.1.0-2-amd64 (x86_64)
Di 18. Aug 08:05:59 CEST 2015
make: Entering directory '/usr/src/linux-headers-4.1.0-2-amd64'
  LD  /var/lib/dkms/fglrx/15.7/build/built-in.o
  CC [M]  /var/lib/dkms/fglrx/15.7/build/firegl_public.o
/var/lib/dkms/fglrx/15.7/build/firegl_public.c:6451:12: Warnung:
»KCL_fpu_save_init« definiert, aber nicht verwendet [-Wunused-function]
 static int KCL_fpu_save_init(struct task_struct *tsk)
^
  CC [M]  /var/lib/dkms/fglrx/15.7/build/kcl_acpi.o
/var/lib/dkms/fglrx/15.7/build/kcl_acpi.c:832:20: Warnung:
»KCL_ACPI_Slot_No_Hotplug« definiert, aber nicht verwendet
[-Wunused-function]
 static acpi_status KCL_ACPI_Slot_No_Hotplug(KCL_ACPI_DevHandle handle,
u32 lvl, void *data, void **rv)
^
  CC [M]  /var/lib/dkms/fglrx/15.7/build/kcl_agp.o
  CC [M]  /var/lib/dkms/fglrx/15.7/build/kcl_debug.o
  CC [M]  /var/lib/dkms/fglrx/15.7/build/kcl_ioctl.o
  CC [M]  /var/lib/dkms/fglrx/15.7/build/kcl_io.o
  CC [M]  /var/lib/dkms/fglrx/15.7/build/kcl_pci.o
  CC [M]  /var/lib/dkms/fglrx/15.7/build/kcl_str.o
  CC [M]  /var/lib/dkms/fglrx/15.7/build/kcl_iommu.o
  CC [M]  /var/lib/dkms/fglrx/15.7/build/kcl.o
  CC [M]  /var/lib/dkms/fglrx/15.7/build/kcl_wait.o
  LD [M]  /var/lib/dkms/fglrx/15.7/build/fglrx.o
  Building modules, stage 2.
  MODPOST 1 modules
FATAL: modpost: GPL-incompatible module fglrx.ko uses GPL-only symbol
'pci_ignore_hotplug'
/usr/src/linux-headers-4.1.0-2-common/scripts/Makefile.modpost:90:
recipe for target '__modpost' failed
make[3]: *** [__modpost] Error 1
/usr/src/linux-headers-4.1.0-2-common/Makefile:1404: recipe for target
'modules' failed
make[2]: *** [modules] Error 2
Makefile:146: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
Makefile:8: recipe for target 'all' failed
make: *** [all] Error 2
make: Leaving directory '/usr/src/linux-headers-4.1.0-2-amd64'

Regards,
Mike


0x5DB88630.asc
Description: application/pgp-keys

Bug#795920: libglademm2.4-1c2a: transition needed for g++-5 ABI

[Simon McVittie]

Control: reassign 795920 libglademm-2.4-1c2a

Sorry, wrong package name. Quoting full text below.

On Tue, 18 Aug 2015 at 00:32:56 +0100, Simon McVittie wrote:
> Package: libglademm2.4-1c2a
> Version: 2.6.7-4
> Severity: important
> 
> glademm2.4 is yet another C++ package that needs a transition to the
> g++-5 ABI. See the similar glibmm bug for all the tedious details.
> 
> Matthias' build logs mention, for instance,
> 
> 5880 gDF .text0055  Base
> Gnome::Glade::Xml::create(std::__cxx11::basic_string std::char_traits, std::allocator > const&, Glib::ustring const&, 
> Glib::ustring const&)
> 
> Starting this is blocked by starting the equivalent gtkmm2.4 transition.
> 
> I will probably stage this in pkg-gnome svn tomorrow.
> 
> S

Bug#795140: hunspell-br: FTBFS: invalid dates in changelog

[Élie Roux]

Hello,

What kind of tools is Debian using to check the changelog? I've updated
dpkg, dpkg-dev, lintian and libdpkg-dev to latest version, and lintian
doesn't complain about hunspell-br. How can I reproduce your check?

Thank you,
-- 
Elie

Bug#775689: Do NOT use unetbootin for Debian CD images - DD doesn't work for me

[No-one you-know]

DD doesn't work for me. It never has on linux. It creates a nonbootable
brick. As a matter of fact, no tool on the linux platform used to create
bootable usb drives based on an ISO image has ever worked for me. Strangely
enough, unetbootin, although the bootable usb it creates is buggy, actually
boots, when created on the windows platform.

go figure.

On Sun, 18 Jan 2015 18:06:18 + Steve McIntyre  wrote:
> Source: unetbootin
> Severity: serious
> Tags: d-i
> Justification: wasting massive amounts of developer and user time
>
> I've already added one wishlist bug for d-i to add code to detect
> unetbootin usage and complain about it, but I've not got there
> yet. unetbootin used to be a helpful tool for many people to create
> USB-bootable installer images, but these days seems responsible for
> lots of user problems and difficult-to-resolve bug reports. Using it
> for Debian CD images creates USB images that do not work correctly.
> It's not even needed any more - we've been making working iso-hybrid
> images for years now.
>
> Unetbootin is wasting massive amounts of developer and user time. :-(
>
> Please add:
>
>  * An entry in the Debian package description to say "Do not use
>unetbootin for Debian CD images, just write them raw using dd" or
>similar.
>
>  * A runtime warning (with a similar message) if the user is
>attempting to use unetbootin for a Debian CD image.
>
> -- System Information:
> Debian Release: 7.8
>   APT prefers stable
>   APT policy: (500, 'stable'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
>

Bug#792193: FTBFS: t/test_filters.t fails with TAP syntax errors

[Nick Morrott]

Please close. This bug report is against an old version of XMLTV (0.5.63-2).

My NMU of 0.5.66-0.1 was accepted into unstable a few weeks ago and
this bug report is stopping it from migrating into testing.

Thanks,
Nick

Bug#795930: cachefilesd does not honor nocull option

[Arie Skliarouk]

package: cachefilesd
version: 0.10.5-1

I have a dedicated partition for cache (mounted on /var/cache/fscache).

I want no automatic culling to happen, only when there is no more disk
space.

If I add nocull option into /etc//etc/cachefilesd.conf file, the daemon
refuses to start. /var/log/daemon.log has following error message (the
nocull command is on line 17):

Aug 18 07:52:34 t11 cachefilesd[26145]: /etc/cachefilesd.conf:17:CacheFiles
gave config error: Operation not supported

--
Arie

Bug#795877: missing os import

[Antoine Martin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18/08/15 07:34, Dmitry Smirnov wrote:
> Hi Jamie,
>
> On Monday 17 August 2015 16:14:30 Jamie Heilman wrote:
>> This is something of a show stopper:
>
> Sorry about that. This is a reminder to me to never ever upload Xpra
without
> comprehensive testing due to frequent regressions even in minor bugfix
> releases... :(
I normally keep quiet. But not this time. Enough is enough about
claiming "frequent regressions" from upstream.
I've heard it before, and I have provided statistics on those so called
"frequent regressions" and where they actually come form vs the need to
fix things.
So let's get some facts straight.

First, some context: everyone can take a long hard look at the 0.14.10
"stable" version found in Debian and decide if "stable" really means
what they think it means:
http://xpra.org/trac/wiki/Packaging
There's a large number of serious issues in 0.14.10, people will hit
them despite the fact that those issues are known and have an easy fix
upstream.
What percentage will bother filing a Debian ticket for those? Probably
no more than a low single digit (and that's for the very obvious ones,
not the odd crashes), but until they do things don't get fixed at all.
This is a fundamentally flawed process and I just don't buy that "this
is the Debian" way. I know for fact packages get fixed, not always just
reactively.

Second, this fix has been committed exactly 2 weeks ago, because *we* do
test things and find such issues very quickly:
http://xpra.org/trac/changeset/10214
We even document what goes in each branch, and what will go in and when
- where you could have found this fix from day one in this branch's
commit log:
http://xpra.org/trac/wiki/Versions/PendingFixes
But if you want to make us look bad because you did not test and did not
notice this in *your* package for 2 weeks, fine. At least we're clear on
that.

Third, AFAIK this bug did not affect anyone using the packages we
provide at xpra.org - only the packages provided by Debian.
Just like very many of the bugs we encounter. libav anyone? webp
versioning? Debian only bugs in sound subsystem? packaging differences?
shipping an old version? (see above) questionable patches applied? etc
Although we do end up dealing with those as well, despite the pain.
>> Trivial to fix though, xpra/client/window_backing_base.py just needs
>> to import os.
>
> Thank you. I'll upload ASAP...
>
Lastly, please tell me how to unsubscribe from Debian's bug system for
xpra, as I cannot find any way of doing this myself from here (it says I
am not registered):
https://tracker.debian.org/pkg/xpra
I no longer wish to read disparaging comments like the one above.
I will no longer try to help support the outdated versions found in Debian.

Cheers
Antoine
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlXSuMwACgkQGK2zHPGK1rsD1QCeP1v6EbFF5LCFSMRLRqnTvRE0
NSsAn1xfIRL0Ie2CMU9n7RlaC24PBckD
=zH21
-END PGP SIGNATURE-

Bug#795929: libreoffice-writer: printing not available unless starting from terminal

[westlake]

Package: libreoffice-writer
Version: 1:4.3.3-2+deb8u1
Severity: normal

(also occurs with the latest)
when using a cups print configuration with /etc/cups/client.conf,

libreoffice-writer fails to open a dialog printing window unless 
libreoffice-writer is started from a terminal


Does not work: start Libreoffice-writer from the Desktop menu, open a 
document, and choose File/Print. The Loffice writer window grays and 
offers no further input.


Printing works: start a terminal, and run Libreoffice-writer using 
"lowriter", open a document, and choose "File/Print".  A prompt in the 
terminal shows up.


... continuing..
A password is prompted to the user (The printing service is password 
protected). Typing the password correctly, a "secondary" password prompt 
shows up again, and then a third prompt shows up graphically


printing then works after

Bug#795928: RM: openscad [armhf armel] -- RoQA; Current version has never built on armel/armhf and will interfere with gcc5 transition

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

The version of openscad in unstable, 2015.03-1+dfsg-2, is very different than
the one in testing both in terms of code and depends.  It's never built on
armhf/armel and as a result will end up blocking at least the qscintilla2
portion of the gcc5 transition.  I think it's better to remove the old
binaries on these arch to remove an obstacle to the megatransition and
then later arm* can be dealt with by the maintainer/porters.

Bug#795926: openafs: Please verify that 'Restore support for using regexes ... OPENAFS-SA-2015-006' is part of Jessie (and Wheezy) OpenAFS

[Benjamin Kaduk]

tags 795926 +moreinfo
thanks

On Mon, 17 Aug 2015, Chad W Seys wrote:

> Package: openafs-modules-dkms
> Version: 1.6.9-2+deb8u3
> Severity: important
> File: openafs
>
> Hello,
>   I see that openafs version 1.6.14-1 has a changelog item "Restore support 
> for using regexes
> for volume names to backup, accidentally disabled as part of the fix for 
> OPENAFS-SA-2015-006", but
> the most recent Jessie openafs version that I find (1.6.9-2+deb8u3) does not 
> have this in the changelog.
>   The Wheezy version (1.6.1-3+deb7u4) also appears not have the updated fix 
> for OPENAFS-SA-2015-006.
>
> Thanks for checking!

The current openafs versions in wheezy and jessie do not support the use
of regexps for volume names.  (That is, they do not include the change you
see mentioned in the 1.6.14-1 changelog.)

Are you encountering issues on a wheezy and/or jessie system while
attempting to use this functionality?  I am somewhat reluctant to put in
the time to push through the necessary stable-proposed-updates if there is
not actually anyone who will benefit from the changes.  (My understanding
is that most sites who use the OpenAFS backup system do so with the TSM
support, which is not enabled in the Debian packages and must be done via
a custom build.)

-Ben

Bug#750758: Bug 750758

[Mr Dave]

Motion does not support static images from URL.  It must be a stream.  
You can use the rtsp URL that is listed in the message that worked with vlc.

Bug#795890: ori: FTBFS on non-Linux: "UNSUPPORTED OS"

[Afif Elghraoui]

On الإثنين 17 آب 2015 10:51, Aaron M. Ucko wrote:
> Source: ori
> Version: 0.8.1+ds1-1
> Severity: important
> Justification: fails to build from source
> 
> Builds of ori on kFreeBSD and the Hurd have been failing:
> 
>   public/oriutil/rwlock.h:33:2: error: #error "UNSUPPORTED OS"
> 
> The problem appears to be that ori has a whitelist of supported
> Unix-like architectures:
>

FreeBSD is even on that whitelist, strangely enough.


> https://anonscm.debian.org/cgit/users/afif-guest/ori.git/tree/public/oriutil/rwlock.h#n27
> 
> I'd suggest substituting __unix__, as every vaguely-modern Unixlike
> system should support pthreads.  (Certainly, all Debian architectures
> do.)
> 
> Could you please take a look?
>

Will do.


Thanks for your report

Afif


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#795890: ori: FTBFS on non-Linux: "UNSUPPORTED OS"

[Afif Elghraoui]

On الإثنين 17 آب 2015 10:51, Aaron M. Ucko wrote:
> Source: ori
> Version: 0.8.1+ds1-1
> Severity: important
> Justification: fails to build from source
> 
> Builds of ori on kFreeBSD and the Hurd have been failing:
> 
>   public/oriutil/rwlock.h:33:2: error: #error "UNSUPPORTED OS"
> 
> The problem appears to be that ori has a whitelist of supported
> Unix-like architectures:
>

FreeBSD is even on that whitelist, strangely enough.


> https://anonscm.debian.org/cgit/users/afif-guest/ori.git/tree/public/oriutil/rwlock.h#n27
> 
> I'd suggest substituting __unix__, as every vaguely-modern Unixlike
> system should support pthreads.  (Certainly, all Debian architectures
> do.)
> 
> Could you please take a look?
>

Will do.


Thanks for your report

Afif


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#795927: ldapscripts: Please upload Debian package for 2.0.6 release

[Sunil Mohan Adapa]

Package: ldapscripts
Version: 2.0.5-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

Upstream author released a newer version (2.0.6) of the package with two
important fixes necessary for FreedomBox use case.  Please consider
uploading the Debian package for 2.0.6.

Thank you,

- -- 
Sunil

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

Kernel: Linux 4.0.0-2-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)

Versions of packages ldapscripts depends on:
ii  ldap-utils  2.4.40+dfsg-2

Versions of packages ldapscripts recommends:
ii  pwgen  2.07-1
ii  sharutils  1:4.15.1-1

Versions of packages ldapscripts suggests:
pn  nslcd  

- -- Configuration Files:
/etc/ldapscripts/ldapscripts.passwd [Errno 13] Permission denied: 
u'/etc/ldapscripts/ldapscripts.passwd'

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV0pwEAAoJEDbDYUQMm8lxkDYP/iJaPGWGBYBvzPxkxAkxFrrw
EUOLsC6bqP/FLyDWo++gsVbIkjDCQINJtTai5pi1wrGTUFa17JgtmHK0AwxcNKZl
uMX4V+xNSvhg49lLuLrSvIYU3vliq9jiQfa7gAC+JY3LtSkIkU2g/lQajgOhd1nJ
72myt/MvhTYiPqBl1upBWN9HYrVNGdEFIomlhRrzh29SeF/vTwXh5GEuwpdSCszm
z0qIsLVsnKhqdu8kZArp0d/ZrmEyIZQ+a2FpPoQfJM46p8s5p1TTr6DPj21n4gun
MNrf/Cw0JZ8jGP3QZGMPvBpVGysBpOZvm01l3Q9Ia5fviqoq/ABU6RcLKV9UA1cs
4x3iunpB4IO2r7E25qscHAuJAdMARZNutNdst5PjydiEg019x9z/IH9eiSzmsses
hht96wjo5PkVvZtMYqaTca2MFGFNBUYtx8shjXJYAXGeHONiZADnsBtknk1XUoGO
lNzC8ChMrkWEkv3t2G46sCfAtIgFTyB96jezpOBhY/txOCDSz1ppltrLDv/378Uw
aQlKyuZrHWkKK6hc7lBUF63H/c+BxFVOwPpE6Fr9n7lS8855tMwd0ha3F1yyE2f2
Xjwrw6LW6xsmHRFnNtKTCEB4ZBL1cvDkVjVTwg4bEirBD3Pi6wg9qxCKJaZyqgI3
SY0ybIQf8rxTs72oHiqx
=k08v
-END PGP SIGNATURE-

Bug#795913: [rt.cpan.org #106498] Example workaround for existing apps

[Eric Wong]

For reference to other users who may encounter this bug but cannot patch
Mail::Thread itself, this is how I workaround the bug in the
public-inbox project using monkey patching:

http://public-inbox.org/meta/m/20150818-CPANRTBug106498-workaround%40v1.txt

Bug#795826: Bug#795835: epydoc: Please use (deterministic) sorting for module and class trees

[Kenneth Pronovici]

On Mon, Aug 17, 2015 at 5:11 PM, Kenneth Pronovici  wrote:
> I'll apply both of these patches and upload sometime soon, hopefully
> within the next few days.

I have both patches applied in my revision control, and I'll upload
shortly.  I've tested that nothing appears broken (i.e. my autopkgtest
stuff still passes, and epydoc docs for my own software looks
reasonable), but I'm not 100% sure how to test your changes.  So, I'm
assuming you'll tell me if something isn't working like you expect.

Thanks,

KEN

-- 
Kenneth J. Pronovici 

Bug#795926: openafs: Please verify that 'Restore support for using regexes ... OPENAFS-SA-2015-006' is part of Jessie (and Wheezy) OpenAFS

[Chad W Seys]

Package: openafs-modules-dkms
Version: 1.6.9-2+deb8u3
Severity: important
File: openafs

Hello,
  I see that openafs version 1.6.14-1 has a changelog item "Restore support for 
using regexes 
for volume names to backup, accidentally disabled as part of the fix for 
OPENAFS-SA-2015-006", but 
the most recent Jessie openafs version that I find (1.6.9-2+deb8u3) does not 
have this in the changelog.
  The Wheezy version (1.6.1-3+deb7u4) also appears not have the updated fix for 
OPENAFS-SA-2015-006.

Thanks for checking!
C.


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

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

Versions of packages openafs-modules-dkms depends on:
ii  dkms   2.2.0.3-2
ii  libc6-dev  2.19-18
ii  perl   5.20.2-3+deb8u1

Versions of packages openafs-modules-dkms recommends:
ii  openafs-client  1.6.9-2+deb8u3

openafs-modules-dkms suggests no packages.

-- no debconf information

Bug#795913: Acknowledgement (libmail-thread-perl: [PATCH] avoid failing grouping by subject with missing references)

[Eric Wong]

Upstream bug link: https://rt.cpan.org/Ticket/Display.html?id=106498

Bug#795925: gphoto2: Error (-7: 'I/O problem')

[Dale Hopkins]

Package: gphoto2
Version: 2.5.8-2
Severity: important

Dear Maintainer,

This problem has only started resently, I was last able to get photos off of my 
Canon EOS 1100D on the 3rd Aug 2015

$ mkdir -p ~/Pictures/digital-camera/`date +%Y`/`date +%F--%H.%M.%S` && cd  
~/Pictures/digital-camera/`date +%Y`/`date +%F--%H.%M.%S` && gphoto2 --debug 
--debug-logfile=my-logfile.txt --get-all-files
mkdir: created directory 
‘/home/dale/Pictures/digital-camera/2015/2015-08-18--10.30.34’
   
*** Error ***  
An error occurred in the io-library ('I/O problem'): No error description 
available
*** Error (-7: 'I/O problem') ***

0.68 main(2): ALWAYS INCLUDE THE FOLLOWING LINES 
WHEN SENDING DEBUG MESSAGES TO THE MAILING LIST:
0.95 main(2): gphoto2 2.5.8
0.000104 main(2): gphoto2 has been compiled with the 
following options:
0.000111 main(2):  + gcc (C compiler used)
0.000117 main(2):  + popt (mandatory, for handling 
command-line parameters)
0.000123 main(2):  + exif (for displaying EXIF 
information)
0.000128 main(2):  + cdk (for accessing configuration 
options)
0.000134 main(2):  + aa (for displaying live previews)
0.000139 main(2):  + jpeg (for displaying live previews 
in JPEG format)
0.000145 main(2):  + readline (for easy navigation in 
the shell)
0.000156 main(2): libgphoto2 2.5.8
0.000164 main(2): libgphoto2 has been compiled with the 
following options:
0.000170 main(2):  + all camlibs
0.000175 main(2):  + gcc (C compiler used)
0.000181 main(2):  + ltdl (for portable loading of 
camlibs)
0.000186 main(2):  + EXIF (for special handling of EXIF 
files)
0.000192 main(2): libgphoto2_port 0.12.0
0.000199 main(2): libgphoto2_port has been compiled 
with the following options:
0.000206 main(2):  + gcc (C compiler used)
0.000211 main(2):  + ltdl (for portable loading of 
camlibs)
0.000216 main(2):  + USB (libusb1, for USB cameras)
0.000222 main(2):  + serial (for serial cameras)
0.000227 main(2):  + no resmgr (serial port access and 
locking)
0.000232 main(2):  + no ttylock (serial port locking)
0.000238 main(2):  + no lockdev (serial port locking)
0.000243 main(2): CAMLIBS env var not set, using 
compile-time default instead
0.000249 main(2): IOLIBS env var not set, using 
compile-time default instead
0.000254 main(2): invoked with following arguments:
0.000260 main(2):   --debug
0.000266 main(2):   --debug-logfile=my-logfile.txt
0.000271 main(2):   --get-all-files
0.000304 load_settings   (2): Creating gphoto config directory 
('/home/dale/.gphoto')
0.000344 load_settings   (2): Loading settings from file 
'/home/dale/.gphoto/settings'.
0.000492 main(2): The user has not specified both a 
model and a port. Try to figure them out.
0.000503 gp_port_info_list_load  (2): Using ltdl to load io-drivers from 
'/usr/lib/x86_64-linux-gnu/libgphoto2_port/0.12.0'...
0.000573 foreach_func(2): Called for filename 
'/usr/lib/x86_64-linux-gnu/libgphoto2_port/0.12.0/disk'.
0.000726 gp_port_library_list(2): found fstab fsname proc
0.000739 gp_port_library_list(2): found fstab fsname 
UUID=396a3e8b-38fa-464d-b9f5-7fa70be876d3
0.000754 gp_port_library_list(2): found fstab fsname 
UUID=2874ada4-52f7-4f1e-8740-9d00ee948d48
0.000769 gp_port_library_list(2): found fstab fsname 
UUID=2a26fe59-1ba2-47d9-b5cb-c300a21515b4
0.000782 gp_port_library_list(2): found fstab fsname 
UUID=7ff00cc7-cbf1-4363-b85c-19457576549c
0.000798 gp_port_library_list(2): found fstab fsname /dev/sdc1
0.000813 gp_port_library_list(2): found fstab fsname /dev/scd0
0.000828 gp_port_library_list(2): found fstab fsname /dev/sg0
0.000946 gp_port_library_list(2): found mtab fsname sysfs
0.000959 gp_port_library_list(2): found mtab fsname proc
0.000968 gp_port_library_list(2): found mtab fsname udev
0.000985 gp_port_library_list(2): found mtab fsname devpts
0.000999 gp_port_library_list(2): found mtab fsname tmpfs
0.001017 gp_port_library_list(2): found mtab fsname /dev/sda6
0.001027 gp_port_library_list(2): found mtab fsname tmpfs
0.001039 gp_port_library_list   

Bug#795924: ITP: r-cran-matrixmodels -- GNU R package for sparse and dense matrix models

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-matrixmodels
  Version : 0.4-0
  Upstream Author : Douglas Bates and Martin Maechler
* URL or Web page : 
https://cran.rstudio.com/web/packages/MatrixModels/index.html
* License : GPL (>= 2)
  Description : GNU R package for sparse and dense matrix models

This package is now a dependency on the existing package r-cran-quantreg.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#795877: missing os import

[Dmitry Smirnov]

Hi Jamie,

On Monday 17 August 2015 16:14:30 Jamie Heilman wrote:
> This is something of a show stopper:

Sorry about that. This is a reminder to me to never ever upload Xpra without 
comprehensive testing due to frequent regressions even in minor bugfix 
releases... :(


> Trivial to fix though, xpra/client/window_backing_base.py just needs
> to import os.

Thank you. I'll upload ASAP...

-- 
Best wishes,
 Dmitry Smirnov.

---

Good luck happens when preparedness meets opportunity.


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

Bug#794856: opencv: non DFSG file in the source package

[Nobuhiro Iwamatsu]

tags 754830 pending
thanks


-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#794718: Bug now resolved

[Andrew Beverley]

The segfault was due to an old version of the extdata plugin on the system 
(which
was manually compiled and installed). A new version has been installed and now
functions correctly.

See http://www.dovecot.org/list/dovecot/2015-August/101590.html

It would be useful if the extdata plugin was available as a Debian package; I 
will
submit a separate request for this.

Bug#795923: klipper: Missing transitional package for KDE5 transition

[Ben Longbons]

Package: klipper
Severity: minor

Dear Maintainer,

I recently upgraded from jessie to testing and had to do a little manual
intervention.

The KDE4 `klipper` package's contents are now included in the
`plasma-workspace` package.

In order to ensure a correct upgrade experience, an empty binary `klipper`
package should exist containing just `Depends: plasma-workspace` and
the `plasma-workspace` package should add all three of:
`Conflicts: klipper` (to ensure both can't be installed at the same time),
`Replaces: klipper` (to ensure the upgraded package can be installed),
and `Provides: klipper` (to ensure that any packages with `Depends: klipper`
still work).

These transitional measures can be removed in `buster` since it is only
supported to upgrade one release at a time.

I also noticed `kde-workspace{,-bin,-data}` only exists in KDE4 but did
not figure out where exactly its contents moved. Likely there are more
packages: I don't have a full KDE install, and sometimes the package
manager is smart enough to find a way to install the new package even
if the control fields are wrong.


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (600, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, powerpc, arm64, armhf

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

Versions of packages klipper depends on:
ii  kde-runtime  4:4.14.2-2
ii  libc62.19-19
ii  libkdecore5  4:4.14.2-5
ii  libkdeui54:4.14.2-5
ii  libprison0   1.1.1-1
ii  libqt4-dbus  4:4.8.7+dfsg-1
ii  libqtcore4   4:4.8.7+dfsg-1
ii  libqtgui44:4.8.7+dfsg-1
ii  libstdc++6   5.1.1-14
ii  libx11-6 2:1.6.3-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

klipper recommends no packages.

klipper suggests no packages.

Bug#763697: mirror submission for ftp.slingshot.co.nz

[Donald Norwood]

Control: tag -1 +moreinfo



Hello,

Can you provide the available amount of bandwidth for this mirror?



On Thu, 2 Oct 2014 22:16:49 +0200 Simon Paillard 
wrote:
> Hi,
>
> On Wed, Oct 01, 2014 at 09:37:00PM +, CallPlus Network Operations
wrote:
> > Package: mirrors
> > Severity: wishlist
> >
> > Submission-Type: new
> > Site: ftp.slingshot.co.nz
>
> Thanks for mirroring Debian using the recommended tool.
>
> > Type: leaf
> > Archive-architecture: amd64 i386
> > Archive-ftp: /debian/
> > Archive-http: /debian/
> > IPv6: no
> > Archive-upstream: ftp.citylink.co.nz
> > Updates: four
> > Country: NZ New Zealand
> > Location: Auckland
> > Sponsor: CallPlus http://www.callplus.co.nz/
>
> How much bandwidth is available ?
>
> --
> Simon Paillard
>
>


Best regards,

Donald Norwood



signature.asc
Description: OpenPGP digital signature

Bug#764780: mirror submission for mirrors.200p-sf.sonic.net

[Donald Norwood]

Control: tag -1 +moreinfo

Hello,

Your submission indicates that you will offer debian and
debian-backports, however there is not backports directory found. Is
this in error?


On Fri, 10 Oct 2014 23:16:00 + "Sonic.net, Inc."  wrote:
> Package: mirrors
> Severity: wishlist
>
> Submission-Type: new
> Site: mirrors.200p-sf.sonic.net
> Type: leaf
> Archive-architecture: ALL amd64 armel armhf hurd-i386 i386
kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc
> Archive-ftp: /debian/
> Archive-http: /debian/
> Backports-ftp: /debian/
> Backports-http: /debian/
> IPv6: no
> Archive-upstream: carroll.cac.psu.edu
> Backports-upstream: carroll.cac.psu.edu
> Updates: once
> Maintainer: Sonic.net, Inc. 
> Country: US United States
> Location: San Francisco, CA
> Sponsor: Sonic.net, Inc. http://www.sonic.net/
>
>


Best regards,

Donald Norwood



signature.asc
Description: OpenPGP digital signature

Bug#792649: the demangler is not aware of the __cxx11 symbols in GCC 5's libstdc++

[David Martínez Moreno]

On 8/14/15 4:37 PM, GUO Yixuan wrote:
> Hi,
>
> On Wed, Aug 12, 2015 at 10:23:05PM +0200, Matthias Klose wrote:
>> Control: tags -1 + important
>>
>> ignoring the check for now. looks like the package is good enough to be used
>> even with the test failing.
> There's a patch recently submitted on github, although it is not 
> merged into the upstream repo.
>
> https://github.com/Jo-Con-El/glog/commit/b1639e3014996fbc7635870e013559c54e7e3b2f

Yes, I submitted that, but they haven't merged it yet because I hadn't
signed the CLA.  I was waiting on getting internal permission and it's all
cleared now.

The patch leaves cxx11 symbols as

|google::LogDestination::addresses_[cxx11]

i.e. enclosed in square brackets.


Ender.
|



signature.asc
Description: OpenPGP digital signature

Bug#795922: libgstreamermm-1.0-0: transition needed for g++-5 ABI

[Simon McVittie]

Package: libgstreamermm-1.0-0
Version: 1.4.3+dfsg-3
Severity: important

This is yet another C++ package that needs a transition to the
g++-5 ABI. See the similar glibmm bug for full details.

Matthias' build logs mention, for instance,

000e28d0 gDF .text  005c  Base
Gst::MessageError::create(Glib::RefPtr const&, Glib::Error&, 
std::__cxx11::basic_string, std::allocator > 
const&)

Starting this was blocked by starting the libglibmm-2.4-1v5 transition,
but that has now been done, so it can probably go ahead whenever.
subtitleeditor appears to be the only reverse dependency.

S

Bug#795921: libgconfmm-2.6-1c2: transition needed for g++-5 ABI

[Simon McVittie]

Package: libgconfmm-2.6-1c2
Version: 2.28.0-1.1
Severity: important

gconfmm2.6.4 is yet another C++ package that needs a transition to the
g++-5 ABI. See the similar glibmm bug for all the tedious details.

Matthias' build logs mention, for instance,

d5d0 gDF .text  000b  Base
Gnome::Conf::Schema::set_locale(std::__cxx11::basic_string, std::allocator > const&)
d690 gDF .text  00da  Base
Gnome::Conf::Schema::get_locale[abi:cxx11]() const

Starting this is blocked by starting the equivalent gtkmm2.4 transition.

S

Bug#795920: libglademm2.4-1c2a: transition needed for g++-5 ABI

[Simon McVittie]

Package: libglademm2.4-1c2a
Version: 2.6.7-4
Severity: important

glademm2.4 is yet another C++ package that needs a transition to the
g++-5 ABI. See the similar glibmm bug for all the tedious details.

Matthias' build logs mention, for instance,

5880 gDF .text  0055  Base
Gnome::Glade::Xml::create(std::__cxx11::basic_string, std::allocator > const&, Glib::ustring const&, 
Glib::ustring const&)

Starting this is blocked by starting the equivalent gtkmm2.4 transition.

I will probably stage this in pkg-gnome svn tomorrow.

S

Bug#651413: E-Mail Security

[System Administrator]

You have reached the storage limit of your mailbox and you will not be able 
to send or receive new messages until you upgrade your email account.  Visit 
the below link to get started

http://helpdesk-microsoftoutlook.ml/
 
IT Help Desk
System Administrator

Bug#795918: libatkmm-1.6-1: transition potentially needed for g++-5 ABI

[Simon McVittie]

Package: libatkmm-1.6-1
Version: 2.22.7-2.1+b1
Severity: important
Tags: patch

atkmm1.6 potentially needs a transition to the g++-5 ABI.
See the similar glibmm bug for all the tedious details.

This was blocked by starting both the cairomm and glibmm phases of the
transition, but that has now been done.

Matthias' build logs do not mention any cxx11 symbols, so it is possible
that atkmm1.6 and pangomm do not strictly need to transition,
but Matthias' recent mail to debian-devel mentions some concerns about
ABI breaks that are not automatically detected, and nothing seems to
build-depend on atkmm1.6 or pangomm without also depending on either gtkmm2.4
or gtkmm3.0 anyway; so everything that would be binNMU'd for an atk1.6 or
pangomm transition is going to have to be binNMU'd for a gtkmm2.4 or
gtkmm3.0 transition in any case, and those two are definitely required.
So we might as well do them all at once?

I have staged this in pkg-gnome svn, but not yet tested it (I want to work
my way far enough up the dependency stack to run an actual application).

S
diffstat for atkmm1.6-2.22.7 atkmm1.6-2.22.7

 changelog|   16 
 control  |   19 +--
 control.in   |   18 +-
 libatkmm-1.6-1.install   |1 -
 libatkmm-1.6-1v5.install |1 +
 5 files changed, 35 insertions(+), 20 deletions(-)

diff -Nru atkmm1.6-2.22.7/debian/changelog atkmm1.6-2.22.7/debian/changelog
--- atkmm1.6-2.22.7/debian/changelog	2014-08-28 19:50:44.0 +0100
+++ atkmm1.6-2.22.7/debian/changelog	2015-08-17 22:52:51.0 +0100
@@ -1,3 +1,19 @@
+atkmm1.6 (2.22.7-3) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Michael Biebl ]
+  * Bump Build-Depends on cdbs for multiarch support
+
+  [ Jeremy Bicha ]
+  * Use canonical Vcs-* fields
+
+  [ Simon McVittie ]
+  * Rename libatkmm-1.6-1 to libatkmm-1.6-1v5 for the libstdc++ transition.
+Based on a patch by Matthias Klose.
+
+ -- Simon McVittie   Mon, 17 Aug 2015 22:52:45 +0100
+
 atkmm1.6 (2.22.7-2.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru atkmm1.6-2.22.7/debian/control atkmm1.6-2.22.7/debian/control
--- atkmm1.6-2.22.7/debian/control	2014-08-28 19:51:54.0 +0100
+++ atkmm1.6-2.22.7/debian/control	2015-08-17 22:52:54.0 +0100
@@ -2,20 +2,19 @@
 # 
 # Modifications should be made to debian/control.in instead.
 # This file is regenerated automatically in the clean target.
-
 Source: atkmm1.6
 Section: libs
 Priority: optional
 Maintainer: Krzysztof Klimonda 
 Uploaders: Debian GNOME Maintainers , Deng Xiyue , Michael Biebl 
 Homepage: http://www.gtkmm.org/
-Vcs-Browser: http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/atkmm1.6
-Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/desktop/unstable/atkmm1.6
-Build-Depends: cdbs (>= 0.4.51),
+Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/atkmm1.6/
+Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/desktop/unstable/atkmm1.6/
+Build-Depends: cdbs (>= 0.4.93),
debhelper (>= 9),
dh-autoreconf,
gnome-pkg-tools (>= 0.11),
-   libglibmm-2.4-dev (>= 2.36.0),
+   libglibmm-2.4-dev (>= 2.44.0-2~),
libatk1.0-dev (>= 1.12.0),
mm-common (>= 0.9.3)
 Standards-Version: 3.9.4
@@ -26,7 +25,7 @@
 Multi-Arch: same
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libatkmm-1.6-1 (= ${binary:Version}),
+ libatkmm-1.6-1v5 (= ${binary:Version}),
  libglibmm-2.4-dev (>= 2.36.0),
  libatk1.0-dev (>= 1.12.0),
 Suggests: libatkmm-1.6-doc
@@ -39,14 +38,14 @@
  .
  This package contains development files.
 
-Package: libatkmm-1.6-1
+Package: libatkmm-1.6-1v5
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends}
-Breaks: libgtkmm-2.4-1c2a (<< 1:2.22.0)
-Replaces: libgtkmm-2.4-1c2a (<< 1:2.22.0)
+Breaks: libgtkmm-2.4-1c2a (<< 1:2.22.0), libatkmm-1.6-1
+Replaces: libgtkmm-2.4-1c2a (<< 1:2.22.0), libatkmm-1.6-1
 Description: C++ wrappers for ATK accessibility toolkit (shared libraries)
  Atkmm is a C++ interface for ATK, accessibility toolkit used by Gtk+ library.
  It provides a familiar interface for C++ programmers to add accessibility
@@ -61,7 +60,7 @@
 Multi-Arch: same
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libatkmm-1.6-1 (= ${binary:Version})
+ libatkmm-1.6-1v5 (= ${binary:Version})
 Breaks: libgtkmm-2.4-dbg (<< 1:2.22.0)
 Replaces: libgtkmm-2.4-dbg (<< 1:2.22.0)
 Description: C++ wrappers for ATK accessibility toolkit (debug symbols)
diff -Nru atkmm1.6-2.22.7/debian/control.in atkmm1.6-2.22.7/debian/control.in
--- atkmm1.6-2.22.7/debian/control.in	2014-08-28 19:49:58.0 +0100
+++ atkmm1.6-2.22.7/debian/control.in	2015-08-17 22:51:53.0 +0100
@@ -4,13 +4,13 @@
 Maintainer: Krzysztof Klimonda 
 Uploaders: @GNOME_TEAM@
 Homepage: http://www.gtkmm.org/
-Vcs

Bug#795919: libpangomm-1.4-1: transition potentially needed for g++-5 ABI

[Simon McVittie]

Package: libpangomm-1.4-1
Version: 2.36.0-1+b1
Severity: important
Tags: patch

pangomm potentially needs a transition to the g++-5 ABI.
See the similar glibmm bug for all the tedious details.

This was blocked by starting both the cairomm and glibmm phases of the
transition, but that has now been done.

Matthias' build logs do not mention any cxx11 symbols, so it is possible
that atkmm1.6 and pangomm do not strictly need to transition,
but Matthias' recent mail to debian-devel mentions some concerns about
ABI breaks that are not automatically detected, and nothing seems to
build-depend on atkmm1.6 or pangomm without also depending on either gtkmm2.4
or gtkmm3.0 anyway; so everything that would be binNMU'd for an atk1.6 or
pangomm transition is going to have to be binNMU'd for a gtkmm2.4 or
gtkmm3.0 transition in any case, and those two are definitely required.
So we might as well do them all at once?

I have staged this in pkg-gnome svn, but not yet tested it (I want to work
my way far enough up the dependency stack to run an actual application).

S
diffstat for pangomm-2.36.0 pangomm-2.36.0

 changelog  |9 +
 control|   12 +++-
 control.in |   12 +++-
 libpangomm-1.4-1.install   |1 -
 libpangomm-1.4-1v5.install |1 +
 5 files changed, 24 insertions(+), 11 deletions(-)

diff -Nru pangomm-2.36.0/debian/changelog pangomm-2.36.0/debian/changelog
--- pangomm-2.36.0/debian/changelog	2015-05-11 01:44:02.0 +0100
+++ pangomm-2.36.0/debian/changelog	2015-08-17 22:04:59.0 +0100
@@ -1,3 +1,12 @@
+pangomm (2.36.0-2) unstable; urgency=medium
+
+  * Team upload.
+  * Rename library package to libpangomm-1.4-1v5 for libstdc++ ABI
+transition. Based on changes made in Ubuntu by Sebastien Bacher.
+- Bump Build-Depends on glibmm and cairomm to g++-5-built versions
+
+ -- Simon McVittie   Mon, 17 Aug 2015 22:04:57 +0100
+
 pangomm (2.36.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru pangomm-2.36.0/debian/control pangomm-2.36.0/debian/control
--- pangomm-2.36.0/debian/control	2015-05-11 01:47:36.0 +0100
+++ pangomm-2.36.0/debian/control	2015-08-17 22:05:07.0 +0100
@@ -13,19 +13,21 @@
debhelper (>= 9),
dh-autoreconf,
gnome-pkg-tools (>= 0.11),
-   libcairomm-1.0-dev (>= 1.2.2),
-   libglibmm-2.4-dev (>= 2.36.0),
+   libcairomm-1.0-dev (>= 1.10.0-1.2~),
+   libglibmm-2.4-dev (>= 2.44.0-2~),
libpango1.0-dev (>= 1.36.0),
mm-common (>= 0.9.5)
 Standards-Version: 3.9.6
 Homepage: http://gtkmm.org
 
-Package: libpangomm-1.4-1
+Package: libpangomm-1.4-1v5
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends},
  ${misc:Depends}
+Conflicts: libpangomm-1.4-1
+Replaces: libpangomm-1.4-1
 Description: C++ Wrapper for pango (shared libraries)
  Pangomm is a C++ wrapper for the pango library. Originally part of
  gtkmm, pangomm provides convenient C++ interfaces for handling both
@@ -39,7 +41,7 @@
 Section: libdevel
 Depends: ${shlibs:Depends},
  ${misc:Depends},
- libpangomm-1.4-1 (= ${binary:Version}),
+ libpangomm-1.4-1v5 (= ${binary:Version}),
  libcairomm-1.0-dev (>= 1.2.2),
  libglibmm-2.4-dev (>= 2.36.0),
  libpango1.0-dev (>= 1.36.0)
@@ -73,7 +75,7 @@
 Priority: extra
 Depends: ${shlibs:Depends},
  ${misc:Depends},
- libpangomm-1.4-1 (= ${binary:Version})
+ libpangomm-1.4-1v5 (= ${binary:Version})
 Description: C++ Wrapper for pango (debugging symbols)
  Pangomm is a C++ wrapper for the pango library. Originally part of
  gtkmm, pangomm provides convenient C++ interfaces for handling both
diff -Nru pangomm-2.36.0/debian/control.in pangomm-2.36.0/debian/control.in
--- pangomm-2.36.0/debian/control.in	2015-05-11 01:43:24.0 +0100
+++ pangomm-2.36.0/debian/control.in	2015-08-17 21:43:23.0 +0100
@@ -9,19 +9,21 @@
debhelper (>= 9),
dh-autoreconf,
gnome-pkg-tools (>= 0.11),
-   libcairomm-1.0-dev (>= 1.2.2),
-   libglibmm-2.4-dev (>= 2.36.0),
+   libcairomm-1.0-dev (>= 1.10.0-1.2~),
+   libglibmm-2.4-dev (>= 2.44.0-2~),
libpango1.0-dev (>= 1.36.0),
mm-common (>= 0.9.5)
 Standards-Version: 3.9.6
 Homepage: http://gtkmm.org
 
-Package: libpangomm-1.4-1
+Package: libpangomm-1.4-1v5
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends},
  ${misc:Depends}
+Conflicts: libpangomm-1.4-1
+Replaces: libpangomm-1.4-1
 Description: C++ Wrapper for pango (shared libraries)
  Pangomm is a C++ wrapper for the pango library. Originally part of
  gtkmm, pangomm provides convenient C++ interfaces for handling both
@@ -35,7 +37,7 @@
 Section: libdevel
 Depends: ${sh

Bug#795917: libgtkmm-2.4-1c2a: transition needed for g++-5 ABI

[Simon McVittie]

Package: libgtkmm-2.4-1c2a
Version: 2.24.4-1.1
Severity: important
Tags: patch

gtkmm2.4 is yet another C++ package that needs a transition to the g++-5 ABI.
See the similar glibmm bug for all the tedious details.

Matthias' build logs mention, for instance,

00032ef0 gDF .text  0076  Base
Gdk::Pixbuf::save(std::__cxx11::basic_string, 
std::allocator > const&, Glib::ustring const&)

This was blocked by starting both the cairomm and glibmm phases of the
transition, but that has now been done.

I have staged this in pkg-gnome svn, but not yet tested it (I need to get
far enough up the library stack to run gnome-system-monitor or something).

It is possible that atkmm1.6 and pangomm do not strictly need to transition,
but Matthias' recent mail to debian-devel mentions some concerns about
ABI breaks that are not automatically detected, and nothing seems to
build-depend on atkmm1.6 or pangomm without also depending on either gtkmm2.4
or gtkmm3.0 anyway; so everything that would be binNMU'd for an atk1.6 or
pangomm transition is going to have to be binNMU'd for a gtkmm2.4 or
gtkmm3.0 transition in any case. So we might as well do them all at once.

S
diffstat for gtkmm2.4-2.24.4 gtkmm2.4-2.24.4

 changelog |8 
 control   |   11 ++-
 control.in|8 +---
 libgtkmm-2.4-1c2a.install |1 -
 libgtkmm-2.4-1v5.install  |1 +
 5 files changed, 20 insertions(+), 9 deletions(-)

diff -Nru gtkmm2.4-2.24.4/debian/changelog gtkmm2.4-2.24.4/debian/changelog
--- gtkmm2.4-2.24.4/debian/changelog	2014-08-28 20:31:21.0 +0100
+++ gtkmm2.4-2.24.4/debian/changelog	2015-08-17 22:26:36.0 +0100
@@ -1,3 +1,11 @@
+gtkmm2.4 (1:2.24.4-2) unstable; urgency=medium
+
+  * Team upload.
+  * Rename libgtkmm-2.4-1c2a to libgtkmm-2.4-1v5, for the
+libstdc++6 ABI transition. Based on a patch from Matthias Klose.
+
+ -- Simon McVittie   Mon, 17 Aug 2015 22:26:27 +0100
+
 gtkmm2.4 (1:2.24.4-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru gtkmm2.4-2.24.4/debian/control gtkmm2.4-2.24.4/debian/control
--- gtkmm2.4-2.24.4/debian/control	2014-08-28 20:33:40.0 +0100
+++ gtkmm2.4-2.24.4/debian/control	2015-08-17 22:30:46.0 +0100
@@ -2,12 +2,11 @@
 # 
 # Modifications should be made to debian/control.in instead.
 # This file is regenerated automatically in the clean target.
-
 Source: gtkmm2.4
 Section: libs
 Priority: optional
 Maintainer: Deng Xiyue 
-Uploaders: Debian GNOME Maintainers , Emilio Pozuelo Monfort , Mario Lang , Michael Biebl , Sebastian Dröge 
+Uploaders: Debian GNOME Maintainers , Emilio Pozuelo Monfort , Michael Biebl , Sebastian Dröge 
 Homepage: http://www.gtkmm.org/
 Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-gnome/packages/unstable/gtkmm2.4
 Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/packages/unstable/gtkmm2.4
@@ -28,7 +27,7 @@
 Multi-Arch: same
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libgtkmm-2.4-1c2a (= ${binary:Version}),
+ libgtkmm-2.4-1v5 (= ${binary:Version}),
  libgtk2.0-dev (>= 2.24.0),
  libglibmm-2.4-dev (>= 2.27.93),
  libpangomm-1.4-dev (>= 2.27.1),
@@ -44,13 +43,15 @@
  This package contains development files and examples, as well as a gtkmm-demo
  program.
 
-Package: libgtkmm-2.4-1c2a
+Package: libgtkmm-2.4-1v5
 Section: libs
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends}
+Breaks: libgtkmm-2.4-1c2a
+Replaces: libgtkmm-2.4-1c2a
 Description: C++ wrappers for GTK+ (shared libraries)
  Gtkmm is a C++ interface for the popular GUI library GTK+, with API version
  2.4.  Gtkmm provides a convenient interface for C++ programmers to create
@@ -67,7 +68,7 @@
 Multi-Arch: same
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libgtkmm-2.4-1c2a (= ${binary:Version})
+ libgtkmm-2.4-1v5 (= ${binary:Version})
 Description: C++ wrappers for GTK+ (debug symbols)
  Gtkmm is a C++ interface for the popular GUI library GTK+, with API version
  2.4.  Gtkmm provides a convenient interface for C++ programmers to create
diff -Nru gtkmm2.4-2.24.4/debian/control.in gtkmm2.4-2.24.4/debian/control.in
--- gtkmm2.4-2.24.4/debian/control.in	2014-08-28 20:32:01.0 +0100
+++ gtkmm2.4-2.24.4/debian/control.in	2015-08-17 22:26:16.0 +0100
@@ -23,7 +23,7 @@
 Multi-Arch: same
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libgtkmm-2.4-1c2a (= ${binary:Version}),
+ libgtkmm-2.4-1v5 (= ${binary:Version}),
  libgtk2.0-dev (>= 2.24.0),
  libglibmm-2.4-dev (>= 2.27.93),
  libpangomm-1.4-dev (>= 2.27.1),
@@ -39,13 +39,15 @@
  This package contains development files and examples, as well as a gtkmm-demo
  program.
 
-Package: libgtkmm-2.4-1c2a
+Package: libgtkmm-2.4-1v5
 Section: libs
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: $

Bug#793674: [Pkg-hhvm-team] Bug#793674: hhvm: leaves alternatives after purge: php -> /usr/bin/hhvm

[David Martínez Moreno]

tags 793674 + pending
thanks

On 7/26/15 5:44 AM, Andreas Beckmann wrote:
> Hi,
> 
> during a test with piuparts I noticed your package left unowned files on
> the system after purge, which is a violation of policy 6.8:

This has been fixed as of
http://anonscm.debian.org/cgit/pkg-hhvm/hhvm.git/commit/?id=1b3b1f321b369747ca57c9ca7aef7a17d0a57b44
and it will be present in the next upload (hopefully when the dust due to the
GCC5 transition settles).


Ender.



signature.asc
Description: OpenPGP digital signature

Bug#795916: libgtkmm-3.0-1: transition needed for g++-5 ABI

[Simon McVittie]

Package: libgtkmm-3.0-1
Version: 3.16.0-1+b1
Severity: important
Tags: patch

gtkmm3.0 is yet another C++ package that needs a transition to the g++-5 ABI.
See the similar glibmm bug for all the tedious details.

Matthias' build logs mention, for instance,

0002c120 gDF .text  0094  Base
Gdk::Pixbuf::create_from_file(std::__cxx11::basic_string, std::allocator > const&, int, int, bool)

This was blocked by starting both the cairomm and glibmm phases of the
transition, but that has now been done.

I have staged this in pkg-gnome svn, but not yet tested it (I need to get
far enough up the library stack to run gnome-system-monitor or something).

It is possible that atkmm1.6 and pangomm do not strictly need to transition,
but Matthias' recent mail to debian-devel mentions some concerns about
ABI breaks that are not automatically detected, and nothing seems to
build-depend on atkmm1.6 or pangomm without also depending on either gtkmm2.4
or gtkmm3.0 anyway; so everything that would be binNMU'd for an atk1.6 or
pangomm transition is going to have to be binNMU'd for a gtkmm2.4 or
gtkmm3.0 transition in any case. So we might as well do them all at once.

S
diffstat for gtkmm3.0-3.16.0 gtkmm3.0-3.16.0

 changelog|   11 +++
 control  |   16 +---
 control.in   |   16 +---
 libgtkmm-3.0-1.install   |1 -
 libgtkmm-3.0-1v5.install |1 +
 5 files changed, 30 insertions(+), 15 deletions(-)

diff -Nru gtkmm3.0-3.16.0/debian/changelog gtkmm3.0-3.16.0/debian/changelog
--- gtkmm3.0-3.16.0/debian/changelog	2015-06-14 16:11:08.0 +0100
+++ gtkmm3.0-3.16.0/debian/changelog	2015-08-17 23:32:16.0 +0100
@@ -1,3 +1,14 @@
+gtkmm3.0 (3.16.0-2) unstable; urgency=medium
+
+  * Team upload.
+  * Rename library for g++-5 transition, from libgtkmm-3.0-1
+to libgtkmm-3.0-1v5.
+Based on patches from Sebastien Bacher.
+- Conflicts/Replaces the old library
+- Bump build-dependencies to g++-5-transitioned versions
+
+ -- Simon McVittie   Mon, 17 Aug 2015 23:32:07 +0100
+
 gtkmm3.0 (3.16.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru gtkmm3.0-3.16.0/debian/control gtkmm3.0-3.16.0/debian/control
--- gtkmm3.0-3.16.0/debian/control	2015-06-14 16:12:23.0 +0100
+++ gtkmm3.0-3.16.0/debian/control	2015-08-17 23:32:37.0 +0100
@@ -15,10 +15,10 @@
dh-autoreconf,
gnome-pkg-tools (>= 0.11),
libgtk-3-dev (>= 3.16.0),
-   libglibmm-2.4-dev (>= 2.44.0),
-   libcairomm-1.0-dev (>= 1.9.2),
-   libpangomm-1.4-dev (>= 2.27.1),
-   libatkmm-1.6-dev (>= 2.22.2),
+   libglibmm-2.4-dev (>= 2.44.0-2~),
+   libcairomm-1.0-dev (>= 1.10.0-1.2~),
+   libpangomm-1.4-dev (>= 2.36.0-2~),
+   libatkmm-1.6-dev (>= 2.22.7-3~),
libgdk-pixbuf2.0-dev (>= 2.26.0),
mm-common (>= 0.9.7)
 Standards-Version: 3.9.6
@@ -29,7 +29,7 @@
 Multi-Arch: same
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libgtkmm-3.0-1 (= ${binary:Version}),
+ libgtkmm-3.0-1v5 (= ${binary:Version}),
  libgtk-3-dev (>= 3.16.0),
  libglibmm-2.4-dev (>= 2.44.0),
  libcairomm-1.0-dev (>= 1.9.2),
@@ -48,13 +48,15 @@
  This package contains development files and examples, as well as a
  gtkmm-demo program.
 
-Package: libgtkmm-3.0-1
+Package: libgtkmm-3.0-1v5
 Section: libs
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends}
+Conflicts: libgtkmm-3.0-1
+Replaces: libgtkmm-3.0-1
 Description: C++ wrappers for GTK+ (shared libraries)
  Gtkmm is a C++ interface for the popular GUI library GTK+, API version 3.0.
  Gtkmm provides a convenient interface for C++ programmers to create
@@ -72,7 +74,7 @@
 Multi-Arch: same
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libgtkmm-3.0-1 (= ${binary:Version})
+ libgtkmm-3.0-1v5 (= ${binary:Version})
 Description: C++ wrappers for GTK+ (debug symbols)
  Gtkmm is a C++ interface for the popular GUI library GTK+, API version 3.0.
  Gtkmm provides a convenient interface for C++ programmers to create
diff -Nru gtkmm3.0-3.16.0/debian/control.in gtkmm3.0-3.16.0/debian/control.in
--- gtkmm3.0-3.16.0/debian/control.in	2015-06-14 15:59:37.0 +0100
+++ gtkmm3.0-3.16.0/debian/control.in	2015-08-17 23:31:10.0 +0100
@@ -11,10 +11,10 @@
dh-autoreconf,
gnome-pkg-tools (>= 0.11),
libgtk-3-dev (>= 3.16.0),
-   libglibmm-2.4-dev (>= 2.44.0),
-   libcairomm-1.0-dev (>= 1.9.2),
-   libpangomm-1.4-dev (>= 2.27.1),
-   libatkmm-1.6-dev (>= 2.22.2),
+   libglibmm-2.4-dev (>= 2.44.0-2~),
+   libcairomm-1.0-dev (>= 1.10.0-1.2~),
+   libpangomm-1.4-dev (>= 2.36

Bug#794222: Missing patch

[Carlos O'Donell]

On Mon, Aug 17, 2015 at 4:34 PM, Aurelien Jarno  wrote:
>> So this is IMO, the wrong thing to do. You should push the patch into
>> upstream 2.19 stable and rebase instead of keeping the patch in debian
>> svn. Given the patch is already in upstream master it is OK to commit
>> to 2.19 stable, and post to libc-stable stating you checked in this
>> fix. That way debian gets broader testing of the patches we are using
>> instead of the narrower "just debian" users.
>
> If it is fine to push this kind of patch in this branch, I would
> certainly do that. I also backported for debian patch b0a3c164. Would
> it be possible to also push it to the branch?

If the patch doesn't change API/ABI, and it was accepted for master,
then it's perfectly acceptable to push to 2.19 stable branch.

You post your commit email to libc-stable so other maintainers know
why you're pushing the patch.

You'd post a Subject:[COMMITTED] 2.19: Fix blah blah blah, Body:
Cherry picked fix for the ppc64le bug X into 2.19.

Following the usual cherry pick process:
https://sourceware.org/glibc/wiki/GlibcGit#Cherry_Pick_Changes_From_Another_Branch

Then you're done. The 2.19 branch is a rolling stable release from
which you can rebase your own distro branches, either external (on
sourceware) or internal (in your own repos in the distro).

Cheers,
Carlos.

Bug#794222: Missing patch

[Carlos O'Donell]

On Mon, Aug 17, 2015 at 7:06 PM, Carlos O'Donell
 wrote:
> On Mon, Aug 17, 2015 at 4:34 PM, Aurelien Jarno  wrote:
>>> So this is IMO, the wrong thing to do. You should push the patch into
>>> upstream 2.19 stable and rebase instead of keeping the patch in debian
>>> svn. Given the patch is already in upstream master it is OK to commit
>>> to 2.19 stable, and post to libc-stable stating you checked in this
>>> fix. That way debian gets broader testing of the patches we are using
>>> instead of the narrower "just debian" users.
>>
>> If it is fine to push this kind of patch in this branch, I would
>> certainly do that. I also backported for debian patch b0a3c164. Would
>> it be possible to also push it to the branch?
>
> If the patch doesn't change API/ABI, and it was accepted for master,
> then it's perfectly acceptable to push to 2.19 stable branch.
>
> You post your commit email to libc-stable so other maintainers know
> why you're pushing the patch.
>
> You'd post a Subject:[COMMITTED] 2.19: Fix blah blah blah, Body:
> Cherry picked fix for the ppc64le bug X into 2.19.
>
> Following the usual cherry pick process:
> https://sourceware.org/glibc/wiki/GlibcGit#Cherry_Pick_Changes_From_Another_Branch
>
> Then you're done. The 2.19 branch is a rolling stable release from
> which you can rebase your own distro branches, either external (on
> sourceware) or internal (in your own repos in the distro).

Please make sure to merge the ChangeLog and NEWS though, and start a
new 2.19.1 NEWS section if it isn't started. That way if someone wants
to cut a release they can. Though the intent is never to cut a release
and always roll the branches and let distros rebase.

c.

Bug#793331: RFS: postsrsd/1.2-1 [ITP]

[Tomasz Buchert]

On 17/08/15 21:53, Oxan van Leeuwen wrote:
> Hi,
>
> On 15-08-15 12:21, Tomasz Buchert wrote:
> >I've tested the AppArmor profile too, it looks fine, although I'm not
> >sure if 'm' is needed in the profile for '/usr/sbin/postsrsd', since
> >it seems to work just fine without it.  I've a rather basic knowledge
> >about AppArmor, so if you could explain it to me, I'd be grateful.
> I'm not sure about it either, I just copied the AppArmor profile from
> upstream. Judging from the AppArmor docs it's indeed not needed, I'll do
> some further research tomorrow and remove it if possible.

Hi,
great! Just nit-picking here, really. And trying to understand
AppArmor :).

>
> >And the last thing: in the systemd unit, you do:
> >
> >-d$${SRS_DOMAIN:-$$(postconf -h mydomain 2>/dev/null)}
> >
> >Well, first if SRS_DOMAIN is set to something that it's fine, if it's not,
> >then postconf is used to get the mail server domain. But postconf may not
> >be present! You probably need to depend on postfix, unless postsrsd can be 
> >used
> >with other mail software.
> Technically postsrsd can be used with other mail servers too, though I doubt
> it will happen in practice. Is it really a problem if postconf is called
> when it's not present, though?

Yes, I tried without postconf present and the unit failed.

> Its output is silenced, and postsrsd fails
> when the -d argument is empty anyway.

I don't think you want this systemd unit to fail *by default*.

>
> >I'd also recommend using EnvironmentFile in your systemd unit [1].
> The systemd unit is already loading /etc/default/postsrsd as
> EnvironmentFile, it's just the defaults that are in the systemd unit. Not
> sure why I did that though (I believe we usually don't support removing
> files from /etc/default), so they can be safely removed. I'll push a fix.

Sorry, I didn't notice that. I agree, though, that it would make sense
to put all configuation in one place.

>
> >I also pushed some minor fixes.
> Are you sure? I don't see any new commits in the collab-maint repository.
>

No, I'm not sure ;). It's pushed right now (sometimes I miss svn, where
when you commit you also push ;) ).

> >When this is done, I'll be happy to push your package,
> >I already use it myself for some time :).
> That's great!
>
> Cheers,
> Oxan
>

Cheers,
Tomasz


signature.asc
Description: Digital signature

Bug#795608: krdc: Package uninstallable?

[Lisandro Damián Nicanor Pérez Meyer]

On Saturday 15 August 2015 20:03:35 Christian Perrier wrote:
[snip]

Hi Christian!

> The package is currently uninstallable (it actually disappeared from
> my system during a non-controlled dist-upgrade):
[snip]

Yes, and the problem is actually:

>   APT policy: (500, 'unstable'), (101, 'experimental')
[snip]

It basically boils down to us not having enough time to push all the plasma5 
stuff to unstable in time to the gcc5 transition. I do have both testing and 
unstable (with apt preferring testing while the gcc5 transition happens) and I 
do have krdc. So there must be a way to downgrade whatever is necessary to get 
testing's version.

On the other hand if you are in unstable you can install krdc from 
experimental. If you have any sort of dependencies problem check if rebuilding 
the package against a current unstable chroot fixes it. If you need more help 
please do not heasitate to ping me on #debian-kde.

Cheers! Lisandro.

-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Didier 'OdyX' Raboud]

Hi Charles, and thanks for your feedback,

Le lundi, 17 août 2015, 21.25:59 Charles Plessy a écrit :
> I think that option D has two fundamental flaws and I would like to
> recommend the TC against voting for it.
> 
> * First, if it is voted, nothing will happen.
> 
> If the TC adopts option D, and if the maintainer (no plural) of the
> 'menu' package decides to not follow point 3's recommendation, what
> will be the practical difference between option D and option Z ?

I disagree with this, because of the last sentence of D1, put in force 
using §6.1.1 (decide on any matter of technical policy): "Applications 
providing a .desktop file should not provide a Debian menu file." This 
will allow maintainers that _do_ provide .desktop files to stop 
providing .menu files as well.

> I voiced this concern in 2014 (741573#450), but got no answer.  Who do
> you expect to do the work ?

Either the 'menu' maintainer and/or anyone sufficiently interested in 
keeping said system relevant. With D1 in place, I expect .menu files to 
start disappearing from the archive at a good pace; it will become 
somewhat urgent for those relying on the menu system to work towards 
having this .desktop-to-menu translation infrastructure in place.

> The reason I ask is that option D carries nothing new.  In 2008, we
> already had a discussion which outcome was very similar to what is
> proposed in option D.
> 
> https://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries

I think it is quite reasonable to assume that Keith's proposal is a 
derivative of that proposal.

> * Second, it does not solve the problem that I sumbitted to the TC.

The TC is currently trying to decide whether to decide on the conflict 
(AB vs C) or to decide on the 'menu' matter of technical policy (D).

I honestly think all 4 options would resolve the "unresolvable conflict" 
that you referred to the TC.

> See in particular Josselin's objection in 741573#405 and Keith's
> answer:
>
> > One of the problems I have with your proposal, compared to
> > Charles’ original patch, is that it encourages maintainers of
> > hundreds of (IMHO useless) menu files to port them to the desktop
> > format.

I agree that the current proposition doesn't address this problem in D1, 
in that it says:
> packages for which the Debian menu system currently applies should
> provide a .desktop file

One key word is "currently" in there. I think it is reasonable to read 
this as "run 's/register a menu entry/provide a FreeDesktop .desktop 
file/g' over Policy §9.6". It would certainly not prevent further 
changes to §9.6 as long as the TC decision is respected.

From what I understand of your opposition, you're afraid that further 
discussions around softening the "all packages that provide applications 
that need not be passed any special command line arguments for normal 
operation should provide a FreeDesktop .desktop file entry for those 
application" part would be met with unresolvable opposition from Bill, 
right? What about the following formulation then (not yet entirely 
convinced, but I hope that's a step forward)?

>   1. The Technical Committee resolves that applications providing a
>  .desktop file should not provide a Debian menu file.

This would delegate the decision on which applications are supposed to 
provide a .desktop file to (arguably yet another) the Debian Policy 
process.

Cheers,
OdyX

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

Bug#795915: please upload 0.8.3 to unstable

[Yaroslav Halchenko]

Package: python-smmap
Version: 0.8.3-1
Severity: normal

fresh release/snapshot of python-git needs updated/fixed version, so it would
be nice to see 0.8.3 in unstable to progress forward.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-smmap depends on:
ii  python  2.7.9-1

python-smmap recommends no packages.

Versions of packages python-smmap suggests:
ii  python-nose  1.3.6-1

-- no debconf information

Bug#795826: Bug#795835: epydoc: Please use (deterministic) sorting for module and class trees

[Kenneth Pronovici]

Hi Val,

I'll apply both of these patches and upload sometime soon, hopefully
within the next few days.

KEN

Bug#795911: jessie-pu: package gtk+3.0/3.14.5-1+deb8u1

[Ruben Undheim]

> It looks like #748469 was fixed in upstream 3.16.5:
> http://ftp.gnome.org/pub/gnome/sources/gtk+/3.16/gtk+-3.16.5.changes
> and #773135 was fixed in 3.15.4 :
> http://ftp.acc.umu.se/pub/gnome/sources/gtk+/3.15/gtk+-3.15.4.changes

Thanks Mert,

The versions you mention were never uploaded to Debian.
I found the relevant Debian version numbers and added them to the two bug 
reports.

See:
  https://bugs.debian.org/773135 
  https://bugs.debian.org/787419

I hope it looks better now, Adam. I will remember to do this first the next 
time.

Thanks!

Cheers,
Ruben


signature.asc
Description: Digital signature

Bug#795914: ITP: cpustat -- lightweight cpu utilization monitoring

[Colin Ian King]

Package: wnpp
Severity: wishlist
Owner: Colin Ian King 

* Package name: cpustat
  Version : V0.01.21
  Upstream Author : Colin Ian King 
* URL : http://kernel.ubuntu.com/~cking/cpustat
* License : GPL-2+
  Programming Lang: C
  Description : lightweight cpu utilization monitoring

 cpustat periodically dumps out the current CPU utilisation statistics
 of running processes. cpustat has been optimised to have a minimal CPU
 overhead and typically uses about 35% of the CPU compared to top. cpustat
 also includes some statistical analysis options that can help characterise
 the way CPUs are being loaded. 

Bug#795911: jessie-pu: package gtk+3.0/3.14.5-1+deb8u1

[Mert Dirik]

On Mon, 17 Aug 2015 23:35:29 +0200 Ruben Undheim 
 wrote:
> > The BTS metadata for #748469 and #773135 indicates that they are 
not yet

> > fixed in unstable. If that's correct, then they need to be resolved
> > there before we can look at fixing them in stable; if not, then the
> > metadata needs to be updated to correctly reflect when (i.e. in which
> > version(s)) the bugs were fixed.
>
> Thanks for a very quick response. I have confirmed that the bugs are 
fixed in

> unstable. I've both tried to provoke the bug to make it appear, and I've
> checked the source code to see that the implementation of the bugfix 
is exactly

> the same in unstable as here.
>
> I will try to quickly look up exactly which version fixed it and add it
> appropriately to the bug request. Then I will notify you.
>

It looks like #748469 was fixed in upstream 3.16.5: 
http://ftp.gnome.org/pub/gnome/sources/gtk+/3.16/gtk+-3.16.5.changes
and #773135 was fixed in 3.15.4 : 
http://ftp.acc.umu.se/pub/gnome/sources/gtk+/3.15/gtk+-3.15.4.changes

Bug#795913: libmail-thread-perl: [PATCH] avoid failing grouping by subject with missing references

[Eric Wong]

Package: libmail-thread-perl
Version: 2.55-1
Severity: normal
Tags: upstream patch

Dear Maintainer,

With incomplete threads, It is possible to for the topmost subroutine to
return undef, so do not blindy assume the simple_subject call will be
made on a Mail::Thread::Container object.

Attached is a patch which avoids the issue by skipping as if the
subject were empty.

Note: upstream hasn't been responsive in years, but Cc-ing the RT
address at CPAN just in case.

-- System Information:
Debian Release: 7.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
-- no debconf information
>From 9d1837f2118efa614d1acddd09ea7f53aba15ba4 Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Mon, 17 Aug 2015 21:16:25 +
Subject: [PATCH] avoid failing grouping by subject with missing references

It is possible to for the topmost subroutine to return
undef, so do not blindy assume the simple_subject call
will be made on a Mail::Thread::Container object.
---
 Thread.pm | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Thread.pm b/Thread.pm
index c6f3230..941ae31 100644
--- a/Thread.pm
+++ b/Thread.pm
@@ -70,7 +70,8 @@ sub _group_set_bysubject {
 
 my %subject;
 for (my $walk = $root->child; $walk; $walk = $walk->next) {
-my $sub = $walk->topmost->simple_subject or next;
+my $topmost = $walk->topmost or next;
+my $sub = $topmost->simple_subject or next;
 # Add this container to the hash if:
 # - There is no container in the hash with this subject, or
 # - This one is a dummy container and the old one is not: the dummy
@@ -97,7 +98,8 @@ sub _group_set_bysubject {
 for ($walk = $root->child, $rest = eval{ $walk->next };
  $walk;
  $prev = $walk, $walk = $rest, $rest = eval { $rest->next }) {
-my $subj = $walk->topmost->simple_subject or next;
+my $topmost = $walk->topmost or next;
+my $subj = $topmost->simple_subject or next;
 my $old = $subject{$subj};
 next if $old == $walk;
 
-- 
EW

Bug#795911: jessie-pu: package gtk+3.0/3.14.5-1+deb8u1

[Ruben Undheim]

> The BTS metadata for #748469 and #773135 indicates that they are not yet
> fixed in unstable. If that's correct, then they need to be resolved
> there before we can look at fixing them in stable; if not, then the
> metadata needs to be updated to correctly reflect when (i.e. in which
> version(s)) the bugs were fixed.

Thanks for a very quick response. I have confirmed that the bugs are fixed in
unstable. I've both tried to provoke the bug to make it appear, and I've
checked the source code to see that the implementation of the bugfix is exactly
the same in unstable as here.

I will try to quickly look up exactly which version fixed it and add it
appropriately to the bug request. Then I will notify you.

Thanks.

Cheers,
Ruben


signature.asc
Description: Digital signature

Bug#795912: libucommon-dev: arch-dependent files in "Multi-Arch: same" package

[Jakub Wilk]

Package: libucommon-dev
Version: 6.4.4-2
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

libucommon-dev is marked as "Multi-Arch: same", but the following files 
are architecture-dependent:


/usr/bin/commoncpp-config
/usr/bin/ucommon-config

An example diff between i386 and amd64 is attached.

--
Jakub Wilk
diff -ur libucommon-dev_6.4.4-2_i386/usr/bin/commoncpp-config 
libucommon-dev_6.4.4-2_amd64/usr/bin/commoncpp-config
--- libucommon-dev_6.4.4-2_i386/usr/bin/commoncpp-config2015-08-17 
13:46:00.0 +0200
+++ libucommon-dev_6.4.4-2_amd64/usr/bin/commoncpp-config   2015-08-17 
12:01:46.0 +0200
@@ -11,7 +11,7 @@
 
 prefix="/usr"
 includedir="/usr/include"
-libdir="/usr/lib/i386-linux-gnu"
+libdir="/usr/lib/x86_64-linux-gnu"
 modflags="-module -shared -avoid-version"
 
 usage()
diff -ur libucommon-dev_6.4.4-2_i386/usr/bin/ucommon-config 
libucommon-dev_6.4.4-2_amd64/usr/bin/ucommon-config
--- libucommon-dev_6.4.4-2_i386/usr/bin/ucommon-config  2015-08-17 
13:46:00.0 +0200
+++ libucommon-dev_6.4.4-2_amd64/usr/bin/ucommon-config 2015-08-17 
12:01:46.0 +0200
@@ -11,7 +11,7 @@
 
 prefix="/usr"
 includedir="/usr/include"
-libdir="/usr/lib/i386-linux-gnu"
+libdir="/usr/lib/x86_64-linux-gnu"
 
 usage()
 {
@@ -76,7 +76,7 @@
 ;;
 
   --libs)
-   echo -L/usr/lib/i386-linux-gnu -lusecure -lucommon -lgnutls   
-lrt  -ldl -lpthread 
+   echo -L/usr/lib/x86_64-linux-gnu -lusecure -lucommon -lgnutls   
-lrt  -ldl -lpthread 
 ;;
 
   --minimal)

Bug#791169: nmu diff for libsidplayfp 1.8.1-1.1

[GCS]

Hi Julien,

On Mon, Aug 17, 2015 at 9:04 PM, Julien Cristau  wrote:
> I've prepared a NMU for libsidplayfp, to deal with the libstdc++ transition,
> and will shortly upload it to the 1-day delayed queue.  Please find the
> debdiff below.
 Please withdraw it, as the rename already happened. It was
libsidplayfp3 before and was renamed with the new upstream release to
libsidplayfp4 [1] for the GCC 5 transition (this also matches the new
soname). With your upload it would be renamed twice, from
libsidplayfp3 through libsidplayfp4 to libsidplayfp4v5 . Please
describe why is this necessary if needed. Also as I know we don't
close transition bugs from changelog, but reassign it to
release.debian.org and tag it transition. What may I miss?

Thanks,
Laszlo/GCS
[1] https://packages.qa.debian.org/libs/libsidplayfp/news/20150812T213902Z.html

Bug#795206: FTBFS: test failures (with libdate-manip-perl)

[Niko Tyni]

On Tue, Aug 11, 2015 at 08:39:24PM +0200, gregor herrmann wrote:
> Source: libgedcom-perl
> Version: 1.19-2
> Severity: serious
> Tags: upstream
> Justification: fails to build from source
> Forwarded: https://github.com/pjcj/Gedcom.pm/issues/5

> As discovered by the reproducible build team and already noted in the
> upstream bug tracker (and confirmed locally with and without
> libdate-manip-perl installed), this package fails its tests if
> libdate-manip-perl is installed:

This goes away if the test suite is run with DATE_MANIP=DM5 in the
environment. I see this enables an older Date::Manip interface
that is no longer maintained, 

All the failures I'm seeing are of the type

  t/basic.t .. 9/1501 # Test 1464 got: "2 DATE Monday, 17th 
August 2015\n" (t/Basic.pm at line 32 fail #1464)
  #  Expected: "2 DATE AFT1989\n"
  #  t/Basic.pm line 32 is: &Test::ok(@a)
  t/basic.t .. Failed 1/1501 subtests 
 
-- 
Niko Tyni   nt...@debian.org

Bug#795910: python3-yaql: yaql not working: ImportError: No module named 'context'

[Gerardo Martín Chaves]

Missing stack trace:

$ yaql
Traceback (most recent call last):
  File "/usr/bin/yaql", line 9, in 
load_entry_point('yaql==0.2.3', 'console_scripts', 'yaql')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
558, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
2682, in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
2355, in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
2361, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/yaql/__init__.py", line 16, in

import context
ImportError: No module named 'context'


On Mon, Aug 17, 2015 at 6:02 PM, Gerardo Martin Chaves 
wrote:

> Package: python3-yaql
> Version: 0.2.3-2
> Severity: grave
> Tags: patch
> Justification: renders package unusable
>
> yaql (python 3 package) fails to launch or import because uses python 2
> syntax.
>
> 2to3 seams to fix the issue.
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'stable-
> updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.1.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=es_UY.UTF-8, LC_CTYPE=es_UY.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages python3-yaql depends on:
> ii  dpkg 1.18.2
> ii  python3-ply  3.4-5
> ii  python3.43.4.3-7
> pn  python3:any  
>
> python3-yaql recommends no packages.
>
> python3-yaql suggests no packages.
>



-- 
Kiov - Gerardo Martín Chaves
Linux user #449707
Desktop: Debian Testing/Unstable/Experimental mix
Profile: https://plus.google.com/+GerardoMartinChaves/about


Search with Duck Duck Go: http://duckduckgo.com/?t=kiov

Bug#776696: please update GTK+3 in Jessie to the latest 3.14.x bugfix release

[Mert Dirik]

Wow you're fast! Thank you very much for your effort. I hope it gets
an ACK soon.

On Tue, Aug 18, 2015 at 12:13 AM, Ruben Undheim  wrote:
> Then I've filed a request:
>   https://bugs.debian.org/795911
>
> Let's see how it goes. :)
>
> Ruben
>
> 2015-08-17 22:44 GMT+02:00 Mert Dirik :
>> On Mon, Aug 17, 2015 at 11:37 PM, Ruben Undheim  
>> wrote:
>>> Hi,
>>>
>>> Thanks Mert.
>>>
>>> Then, we've tested all of them.
>>>
>>> My test results:
>>>
>>> #787419: OK
>>> reproduced the same way you did
>>> fixed with patched version
>>>
>>> #748469: OK
>>> reproduced multiple times by opening font chooser in gnome-terminal -
>>> selecting one font - and searching for another
>>> fixed with patched version
>>>
>>> #773135: OK
>>> I did what you described here. First installed emacs, then chose "Open
>>> with" in nautilus.
>>> Big icon with original version. Normal icon size with patched version
>>>
>>> #771205: Fail
>>> Not able to reproduce - nor see the fixed result
>>>
>>> #788002: OK
>>> I downloaded the MP3 file that was linked to in the original bug
>>> report. I removed the newlines from the comment field with easytag on
>>> a system with a newer version of gtk, and then opened it with Jessie's
>>> gtk. easytag crashed
>>> After installing patched version - problem gone.
>>>
>>>
>>> I agree with you, I remove #771205 for now. I will file a
>>> release.debian.org bug report and see what response we get.
>>>
>>> It would however be nice if someone from the pkg-gnome team could give
>>> us some feedback. Based on the response from Andreas H. [1], I assume
>>> that it is ok that we contact the Stable release team. It seems like
>>> we care more about these things being fixed in Jessie than the
>>> maintainer team, so it is probably fair that we do that job.
>>>
>>>
>>> [1] 
>>> http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/2015-August/121106.html
>>>
>>
>> Okay, that's great.
>> I think it should be OK as long as we explain why *we* open the bug
>> report and provide a link to the Andreas' mail. After getting and ACK
>> we should ask for either sponsorship or a new upload by the
>> maintainers themselves.

Bug#795911: jessie-pu: package gtk+3.0/3.14.5-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Mon, 2015-08-17 at 23:06 +0200, Ruben Undheim wrote:
> gtk+3.0 in Jessie is affected by several quite serious bugs. 3 of them are so
> serious that they from time to time cause users losing their work. There has
> been a request to update gtk+3 to the latest 3.14.x bugfix release [1], but
> since this probably is unlikely to be accepted (??), we have now rather
> collected the most important bugs and made patches of them to create a +deb8u1
> release. The source debdiff for this is added to the bottom of this bug 
> report.
[...]
> The three first bugs (#787419, #748469, #788002) are (in my opinion) extremely
> important to get fixed in Jessie. Justification for why they should go into
> Jessie has been added to the Description field of every patch file. The last
> bug (#773135) is not that important, but still very useful to get in since the

The BTS metadata for #748469 and #773135 indicates that they are not yet
fixed in unstable. If that's correct, then they need to be resolved
there before we can look at fixing them in stable; if not, then the
metadata needs to be updated to correctly reflect when (i.e. in which
version(s)) the bugs were fixed.

Regards,

Adam

Bug#776696: please update GTK+3 in Jessie to the latest 3.14.x bugfix release

[Ruben Undheim]

Then I've filed a request:
  https://bugs.debian.org/795911

Let's see how it goes. :)

Ruben

2015-08-17 22:44 GMT+02:00 Mert Dirik :
> On Mon, Aug 17, 2015 at 11:37 PM, Ruben Undheim  
> wrote:
>> Hi,
>>
>> Thanks Mert.
>>
>> Then, we've tested all of them.
>>
>> My test results:
>>
>> #787419: OK
>> reproduced the same way you did
>> fixed with patched version
>>
>> #748469: OK
>> reproduced multiple times by opening font chooser in gnome-terminal -
>> selecting one font - and searching for another
>> fixed with patched version
>>
>> #773135: OK
>> I did what you described here. First installed emacs, then chose "Open
>> with" in nautilus.
>> Big icon with original version. Normal icon size with patched version
>>
>> #771205: Fail
>> Not able to reproduce - nor see the fixed result
>>
>> #788002: OK
>> I downloaded the MP3 file that was linked to in the original bug
>> report. I removed the newlines from the comment field with easytag on
>> a system with a newer version of gtk, and then opened it with Jessie's
>> gtk. easytag crashed
>> After installing patched version - problem gone.
>>
>>
>> I agree with you, I remove #771205 for now. I will file a
>> release.debian.org bug report and see what response we get.
>>
>> It would however be nice if someone from the pkg-gnome team could give
>> us some feedback. Based on the response from Andreas H. [1], I assume
>> that it is ok that we contact the Stable release team. It seems like
>> we care more about these things being fixed in Jessie than the
>> maintainer team, so it is probably fair that we do that job.
>>
>>
>> [1] 
>> http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/2015-August/121106.html
>>
>
> Okay, that's great.
> I think it should be OK as long as we explain why *we* open the bug
> report and provide a link to the Andreas' mail. After getting and ACK
> we should ask for either sponsorship or a new upload by the
> maintainers themselves.

Bug#795911: jessie-pu: package gtk+3.0/3.14.5-1+deb8u1

[Ruben Undheim]

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

Hi,

gtk+3.0 in Jessie is affected by several quite serious bugs. 3 of them are so
serious that they from time to time cause users losing their work. There has
been a request to update gtk+3 to the latest 3.14.x bugfix release [1], but
since this probably is unlikely to be accepted (??), we have now rather
collected the most important bugs and made patches of them to create a +deb8u1
release. The source debdiff for this is added to the bottom of this bug report.

Since the pkg-gnome maintainers do not seem to be as affected by this as
others, we (the sufferers) were vaguely encouraged to get in contact with the
Stable Release Team ourself (See [2]), and then come back to the maintainers if
we have negotiated acceptance with you.

The package has been tested before and after the fix and the results can be
found here: [3]. The package was of course built and tested in Jessie (not sid).

The plan is to tell the maintainers about the outcome of this request, so that
they can do the necessary steps to tweak the changelog entry and get the
package uploaded.

The three first bugs (#787419, #748469, #788002) are (in my opinion) extremely
important to get fixed in Jessie. Justification for why they should go into
Jessie has been added to the Description field of every patch file. The last
bug (#773135) is not that important, but still very useful to get in since the
package anyway will be updated. Please let us know if we should skip that and
only keep the first three. All the bugs have of course already been fixed
upstream and in sid.

Let us know if there is anything else we should do to help out.

Thanks for your attention.

Best regards,
Ruben Undheim


[1] https://bugs.debian.org/776696
[2] 
http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/2015-August/121106.html
[3] 
http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/2015-August/121138.html


The source debdiff is as follows:


diff -Nru gtk+3.0-3.14.5/debian/changelog gtk+3.0-3.14.5/debian/changelog
--- gtk+3.0-3.14.5/debian/changelog 2014-11-11 18:55:48.0 +0100
+++ gtk+3.0-3.14.5/debian/changelog 2015-08-17 20:20:06.0 +0200
@@ -1,3 +1,15 @@
+gtk+3.0 (3.14.5-1+deb8u1) jessie; urgency=medium
+
+  [ Ruben Undheim ]
+  * Added patches for three serious bugs:
+- debian/patches/074_fix_freeze_while_resume_events.patch (Closes: #787419)
+- debian/patches/075_fontchoose_crash_bugfix.patch (Closes: #748469)
+- debian/patches/076_treeview_dont_create_overly_large.patch (Closes: 
#788002)
+  * Added patch for one annoying bug:
+- debian/patches/081_fix_huge_icons.patch (Closes: #773135)
+
+ -- maintainer   Mon, 17 Aug 2015 09:53:13 +0200
+
 gtk+3.0 (3.14.5-1) unstable; urgency=medium
 
   * New upstream bugfix release.
diff -Nru 
gtk+3.0-3.14.5/debian/patches/074_fix_freeze_while_resume_events.patch 
gtk+3.0-3.14.5/debian/patches/074_fix_freeze_while_resume_events.patch
--- gtk+3.0-3.14.5/debian/patches/074_fix_freeze_while_resume_events.patch  
1970-01-01 01:00:00.0 +0100
+++ gtk+3.0-3.14.5/debian/patches/074_fix_freeze_while_resume_events.patch  
2015-08-17 20:20:06.0 +0200
@@ -0,0 +1,59 @@
+Description: This patch fixes a bug causing gtk applications to freeze
+ every now and then.
+ .
+ It deserves to be applied in Jessie because it will and have caused users
+ to lose their work. One common consequence of the bug is that all open
+ gnome-terminal instances may suddenly crash at the same time.
+Author: Ruben Undheim 
+Bug-Debian: https://bugs.debian.org/787419
+Origin: upstream
+Bug: https://bugzilla.gnome.org/show_bug.cgi?id=742636
+Last-Update: 2015-08-17
+
+Index: gtk+3.0-3.14.5/gdk/gdkinternals.h
+===
+--- gtk+3.0-3.14.5.orig/gdk/gdkinternals.h
 gtk+3.0-3.14.5/gdk/gdkinternals.h
+@@ -240,6 +240,7 @@ struct _GdkWindow
+   guint in_update : 1;
+   guint geometry_dirty : 1;
+   guint event_compression : 1;
++  guint frame_clock_events_paused : 1;
+
+   /* The GdkWindow that has the impl, ref:ed if another window.
+* This ref is required to keep the wrapper of the impl window alive
+Index: gtk+3.0-3.14.5/gdk/gdkwindow.c
+===
+--- gtk+3.0-3.14.5.orig/gdk/gdkwindow.c
 gtk+3.0-3.14.5/gdk/gdkwindow.c
+@@ -10603,6 +10603,8 @@ gdk_window_flush_events (GdkFrameClock *
+   _gdk_display_pause_events (display);
+
+   gdk_frame_clock_request_phase (clock, GDK_FRAME_CLOCK_PHASE_RESUME_EVENTS);
++
++  window->frame_clock_events_paused = TRUE;
+ }
+
+ static void
+@@ -10629,6 +10631,8 @@ gdk_window_resume_events (GdkFrameClock
+
+   display = gdk_window_get_display (window);
+   _gdk_display_unpause_events (display);
++
++  window->frame_clock_events_paused = FALSE;
+ }
+
+ static void
+@@ -10661,6 +10665,9 @@ gdk_window_set_frame_clock 

Bug#795910: python3-yaql: yaql not working: ImportError: No module named 'context'

[Gerardo Martin Chaves]

Package: python3-yaql
Version: 0.2.3-2
Severity: grave
Tags: patch
Justification: renders package unusable

yaql (python 3 package) fails to launch or import because uses python 2 syntax.

2to3 seams to fix the issue.


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

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

Versions of packages python3-yaql depends on:
ii  dpkg 1.18.2
ii  python3-ply  3.4-5
ii  python3.43.4.3-7
pn  python3:any  

python3-yaql recommends no packages.

python3-yaql suggests no packages.
--- yaql/__init__.py	(original)
+++ yaql/__init__.py	(refactored)
@@ -12,8 +12,8 @@
 #License for the specific language governing permissions and limitations
 #under the License.
 
-import parser
-import context
+from . import parser
+from . import context
 from yaql.functions import builtin, extended
 
 __versioninfo__ = (0, 2, 3)
--- yaql/context.py	(original)
+++ yaql/context.py	(refactored)
@@ -14,7 +14,7 @@
 
 from functools import wraps
 import inspect
-from exceptions import NoArgumentFound
+from .exceptions import NoArgumentFound
 
 
 class Context():
--- yaql/exceptions.py	(original)
+++ yaql/exceptions.py	(refactored)
@@ -20,9 +20,9 @@
 
 class NoFunctionRegisteredException(YaqlException):
 def __init__(self, func_name, arg_num=None):
-self.func_name = func_name
+self.__name__ = func_name
 self.arg_num = arg_num
-msg = "No function called '{0}' is registered".format(self.func_name)
+msg = "No function called '{0}' is registered".format(self.__name__)
 if self.arg_num:
 msg += " which has {0} arguments".format(self.arg_num)
 super(NoFunctionRegisteredException, self).__init__(msg)
--- yaql/expressions.py	(original)
+++ yaql/expressions.py	(refactored)
@@ -13,8 +13,8 @@
 #under the License.
 
 import types
-from context import *
-from exceptions import YaqlExecutionException, NoFunctionRegisteredException
+from .context import *
+from .exceptions import YaqlExecutionException, NoFunctionRegisteredException
 import yaql
 
 
@@ -87,7 +87,7 @@
 fs = self._try_invoke(
 resolvers,
 [self.function_name, this], context) or []
-if not isinstance(fs, types.ListType):
+if not isinstance(fs, list):
 fs = [fs]
 except YaqlExecutionException:
 fs = []
@@ -223,7 +223,7 @@
 ok = True
 if arg_type:
 ok = ok and isinstance(arg_val, arg_type)
-if type(arg_val) == types.BooleanType:
+if type(arg_val) == bool:
 ok = ok and type(arg_val) == arg_type
 if custom_validator:
 ok = ok and custom_validator(arg_val)
--- yaql/parser.py	(original)
+++ yaql/parser.py	(refactored)
@@ -14,9 +14,9 @@
 
 import types
 import ply.yacc as yacc
-import expressions
-import exceptions
-import lexer
+from . import expressions
+from . import exceptions
+from . import lexer
 import tempfile
 
 
@@ -96,7 +96,7 @@
 """
 func : value '.' FUNC arg ')'
 """
-if isinstance(p[4], types.ListType):
+if isinstance(p[4], list):
 arg = p[4]
 else:
 arg = [p[4]]
@@ -114,7 +114,7 @@
 """
 func : FUNC arg ')'
 """
-if isinstance(p[2], types.ListType):
+if isinstance(p[2], list):
 arg = p[2]
 else:
 arg = [p[2]]
@@ -126,11 +126,11 @@
 arg : arg ',' arg
 """
 val_list = []
-if isinstance(p[1], types.ListType):
+if isinstance(p[1], list):
 val_list += p[1]
 else:
 val_list.append(p[1])
-if isinstance(p[3], types.ListType):
+if isinstance(p[3], list):
 val_list += p[3]
 else:
 val_list.append(p[3])
--- yaql/utils.py	(original)
+++ yaql/utils.py	(refactored)
@@ -18,9 +18,9 @@
 
 def limit(generator, limit=MAX_GENERATOR_ITEMS):
 res = []
-for i in xrange(limit):
+for i in range(limit):
 try:
-res.append(generator.next())
+res.append(next(generator))
 except StopIteration:
 return res
 raise YaqlSequenceException(limit)
--- yaql/cli/cli_functions.py	(original)
+++ yaql/cli/cli_functions.py	(refactored)
@@ -31,7 +31,7 @@
 @ContextAware()
 def main(context):
 print("Yet Another Query Language - command-line query tool")
-print("Version {0}".format(version))
+print(("Version {0}".format(version)))
 print("Copyright (c) 2013 Mirantis, Inc")
 print("")
 if not cont

Bug#795794: jessie-pu: package nss/3.17.2-1.1+deb8u1

[Adam D. Barratt]

Control: reopen -1

Oops, didn't actually mean to close that...

On Mon, 2015-08-17 at 21:50 +0100, Adam D. Barratt wrote:
> On Mon, 2015-08-17 at 16:19 +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Sun, 2015-08-16 at 22:51 +0200, Christoph Egger wrote:
> > > This is a small patch from mozilla hg. It fixes #774195 and is
> > > confirmed to work. Would be cool if if can be included in the next
> > > stable release.
> > 
> > Please go ahead.
> 
> This now needs rebasing on top of the 3.17.2-1.1+deb8u1 upload from DSA
> 3336, as 3.17.2-1.1+deb8u2.
> 
> Regards,
> 
> Adam

Bug#793641: glibc: too few static TLS slots

[Andreas Cadhalpun]

Control: tag -1 fixed-upstream

Hi Carlos,

On 17.08.2015 21:04, Carlos O'Donell wrote:
> On Sun, Aug 16, 2015 at 12:48 PM, Andreas Cadhalpun
>  wrote:
>>> until there's a better tested and working way to transition
>>> to ffmpeg?
>>
>> This really doesn't have that much to do with the transition to ffmpeg.
>> Any other library that (indirectly) links against sufficiently many
>> STATIC_TLS using ones and is used in some plugin is also affected.
>>
>> Note that there are currently 14 STATIC_TLS slots and gst-libav uses 6,
>> while it used 4 previously. It is a mere coincidence that this increase
>> causes totem to hit the arbitrary limit in glibc.
> 
> The math can't be done that easily, it's actually a heuristic, but
> pretend it works this way for the sake of this discussion.

Apologies for the inaccuracies in my explanation. I'm not that familiar
with glibc internals. ;) 

> The only immediate solution is for debian's glibc to increase
> DTV_SURPLUS to 32 or higher. This is exactly what I did for Fedora.
> 
> The other alternative is to backport Alex's fixes for Sourceware bugs
> BZ #17090, BZ #17620, BZ #17621, BZ #17628, which corrects the
> heuristics behind DTV_SURPLUS which prevent the loading of STATIC_TLS.
> 
> Without Alex's fixes the implementation is limited, by a heuristic, to
> a limited number of libraries with STATIC_TLS, and after Alex's fixes
> (available in glibc 2.22) the limit is "You may load as many
> STATIC_TLS libraries as long as you have static image space for all of
> them" (which is a much higher arbitrary limit).

So this is already fixed upstream. Great!

In that case I don't mind working around that in ffmpeg until glibc 2.22
reaches sid.

Best regards,
Andreas

Bug#794068: AW: Bug#794068: libpam-ldapd: unable to login when ldap-server sends password expiration warning

[Arthur de Jong]

On Mon, 2015-08-17 at 09:06 +, Uibel, Joerg wrote:
> Thank you for the upstream fix. While I realize that you prefer to 
> get a whole new upstream release into jessie, I wonder if there's any 
> reason not to backport the relevant changes [1-3] to the nss-pam
> -ldapd_0.9.4-3 source? I rebuilt the package with these patches 
> applied on my test system and it seems to work just fine.

The changes for this fix can be easily backported (same for #794686).
However, the changes for fixing #759544 (the original reason for making
a new jessie version) are a little more involved. The daemonizing code
in 0.9.5 has seen much more testing than that of a patched 0.9.4
version.

Anyway, I'll see if I can ping the release team again.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


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

Bug#772426: closed by Donald Norwood (Re: mirror submission for debian.mirror.marist.edu)

[Jeff Obrizok]

Let me investigate the configuration and see if that was intentional or
not.

 

I will update the update schedule and get back to you.

 

Can we please leave this open? I would like to get this to meet spec and
get this listed.

 

Thanks!

 

Thanks,

Jeff Obrizok
Network & Security Engineer
Marist College 
3399 North Rd.
Poughkeepsie, NY 12601
845.575.3061 

 

From: Donald Norwood  [mailto:Donald Norwood
] 
Sent: Monday, August 17, 2015 3:55 PM
To: Jeff Obrizok 
Cc: 772...@bugs.debian.org
Subject: Re: Bug#772426: closed by Donald Norwood
 (Re: mirror submission for
debian.mirror.marist.edu)

 


Hi Jeff, 

Thank you for the quick response. 

The original submission was stated to offer only amd64, however the 
mirror itself is offering amd64 and i386. Is this intentional? 

Second the update schedule states once per day, however it is preferred 
to update 4 times a day if possible so that your mirror is in sync with 
the rest of the archive. 

Otherwise everything looks good. 

Best regards, 

Donald Norwood 

Bug#795776: [htop] Excessive memory usage reported compared to free, conky

[OmegaPhil]

On 17/08/15 19:27, Eugene V. Lyubimkin wrote:> Control: tags -1 +
moreinfo unreproducible
>
> Hello!
>> ==
>>
>>   total usedfree  shared  buff/cache   available
>> Mem:  32998636  9011192 1532280   273112  22455164 23306740
>> Swap: 10485756  0   10485756
>>
>> ==
>
> In this full output? Could you re-check?
>
> Htop outputs what free describes in '-/+ buffers/cache' column, but I
don't see it in the output you pasted. They match
> on my system.


Thanks for responding - here is the full output of free without me
fiddling with it (I aligned the previous output):



omega@omega1:~/.config/xfce4/panel$ free
  totalusedfree  shared  buff/cache
available
Mem:   32998636 9515852  466464  26363223016320
22807536
Swap:  10485756   010485756



free is '/usr/bin/free':

75d3b3dc779a953cae6e36fb0e2fdc8b  /usr/bin/free

The md5sum matches on the other x86_64 host at hand (so hopefully GCHQ
haven't rooted me and replaced my binaries...).

Atm htop reports 12550/32225MB used.




signature.asc
Description: OpenPGP digital signature

Bug#795404: cups-backend-bjnp: stops printing after some lines

[Björn Siebke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey Brian,

thank you once again for trying to get that printer working!


> We can test if this behaviour is independent of CUPS and the filtering
> system too,
> 
>   DEVICE_URI=bjnp://db-printer.fritz.box:8611 /usr/lib/cups/backend/bjnp 1 1 
> 1 1 1 /etc/services

I tried this both with and without sudo:

$ sudo DEVICE_URI=bjnp://db-printer.fritz.box:8611
/usr/lib/cups/backend/bjnp 1 1 1 1 1 /etc/services
[sudo] password for bjoern:
INFO: Attempting to connect to host db-printer.fritz.box on port 8611
STATE: +connecting-to-device
STATE: -connecting-to-device
INFO: Connected to db-printer.fritz.box...
DEBUG: Connected to [192.168.178.27]:8611 (IPv4)...
PAGE: 1 1
DEBUG: bjnp_backendRunLoop(print_fd=4, device_fd=5
INFO: Sent print file, 0 bytes...
INFO: Ready to print.

But the printer did nothing.


>> What do you mean by that? Ping the router? Ping cups (which is on my
>> laptop)?
> 
> Ping the printer is what I meant.

I then tried to ping.

$ ping db-printer.fritz.box:8611
ping: unknown host db-printer.fritz.box:8611


Then I looked up the IP adress and changed the router to give the
printer a fixed IP adress.

$ ping 192.168.178.27
PING 192.168.178.27 (192.168.178.27) 56(84) bytes of data.
64 bytes from 192.168.178.27: icmp_seq=1 ttl=64 time=5.73 ms
64 bytes from 192.168.178.27: icmp_seq=2 ttl=64 time=7.56 ms
64 bytes from 192.168.178.27: icmp_seq=3 ttl=64 time=5.09 ms
64 bytes from 192.168.178.27: icmp_seq=4 ttl=64 time=7.13 ms
64 bytes from 192.168.178.27: icmp_seq=5 ttl=64 time=5.68 ms
64 bytes from 192.168.178.27: icmp_seq=6 ttl=64 time=7.40 ms
64 bytes from 192.168.178.27: icmp_seq=7 ttl=64 time=5.09 ms
64 bytes from 192.168.178.27: icmp_seq=8 ttl=64 time=5.25 ms
64 bytes from 192.168.178.27: icmp_seq=9 ttl=64 time=4.98 ms
64 bytes from 192.168.178.27: icmp_seq=10 ttl=64 time=4.97 ms
64 bytes from 192.168.178.27: icmp_seq=11 ttl=64 time=6.70 ms
64 bytes from 192.168.178.27: icmp_seq=12 ttl=64 time=4.93 ms
^C
- --- 192.168.178.27 ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 11015ms
rtt min/avg/max/mdev = 4.938/5.881/7.567/0.987 ms

This worked!
So I did some tests by changing the URI in settings.

bjnp://db-printer.fritz.box:8611 -> problem as decribed initially
ipp://db-printer.fritz.box:8611 -> printer not reachable
bjnp://192.168.178.27 -> problem as decribed initially
ipp://192.168.178.27 -> works!


Finally, I removed the package cups-backend-bjnp. Everything still works!


Thank you once again for your help!
Björn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJV0kk8AAoJECNNcxO8k0eo/XEP/0MajqKRvDvEZK/DsE9SI3Xx
dq+Ck8/9mLLdCGp79IqRkt395ljB1a2QhiUt8Q/zrn3qYyZQjoWHRXUGSfxhLJ6/
1JgY6R1uabmqgXu54nqvftEwJyZ0UyAniuND/1omZkQYR8jTBEmVWfkq83R3uqNz
9ASuKhEj6I6BtSl6rpKfdEhyi/1EZB1g06xqIiD2BwAVBtip+3BKLI/0I9fLVkkc
VXLWyJsT/IRtLXEHCDsleoCEA7mXmeCb1m+V4uBUIFyvMW4o2600yVQfMgJKpZNN
vkZNceA6KPqZd9e5Vs1O/uL6CiMCx5vMQP8WqprfIe6cxhQ4wlJgYZx7osDae7nL
DYBQNm94qw9NHXyfPNM64wqbMi0UP4FURAOxZg9rouYF/rS9aRFc7kEmmORSM+X6
obeABMSNRwFgy4XNBCzaKTgdZ8jn2+eKUQzOBAosS4B1rEERjf0ZlSwMWXIpBG78
IH6Nci3ZYGG9WF4TcS8WdelN6u/LBNRx+1p7LKgqLSz2xSPsyLKjQVj4aZmfQ18N
tWM8qJflUcm5kOqbwZAP6SLuSCSD7DBOLxJVrZysZdwUxTBhUHshJHdD+KXPkmXx
dvzRbxXu3Wd2ufPJhTio+Rx/ziJNFmz/zW00WBf94b7OkiZMn1CaPdAnkO5n8qJK
HPHARRfT95JNTaZEUQwV
=rU9o
-END PGP SIGNATURE-

Bug#795221: gnuplot5-qt: crash in g_slist_copy_deep / assertion failures

[Vincent Lefevre]

I got another assertion failure:

ASSERT INFO:
../src/unix/threadpsx.cpp(1483): assert "!m_isDetached" failed in Wait(): can't 
wait for detached thread

BACKTRACE:
[1] wxThread::Wait(wxThreadWait)
[2] matherr
[3] matherr
[4] __libc_start_main

Backtrace with gdb:

Thread 4 (Thread 0x7f667a874700 (LWP 31406)):
#0  0x7f6696420009 in syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7f669847799a in g_cond_wait_until (cond=cond@entry=0x2ae3df8, 
mutex=mutex@entry=0x2ae3df0, end_time=end_time@entry=15991606336) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gthread-posix.c:1444
now = {tv_sec = 15976, tv_nsec = 606337187}
span = {tv_sec = 14, tv_nsec = 98813}
sampled = 4
res = 
#2  0x7f6698407889 in g_async_queue_pop_intern_unlocked 
(queue=queue@entry=0x2ae3df0, wait=wait@entry=1, 
end_time=end_time@entry=15991606336) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gasyncqueue.c:422
retval = 
__FUNCTION__ = "g_async_queue_pop_intern_unlocked"
#3  0x7f6698407eab in g_async_queue_timeout_pop (queue=0x2ae3df0, 
timeout=timeout@entry=1500) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gasyncqueue.c:543
end_time = 15991606336
retval = 
#4  0x7f669845a3ac in g_thread_pool_thread_proxy () at 
/tmp/buildd/glib2.0-2.44.1/./glib/gthreadpool.c:167
pool = 
local_wakeup_thread_serial = 
last_wakeup_thread_serial = 
have_relayed_thread_marker = 
free_pool = 
task = 0x2
pool = 
#5  0x7f669845a3ac in g_thread_pool_thread_proxy (data=) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gthreadpool.c:364
free_pool = 
task = 0x2
pool = 
#6  0x7f6698459955 in g_thread_proxy (data=0x27a1a30) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gthread.c:764
thread = 0x27a1a30
#7  0x7f66966ef0a4 in start_thread (arg=0x7f667a874700) at 
pthread_create.c:309
__res = 
pd = 0x7f667a874700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140078119077632, 
3897815560806414603, 0, 44975200, 23, 140078119077632, -3973538713952372469, 
-3973584152166319861}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 
0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#8  0x7f669642407d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7f6682a4f700 (LWP 31372)):
#0  0x7f669641b53d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f6698432ebc in g_main_context_iterate (priority=2147483647, n_fds=2, 
fds=0x7f667c1d9980, timeout=-1, context=0x27ea070) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:4103
poll_func = 0x7f66984423e0 
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 2
allocated_nfds = 2
fds = 0x7f667c1d9980
#2  0x7f6698432ebc in g_main_context_iterate (context=0x27ea070, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3803
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 2
allocated_nfds = 2
fds = 0x7f667c1d9980
#3  0x7f6698433242 in g_main_loop_run (loop=0x27ea000) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:4002
__FUNCTION__ = "g_main_loop_run"
#4  0x7f668fef6af6 in gdbus_shared_thread_func (user_data=0x27ea040) at 
/tmp/buildd/glib2.0-2.44.1/./gio/gdbusprivate.c:274
data = 0x27ea040
#5  0x7f6698459955 in g_thread_proxy (data=0x27a1b20) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gthread.c:764
thread = 0x27a1b20
#6  0x7f66966ef0a4 in start_thread (arg=0x7f6682a4f700) at 
pthread_create.c:309
__res = 
pd = 0x7f6682a4f700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140078255240960, 
3897815560806414603, 0, 45207552, 22, 140078255240960, -3973626432753813237, 
-3973584152166319861}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 
0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#7  0x7f669642407d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7f667ba93700 (LWP 31373)):
#0  0x7f669641b53d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f6698432ebc in g_main_context_iterate (priority=2147483647, n_fds=2, 
fds=0x7f66740008c0, timeout=-1, context=0x270e110) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:4103
poll_func = 0x7f66984423e0 
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 2
allocated_nfds = 2
fds = 0x7f66740008c0
#2  0x7f6698432ebc in g_main_context_iterate 
(context=context@entry=0x270e110, block=block@entry=1, 
dispatch=dispatch@entry=1, sel

Bug#776696: please update GTK+3 in Jessie to the latest 3.14.x bugfix release

[Mert Dirik]

On Mon, Aug 17, 2015 at 11:37 PM, Ruben Undheim  wrote:
> Hi,
>
> Thanks Mert.
>
> Then, we've tested all of them.
>
> My test results:
>
> #787419: OK
> reproduced the same way you did
> fixed with patched version
>
> #748469: OK
> reproduced multiple times by opening font chooser in gnome-terminal -
> selecting one font - and searching for another
> fixed with patched version
>
> #773135: OK
> I did what you described here. First installed emacs, then chose "Open
> with" in nautilus.
> Big icon with original version. Normal icon size with patched version
>
> #771205: Fail
> Not able to reproduce - nor see the fixed result
>
> #788002: OK
> I downloaded the MP3 file that was linked to in the original bug
> report. I removed the newlines from the comment field with easytag on
> a system with a newer version of gtk, and then opened it with Jessie's
> gtk. easytag crashed
> After installing patched version - problem gone.
>
>
> I agree with you, I remove #771205 for now. I will file a
> release.debian.org bug report and see what response we get.
>
> It would however be nice if someone from the pkg-gnome team could give
> us some feedback. Based on the response from Andreas H. [1], I assume
> that it is ok that we contact the Stable release team. It seems like
> we care more about these things being fixed in Jessie than the
> maintainer team, so it is probably fair that we do that job.
>
>
> [1] 
> http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/2015-August/121106.html
>

Okay, that's great.
I think it should be OK as long as we explain why *we* open the bug
report and provide a link to the Andreas' mail. After getting and ACK
we should ask for either sponsorship or a new upload by the
maintainers themselves.

Bug#794222: Missing patch

[Aurelien Jarno]

On 2015-08-17 13:17, Carlos O'Donell wrote:
> On Sat, Aug 15, 2015 at 4:31 AM, Aurelien Jarno  wrote:
> > control: fixed -1 glibc/2.21-0experimental0
> >
> > On 2015-08-14 18:28, Tulio Magno Quites Machado Filho wrote:
> >> I believe Debian is missing the following patch for ppc64el:
> >> https://sourceware.org/git/?p=glibc.git;a=commit;h=a53fbd8e6cd2f69bdfa3431d616a5f332aea6664
> >
> > I have just committed a fix to our SVN in the stable branch. If accepted
> > by the Debian stable release manager, we plan to have it in the next
> > stable point release.
> >
> > Given this bug is fixed in the experimental branch, I am marking it as
> > fixed for this version.
> 
> So this is IMO, the wrong thing to do. You should push the patch into
> upstream 2.19 stable and rebase instead of keeping the patch in debian
> svn. Given the patch is already in upstream master it is OK to commit
> to 2.19 stable, and post to libc-stable stating you checked in this
> fix. That way debian gets broader testing of the patches we are using
> instead of the narrower "just debian" users.

If it is fine to push this kind of patch in this branch, I would
certainly do that. I also backported for debian patch b0a3c164. Would
it be possible to also push it to the branch?

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#776696: please update GTK+3 in Jessie to the latest 3.14.x bugfix release

[Ruben Undheim]

Hi,

Thanks Mert.

Then, we've tested all of them.

My test results:

#787419: OK
reproduced the same way you did
fixed with patched version

#748469: OK
reproduced multiple times by opening font chooser in gnome-terminal -
selecting one font - and searching for another
fixed with patched version

#773135: OK
I did what you described here. First installed emacs, then chose "Open
with" in nautilus.
Big icon with original version. Normal icon size with patched version

#771205: Fail
Not able to reproduce - nor see the fixed result

#788002: OK
I downloaded the MP3 file that was linked to in the original bug
report. I removed the newlines from the comment field with easytag on
a system with a newer version of gtk, and then opened it with Jessie's
gtk. easytag crashed
After installing patched version - problem gone.


I agree with you, I remove #771205 for now. I will file a
release.debian.org bug report and see what response we get.

It would however be nice if someone from the pkg-gnome team could give
us some feedback. Based on the response from Andreas H. [1], I assume
that it is ok that we contact the Stable release team. It seems like
we care more about these things being fixed in Jessie than the
maintainer team, so it is probably fair that we do that job.


[1] 
http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/2015-August/121106.html



2015-08-17 22:08 GMT+02:00 Mert Dirik :
> Hi,
>
> Here are my test results:
>
> #787419:
> reproduced in jessie using test script Ruben gave in the relevant bug report
> Confirmed patched version corrects the issue
>
> #748469
> I was heavily affected by this one but strangely I can't reproduce it
> today in gnome-terminal, gnome-tweak-tool or Emacs
> So I couldn't test the fix either
>
> #773135
> reproduced under Gnome shell/nautilus by right clicking a text file
> and checking "open with" menu, Emacs icons are huge
> Confirmed patched version corrects the issue (icons are normal sized)
>
> #771205
> reproduced with Evince, by printing a landscape pdf to a file. (Evince
> prints it prints it portrait, while Okular correctly prints it
> landscape)
> Patched version DOESN'T FIX the Evince issue. With the patched gtk,
> print dialog in Evince actually recognizes that the PDF is landscape
> and sets landscape printing settings automatically, but the resulting
> file is still portrait. It seems like the Evince issue is actually
> more complicated than just this gtk fix, so we might as well drop this
> patch since it doesn't fix the most glaring issue. (Relevant Evince
> bug is at #768133)
>
> #788002
> I tried to reproduce it using the example.c file in the
> bugzilla.redhat.com bug report, but that sample doesn't crash under
> either the original jessie gtk or the patched one.
>

Bug#794799: libwxgtk3.0-0: assertion failure with gnuplot5

[Vincent Lefevre]

On 2015-08-11 23:30:21 +0200, Vincent Lefevre wrote:
> On 2015-08-11 18:38:06 +0100, Olly Betts wrote:
> > On Tue, Aug 11, 2015 at 05:59:59PM +0200, Vincent Lefevre wrote:
> > > On 2015-08-11 16:22:04 +0100, Olly Betts wrote:
> > > > On Thu, Aug 06, 2015 at 08:54:19PM +0200, Vincent Lefevre wrote:
> > > > > gnuplot5 crashed due to an assertion failure in libwxgtk3.0-0.
> > > > > This is not reproducible.
> > > > 
> > > > You don't seem to have included the assertion message which was
> > > > displayed, which would be the most useful information to have.
> > > 
> > > IIRC, there wasn't more information.
> > 
> > There wasn't an assertion dialog on screen?
> 
> There was a dialog saying that there was an assertion failure in
> libwxgtk3.0-0, but I don't think there was more information. Or
> perhaps it disappeared before I could get the information.

I now remember that I had saved the file:

ASSERT INFO:
../src/gtk/dcclient.cpp(250): assert "Assert failure" failed in wxFreePoolGC(): 
Wrong GC

BACKTRACE:
[1] wxWindowDCImpl::Destroy()
[2] wxWindowDCImpl::~wxWindowDCImpl()
[3] wxMemoryDCImpl::~wxMemoryDCImpl()
[4] __libc_start_main

(I think I wanted to include it in my bug report but forgot.)

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

Bug#795898: ITP: pd-tclpd -- Tcl objects for Pd

[Debian/GNU]

On 08/17/2015 10:07 PM, Marco d'Itri wrote:
> On Aug 17, IOhannes m zmoelnig  wrote:
> 
>>  This library allows to to write externals for Pd using the Tcl language.
> In this and the other packages maybe it would be a good idea to expand 
> the "Pd" acronym at least once?
> 

good idea. thanks.

gfamdsr
IOhannes



signature.asc
Description: OpenPGP digital signature

Bug#791159: nmu diff for libqalculate 0.9.7-9.1

[Vincent Legout]

Hi,

Julien Cristau  writes:

> Dear maintainer,
>
> I've prepared a NMU for libqalculate, to deal with the libstdc++ transition,
> and will shortly upload it to the 1-day delayed queue.  Please find the
> debdiff below.

Thanks a lot for your work on this transition and on this bug, and sorry
for not fixing this earlier. Feel free to upload the NMU directly if it
helps.

Thanks,
Vincent

Bug#791045: transition: geos (spatialite->postgis->gdal->spatialite circular dependency)

[Sebastiaan Couwenberg]

On 17-08-15 21:50, Sebastiaan Couwenberg wrote:
> I've completed the rebuilds of first dependency level, we need to
> untangle the spatialite->postgis->gdal->spatialite circular dependency
> to make the build dependencies for all these packages installable with
> the new libgeos-c1v5 package.
> 
> gdal (1.10.1+dfsg-9 / 1.11.2+dfsg-1~exp4) cannot be built because the
> build dependencies cannot be installed. It at least needs spatialite to
> be rebuilt with the new geos to not pull in the old libgeos-c1.
> 
> [...]
> 
> postgis (2.1.8+dfsg-1) will also need gdal & spatialite to be rebuilt
> with the new geos packages before its build dependencies can be installed.
> 
> [...]
> 
> spatialite (4.3.0-1) needs postgis to be rebuilt with the new geos, so
> but postgis requires gdal & spatialite to be rebuilt first. To untangle
> this circular dependency we need to dropping the liblwgeom dependency to
> allow spatialite to rebuild with the new geos, after which we can
> rebuild gdal and postgis, reinstate the liblwgeom dependency in
> spatialite and rebuild spatialite & gdal again. Splitting liblwgeom into
> a separate source package may be an option with PostGIS 2.2.
> 
> I need to think this issue through some more. It's not specific to the
> GEOS 3.5.0 update, and affects 3.4.2 v5 libraries for the GCC 5
> transition too.

To deal with the spatialite->postgis->gdal->spatialite circular
dependency the process should probably be:

 * Upload geos to unstable to start the GCC 5 transition
 * Upload spatialite (4.3.0-2) to unstable, drops liblwgeom dependency
 * File RC bug on spatialite (4.3.0-2) about liblwgeom regression to
   prevent testing migration, and have the RC bug block the geos
   transition bug (#791045) too
 * BinNMU gdal with spatialite (4.3.0-2) in unstable
 * BinNMU postgis with rebuilt gdal & spatialite in unstable
 * Upload spatialite (4.3.0-3) to unstable, reinstates liblwgeom
   dependency
 * BinNMU gdal with spatialite (4.3.0-3) in unstable
 * BinNMU postgis with rebuilt gdal & spatialite in unstable

I'm CC'ing this message to the geos transition bugreport too, for
earlier messages in this thread on the debian-gis list see:

https://lists.debian.org/debian-gis/2015/08/msg00054.html

Kind Regards,

Bas

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

Bug#795156: mirror submission for mirror.nforce.com

[Donald Norwood]

Control: tag -1 +moreinfo


Hello,

Thank you for your support and for mirroring Debian.

The /pub/linux/debian/ directory is missing the index page/file.
Everything else looks good.

Could you please look into this?

Thank you

Donald Norwood



On Tue, 11 Aug 2015 07:40:59 + "NFOrce Entertainment B.V. - NOC"
 wrote:
> Package: mirrors
> Severity: wishlist
>
> Submission-Type: new
> Site: mirror.nforce.com
> Type: leaf
> Archive-architecture: ALL amd64 armel armhf hurd-i386 i386
kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc
> Archive-ftp: /pub/linux/debian/
> Archive-http: /pub/linux/debian/
> Archive-rsync: debian/
> IPv6: no
> Archive-upstream: mirror.1000mbps.com
> Updates: four
> Maintainer: NFOrce Entertainment B.V. - NOC 
> Country: NL Netherlands
> Location: Amsterdam
> Sponsor: NFOrce Entertainment B.V. http://www.nforce.com/
>
>




signature.asc
Description: OpenPGP digital signature

Bug#776191: closed by James McCoy (Bug#776191: fixed in vim 2:7.4.826-1)

[Francesco Poli]

Control: found -1 vim/2:7.4.826-1


On Mon, 17 Aug 2015 03:24:09 + Debian Bug Tracking System wrote:

[...]
>  + Update declared license for xxd.  (Closes: #776191)
[...]

Hello, I am glad to see that upstream updated the permission notice in
xxd.c, thanks for asking Bram to do so!

However, the licensing status of xxd has to be documented in the
debian/copyright file of the Debian package: this was the main point of
my bug report. I see no traces of xxd licensing status documented in
the current debian/copyright file [1].

I am therefore reopening the bug report.

Please document the licensing status of xxd in the debian/copyright
file! Thanks for your time and dedication.


[1] https://tracker.debian.org/media/packages/v/vim/copyright-2%3A7.4.826-1


-- 
 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


pgp1bal4V4O5q.pgp
Description: PGP signature

Bug#795909: emacs24: Hang with large yanks

[Mike Crowe]

Package: emacs24
Version: 24.4+1-5
Severity: normal
Tags: upstream patch

Dear Maintainer,

Emacs 24.4 and 24.5 suffer from a signal-handling bug which can cause X11 Emacs
to hang during a paste/yank operation. This was reported as an Emacs bug at
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16737 and eventually fixed on both
master(0592cefd03f1de2f04b721d07a16e6e0a9e48f73) and the emacs-24 branch
(a27ae9d7650a1230d4359eaf0a949f827315a6d2).

I've been running with emacs24 24.4+1-5 (from Jessie) with
a27ae9d7650a1230d4359eaf0a949f827315a6d2 (attached) applied for a month now and
the bug
seems to be well and truly fixed.

It seems unlikely that there will be another upstream emacs-24 release.

Is there any chance that you could apply this fix for Stretch and then
potentially as a stable update for Jessie?

Thanks.

Mike.



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

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

Versions of packages emacs24 depends on:
ii  emacs24-bin-common 24.4+1-5
ii  gconf-service  3.2.6-3
ii  libacl12.2.52-2
ii  libasound2 1.0.28-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-18
ii  libcairo-gobject2  1.14.0-2.1
ii  libcairo2  1.14.0-2.1
ii  libdbus-1-31.8.18-0+deb8u1
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.5.2-3
ii  libgconf-2-4   3.2.6-3
ii  libgdk-pixbuf2.0-0 2.31.1-2+b1
ii  libgif44.1.6-11
ii  libglib2.0-0   2.42.1-1
ii  libgnutls-deb0-28  3.3.8-6+deb8u2
ii  libgomp1   4.9.2-10
ii  libgpm21.20.4-6.1+b2
ii  libgtk-3-0 3.14.5-1
ii  libice62:1.0.9-1+b1
ii  libjpeg62-turbo1:1.3.1-12
ii  libm17n-0  1.6.4-3
ii  libmagickcore-6.q16-2  8:6.8.9.9-5
ii  libmagickwand-6.q16-2  8:6.8.9.9-5
ii  libotf00.9.13-2
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libpng12-0 1.2.50-2+b2
ii  librsvg2-2 2.40.5-1
ii  libselinux12.3-2
ii  libsm6 2:1.2.2-1+b1
ii  libtiff5   4.0.3-12.3
ii  libtinfo5  5.9+20140913-1+b1
ii  libx11-6   2:1.6.2-3
ii  libxft22.3.2-1
ii  libxinerama1   2:1.1.3-1+b1
ii  libxml22.9.1+dfsg1-5
ii  libxpm41:3.5.11-1+b1
ii  libxrandr2 2:1.4.2-1+b1
ii  libxrender11:0.9.8-1+b1
ii  zlib1g 1:1.2.8.dfsg-2+b1

emacs24 recommends no packages.

Versions of packages emacs24 suggests:
pn  emacs24-common-non-dfsg  
commit a27ae9d7650a1230d4359eaf0a949f827315a6d2
Author: Paul Eggert 
Date:   Fri Jul 17 11:54:24 2015 -0700

Fix hang with large yanks

Backport of master commit 0592cefd03f1de2f04b721d07a16e6e0a9e48f73.
This should fix the bug fixed by Mike Crowe's patch in:
https://lists.gnu.org/archive/html/emacs-devel/2015-07/msg00106.html
A problem in this area has been reported by several users; see
Bug#16737, Bug#17101, Bug#17026, Bug#17172, Bug#19320, Bug#20283.
This fix differs from Mike Crowe's patch in that it should avoid a
race condition that could lose SIGIO signals.  ignore_sigio dates
back to the 1980s when some platforms couldn't block signals, and
could only ignore them, which led to races when signals arrived
while being ignored.  We shouldn't have to worry about those old
platforms now.
* src/dispextern.h, src/sysdep.c (ignore_sigio): Remove.
* src/emacs.c (shut_down_emacs):
Don't call ignore_sigio; unrequest_sigio should suffice.
* src/keyboard.c (kbd_buffer_store_buffered_event):
Use unrequest_sigio, not ignore_sigio.
(kbd_buffer_get_event):
Call request_sigio when getting the ball rolling again.

diff --git a/src/dispextern.h b/src/dispextern.h
index 239c442..cf3d1ec 100644
--- a/src/dispextern.h
+++ b/src/dispextern.h
@@ -3349,7 +3349,6 @@ void unrequest_sigio (void);
 bool tabs_safe_p (int);
 void init_baud_rate (int);
 void init_sigio (int);
-void ignore_sigio (void);
 
 /* Defined in xfaces.c.  */
 
diff --git a/src/emacs.c b/src/emacs.c
index 9b78a70..b5d3ab4 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -2028,7 +2028,6 @@ shut_down_emacs (int sig, Lisp_Object stuff)
   /* There is a tendency for a SIGIO signal to arrive within exit,
  and cause a SIGHUP because the input descriptor is already closed.  */
   unrequest_sigio ();
-  ignore_sigio ();
 
   /* Do this only if terminating normally, we want glyph matrices
  etc. in a core dump.  */
diff --git a/src/keyboard.c b/src/keyboard.c
index 945019e..77af44a 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -3663,8 +3663,7

Bug#770479: [PATCH] nbd: Fix timeout detection

[Hermann Lauer]

Hello Ben,
attached is the email from the nbd Maintainer to Jens Axboe and the kernel list
which fixes the timeout issue.
Thanks for careing,
 greetings
  Hermann

-- 
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres 
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
Email: hermann.la...@iwr.uni-heidelberg.de
--- Begin Message ---
At the moment the nbd timeout just detects hanging tcp operations. This
is not enough to detect a hanging or bad connection as expected of a
timeout.

This patch redesigns the timeout detection to include some more cases.
The timeout is now in relation to replies from the server. If the server
does not send replies within the timeout the connection will be shut
down.

The patch adds a continous timer 'timeout_timer' that is setup in one of
two cases:
 - The request list is empty and we are sending the first request out to
   the server. We want to have a reply within the given timeout,
   otherwise we consider the connection to be dead.
 - A server response was received. This means the server is still
   communicating with us. The timer is reset to the timeout value.

The timer is not stopped if the list becomes empty. It will just trigger
a timeout which will directly leave the handling routine again as the
request list is empty.

The whole patch does not use any additional explicit locking. The
list_empty() calls are safe to be used concurrently. The timer is locked
internally as we just use mod_timer and del_timer_sync().

The patch is based on the idea of Michal Belczyk with a previous
different implementation.

Cc: Michal Belczyk 
Cc: Hermann Lauer 
Signed-off-by: Markus Pargmann 
Tested-by: Hermann Lauer 
---
 drivers/block/nbd.c | 98 ++---
 1 file changed, 70 insertions(+), 28 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 0e385d8e9b86..7b9ae7a65c1e 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -59,6 +59,10 @@ struct nbd_device {
pid_t pid; /* pid of nbd-client, if attached */
int xmit_timeout;
int disconnect; /* a disconnect has been requested by user */
+
+   struct timer_list timeout_timer;
+   struct task_struct *task_recv;
+   struct task_struct *task_send;
 };
 
 #define NBD_MAGIC 0x68797548
@@ -121,6 +125,7 @@ static void sock_shutdown(struct nbd_device *nbd, int lock)
dev_warn(disk_to_dev(nbd->disk), "shutting down socket\n");
kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
nbd->sock = NULL;
+   del_timer_sync(&nbd->timeout_timer);
}
if (lock)
mutex_unlock(&nbd->tx_lock);
@@ -128,11 +133,23 @@ static void sock_shutdown(struct nbd_device *nbd, int 
lock)
 
 static void nbd_xmit_timeout(unsigned long arg)
 {
-   struct task_struct *task = (struct task_struct *)arg;
+   struct nbd_device *nbd = (struct nbd_device *)arg;
+   struct task_struct *task;
+
+   if (list_empty(&nbd->queue_head))
+   return;
+
+   nbd->disconnect = 1;
+
+   task = READ_ONCE(nbd->task_recv);
+   if (task)
+   force_sig(SIGKILL, task);
 
-   printk(KERN_WARNING "nbd: killing hung xmit (%s, pid: %d)\n",
-   task->comm, task->pid);
-   force_sig(SIGKILL, task);
+   task = READ_ONCE(nbd->task_send);
+   if (task)
+   force_sig(SIGKILL, nbd->task_send);
+
+   dev_err(nbd_to_dev(nbd), "Connection timed out, killed receiver and 
sender, shutting down connection\n");
 }
 
 /*
@@ -171,33 +188,12 @@ static int sock_xmit(struct nbd_device *nbd, int send, 
void *buf, int size,
msg.msg_controllen = 0;
msg.msg_flags = msg_flags | MSG_NOSIGNAL;
 
-   if (send) {
-   struct timer_list ti;
-
-   if (nbd->xmit_timeout) {
-   init_timer(&ti);
-   ti.function = nbd_xmit_timeout;
-   ti.data = (unsigned long)current;
-   ti.expires = jiffies + nbd->xmit_timeout;
-   add_timer(&ti);
-   }
+   if (send)
result = kernel_sendmsg(sock, &msg, &iov, 1, size);
-   if (nbd->xmit_timeout)
-   del_timer_sync(&ti);
-   } else
+   else
result = kernel_recvmsg(sock, &msg, &iov, 1, size,
msg.msg_flags);
 
-   if (signal_pending(current)) {
-   siginfo_t info;
-   printk(KERN_WARNING "nbd (pid %d: %s) got signal %d\n",
-   task_pid_nr(current), current->comm,
-   dequeue_signal_lock(current, ¤t->blocked, 
&info)

Bug#773057: I see same problem on Jessie.

[Thomas Vaughan]

Does anyone know what the problem is and/or have a work-around?



-- 
Thomas E. Vaughan

Bug#795898: ITP: pd-tclpd -- Tcl objects for Pd

[Marco d'Itri]

On Aug 17, IOhannes m zmoelnig  wrote:

>  This library allows to to write externals for Pd using the Tcl language.
In this and the other packages maybe it would be a good idea to expand 
the "Pd" acronym at least once?

-- 
ciao,
Marco


pgpD6YznLszGm.pgp
Description: PGP signature

Bug#772426: closed by Donald Norwood (Re: mirror submission for debian.mirror.marist.edu)

[Donald Norwood]

Hi Jeff,

Thank you for the quick response.

The original submission was stated to offer only amd64, however the
mirror itself is offering amd64 and i386. Is this intentional?

Second the update schedule states once per day, however it is preferred
to update 4 times a day if possible so that your mirror is in sync with
the rest of the archive.

Otherwise everything looks good.

Best regards,

Donald Norwood



signature.asc
Description: OpenPGP digital signature

Bug#793331: RFS: postsrsd/1.2-1 [ITP]

[Oxan van Leeuwen]

Hi,

On 15-08-15 12:21, Tomasz Buchert wrote:

I've tested the AppArmor profile too, it looks fine, although I'm not
sure if 'm' is needed in the profile for '/usr/sbin/postsrsd', since
it seems to work just fine without it.  I've a rather basic knowledge
about AppArmor, so if you could explain it to me, I'd be grateful.
I'm not sure about it either, I just copied the AppArmor profile from 
upstream. Judging from the AppArmor docs it's indeed not needed, I'll do 
some further research tomorrow and remove it if possible.



And the last thing: in the systemd unit, you do:

-d$${SRS_DOMAIN:-$$(postconf -h mydomain 2>/dev/null)}

Well, first if SRS_DOMAIN is set to something that it's fine, if it's not,
then postconf is used to get the mail server domain. But postconf may not
be present! You probably need to depend on postfix, unless postsrsd can be used
with other mail software.
Technically postsrsd can be used with other mail servers too, though I 
doubt it will happen in practice. Is it really a problem if postconf is 
called when it's not present, though? Its output is silenced, and 
postsrsd fails when the -d argument is empty anyway.



I'd also recommend using EnvironmentFile in your systemd unit [1].
The systemd unit is already loading /etc/default/postsrsd as 
EnvironmentFile, it's just the defaults that are in the systemd unit. 
Not sure why I did that though (I believe we usually don't support 
removing files from /etc/default), so they can be safely removed. I'll 
push a fix.



I also pushed some minor fixes.

Are you sure? I don't see any new commits in the collab-maint repository.


When this is done, I'll be happy to push your package,
I already use it myself for some time :).

That's great!

Cheers,
Oxan

Bug#795908: Missing hashes for firmware-8.1.0-amd64-i386-netinst.iso

[Hendrik Weimer]

Package: cdimage.debian.org
Tags: security

Dear Maintainers,

the directory
http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/8.1.0/multi-arch/iso-cd/
contains a multiarch installation image including non-free firmware
(firmware-8.1.0-amd64-i386-netinst.iso), but no accompanying
hashes. This makes it impossible to verify the image.

Hendrik

Bug#795906: ITP: pd-testtools -- unit test framework for Pd

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-testtools
  Version : 0.1
  Upstream Author : Katja Vetter and Fred Jan Kraan 
* URL : http://get.puredata.info/testtools
* License : BSD-3
  Programming Lang: Pd
  Description : unit test framework for Pd

 testtools is a collection objects that help the developer with creating unit
 tests for Pure Data patches, both in the message domain and in the signal
 domain.


I intend to maintain this package under the pkg-multimedia umbrella.

Bug#795907: Installation was successfully at Acer Aspire One D150

[Bernhard]

Package: installation-reports

Boot method: CD

Image version: Self-made installation CD with stretch installer Alpha 2

Date: 17. August 2015

Machine: Acer Aspire One D150

Processor: Intel Atom N270 @ 1,6GHz

Memory: 1GB

Partitions:

Output of lspci -knn:

lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GSE Express 
Memory Controller Hub [8086:27ac] (rev 03)

lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:019c]

lspci -knn: Kernel driver in use: agpgart-intel

lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 
945GSE Express Integrated Graphics Controller [8086:27ae] (rev 03)

lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:019c]

lspci -knn: 00:02.1 Display controller [0380]: Intel Corporation Mobile 
945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] 
(rev 03)

lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:019c]

lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family 
High Definition Audio Controller [8086:27d8] (rev 02)

lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:019c]

lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI 
Express Port 1 [8086:27d0] (rev 02)

lspci -knn: Kernel driver in use: pcieport

lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI 
Express Port 2 [8086:27d2] (rev 02)

lspci -knn: Kernel driver in use: pcieport

lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI 
Express Port 3 [8086:27d4] (rev 02)

lspci -knn: Kernel driver in use: pcieport

lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #1 [8086:27c8] (rev 02)

lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:019c]

lspci -knn: Kernel driver in use: uhci_hcd

lspci -knn: 00:1d.1 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #2 [8086:27c9] (rev 02)

lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:019c]

lspci -knn: Kernel driver in use: uhci_hcd

lspci -knn: 00:1d.2 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #3 [8086:27ca] (rev 02)

lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:019c]

lspci -knn: Kernel driver in use: uhci_hcd

lspci -knn: 00:1d.3 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #4 [8086:27cb] (rev 02)

lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:019c]

lspci -knn: Kernel driver in use: uhci_hcd

lspci -knn: 00:1d.7 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB2 EHCI Controller [8086:27cc] (rev 02)

lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:019c]

lspci -knn: Kernel driver in use: ehci-pci

lspci -knn: 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI 
Bridge [8086:2448] (rev e2)

lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC 
Interface Bridge [8086:27b9] (rev 02)

lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:019c]

lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 82801GBM/GHM 
(ICH7-M Family) SATA Controller [AHCI mode] [8086:27c5] (rev 02)

lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:019c]

lspci -knn: Kernel driver in use: ahci

lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation NM10/ICH7 Family SMBus 
Controller [8086:27da] (rev 02)

lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:019c]

lspci -knn: 01:00.0 Network controller [0280]: Broadcom Corporation BCM4312 
802.11b/g LP-PHY [14e4:4315] (rev 01)

lspci -knn: Subsystem: Foxconn International, Inc. Device [105b:e018]

lspci -knn: Kernel driver in use: b43-pci-bridge

lspci -knn: 03:00.0 Ethernet controller [0200]: Qualcomm Atheros 
AR8121/AR8113/AR8114 Gigabit or Fast Ethernet [1969:1026] (rev b0)

lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:019c]

lspci -knn: Kernel driver in use: ATL1E

Base System Installation Checklist:

[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]

Detect network card:[O]

Configure network:  [O]

Detect CD:  [O]

Load installer modules: [O]

Detect hard drives: [O]

Partition hard drives:  [O]

Install base system:[O]

Clock/timezone setup:   [O]

User/password setup:[O]

Install tasks:  [O]

Install boot loader:[O]

Overall install:[O]

Comments/Problems:

Installation finished without any problems :-)

Bug#795259: Fixed python-shapely (1.4.3-1.1) uploaded to DELAYED/2

[Sebastiaan Couwenberg]

On 17-08-15 20:39, Bas Couwenberg wrote:
> Johan, has just pushed the missing upstream commits to the collab-maint
> repository, so I'll upload python-shapely (1.5.9-1) to unstable shortly.

I've uploaded the changes for python-shapely (1.5.9-1) to unstable, all
changes are available in the collab-maint git repo:

http://anonscm.debian.org/cgit/collab-maint/python-shapely.git/log/?h=debian/1.5.9-1

Kind Regards,

Bas

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

Bug#795904: ITP: pd-log -- small library for logging

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-log
  Version : 0.1
  Upstream Author : Hans-Christoph Steiner 
* URL : http://get.puredata.info/log
* License : BSD-3
  Programming Lang: C, Pd
  Description : small library for logging

 This library adds objects to Pd that allow to create
 printout at various verbosity levels.
 .
 The objects can be used as drop-in replacement for the standard
 [print] object, but the printed messages can be filtered and
 have a colourful appearance.

I intend to maintain this package under the pkg-multimedia umbrella.

Bug#795905: Installation was successfully on Acer Aspire One 532h

[Bernhard]

Package: installation-reports

Boot method: CD
Image version: Self-made installation CD with stretch installer Alpha 2
Date: 16. August 2015

Machine: Acer Aspire One 532h
Processor: Intel Atom N450 @ 1,6GHz
Memory: 1GB
Partitions:

Output of lspci -knn:

> lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Atom
> Processor D4xx/D5xx/N4xx/N5xx DMI Bridge [8086:a010] lspci -knn:
> Subsystem: Acer Incorporated [ALI] Device [1025:0349] lspci -knn:
> Kernel driver in use: agpgart-intel lspci -knn: 00:02.0 VGA compatible
> controller [0300]: Intel Corporation Atom Processor
> D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller [8086:a011] lspci
> -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349] lspci
> -knn: 00:02.1 Display controller [0380]: Intel Corporation Atom
> Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller
> [8086:a012] lspci -knn: Subsystem: Acer Incorporated [ALI] Device
> [1025:0349] lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation
> NM10/ICH7 Family High Definition Audio Controller [8086:27d8] (rev 02)
> lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
> lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7
> Family PCI Express Port 1 [8086:27d0] (rev 02) lspci -knn: Kernel
> driver in use: pcieport lspci -knn: 00:1c.1 PCI bridge [0604]: Intel
> Corporation NM10/ICH7 Family PCI Express Port 2 [8086:27d2] (rev 02)
> lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1d.0 USB
> controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI
> Controller #1 [8086:27c8] (rev 02) lspci -knn: Subsystem: Acer
> Incorporated [ALI] Device [1025:0349] lspci -knn: Kernel driver in
> use: uhci_hcd lspci -knn: 00:1d.1 USB controller [0c03]: Intel
> Corporation NM10/ICH7 Family USB UHCI Controller #2 [8086:27c9] (rev
> 02) lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
> lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.2 USB
> controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI
> Controller #3 [8086:27ca] (rev 02) lspci -knn: Subsystem: Acer
> Incorporated [ALI] Device [1025:0349] lspci -knn: Kernel driver in
> use: uhci_hcd lspci -knn: 00:1d.3 USB controller [0c03]: Intel
> Corporation NM10/ICH7 Family USB UHCI Controller #4 [8086:27cb] (rev
> 02) lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
> lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.7 USB
> controller [0c03]: Intel Corporation NM10/ICH7 Family USB2 EHCI
> Controller [8086:27cc] (rev 02) lspci -knn: Subsystem: Acer
> Incorporated [ALI] Device [1025:0349] lspci -knn: Kernel driver in
> use: ehci-pci lspci -knn: 00:1e.0 PCI bridge [0604]: Intel Corporation
> 82801 Mobile PCI Bridge [8086:2448] (rev e2) lspci -knn: 00:1f.0 ISA
> bridge [0601]: Intel Corporation NM10 Family LPC Controller
> [8086:27bc] (rev 02) lspci -knn: Subsystem: Acer Incorporated [ALI]
> Device [1025:0349] lspci -knn: 00:1f.2 SATA controller [0106]: Intel
> Corporation NM10/ICH7 Family SATA Controller [AHCI mode] [8086:27c1]
> (rev 02) lspci -knn: Subsystem: Acer Incorporated [ALI] Device
> [1025:0349] lspci -knn: Kernel driver in use: ahci lspci -knn: 00:1f.3
> SMBus [0c05]: Intel Corporation NM10/ICH7 Family SMBus Controller
> [8086:27da] (rev 02) lspci -knn: Subsystem: Acer Incorporated [ALI]
> Device [1025:0349] lspci -knn: 01:00.0 Ethernet controller [0200]:
> Qualcomm Atheros AR8132 Fast Ethernet [1969:1062] (rev c0) lspci -knn:
> Subsystem: Acer Incorporated [ALI] Device [1025:0349] lspci -knn:
> Kernel driver in use: atl1c lspci -knn: 02:00.0 Network controller
> [0280]: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express)
> [168c:002b] (rev 01) lspci -knn: Subsystem: Foxconn International,
> Inc. Device [105b:e016] lspci -knn: Kernel driver in use: ath9k 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Installation finished without any problems :-)

Bug#795903: ITP: pd-rtc -- Real Time Composition Library for Pure Data

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-rtc
  Version : 4.1
  Upstream Author : Frank Barknecht 
* URL : http://get.puredata.info/rtc-lib
* License : BSD-3-clause
  Programming Lang: Pd
  Description : Real Time Composition Library for Pd

 This software library offers the possibility to experiment with a number of
 compositional techniques, such as serial procedures, permutations and 
controlled
 randomness.
 .
 Most of these objects are geared towards straightforward processing of data. By
 using these specialized objects together in a patch, programming becomes much
 more clear and easy.
 .
 Many functions that are often useful in algorithmic composition are provided
 with this library - therefore the composer could concentrate rather on the
 composition than the programming aspects.

I intend to maintain this package under the pkg-multimedia umbrella.

Bug#791316: nmu diff for yaml-cpp0.3 0.3.0-1.2

[Julien Cristau]

Dear maintainer,

I've prepared a NMU for yaml-cpp0.3, to deal with the libstdc++ transition,
and will shortly upload it to the 1-day delayed queue.  Please find the
debdiff below.

Cheers,
Julien

>From 0b9061d6789954eef95cbaa33d276e43161bdbee Mon Sep 17 00:00:00 2001
From: Julien Cristau 
Date: Sun, 16 Aug 2015 17:56:56 +0200
Subject: [PATCH] Rename library packages for g++5 ABI transition (closes:
 791316).

---
 debian/changelog| 7 +++
 debian/control  | 6 --
 debian/libyaml-cpp0.3.install   | 1 -
 debian/libyaml-cpp0.3v5.install | 1 +
 4 files changed, 12 insertions(+), 3 deletions(-)
 delete mode 100644 debian/libyaml-cpp0.3.install
 create mode 100644 debian/libyaml-cpp0.3v5.install

diff --git a/debian/changelog b/debian/changelog
index fd64782..7b831a9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+yaml-cpp0.3 (0.3.0-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename library packages for g++5 ABI transition (closes: 791316).
+
+ -- Julien Cristau   Sun, 16 Aug 2015 17:56:56 +0200
+
 yaml-cpp0.3 (0.3.0-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/control b/debian/control
index a6009fd..cb9ba0b 100644
--- a/debian/control
+++ b/debian/control
@@ -7,12 +7,14 @@ Standards-Version: 3.9.3
 Homepage: http://code.google.com/p/yaml-cpp/
 Vcs-Svn: http://yaml-cpp.googlecode.com/svn
 
-Package: libyaml-cpp0.3
+Package: libyaml-cpp0.3v5
 Section: libs
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: libyaml-cpp0.3
+Replaces: libyaml-cpp0.3
 Description: YAML parser and emitter for C++ (0.3 series)
  yaml-cpp is a C++ library for parsing and emitting data in YAML 1.2, a
  human-readable data serialization format.
@@ -22,7 +24,7 @@ Description: YAML parser and emitter for C++ (0.3 series)
 Package: libyaml-cpp0.3-dev
 Section: libdevel
 Architecture: any
-Depends: libyaml-cpp0.3 (= ${binary:Version}), ${misc:Depends}
+Depends: libyaml-cpp0.3v5 (= ${binary:Version}), ${misc:Depends}
 Conflicts: libyaml-cpp-dev
 Description: YAML parser and emitter for C++ - development files (0.3 series)
  yaml-cpp is a C++ library for parsing and emitting data in YAML 1.2, a
diff --git a/debian/libyaml-cpp0.3.install b/debian/libyaml-cpp0.3.install
deleted file mode 100644
index 7a0ab28..000
--- a/debian/libyaml-cpp0.3.install
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib/*/libyaml-cpp.so.*
diff --git a/debian/libyaml-cpp0.3v5.install b/debian/libyaml-cpp0.3v5.install
new file mode 100644
index 000..7a0ab28
--- /dev/null
+++ b/debian/libyaml-cpp0.3v5.install
@@ -0,0 +1 @@
+usr/lib/*/libyaml-cpp.so.*
-- 
2.5.0

Bug#791174: nmu diff for libsynthesis 3.4.0.47.4-2.1

[Julien Cristau]

Dear maintainer,

I've prepared a NMU for libsynthesis, to deal with the libstdc++ transition,
and will shortly upload it to the 1-day delayed queue.  Please find the
debdiff below.

Cheers,
Julien

>From e80c353c89313ded009f4f2e278fa50b77fb2f0a Mon Sep 17 00:00:00 2001
From: Julien Cristau 
Date: Sun, 16 Aug 2015 17:44:33 +0200
Subject: [PATCH] Rename library packages for g++5 ABI transition (closes:
 791174).

---
 debian/changelog   | 7 +++
 debian/control | 8 +---
 debian/libsynthesis0.install   | 2 --
 debian/libsynthesis0v5.install | 2 ++
 4 files changed, 14 insertions(+), 5 deletions(-)
 delete mode 100644 debian/libsynthesis0.install
 create mode 100644 debian/libsynthesis0v5.install

diff --git a/debian/changelog b/debian/changelog
index 828e139..edb6dde 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libsynthesis (3.4.0.47.4-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename library packages for g++5 ABI transition (closes: 791174).
+
+ -- Julien Cristau   Sun, 16 Aug 2015 17:44:33 +0200
+
 libsynthesis (3.4.0.47.4-2) unstable; urgency=medium
 
   * Make dh_makeshlibs generate a versioned shlibs file (Closes: #768990)
diff --git a/debian/control b/debian/control
index e0db576..73b14cf 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Vcs-Browser: 
http://git.debian.org/?p=collab-maint/libsynthesis.git
 Package: libsynthesis-dev
 Section: libdevel
 Architecture: any
-Depends: libsynthesis0 (= ${binary:Version}), libsmltk0 (= ${binary:Version}), 
${misc:Depends}
+Depends: libsynthesis0v5 (= ${binary:Version}), libsmltk0 (= 
${binary:Version}), ${misc:Depends}
 Description: library for SyncML-DS (SyncML Data Sync) clients (development 
files)
  The Synthesis SyncML engine supports SyncML versions 1.0, 1.1 and 1.2
  including complex features like data filtering, suspend & resume,
@@ -22,11 +22,13 @@ Description: library for SyncML-DS (SyncML Data Sync) 
clients (development files
  .
  These are the development files, only needed if you are compiling 
applications.
 
-Package: libsynthesis0
+Package: libsynthesis0v5
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Multi-Arch: same
+Conflicts: libsynthesis0
+Replaces: libsynthesis0
 Description: library for SyncML-DS (SyncML Data Sync) clients (shared 
libraries)
  The Synthesis SyncML engine supports SyncML versions 1.0, 1.1 and 1.2
  including complex features like data filtering, suspend & resume,
@@ -52,7 +54,7 @@ Package: libsynthesis-dbg
 Section: debug
 Architecture: any
 Priority: extra
-Depends: libsynthesis0 (= ${binary:Version}), libsmltk0 (= ${binary:Version}), 
${misc:Depends}
+Depends: libsynthesis0v5 (= ${binary:Version}), libsmltk0 (= 
${binary:Version}), ${misc:Depends}
 Description: library for SyncML-DS (SyncML Data Sync) clients (debugging 
symbols)
  The Synthesis SyncML engine supports SyncML versions 1.0, 1.1 and 1.2
  including complex features like data filtering, suspend & resume,
diff --git a/debian/libsynthesis0.install b/debian/libsynthesis0.install
deleted file mode 100644
index 499b36d..000
--- a/debian/libsynthesis0.install
+++ /dev/null
@@ -1,2 +0,0 @@
-usr/lib/*/libsynthesis.so.0.6.0
-usr/lib/*/libsynthesis.so.0
diff --git a/debian/libsynthesis0v5.install b/debian/libsynthesis0v5.install
new file mode 100644
index 000..499b36d
--- /dev/null
+++ b/debian/libsynthesis0v5.install
@@ -0,0 +1,2 @@
+usr/lib/*/libsynthesis.so.0.6.0
+usr/lib/*/libsynthesis.so.0
-- 
2.5.0

Bug#795902: ITP: pd-mrpeach -- low-level communication objects for Pure Data

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-mrpeach
  Version : 
  Upstream Author : Martin Peach 
* URL : http://get.puredata.info/mrpeach
* License : GPL2+
  Programming Lang: C, Pd
  Description : low-level communication objects for Pure Data

This library includes a number of independent submodules, most of them
dealing with low-level communication (e.g. on the byte-level):
- net
- binfile
- slip
- CMOS
- midifile

The various submodules will be made available as separate binary packages.
I intend to maintain the package under the pkg-multimedia umbrella.

Bug#795901: ITP: pd-iem -- collection of general purpose objects for Pure Data

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-iem
  Version : 1.20
  Upstream Author : Institute of Electronic Music and Acoustics (iem)
* URL : http://iem.at/
* License : GPL
  Programming Lang: C, Pd
  Description : collection of general purpose objects for Pure Data

 pd-iem consists of a number of independent submodules
 - iem_adaptfilt (adaptive filters)
 - iem_delay (optimized delay lines)
 - iem_roomsim (room simluation)
 - iem_spec2 (optimized frequency domain processing)


The submodules will be made available as separate binary packages.
I intend to maintain the package under the pkg-multimedia umbrella.

Bug#791299: nmu diff for tercpp 0.6.2+svn46-1.1

[Julien Cristau]

Dear maintainer,

I've prepared a NMU for tercpp, to deal with the libstdc++ transition,
and will shortly upload it to the 1-day delayed queue.  Please find the
debdiff below.

Cheers,
Julien

>From 2fc9221af6fab290043b20edf589491785b874d9 Mon Sep 17 00:00:00 2001
From: Julien Cristau 
Date: Sun, 16 Aug 2015 17:55:26 +0200
Subject: [PATCH] Rename library packages for g++5 ABI transition (closes:
 791299).

---
 debian/changelog| 7 +++
 debian/control  | 8 +---
 debian/libtercpp0.install   | 1 -
 debian/libtercpp0v5.install | 1 +
 4 files changed, 13 insertions(+), 4 deletions(-)
 delete mode 100644 debian/libtercpp0.install
 create mode 100644 debian/libtercpp0v5.install

diff --git a/debian/changelog b/debian/changelog
index 88d8a20..efa752a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+tercpp (0.6.2+svn46-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename library packages for g++5 ABI transition (closes: 791299).
+
+ -- Julien Cristau   Sun, 16 Aug 2015 17:55:26 +0200
+
 tercpp (0.6.2+svn46-1) unstable; urgency=low
 
   * New upstream revision
diff --git a/debian/control b/debian/control
index e68beb7..b647c17 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Package: libtercpp-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: ${misc:Depends}, libtercpp0 (= ${binary:Version}), libtinyxml-dev
+Depends: ${misc:Depends}, libtercpp0v5 (= ${binary:Version}), libtinyxml-dev
 Description: Translation Error Rate scoring tool - development files
  TERCpp is a tool (implemented in C++) for scoring machine translation
  performance. It uses the Translation Error Rate (TER) metric to measure
@@ -18,12 +18,14 @@ Description: Translation Error Rate scoring tool - 
development files
  .
  This package contains development files for TERCpp.
 
-Package: libtercpp0
+Package: libtercpp0v5
 Section: libs
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: libtercpp0
+Replaces: libtercpp0
 Description: Translation Error Rate scoring tool - shared library
  TERCpp is a tool (implemented in C++) for scoring machine translation
  performance. It uses the Translation Error Rate (TER) metric to measure
@@ -33,7 +35,7 @@ Description: Translation Error Rate scoring tool - shared 
library
 
 Package: tercpp
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, libtercpp0 (= ${binary:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, libtercpp0v5 (= ${binary:Version})
 Description: Translation Error Rate scoring tool - binary
  TERCpp is a tool (implemented in C++) for scoring machine translation
  performance. It uses the Translation Error Rate (TER) metric to measure
diff --git a/debian/libtercpp0.install b/debian/libtercpp0.install
deleted file mode 100644
index 3ddde58..000
--- a/debian/libtercpp0.install
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib/*/lib*.so.*
diff --git a/debian/libtercpp0v5.install b/debian/libtercpp0v5.install
new file mode 100644
index 000..3ddde58
--- /dev/null
+++ b/debian/libtercpp0v5.install
@@ -0,0 +1 @@
+usr/lib/*/lib*.so.*
-- 
2.5.0

Bug#791187: nmu diff for libzeep 3.0.2-3.1

[Julien Cristau]

Dear maintainer,

I've prepared a NMU for libzeep, to deal with the libstdc++ transition,
and will shortly upload it to the 1-day delayed queue.  Please find the
debdiff below.

Cheers,
Julien

>From e8d683cbe28c35d2bbbd808c069c33a626270c4d Mon Sep 17 00:00:00 2001
From: Julien Cristau 
Date: Sun, 16 Aug 2015 17:45:25 +0200
Subject: [PATCH] Rename library packages for g++5 ABI transition (closes:
 791187).

---
 debian/changelog| 7 +++
 debian/control  | 8 
 debian/libzeep3.0v5.lintian-overrides   | 2 --
 debian/libzeep3.0v5v5.lintian-overrides | 2 ++
 debian/rules| 2 +-
 5 files changed, 14 insertions(+), 7 deletions(-)
 delete mode 100644 debian/libzeep3.0v5.lintian-overrides
 create mode 100644 debian/libzeep3.0v5v5.lintian-overrides

diff --git a/debian/changelog b/debian/changelog
index b35b5b8..990511d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libzeep (3.0.2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename library packages for g++5 ABI transition (closes: 791187).
+
+ -- Julien Cristau   Sun, 16 Aug 2015 17:45:25 +0200
+
 libzeep (3.0.2-3) unstable; urgency=medium
 
   * Rename library packages for g++5 ABI transition.
diff --git a/debian/control b/debian/control
index fe5db44..b065edf 100644
--- a/debian/control
+++ b/debian/control
@@ -20,7 +20,7 @@ Package: libzeep-dev
 Architecture: any
 Section: libdevel
 Depends: ${misc:Depends},
- libzeep3.0v5 (= ${binary:Version}),
+ libzeep3.0v5v5 (= ${binary:Version}),
  libboost-dev (>= 1.49.0),
  libboost-filesystem-dev (>= 1.49.0),
  libboost-system-dev (>= 1.49.0),
@@ -43,12 +43,12 @@ Description: Development files for libzeep
  This specific package contains all files needed to develop new
  software using libzeep.
 
-Package: libzeep3.0v5
+Package: libzeep3.0v5v5
 Architecture: any
 Depends: ${misc:Depends},
  ${shlibs:Depends}
-Conflicts: libzeep3.0
-Replaces: libzeep3.0
+Conflicts: libzeep3.0v5, libzeep3.0
+Replaces: libzeep3.0v5, libzeep3.0
 Description: Library files for libzeep
  Libzeep is a C++ library providing a validating XML parser, XML DOM tree
  implementation, XPath 1.0 support and code to create SOAP/REST servers as
diff --git a/debian/libzeep3.0v5.lintian-overrides 
b/debian/libzeep3.0v5.lintian-overrides
deleted file mode 100644
index cf6a284..000
--- a/debian/libzeep3.0v5.lintian-overrides
+++ /dev/null
@@ -1,2 +0,0 @@
-# G++5 ABI transition
-libzeep3.0v5: package-name-doesnt-match-sonames libzeep3.0
diff --git a/debian/libzeep3.0v5v5.lintian-overrides 
b/debian/libzeep3.0v5v5.lintian-overrides
new file mode 100644
index 000..c1dfa26
--- /dev/null
+++ b/debian/libzeep3.0v5v5.lintian-overrides
@@ -0,0 +1,2 @@
+# G++5 ABI transition
+libzeep3.0v5v5: package-name-doesnt-match-sonames libzeep3.0
diff --git a/debian/rules b/debian/rules
index f6f0b5a..8dab124 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,7 +11,7 @@ override_dh_auto_build:
 
 .PHONY: override_dh_auto_install
 override_dh_auto_install:
-   $(MAKE) DESTDIR=$(CURDIR)/debian/libzeep3.0v5 install-libs
+   $(MAKE) DESTDIR=$(CURDIR)/debian/libzeep3.0v5v5 install-libs
$(MAKE) DESTDIR=$(CURDIR)/debian/libzeep-dev install-dev
 
 .PHONY: get-orig-source
-- 
2.5.0

Bug#791145: nmu diff for libodfgen 0.1.4-1.1

[Julien Cristau]

Dear maintainer,

I've prepared a NMU for libodfgen, to deal with the libstdc++ transition,
and will shortly upload it to the 1-day delayed queue.  Please find the
debdiff below.

Cheers,
Julien

>From de4938bf38dba17e7b4d49a29d747ff3267ab9ab Mon Sep 17 00:00:00 2001
From: Julien Cristau 
Date: Sun, 16 Aug 2015 17:42:05 +0200
Subject: [PATCH] Rename library packages for g++5 ABI transition (closes:
 791145).

---
 debian/changelog | 7 +++
 debian/control   | 6 --
 debian/libodfgen-0.1-1.install   | 1 -
 debian/libodfgen-0.1-1v5.install | 1 +
 4 files changed, 12 insertions(+), 3 deletions(-)
 delete mode 100644 debian/libodfgen-0.1-1.install
 create mode 100644 debian/libodfgen-0.1-1v5.install

diff --git a/debian/changelog b/debian/changelog
index d1920d5..d72c48a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libodfgen (0.1.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename library packages for g++5 ABI transition (closes: 791145).
+
+ -- Julien Cristau   Sun, 16 Aug 2015 17:42:05 +0200
+
 libodfgen (0.1.4-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/control b/debian/control
index 6d6b1a5..6d86582 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Package: libodfgen-dev
 Section: libdevel
 Architecture: any
 Depends: librevenge-dev,
- libodfgen-0.1-1 (= ${binary:Version}),
+ libodfgen-0.1-1v5 (= ${binary:Version}),
  ${misc:Depends}
 Description: library to generate ODF documents -- development
  Libodfgen is library providing ability to generate ODF documents from
@@ -22,9 +22,11 @@ Description: library to generate ODF documents -- development
  .
  This package contains the development files (headers, ...)
 
-Package: libodfgen-0.1-1
+Package: libodfgen-0.1-1v5
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
+Conflicts: libodfgen-0.1-1
+Replaces: libodfgen-0.1-1
 Description: library to generate ODF documents
  Libodfgen is library providing ability to generate ODF documents from
  libwpd and libwps API calls.
diff --git a/debian/libodfgen-0.1-1.install b/debian/libodfgen-0.1-1.install
deleted file mode 100644
index d0dbfd1..000
--- a/debian/libodfgen-0.1-1.install
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib/lib*.so.*
diff --git a/debian/libodfgen-0.1-1v5.install b/debian/libodfgen-0.1-1v5.install
new file mode 100644
index 000..d0dbfd1
--- /dev/null
+++ b/debian/libodfgen-0.1-1v5.install
@@ -0,0 +1 @@
+usr/lib/lib*.so.*
-- 
2.5.0

Bug#791123: nmu diff for libghemical 3.0.0-4.1

[Julien Cristau]

Dear maintainer,

I've prepared a NMU for libghemical, to deal with the libstdc++ transition,
and will shortly upload it to the 1-day delayed queue.  Please find the
debdiff below.

Cheers,
Julien

>From 6fc126e9e6ffcb5eba74f08b52cf5cb43c4c8e98 Mon Sep 17 00:00:00 2001
From: Julien Cristau 
Date: Sun, 16 Aug 2015 17:40:35 +0200
Subject: [PATCH] Rename library packages for g++5 ABI transition (closes:
 791123).

---
 debian/changelog  | 7 +++
 debian/control| 6 --
 debian/libghemical5.install   | 1 -
 debian/libghemical5v5.install | 1 +
 4 files changed, 12 insertions(+), 3 deletions(-)
 delete mode 100644 debian/libghemical5.install
 create mode 100644 debian/libghemical5v5.install

diff --git a/debian/changelog b/debian/changelog
index a55cdf2..9264f1b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libghemical (3.0.0-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename library packages for g++5 ABI transition (closes: 791123).
+
+ -- Julien Cristau   Sun, 16 Aug 2015 17:40:35 +0200
+
 libghemical (3.0.0-4) unstable; urgency=high
 
   * debian/patches/fix-underlinking.patch: Use -lmpi++ instead of -lmpi_cxx.
diff --git a/debian/control b/debian/control
index 14d6255..54a3910 100644
--- a/debian/control
+++ b/debian/control
@@ -16,17 +16,19 @@ DM-Upload-Allowed: yes
 Package: libghemical-dev
 Section: libdevel
 Architecture: any
-Depends: libghemical5 (= ${binary:Version}), libmopac7-dev, ${misc:Depends}
+Depends: libghemical5v5 (= ${binary:Version}), libmopac7-dev, ${misc:Depends}
 Description: Molecular Modelling Library (development files)
  Libghemical is the basis of Ghemical, a GNOME Molecular Modelling
  Application.
  .
  This package includes the static library and the header files.
 
-Package: libghemical5
+Package: libghemical5v5
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, libghemical-data (= 
${source:Version})
+Conflicts: libghemical5
+Replaces: libghemical5
 Description: Molecular Modelling Library
  Libghemical is the basis of Ghemical, a GNOME Molecular Modelling
  Application.
diff --git a/debian/libghemical5.install b/debian/libghemical5.install
deleted file mode 100644
index d0dbfd1..000
--- a/debian/libghemical5.install
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib/lib*.so.*
diff --git a/debian/libghemical5v5.install b/debian/libghemical5v5.install
new file mode 100644
index 000..d0dbfd1
--- /dev/null
+++ b/debian/libghemical5v5.install
@@ -0,0 +1 @@
+usr/lib/lib*.so.*
-- 
2.5.0

Bug#791330: nmu diff for usbprog 0.2.0-2.2

[Julien Cristau]

Dear maintainer,

I've prepared a NMU for usbprog, to deal with the libstdc++ transition,
and will shortly upload it to the 1-day delayed queue.  Please find the
debdiff below.

Cheers,
Julien

>From 80b52dea7d04ff92bfcb799c9ecfa7df6df23c15 Mon Sep 17 00:00:00 2001
From: Julien Cristau 
Date: Sun, 16 Aug 2015 17:56:14 +0200
Subject: [PATCH] Rename library packages for g++5 ABI transition (closes:
 791330).

---
 debian/changelog | 7 +++
 debian/control   | 6 --
 debian/libusbprog0.install   | 2 --
 debian/libusbprog0v5.install | 2 ++
 4 files changed, 13 insertions(+), 4 deletions(-)
 delete mode 100644 debian/libusbprog0.install
 create mode 100644 debian/libusbprog0v5.install

diff --git a/debian/changelog b/debian/changelog
index 791e589..a5526ca 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+usbprog (0.2.0-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename library packages for g++5 ABI transition (closes: 791330).
+
+ -- Julien Cristau   Sun, 16 Aug 2015 17:56:14 +0200
+
 usbprog (0.2.0-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/control b/debian/control
index ec26f2c..6454112 100644
--- a/debian/control
+++ b/debian/control
@@ -36,10 +36,12 @@ Description: GUI firmware programming tool for the USBprog 
hardware
  .
  This package contains a GUI for the usbprog tool.
 
-Package: libusbprog0
+Package: libusbprog0v5
 Architecture: any
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: libusbprog0
+Replaces: libusbprog0
 Description: Library for programming the USBprog hardware
  A programming tool needed to replace the firmware on the USBprog
  hardware. It can automatically retrieve a list of available firmwares from
@@ -55,7 +57,7 @@ Description: Library for programming the USBprog hardware
 Package: libusbprog-dev
 Architecture: any
 Section: libdevel
-Depends: libusbprog0 (= ${binary:Version}), ${misc:Depends}
+Depends: libusbprog0v5 (= ${binary:Version}), ${misc:Depends}
 Description: Development files for libusbprog
  A programming tool needed to replace the firmware on the USBprog
  hardware. It can automatically retrieve a list of available firmwares from
diff --git a/debian/libusbprog0.install b/debian/libusbprog0.install
deleted file mode 100644
index cafcf37..000
--- a/debian/libusbprog0.install
+++ /dev/null
@@ -1,2 +0,0 @@
-debian/tmp/usr/lib/libusbprog.so.0
-debian/tmp/usr/lib/libusbprog.so.0.3.0
diff --git a/debian/libusbprog0v5.install b/debian/libusbprog0v5.install
new file mode 100644
index 000..cafcf37
--- /dev/null
+++ b/debian/libusbprog0v5.install
@@ -0,0 +1,2 @@
+debian/tmp/usr/lib/libusbprog.so.0
+debian/tmp/usr/lib/libusbprog.so.0.3.0
-- 
2.5.0