Bug#827061: transition: openssl

[Kurt Roeckx]

On Thu, Sep 15, 2016 at 11:44:42PM +0200, Christoph Berg wrote:
> Re: Kurt Roeckx 2016-06-11 <20160611194259.ga6...@roeckx.be>
> > > > If I'm ready to upload it to unstable, can I start this
> > > > transition?  Are there things you want me to do?
> > > 
> > > Please upload to experimental first and let us know when that's happened.
> > 
> > It's in experimental already.  The test suite only fails
> > on hurd, for some reason it's not finding the engine.  I still
> > need to look at that.
> 
> Hi,
> 
> do you expect the transition to be done for stretch?

I really would like to have it in stretch.  I don't want to have
the same situtation like we had with 1.0.2 that didn't make it it
to jessie.

> I'm asking because the PostgreSQL people want to know if they need to
> add support for OpenSSL 1.1 in the older release branches (9.2 ..
> 9.4), or if patching 9.5 .. 10 is enough for now.

I guess they want to provide binaries for all their releases on
apt.postgresql.org?  

> (Alternatively, would stretch have OpenSSL 1.0 next to 1.1? This seems
> unlikely, but just to confirm?)

This is not my plan.


Kurt

Bug#837629: u-boot 2016.09 in Debian

[Vagrant Cascadian]

Control: severity 837629 serious

On 2016-09-14, Rick Thomas wrote:
> On Sep 14, 2016, at 5:31 PM, Vagrant Cascadian  wrote:
>
>> Worst case, we have to remove it from stretch again if it really is that
>> bad...
>
> I’ll certainly do the test.  If it still doesn’t work on the OpenRD, I
> would not remove it from stretch just yet.  Frankly, there just aren’t
> that many OpenRD machines out there, and it works on everything else
> we’ve tested it on — including my non-ESATA SheevaPlug.  If we can’t
> fix it for OpenRD, we’ll have to put a warning in NEWS.Debian, but
> IMHO that’s not a reason for denying its benefits to all the other
> machine types.

No, a warning in NEWS.Debian is not good enough; I meant removing the
targets that "brick" devices. There's no point in shipping something
known to be broken in ways that cause boot failures.

At one point I disabled the OpenRD* targets as it was failing to
build... now we're in a similar situation, only they fail to boot at all
even though they build, which is considerably more dangerous...

Upgrading the severity to prevent migration to stretch, until we have
a better handle on the situation...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#837977: mate-terminal: the terminal crashes when changing the color settings of the application

[william]

Package: mate-terminal
Version: 1.14.1-1
Severity: normal

Dear Maintainer,

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

   * what led me up to this is when i try to change a certain setting it causes
a crash to happen
   * i did not do anything to find a fix for this issue
   * the outcome is that the crash occurs every time it can be repeated
   * i expected mate-terminal not to crash suddenly




-- System Information:
Distributor ID: Sparky
Description:SparkyLinux
Release:4
Codename:   Tyche
Architecture: i686

Kernel: Linux 4.7.3-sparky-686 (SMP w/1 CPU core)
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 mate-terminal depends on:
ii  gsettings-desktop-schemas  3.21.4-2
ii  libatk1.0-02.21.90-2
ii  libc6  2.23-5
ii  libcairo-gobject2  1.14.6-1+b1
ii  libcairo2  1.14.6-1+b1
ii  libgdk-pixbuf2.0-0 2.34.0-1
ii  libglib2.0-0   2.49.6-1
ii  libgnutls303.5.3-4
ii  libgtk-3-0 3.21.5-3
ii  libice62:1.0.9-1+b1
ii  libmate-desktop-2-17   1.14.1-1
ii  libpango-1.0-0 1.40.2-1
ii  libpangocairo-1.0-01.40.2-1
ii  libsm6 2:1.2.2-1+b1
ii  libstartup-notification0   0.12-4
ii  libvte-2.91-0  0.45.90-2
ii  libx11-6   2:1.6.3-1
ii  mate-desktop-common1.14.1-1
ii  mate-terminal-common   1.14.1-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

mate-terminal recommends no packages.

mate-terminal suggests no packages.

-- no debconf information

Bug#837976: mmh: Fails to install if package pick is installed

[Andreas Schmidt]

Package: mmh
Version: 0.3-1
Severity: important

Dear Maintainer,

I can't install mmh because it conflicts with files that are present in a
completely unrelated package (pick, a" utility to choose one option from a set
of choices"):

***
Preparing to unpack .../archives/mmh_0.3-1_i386.deb ...
Unpacking mmh (0.3-1) ...
dpkg: error processing archive /var/cache/apt/archives/mmh_0.3-1_i386.deb
(--unpack):
 trying to overwrite '/usr/share/man/man1/pick.1.gz', which is also in package
pick 1.1.1-1+b1
Errors were encountered while processing:
 /var/cache/apt/archives/mmh_0.3-1_i386.deb
***

Could you, perhaps, pick another name for the pick utility contained in your
package?

Thanks and best regards!

Andreas



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

Kernel: Linux 4.7.0-1-686-pae (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)

Bug#837975: generate pdiff for DEP-11 Metadata

[Pirate Praveen]

package: ftp.debian.org

See https://lists.debian.org/debian-devel/2016/09/msg00370.html for
discussion.



signature.asc
Description: OpenPGP digital signature

Bug#837974: ftp.debian.org: please enable pdiffs for the debian-debug archive

[Paul Wise]

Package: ftp.debian.org
Severity: wishlist

Please enable pdiffs for the Debian debug archive. The number of
packages in the debug archive has increased a lot since it was created
and the Packages file for amd64 is now about 2MB. Enabling pdiffs would
help folks who have small quotas or slow connections to use the debug
archive. The debug archive already has debdelta support for reducing
download sizes of binary packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#837973: licensecheck should check license of font files

[Pirate Praveen]

package: licensecheck

version: 3.0.24-1

severity: wishlist

Many times ftp master reject a package because copyright of embedded
fonts are missing. It wuld be nice if licensecheck can find it before
the upload itself.





signature.asc
Description: OpenPGP digital signature

Bug#837972: qbittorrent: Please package 3.3.7 as there are some bug-fixes

[shirish शिरीष]

Package: qbittorrent
Version: 3.3.6-1+b1
Severity: wishlist

Dear Maintainer,
Pleae package qbittorrent as the new release has some bug-fixes -

Sunday September 11th 2016 - qBittorrent v3.3.7 release

qBittorrent v3.3.7 was released. Minor bugfixes of v3.3.6. Mac OS X
builds will be delayed a little bit because Qt 5.6.1 doesn't play nice
and I'll need to rebuild 5.6.0.

FEATURE: Delete torrent+files with Shift+Delete (pieniacy)
BUGFIX: Fix 6-hour speedplot point push rate. Close #5545 (Daniel Segesdi)
BUGFIX: Avoid spawning a new explorer.exe process when selecting
"Open containing folder". Closes #5564. (Chocobo1)
BUGFIX: Fix loading of new geoip db due to an artificial size
limit. (SagePtr)
BUGFIX: Better error handling and logging with smtp communication.
(Brian Kendall)
SEARCH: Remove KickassTorrents search engine (ngosang)
SEARCH: Remove BTDigg search engine (ngosang)
SEARCH: Update Torrentz search engine (ngosang)

http://www.qbittorrent.org/news.php

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

Kernel: Linux 4.6.0-1-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: systemd (via /run/systemd/system)

Versions of packages qbittorrent depends on:
ii  geoip-database 20160812-1
ii  libboost-system1.61.0  1.61.0+dfsg-2.1
ii  libc6  2.23-5
ii  libgcc11:6.1.1-11
ii  libqt5core5a   5.6.1+dfsg-3+b1
ii  libqt5dbus55.6.1+dfsg-3+b1
ii  libqt5gui5 5.6.1+dfsg-3+b1
ii  libqt5network5 5.6.1+dfsg-3+b1
ii  libqt5widgets5 5.6.1+dfsg-3+b1
ii  libqt5xml5 5.6.1+dfsg-3+b1
ii  libstdc++6 6.1.1-11
ii  libtorrent-rasterbar9  1.1.0-3
ii  python 2.7.11-2
ii  zlib1g 1:1.2.8.dfsg-2+b1

qbittorrent recommends no packages.

Versions of packages qbittorrent suggests:
ii  qbittorrent-dbg  3.3.6-1+b1

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#837971: aptitude: [PATCH] Distinguish Debian-specific and upstream upgrades

[Keshav Kini]

On 09/15/2016 08:51 PM, Keshav Kini wrote:
> ===File
> /home/fs/src/aptitude/0001-Distinguish-Debian-specific-and-upstream-upgrades.patch===

Oops, looks like I accidentally attached the patch both as a MIME
attachment and inline.  Sorry about that -- they're the same patch.

-Keshav

Bug#837971: aptitude: [PATCH] Distinguish Debian-specific and upstream upgrades

[Keshav Kini]

Package: aptitude
Version: 0.8.3-1
Severity: wishlist
Tags: patch

Dear Maintainer,

When upgrading packages, aptitude users might like to know whether each
upgrade represents a newer upstream version of the package, or is merely
a Debian-specific change.  This can be determined by comparing the
current and candidate versions in the rightmost two columns of the
package listing, but I thought it might be easier to see at a glance if
these two kinds of upgrades were colored differently in the UI.

The attached patch (directly importable into git) makes upgrades that
represent a newer upstream version appear in bold, while upgrades that
represent a Debian revision bump appear as before.

Thanks,
Keshav

>From a75130149a4e838d090d5af3158868d24b0b2c7d Mon Sep 17 00:00:00 2001
From: Keshav Kini 
Date: Thu, 15 Sep 2016 20:34:35 -0700
Subject: [PATCH] Distinguish Debian-specific and upstream upgrades

When upgrading packages, aptitude users might like to know whether each
upgrade represents a newer upstream version of the package, or is merely
a Debian-specific change.  This can be determined by comparing the
current and candidate versions in the rightmost two columns of the
package listing, but I thought it might be easier to see at a glance if
these two kinds of upgrades were colored differently in the UI.

This commit makes upgrades that represent a newer upstream version
appear in bold, while upgrades that represent a Debian revision bump
appear as before.
---
 src/defaults.cc | 36 +++-
 src/pkg_item.cc | 11 +--
 2 files changed, 28 insertions(+), 19 deletions(-)

diff --git a/src/defaults.cc b/src/defaults.cc
index 1747f90..f0ad047 100644
--- a/src/defaults.cc
+++ b/src/defaults.cc
@@ -107,23 +107,25 @@ static void init_keybindings()
 
 static void init_styles()
 {
-  cw::set_style("PkgNotInstalled", cw::style());
-  cw::set_style("PkgIsInstalled",  cw::style_attrs_on(A_BOLD));
-  cw::set_style("PkgToHold",   cw::style_fg(COLOR_WHITE)   + cw::style_attrs_on(A_REVERSE));
-  cw::set_style("PkgToRemove", cw::style_fg(COLOR_MAGENTA) + cw::style_attrs_on(A_REVERSE));
-  cw::set_style("PkgBroken",   cw::style_fg(COLOR_RED) + cw::style_attrs_on(A_REVERSE));
-  cw::set_style("PkgToInstall",cw::style_fg(COLOR_GREEN)   + cw::style_attrs_on(A_REVERSE));
-  cw::set_style("PkgToUpgrade",cw::style_fg(COLOR_CYAN)+ cw::style_attrs_on(A_REVERSE));
-  cw::set_style("PkgToDowngrade",  cw::style_fg(COLOR_YELLOW)  + cw::style_attrs_on(A_REVERSE));
-
-  cw::set_style("PkgNotInstalledHighlighted", cw::style_attrs_flip(A_REVERSE));
-  cw::set_style("PkgIsInstalledHighlighted",  cw::style_attrs_on(A_BOLD) + cw::style_attrs_flip(A_REVERSE));
-  cw::set_style("PkgToHoldHighlighted",   cw::style_fg(COLOR_WHITE));
-  cw::set_style("PkgToRemoveHighlighted", cw::style_fg(COLOR_MAGENTA));
-  cw::set_style("PkgBrokenHighlighted",   cw::style_fg(COLOR_RED));
-  cw::set_style("PkgToInstallHighlighted",cw::style_fg(COLOR_GREEN));
-  cw::set_style("PkgToUpgradeHighlighted",cw::style_fg(COLOR_CYAN));
-  cw::set_style("PkgToDowngradeHighlighted",  cw::style_fg(COLOR_YELLOW));
+  cw::set_style("PkgNotInstalled",  cw::style());
+  cw::set_style("PkgIsInstalled",   cw::style_attrs_on(A_BOLD));
+  cw::set_style("PkgToHold",cw::style_fg(COLOR_WHITE)   + cw::style_attrs_on(A_REVERSE));
+  cw::set_style("PkgToRemove",  cw::style_fg(COLOR_MAGENTA) + cw::style_attrs_on(A_REVERSE));
+  cw::set_style("PkgBroken",cw::style_fg(COLOR_RED) + cw::style_attrs_on(A_REVERSE));
+  cw::set_style("PkgToInstall", cw::style_fg(COLOR_GREEN)   + cw::style_attrs_on(A_REVERSE));
+  cw::set_style("PkgToUpgradeUpstream", cw::style_fg(COLOR_CYAN)+ cw::style_attrs_on(A_REVERSE | A_BOLD));
+  cw::set_style("PkgToUpgradeDebian",   cw::style_fg(COLOR_CYAN)+ cw::style_attrs_on(A_REVERSE));
+  cw::set_style("PkgToDowngrade",   cw::style_fg(COLOR_YELLOW)  + cw::style_attrs_on(A_REVERSE));
+
+  cw::set_style("PkgNotInstalledHighlighted",  cw::style_attrs_flip(A_REVERSE));
+  cw::set_style("PkgIsInstalledHighlighted",   cw::style_attrs_on(A_BOLD) + cw::style_attrs_flip(A_REVERSE));
+  cw::set_style("PkgToHoldHighlighted",cw::style_fg(COLOR_WHITE));
+  cw::set_style("PkgToRemoveHighlighted",  cw::style_fg(COLOR_MAGENTA));
+  cw::set_style("PkgBrokenHighlighted",cw::style_fg(COLOR_RED));
+  cw::set_style("PkgToInstallHighlighted", cw::style_fg(COLOR_GREEN));
+  cw::set_style("PkgToUpgradeUpstreamHighlighted", cw::style_fg(COLOR_CYAN) + cw::style_attrs_on(A_BOLD));
+  cw::set_style("PkgToUpgradeDebianHighlighted",   cw::style_fg(COLOR_CYAN));
+  cw::set_style("PkgToDowngradeHighlighted",   cw::style_fg(COLOR_YELLOW));
 
   cw::set_style("DepBroken", cw::style_fg(COLOR_BLACK)+cw::style_bg(COLOR_RED));
 
diff --git a/src/pkg_item.cc b/src/pkg_item.cc
index 

Bug#837810: df and du shows different size

[Bob Proulx]

Андрей Василишин wrote:
> Thanks for your reply.
> If you watched my first message, you can see difference between df and du
> used space  237G vs 24G. There are no open deleted files. If I unmount this
> filesystems and do fsck, du and df will show the same used space.

I did read your message but honestly I assumed it was deleted files
since that is the most common problem.  The FAQ covers that case
specifically and therefore that seemed like the mostly likely reason.

This is unlikely to actually be a df or du problem since those simply
sum up the result of kernel system calls.  If the kernel is returning
correct data then those utilities return correct information.  If not
then the underlying system calls would be to blame.

If you can recreate this problem again (since you said they are now
the same again) then try using strace to record what the underlying
system calls returned.

  strace -v -o df.strace.out df -H

  strace -v -o du.ms1.strace.out du -hs /megastorage1

The files produced will record the raw system call data.  For df that
is relatively simple to work with directly.  For du it will be at
least one stat for every file it is summing and will need something to
sum up the raw data such as an awk, perl, python or other script.  But
that would show that the utilties are producing the correct
information given the raw data they are receiving from the kernel
system calls.

Bob

Bug#837964: mdadm --add fails, can not add spares (regression)

[Anthony DeRobertis]

Got the exact mdadm error message (well, with a different device):

mdadm: add new device failed for /dev/sdc3 as 8: Invalid argument

and the associated kernel messages for that one:

[12082.269147] md: sdc3 does not have a valid v1.0 superblock, not 
importing!

[12082.269155] md: md_import_device returned -22

sdc3 used to be in the array, but I removed it and did a 
--zero-superblock on it before trying to re-add it. (sdb3 had never been 
in the array before).

Bug#837970: Apt simulation improvements

[Kevin Mills]

Package: apt
Version: 1.2.12
Severity: wishlist

It should be possible to continue a simulation through several invocations
of apt. As it is, you can only do a simulation of one thing; you can't
simulate, for example, installing package X and removing package Y, only
one or the other.

Perhaps an environment variable could be added (such as APT_SIMULATE or
APT_SIMULATION), which, when defined, would cause all invocations of apt to
be part of a single simulation.

Bug#837969: task-sinhala-desktop: please change the default font from LKLUG to Noto

[Harshula]

Package: tasksel
Version: 3.35
Severity: important

Please change the default font from LKLUG to Noto.

The LKLUG font is viewed as deprecated and we've been trying to
encourage other fonts that can succeed as the default Sinhala font on
GNU/Linux.

At this stage the Noto Sinhala range, in fonts-noto-hinted, is a more
appropriate default font than LKLUG.

See the discussion here:
http://sourceforge.net/p/sinhala/mailman/message/34481529/

$ apt-cache rdepends fonts-lklug-sinhala
fonts-lklug-sinhala
Reverse Depends:
  task-sinhala-desktop

$ dpkg -L fonts-noto-hinted | grep -i sinhala
/usr/share/fonts/truetype/noto/NotoSansSinhala-Bold.ttf
/usr/share/fonts/truetype/noto/NotoSansSinhala-Regular.ttf

Thanks,
#

Bug#837968: key generation blocks gpg signing with another already existing key

[Joey Hess]

Package: gnupg
Version: 2.1.15-2
Severity: normal

I was running gpg --full-gen-key in one terminal, and it was taking a
while to find enough entropy.

In another terminal, I tried to make a git commit, and this hung. git
was running gpg -bsau, signing using a differeny key that already exists, 
and it seems it's blocking while the key generation is running.

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

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

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.15-2
ii  libassuan0 2.4.3-1
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.24-2
ii  libgcrypt201.7.3-1
ii  libgpg-error0  1.24-1
ii  libksba8   1.3.5-2
ii  libreadline6   6.3-8+b4
ii  libsqlite3-0   3.14.1-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
ii  dirmngr 2.1.15-2
pn  gnupg-l10n  

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#835360: rkt: FTBFS on several architectures

[Potter, Tim (HPE Linux Support)]

On 29 Aug 2016, at 8:59 PM, Luca BRUNO  wrote:
> 
> 1.13.0+dfsg-1 has been built without issues on i386:
> https://buildd.debian.org/status/fetch.php?pkg=rkt=i386=1.13.0%2Bdfsg-1=1472188080
> 
> ppc64 and s390x are in progress upstream and should hopefully
> be back in the next releases.
> 
> Ciao, Luca

PPC support looks like it has been added in rkt 1.14 and above [1].  According 
to the
release notes on golang.org, experimental support has been added for s390 
systems
in Go 1.7.  We're currently up to Go 1.7 in unstable so we could have rkt 
building on
all architectures pretty soon.


Tim.

[1] https://github.com/coreos/rkt/blob/v1.14.0/configure.ac#L49
[2] https://golang.org/doc/go1.7


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#837967: icedtea-netx: update-alternatives warns when removing icedtea-netx

[River Chiang]

Package: icedtea-netx
Severity: normal

Dear Maintainer,


This warning happens when I purg icedtea-netx package.
Please refer to the following log.


root@debian:~# apt-get purge icedtea-7-plugin icedtea-netx icedtea-netx-common 
icedtea-plugin
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  icedtea-7-plugin* icedtea-netx* icedtea-netx-common* icedtea-plugin*
0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded.
After this operation, 2,260 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 137810 files and directories currently installed.)
Removing icedtea-plugin (1.5.3-1) ...
Removing icedtea-7-plugin:amd64 (1.5.3-1) ...
Removing icedtea-netx:amd64 (1.5.3-1) ...
update-alternatives: warning: forcing reinstallation of alternative 
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/itweb-settings because link group 
itweb-settings is broken
update-alternatives: warning: not replacing 
/usr/share/man/man1/itweb-settings.1.gz with a link
Removing icedtea-netx-common (1.5.3-1) ...
Purging configuration files for icedtea-netx-common (1.5.3-1) ...
Processing triggers for man-db (2.7.0.2-5) ...
Processing triggers for desktop-file-utils (0.22-1) ...
Processing triggers for gnome-menus (3.13.3-6) ...
Processing triggers for mime-support (3.58) ...
Processing triggers for hicolor-icon-theme (0.13-1) ...
root@debian:~# aptitude search icedtea
p   icedtea-7-jre-jamvm - Alternative JVM for OpenJDK, using JamVM  
pi  icedtea-7-plugin- web browser plugin based on OpenJDK and Ic
pi  icedtea-netx- NetX - implementation of the Java Network 
pi  icedtea-netx-common - NetX - implementation of the Java Network 
pi  icedtea-plugin


After purging the packages, the status becomes pi.





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

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

Bug#837890: libqt5sql5-sqlite: /usr/lib/x86_64-linux-gnu/cmake/Qt5Sql/Qt5Sql_QSQLiteDriverPlugin.cmake is missing

[Lisandro Damián Nicanor Pérez Meyer]

tag 837890 moreinfo
thanks

Hi Paul!

On jueves, 15 de septiembre de 2016 10:23:31 A. M. ART Paul Labedan wrote:
[snip] 
> The /usr/lib/x86_64-linux-gnu/cmake/Qt5Sql/Qt5Sql_QSQLiteDriverPlugin.cmake
> file is missing (it's loaded by
> /usr/lib/x86_64-linux-gnu/cmake/Qt5Sql/Qt5SqlConfig.cmake) to populate
> Qt5::QSQLiteDriverPlugin (which then could be used to locate the plugin
> withing cmake). I found the issue on debian 8 and 7 with backports, both on
> x86 and amd64.

We are actually proactively removing them for every plugin. The rationale is 
that so far we could not find a reason to ship them, as the only use we could 
hear of so far is to locate the plugin to be able to ship it on a bundled app.

Of course if you have a good reason to ship this CMake files please do not 
heasitate in telling us, so we can reconsider this.

Thanks for your bug report!



-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!

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#837966: libghc-regex-pcre-dev: problem when searching within a unicode string

[Brian Sammon]

Package: libghc-regex-pcre-dev
Version: 0.94.4-7
Severity: normal

When I try to run a program that searches for a (ASCII) string in a
UTF8-encoded string, I get a wierd "off-by-one" error:
I expect
  title is |Page Title|
I get
  title is |age Title'|

I can't find any docs that say I'm doing it wrong, or that I have to do
things a specific way to get unicode support.

(hopefully) A test-case haskell script is attached.

-- System Information:
Debian Release: 7.7
  APT prefers stable
  APT policy: (990, 'stable'), (990, 'oldstable')
Architecture: i386 (i686)

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

Versions of packages libghc-regex-pcre-dev depends on:
ii  ghc [libghc-containers-dev-0.5.6.2-5879d]   7.10.3-9
ii  libc6   2.19-18
pn  libghc-array-dev-0.5.1.0-98220  
pn  libghc-base-dev-4.8.2.0-a3ce8   
pn  libghc-bytestring-dev-0.10.6.0-89a6f
ii  libghc-regex-base-dev [libghc-regex-base-dev-0.93.2-b11ef]  0.93.2-8
ii  libpcre32:8.35-3.3
ii  libpcre3-dev2:8.35-3.3

libghc-regex-pcre-dev recommends no packages.

Versions of packages libghc-regex-pcre-dev suggests:
pn  libghc-regex-pcre-doc   
pn  libghc-regex-pcre-prof  

-- no debconf information
#!/usr/bin/runghc

module Main where

import Text.Regex.PCRE

get_subgroup :: (String, String, String, [String]) -> Int -> String
get_subgroup (_, m, _, _) 0 = m
get_subgroup (_, _, _, tl) i = tl !! (i - 1)

main = do
  let i = " "
  
  let title = get_subgroup (i =~ "title='([^']*)'") 1

  putStrLn ("title is |" ++ title ++ "|")

Bug#811767: great news

[Patty Langer]

Hey! 

I've got great news for you, you're going to  be really surprised,  just take a 
look 

Best Wishes, Patty Langer

Bug#778695: wheezy -> jessie: no gdm3 prompt, dependency loops and broken initrd

[Gabriel Filion]

Hello,

I've worked a little bit on this in the same setup as Anarcat used, here
at koumbit.

I've figured out why the users were not listed in gdm3. It was a line in
/etc/pam.d/common-session that was missing:

session optionalpam_systemd.so

with this line users are listed.

This problem was caused by our puppetmaster crushing the file's
contents, so it's not an issue with the upgrade process itself.


I've also had issues with dependencies during dist-upgrade but I don't
have good info to show here and I think the issues were with different
packages. I'll try to get more info on this on the next upgrade.

However I couldn't reproduce the initrd issue. The desktop rebooted in
the new kernel as expected after both short and full upgrades. Maybe the
difference was that I did not reboot between short and full upgrades and
rebooted only once at the end of the whole process.

Cheers



signature.asc
Description: OpenPGP digital signature

Bug#684382: PHP bindings for libhdate

[Ariel]

Source: libhdate
Followup-For: Bug #684382

Please enable the PHP bindings. I am including a patchfile with everything 
necessary.

Just apply the patch and rebuild, you don't have to do anything else.

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

Kernel: Linux 3.16.36 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Naur old/debian/control new/debian/control
--- old/debian/control	2014-09-10 11:04:04.0 -0400
+++ new/debian/control	2016-09-15 19:24:30.842054753 -0400
@@ -51,6 +51,19 @@
  .
  This package contains perl bindings to libhdate
 
+Package: libhdate-php
+Section: php
+Architecture: any
+Depends: libhdate1 (= ${binary:Version}), ${php:Depends}, ${shlibs:Depends}, ${misc:Depends}
+Description: Provides a library that help use hebrew dates (php bindings)
+ LibHdate is a small C,C++ library for Hebrew dates,
+ holidays, and reading sequence (parasha). It is using 
+ the source code from Amos Shapir's "hdate" package fixed 
+ and patched by Nadav Har'El. The Torah reading sequence
+ is from tables by Zvi Har'El.
+ .
+ This package contains PHP bindings to libhdate
+
 Package: libhdate1
 Section: libs
 Architecture: any
diff -Naur old/debian/libhdate-php.install new/debian/libhdate-php.install
--- old/debian/libhdate-php.install	2016-09-15 18:52:02.306608632 -0400
+++ new/debian/libhdate-php.install	2016-09-15 19:01:06.835711780 -0400
@@ -1,2 +1,3 @@
-bindings/php/hdate.ini etc/php5/conf.d
+bindings/php/hdate.ini etc/php5/mods-available
 usr/lib/php5/*
+usr/share/php/hdate.php
diff -Naur old/debian/libhdate-php.postinst new/debian/libhdate-php.postinst
--- old/debian/libhdate-php.postinst	1969-12-31 19:00:00.0 -0500
+++ new/debian/libhdate-php.postinst	2016-09-15 19:10:03.269678201 -0400
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+set -e
+
+dpkg-maintscript-helper mv_conffile /etc/php5/conf.d/hdate.ini \
+/etc/php5/mods-available/hdate.ini 1.6-3+b2 -- "$@"
+rm -f /etc/php5/conf.d/hdate.ini
+
+[ "$1" = "configure" ] && php5enmod hdate
+
+#DEBHELPER#
+
+exit 0
diff -Naur old/debian/libhdate-php.preinst new/debian/libhdate-php.preinst
--- old/debian/libhdate-php.preinst	1969-12-31 19:00:00.0 -0500
+++ new/debian/libhdate-php.preinst	2016-09-15 19:10:23.446030225 -0400
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+set -e
+
+dpkg-maintscript-helper mv_conffile /etc/php5/conf.d/hdate.ini \
+/etc/php5/mods-available/hdate.ini 1.6-3+b2 -- "$@"
+rm -f /etc/php5/conf.d/hdate.ini
+
+#DEBHELPER#
+
+exit 0
diff -Naur old/debian/libhdate-php.prerm new/debian/libhdate-php.prerm
--- old/debian/libhdate-php.prerm	1969-12-31 19:00:00.0 -0500
+++ new/debian/libhdate-php.prerm	2016-09-15 19:10:55.480600612 -0400
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+set -e
+
+dpkg-maintscript-helper mv_conffile /etc/php5/conf.d/hdate.ini \
+/etc/php5/mods-available/hdate.ini 1.6-3+b2 -- "$@"
+rm -f /etc/php5/conf.d/hdate.ini
+
+[ "$1" = "remove" ] && php5dismod hdate
+
+#DEBHELPER#
+
+exit 0
diff -Naur old/debian/rules new/debian/rules
--- old/debian/rules	2016-09-15 19:43:46.027354228 -0400
+++ new/debian/rules	2016-09-15 19:44:09.540765571 -0400
@@ -3,10 +3,13 @@
 ARCHLIB := $(shell perl -MConfig -e 'print $$Config{vendorarch}')
 
 %:
-	dh $* --with python2,autoreconf
+	dh $* --with python2,autoreconf,php5
 
 override_dh_auto_configure:
 	dh_auto_configure -- --with-perl-sitelib-dir=$(ARCHLIB)
 
 override_dh_python2:
 	dh_python2 -s --no-guessing-versions
+
+binary-arch:
+	echo "php:Depends=phpapi-`php-config5 --phpapi`" >> debian/libhdate-php.substvars

Bug#837965: mate-power-manager: segfaults in strtod

[brian m. carlson]

Package: mate-power-manager
Version: 1.14.0-2
Severity: grave

mate-power-manager segfaults.  Consequently, laptops do not suspend and
they run out of power and crash.

Backtrace:

genre ok % gdb $(which mate-power-manager)
GNU gdb (Debian 7.11.1-2) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/mate-power-manager...Reading symbols from 
/usr/lib/debug/.build-id/4e/335f33ab0234b6fb93ea03f8a340c16b7cfddd.debug...done.
done.
(gdb) run
Starting program: /usr/bin/mate-power-manager
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffebfa4700 (LWP 9556)]
[New Thread 0x7fffeb7a3700 (LWP 9557)]
[New Thread 0x7fffea557700 (LWP 9558)]

(mate-power-manager:9502): Gtk-WARNING **: gtk_widget_size_allocate(): attempt 
to underallocate toplevel GtkTrayIcon 0x55aac4b0. Allocation is 16x26, but 
minimum required size is 22x16.

(mate-power-manager:9502): Gtk-WARNING **: gtk_widget_size_allocate(): attempt 
to underallocate GtkTrayIcon's child GtkImage 0x55973140. Allocation is 
16x26, but minimum required size is 22x16.

Thread 1 "mate-power-mana" received signal SIGSEGV, Segmentation fault.
__GI_strtod_l_internal (nptr=0x75e1595d "10", endptr=0x7f7ff330, 
group=0, loc=0x736e3820 <_nl_C_locobj>) at strtod_l.c:481
481 strtod_l.c: No such file or directory.
(gdb) bt full
#0  __GI_strtod_l_internal (nptr=0x75e1595d "10", 
endptr=0x7f7ff330, group=0, loc=0x736e3820 <_nl_C_locobj>) at 
strtod_l.c:481
negative = 
num = 
numsize = 
exponent = 
base = 10
den = {0 , 140737286183751, 93824995883472, 0, 1, 
93824997126160, 140737479963664, 140737286176431, 206158430240, 
140737479963888, 140737479963696,
  2108808263226697984, 4621819117588971520, 140737286183751, 
93824995883472, 0, 1, 93824997126272, 140737479963760, 140737286176431, 
206158430240, 140737479963984,
  140737479963792, 2108808263226697984, 2, 140737286164900, 
93824996048256, 140737286164592, 32, 1, 93824995883472, 140737286273314, 
93823560581122, 140737283113241,
  140737318574429, 93824997126272, 4, 140737286183751, 0, 
140737277479680, 32, 93825014019456, 0}
densize = 
retval = 
bits = 
cp = 
tp = 
startp = 
start_of_digits = 
expp = 
dig_no = 
int_no = 
lead_zero = 
c = 
decimal = 
decimal_len = 
thousands = 0x0
grouping = 
cnt = 
current = 0x736e1c60 <_nl_C_LC_NUMERIC>
__PRETTY_FUNCTION__ = "strtod_l_internal"
lowc = 
#1  0x752ac0fe in ?? () from /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0
No symbol table info available.
#2  0x752ad7a1 in pango_font_description_from_string () from 
/usr/lib/x86_64-linux-gnu/libpango-1.0.so.0
No symbol table info available.
#3  0x75acb450 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
No symbol table info available.
#4  0x73f5034b in g_type_create_instance () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#5  0x73f321fb in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#6  0x73f3410e in g_object_new_valist () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#7  0x73f343b1 in g_object_new () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#8  0x75ad17d6 in gtk_widget_get_style () from 
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
No symbol table info available.
#9  0x5556a234 in msd_osd_window_style_set (widget=0x55aa4390, 
previous_style=0x0) at msd-osd-window.c:501
style = 
#10 0x73f3 in g_cclosure_marshal_VOID__OBJECTv () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#11 0x73f2d0f2 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#12 0x73f478bd in g_signal_emit_valist () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#13 0x73f47faf in g_signal_emit () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No 

Bug#836585: celery: FTBFS in testing (failing tests)

[Santiago Vila]

On Wed, 14 Sep 2016, Michael Fladischer wrote:

> > So: It is really so much work to add a versioned build-depends?
> > (I see that a lot of them are already versioned).
> > 
> > We really *never* use versioned build-depends to avoid FTBFS bugs
> > as some people claim?
> 
> To me, versioned dependencies were used to prevent FTBFS in unstable.
> But you have a point here, I'll probably add a version constraint to
> python-openssl in my next upload to unstable.

Hi. This is probably not necessary anymore as there is a better solution
proposed by Scott Kitterman in -devel.

Thanks.

Bug#837797: tzdata: America/Eastern reports Local Mean Time by default instead of EST

[Aurelien Jarno]

On 2016-09-14 14:15, Greg Flynn wrote:
> Package: tzdata
> Version: 2016f-1
> Severity: critical
> Tags: newcomer
> Justification: breaks unrelated software
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> Running unit tests in Python while set timezone using the string
> 'America/Eastern'.
> The offset was reported as UTC-4.9333 which resulted 
> in
> a discrepency of about 4 minutes
> When running the same test on a server running Debian 8.5 with tzdata
> 2016f-0+deb8u1 the same test passed
>* What exactly did you do (or not do) that was effective (or ineffective)?
> Changing timezone to 'EST' fixed the particular test and gave the
> expected -5 offset for Standard time, but I think EST and America/Eastern
> should be returning the same value

I think your expectation here is wrong, and probably also your
understanding of the python-tz library. The EST timezone has always been
at UTC-5, so it's normal it returns a UTC-5 value. On the other hand the
New York timezone has been using the LMT in the past.

In the example code you have given, the year is unspecified. You have
tried to freeze the current time, but arrow.get doesn't use the current
time for the values that are unspecified. This can be shown by running
for example: 

  print arrow.get('10:00:00', 'HH:mm:SS').format('')

This returns year 0001. Many softwares, including python-tz did not
handle dates before the first transition, which in the New York timezone
case corresponds to the switch from LMT to UTC-5. Therefore this
transition was kind of ignored and all dates before this transition was
returned as UTC-5. Recent version of zic (ie the one in stretch) has
duplicated the first transition at the time of the big bang so that
dates before this transition are handled correctly on all software.
That's why in stretch year 0001 is considered in LMT, while in jessie it
is considered in UTC-5.

In your case you should change your test code to include the full date
instead of using freeze_time:

  arrow.get('2016-01-01 10:00:00', '-MM-DD HH:mm:SS')

Given the above explanations, I do not believe it's a bug in tzdata, at
most it's a bug in python-tz. I therefore offer to just close this bug
if you agree.

Aurelien

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


signature.asc
Description: PGP signature

Bug#837964: mdadm --add fails, can not add spares (regression)

[Anthony DeRobertis]

Package: mdadm
Version: 3.4-4
Severity: important

I attempted both of these:

mdadm --add /dev/md127 /dev/sdb3
mdadm --add-spare /dev/md127 /dev/sdb3

both failed (sorry, didn't take down the exact error message), giving
this in the kernel log:

[   24.109034] md: sdb3 does not have a valid v1.0 superblock, not importing!
[   24.109105] md: md_import_device returned -22

I grabbed mdadm 3.3.2-5+deb8u1 from stable, extracted it to a random
directory ("ugh") in /root (with dpkg -x), then:

/root/ugh/sbin/mdadm -a /dev/md127 /dev/sdb3

... worked.

So it appears adding spares has been broken, at least in some cases, in
newer mdadm.

If you'd like, I'll try to play around with it tomorrow and see if I can
reproduce on loopback devices.

-- Package-specific info:
--- mdadm.conf
DEVICE partitions
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST 
MAILADDR root,derob...@gmail.com
ARRAY /dev/md0 metadata=0.90 UUID=a1b8efea:2114fd99:28a5f279:815d333e
ARRAY /dev/md/pv0 metadata=1.0 UUID=c840d0de:0626d783:3f1b28dc:c5ec649a 
name=Zia:pv0

--- /etc/default/mdadm
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities : [raid10] [raid1] [linear] [multipath] [raid0] [raid6] [raid5] 
[raid4] 
md127 : active raid10 sdb3[7](S) sde3[5] sdc3[2] sdd3[6] sda3[4]
  1953005568 blocks super 1.0 512K chunks 2 far-copies [4/4] []
  bitmap: 12/466 pages [48KB], 2048KB chunk

md0 : active raid1 sdd1[3] sde1[2] sdc1[0] sda1[1] sdb1[4]
  128384 blocks [5/5] [U]
  bitmap: 0/16 pages [0KB], 4KB chunk

unused devices: 

--- /proc/partitions:
major minor  #blocks  name

   80 1953514584 sda
   81 128488 sda1
   82 128520 sda2
   83  976502992 sda3
   8   64  976762584 sde
   8   65 128488 sde1
   8   66 128520 sde2
   8   67  976502992 sde3
   8   48 1953514584 sdd
   8   49 128488 sdd1
   8   50 128520 sdd2
   8   51  976502992 sdd3
   8   16 1953514584 sdb
   8   17 128488 sdb1
   8   18 128520 sdb2
   8   19  976502992 sdb3
   8   32  976762584 sdc
   8   33 128488 sdc1
   8   34 128520 sdc2
   8   35  976502992 sdc3
   90 128384 md0
   9  127 1953005568 md127
 25305857280 dm-0
 2531  157286400 dm-1
 2532  471859200 dm-2
 2533  209715200 dm-3
 2534  157286400 dm-4
 2535   40222720 dm-5
 2536 753664 dm-6
 2537  714629120 dm-7
  1101048575 sr0
 25385857280 dm-8

--- LVM physical volumes:
  PV VG  Fmt  Attr PSize PFree  
  /dev/md127 Zia lvm2 a--  1.82t 186.34g
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=12338360k,nr_inodes=3084590,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=2468440k,mode=755)
/dev/mapper/Zia-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
systemd-1 on /xfer/5 type autofs 
(rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1565)
systemd-1 on /xfer/4 type autofs 
(rw,relatime,fd=34,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1569)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1575)
systemd-1 on /xfer/2 type autofs 
(rw,relatime,fd=37,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1579)
systemd-1 on /xfer/3 type autofs 
(rw,relatime,fd=40,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1586)
systemd-1 on /xfer/1 type autofs 

Bug#837963: clang-4.0: bogus valgrind warning from push_back() on std::string

[Olly Betts]

Package: clang-4.0
Version: 1:4.0~svn279916-1
Severity: normal

If I compile this reduced testcase with clang++-4.0 and run it under
valgrind, I get a bogus warning from the second push_back().  If I
compile with other versions of clang++ or g++ from Debian I don't
get this warning:

$ cat unittest.cc 
#include 
#include 
#include 

using namespace std;

typedef void (*func)();

struct S {
static void run(func t) {
try {
t();
} catch (const std::exception&) {
cout << "std::exception" << endl;
}
}
};

static void f() {
string s;
s.push_back('a');
s.push_back('a');
cout << s << endl;
}

int main() {
S::run(f);
}
$ clang++-4.0 -g -O2 -o unittest unittest.cc && valgrind ./unittest 
==15131== Memcheck, a memory error detector
==15131== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==15131== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==15131== Command: ./unittest
==15131== 
==15131== Conditional jump or move depends on uninitialised value(s)
==15131==at 0x400C7F: push_back (basic_string.h:1167)
==15131==by 0x400C7F: f() (unittest.cc:22)
==15131==by 0x400CF2: S::run(void (*)()) (unittest.cc:12)
==15131==by 0x400C4A: main (unittest.cc:26)
==15131== 
aa
==15131== 
==15131== HEAP SUMMARY:
==15131== in use at exit: 0 bytes in 0 blocks
==15131==   total heap usage: 1 allocs, 1 frees, 72,704 bytes allocated
==15131== 
==15131== All heap blocks were freed -- no leaks are possible
==15131== 
==15131== For counts of detected and suppressed errors, rerun with: -v
==15131== Use --track-origins=yes to see where uninitialised values come from
==15131== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

The resulting value of s seems to be correct, so it's not entirely clear
to me if the issue is with the generated code, or if this is actually a
valgrind problem, but as it is specific to this compiler version it
seems there's at least some change in the compiler which is triggering
this.

Cheers,
Olly

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

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

Versions of packages clang-4.0 depends on:
ii  binutils 2.27-8
ii  libc62.24-2
ii  libc6-dev2.24-2
ii  libclang-common-4.0-dev  1:4.0~svn279916-1
ii  libclang1-4.01:4.0~svn279916-1
ii  libgcc-6-dev 6.2.0-3
ii  libgcc1  1:6.2.0-3
ii  libjsoncpp1  1.7.4-3
ii  libllvm4.0   1:4.0~svn279916-1
ii  libobjc-6-dev6.2.0-3
ii  libstdc++-6-dev  6.2.0-3
ii  libstdc++6   6.2.0-3

Versions of packages clang-4.0 recommends:
ii  llvm-4.0-dev  1:4.0~svn279916-1
ii  python2.7.11-2

Versions of packages clang-4.0 suggests:
pn  clang-4.0-doc  
pn  gnustep
pn  gnustep-devel  

-- no debconf information


signature.asc
Description: PGP signature

Bug#477297: fixed upstream in master

[Tom Yu]

tags 477297 fixed-upstream
tags 479405 fixed-upstream
thanks

Upstream added a feature to bind specific listening addresses for
krb5kdc and kadmind, in the master branch.  This will be in the upcoming
krb5-1.15 release.

Bug#837962: Xen 4.6 fails to build due to incorrect patch applied to tools/blktap2/drivers/tapdisk-vbd.c

[Brett Stahlman]

Package: xen-hypervisor-4.6-amd64
Version: 4.6.0-1ubuntu4.1

I downloaded the source with `apt-get source', and did the following:
./configure
make debball

The build fails with the following error:
gcc  -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99
-Wall -Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable -Wno-unused-local-typedefs
-D__XEN_TOOLS__ -MMD -MF .tapdisk-vbd.o.d -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE   -Werror -Wno-unused -fno-strict-aliasing
-I../include -I../drivers
-I/home/bstahlman/src/xen-4.6-src/xen-4.6.0/tools/blktap2/drivers/../../../tools/libxc/include
-I/home/bstahlman/src/xen-4.6-src/xen-4.6.0/tools/blktap2/drivers/../../../tools/include
-D_GNU_SOURCE -DUSE_NFS_LOCKS
-I/home/bstahlman/src/xen-4.6-src/xen-4.6.0/tools/blktap2/drivers/../../../tools/libxc
-fPIC  -c -o tapdisk-vbd.o tapdisk-vbd.c
tapdisk-vbd.c: In function ‘tapdisk_vbd_pull_ring_requests’:
tapdisk-vbd.c:1572:13: error: invalid type argument of ‘->’ (have
‘blkif_request_t {aka struct blkif_request}’)
   idx  = req->id;
 ^

I have been in touch with the author of the patch, Konrad Rzeszutek
Wilk, who has confirmed that one of the patches in the Debian package
is incorrect. It was apparently amended at some point, but debian is
using the original, flawed version. The following patch is the correct
one in a set of 3 xsa155 patches:
https://xenbits.xen.org/xsa/xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch

The debian package includes an incorrect patch with the same name:
debian/patches/xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch

It's clear that the debian patch won't work, as it declares "req" as a
struct (blkif_request_t req) but de-references it as though it were
pointer to struct (req->id).

I suggest replacing the incorrect xsa155 patch with the fixed one
referenced in the URL above.

I am using Ubuntu 16.04 LTS x86_64 GNU/Linux 4.4, kernel
4.4.0-36-generic #55-Ubuntu SMP

Thanks,
Brett Stahlman

Bug#834682: mina2: FTBFS too much often (failing tests)

[Santiago Vila]

On Fri, 26 Aug 2016, Markus Koschany wrote:

> Control: severity -1 normal

Markus, this package fails to build from source:

* In my 5 autobuilders.

* In one of the three tests made by Gregor.

* In several autobuilders from the reproducible builds effort:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mina2.html


As the failure has been verified from several independent parties, it
would not be unfair at all to say that, objectively, this package FTBFS.

Being able to build from source is a release goal since a lot of time
and deserves serious severity according to release policy:

https://release.debian.org/stretch/rc_policy.txt

which clearly says "Packages must autobuild".

So I ask you one more time that you respect release policy and
reconsider about this.

Thanks.

Bug#835608: mkchromecast: fails to Open pavucontrol and select the mkchromecast sink.

[Muammar El Khatib]

Hi Christian,

On Wed, Aug 31, 2016 at 9:13 AM, Cristian Ionescu-Idbohrn
 wrote:
>
> Could you please heavily comment your proposed configuration so I can
> locate and modify the relevant bits, before testing again?

>
> It did capture a totally silent wav.  And I guess main reason is
> loopback device number.

I hope you are still interested in this. After reading a lot here and
there, I am writing this mail casting ti the chromecast using ALSA
instead of pulseaudio :). It works pretty well so far.  I decided to
uninstall pulseaudio and I gave it a try.

I have prepared a page in the wiki that you can check:

https://github.com/muammar/mkchromecast/wiki/ALSA

I would be glad if you could test it. Note that you have to checkout
the `alsa` branch.

Regarding the two interfaces in your machine, was the chromecast
detected? If yes, I think I can provide a flag where you can specify
the ip of the host.

Regards,
-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#837961: atftpd: presence of optional configfile /etc/atfpd.pcre breaks upgrade

[Ben Hildred]

Package: atftpd
Version: 0.7.git20120829-3
Severity: normal

The most recent version tries to create a directory at /etc/atfpd.pcre.
Previously this was an optional regular configuration file. If this file is
present during the directory creation step, the upgrade fails.



-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.6.0-1-rt-686-pae (SMP w/2 CPU cores; PREEMPT)
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 atftpd depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.23-5
ii  libpcre3   2:8.39-2
ii  libwrap0   7.6.q-25
ii  lsb-base   9.20160629
ii  update-inetd   4.43

Versions of packages atftpd recommends:
ii  openbsd-inetd [inet-superserver]  0.20140418-2

Versions of packages atftpd suggests:
ii  logrotate  3.8.7-2

-- debconf information excluded

Bug#837959: New version available - 1.7.0

[Eric Dorland]

It's already packaged and waiting in NEW.

* Michael-John Turner (m...@mjturner.net) wrote:
> Package: dnscrypt-proxy
> Version 1.6.1-1
> Severity: wishlist
> 
> Hi,
> 
> A new upstream version of dnscrypt-proxy is available - 1.7.0. It would be
> great if the Debian package could be updated to this version.
> 
> Source available from https://download.dnscrypt.org/dnscrypt-proxy/
> 
> Cheers, MJ

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93

Bug#480517: fixed in krb5-1.11

[Tom Yu]

fixed 480517 krb5/1.11.1+dfsg-1
thanks

Upstream fixed this as part of the documentation consolidation in
release krb5-1.11.

Bug#837960: spdylay: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

Package: spdylay
Version: 1.3.2-2
Severity: important
Tags: patch
Control: block 827061 by -1
Control: user pkg-openssl-devel-requ...@lists.alioth.debian.org
Control: usertag -1 openssl-1.1-trans-keypkg
Control: usertag -1 openssl-1.1-trans

This package fails currently to compile against openssl 1.1.0 (currently
available in experimental). The issues look not openssl specific. The
full build of the build failure is available
  
https://breakpoint.cc/openssl-1.1-rebuild-2016-08-26/failed/spdylay_1.3.2-2_amd64-2016-08-26T19%3A47%3A25Z

With the patch attached is manages to build. The testsuite fails then :)
The SSL error message was obtained via ERR_print_errors_fp(stderr):

| =
|spdylay 1.3.2: tests/test-suite.log
| =
| 
| # TOTAL: 3
| # PASS:  2
| # SKIP:  0
| # XFAIL: 0
| # FAIL:  1
| # XPASS: 0
| # ERROR: 0
| 
| .. contents:: :depth: 2
| 
| FAIL: end_to_end.py
| ===
| 
| SSL_CTX_use_certificate_file failed.
| 140680762493824:error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key 
too small:ssl/ssl_rsa.c:305:
| Could not connect to the host: localhost:9893
| error:1408F10B:SSL routines:ssl3_get_record:wrong version number
| Could not connect to the host: localhost:79
| FCould not connect to the host: localhost:2
| .Could not connect to the host: localhost:9893
| Could not connect to the host: localhost:9893
| FCould not connect to the host: localhost:9893
| FCould not connect to the host: localhost:9893
| FSSL_CTX_use_certificate_file failed.
| 140100289985408:error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key 
too small:ssl/ssl_rsa.c:305:
| Could not connect to the host: localhost:9893

So it looks like the key in the test is too small.

Sebastian
>From 9e74d00a28bf3294722d07a52646a8b1a5740237 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Thu, 15 Sep 2016 20:01:49 +
Subject: [PATCH] spdylay: compile against openssl-1.1.0

It fails to compile against openssl 1.1.0 due to things like
|shrpx_client_handler.cc:90:30: error: 'strerror' was not declared in this scope
|shrpx_listen_handler.cc:112:32: error: 'memset' was not declared in this scope
|shrpx_listen_handler.cc:114:43: error: 'memcpy' was not declared in this scope

This resolves it.

Signed-off-by: Sebastian Andrzej Siewior 
---
 examples/spdycli.c  | 1 +
 src/shrpx.cc| 1 +
 src/shrpx_client_handler.cc | 1 +
 src/shrpx_listen_handler.cc | 1 +
 src/shrpx_ssl.cc| 2 +-
 5 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/examples/spdycli.c b/examples/spdycli.c
index 3874aa4..040ae82 100644
--- a/examples/spdycli.c
+++ b/examples/spdycli.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git a/src/shrpx.cc b/src/shrpx.cc
index 65e9afd..f7bd742 100644
--- a/src/shrpx.cc
+++ b/src/shrpx.cc
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/src/shrpx_client_handler.cc b/src/shrpx_client_handler.cc
index df6bb1c..e8db861 100644
--- a/src/shrpx_client_handler.cc
+++ b/src/shrpx_client_handler.cc
@@ -26,6 +26,7 @@
 
 #include 
 #include 
+#include 
 
 #include "shrpx_upstream.h"
 #include "shrpx_spdy_upstream.h"
diff --git a/src/shrpx_listen_handler.cc b/src/shrpx_listen_handler.cc
index aabd013..f5b8ac6 100644
--- a/src/shrpx_listen_handler.cc
+++ b/src/shrpx_listen_handler.cc
@@ -28,6 +28,7 @@
 #include 
 
 #include 
+#include 
 
 #include 
 
diff --git a/src/shrpx_ssl.cc b/src/shrpx_ssl.cc
index f712816..58753be 100644
--- a/src/shrpx_ssl.cc
+++ b/src/shrpx_ssl.cc
@@ -30,7 +30,7 @@
 #include 
 
 #include 
-#include 
+#include 
 
 #include 
 #include 
-- 
2.9.3

Bug#827061: transition: openssl

[Christoph Berg]

Re: Kurt Roeckx 2016-06-11 <20160611194259.ga6...@roeckx.be>
> > > If I'm ready to upload it to unstable, can I start this
> > > transition?  Are there things you want me to do?
> > 
> > Please upload to experimental first and let us know when that's happened.
> 
> It's in experimental already.  The test suite only fails
> on hurd, for some reason it's not finding the engine.  I still
> need to look at that.

Hi,

do you expect the transition to be done for stretch?

I'm asking because the PostgreSQL people want to know if they need to
add support for OpenSSL 1.1 in the older release branches (9.2 ..
9.4), or if patching 9.5 .. 10 is enough for now.

(Alternatively, would stretch have OpenSSL 1.0 next to 1.1? This seems
unlikely, but just to confirm?)

Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#832124: gitlab: Still affects jessie packages

[Boyd Stephen Smith Jr.]

Package: gitlab
Version: 8.10.5+dfsg-1
Followup-For: Bug #832124

Dear Maintainer,

I tried installing gitlab from your jessie repository (on
people.debian.org), and ran into these errors when the package was
trying to configure itself:

I installed using aptitude.  It pulled most dependencies from your jessie
repository, though some I satisfied from the official backports
repository.

--->8---
Create database if not present
Make gitlab user owner of gitlab_production database...
ALTER DATABASE
Grant all privileges to gitlab user...
GRANT
NOTICE:  extension "pg_trgm" already exists, skipping
CREATE EXTENSION
Verifying we have all required libraries...

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

sudo: no tty present and no askpass program specified
Resolving dependencies...
Bundler could not find compatible versions for gem
"expression_parser":
  In Gemfile:
wikicloth (= 0.8.1) was resolved to 0.8.1, which
depends on
  expression_parser

  Could not find gem 'expression_parser', which is
  required by gem 'wikicloth (=
  0.8.1)', in any of the sources.
---8<---

I did not expect the *inst package script to "sudo", or for there to be
some note about the minimal sudo permissions I need to allow prior to
installing the package.

I also expected any gems to be installed from a Debian package (instead
of via "Bundler?") as is the case with the majority of the gems this
package requires.

Thanks for your hard work on getting gitlab-ce on Debian!

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'stable'), (850, 
'proposed-updates')
Architecture: amd64 (x86_64)

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

Versions of packages gitlab depends on:
ii  adduser3.113+nmu3
ii  apache2 [httpd]2.4.10-10+deb8u5
ii  apache2-mpm-worker [httpd] 2.4.10-10+deb8u5
ii  asciidoctor1.5.4-1~bpo8+1
ii  bc 1.06.95-9
ii  bundler1.11.2-1~bpo8+1
ii  debconf [debconf-2.0]  1.5.56
ii  exim4-daemon-light [mail-transport-agent]  4.84.2-2+deb8u1
ii  git1:2.9.3-1
ii  gitlab-shell   3.4.0-1
ii  gitlab-workhorse   0.7.2-1
ii  init-system-helpers1.22
ii  libjs-chartjs  1.0.2-1
ii  libjs-clipboard1.4.2-1
ii  libjs-graphael 0.5+dfsg-1
ii  libjs-jquery-cookie10-1
ii  libjs-jquery-history   10-1
ii  libjs-jquery-nicescroll3.6.6-1
ii  nodejs 4.3.1~dfsg-3
ii  openssh-client 1:6.7p1-5+deb8u3
ii  postgresql-client  9.4+165+deb8u1
ii  postgresql-client-9.4 [postgresql-client]  9.4.9-0+deb8u1
ii  postgresql-contrib 9.4+165+deb8u1
ii  rake   10.3.2-2
ii  redis-server   2:2.8.17-1+deb8u5
ii  ruby   1:2.1.5+deb8u2
ii  ruby-ace-rails-ap  4.0.2-1
ii  ruby-activerecord-deprecated-finders   1.0.4-1
ii  ruby-activerecord-session-store1.0.0-1
ii  ruby-acts-as-taggable-on   3.5.0-2
ii  ruby-addressable   2.3.8-1
ii  ruby-after-commit-queue1.3.0-1
ii  ruby-akismet   2.0.0-1
ii  ruby-allocations   1.0.3-1
ii  ruby-asana 0.4.0-1
ii  ruby-attr-encrypted3.0.1-1
ii  ruby-babosa1.0.2-1
ii  ruby-base320.3.2-3
ii  ruby-bootstrap-sass3.3.5.1-3
ii  ruby-browser   2.2.0-1
ii  ruby-cal-heatmap-rails 3.6.0+dfsg-1
ii  ruby-carrierwave   0.10.0+gh-2
ii  ruby-charlock-holmes   0.7.3+dfsg-2
ii  ruby-chronic-duration  0.10.6-1
ii  ruby-coffee-rails  4.1.0-2
ii  ruby-coffee-script-source  1.10.0-1
ii  ruby-connection-pool   2.2.0-1
ii  ruby-creole0.5.0-2
ii  ruby-d3-rails  3.5.6+dfsg-1
ii  ruby-default-value-for 3.0.1-1
ii  ruby-devise

Bug#837959: New version available - 1.7.0

[Michael-John Turner]

Package: dnscrypt-proxy
Version 1.6.1-1
Severity: wishlist

Hi,

A new upstream version of dnscrypt-proxy is available - 1.7.0. It would be
great if the Debian package could be updated to this version.

Source available from https://download.dnscrypt.org/dnscrypt-proxy/

Cheers, MJ
-- 
Michael-John Turner * m...@mjturner.net * http://mjturner.net/

Bug#833634: jessie-pu: package apache2/2.4.10-10+deb8u6

[Stefan Fritsch]

On Thu, 15 Sep 2016, Adam D. Barratt wrote:
> > > If you can get a fix for that uploaded asap then I'll look at getting it
> > > through stable-new in time for Saturday morning.
> > 
> > There has also been a report that the 2.2 -> 2.4 upgrade logic runs even 
> > for 
> > upgrades within s-p-u from 2.4.10-* to 2.4.10-* .  Would you accept a fix 
> > for 
> > that, too?  It's #836818
> 
> I'm afraid it's too late for new fixes for this round, so we'd be
> looking at a further upload for 8.7 in that case. (I'm also assuming the
> code in question has been around for quite some time, and the
> submitter's configuration does seem somewhat designed to produce
> confusion.)

Yes, the issue has been around forever and he was the first who noticed. I 
will include it in the next update, then. Thanks for checking.

Cheers,
Stefan

Bug#833634: jessie-pu: package apache2/2.4.10-10+deb8u6

[Adam D. Barratt]

On Thu, 2016-09-15 at 23:12 +0200, Stefan Fritsch wrote:
> On Thursday, 15 September 2016 19:44:44 CEST Adam D. Barratt wrote:
> > "
> > Configuration file /lib/systemd/system/apache2.service.d/forking.conf is
> > marked executable. Please remove executable permission bits. Proceeding
> > anyway.
> > Failed to read configuration file
> > '/lib/systemd/system/apache2.service.d/forking.conf': Is a directory
> > "
> 
> Sigh. For some reason, systemd on my system does not complain. I can upload a 
> fix shortly.

Julien beat you to that, I'm afraid - it's already in ftp-master's
unchecked queue.

> > If you can get a fix for that uploaded asap then I'll look at getting it
> > through stable-new in time for Saturday morning.
> 
> There has also been a report that the 2.2 -> 2.4 upgrade logic runs even for 
> upgrades within s-p-u from 2.4.10-* to 2.4.10-* .  Would you accept a fix for 
> that, too?  It's #836818

I'm afraid it's too late for new fixes for this round, so we'd be
looking at a further upload for 8.7 in that case. (I'm also assuming the
code in question has been around for quite some time, and the
submitter's configuration does seem somewhat designed to produce
confusion.)

Regards,

Adam

Bug#837804: libatdgen-ocaml-dev: /usr/bin/atdgen missing on alpha, hppa, mips, mips64el, mipsel, ppc64, ppc64el, s390x, sh4, sparc64 and x32

[Johannes Schauer]

Hi,

On Wed, 14 Sep 2016 21:58:46 +0200 Johannes Schauer  wrote:
> the package libatdgen-ocaml-dev does not ship /usr/bin/atdgen on several
> architectures. This makes my source package botch FTBFS on these
> architectures.

while upstream didn't fix this problem yet, we could just install a symlink
from /usr/bin/atdgen to atdgen.run on non-native architectures.

The attached patch implements this.

If you want, I can make an upload with this fix.

Thanks!

cheers, josch
From a4ff3800dee0718b93d3c4b524e4f2f78d130807 Mon Sep 17 00:00:00 2001
From: Johannes Schauer 
Date: Thu, 15 Sep 2016 22:56:18 +0200
Subject: [PATCH] Add symlink from /usr/bin/atdgen to atdgen.run on
 architectures without ocamlopt

---
 debian/changelog  | 8 
 debian/libatdgen-ocaml-dev.install.in | 2 +-
 debian/rules  | 1 +
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 53cd5a4..d1d8e1a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+atdgen (1.9.1-2) unstable; urgency=medium
+
+  * Team upload.
+  * Add symlink from /usr/bin/atdgen to atdgen.run on architectures without
+ocamlopt (closes: #837804)
+
+ -- Johannes Schauer   Thu, 15 Sep 2016 22:52:42 +0200
+
 atdgen (1.9.1-1) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/libatdgen-ocaml-dev.install.in b/debian/libatdgen-ocaml-dev.install.in
index 532d7c0..cffcf66 100644
--- a/debian/libatdgen-ocaml-dev.install.in
+++ b/debian/libatdgen-ocaml-dev.install.in
@@ -5,7 +5,7 @@ OPT: @OCamlStdlibDir@/atdgen/*.o
 OPT: @OCamlStdlibDir@/atdgen/*.cmxa
 OPT: @OCamlStdlibDir@/atdgen/*.a
 OPT: @OCamlStdlibDir@/atdgen/*.cmx
-OPT: /usr/bin/atdgen
+/usr/bin/atdgen
 /usr/bin/atdgen.run
 /usr/bin/atdgen-cppo
 /usr/bin/cppo-json
diff --git a/debian/rules b/debian/rules
index b60392b..141e614 100755
--- a/debian/rules
+++ b/debian/rules
@@ -31,6 +31,7 @@ override_dh_auto_install:
 	mkdir -p '$(DESTDIR)/usr/bin'
 	mkdir -p '$(OCAMLFIND_DESTDIR)'
 	make install 'BINDIR=$(DESTDIR)/usr/bin'
+	test -f $(DESTDIR)/usr/bin/atdgen || ln -s atdgen.run $(DESTDIR)/usr/bin/atdgen
 
 
 .PHONY: override_dh_install
-- 
2.9.3



signature.asc
Description: signature

Bug#833634: jessie-pu: package apache2/2.4.10-10+deb8u6

[Stefan Fritsch]

On Thursday, 15 September 2016 19:44:44 CEST Adam D. Barratt wrote:
> "
> Configuration file /lib/systemd/system/apache2.service.d/forking.conf is
> marked executable. Please remove executable permission bits. Proceeding
> anyway.
> Failed to read configuration file
> '/lib/systemd/system/apache2.service.d/forking.conf': Is a directory
> "

Sigh. For some reason, systemd on my system does not complain. I can upload a 
fix shortly.

> If you can get a fix for that uploaded asap then I'll look at getting it
> through stable-new in time for Saturday morning.

There has also been a report that the 2.2 -> 2.4 upgrade logic runs even for 
upgrades within s-p-u from 2.4.10-* to 2.4.10-* .  Would you accept a fix for 
that, too?  It's #836818

Cheers,
Stefan

Bug#837956: google-android-ndk-installer: [INTL:fr] French debconf translation

[jean-pierre giraud]

Package: google-android-ndk-installer
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege


fr.po.gz
Description: application/gzip

Bug#837958: O: naturaldocs -- extensible, multi-language documentation generator

[Petter Reinholdtsen]

Package: wnpp
Severity: normal

The maintainer of the naturaldocs is busy and asked for his packages to
be orphaned.

-- 
Happy hacking
Petter Reinholdtsen

Bug#833634: jessie-pu: package apache2/2.4.10-10+deb8u6

[Julien Cristau]

On Thu, Sep 15, 2016 at 19:44:44 +0100, Adam D. Barratt wrote:

> On Sat, 2016-09-03 at 19:11 +0100, Adam D. Barratt wrote:
> > Uploaded and flagged for acceptance.
> 
> It was pointed out on IRC that the installation change for forking.conf
> is broken. This:
> 
> +debian/forking.conf  
> /lib/systemd/system/apache2.service.d/forking.conf
> 
> results
> in /lib/systemd/system/apache2.service.d/forking.conf/forking.conf,
> which systemd doesn't like:
> 
> "
> Configuration file /lib/systemd/system/apache2.service.d/forking.conf is
> marked executable. Please remove executable permission bits. Proceeding
> anyway.
> Failed to read configuration file
> '/lib/systemd/system/apache2.service.d/forking.conf': Is a directory
> "
> 
> If you can get a fix for that uploaded asap then I'll look at getting it
> through stable-new in time for Saturday morning.
> 
I'm about to upload with this diff:

diff -Nru apache2-2.4.10/debian/apache2.install 
apache2-2.4.10/debian/apache2.install
--- apache2-2.4.10/debian/apache2.install   2016-08-07 12:56:37.0 
+0200
+++ apache2-2.4.10/debian/apache2.install   2016-09-15 22:41:39.0 
+0200
@@ -5,4 +5,4 @@
 debian/a2query /usr/sbin
 debian/ask-for-passphrase  /usr/share/apache2/
 debian/debhelper/apache2-maintscript-helper/usr/share/apache2/
-debian/forking.conf
/lib/systemd/system/apache2.service.d/forking.conf
+debian/forking.conf
/lib/systemd/system/apache2.service.d
diff -Nru apache2-2.4.10/debian/changelog apache2-2.4.10/debian/changelog
--- apache2-2.4.10/debian/changelog 2016-08-07 13:02:55.0 +0200
+++ apache2-2.4.10/debian/changelog 2016-09-15 22:42:20.0 +0200
@@ -1,3 +1,9 @@
+apache2 (2.4.10-10+deb8u7) jessie; urgency=medium
+
+  * Fix installation of /lib/systemd/system/apache2.service.d/forking.conf.
+
+ -- Julien Cristau   Thu, 15 Sep 2016 22:42:19 +0200
+
 apache2 (2.4.10-10+deb8u6) jessie; urgency=medium
 
   * Fix race condition and logical error in init script. Thanks to Thomas

Cheers,
Julien

Bug#837957: google-android-build-tools-installer: [INTL:fr] French debconf translation

[jean-pierre giraud]

Package: google-android-build-tools-installer
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege


fr.po.gz
Description: application/gzip

Bug#837955: google-android-sdk-docs-installer: [INTL:fr] French debconf translation

[jean-pierre giraud]

Package: google-android-sdk-docs-installer
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege


fr.po.gz
Description: application/gzip

Bug#836917: transition: openmpi

[Julien Cristau]

On Thu, Sep 15, 2016 at 22:21:19 +0200, Sebastiaan Couwenberg wrote:

> Thanks, that did the trick. Let's hope it doesn't get stuck in Uploaded
> state like pnetcdf (I've already emailed ar...@buildd.debian.org about
> that).
> 
pnetcdf poked to reupload.  Please use debian-wb-team rather than the
arch specific alias, you'll reach more people who can fix that sort of
thing this way.

Cheers,
Julien

Bug#837954: O: libnoise -- Portable, coherent noise-generating library for C++

[Petter Reinholdtsen]

Package: wnpp
Severity: normal

The maintainer of the libnoise is busy and asked for his packages to be
orphaned.

-- 
Happy hacking
Petter Reinholdtsen

Bug#837953: ITP: dh-r -- Debhelper support for R packages

[Gordon Ball]

Package: wnpp
Severity: wishlist
Owner: Gordon Ball 

* Package name: dh-r
  Version : 20160901
  Upstream Author : Gordon Ball 
* URL : 
https://anonscm.debian.org/git/debian-science/packages/dh-r.git
* License : MIT
  Programming Lang: Perl, R
  Description : Debhelper support for R packages

This is a debhelper buildsystem for R packages, and a script
to generate debian/ skeletons for new R packages.

It will be maintained within the debian-science team.

Bug#837952: Acknowledgement (icedove: SIGSEGV in gfxShapedText::DetailedGlyphStore::Get)

[Stefan Weil]

Icedove was running in safe mode, without any extensions.

gdb output (stack traces, registers, disassembly) is appended.

MOZILLA_FIVE_HOME=/usr/lib/icedove
  LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove
DISPLAY=:0
DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove
 LIBRARY_PATH=
   SHLIB_PATH=/usr/lib/icedove:/usr/lib/icedove
  LIBPATH=/usr/lib/icedove:/usr/lib/icedove
   ADDON_PATH=
  MOZ_PROGRAM=/usr/lib/icedove/icedove-bin
  MOZ_TOOLKIT=
moz_debug=1
 moz_debugger=
moz_debugger_args=
/usr/bin/gdb  --args /usr/lib/icedove/icedove-bin --safe-mode
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from /usr/lib/debug//usr/lib/icedove/icedove-bin...done.
done.
(gdb) r
Starting program: /usr/lib/icedove/icedove-bin --safe-mode
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/b0/7fd302019b514d7f89c4d611170f2857da7947.debug]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/c6/413377496564262e47f01293586a80ca2cf9da.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/4b/4ee36ff05fd0dba70d4a731857d5dc43a9a8fd.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/53/94c64e472dccc4892a9635f1b07dc01e2b886d.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/80/cbeba6673abc6763f2e70881c175447f532801.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/21/6c37f3bd675f0475c5c3500476183de6d84b00.debug]
[New Thread 0x7fffe587e700 (LWP 30911)]
[Thread 0x7fffe587e700 (LWP 30911) exited]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/22/cfb993ebf3c793b860f77e97592da7a403bf42.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/24/9e3e31976de4980a657c235f304ea42716676d.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/f0/0efd825198fe36939c108183503c92282c3247.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/5c/6776b52b90476102f1534d4881da8321980d31.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/f7/325886428d95bc4d25f675065e6b230dbd1004.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/ec/593fda49d00bccc1803c6c005f505c42154b41.debug]
[New Thread 0x7fffe587e700 (LWP 30913)]
[New Thread 0x7fffde7ff700 (LWP 30914)]
[New Thread 0x77fed700 (LWP 30915)]
[New Thread 0x7fffddffe700 (LWP 30916)]
[New Thread 0x7fffdd4ff700 (LWP 30917)]
[New Thread 0x7fffdd2fe700 (LWP 30918)]
[New Thread 0x7fffdd0fd700 (LWP 30919)]
[New Thread 0x7fffdcefc700 (LWP 30920)]
[New Thread 0x7fffdccfb700 (LWP 30921)]
[New Thread 0x7fffdcafa700 (LWP 30922)]
[New Thread 0x7fffdc8f9700 (LWP 30923)]
[New Thread 0x7fffdc6f8700 (LWP 30924)]
[New Thread 0x7fffdb3ff700 (LWP 30925)]
[New Thread 0x7fffda8ff700 (LWP 30926)]
[New Thread 0x7fffda0fe700 (LWP 30927)]
[New Thread 0x7fffe4e64700 (LWP 30928)]
[New Thread 0x7fffd94ff700 (LWP 30929)]
[New Thread 0x7fffd8169700 (LWP 30930)]
[New Thread 0x7fffd7968700 (LWP 30931)]
[New Thread 0x7fffd53ff700 (LWP 30932)]
[New Thread 0x7fffd3e50700 (LWP 30933)]
[New Thread 0x7fffd364f700 (LWP 30934)]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/ba/3e1a3ec172db43a8c535ad3584c8e495d8.debug]
[New Thread 0x7fffd21ff700 (LWP 30935)]
[New Thread 0x7fffd19fe700 (LWP 30936)]
[New Thread 0x7fffd11fd700 (LWP 30937)]
[New Thread 0x7fffd09fc700 (LWP 30938)]
[New Thread 

Bug#681375: Request for new mailing list: debian-dug-co

[Julián Moreno Patiño]

Hello Alexander,

Any news about it?

Thanks in advance for your help.

Kind regards,

-- 
Julián Moreno Patiño
Debian Developer
 .''`. Debian GNU/{Linux,KfreeBSD}
: :' : Free Operating Systems
`. `'  http://debian.org/
  `-   GPG Fingerprint:
C2C8 904E 314C D8FA 041D 9B00 D5FD FC15 6168 BF60
Registered GNU Linux User ID 488513


signature.asc
Description: PGP signature

Bug#789416: [python-dateutil] New upstream release

[Guido Günther]

Version: python-dateutil/2.4.2-1

Updated now.

On Sat, Jun 20, 2015 at 04:35:51PM -0300, Dererk wrote:
> Package: python-dateutil
> Version: 2.2-2
> Severity: wishlist
> 
> Dear python-dateutil maintainer,
> 
> There has been some recent development around the activity at upstream
> side on reference to dateutil library and version 2.4.2 has been
> released a few months ago.
> 
> Would it be possible for you to upload this new version into the archive?
> 
> 
> 
> Thanks in advance!
> 
> Cheers,
> 
> Dererk
> 
> -- 
> BOFH excuse #246:
> It must have been the lightning storm we had (yesterday) (last week) (last 
> month)
> 
> 

Bug#837952: icedove: SIGSEGV in gfxShapedText::DetailedGlyphStore::Get

[Stefan Weil]

Package: icedove
Version: 1:45.2.0-4+b1
Severity: normal

This is one of the random crashes which happen frequently
(~ 1 crash every 2 days).

I write a new report because it is the first crash in function 
gfxShapedText::DetailedGlyphStore::Get.


gdb output is available.

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'testing'), (500, 'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages icedove depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3+deb8u1
ii  libasound21.0.28-1
ii  libatk1.0-0   2.21.90-2
ii  libc6 2.23-5
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libdbus-1-3   1.10.10-1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3+deb8u1
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:6.1.1-11
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.49.6-1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.4-0 1.4.1-2
ii  libicu57  57.1-4
ii  libnspr4  2:4.12-2
ii  libnss3   2:3.25-1
ii  libpango-1.0-01.40.2-1
ii  libpangocairo-1.0-0   1.40.2-1
ii  libpangoft2-1.0-0 1.40.2-1
ii  libpixman-1-0 0.32.6-3
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.1.1-11
ii  libvpx4   1.6.0-2
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-de-at [hunspell-dictionary]  20131206-5
ii  hunspell-de-ch [hunspell-dictionary]  20131206-5
ii  hunspell-de-de [hunspell-dictionary]  20131206-5
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.2.0-4+b1

Versions of packages icedove suggests:
pn  apparmor  
ii  fonts-lyx 2.1.2-2
ii  libgssapi-krb5-2  1.14.3+dfsg-2

-- no debconf information

Bug#836917: transition: openmpi

[Sebastiaan Couwenberg]

On 09/15/2016 09:41 PM, Emilio Pozuelo Monfort wrote:
> On 15/09/16 21:28, Sebastiaan Couwenberg wrote:
>> On 09/12/2016 05:52 PM, Alastair McKinstry wrote:
>>> mpi4py was also failing to build with openmpi-2.0.1 due to hangs in the
>>> test suite; I've just uploaded 2.0.1-5 which includes a fix for this.
>>> mpi4py will need to be rebuilt (there is an older RC bug due to FTBFS on
>>> 1.10.3, which is now obsolete).
>>
>> I haven't been able to reproduce the dune-grid FTBFS on powerpc, I think
>> the timeout has been fixed with the same change in openmpi (2.0.1-5)
>> which solved the timeout for mpi4py.
>>
>> Can the dune-grid build be retried on powerpc with openmpi (2.0.1-5)? It
>> was built with -3 which did not contain the wait fix.
> 
> Given back.

Thanks, that did the trick. Let's hope it doesn't get stuck in Uploaded
state like pnetcdf (I've already emailed ar...@buildd.debian.org about
that).

Kind Regards,

Bas

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

Bug#837950: dialog FTCBFS: uses build architecture strip

[Santiago Vila]

Thanks for the patch.

If I don't switch to dh, I'll probably apply it "as is" in the next
upload (whenever that will be).

Bug#837951: tcpdump FTCBFS: fails to pass --host to configure

[Helmut Grohne]

Source: tcpdump
Version: 4.7.4-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

tcpdump fails to cross build from source, because it configures the
build for the build architecture. To support cross builds, it needs to
pass --host. The attached patch implements that by replacing the
explicit ./configure invocation with dh_auto_configure, which happens to
know what to pass. Please consider applying the patch.

Helmut
diff --minimal -Nru tcpdump-4.7.4/debian/changelog 
tcpdump-4.7.4/debian/changelog
--- tcpdump-4.7.4/debian/changelog  2016-08-28 18:16:50.0 +0200
+++ tcpdump-4.7.4/debian/changelog  2016-09-15 22:14:25.0 +0200
@@ -1,3 +1,10 @@
+tcpdump (4.7.4-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host (closes: #-1).
+
+ -- Helmut Grohne   Thu, 15 Sep 2016 22:14:06 +0200
+
 tcpdump (4.7.4-2) unstable; urgency=medium
 
   * Disable crypto support as it causes FTBFS with OpenSSL 1.1.x and we
diff --minimal -Nru tcpdump-4.7.4/debian/rules tcpdump-4.7.4/debian/rules
--- tcpdump-4.7.4/debian/rules  2016-08-28 18:16:50.0 +0200
+++ tcpdump-4.7.4/debian/rules  2016-09-15 22:14:04.0 +0200
@@ -8,4 +8,4 @@
 
 override_dh_auto_configure:
autoconf --force
-   ./configure --prefix=/usr --enable-ipv6 --with-crypto=no
+   dh_auto_configure -- --enable-ipv6 --with-crypto=no

Bug#834135: mplayer crashes with SIGSEGV when taking a screenshot

[Antonio Ospite]

Package: mplayer
Version: 2:1.3.0-3
Followup-For: Bug #834135

Dear Maintainer,

The issue has been fixed upstream, see
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2016-June/073497.html

I prepared a patch against the debian package repository to integrate
the fix.

Now I have a package with a working mplayer installed locally, but it
would be great for others if you could upload a new package version with
the fix.

Thanks,
   Antonio

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

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

Versions of packages mplayer depends on:
ii  liba52-0.7.4  0.7.4-18
ii  libaa11.4p5-44
ii  libasound21.1.2-1
ii  libass5   0.13.2-1
ii  libaudio2 1.9.4-5
ii  libavcodec57  7:3.1.3-1+b3
ii  libavformat57 7:3.1.3-1+b3
ii  libavutil55   7:3.1.3-1+b3
ii  libbluray11:0.9.3-2
ii  libbs2b0  3.1.0+dfsg-2.2
ii  libc6 2.24-2
ii  libcaca0  0.99.beta19-2+b1
ii  libcdio-cdda1 0.83-4.2+b1
ii  libcdio-paranoia1 0.83-4.2+b1
ii  libcdio13 0.83-4.2+b1
ii  libdca0   0.0.5-10
ii  libdirectfb-1.2-9 1.2.10.0-5.2+b1
ii  libdv41.0.0-11
ii  libdvdnav45.0.3-1
ii  libdvdread4   5.0.3-1
ii  libenca0  1.19-1
ii  libfaad2  2.8.0~cvs20150510-1
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libfribidi0   0.19.7-1
ii  libgif7   5.1.4-0.3
ii  libgl1-mesa-glx [libgl1]  12.0.2-1
ii  libjack-jackd2-0 [libjack-0.116]  1.9.10+20150825git1ed50c92~dfsg-2
ii  libjpeg62-turbo   1:1.5.0-1
ii  liblircclient00.9.0~pre1-1.2
ii  libmad0   0.15.1b-8
ii  libmpeg2-40.5.1-7
ii  libmpg123-0   1.22.4-1
ii  libogg0   1.3.2-1
ii  libopenal11:1.17.2-2
ii  libpng16-16   1.6.25-1
ii  libpostproc54 7:3.1.3-1+b3
ii  libpulse0 9.0-3
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libsmbclient  2:4.4.5+dfsg-3
ii  libspeex1 1.2~rc1.2-1
ii  libswresample27:3.1.3-1+b3
ii  libswscale4   7:3.1.3-1+b3
ii  libtheora01.1.1+dfsg.1-14
ii  libtinfo5 6.0+20160910-1
ii  libvdpau1 1.1.1-3
ii  libvorbisidec11.0.2+svn18153-0.2
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxss1   1:1.2.2-1
ii  libxv12:1.0.10-1+b1
ii  libxvidcore4  2:1.3.4-1
ii  libxvmc1  2:1.0.9-1
ii  libxxf86dga1  2:1.1.4-1+b1
ii  libxxf86vm1   1:1.1.4-1
ii  zlib1g1:1.2.8.dfsg-2+b1

mplayer recommends no packages.

Versions of packages mplayer suggests:
ii  bzip2   1.0.6-8
ii  fontconfig  2.11.0-6.7
ii  fonts-freefont-ttf  20120503-4
pn  mplayer-doc 
pn  netselect | fping   

-- no debconf information
-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
>From 462f10a73d11367dab08c8c4ffbf28d1c3a144ea Mon Sep 17 00:00:00 2001
From: Antonio Ospite 
Date: Thu, 15 Sep 2016 20:25:57 +0200
Subject: [PATCH] Add mplayer-vf-screenshot-avcodec_open2-fix.patch
X-Face: z*RaLf`X<@C75u6Ig9}{oW$H;1_\2t5)({*|jhM/Vb;]yA5\I~93>J<_`<4)A{':UrE

Gbp-Dch: ignore
---
 debian/changelog  |  8 
 .../mplayer-vf-screenshot-avcodec_open2-fix.patch | 19 +++
 debian/patches/series |  1 +
 3 files changed, 28 insertions(+)
 create mode 100644 debian/patches/mplayer-vf-screenshot-avcodec_open2-fix.patch

diff --git a/debian/changelog b/debian/changelog
index f895d27..80b647e 100644
--- a/debian/changelog
+++ 

Bug#837950: dialog FTCBFS: uses build architecture strip

[Helmut Grohne]

Source: dialog
Version: 1.3-20160828-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

dialog fails to cross build from source, because it runs the build
architecture strip after build. Simply prefixing it with the host
triplet makes the build succeed. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru dialog-1.3-20160828/debian/changelog 
dialog-1.3-20160828/debian/changelog
--- dialog-1.3-20160828/debian/changelog2016-08-29 23:36:10.0 
+0200
+++ dialog-1.3-20160828/debian/changelog2016-09-15 22:07:22.0 
+0200
@@ -1,3 +1,10 @@
+dialog (1.3-20160828-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use triplet prefixed strip. Closes: #-1.
+
+ -- Helmut Grohne   Thu, 15 Sep 2016 22:07:06 +0200
+
 dialog (1.3-20160828-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru dialog-1.3-20160828/debian/rules 
dialog-1.3-20160828/debian/rules
--- dialog-1.3-20160828/debian/rules2016-08-29 22:00:00.0 +0200
+++ dialog-1.3-20160828/debian/rules2016-09-15 22:07:04.0 +0200
@@ -39,8 +39,8 @@
 endif
 
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-  STRIP = strip --remove-section=.comment --remove-section=.note
-  ATRIP = strip --strip-debug
+  STRIP = $(DEB_HOST_GNU_TYPE)-strip --remove-section=.comment 
--remove-section=.note
+  ATRIP = $(DEB_HOST_GNU_TYPE)-strip --strip-debug
 endif
 
 build:

Bug#837944: ocserv should use standalone systemd config to avoid hardcode port

[fishy]

On Thu, Sep 15, 2016 at 1:00 PM Mike Miller  wrote:

> On Thu, Sep 15, 2016 at 19:41:28 +, fishy wrote:
> > I tried /etc/systemd/system/ocserv.socket.d/port.conf trick, looks like
> it
> > adds port to listen, but didn't replace the ports defined in
> > /lib/systemd/system/ocserv.socket:
>
> Sorry, you're right, I forgot these options are cumulative. Assigning
> them to an empty value first in the drop-in file disables the default
> port (see 'man systemd.socket').
>
> Actually tested this time and works for me:
>
>   [Socket]
>   ListenStream=
>   ListenDatagram=
>   ListenStream=12345
>   ListenDatagram=12345
>
> Reorder however you like, as long as the empty assignment comes before
> the new port assignment of the corresponding socket type.
>

Thanks, this works.


>
> Do you think this should be documented in ocserv, maybe README.Debian?
>

Yeah that would be great. Thanks!


>
> --
> mike
>
-- 
fishy

Bug#808802: it seems there is lot of spam on the bug - anyways I got the same when trying to get sources

[shirish शिरीष]

Hi all,

I got the warnings as some of the people above -

[$] sudo apt-get source leafpad

Reading package lists... Done
NOTICE: 'leafpad' packaging is maintained in the 'Git' version control
system at:
https://anonscm.debian.org/collab-maint/leafpad.git
Please use:
git clone https://anonscm.debian.org/collab-maint/leafpad.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 301 kB of source archives.
Get:1 http://mirror.mirohost.net/debian testing/main leafpad
0.8.18.1-5 (dsc) [1,940 B]
Get:2 http://mirror.mirohost.net/debian testing/main leafpad
0.8.18.1-5 (tar) [289 kB]
Get:3 http://mirror.mirohost.net/debian testing/main leafpad
0.8.18.1-5 (diff) [9,636 B]
Fetched 301 kB in 52s (5,741 B/s)
dpkg-source: info: extracting leafpad in leafpad-0.8.18.1
dpkg-source: info: unpacking leafpad_0.8.18.1.orig.tar.gz
dpkg-source: info: unpacking leafpad_0.8.18.1-5.debian.tar.xz
dpkg-source: info: applying 30-fix-desktop-in
dpkg-source: info: applying 20-format-spec.patch
W: Can't drop privileges for downloading as file
'leafpad_0.8.18.1-5.dsc' couldn't be accessed by user '_apt'. -
pkgAcquire::Run (13: Permission denied)

And this is when I'm using sudo .

I tried again, being root this time and trying again but with the same result -

root@debian:/home/shirish/leafpad# apt-get source leafpad
Reading package lists... Done
NOTICE: 'leafpad' packaging is maintained in the 'Git' version control
system at:
https://anonscm.debian.org/collab-maint/leafpad.git
Please use:
git clone https://anonscm.debian.org/collab-maint/leafpad.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 301 kB of source archives.
Get:1 http://debian-mirror.sakura.ne.jp/debian testing/main leafpad
0.8.18.1-5 (dsc) [1,940 B]
Get:2 http://debian-mirror.sakura.ne.jp/debian testing/main leafpad
0.8.18.1-5 (tar) [289 kB]
Get:3 http://debian-mirror.sakura.ne.jp/debian testing/main leafpad
0.8.18.1-5 (diff) [9,636 B]
Fetched 301 kB in 1min 4s (4,646 B/s)
dpkg-source: info: extracting leafpad in leafpad-0.8.18.1
dpkg-source: info: unpacking leafpad_0.8.18.1.orig.tar.gz
dpkg-source: info: unpacking leafpad_0.8.18.1-5.debian.tar.xz
dpkg-source: info: applying 30-fix-desktop-in
dpkg-source: info: applying 20-format-spec.patch
W: Can't drop privileges for downloading as file
'leafpad_0.8.18.1-5.dsc' couldn't be accessed by user '_apt'. -
pkgAcquire::Run (13: Permission denied)

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#837949: ship xorg-wacom.pc in a multiarch location

[Helmut Grohne]

Package: xserver-xorg-input-wacom
Version: 0.30.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gnome-settings-daemon and cinnamon-settings-daemon fail to cross build
from source, because they fail to find xorg-wacom.pc. pkg-config does
not consider /usr/lib/pkgconfig for cross compiling, so the file is not
found. Please move it to a multiarch location. I am proposing the
attached patch to address that.

Helmut
diff -u xf86-input-wacom-0.30.0/debian/changelog 
xf86-input-wacom-0.30.0/debian/changelog
--- xf86-input-wacom-0.30.0/debian/changelog
+++ xf86-input-wacom-0.30.0/debian/changelog
@@ -1,3 +1,10 @@
+xf86-input-wacom (0.30.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move xorg-wacom.pc to a multiarch path.  Closes: #-1
+
+ -- Helmut Grohne   Thu, 15 Sep 2016 21:51:04 +0200
+
 xf86-input-wacom (0.30.0-1) unstable; urgency=medium
 
   * Fixes FTBFS in Stretch due to missing headers needed for fstat(2).
diff -u xf86-input-wacom-0.30.0/debian/rules 
xf86-input-wacom-0.30.0/debian/rules
--- xf86-input-wacom-0.30.0/debian/rules
+++ xf86-input-wacom-0.30.0/debian/rules
@@ -8,8 +8,7 @@
 
 # These are used for cross-compiling and for saving the configure script
 # from having to guess our platform (since we know it already)
-DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
+include /usr/share/dpkg/architecture.mk
 
 
 objdir = objs
@@ -60,6 +59,9 @@
mv debian/$(package)/lib/udev/rules.d/wacom.rules \
   debian/$(package)/lib/udev/rules.d/69-wacom.rules
$(RM) debian/$(package)/usr/lib/xorg/modules/input/*.la
+   mkdir -p debian/$(package)/usr/lib/$(DEB_HOST_MULTIARCH)
+   mv debian/$(package)/usr/lib/pkgconfig \
+   debian/$(package)/usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig
 
echo "xinpdriver:Depends=$(XDEP)" > $(XSUB)
echo "xinpdriver:Provides=xorg-driver-input" >> $(XSUB)

Bug#837944: ocserv should use standalone systemd config to avoid hardcode port

[Mike Miller]

On Thu, Sep 15, 2016 at 19:41:28 +, fishy wrote:
> I tried /etc/systemd/system/ocserv.socket.d/port.conf trick, looks like it
> adds port to listen, but didn't replace the ports defined in
> /lib/systemd/system/ocserv.socket:

Sorry, you're right, I forgot these options are cumulative. Assigning
them to an empty value first in the drop-in file disables the default
port (see 'man systemd.socket').

Actually tested this time and works for me:

  [Socket]
  ListenStream=
  ListenDatagram=
  ListenStream=12345
  ListenDatagram=12345

Reorder however you like, as long as the empty assignment comes before
the new port assignment of the corresponding socket type.

Do you think this should be documented in ocserv, maybe README.Debian?

-- 
mike

Bug#836917: transition: openmpi

[Emilio Pozuelo Monfort]

On 15/09/16 21:28, Sebastiaan Couwenberg wrote:
> On 09/12/2016 05:52 PM, Alastair McKinstry wrote:
>> mpi4py was also failing to build with openmpi-2.0.1 due to hangs in the
>> test suite; I've just uploaded 2.0.1-5 which includes a fix for this.
>> mpi4py will need to be rebuilt (there is an older RC bug due to FTBFS on
>> 1.10.3, which is now obsolete).
> 
> I haven't been able to reproduce the dune-grid FTBFS on powerpc, I think
> the timeout has been fixed with the same change in openmpi (2.0.1-5)
> which solved the timeout for mpi4py.
> 
> Can the dune-grid build be retried on powerpc with openmpi (2.0.1-5)? It
> was built with -3 which did not contain the wait fix.

Given back.

Emilio

Bug#837948: override: gnupg2:oldlibs/extra

[Daniel Kahn Gillmor]

Package: ftp.debian.org
Severity: normal

Hi there--

the gnupg2 source package currently has some overrides on
ftp.debian.org:

gnupg2: Override says utils - optional, .deb says oldlibs - extra
gpgv2: Override says utils - optional, .deb says oldlibs - extra
gnupg: Override says utils - important, .deb says utils - optional

gnupg2 and gpgv2 in unstable are both symlink packages that provide
backward compatibility.  They are in section oldlibs and should be
priority extra.

the gnupg package really should be optional -- it's not a critical
component to a debian system.  gpgv is the critical component (for
verifying software package signatures), and it is still priority
important.

Please revise the overrides file to match the .debs as noted in
2.1.15-3.

Thanks,

--dkg

Bug#837944: ocserv should use standalone systemd config to avoid hardcode port

[fishy]

Thanks, Mike.

I tried /etc/systemd/system/ocserv.socket.d/port.conf trick, looks like it
adds port to listen, but didn't replace the ports defined in
/lib/systemd/system/ocserv.socket:

$ sudo systemctl status ocserv.socket
● ocserv.socket - OpenConnect SSL VPN server Socket
   Loaded: loaded (/lib/systemd/system/ocserv.socket; enabled; vendor
preset: enabled)
  Drop-In: /etc/systemd/system/ocserv.socket.d
   └─port.conf
   Active: failed (Result: resources) since Thu 2016-09-15 12:38:10 PDT;
49s ago
   Listen: [::]:443 (Stream)
   [::]:443 (Datagram)
   [::]:12345 (Stream)
   [::]:12345 (Datagram)

Sep 15 11:30:46 Simpson systemd[1]: Listening on OpenConnect SSL VPN server
Socket.
Sep 15 12:38:10 Simpson systemd[1]: Closed OpenConnect SSL VPN server
Socket.
Sep 15 12:38:22 Simpson systemd[1]: ocserv.socket: Failed to listen on
sockets: Address already in use
Sep 15 12:38:22 Simpson systemd[1]: Failed to listen on OpenConnect SSL VPN
server Socket.
Sep 15 12:38:22 Simpson systemd[1]: ocserv.socket: Unit entered failed
state.
Sep 15 12:38:22 Simpson systemd[1]: ocserv.socket: Failed to listen on
sockets: Address already in use
Sep 15 12:38:22 Simpson systemd[1]: Failed to listen on OpenConnect SSL VPN
server Socket.

On Thu, Sep 15, 2016 at 12:24 PM Mike Miller  wrote:

> On Thu, Sep 15, 2016 at 11:37:24 -0700, Yuxuan Wang wrote:
> > The currect packed ocserv uses socket-activated systemd config[1] from
> > upstream.
> >
> > These config hardcoded the port number (443), ignoring the port number
> > configured in /etc/ocserv/ocserv.conf, and will be overwritten every
> > time the package upgrades. So if the user manually changed the port
> > number, and have another service occupied port 443, upgrade will fail.
> >
> > Upstream also provided another systemd config, standalone[2], which
> > doesn't have this problem and will honor the port defined in
> > /etc/ocserv/ocserv.conf
> >
> > I think this package should use the standalone version of systemd config
> > instead.
>
> On the contarary, customizing the port number used in the
> socket-activated configuration is much easier and less error-prone.
>
> Instead of editing the file /etc/ocserv/ocserv.conf, just create a file
> /etc/systemd/system/ocserv.socket.d/port.conf with the contents
>
>   [Socket]
>   ListenStream=12345
>   ListenDatagram=12345
>
> This file will not be overwritten or replaced, and the custom port
> number will be preserved across upgrades.
>
> This technique is common to any socket-activated service, but may not be
> explicitly docummented in the ocserv package itself.
>
> --
> mike
>
-- 
fishy

Bug#679675: libnss-db: Please multiarchify package

[Matthias Klose]

Control: tags -1 - patch

I don't think the test is complete and tested.

 - you install files for a -common package but install into -bin.
 - you create a dependency libnss-db: libnss-db-bin
 - you move the config file

Bug#836162: diversions for linkers need an update

[Moritz Mühlenhoff]

On Thu, Sep 15, 2016 at 09:10:04PM +0200, Sven Joachim wrote:
> On 2016-09-15 08:14 +0200, Moritz Mühlenhoff wrote:
> 
> > On Wed, Sep 14, 2016 at 10:03:51PM -0700, Kees Cook wrote:
> >> On Thu, Sep 01, 2016 at 05:17:06PM +0200, Moritz Muehlenhoff wrote:
> >> > I think we should remove hardening-wrapper for the stretch release? 
> >> > dpkg-buildflags/dh
> >> > are around for a long time now and we're down to about 50 reverse 
> >> > dependencies at
> >> > this point. Plus, lintian marks it as deprecated for quite a while now.
> >> > 
> >> > Kees, what do you think?
> >> 
> >> Yeah, it (and hardening-includes) should get removed in favor of
> >> the dpkg-buildflags method.  However, this means we need to move the
> >> "hardening-check" script from hardening-includes to lintian, probably.
> >
> > Ack. devscripts might be more appropriate, though.
> 
> That would make lintian depend on devscripts.  I suppose this is not
> really desirable, is it?

True, I was more thinking from the perspective of the "maintainer wants to check
her package for hardened build flags" use case.

Cheers,
Moritz

Bug#837946: aptitude-debug.log

[Marcel Partap]

Forgot this, the line that comes up with `aptitude --log-level=debug` when 
crashing:

> 2016-09-15 21:03:45 [4,139,685,696] problemresolver.h:3,774 DEBUG 
> aptitude.resolver.search - Creating new problem resolver: step_score = -10, 
> broken_score = -100, unfixed_soft_score = -200, infinity = 1,000,000, 
> full_solution_score = 50, future_horizon = 50, initial_state = {} 

Bug#836917: transition: openmpi

[Sebastiaan Couwenberg]

On 09/12/2016 05:52 PM, Alastair McKinstry wrote:
> mpi4py was also failing to build with openmpi-2.0.1 due to hangs in the
> test suite; I've just uploaded 2.0.1-5 which includes a fix for this.
> mpi4py will need to be rebuilt (there is an older RC bug due to FTBFS on
> 1.10.3, which is now obsolete).

I haven't been able to reproduce the dune-grid FTBFS on powerpc, I think
the timeout has been fixed with the same change in openmpi (2.0.1-5)
which solved the timeout for mpi4py.

Can the dune-grid build be retried on powerpc with openmpi (2.0.1-5)? It
was built with -3 which did not contain the wait fix.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#648249: zram script: use one zram device for each CPU

[Jeronimo Pellegrini]

Hello,

I instaled the Ubuntu script, and it works perfectly.

The script that Dmitry Smirnov presented also works, but creates 
only zram0.
The Ubuntu script creates one for each CPU (so that compressing
and decompressing work is spread among them). For an 8-core system,
for example, this may be really nice.

Also, it would be good to have a method not only to turn on zram,
but also to turn it off -- like "service zram stop". And having
"service status zram" available is also great.

And -- having it packaged as Ubuntu does helps make the whole system 
more consistent (using "service  action" for things that
can be turned on, off, enabled at startup is really a good thing, 
IMHO).

J.

Bug#837944: ocserv should use standalone systemd config to avoid hardcode port

[Mike Miller]

On Thu, Sep 15, 2016 at 11:37:24 -0700, Yuxuan Wang wrote:
> The currect packed ocserv uses socket-activated systemd config[1] from
> upstream.
> 
> These config hardcoded the port number (443), ignoring the port number
> configured in /etc/ocserv/ocserv.conf, and will be overwritten every
> time the package upgrades. So if the user manually changed the port
> number, and have another service occupied port 443, upgrade will fail.
> 
> Upstream also provided another systemd config, standalone[2], which
> doesn't have this problem and will honor the port defined in
> /etc/ocserv/ocserv.conf
> 
> I think this package should use the standalone version of systemd config
> instead.

On the contarary, customizing the port number used in the
socket-activated configuration is much easier and less error-prone.

Instead of editing the file /etc/ocserv/ocserv.conf, just create a file
/etc/systemd/system/ocserv.socket.d/port.conf with the contents

  [Socket]
  ListenStream=12345
  ListenDatagram=12345

This file will not be overwritten or replaced, and the custom port
number will be preserved across upgrades.

This technique is common to any socket-activated service, but may not be
explicitly docummented in the ocserv package itself.

-- 
mike

Bug#837920: user-mode-linux should be built directly by src:linux

[Ben Hutchings]

On Thu, 2016-09-15 at 20:55 +0200, Mattia Dongili wrote:
> On Thu, September 15, 2016 7:16 pm, Ben Hutchings wrote:
> ...
> > 
> > 
> > I'm open to the possibility of folding this into src:linux, if someone
> > in (or joining) the kernel team can take responsibility for maintaining
> > it.  Now that all the userland tools are built from src:linux, it might
> > not be that hard to add UML.
> 
> There's a mini-team (Ritesh and me) taking care of UML today.
> What is the expectation for that someone?

Maintain the configuration, investigate and fix build failures, that
sort of thing.

> I'm willing to step forward, but I'm also aware I have limits in my
> availability.
> 
> > 
> > There are a few issues I can immediately see:
> > 
> > - UML binaries can't be built using the existing makefile rules for
> > linux-image packages, as they need different package names,
> > installation paths, and maintainer scripts.  This would need entirely
> > new rules.
> > 
> > - The current base config (debian/config/config) might not make any
> > sense for UML (but then, maybe all the irrelevant stuff will simply be
> > disabled automatically).
> 
> Yes, these both need to be solved. To be fair I haven't had time to look
> into the specifics but that's what's next.
> 
> > 
> > - I'm a little concerned about the possibility of build breakage in UML
> > that would then block everything else built from src:linux.  Does UML
> > break often?
> 
> I haven't been tracking RCs, but stable releases aren't giving many
> problems (a recent one was that then nvram module broke, but that's a case
> of a module that doesn't make sense for UML and shouldn't be enabled to
> start with).
> From looking at the UML upstream mailing lists, there haven't been many
> big breakages in recent times.

Good.  Since we do upload release candidates to experimental, it might
become necessary to fix build failures earlier.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


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

Bug#836162: diversions for linkers need an update

[Sven Joachim]

On 2016-09-15 08:14 +0200, Moritz Mühlenhoff wrote:

> On Wed, Sep 14, 2016 at 10:03:51PM -0700, Kees Cook wrote:
>> On Thu, Sep 01, 2016 at 05:17:06PM +0200, Moritz Muehlenhoff wrote:
>> > I think we should remove hardening-wrapper for the stretch release? 
>> > dpkg-buildflags/dh
>> > are around for a long time now and we're down to about 50 reverse 
>> > dependencies at
>> > this point. Plus, lintian marks it as deprecated for quite a while now.
>> > 
>> > Kees, what do you think?
>> 
>> Yeah, it (and hardening-includes) should get removed in favor of
>> the dpkg-buildflags method.  However, this means we need to move the
>> "hardening-check" script from hardening-includes to lintian, probably.
>
> Ack. devscripts might be more appropriate, though.

That would make lintian depend on devscripts.  I suppose this is not
really desirable, is it?

Cheers,
   Sven

Bug#837947: apt-listchanges seems to ignore DEBIAN_FRONTEND=noninteractive

[Christoph Schulz]

Package: apt-listchanges
Version: 3.4
Severity: normal

I run my updates daily via cron but since the update to 3.3 apt-listchanges 
always shows this warning:

apt-listchanges warning: Cannot reopen /dev/tty for stdin: [Errno 6] Kein 
passendes Gerät bzw. keine passende Adresse gefunden: '/dev/tty'
apt-listchanges: Lese Changelogs...

Says it does not find a apropriate device or address.

The full cron command:

30 19 * * */1 export DEBIAN_FRONTEND=noninteractive; export 
PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH; ~/notify-send-remote.sh christoph 
"Upgrading distro" && apt-get update && apt-get dist-upgrade -y && 
~/notify-send-remote.sh christoph "Finished upgrading distro."

Seem's like it ignoress my DEBIAN_FRONTEND?

Thank you.


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

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

Versions of packages apt-listchanges depends on:
ii  apt1.3~rc4
ii  debconf [debconf-2.0]  1.5.59
ii  debianutils4.8
ii  python3-apt1.1.0~beta5
pn  python3:any
ii  ucf3.0036

apt-listchanges recommends no packages.

Versions of packages apt-listchanges suggests:
ii  chromium [www-browser] 52.0.2743.116-2
ii  exim4-daemon-light [mail-transport-agent]  4.87-3
ii  firefox-esr [www-browser]  45.3.0esr-1
ii  gnome-terminal [x-terminal-emulator]   3.21.90-3
ii  python3-gi 3.21.91-2
ii  w3m [www-browser]  0.5.3-29
ii  xterm [x-terminal-emulator]325-1

-- debconf information:
  apt-listchanges/which: news
  apt-listchanges/confirm: false
  apt-listchanges/email-address: root
  apt-listchanges/frontend: pager
  apt-listchanges/save-seen: true

Bug#837946: aptitude: actions causing »aptitude received signal SIGABRT, Aborted.«

[Marcel Partap]

Package: aptitude
Version: 0.8.2-1+b1
Severity: normal

There is one sole action saved from a previous run:
# ci  kernel linux-image-4.6.0-1-amd64:amd64
"Cancel pending actions" does not deselect actually cancel it, holding the
package does. Either way (action canceled or still pending), when next pressing
'g' to preview, aptitude crashes with:

Thread 1 "aptitude" received signal SIGABRT, Aborted.
0xf776ad09 in __kernel_vsyscall ()
@@gdb> bt
@gdb> #0  0xf776ad09 in __kernel_vsyscall ()
#1  0xf6d08c19 in __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#2  0xf6d0a117 in __GI_abort () at abort.c:89
#3  0x5676f8d9 in subsumes (d2=..., d1=...) at
../../../../src/generic/apt/apt.cc:1182
#4  or_group_subsumes (d1=..., d2=..., cache=) at
../../../../src/generic/apt/apt.cc:1205
#5  0x567715d2 in internal_is_interesting_dep (cache=0x5834cff8, d=...) at
../../../../src/generic/apt/apt.cc:1303
#6  is_interesting_dep (d=..., cache=0x5834cff8) at
../../../../src/generic/apt/apt.cc:1344
#7  0x56794e35 in aptitude_resolver_version::dep_iterator::applicable (dep=...,
prv=..., prv_open=false, cache=0x5834cff8) at
../../../../src/generic/apt/aptitude_resolver_universe.cc:283
#8  0x5678e2aa in aptitude_resolver_version::dep_iterator::applicable
(this=0xffdb1208) at
../../../../src/generic/apt/aptitude_resolver_universe.cc:302
#9  0x5678e389 in aptitude_resolver_version::dep_iterator::normalize
(this=0xffdb1208) at
../../../../src/generic/apt/aptitude_resolver_universe.cc:317
#10 0x5678f665 in aptitude_resolver_version::dep_iterator::operator++
(this=0xffdb1208) at
../../../../src/generic/apt/aptitude_resolver_universe.cc:529
#11 0x5687df87 in aptitude_universe::dep_iterator::operator++ (this=) at ../../../../src/generic/apt/aptitude_resolver_universe.h:1246
#12 generic_problem_resolver::generic_problem_resolver
(this=, _step_score=, _broken_score=, _unfixed_soft_score=, infinity=,
_full_solution_score=, _unfixed_soft_cost=...,
_future_horizon=, _initial_state=..., _universe=...) at
../../../../src/generic/problemresolver/problemresolver.h:3782
#13 0x5686cd0c in aptitude_resolver::aptitude_resolver (this=0x583427c8,
step_score=-10, broken_score=-100, unfixed_soft_score=-200, infinity=100,
resolution_score=50, unfixed_soft_cost=..., future_horizon=50,
_cost_settings=..., initial_installations=..., cache=0x5834cff8,
_policy=0x599b2240) at ../../../../src/generic/apt/aptitude_resolver.cc:731
#14 0x567e7091 in resolver_manager::create_resolver (this=0x5a866730) at
../../../../src/generic/apt/resolver_manager.cc:968
#15 0x567e9373 in resolver_manager::maybe_create_resolver (this=0x5a866730,
consider_policybroken=true) at
../../../../src/generic/apt/resolver_manager.cc:805
#16 0x567e9ce8 in resolver_manager::reset_resolver (this=,
consider_policybroken=) at
../../../../src/generic/apt/resolver_manager.cc:218
#17 0x566c3ba4 in do_package_run () at ../../src/ui.cc:1817
#18 0xf74c745c in cwidget::widgets::widget::handle_key(cwidget::config::key
const&) () from /usr/lib/i386-linux-gnu/libcwidget.so.3
#19 0xf7499b88 in
cwidget::widgets::passthrough::handle_key(cwidget::config::key const&) () from
/usr/lib/i386-linux-gnu/libcwidget.so.3
#20 0xf74cbb3b in cwidget::widgets::widget::dispatch_key(cwidget::config::key
const&) () from /usr/lib/i386-linux-gnu/libcwidget.so.3
#21 0xf747621c in cwidget::widgets::menubar::handle_key(cwidget::config::key
const&) () from /usr/lib/i386-linux-gnu/libcwidget.so.3
#22 0xf74cbb3b in cwidget::widgets::widget::dispatch_key(cwidget::config::key
const&) () from /usr/lib/i386-linux-gnu/libcwidget.so.3
#23 0xf743db51 in cwidget::toplevel::input_thread::get_input_event::dispatch()
() from /usr/lib/i386-linux-gnu/libcwidget.so.3
#24 0xf7434bef in cwidget::toplevel::mainloop(int) () from /usr/lib/i386-linux-
gnu/libcwidget.so.3
#25 0x566c3dae in ui_main () at ../../src/ui.cc:3124
#26 0x565ccf11 in main (argc=, argv=) at
../../src/main.cc:1402

Kinda stuck.
Downgrading to 0.8.2-1+b1 from 0.8.3 (also to install dbg symbols) did not
work. Backtrace is from the former version.



-- Package-specific info:
Terminal: screen-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.2
Compiler: g++ 6.1.1 20160724
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.8.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20160625
  cwidget version: 0.5.17
  Apt version: 5.0.0

aptitude linkage:
linux-gate.so.1 (0xf7794000)
libapt-pkg.so.5.0 => /usr/lib/i386-linux-gnu/libapt-pkg.so.5.0 
(0xf7152000)
libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xf711d000)
libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xf70f9000)
libsigc-2.0.so.0 => /usr/lib/i386-linux-gnu/libsigc-2.0.so.0 
(0xf70f1000)
libcwidget.so.3 => /usr/lib/i386-linux-gnu/libcwidget.so.3 (0xf6fee000)
libsqlite3.so.0 => 

Bug#837945: curl: CVE-2016-7167: escape and unescape integer overflows

[Salvatore Bonaccorso]

Source: curl
Version: 7.26.0-1
Severity: important
Tags: security upstream patch fixed-upstream

Hi,

the following vulnerability was published for curl.

CVE-2016-7167[0]:
curl escape and unescape integer overflows

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-7167
[1] https://curl.haxx.se/docs/adv_20160914.html

Regards,
Salvatore

Bug#837920: user-mode-linux should be built directly by src:linux

[Mattia Dongili]

On Thu, September 15, 2016 7:16 pm, Ben Hutchings wrote:
...
>
> I'm open to the possibility of folding this into src:linux, if someone
> in (or joining) the kernel team can take responsibility for maintaining
> it.  Now that all the userland tools are built from src:linux, it might
> not be that hard to add UML.

There's a mini-team (Ritesh and me) taking care of UML today.
What is the expectation for that someone?
I'm willing to step forward, but I'm also aware I have limits in my
availability.

> There are a few issues I can immediately see:
>
> - UML binaries can't be built using the existing makefile rules for
> linux-image packages, as they need different package names,
> installation paths, and maintainer scripts.  This would need entirely
> new rules.
>
> - The current base config (debian/config/config) might not make any
> sense for UML (but then, maybe all the irrelevant stuff will simply be
> disabled automatically).

Yes, these both need to be solved. To be fair I haven't had time to look
into the specifics but that's what's next.

> - I'm a little concerned about the possibility of build breakage in UML
> that would then block everything else built from src:linux.  Does UML
> break often?

I haven't been tracking RCs, but stable releases aren't giving many
problems (a recent one was that then nvram module broke, but that's a case
of a module that doesn't make sense for UML and shouldn't be enabled to
start with).
>From looking at the UML upstream mailing lists, there haven't been many
big breakages in recent times.

-- 
mattia
:wq!

Bug#833634: jessie-pu: package apache2/2.4.10-10+deb8u6

[Adam D. Barratt]

On Sat, 2016-09-03 at 19:11 +0100, Adam D. Barratt wrote:
> Uploaded and flagged for acceptance.

It was pointed out on IRC that the installation change for forking.conf
is broken. This:

+debian/forking.conf
/lib/systemd/system/apache2.service.d/forking.conf

results
in /lib/systemd/system/apache2.service.d/forking.conf/forking.conf,
which systemd doesn't like:

"
Configuration file /lib/systemd/system/apache2.service.d/forking.conf is
marked executable. Please remove executable permission bits. Proceeding
anyway.
Failed to read configuration file
'/lib/systemd/system/apache2.service.d/forking.conf': Is a directory
"

If you can get a fix for that uploaded asap then I'll look at getting it
through stable-new in time for Saturday morning.

Regards,

Adam

Bug#837810: df and du shows different size

[Андрей Василишин]

lsof | grep -i del | grep /megastorage

shows nothing


You ran it as root?


Yes

Bug#813969: O: eyed

[Gaetano Guerriero]

Il giorno dom, 11/09/2016 alle 19.33 +0200, Petter Reinholdtsen ha
scritto:
> Thank you.  It seem to miss the latest uploads to Debian, see
> https://tracker.debian.org/pkg/eyed3 > for a summary of the
> status
> in Debian at the moment.  Please base your new version on the version
> in
> unstable at the moment.
> 
> Please also check out the bug reports in Debian.  A new version
> should
> close at least one of them in the d/changelog text.
> 
> Another thing, are you in touch with upstream?  The manual page in
> debian/eyeD3.1 should probably be pushed upstream.

I've uploaded a new version addressing, I hope, those issues.   
The new version is rebased on the last debian version in unstable.
Debian patches were removed since no longer needed (more in the
changelog). Changelog now includes "Closes: #"

Regarding the man page, I've composed a new version collecting output
of eyeD3 --help and other documentation of the project: I'll soon write
to upstream to propose merge of this manpage, it is already in the deb.

The url of the upload is still https://mentors.debian.net/package/eyed3


Thank you,

 Gaetano

Bug#793824: plasma-nm: plasma-widget-networkmanager has totally disappeared with plasma-nm 4:5.3.2-1

[Jan Klötzke]

Package: plasma-nm
Version: 4:5.7.4-1
Followup-For: Bug #793824

Dear Maintainer,

I've hit the same bug today when doing a dist-upgrade on my
debian testing installation.

I have created a new user and there it seems to work fine. So the reason
seams to be some old state in my user profile (that I have since KDE3).
Any advice on how to proceed?

Regards,
Jan

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

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

Versions of packages plasma-nm depends on:
ii  libc6   2.23-5
ii  libkf5completion5   5.25.0-1
ii  libkf5configcore5   5.25.0-1
ii  libkf5configwidgets55.25.0-1
ii  libkf5coreaddons5   5.25.0-1
ii  libkf5dbusaddons5   5.25.0-1
ii  libkf5i18n5 5.25.0-1
ii  libkf5iconthemes5   5.25.0-1
ii  libkf5itemviews55.25.0-1
ii  libkf5kdelibs4support5  5.25.0-1
ii  libkf5kiowidgets5   5.25.0-1
ii  libkf5modemmanagerqt6   5.25.0-1
ii  libkf5networkmanagerqt6 5.25.0-1
ii  libkf5notifications55.25.0-1
ii  libkf5service-bin   5.25.0-1
ii  libkf5service5  5.25.0-1
ii  libkf5solid55.25.0-1
ii  libkf5wallet-bin5.25.0-1
ii  libkf5wallet5   5.25.0-1
ii  libkf5widgetsaddons55.25.0-1
ii  libkf5windowsystem5 5.25.0-1
ii  libkf5xmlgui5   5.25.0-1
ii  libopenconnect5 7.06-2+b2
ii  libqca-qt5-22.1.1-2
ii  libqt5core5a5.6.1+dfsg-3+b1
ii  libqt5dbus5 5.6.1+dfsg-3+b1
ii  libqt5gui5  5.6.1+dfsg-3+b1
ii  libqt5network5  5.6.1+dfsg-3+b1
ii  libqt5qml5  5.6.1-7
ii  libqt5widgets5  5.6.1+dfsg-3+b1
ii  libqt5xml5  5.6.1+dfsg-3+b1
ii  libstdc++6  6.1.1-11
ii  mobile-broadband-provider-info  20151214-0.1
ii  network-manager 1.2.4-2
ii  plasma-framework5.25.0-1
ii  qml-module-org-kde-kcoreaddons  5.25.0-1

plasma-nm recommends no packages.

Versions of packages plasma-nm suggests:
pn  network-manager-openconnect  
pn  network-manager-openvpn  
pn  network-manager-pptp 
pn  network-manager-vpnc 

-- no debconf information

Bug#827517: [Pkg-mozext-maintainers] Bug#827517: xul-ext-ublock-origin: Missing icons in uBlock's popup UI

[Evgeny Kapun]

This bug looks similar to bug #819900. That bug was caused by faulty handling 
of symlinks by Firefox, which Mozilla refuses to fix [1].

There is a simple workaround: use an absolute symlink instead of a relative one.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1286634

Bug#837944: ocserv should use standalone systemd config to avoid hardcode port

[Yuxuan Wang]

Package: ocserv
Version: 0.11.4-1+b1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

The currect packed ocserv uses socket-activated systemd config[1] from
upstream.

These config hardcoded the port number (443), ignoring the port number
configured in /etc/ocserv/ocserv.conf, and will be overwritten every
time the package upgrades. So if the user manually changed the port
number, and have another service occupied port 443, upgrade will fail.

Upstream also provided another systemd config, standalone[2], which
doesn't have this problem and will honor the port defined in
/etc/ocserv/ocserv.conf

I think this package should use the standalone version of systemd config
instead.

[1] https://github.com/mtmiller/ocserv/tree/master/doc/systemd/socket-activated
[2] https://github.com/mtmiller/ocserv/tree/master/doc/systemd/standalone


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

Kernel: Linux 4.7.0-1-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: systemd (via /run/systemd/system)

Versions of packages ocserv depends on:
ii  dbus 1.10.10-1
ii  init-system-helpers  1.44
ii  libc62.24-2
ii  libev4   1:4.22-1
ii  libgnutls30  3.5.4-2
ii  libgssapi-krb5-2 1.14.3+dfsg-2
ii  libhttp-parser2.12.1-2
ii  liblz4-1 0.0~r131-2
ii  libnettle6   3.2-1
ii  libnl-3-200  3.2.27-1
ii  libnl-route-3-2003.2.27-1
ii  liboath0 2.6.1-1
ii  libopts251:5.18.10-4
ii  libpam0g 1.1.8-3.3
ii  libpcl1  1.6-1
ii  libprotobuf-c1   1.2.1-1+b1
ii  libradcli4   1.2.6-3
ii  libreadline6 6.3-8+b4
ii  libseccomp2  2.3.1-2
ii  libsystemd0  231-6
ii  libtalloc2   2.1.7-1
ii  libtasn1-6   4.9-4
ii  libwrap0 7.6.q-25
ii  ssl-cert 1.0.38

Versions of packages ocserv recommends:
ii  ca-certificates  20160104

ocserv suggests no packages.

-- Configuration Files:
/etc/ocserv/ocserv.conf changed [not included]

-- no debconf information

Bug#837943: rpl: the fix in version 1.5.5-1.1 need to go into the stable version.

[Simon Clematide]

Package: rpl
Version: 1.5.5-1
Severity: important

Dear Maintainer,

The umlaut in 1.5.5-1 in the info package rpl renders important python 
package management and virtualenv tools (pip, pew) unusable because of the 
UnicodeError raised by a non-utf-8 character in the file 
/usr/lib/pymodules/python2.7/rpl-1.5.5.egg-info. 
See https://github.com/pypa/setuptools/issues/719  or 
http://stackoverflow.com/questions/34440958/cant-run-pip-unicodedecodeerror/34613967
 . The presence of rpl has detrimental side-effect on all python packages that 
process the egg info files of python packages.


   * What led up to the situation? Installing rpl on jessie
   * What was the outcome of this action? Cannot use pip2 or pew anymore
$ pip2
Traceback (most recent call last):
  File "/usr/local/bin/pip2", line 7, in 
from pip import main
  File "/usr/local/lib/python2.7/dist-packages/pip/__init__.py", line 14, in 

from pip.utils import get_installed_distributions, get_prog
  File "/usr/local/lib/python2.7/dist-packages/pip/utils/__init__.py", line 27, 
in 
from pip._vendor import pkg_resources
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 2927, in 
@_call_aside
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 2913, in _call_aside
f(*args, **kwargs)
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 2940, in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 626, in _build_master
ws = cls()
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 619, in __init__
self.add_entry(entry)
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 675, in add_entry
for dist in find_distributions(entry, True):
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 1982, in find_on_path
path_item, entry, metadata, precedence=DEVELOP_DIST
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 2370, in from_location
py_version=py_version, platform=platform, **kw
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 2687, in _reload_version
md_version = _version_from_file(self._get_metadata(self.PKG_INFO))
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 2335, in _version_from_file
line = next(iter(version_lines), '')
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 2503, in _get_metadata
for line in self.get_metadata_lines(name):
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 1873, in get_metadata_lines
return yield_lines(self.get_metadata(name))
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 1863, in get_metadata
metadata = f.read()
  File "/usr/lib/python2.7/codecs.py", line 296, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xb6 in position 147: 
invalid start byte in /usr/lib/pymodules/python2.7/rpl-1.5.5.egg-info
[s

   * What outcome did you expect instead? The package management should not be 
affected by a system package.



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

Kernel: Linux 4.4.15-1-pve (SMP w/32 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 rpl depends on:
ii  python  2.7.9-1
ii  python-support  1.0.15

rpl recommends no packages.

rpl suggests no packages.

-- no debconf information

 

Bug#837839: libtasn1-6: (Future) FTBFS due to undeclared build dependencies

[Andreas Metzler]

On 2016-09-15 Andreas Metzler  wrote:
> On 2016-09-15 bi...@debian.org wrote:
[...]
> Please note that for libtasn1-6 I am not relying on gtk-doc-tools to
> pull in pkg-config because libtasn1-6 requires it. The only thing
> pkg-config is used for is for GTK_DOC_CHECK.

Oi, just realized my test was broken. Time to switch of the computer.

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

[Sean Whitton]

Hello Boyuan,

On Wed, Sep 14, 2016 at 12:23:48PM +0800, Boyuan Yang wrote:
> Yes, they are up-to-date now. The package on debian-mentors is also
> updated.

Thanks.  I'll get to this by Saturday at the latest.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#837839: libtasn1-6: (Future) FTBFS due to undeclared build dependencies

[Andreas Metzler]

On 2016-09-15 bi...@debian.org wrote:
> Source: libtasn1-6
> Version: 4.9-4
> Severity: important
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: gtk-doc-tools

> Hi,

> your package libtasn1-6 declares a build dependency on gtk-doc-tools.
> gtk-doc-tools in turn depends on gnome-common, which in turn pulls in packages
> like gettext, intltool or pkg-config.
[...]
> Please add the required build-dependencies to your package so once we upload
> gtk-doc-tools_1.25-4 to unstable your package doesn't FTBFS.

Hello Michael,

for libtasn1 the cause for the build-error is pkg-config. However I
think that is a gtk-doc-tools needs to add a dep on pkg-config since
GTK_DOC_CHECK requires it. So imho it is pretty much a hard dependency.

Please note that for libtasn1-6 I am not relying on gtk-doc-tools to
pull in pkg-config because libtasn1-6 requires it. The only thing
pkg-config is used for is for GTK_DOC_CHECK.

I have already submitted a report against gtk-doc-tools because I missed
the explicit mention of pkg-config in your report. Sorry for that.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#837942: gtk-doc-tools: Missing dependency on pkg-config

[Andreas Metzler]

Package: gtk-doc-tools
Version: 1.25-4
Severity: serious

gtk-doc-tools in experimental is lacking a dependency on pkg-config,
GTK_DOC_CHECK will fail if it is missing.

---
AC_DEFUN([GTK_DOC_CHECK],
[
  AC_REQUIRE([PKG_PROG_PKG_CONFIG])
---

This only applies to experimental, sid fullfils this via the gnome-core
dependency.

cu Andreas 
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#837940: gnome-twitch-player-backend-mpv-opengl: immediate segmentation fault

[Jonas Smedegaard]

Package: gnome-twitch-player-backend-mpv-opengl
Version: 0.3.0-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Selecting mpv backend immediately causes segmentation fault.

 - Jonas

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

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

Versions of packages gnome-twitch-player-backend-mpv-opengl depends on:
ii  gnome-twitch   0.3.0-1
ii  libc6  2.24-2
ii  libepoxy0  1.3.1-1
ii  libglib2.0-0   2.49.7-1
ii  libgtk-3-0 3.21.6-1
ii  libmpv10.20.0-1+b1
ii  libpeas-1.0-0  1.18.0-3

gnome-twitch-player-backend-mpv-opengl recommends no packages.

gnome-twitch-player-backend-mpv-opengl suggests no packages.

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJX2uFMAAoJECx8MUbBoAEh1cMQAIagMFykMcn5Ko+uHuIIzv2O
oNUA5V8Ymfordx6CWTziYqVJW5aQ6ztDJubrfh/SZ/fNHLFhCoG0CvYPOFJLTf4X
fO8YdTN83c2skZJUAo9lChyjnlhuwfjwUXMyp1JNmgbKz81QdxVL9J3CtsH42mwd
nolJy/F/jLFeTAomnOJHKZ1myUpAvpBliEx9o/eAO37Vn9xMhnJPp49FqZGfawov
tBJkF4PWCrRcJjZibo30ccHCuZgHB5cF5NrpNuspKMOkGyRopeAh8eU3TM2jo27e
EFlpxpvXT3dCwYIk+Gz7f6XxH4LNGhYlRYGiuyXzwYH4BMeJG4fpbXFgaWUMcNFU
uRJWwNmWsCLvyG9kL0v3UDt1dJC7OHoChyAKCUoPGDEd3Jju7iH/fvttu7pdfxYQ
TWp/Wa2sAPdY/VH1OLB81K9Nst4K98dLhHZD2SKJa15T9GKpAyY0wpmCJYJJIuda
5pZf0tPKk/gsi4diIS7/bJ6IhqzGIxCZCW7zqyG+9xsGo0czZ6S4J4WdgsoxTutf
iN6/tl0nMZU34M+aBN8GXMotxWH73zlWem9V92Pmx2eznEjszNzGMc958LNXOOyT
PdT9Si5Nb21/xgwbepwm78pnFmCK2ZII2tVtOMyDxpI5HNyoRM9JJhTZW1n91jeY
CCCZwUy2VluFKXjREvFt
=s4zL
-END PGP SIGNATURE-

Bug#809832: base: fails to inser modules ext2 or ext3

[Santiago Vila]

On Thu, Sep 15, 2016 at 02:17:08PM -0300, Mario Pereyra wrote:

> I'll check this on a new debian 7 installation with all updates installed
> and let you know the result.
> 
> This will be in a few weeks.

Well, if you can't afford reinstalling linux-image-* and perform a
reboot because it's a super-important server (or you are just several
kilometers away from it), that's ok.

But please note that the debsums test is harmless and you can do it
without risk.

More to the point, if you are not applying security updates to your
running system, maybe you should!

Thanks.

Bug#837939: ITP: ruby-ffaker -- Ffaker generates dummy data

[Pirate Praveen]

package: wnpp
severity: wishlist
owner: Pirate Praveen 

from https://rubygems.org/gems/ffaker
dependency for gitlab 8.11.3 tests

















signature.asc
Description: OpenPGP digital signature

Bug#831240: google-perftools: FTBFS: Running death test 0 hangs

[Santiago Vila]

Hello.

This package is still a headache for my autobuilder.

On Tue, 19 Jul 2016, Lucas Nussbaum wrote:

> Indeed it was the equivalent of dpkg-buildpackage -A that
> triggered it.

Do you mean you could always reproduce with "dpkg-buildpackage -A"
and never with "dpkg-buildpackage"?

Later you said:

> [ sysctl tunings ]
> It seems that one of those caused that failure, because, now that I have
> them disabled, it does not fail anymore.

Are you sure that removing those settings is the real reason it stopped
failing for you? (Would you try a few more times?)

It still fails for me, randomly, and I'm not using EC2 but KVM on my
own server and KVM on a commercial provider, so my alternate theory is
that it was random before you dropped the settings, and it continues
to be random after dropping the settings.

This is my historic data:

Status: failed  google-perftools_2.2.1-0.2_amd64-20151025T1748Z
Status: failed  google-perftools_2.2.1-0.2_amd64-20151201T1848Z
Status: failed  google-perftools_2.2.1-0.2_amd64-20151220T1430Z
Status: failed  google-perftools_2.2.1-0.2_amd64-20160101T2221Z
Status: failed  google-perftools_2.2.1-0.2_amd64-20160507T1523Z
Status: failed  google-perftools_2.2.1-0.2_amd64-20160507T1649Z
Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T055103Z
Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T150752Z
Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T151026Z
Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T151114Z
Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T161241Z
Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T151357Z
Status: successful  google-perftools_2.2.1-0.3_amd64-20160914T161322Z
Status: successful  google-perftools_2.2.1-0.3_amd64-20160914T161612Z
Status: successful  google-perftools_2.2.1-0.3_amd64-20160914T161656Z
Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T161654Z
Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T161043Z


Version 2.2.1-0.3 is the first one that does not *always* fail for me.
This is a great achievement indeed.

Now it builds sometimes, but 3/11 is not a very good ratio.

Is the Debian maintainer alive?

Bug#837681: debug output (Re: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs)

[HW42]

Holger Levsen:
> On Thu, Sep 15, 2016 at 04:38:00PM +, HW42 wrote:
>>> 3.16.0-4-amd64 is the kernel (so jessie standard), and the host this is
>>> running on is a profitbricks VM, so running on kvm.
>> I assume you have this kernel only installed on the VM not the chroot.
>> So try installing linux-image-amd64 _inside_ the chroot.
> 
> the problem is, that this is a sid chroot, so linux-image would have
> version 4.7.2, while the host has 3.16…

I don't think this mismatch is a problem.



signature.asc
Description: OpenPGP digital signature

Bug#837681: debug output (Re: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs)

[Holger Levsen]

On Thu, Sep 15, 2016 at 04:38:00PM +, HW42 wrote:
> > 3.16.0-4-amd64 is the kernel (so jessie standard), and the host this is
> > running on is a profitbricks VM, so running on kvm.
> I assume you have this kernel only installed on the VM not the chroot.
> So try installing linux-image-amd64 _inside_ the chroot.

the problem is, that this is a sid chroot, so linux-image would have
version 4.7.2, while the host has 3.16…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#837938: move the hardening-check script from hardening-includes to devscripts

[Matthias Klose]

Package: hardening-includes,devscripts
Severity: important

As discussed in #836162, the hardening-check script from hardening-includes
should be shipped by the devscripts package with proper Breaks/Replaces.

hardening-includes is currently not installable, therefore the important 
severity.

Bug#837700: gnutls: GNUTLS segfaults on initialization

[Andreas Metzler]

Control: tags -1 unreproducible
Control: severity -1 important

On 2016-09-14 J Phelps  wrote:
>>Can you provide a (simple) way to reproduce the issue?

> Reproduction was simple on my machine: Just try to run Chromium 53.0.2785.92,
> which depends on libgnutls30. It crashed immediately.

Works for me. :-(

> I had just upgraded from a much older version of Chromium (in the 30s IIRC)
> using Aptitude.

> Running it under GDB showed that the segfault happened in Nettle.

>> Your diagnosis cannot be completely correct. e.g. libgnutls30
>> 3.5.4-2 on i386 (which you reported the issue against) was built against
>> nettle-dev i386 3.2-1 which continues to be the latest version of nettle
>> available in Debian. So you cannot experience a breakage in Debian
>> caused by the Debian-installed nettle version being newer and having a
>> different ABI than the version GnuTLS was built against.

> I think that the binary in the .deb package was compiled from a different
> Nettle source than the one that you find in the corresponding .dsc package.

I am pretty sure that is not true. For that to happen some Debian
developer would have needed to make a manual build and upload.

> Otherwise, compiling the .dsc package should have given me a binary
> that was compatible with the one that was already installed on my
> system.

> Instead, I had unresolved symbols (I don't remember which ones),

Can you reproduce this and show the exact error message?

> and I had
> to go to Nettle's Git repository (https://git.lysator.liu.se/nettle/nettle)
> to find source code that could produce a linkable library. The symbols
> that were unresolved were only found in the "ecc-support" branch of that
> repo. Compiling from the trunk led to the same symbols being unresolved.
[...]

I strongly suspect a local issue, e.g. locally built old version of
gnutls or nettle in /usr/local. "ldd  /usr/lib/chromium/chromium" might
point in the right direction.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#836162: gcc-6 diversion updates now needed as well

[Matthias Klose]

Control: retitle -1 diversions for linkers and gcc-6 need an update

gcc-6 6.2.0-4 now ships the triplet prefixed names as files, and the unprefixed
names as symlinks.  The hardening-wrapper diversions need an update.

Bug#837937: ITP: ruby-email-spec --easily test email in rspec and cucumber and minitest

[Pirate Praveen]

package: wnpp
severity: wishlist
owner: Pirate Praveen 

from https://rubygems.org/gems/email_spec
dependency for gitlab 8.11.3 tests















signature.asc
Description: OpenPGP digital signature

Bug#809832: base: fails to inser modules ext2 or ext3

[Mario Pereyra]

Thanks Santiago,

I'll check this on a new debian 7 installation with all updates 
installed and let you know the result.


This will be in a few weeks.


BR

Mario Pereyra
SecureTech A
+598 2900-6836 Tel
+598 2900-7526 Tel/Fax
b...@securetech.com.uy
Wilson F. Aldunate 1294 Of. 302
Montevideo CP 11100 - Uruguay
www.securetech.com.uy

On 15/09/16 09:59, Santiago Vila wrote:

On Thu, Sep 15, 2016 at 09:05:52AM -0300, Mario Pereyra wrote:


The file "/lib/modules/3.2.0-4-amd64/kernel/fs/ext2/ext2.ko"
is present (exist) in the file system and is a module file (as
you can see in insmod command).

If the file does not exist, the response from insmod command
is other (Error: could not load module ...: No such file or directory).
But in this case this message is not present, otherwise the message
is from libkmod and is stating it is failing to inset the module.

As you say, the message is stating (and I understand it correctly)
that the file is not in the file system, but that is not true.

I can't reproduce what you reported in a newly installed Debian 7
system.

# modprobe -vv ext2
insmod /lib/modules/3.2.0-4-amd64/kernel/fs/ext2/ext2.ko
libkmod: INFO ../libkmod/libkmod.c:319 kmod_unref: context
0x7f713d6d51d0 released

Can you reproduce it in a newly installed Debian 7 system?


My guess is that the file is there but it's corrupted for whatever
reason, and that's why insmod can't load the module (I can agree that
the error message may be a little bit misleading).

You can check this easily:

# apt-get install debsums
# debsums linux-image-3.2.0-4-amd64 | grep ext2

and it should say this:

/lib/modules/3.2.0-4-amd64/kernel/fs/ext2/ext2.ko OK

If it says this instead:

/lib/modules/3.2.0-4-amd64/kernel/fs/ext2/ext2.ko FAILED

then you should definitely reinstall the package containing ext2.ko:

# dpkg -S /lib/modules/3.2.0-4-amd64/kernel/fs/ext2/ext2.ko
linux-image-3.2.0-4-amd64:
/lib/modules/3.2.0-4-amd64/kernel/fs/ext2/ext2.ko
# apt-get --reinstall install linux-image-3.2.0-4-amd64


If reinstalling linux-image-3.2.0-4-amd64 does not solve the problem,
please try asking in debian-user, I'm just a random Debian maintainer
who happened to take a look at bugs reported against "base".

Thanks.