Bug#868473: dh-acc: Incorrect usage of doit (Dh_Lib)

[Gianfranco Costamagna]

On Thu, 31 Aug 2017 08:07:45 -0400 Jeremy Bicha  wrote:
> This bug is still unfixed in Debian right? It makes debci less useful
> for packages that use dh-acc.
> 

you are right

the following debdiff is going in unstable *right now*

(I also took the gcc fixes from Ubuntu)

thanks!

G.
> Thanks,
> Jeremy Bicha
> 
> 
diff -Nru abi-compliance-checker-1.99.22/debian/changelog 
abi-compliance-checker-1.99.22/debian/changelog
--- abi-compliance-checker-1.99.22/debian/changelog 2016-07-16 
21:24:13.0 +0200
+++ abi-compliance-checker-1.99.22/debian/changelog 2017-09-01 
07:51:53.0 +0200
@@ -1,3 +1,16 @@
+abi-compliance-checker (1.99.22-1.1) unstable; urgency=high
+
+  [ Dmitry Shachnev ]
+  * Add a patch to fix tests compilation with new GCC.
+  * Add a patch to not rely on GCC for symbols mangling, it is not working
+with GCC 6 and GCC 7 because of PR c++/78040.
+
+  [ Gianfranco Costamagna ]
+  * Non-maintainer upload
+  * Fix autopkgtests, due to bad doit call (Closes: #868473)
+
+ -- Gianfranco Costamagna   Fri, 01 Sep 2017 
07:51:53 +0200
+
 abi-compliance-checker (1.99.22-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru abi-compliance-checker-1.99.22/debian/dh/dh_acc 
abi-compliance-checker-1.99.22/debian/dh/dh_acc
--- abi-compliance-checker-1.99.22/debian/dh/dh_acc 2016-07-16 
21:23:50.0 +0200
+++ abi-compliance-checker-1.99.22/debian/dh/dh_acc 2017-09-01 
07:51:12.0 +0200
@@ -56,11 +56,11 @@
 
if ($definition) {
# TODO if next command fails, should output debug/log info?
-   doit("abi-compliance-checker -q -l $package -v1 $version -dump 
$definition -dump-path $abidump");
+   doit('abi-compliance-checker', '-q', '-l', $package, '-v1', 
$version, '-dump', $definition, '-dump-path', $abidump);
}
if ($base) {
-   doit("abi-compliance-checker -l $package -d1 $base -d2 $abidump 
-report-path ${path}_report.html");
-   doit("abi-compliance-checker -q -l $package -d1 $base -d2 $abidump 
-xml -report-path ${path}_report.xml");
+   doit('abi-compliance-checker', '-l', $package, '-d1', $base, '-d2', 
$abidump, '-report-path', ${path}.'_report.html');
+   doit('abi-compliance-checker', '-q', '-l', $package, '-d1', $base, 
'-d2', $abidump, '-xml', '-report-path', ${path}.'_report.xml');
}
# TODO clean up temp files & logs
 }
diff -Nru abi-compliance-checker-1.99.22/debian/patches/emergency-mode.patch 
abi-compliance-checker-1.99.22/debian/patches/emergency-mode.patch
--- abi-compliance-checker-1.99.22/debian/patches/emergency-mode.patch  
1970-01-01 01:00:00.0 +0100
+++ abi-compliance-checker-1.99.22/debian/patches/emergency-mode.patch  
2017-09-01 07:51:12.0 +0200
@@ -0,0 +1,27 @@
+Description: enable emergency mode for newer GCC versions too, not only 4.8
+ GCC 6 and newer do not mangle symbols, see 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78040.
+Author: Dmitry Shachnev 
+Bug: https://github.com/lvc/abi-compliance-checker/issues/62
+Forwarded: no
+Last-Update: 2017-08-13
+
+--- a/abi-compliance-checker.pl
 b/abi-compliance-checker.pl
+@@ -4939,7 +4939,7 @@
+ # try to mangle symbol
+ if((not check_gcc($GCC_PATH, "4") and 
$SymbolInfo{$Version}{$InfoId}{"Class"})
+ or (check_gcc($GCC_PATH, "4") and not 
$SymbolInfo{$Version}{$InfoId}{"Class"})
+-or $EMERGENCY_MODE_48)
++or true)
+ { # GCC 3.x doesn't mangle class methods names in the TU dump (only 
functions and global data)
+   # GCC 4.x doesn't mangle C++ functions in the TU dump (only class 
methods) except extern "C" functions
+   # GCC 4.8.[012] doesn't mangle anything
+@@ -4951,7 +4951,7 @@
+ }
+ if($CheckHeadersOnly
+ or not $BinaryOnly
+-or $EMERGENCY_MODE_48)
++or true)
+ { # 1. --headers-only mode
+   # 2. not mangled src-only symbols
+ if(my $Mangled = mangle_symbol($InfoId, $Version, "GCC")) {
diff -Nru 
abi-compliance-checker-1.99.22/debian/patches/fix-test-compilation.patch 
abi-compliance-checker-1.99.22/debian/patches/fix-test-compilation.patch
--- abi-compliance-checker-1.99.22/debian/patches/fix-test-compilation.patch
1970-01-01 01:00:00.0 +0100
+++ abi-compliance-checker-1.99.22/debian/patches/fix-test-compilation.patch
2017-09-01 07:51:12.0 +0200
@@ -0,0 +1,17 @@
+Description: fix test compilation with new GCC
+ The implicit constructor is implicitly deleted because the const
+ member is not initialized. So we have to use an explicit one.
+Author: Dmitry Shachnev 
+Forwarded: no (this test is disabled upstream)
+Last-Update: 2017-08-13
+
+--- a/modules/Internals/RegTests.pm
 b/modules/Internals/RegTests.pm
+@@ -81,6 +81,7 @@
+ T array[_P];
+ typedef int My;
+ My var;
++ChangedTemplate(): 

Bug#873906: ruby2.3: CVE-2017-14064

[Salvatore Bonaccorso]

Source: ruby2.3
Version: 2.3.3-1
Severity: grave
Tags: upstream patch security

Hi,

the following vulnerability was published for ruby2.3.

CVE-2017-14064[0]:
| Ruby through 2.2.7, 2.3.x through 2.3.4, and 2.4.x through 2.4.1 can
| expose arbitrary memory during a JSON.generate call. The issues lies in
| using strdup in ext/json/ext/generator/generator.c, which will stop
| after encountering a '\0' byte, returning a pointer to a string of
| length zero, which is not the length stored in space_len.

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-2017-14064
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14064
[1] https://bugs.ruby-lang.org/issues/13853
[2] 
https://github.com/flori/json/commit/8f782fd8e181d9cfe9387ded43a5ca9692266b85

Regards,
Salvatore

Bug#873905: ufw: adequate shows obsolete conffile with ufw

[shirish शिरीष]

Package: ufw
Version: 0.35-4
Severity: normal

Dear Maintainer,

Thank you for maintaining ufw. I just updated today and adequate shows
the following -

$  adequate ufw
[100%]
ufw: obsolete-conffile /etc/bash_completion.d/ufw

Please fix the same.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages ufw depends on:
ii  debconf  1.5.63
ii  init-system-helpers  1.48
ii  iptables 1.6.1-2
ii  lsb-base 9.20161125
ii  python3  3.5.3-3
ii  ucf  3.0036

ufw recommends no packages.

Versions of packages ufw suggests:
ii  rsyslog  8.28.0-1

-- debconf information excluded


-- 
  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#873904: libidn2-0: CVE-2017-14061: integer overflow in _isBidi function

[Salvatore Bonaccorso]

Source: libidn2-0
Version: 2.0.2-3
Severity: important
Tags: upstream security patch

Hi,

the following vulnerability was published for libidn2-0, please
double-check.

CVE-2017-14061[0]:
| Integer overflow in the _isBidi function in bidi.c in Libidn2 before
| 2.0.4 allows remote attackers to cause a denial of service or possibly
| have unspecified other impact.

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-2017-14061
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14061
[1] 
https://gitlab.com/libidn/libidn2/commit/16853b6973a1e72fee2b7cccda85472cb9951305

Please adjust the affected versions in the BTS as needed, not sure
about older versions than the one in testing/unstable.

Regards,
Salvatore

Bug#873902: libidn2-0: CVE-2017-14062: integer overflow in decode_digit

[Salvatore Bonaccorso]

Hi libidn team,

On Fri, Sep 01, 2017 at 06:52:53AM +0200, Salvatore Bonaccorso wrote:
> CVE-2017-14062[0]:
> | Integer overflow in the decode_digit function in puny_decode.c in
> | Libidn2 before 2.0.4 allows remote attackers to cause a denial of
> | service or possibly have unspecified other impact.

Unless mistaken I think this goes back to all libidn2-0 versions to
jessie and affects as well src:libidn. I cloned the bug and
reassigned, but let me please know if I oversee something.

Regards,
Salvatore

Bug#873801: node-babel FTBFS without network access

[Pirate Praveen]

Control: severity -1 normal

On Thu, 31 Aug 2017 12:07:37 +0200 Graham Inggs  wrote:
> Node-babel fails to build on a machine without external network access:

This package is in contrib and not main.

"The contrib archive area contains supplemental packages intended to
work with the Debian distribution, but which require software outside of
the distribution to either build or function."

https://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib

It requires packages from npmjs.com to build.

But this is a temporary arrangement to bootstrap as it has a circular
dependency on node-babylon.



signature.asc
Description: OpenPGP digital signature

Bug#515856: [debhelper-devel] Bug#515856: debhelper: please implement dh get-orig-source

[Helmut Grohne]

Control: reassign -1 debian-policy
Control: retitle -1 remove get-orig-source
Control: tags -1 = patch

Dear policy maintainers,

I believe that we should remove get-orig-source from the Debian policy
for the following reasons.

According to codesearch.d.n, get-orig-source is implemented by less than
3000 source packages. This is not very low, but neither a high adoption
rate. It certainly makes using get-orig-source somewhat useless on a
distribution-scale. In contrast, we have some 22500 watch files, an
order of magnitude more. I think it is obvious which mechanism has won.

On Thu, Aug 31, 2017 at 04:34:00PM +, Niels Thykier wrote:
> I am not convinced get-orig-source is well-defined enough that dh can do
> something useful here.

This issue is coming up repeatedly as well. The major concerns raised in
other bug reports (e.g. #466550 or #873001) are:

 * The requirement that get-orig-source may be invoked from any
   directory is difficult to fulfil and often times not implemented. A
   lot of packages (of the 3000 above) simply defer to uscan violating
   it.

 * It is not clear whether the most recent upstream version or the
   currently packaged version should be downloaded.

 * It is not clear where required tools should be declared.

 * The relevance of releases shrinks as upstreams move to distribution
   via VCS exclusively.

It is clear the vagueness of get-orig-source has caused significant work
on debian-mentors for trying to implement it properly. This raises the
bar to packaging in a way that I do not consider a useful use of
mentee's time.

This is why Niels Thykier refused to implement get-orig-source in
debhelper:

> Finally, it is not even clear to me that dh can implement this as you
> need the makefile to determine the package directory and it is probably
> only available in make (if you don't explicitly export it).

I believe that if debhelper is not going to support us in increasing
get-orig-source adoption, then we should just stop doing it and move on
to watch files.

I am attaching the removal patch and call for seconds.

Helmut
diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index f706a13..27c49b5 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -368,19 +368,6 @@ The targets are as follows:
 Instead, the upstream source should be repacked to remove those
 files.
 
-``get-orig-source`` (optional)
-This target fetches the most recent version of the original source
-package from a canonical archive site (via FTP or WWW, for example),
-does any necessary rearrangement to turn it into the original source
-tar file format described below, and leaves it in the current
-directory.
-
-This target may be invoked in any directory, and should take care to
-clean up any temporary files it may have left.
-
-This target is optional, but providing it if possible is a good
-idea.
-
 ``patch`` (optional)
 This target performs whatever additional actions are required to
 make the source ready for editing (unpacking additional upstream

Bug#858005: postfixadmin: upgrade.php fails at various places because of too long indexes

[Gabriel Filion]

Hi there!

I've replicated the issue when running setup.php right after an
installation of postfixadmin.

Then I've applied the patch linked to by Jascha and I can confirm that
it does solve the issue. With the patch applied, the setup.php script
calls upgrade.php and successfully creates the database.



signature.asc
Description: OpenPGP digital signature

Bug#873902: libidn2-0: CVE-2017-14062: integer overflow in decode_digit

[Salvatore Bonaccorso]

Source: libidn2-0
Version: 0.10-2
Severity: important
Tags: upstream security patch

Hi,

the following vulnerability was published for libidn2-0.

CVE-2017-14062[0]:
| Integer overflow in the decode_digit function in puny_decode.c in
| Libidn2 before 2.0.4 allows remote attackers to cause a denial of
| service or possibly have unspecified other impact.

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-2017-14062
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14062
[1] 
https://gitlab.com/libidn/libidn2/commit/3284eb342cd0ed1a18786e3fcdf0cdd7e76676bd

Regards,
Salvatore

Bug#873901: fonts-tlwg-waree: Adequate shows obsolete conffile for fonts-tlwg-waree

[shirish शिरीष]

Package: fonts-tlwg-waree
Version: 1:0.6.3-2
Severity: normal

Dear Maintainer,
 Thank you for maintaining fonts-tlwg-waree. However, adequte reports
obsolete conffile for fonts-tlwg-waree. Please fix/remove the same.

$  adequate fonts-tlwg-waree
[100%]
fonts-tlwg-waree: obsolete-conffile
/etc/fonts/conf.avail/89-tlwg-waree-synthetic.conf


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages fonts-tlwg-waree depends on:
ii  fonts-tlwg-waree-ttf  1:0.6.3-2

fonts-tlwg-waree recommends no packages.

fonts-tlwg-waree suggests no packages.

-- 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#873900: fonts-tlwg-loma: adequate shows fonts-tlwg-loma having obsolete conffiles

[shirish शिरीष]

Package: fonts-tlwg-loma
Version: 1:0.6.3-2
Severity: normal

Dear Maintainer,
   Thank you for maintaining fonts-tlwg-loma. adequate shows
fonts-tlwg-loma having obsolete conffiles .

$ adequate fonts-tlwg-loma
   [100%]
fonts-tlwg-loma: obsolete-conffile
/etc/fonts/conf.avail/89-tlwg-loma-synthetic.conf
fonts-tlwg-loma: obsolete-conffile /etc/fonts/conf.avail/64-12-tlwg-loma.conf

Please fix/remove the two obsolete conffiles.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages fonts-tlwg-loma depends on:
ii  fonts-tlwg-loma-ttf  1:0.6.3-2

fonts-tlwg-loma recommends no packages.

fonts-tlwg-loma suggests no packages.

-- 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#873828: maven-compiler-plugin FTBFS: artifact org.codehaus.plexus:plexus-component-annotations:jar:debian has not been downloaded

[Emmanuel Bourg]

Control: reassign -1 libmaven-plugin-tools-java
Control: affects -1 maven-compiler-plugin

Thank you for the report Adrian. This is an issue with
libmaven-plugin-tools-java and all reverse dependencies are potentially
affected. No need to report other issues like this one immediately if
you find more.

Emmanuel Bourg

Bug#871697: jellyfish: Please add arm64

[Andreas Tille]

control: reopen -1

Hi Edmund,

On Thu, Aug 31, 2017 at 10:24:39PM +0100, Edmund Grimley Evans wrote:
> > Sorry, but this patch does not apply.  You have recommended a change
> > of the *original* code.  That's no proper quilt patch.
> 
> Indeed. Here's another attempt.

unfortunately the bug does not seem to be sufficient.  See


https://buildd.debian.org/status/fetch.php?pkg=jellyfish=arm64=2.2.6-5=1504220784=0

Any further hints?

-- 
http://fam-tille.de

Bug#861691: postfixadmin 3.0 not compatible with php 7

[Gabriel Filion]

Gabriel Filion:
> As this page [0] suggests that function was deprecated in php 5.5 and
> completely removed in php 7, so that means that the postfixadmin
> codebase is not even compatible with PHP 7.

please disregard this comment.. apparently the issue is caused by the
post-install script creating a dbconfig.inc.php file that configures the
database type as "mysql" instead of "mysqli", which triggers the error
that I've seen.

The installation is however not complete because of this issue since
dbconfig-common is unable to create the necessary tables for
postfixadmin and the database is left empty.



signature.asc
Description: OpenPGP digital signature

Bug#873899: python2.7: fpectl removal breaks python-lxml ABI

[Jochen Sprickerhof]

Package: python2.7
Version: 2.7.14~rc1-2
Severity: normal

Dear Maintainer,

after upgrading python2.7 I get:

$ python -c "import lxml.html"
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/lxml/html/__init__.py", line 54, in 

from .. import etree
ImportError: /usr/lib/python2.7/dist-packages/lxml/etree.so: undefined symbol: 
PyFPE_jbuf

I assume this is the same same problem as in #873791, so I would propose
to add a Break python-lxml (<< 3.8.0-1.1).

Thanks

Jochen


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

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

Versions of packages python2.7 depends on:
ii  libpython2.7-stdlib  2.7.14~rc1-2
ii  mime-support 3.60
ii  python2.7-minimal2.7.14~rc1-2

python2.7 recommends no packages.

Versions of packages python2.7 suggests:
ii  binutils   2.29-8
pn  python2.7-doc  

-- no debconf information

Bug#861691: postfixadmin 3.0 not compatible with php 7

[Gabriel Filion]

I've hit errors now on a fresh install of postfixadmin on stretch with
php 7.0.

The error says "MySQL 3.x / 4.0 functions not available! (php5-mysql
installed?)" although php-mysql *is* installed.

I've looked up in the source code what triggers that error and it's a
test to ensure that function "mysql_connect" is present.

As this page [0] suggests that function was deprecated in php 5.5 and
completely removed in php 7, so that means that the postfixadmin
codebase is not even compatible with PHP 7.

[0]:http://php.net/manual/en/function.mysql-connect.php

So either we need patches to make postfixadmin work with php7, or it
should be marked as completely broken and possibly removed. (I'd prefer
the former if possible, but I don't know the state of the upstream code)



signature.asc
Description: OpenPGP digital signature

Bug#853568: No idea how to fix abs arguments in nanopolish

[Walter Landry]

Andreas Tille  wrote:
> Hi,
> 
> to fix bug #853568 I tried a patch (gcc-7.patch) to fix abs() arguments
> in nanopolish[1] but I have no idea how to deal with this:
> 
> ...
> g++ -o src/hmm/nanopolish_pore_model_set.o -c -g -O2 
> -fdebug-prefix-map=/build/nanopolish-0.5.0=. -fstack-protector-strong 
> -Wformat -Werror=format-security -g -O3 -std=c++11 -fopenmp -Wdate-t
> src/common/nanopolish_variant.cpp: In function 'std::vector 
> extract_variants(const string&, const string&)':
> src/common/nanopolish_variant.cpp:32:69: error: call of overloaded 
> 'abs(std::__cxx11::basic_string::size_type)' is ambiguous
>  size_t difference = std::abs(reference.size() - haplotype.size());

The result of subtracting two size_t's is still a size_t, which is
unsigned.  So you need to cast it to a signed type.  The correct type
is ptrdiff_t.

  http://en.cppreference.com/w/cpp/types/ptrdiff_t

The line then becomes

  size_t difference = std::abs(static_cast(reference.size() - 
haplotype.size()));

Or you could do it in two lines

  ptrdiff_t diff_signed (reference.size() - haplotype.size());
  size_t difference = std::abs(diff_signed);

Cheers,
Walter Landry

Bug#873898: trying to overwrite '/usr/lib/i386-linux-gnu/libEGL.so.1.0.0', which is also in package libegl1-mesa:i386 17.2.0~rc3-1

[積丹尼 Dan Jacobson]

Package: libegl1
Version: 0.2.999+git20170802-2

Unpacking libegl1:i386 (0.2.999+git20170802-2) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-m6F0gu/23-libegl1_0.2.999+git20170802-2_i386.deb 
(--unpack):
 trying to overwrite '/usr/lib/i386-linux-gnu/libEGL.so.1.0.0', which is also 
in package libegl1-mesa:i386 17.2.0~rc3-1

Bug#868015: [patch] knockd does not start after system reboot

[Steven Shiau]

I suffered the same issue after upgrading to Debian 9. Attached please 
find the patch file.


Steven

--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/47CF935C
Fingerprint: 0240 1FEB 695D 7112 62F0  8796 11C1 12DA 47CF 935C

--- knockd.service.orig 2017-09-01 11:27:21.080168675 +0800
+++ knockd.service  2017-09-01 11:27:35.432233376 +0800
@@ -11,3 +11,7 @@
 SuccessExitStatus=0 2 15
 ProtectSystem=full
 CapabilityBoundingSet=CAP_NET_RAW CAP_NET_ADMIN
+
+[Install]
+WantedBy=multi-user.target
+Alias=knockd.service

Bug#873897: ITP: ocaml-result -- Compatibility Result module for OCaml

[Andy Li]

Package: wnpp
Severity: wishlist
Owner: Andy Li 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: ocaml-result
  Version : 1.2
  Upstream Author : Jane Street Group, LLC 
* URL : https://github.com/janestreet/result
* License : BSD 3-clause
  Programming Lang: OCaml
  Description : Compatibility Result module for OCaml

Compatibility Result module.

Projects that want to use the new result type defined in OCaml >= 4.03 while
staying compatible with older version of OCaml should use the Result module
defined in this library.

This is a dependency of ocaml-migrate-parsetree (ITP #873896).
I will co-maintain it with the Debian OCaml Maintainers team.




-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJZqNW/AAoJENYPsCrEEWxpDLAH+wSAo/kptPRfEzTfzHcsyrtv
vVU+y/YWaDs7+aqpRUoqWO+MbWw2UwR9vaJ0pPOI0Y68ysnripKdwFQVhvDnYrWM
81Ngb0hNPWyNJtUiCmWy2k/gJOMPbLhPYVUNBYh7HCS74yEciQcfAkCoYEigrUiC
3k2sYVu/4GUTpK1Dc406KGhgkbcxmf62wK3W5mfMbJMtj3QlBScXDdlAqSEISu0y
eWARry+IQmxvZDBC9CM6dXPWTMAU2Y3jeumdOc6HIoQsTLUSUr1gn6X09qNlUiEI
AblhqALoelPKscPolCL5Q/gkyYkOaz71I3POGAREzYNQYhSWnId9ie6cd8+BRzY=
=HbUL
-END PGP SIGNATURE-

Bug#873896: ITP: ocaml-migrate-parsetree -- Convert OCaml parsetrees between different major versions

[Andy Li]

Package: wnpp
Severity: wishlist
Owner: Andy Li 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: ocaml-migrate-parsetree
  Version : 1.0.4
  Upstream Author : Frédéric Bour  and Jérémie
Dimino 
* URL : https://github.com/ocaml-ppx/ocaml-migrate-parsetree
* License : LGPL v2.1
  Programming Lang: OCaml
  Description : Convert OCaml parsetrees between different major versions

This library converts between parsetrees of different OCaml versions.

Supported versions are 4.02, 4.03, 4.04, 4.05 and 4.06 (trunk). For each
version, there is a snapshot of the parsetree and conversion functions to the
next and/or previous version.

This is a dependency of ocaml-sedlex 1.99.4 (ITP #867238).
I　will co-maintain it with the Debian OCaml Maintainers team.




-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJZqNAXAAoJENYPsCrEEWxpSq8IAJSeTsRKUBhNEaanVcCQVWWK
HiJHWmHDFcK1N+5oRjd0DTBiSuXvW08hDM3GGmGy6RB/FSfwZElr2ZLzA7e5lHbh
Vw4mK1BiJSGB3bJOIeufTwkbtK8kz0Bm62KDxWNzWlbUubRBO50kRkHFmh2Bu0yI
lmzrr3PyCeFqAHqVaNVOo20avwmIJLDUvVkOsz+S1OJElnAAurkFvjxywSuKL0y5
vlmt6ZywFwTX9GYus2QuLs1O2CYb2oubDbGoeAoFIg3EKgWwhMAxlKwXUAn9ZGbz
OvAkJyjYIbGucXJrajFiVfTimopcd5G7z6nicn/9ThGhwox5kjepOK0euk/h1Yg=
=1j8P
-END PGP SIGNATURE-

Bug#873895: libsml: FTBFS on non-Linux: libsml.a missing

[Aaron M. Ucko]

Source: libsml
Version: 0.1.1+git20170608-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of libsml for kfreebsd-{amd64,i386} (admittedly not release
architectures) have been failing:

  make[2]: *** No rule to make target '../sml/lib/libsml.a', needed by 
'sml_server'.  Stop.

The hurd-i386 build would have failed the same way if it hadn't first
hit the O_NDELAY issue I just reported separately.

AFAICT, the issue is that sml/Makefile doesn't define an overarching
libsml: target here, so make considers the default target to be
$(DYN_LIB), whereas sml_server specifically seeks to link against the
static library.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#873894: libsml: FTBFS on hurd-i386: O_NDELAY undeclared

[Aaron M. Ucko]

Source: libsml
Version: 0.1.1+git20170608-1
Severity: important
Tags: upstream
Justification: fails to build from source

The build of libsml for hurd-i386 (admittedly not a release
architecture) failed:

  sml_server.c: In function 'serial_port_open':
  sml_server.c:36:44: error: 'O_NDELAY' undeclared (first use in this 
function); did you mean 'VTDELAY'?
int fd = open(device, O_RDWR | O_NOCTTY | O_NDELAY);

Could you please take a look?  Perhaps you can make do without
O_NDELAY on platforms that don't define it.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#873891: Acknowledgement (sshfs 2.5 mount hang with ServerAliveInterval=1,ServerAliveCountMax=1)

[James Thomas Moon]

Also reported on github https://github.com/libfuse/sshfs/issues/87 and
linked to this bug.


*James Thomas Moon*, Senior Software Development Engineer in Test

On Thu, Aug 31, 2017 at 7:45 PM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 873891:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873891.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Bartosz Fenski 
>
> If you wish to submit further information on this problem, please
> send it to 873...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 873891: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873891
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#873893: log --download-only

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.8.8-1
Severity: wishlist

/var/log/aptitude should also log --download-only events.

Then we could send you bug reports on the --download-only option if
later offline we discover that it didn't get all it needs.

Bug#873892: msxpertsuite: FTBFS: latex interference under make install

[Aaron M. Ucko]

Source: msxpertsuite
Version: 3.6.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of msxpertsuite for several architectures failed because the
"make install" command wound up rebuilding(!) the user manual, without
the -j1 safeguard present for the initial make invocation.  Could you
please take a look?

Thanks!

FTR, I'm formally classifying this bug as a regression because it
could well affect binNMU attempts on architectures that succeeded this
time around.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#873891: sshfs 2.5 mount hang with ServerAliveInterval=1,ServerAliveCountMax=1

[James Thomas Moon]

Package: sshfs
Version: 2.5

Mounting a remote directory with sshfs options
"ServerAliveInterval=1,ServerAliveCountMax=1"
and entering the wrong password causes sshfs to hang.

### Reproduction

First, set an empty config file to ensure consistent ssh options

 touch /tmp/empty

Run sshfs with the options

sshfs user@ssh:/tmp /tmp/ssh -F /tmp/empty -o NumberOfPasswordPrompts=1,
ServerAliveInterval=1,ServerAliveCountMax=1

Enter the wrong password for user@ssh .
sshfs hangs.

This is undesirable behavior.

The process can be killed with  keyboard input.  The unsuccessful
mount point remains mounted but is empty.


Change either of the passed -o options "ServerAliveCountMax=1" or
"ServerAliveInterval=1" . sshfs does not hang (desired behavior). For
example, repeat the prior reproduction steps but remove
"ServerAliveCountMax=1"

sshfs user@ssh:/tmp /tmp/ssh -F /tmp/empty -o NumberOfPasswordPrompts=1,
ServerAliveInterval=1

Now sshfs fails after 4 seconds with error message

read: Connection reset by peer

This is desirable behavior.


### Software used

# sshfs --version
   SSHFS version 2.5
   FUSE library version: 2.9.4
   fusermount version: 2.9.4
   using FUSE kernel interface version 7.19

On Ubuntu 16.04.3 using kernel 4.4.0-92.


*James Thomas Moon*, Senior Software Development Engineer in Test

Bug#873890: ansible: enabling systemd service fails in chroot

[JD Friedrikson]

Package: ansible
Version: 2.2.1.0-2
Severity: normal

Hello,

To summarize, my issue is the same as the one here:
https://github.com/ansible/ansible/issues/21026

Fixes have already been merged:
https://github.com/ansible/ansible/pull/21072
https://github.com/ansible/ansible/pull/23904 # mildly related, but maybe 
should be brought up

and should be already included in 2.3.1.0+dfsg-2 (testing and unstable).

Here are the git commits that resolve this:

```
commit 2f0070639f3af9afca3b0280f89346c12e7b7e12
Author: Brian Coca 
Date:   Mon Feb 6 13:05:29 2017 -0500

attempt to fix systemd in chroot env

fixes #21026

diff --git a/lib/ansible/modules/system/systemd.py 
b/lib/ansible/modules/system/systemd.py
index c82bed60d..c970bd3ff 100644
--- a/lib/ansible/modules/system/systemd.py
+++ b/lib/ansible/modules/system/systemd.py
@@ -297,6 +297,7 @@ def main():
 
 # check service data, cannot error out on rc as it changes across 
versions, assume not found
 (rc, out, err) = module.run_command("%s show '%s'" % (systemctl, unit))
+
 if rc == 0:
 # load return of systemctl show into dictionary for easy access and 
return
 multival = []
@@ -327,6 +328,18 @@ def main():
 if is_systemd and 'LoadError' in result['status']:
 module.fail_json(msg="Error loading unit file '%s': %s" % 
(unit, result['status']['LoadError']))
 
+elif out.find('ignoring request') != -1:
+# fallback list-unit-files as show does not work on some systems 
(chroot)
+# not used as primary as it skips some services (like those using 
init.d) and requires .service notation
+if unit.endswith('.service'):
+service = unit
+else:
+service = '%s.service' % unit
+(rc, out, err) = module.run_command("%s list-unit-files '%s'" % 
(systemctl, service))
+if rc == 0:
+is_systemd = True
+
+
 # Does service exist?
 found = is_systemd or is_initd
 if is_initd and not is_systemd:
```
```
commit fa93bf70968f0b65422bd020a4adf9484dde8751
Author: Brian Coca 
Date:   Wed Feb 8 15:05:11 2017 -0500

allow more than .service, onus on user

diff --git a/lib/ansible/modules/system/systemd.py 
b/lib/ansible/modules/system/systemd.py
index c970bd3ff..831637064 100644
--- a/lib/ansible/modules/system/systemd.py
+++ b/lib/ansible/modules/system/systemd.py
@@ -33,7 +33,7 @@ options:
 name:
 required: true
 description:
-- Name of the service.
+- Name of the service. When using in a chroot environment you 
always need to specify the full name i.e. (crond.service).
 aliases: ['unit', 'service']
 state:
 required: false
@@ -330,12 +330,8 @@ def main():
 
 elif out.find('ignoring request') != -1:
 # fallback list-unit-files as show does not work on some systems 
(chroot)
-# not used as primary as it skips some services (like those using 
init.d) and requires .service notation
-if unit.endswith('.service'):
-service = unit
-else:
-service = '%s.service' % unit
-(rc, out, err) = module.run_command("%s list-unit-files '%s'" % 
(systemctl, service))
+# not used as primary as it skips some services (like those using 
init.d) and requires .service/etc notation
+(rc, out, err) = module.run_command("%s list-unit-files '%s'" % 
(systemctl, unit))
 if rc == 0:
 is_systemd = True
```

As this does affect usability for the chroot connector I feel that these fixes 
should be backported.

Please let me know if I'm not doing this correctly or if you need anything more 
from me.

Cheers,
JD


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

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

Versions of packages ansible depends on:
ii  python2.7.13-2
ii  python-crypto 2.6.1-7
ii  python-httplib2   0.9.2+dfsg-1
ii  python-jinja2 2.8-1
ii  python-netaddr0.7.18-2
ii  python-paramiko   2.0.0-1
ii  python-pkg-resources  33.1.1-1
ii  python-yaml   3.12-1

Versions of packages ansible recommends:
ii  python-kerberos   1.1.5-2+b2
ii  python-selinux2.6-3+b1
pn  python-winrm  
ii  python-xmltodict  0.10.2-1

Versions of packages ansible suggests:
pn  cowsay   
pn  sshpass  

-- no debconf information

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Jonathan Nieder]

Russ Allbery wrote:
> Jonathan Nieder  writes:

>>  C. You have transport-level integrity protection, e.g. by using a
>> protocol like https:// or ssh:// with proper PKI.
>
> I think it's worth being honest with ourselves here that the proper PKI
> part is not really happening with the Vcs-Git field (or Vcs-Browser for
> that matter) in normal usage in the context of Debian packages and random
> remote hosts.
>
> The bar to the attacker is not zero when https with normal public CAs is
> in use, but it's not very high.

There's no point in continuing to discuss this here.  I'll respond
privately in case you want to pursue it.

> I'm fine with including integrity protection in the protocol description
> anyway, but hopefully no one will think that it implies that https is
> providing strong authentication of the Git server here.  There's non-zero
> authentication, but it's pretty weak.

Without authentication, you don't have confidentiality either.  That's
how this comes up in the policy language: I don't understand why https
would be better or worse at providing confidentiality versus integrity.

One kind of authentication is that HTTPS protocol gives you some
assurance that the peer who first responded to is the same as the peer
for the rest of the connection.  That's enough to deter an unreliable
MITM or a passive MITM.

Jonathan

Bug#676472: cups: please suggest a compatible inet server (for lpd support)

[Vincent McIntyre]

> As of 2017, I tend to think that lpd support should disappear for Buster. Iff 
> we'd want to keep it, having cups-bsd get a 
>   Suggests: inetutils-inetd | inet-superserver, update-inetd
> _could_ make sense.
> 
> I'm not going to investigate more than that; so if someone wants that in 
> 2017's CUPS, please answer to this bug by saying so and confirming the above 
> strategy makes sense.
> 

Thanks for revisiting this old bug.
We definitely have a use-case for lpd support, so
please count my reply as being in favour of your strategy.

Kind regards
Vince

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Russ Allbery]

Jonathan Nieder  writes:

>  C. You have transport-level integrity protection, e.g. by using a
> protocol like https:// or ssh:// with proper PKI.

I think it's worth being honest with ourselves here that the proper PKI
part is not really happening with the Vcs-Git field (or Vcs-Browser for
that matter) in normal usage in the context of Debian packages and random
remote hosts.

The bar to the attacker is not zero when https with normal public CAs is
in use, but it's not very high.

I'm fine with including integrity protection in the protocol description
anyway, but hopefully no one will think that it implies that https is
providing strong authentication of the Git server here.  There's non-zero
authentication, but it's pretty weak.

-- 
Russ Allbery (r...@debian.org)   

Bug#873889: elvish: FTBFS on ppc64(el): several tests fail

[Aaron M. Ucko]

Source: elvish
Version: 0.9+git20170829.a2ab19c-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of elvish for ppc64el and the non-release architecture ppc64
have been failing with test suite errors as detailed at

https://buildd.debian.org/status/fetch.php?pkg=elvish=ppc64el=0.9%2Bgit20170829.a2ab19c-1=1504173324=0

and

https://buildd.debian.org/status/fetch.php?pkg=elvish=ppc64=0.9%2Bgit20170829.a2ab19c-1=1504174088=0

respectively.  Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#873888: dcl: FTBFS when not building dcl-f77-docs

[Aaron M. Ucko]

Source: dcl
Version: 7.2.3-1
Severity: serious
Justification: fails to build from source

Builds of dcl covering only its architecture-dependent binary packages
(as on the autobuilders or with dpkg-buildpackage -B) have been failing:

  cp -ar demo /<>/debian/dcl-f77-docs/usr/share/doc/dcl-f77-docs/
  cp: cannot create directory 
'/<>/debian/dcl-f77-docs/usr/share/doc/dcl-f77-docs/': No such 
file or directory
  debian/rules:38: recipe for target 'override_dh_install' failed
  make[1]: *** [override_dh_install] Error 1
  make[1]: Leaving directory '/<>'
  debian/rules:13: recipe for target 'binary-arch' failed
  make: *** [binary-arch] Error 2

Please account for these builds, perhaps by splitting
override_dh_install into -arch and -indep variants.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Jonathan Nieder]

Russ Allbery wrote:
> Jonathan Nieder  writes:
>> Russ Allbery wrote:

>>> (That said, my understanding is that you don't get any meaningful
>>> integrity protection for Git from using https over http.)
>>
>> As discussed elsewhere in this thread, it depends on how much you
>> trust (a) ca-certificates, versus (b) DNS.
>
> FWIW, we're talking about integrity protection at different levels here,
> which has made this a bit confusing.  You're talking about authentication
> of the remote server so that you don't get valid commits (in the sense
> that they fit into the Git hash tree) that aren't present in the real
> remote server.  I was talking about integrity protection at the wire
> protocol level (detection of bit flips in transit, that sort of thing),
> which Git will generally do for you regardless of transport by checking
> the hashes of objects, although I'm not sure if it does a full integrity
> check on all remote packs.

I replied privately in more detail (since this is mostly off-topic for
policy), but it's probably useful to clarify a few things publicly,
too.

Indeed, you're right that Git's application-level protocol protects
against cosmic rays and single-bit flips for all objects transfered.
In protocols like git:// and the CGI-based http:// support, this is
guaranteed by the way the protocol works.  If there are any holes in
this protection (e.g. the support for non-dynamic protocols like
ftp:// and static http:// used to have such a bug) then we consider
that a serious bug and would want to know about it so it can be fixed.
Feel free to contact me at g...@packages.debian.org for more details.

By integrity I was referring to something different: protection
against *malicious* manipulation of the response, by a MITM or other
hostile actor.  Git does not guarantee this unless one of the
following holds:

 A. You have learned the name of the commit or tag you are interested
in in a reliable way out-of-band.  That is, if you check out the
revision to be built by SHA-1 instead of by ref name, then Git
intends to guarantee that what you check out is reliably
determined by that SHA-1.

 B. You use signed tags or push certs to verify that you are checking
out what you intend.  E.g. you can do this by using "git tag -v"
to verify that the code you are checking out was (1) signed by
someone you trust and (2) actually refers to the version you want.
Make sure to pay attention to the output to avoid "replay" attacks
(i.e. trying to pass off an old vulnerable tagged version of a
package for a modern fixed version).  Or

 C. You have transport-level integrity protection, e.g. by using a
protocol like https:// or ssh:// with proper PKI.

If people are expecting Git to guarantee that the code you fetch is
what you intended to fetch without (A), (B), or (C), then we are doing
users a dangerous misservice.  I am concerned about where that
expectation comes from and want to do what I can to improve
documentation to avoid that.  Feel free to contact me at
g...@packages.debian.org to help.

> Protocol-level integrity protection doesn't help if you negotiate that
> protocol with the wrong peer, obviously, and preventing that is rather
> outside the scope of the text we're fiddling with here.

I disagree: one of the main goals of HTTPS and the basis for its
support for confidentiality and integrity is avoiding communicating
with the wrong peer.

> But this is all picking nits -- HTTPS provides both confidentiality and
> integrity protection as wire protocol features, so we can just say that
> the protocol should provide those things, regardless of the somewhat
> pedantic point about whether that integrity protection is meaningful for
> Git.

Agreed.

Thanks,
Jonathan

Bug#760021: lintian: check for not wrap-and-sort formatted files

[Russ Allbery]

Mattia Rizzolo  writes:

> Also, wouldn't you need to pick only one of the -t, -s, -a combinations?
> I see people disliking -t (trailing commas) also because it's not in
> policy,

Please file a bug against Policy if you think there's a wording change we
could make to make people comfortable with this as an option.

-- 
Russ Allbery (r...@debian.org)   

Bug#873887: firefox-esr: random crash (SIGSEGV)

[Paul Wise]

Package: firefox-esr
Version: 52.3.0esr-2
Severity: normal

I got a random crash (SIGSEGV) in firefox-esr. If the below full
backtrace isn't useful, please close this bug.

$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'thread apply all bt full' 
--core 
/var/crash/1000/31124-1000-1000-11-1504151892-chianamo--usr-lib-firefox-esr-firefox-esr.core
 /usr/lib/firefox-esr/firefox-esr
[New LWP 29118]
[New LWP 31382]
[New LWP 31413]
[New LWP 31124]
[New LWP 31381]
[New LWP 1066]
[New LWP 8576]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `firefox-esr'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  mozilla::(anonymous namespace)::RunWatchdog (arg=0x7f9ffa4803c8) at 
/build/firefox-esr-3U4Xhp/firefox-esr-52.3.0esr/toolkit/components/terminator/nsTerminator.cpp:158
158 
/build/firefox-esr-3U4Xhp/firefox-esr-52.3.0esr/toolkit/components/terminator/nsTerminator.cpp:
 No such file or directory.
[Current thread is 1 (Thread 0x7f9ff25fe700 (LWP 29118))]
#0  0x7fa09a529b4f in mozilla::(anonymous namespace)::RunWatchdog(void*) 
(arg=0x7f9ffa4803c8) at 
/build/firefox-esr-3U4Xhp/firefox-esr-52.3.0esr/toolkit/components/terminator/nsTerminator.cpp:158
#1  0x7fa097b5f018 in _pt_root (arg=0x7f9ffb4e8260) at ptthread.c:216
#2  0x7fa0a6e84494 in start_thread (arg=0x7f9ff25fe700) at 
pthread_create.c:333
#3  0x7fa0a612aabf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 7 (Thread 0x7fa0168fe700 (LWP 8576)):
#0  0x7fa0a612166d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7fa097b5ca30 in poll (__timeout=-1, __nfds=1, __fds=0x7fa0168fdbc0) 
at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
stack_syspoll = {{fd = 61, events = 1, revents = 1}, {fd = -1490307896, 
events = 32672, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 
-2059499968, events = 32672, revents = 0}, {fd = 378526752, events = 32672, 
revents = 0}, {fd = 0, events = 1, revents = 0}, {fd = -1511428096, events = 
32672, revents = 0}, {fd = 378526736, events = 32672, revents = 0}, {fd = 
-1749825879, events = 32672, revents = 0}, {fd = -1241263273, events = 0, 
revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = 0, events = 0, revents 
= 0}, {fd = -1494745592, events = 32672, revents = 0}, {fd = -1490307896, 
events = 32672, revents = 0}, {fd = 378527260, events = 32672, revents = 0}, 
{fd = 0, events = 0, revents = 0}, {fd = -1510997944, events = 32672, revents = 
0}, {fd = 0, events = 0, revents = 0}, {fd = -1494711855, events = 32672, 
revents = 0}, {fd = -1492480876, events = 32672, revents = 0}, {fd = 5, events 
= 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 618397856, events = 
32672, revents = 0}, {fd = -1494747920, events = 32672, revents = 0}, {fd = 
378527120, events = 32672, revents = 0}, {fd = -1747511504, events = 32672, 
revents = 0}, {fd = 378527260, events = 32672, revents = 0}, {fd = 378527264, 
events = 32672, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = 
429854336, events = 32672, revents = 0}, {fd = 378527280, events = 32672, 
revents = 0}, {fd = -1492480876, events = 32672, revents = 0}, {fd = 5, events 
= 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = -1732908800, events 
= 32672, revents = 0}, {fd = -1494745592, events = 32672, revents = 0}, {fd = 
378527216, events = 32672, revents = 0}, {fd = -1492450401, events = 32672, 
revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 0, events = 0, revents = 
0}, {fd = -1505909760, events = 32672, revents = 0}, {fd = -1505895808, events 
= 32672, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 0, events = 0, 
revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = -1749708040, events = 
32672, revents = 0}, {fd = -1732908800, events = 32672, revents = 0}, {fd = 
378527040, events = 32672, revents = 0}, {fd = 1, events = 0, revents = 0}, {fd 
= 436241152, events = 32672, revents = 0}, {fd = -1, events = 0, revents = 0}, 
{fd = 0, events = 0, revents = 0} , {fd = 16447488, events = 
-29333, revents = 7273}}
syspoll = 0x7fa0168fdbc0
index = 
msecs = -1
ready = 
start = 0
elapsed = 
remaining = 
#2  0x7fa097b5ca30 in _pr_poll_with_poll (pds=pds@entry=0x7fa0168fde20, 
npds=npds@entry=1, timeout=timeout@entry=4294967295) at ptio.c:4031
stack_syspoll = {{fd = 61, events = 1, revents = 1}, {fd = -1490307896, 
events = 32672, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 
-2059499968, events = 32672, revents = 0}, {fd = 378526752, events = 32672, 
revents = 0}, {fd = 0, events = 1, revents = 0}, {fd = -1511428096, events = 
32672, revents = 0}, {fd = 378526736, events = 32672, revents = 0}, {fd = 
-1749825879, events = 32672, revents = 0}, {fd = -1241263273, events = 0, 
revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = 0, events = 0, revents 
= 0}, {fd = -1494745592, events = 32672, revents 

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Russ Allbery]

Jonathan Nieder  writes:
> Russ Allbery wrote:

>> (That said, my understanding is that you don't get any meaningful
>> integrity protection for Git from using https over http.)

> As discussed elsewhere in this thread, it depends on how much you
> trust (a) ca-certificates, versus (b) DNS.

FWIW, we're talking about integrity protection at different levels here,
which has made this a bit confusing.  You're talking about authentication
of the remote server so that you don't get valid commits (in the sense
that they fit into the Git hash tree) that aren't present in the real
remote server.  I was talking about integrity protection at the wire
protocol level (detection of bit flips in transit, that sort of thing),
which Git will generally do for you regardless of transport by checking
the hashes of objects, although I'm not sure if it does a full integrity
check on all remote packs.

Protocol-level integrity protection doesn't help if you negotiate that
protocol with the wrong peer, obviously, and preventing that is rather
outside the scope of the text we're fiddling with here.

But this is all picking nits -- HTTPS provides both confidentiality and
integrity protection as wire protocol features, so we can just say that
the protocol should provide those things, regardless of the somewhat
pedantic point about whether that integrity protection is meaningful for
Git.

-- 
Russ Allbery (r...@debian.org)   

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Christopher Li]

On Thu, Aug 31, 2017 at 6:43 PM, Ramsay Jones
>>  - move sparse to /usr/lib
>>  - teach cgcc about the move of sparse
>>  - make /usr/bin/sparse call cgcc -no-compile "$@"
>
> Hmm, I don't think that would be a good idea ...
>

Agree.

>
> Anyway, if you were to un-install llvm, sparse-llvm etc., would not
> be built, and the tests would not be run ... ;-)

I think Uwe already confirm using cgcc to invoke sparse will
fix the problem.

In this test, we just need to use cgcc to invoke sparse-llvm.
I have a patch to fix the usage in test-suite in the other email.

Chris

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Christopher Li]

On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König  Yes
that works. So to address the Debian bug I can do:
>
>  - move sparse to /usr/lib
>  - teach cgcc about the move of sparse
>  - make /usr/bin/sparse call cgcc -no-compile "$@"

I don't like that. It means the user can't invoke sparse directly.

>
> or is it easier to teach sparse about the architecture stuff?

First of all. It is not very trivial to teach sparse about the architecture
stuff. To my mind, we need to move all the cgcc logic into sparse.

For this case, I think it is easier to teach the sparse validation
code to use cgcc on those back end testing. Most validation don't
need to include system header file at all so it does not have
this problem.

How about this patch?
I know my patch is white space damaged in email.
Git branch is at:
https://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git/log/?h=llvm-cgcc

Please let me know if that fix your problem. It pass check
on my local machine running x86_64. I don't have ppc64 to
test with.

Chris

diff --git a/sparsec b/sparsec
index 9dc96c9..2990d26 100755
--- a/sparsec
+++ b/sparsec
@@ -32,7 +32,8 @@ done
 TMPLLVM=`mktemp -t tmp.XX`".llvm"
 TMPFILE=`mktemp -t tmp.XX`".o"

-$DIRNAME/sparse-llvm $SPARSEOPTS > $TMPLLVM
+env CHECK=$DIRNAME/sparse-llvm $DIRNAME/cgcc -no-compile \
+   $SPARSEOPTS > $TMPLLVM

 LLC=`"${LLVM_CONFIG:-llvm-config}" --bindir`/llc

diff --git a/sparsei b/sparsei
index 3431a9f..3abd00f 100755
--- a/sparsei
+++ b/sparsei
@@ -10,4 +10,4 @@ if [ $# -eq 0 ]; then
   exit 1
 fi

-$DIRNAME/sparse-llvm $@ | $LLI
+env CHECK=$DIRNAME/sparse-llvm $DIRNAME/cgcc -no-compile $@ | $LLI

Bug#498336: bug#28306: grep: option to filter non-printable characters from contents

[Paul Eggert]

Santiago R.R. wrote:

What's your position on this?


Sounds like a reasonable option, though I think I might make it another form of 
coloring rather than a separate option.

Bug#873874: uim FTBFS with libanthy-dev 1:0.3-5

[dai]

Control: forwarded -1 
https://lists.alioth.debian.org/pipermail/pkg-anthy-japanese/2017-August/30.html
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#873886: osmosis: Depend on libplexus-classworlds2-java instead of libplexus-classworlds-java

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Emmanuel,

On 09/01/2017 01:33 AM, Emmanuel Bourg wrote:
> The osmosis package uses the old libplexus-classworlds-java package which
> is going to be removed in a near future. Could you please migrate to
> libplexus-classworlds2-java? I'm attaching a patch, it builds fine but
> I haven't checked if it's still ok at runtime.

Thanks for the patch, I've applied it in git and a new upload to
unstable will follow shortly.

The switch to libplexus-classworlds2-java shouldn't be problematic as
it's the same version (2.5.2) as used by the upstream gradle builds.

Kind Regards,

Bas

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

Bug#873828: Pending fixes for bugs in the maven-plugin-tools package

[pkg-java-maintainers]

tag 873828 + pending
thanks

Some bugs in the maven-plugin-tools package are closed in revision
3c6d3d829275101fe02546ed067abf418672ee7e in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/maven-plugin-tools.git/commit/?id=3c6d3d8

Commit message:

Added the missing Maven rule for plexus-component-annotations (Closes: 
#873828)

Bug#873886: osmosis: Depend on libplexus-classworlds2-java instead of libplexus-classworlds-java

[Emmanuel Bourg]

Package: osmosis
Version: 0.45-4
Severity: normal

Hi,

The osmosis package uses the old libplexus-classworlds-java package which
is going to be removed in a near future. Could you please migrate to
libplexus-classworlds2-java? I'm attaching a patch, it builds fine but
I haven't checked if it's still ok at runtime.

Thank you,

Emmanuel Bourg
diff --git a/debian/control b/debian/control
index 9126bcf..e2514cf 100644
--- a/debian/control
+++ b/debian/control
@@ -26,7 +26,7 @@ Build-Depends: debhelper (>= 9),
libspring-transaction-java,
libstax2-api-java,
libosmpbf-java,
-   libplexus-classworlds-java,
+   libplexus-classworlds2-java,
libprotobuf-java,
libwoodstox-java,
libxerces2-java,
@@ -56,7 +56,7 @@ Depends: default-jre-headless | java7-runtime-headless,
  libspring-jdbc-java,
  libspring-transaction-java,
  libosmpbf-java,
- libplexus-classworlds-java,
+ libplexus-classworlds2-java,
  libprotobuf-java,
  libxerces2-java,
  libxz-java,
diff --git a/debian/maven.rules b/debian/maven.rules
index c6a6042..6fdb0bd 100644
--- a/debian/maven.rules
+++ b/debian/maven.rules
@@ -1,5 +1,6 @@
 
 junit junit * s/.*/4.x/ * *
+org.codehaus.plexus plexus-classworlds * s/.*/2.x/ * *
 org.springframework spring-jdbc * s/.*/debian/ * *
 s/org.jboss.netty/io.netty/ netty * s/.*/debian/ * *
 s/org.postgis/net.postgis/ postgis-jdbc * s/.*/debian/ * *
diff --git a/debian/patches/01-fix_launcher.patch 
b/debian/patches/01-fix_launcher.patch
index 596ede8..48258cf 100644
--- a/debian/patches/01-fix_launcher.patch
+++ b/debian/patches/01-fix_launcher.patch
@@ -32,7 +32,7 @@ Forwarded: not-needed
  
  # Build up the classpath of required jar files via classworlds launcher.
 -MYAPP_CLASSPATH=$MYAPP_HOME/lib/default/plexus-classworlds-*.jar
-+MYAPP_CLASSPATH=$LIBRARIES_HOME/plexus-classworlds.jar
++MYAPP_CLASSPATH=$LIBRARIES_HOME/plexus-classworlds2.jar
  
  MAINCLASS=org.codehaus.classworlds.Launcher
 -EXEC="$JAVACMD $JAVACMD_OPTIONS -cp $MYAPP_CLASSPATH -Dapp.home=$MYAPP_HOME 
-Dclassworlds.conf=$MYAPP_HOME/config/plexus.conf  $MAINCLASS $OSMOSIS_OPTIONS"

Bug#867707: Bootstrapping of libfm / menu-cache

[Daniel Schepler]

There is more work that needs to be done in order to make the libfm /
menu-cache cycle bootstrappable.  Currently, menu-cache Build-Depends
on libfm-dev, which is not built by the stage1 build profile of
src:libfm.
-- 
Daniel Schepler

Bug#867376: Processed: Re: Bug#867376 closed by Alexander GQ Gerasiov <g...@debian.org> (Bug#867376: fixed in uncrustify 0.65+git20170831+dfsg1-1)

[Alexander Gerasiov]

Hello Julien,

On Thu, 31 Aug 2017 22:15:04 +
ow...@bugs.debian.org (Debian Bug Tracking System) wrote:

> This bug was not a request for packaging a new upstream version, so
> this changelog entry isn't appropriate.
Could you please explain your point?

There was several bugs in upstream code which leads to incorrect
behavior on some architectures.
We have fixed them in current upstream code, and current upstream
version was uploaded into archive. This really fixes #867376, you can
see this on https://buildd.debian.org/status/package.php?p=uncrustify

-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: g...@cs.msu.su  Homepage: http://gerasiov.net  Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Bug#873860: [Pkg-ime-devel] Bug#873860: ibus-anthy FTBFS: UnicodeDecodeError: 'euc_jp' codec can't decode byte 0xe5 in position 46: illegal multibyte sequence

[NOKUBI Takatsugu]

Hi, all.

anthy package had updated because of new upstream release. The version
policy had changed, so the latest upstream version is 0.3, and
previous version is 9100h, So debian version has the epoch.

ABI and soname are changed so libanthy1 is the newest one. The default
encoding is switched from EUC-JP to UTF-8.

Almost IMEs with anthy support will be required to adopt such changes.
Now I am going to fix uim-anthy for them.

If I can get much more experiment, share them.

On Fri, 01 Sep 2017 03:24:02 +0900,
Adrian Bunk wrote:
> 
> Source: ibus-anthy
> Version: 1.5.9-2
> Severity: serious
> Tags: buster sid
> 
> Some recent change in unstable makes ibus-anthy FTBFS:
> 
> https://tests.reproducible-builds.org/debian/history/ibus-anthy.html
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ibus-anthy.html
> 
> ...
> Making all in data
> make[3]: Entering directory '/build/1st/ibus-anthy-1.5.9/data'
> LC_ALL=C /usr/bin/intltool-merge  -x -u -c ../po/.intltool-merge-cache ../po 
> ibus-anthy.appdata.xml.in ibus-anthy.appdata.xml
> Generating and caching the translation database
> Merging translations into ibus-anthy.appdata.xml.
> CREATED ibus-anthy.appdata.xml
> Generate emoji.t
> Generate zipcode.t
> Your file is not eucJP? /usr/share/anthy/zipcode.t
> Traceback (most recent call last):
>   File "zipcode-textdic.py", line 24, in 
> contents = codecs.open(anthy_zipfile, 'r', 'euc_jp').read()
>   File "/usr/lib/python3.5/codecs.py", line 698, in read
> return self.reader.read(size)
> UnicodeDecodeError: 'euc_jp' codec can't decode byte 0xe5 in position 46: 
> illegal multibyte sequence
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "zipcode-textdic.py", line 27, in 
> contents = open(anthy_zipfile).read()
>   File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
> return codecs.ascii_decode(input, self.errors)[0]
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 46: 
> ordinal not in range(128)
> Makefile:653: recipe for target 'zipcode.t' failed
> make[3]: *** [zipcode.t] Error 1
> 
> ___
> Pkg-ime-devel mailing list
> pkg-ime-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ime-devel
> 

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Jonathan Nieder]

Jonathan Nieder wrote:
> Russ Allbery wrote:
>>> On Wed, Aug 23 2017, Russ Allbery wrote:

 --- a/policy/ch-controlfields.rst
 +++ b/policy/ch-controlfields.rst
 @@ -962,6 +962,10 @@ repository where the Debian source package is 
 developed.
 
  More than one different VCS may be specified for the same package.
 
 +For both fields, any URLs given should use a scheme that provides
 +confidentiality (``https``, for example, rather than ``http`` or ``git``)
 +if the VCS repository supports it.
 +
  .. _s-f-Package-List:
[...]
>> Maybe I should just say:
>>
>> a scheme that provides confidentiality and integrity protection
>
> Seconded.
>
>> I think I was over-thinking it.
>>
>> (That said, my understanding is that you don't get any meaningful
>> integrity protection for Git from using https over http.)
>
> As discussed elsewhere in this thread, it depends on how much you
> trust (a) ca-certificates, versus (b) DNS.

Correction: even if you trust DNS, you also have to trust IP
infrastructure to ensure your traffic goes to the intended destination
without a MITM modifying it.  That means that even with trustworthy
DNS (e.g. using dnssec), if your ISP is compromised then you have
neither meaningful confidentiality protection nor meaningful integrity
protection over http, beyond what your version control system provides
at the application level.

A good VPN can improve on that, depending on the destination of your
traffic.  But given all the above, I have to say, https really does
seem like a meaningful improvement.

All that said, the other points still apply:

> The ideal is to use signed tags and check them.  (Or even better, to
> work with git upstream to get push certs distributed properly and
> check those.)

These two approaches can protect integrity but do not help with
confidentiality.

> It would be nice to get something like chromium's certificate pinning
> into curl, but that's a separate topic.

Something like this (or a revamping of ca-certificates) is needed for
confidentiality in the presence of a MITM.

And I agree with you that policy doesn't need to get into these details.

Thanks,
Jonathan

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Ramsay Jones]

On 31/08/17 21:55, Uwe Kleine-König wrote:
> On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote:
>> That is very much like on x86_64 missing define "#weak_define __x86_64__ 1"
>>
>> Does cgcc work for you? In the future we do want to move the archetecture
>> related define from cgcc into sparse by itself. For now you can set
>> "sparse" as "cgcc -no-compile"
> 
> Yes that works. So to address the Debian bug I can do:
> 
>  - move sparse to /usr/lib
>  - teach cgcc about the move of sparse
>  - make /usr/bin/sparse call cgcc -no-compile "$@"

Hmm, I don't think that would be a good idea ...

> or is it easier to teach sparse about the architecture stuff?

I now understand (I think!) that you are building a sparse
package (presumably a .deb) and you are concerned that sparse
does not pass it's own testsuite on those platforms.

As I said before, the additional failures you are seeing are
in the 'llvm backend' code (which, as far as I know, only passes
on x86_64 Linux), and in my opinion the llvm-backend programs should
not be installed. (The Makefile will build them automatically if
you have llvm installed, likewise for c2xml/libxml and test-inspect/gtk).

[I would like to see build variable(s) to allow the user to suppress
the build (or installation) of the other 'non-primary' sparse programs.]

Anyway, if you were to un-install llvm, sparse-llvm etc., would not
be built, and the tests would not be run ... ;-)

Christopher, as the project maintainer, has the joy of making these
kinds of decisions! :-D

ATB,
Ramsay Jones

Bug#825683: Processed: retitle to RFP: pycsco -- Python modules to simplify working with Cisco NX-OS devices

[Vincent Bernat]

retitle 825683 ITP: pycsco -- Python modules to simplify working with Cisco 
NX-OS devices
owner 825683 !
stop

Still intent to package. Unfortunately, there is a licensing issue.

https://github.com/jedelman8/pycsco/issues/31
-- 
I fell asleep reading a dull book, and I dreamt that I was reading on,
so I woke up from sheer boredom.


signature.asc
Description: PGP signature

Bug#870987: Bug#814176: Bug#793492: Bug#814176: azureus: (Build-)Depends on OpenJDK 7

[Scott Kitterman]

On August 31, 2017 1:28:40 PM EDT, Emmanuel Bourg  wrote:
>Le 27/08/2017 à 00:07, Scott Kitterman a écrit :
>
>> I would like to give Emmanuel time to respond to this.  I've tagged
>the bug 
>> moreinfo to hold on on processing it for the moment.  If Emmanuel
>agrees to 
>> the removal or we don't hear back in two weeks, then go ahead and
>remove the 
>> moreinfo tag and I'll process the removal then.
>
>I'm busy on another task for now but I plan to upload the current state
>of the azureus repository when I'm done. The package builds fine, there
>is still an issue with the embedded browser but downloading torrents
>works.
>
>Emmanuel Bourg

Do you have an estimate for how long this will take?

Scott K

Bug#864078: CVE-2017-9110 CVE-2017-9111 CVE-2017-9112 CVE-2017-9113 CVE-2017-9114 CVE-2017-9115 CVE-2017-9116 CVE-2017-9117

[Markus Koschany]

clone 864078 -1
severity -1 important
thanks

I have prepared a security update for openexr which I am going to upload
in due course. The upload will fix CVE-2017-9110, CVE-2017-9112 and
CVE-2017-9116. The other CVE are not considered being critical by
upstream. In fact it looks more like they are just normal bugs in the
exr2aces test program which is not built by default. I'm going to clone
this bug report because of the outstanding issues but will lower the
severity to important.

Regards,

Markus
diff -Nru openexr-2.2.0/debian/changelog openexr-2.2.0/debian/changelog
--- openexr-2.2.0/debian/changelog  2016-07-19 08:53:33.0 +0200
+++ openexr-2.2.0/debian/changelog  2017-08-31 23:52:03.0 +0200
@@ -1,3 +1,14 @@
+openexr (2.2.0-11.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Fix CVE-2017-9110, CVE-2017-9112 and CVE-2017-9116.
+Brandon Perry discovered that openexr was affected by an integer overflow
+vulnerability and missing boundary checks that would allow a remote
+attacker to cause a denial of service (application crash) via specially
+crafted image files. (Closes: #864078)
+
+ -- Markus Koschany   Thu, 31 Aug 2017 23:52:03 +0200
+
 openexr (2.2.0-11) unstable; urgency=medium
 
   * Remove symbols files. Closes: #807079
diff -Nru openexr-2.2.0/debian/patches/CVE-2017-911x.patch 
openexr-2.2.0/debian/patches/CVE-2017-911x.patch
--- openexr-2.2.0/debian/patches/CVE-2017-911x.patch1970-01-01 
01:00:00.0 +0100
+++ openexr-2.2.0/debian/patches/CVE-2017-911x.patch2017-08-31 
23:52:03.0 +0200
@@ -0,0 +1,97 @@
+From: Markus Koschany 
+Date: Thu, 31 Aug 2017 23:31:42 +0200
+Subject: CVE-2017-911x
+
+Bug-Upstream: https://github.com/openexr/openexr/issues/232
+Bug-Debian: https://bugs.debian.org/864078
+Origin: 
https://github.com/binarycrusader/openexr/commit/cc603afc7857b99c55360be75a9549422991c1e9
+---
+ IlmImf/ImfDwaCompressor.cpp |  7 ++-
+ IlmImf/ImfHuf.cpp   | 10 ++
+ IlmImf/ImfPizCompressor.cpp |  6 ++
+ 3 files changed, 18 insertions(+), 5 deletions(-)
+
+diff --git a/IlmImf/ImfDwaCompressor.cpp b/IlmImf/ImfDwaCompressor.cpp
+index 1c1bd45..2ef8878 100644
+--- a/IlmImf/ImfDwaCompressor.cpp
 b/IlmImf/ImfDwaCompressor.cpp
+@@ -2377,7 +2377,12 @@ DwaCompressor::uncompress
+ 
+ const char *dataPtr= inPtr + NUM_SIZES_SINGLE * sizeof(Int64);
+ 
+-if (inSize < headerSize + compressedSize) 
++/* Both the sum and individual sizes are checked in case of overflow. */
++if (inSize < (headerSize + compressedSize) ||
++inSize < unknownCompressedSize ||
++inSize < acCompressedSize ||
++inSize < dcCompressedSize ||
++inSize < rleCompressedSize)
+ {
+ throw Iex::InputExc("Error uncompressing DWA data"
+ "(truncated file).");
+diff --git a/IlmImf/ImfHuf.cpp b/IlmImf/ImfHuf.cpp
+index a375d05..97909a5 100644
+--- a/IlmImf/ImfHuf.cpp
 b/IlmImf/ImfHuf.cpp
+@@ -822,7 +822,7 @@ hufEncode  // return: output size 
(in bits)
+ }
+ 
+ 
+-#define getCode(po, rlc, c, lc, in, out, oe)  \
++#define getCode(po, rlc, c, lc, in, out, ob, oe)\
+ { \
+ if (po == rlc)\
+ { \
+@@ -835,6 +835,8 @@ hufEncode  // return: output size 
(in bits)
+   \
+   if (out + cs > oe)  \
+   tooMuchData();  \
++  else if (out - 1 < ob)  \
++  notEnoughData();\
+   \
+   unsigned short s = out[-1]; \
+   \
+@@ -895,7 +897,7 @@ hufDecode
+   //
+ 
+   lc -= pl.len;
+-  getCode (pl.lit, rlc, c, lc, in, out, oe);
++  getCode (pl.lit, rlc, c, lc, in, out, outb, oe);
+   }
+   else
+   {
+@@ -925,7 +927,7 @@ hufDecode
+   //
+ 
+   lc -= l;
+-  getCode (pl.p[j], rlc, c, lc, in, out, oe);
++  getCode (pl.p[j], rlc, c, lc, in, out, outb, oe);
+   break;
+   }
+   }
+@@ -952,7 +954,7 @@ hufDecode
+   if (pl.len)
+   {
+   lc -= pl.len;
+-  getCode (pl.lit, rlc, c, lc, in, out, oe);
++  getCode (pl.lit, rlc, c, lc, in, out, outb, oe);
+   }
+   else
+   {
+diff --git a/IlmImf/ImfPizCompressor.cpp b/IlmImf/ImfPizCompressor.cpp
+index 46c6fba..8b3ee38 100644
+--- a/IlmImf/ImfPizCompressor.cpp
 b/IlmImf/ImfPizCompressor.cpp
+@@ -573,6 +573,12 @@ PizCompressor::uncompress (const char *inPtr,
+ int length;
+ Xdr::read  (inPtr, length);
+ 
++  

Bug#867376: closed by Alexander GQ Gerasiov <g...@debian.org> (Bug#867376: fixed in uncrustify 0.65+git20170831+dfsg1-1)

[Julien Cristau]

Control: reopen -1

On Thu, Aug 31, 2017 at 17:54:05 +, Debian Bug Tracking System wrote:

>  uncrustify (0.65+git20170831+dfsg1-1) unstable; urgency=medium
>  .
>* New upstream version 0.65+git20170831 (Closes: #867376)
>* Bump Standards-Version to 4.1.0 (no additional changes needed).

This bug was not a request for packaging a new upstream version, so this
changelog entry isn't appropriate.

Cheers,
Julien

Bug#873680: gaupol: Gtk-WARNING warnings in gaupol

[Osmo Salomaa]

Hello,

Upstream here. It's a known issue, I've seen for quite a while now,
since some GTK+ release over a year ago. You need to open a file to see
those messages. I don't know if it happens for all users, but it is
common.

The issue is still unfixed because I don't know where the warning
originates from. The vague message refers to GtkApplicationWindow, but
the problem is caused by some widget inside the window, I have no idea
which or what to do about it. Any help is appreciated.

https://github.com/otsaloma/gaupol/issues/26

https://mail.gnome.org/archives/gtk-app-devel-list/2017-July/msg00012.html

-- 
Osmo Salomaa 

Bug#873884: [openssh-server] At boot time ssh is listening at port 22 rather than the one configured in sshd_config

[Garcia Dabo Cesar Enrique]

Package: openssh-server
Version: 1:7.4p1-10+deb9u1
Severity: important
Tags: security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org

--- Please enter the report below this line. ---

I have configured a server with a non-standard port using directive Port in /
etc/ssh/sshd_config, however when I restart the server it listens at port 22.
The ssh related services after rebooting look like this:

# systemctl -a | grep ssh
ssh.service
loaded inactive dead OpenBSD Secure Shell server
system-ssh.slice
loaded active active system-ssh.slice
ssh.socket
loaded active listening OpenBSD Secure Shell server socket

As a workaround, If I restart the ssh server:

# systemctl restart ssh.service

then sshd starts to listen to the configured port as it should be. The
services status look like this:

# systemctl -a | grep ssh
ssh.service
loaded active running OpenBSD Secure Shell server
system-ssh.slice
loaded active active system-ssh.slice
ssh.socket
loaded inactive dead OpenBSD Secure Shell server socket



--- System information. ---
Architecture:
Kernel: Linux 4.9.0-3-amd64

Debian Release: 9.0
500 stable security.debian.org
500 stable ftp.de.debian.org

--- Package information. ---
Depends (Version) | Installed
=-+-==
adduser (>= 3.9) | 3.115
dpkg (>= 1.9.0) | 1.18.24
libpam-modules (>= 0.72-9) | 1.1.8-3.6
libpam-runtime (>= 0.76-14) | 1.1.8-3.6
lsb-base (>= 4.1+Debian3) | 9.20161125
openssh-client (= 1:7.4p1-10) | 1:7.4p1-10deb9u1
openssh-sftp-server | 1:7.4p1-10deb9u1
procps | 2:3.3.12-3
ucf (>= 0.28) | 3.0036
debconf (>= 0.5) | 1.5.61
OR debconf-2.0 |
init-system-helpers (>= 1.18~) | 1.48
libaudit1 (>= 1:2.2.1) | 1:2.6.7-2
libc6 (>= 2.17) | 2.24-11+deb9u1
libcomerr2 (>= 1.01) | 1.43.4-2
libgssapi-krb5-2 (>= 1.14+dfsg) | 1.15-1
libkrb5-3 (>= 1.13~alpha1+dfsg) | 1.15-1
libpam0g (>= 0.99.7.1) | 1.1.8-3.6
libselinux1 (>= 1.32) | 2.6-3+b1
libssl1.0.2 (>= 1.0.2d) | 1.0.2l-2
libsystemd0 | 232-25+deb9u1
libwrap0 (>= 7.6-4~) | 7.6.q-26
zlib1g (>= 1:1.1.4) | 1:1.2.8.dfsg-5


Recommends (Version) | Installed
=-+-===
libpam-systemd | 232-25+deb9u1
ncurses-term | 6.0+20161126-1
xauth | 1:1.0.9-1+b2


Suggests (Version) | Installed
===-+-===
molly-guard |
monkeysphere |
rssh |
ssh-askpass |
ufw |

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Ximin Luo]

Julien Puydt:
> Hi,
> 
>> [..]
> 
> I could reproduce the matter, asked upstream if it was known, and since
> it wasn't:
> https://github.com/wbhart/flint2/issues/372
> 

Thanks for that. I forced the rebuild to continue by skipping the flint tests 
with DEB_BUILD_OPTIONS=nocheck sbuild --profiles=nocheck , and am pleased 
to report that singular and pynac built (including tests) successfully.

If the flint maintainer doesn't fix this "soon" then perhaps we can just 
disable that one test for the short-term to allow this transition to go forward.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#873883: kde-style-oxygen-qt5: completely broken during current transition

[Salvo Tomaselli]

Package: kde-style-oxygen-qt5
Version: 4:5.10.5-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,
Since the current transition going on for Qt, this package is completely
useless.

Every application is using the breeze style, even if in the system settings
preview, it looks correctly like oxygen.

Best

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

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

Versions of packages kde-style-oxygen-qt5 depends on:
ii  libc62.24-17
ii  libkf5completion55.28.0-1
ii  libkf5configcore55.28.0-2
ii  libkf5configgui5 5.28.0-2
ii  libkf5configwidgets5 5.28.0-2
ii  libkf5coreaddons55.28.0-2
ii  libkf5guiaddons5 5.28.0-1
ii  libkf5i18n5  5.28.0-2
ii  libkf5kcmutils5  5.28.0-2
ii  libkf5style5 5.28.0-1
ii  libkf5windowsystem5  5.28.0-2
ii  liboxygenstyle5-54:5.10.5-1
ii  liboxygenstyleconfig5-5  4:5.10.5-1
ii  libqt5core5a 5.9.1+dfsg-9
ii  libqt5dbus5  5.9.1+dfsg-9
ii  libqt5gui5   5.9.1+dfsg-9
ii  libqt5quick5 5.9.1-5
ii  libqt5widgets5   5.9.1+dfsg-9
ii  libqt5x11extras5 5.7.1~20161021-2
ii  libstdc++6   7.2.0-1
ii  libxcb1  1.12-1

kde-style-oxygen-qt5 recommends no packages.

kde-style-oxygen-qt5 suggests no packages.

-- no debconf information

Bug#861617: Fwd: Re: Bug#861617: RFS: ddcutil/0.8.0-6 [ITP] - control monitor settings

[Sanford Rockowitz]

Should have been sent to the entire list.


 Forwarded Message 
Subject: 	Re: Bug#861617: RFS: ddcutil/0.8.0-6 [ITP] - control monitor 
settings

Date:   Thu, 31 Aug 2017 14:41:21 -0400
From:   Sanford Rockowitz 
Organization:   Minaret Software
To: Andrey Rahmatullin 



I have uploaded a new copy of ddcutil, with a modified
debian/changelog.  It closes bug 858510, the original ITP bug,  not the
blocker 861617.  I hope this was the correct choice.

Sanford


On 08/31/2017 01:57 PM, Andrey Rahmatullin wrote:

On Thu, Aug 31, 2017 at 01:35:33PM -0400, Sanford Rockowitz wrote:

I assume you mean replace the dummy "Packaged for debian-mentors
submission." entry and update the timestamp.

Yes, and as I've said, and lintian have told you, you should have done it
at the very beginning.

There are 2 changelog related messages from lintian:

P: ddcutil: no-upstream-changelog

  As I wrote, that file (/usr/share/doc/ddcutil/ChangeLog) will be added in
the next upstream point release.

We were talking about the Debian changelog, why did you suddenly switch to
the upstream one?


W: ddcutil: new-package-should-close-itp-bug

  Your comment on this message was to ignore the warning for now:

 You don't write a separate changelog entry for a mentors "upload".

I didn't mean that, I meant you should write the correct changelog entry
from the very beginning and don't write a stub for a mentors "upload"
(because there is no such thing as a mentors upload wrt debian/changelog).


Can you give some guidance as to what should be in the initial changelog
entry?   Thanks.

* Initial release. (Closes: #NN)

I'm going to interpret the "it" that I should have done as being the
upstream changelog.

:-/

Bug#853568: No idea how to fix abs arguments in nanopolish

[Andreas Tille]

Hi,

to fix bug #853568 I tried a patch (gcc-7.patch) to fix abs() arguments
in nanopolish[1] but I have no idea how to deal with this:

...
g++ -o src/hmm/nanopolish_pore_model_set.o -c -g -O2 
-fdebug-prefix-map=/build/nanopolish-0.5.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -g -O3 -std=c++11 -fopenmp -Wdate-t
src/common/nanopolish_variant.cpp: In function 'std::vector 
extract_variants(const string&, const string&)':
src/common/nanopolish_variant.cpp:32:69: error: call of overloaded 
'abs(std::__cxx11::basic_string::size_type)' is ambiguous
 size_t difference = std::abs(reference.size() - haplotype.size());
 ^
In file included from /usr/include/c++/7/cstdlib:77:0,
 from /usr/include/c++/7/bits/stl_algo.h:59,
 from /usr/include/c++/7/algorithm:62,
 from src/common/nanopolish_variant.cpp:8:
/usr/include/c++/7/bits/std_abs.h:78:3: note: candidate: constexpr long double 
std::abs(long double)
   abs(long double __x)
   ^~~
/usr/include/c++/7/bits/std_abs.h:74:3: note: candidate: constexpr float 
std::abs(float)
   abs(float __x)
   ^~~
/usr/include/c++/7/bits/std_abs.h:70:3: note: candidate: constexpr double 
std::abs(double)
   abs(double __x)
   ^~~
/usr/include/c++/7/bits/std_abs.h:61:3: note: candidate: long long int 
std::abs(long long int)
   abs(long long __x) { return __builtin_llabs (__x); }
   ^~~
/usr/include/c++/7/bits/std_abs.h:56:3: note: candidate: long int std::abs(long 
int)
   abs(long __i) { return __builtin_labs(__i); }
   ^~~
In file included from /usr/include/c++/7/cstdlib:75:0,
 from /usr/include/c++/7/bits/stl_algo.h:59,
 from /usr/include/c++/7/algorithm:62,
 from src/common/nanopolish_variant.cpp:8:
/usr/include/stdlib.h:735:12: note: candidate: int abs(int)
 extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;
^~~
Makefile:98: recipe for target 'src/common/nanopolish_variant.o' failed


Any idea how to patch this?

Kind regards

 Andreas.

[1] https://anonscm.debian.org/git/debian-med/nanopolish.git

-- 
http://fam-tille.de

Bug#873830: geocode-glib FTBFS: Please switch to a UTF-8 locale for your platform.

[Jeremy Bicha]

Control: forwarded -1 https://github.com/mesonbuild/meson/issues/2268

Working around this…

Thanks,
Jeremy Bicha

Bug#873822: RFS: achilles/2-9 [QA]

[Tobias Frost]

Control: owner -1 !
Control: tags -1 moreinfo

Hallo David,

The package is already in a nice state; many thanks for updating it!

However some fixes are required:

- d/copyright needs fixing:
  - as it says "Copyright: ?"... I think it must be 
Copyright: 2000 Matthew Danish 
  - Also the License is GPL-2+
  - The license grant is not copied verbatimly 

- d/manpage is a stray file.

- Please (try to) fix those linitan warnings or evaluate if they are
valid:

W: achilles source: useless-autoreconf-build-depends autotools-dev
I: achilles source: debian-watch-file-is-missing
I: achilles: hardening-no-bindnow usr/bin/achilles
W: achilles: description-synopsis-starts-with-article
I: achilles: desktop-entry-contains-encoding-key
usr/share/applications/achilles.desktop:3 Encoding
I: achilles: desktop-entry-lacks-keywords-entry
usr/share/applications/achilles.desktop


--
tobi

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Jonathan Nieder]

Russ Allbery wrote:
> Sean Whitton  writes:
>> On Wed, Aug 23 2017, Russ Allbery wrote:

>>> --- a/policy/ch-controlfields.rst
>>> +++ b/policy/ch-controlfields.rst
>>> @@ -962,6 +962,10 @@ repository where the Debian source package is 
>>> developed.
>>> 
>>>  More than one different VCS may be specified for the same package.
>>> 
>>> +For both fields, any URLs given should use a scheme that provides
>>> +confidentiality (``https``, for example, rather than ``http`` or ``git``)
>>> +if the VCS repository supports it.
>>> +
>>>  .. _s-f-Package-List:
>>> 
>>>  ``Package-List``
[...]
> Maybe I should just say:
>
> a scheme that provides confidentiality and integrity protection

Seconded.

> I think I was over-thinking it.
>
> (That said, my understanding is that you don't get any meaningful
> integrity protection for Git from using https over http.)

As discussed elsewhere in this thread, it depends on how much you
trust (a) ca-certificates, versus (b) DNS.

The ideal is to use signed tags and check them.  (Or even better, to
work with git upstream to get push certs distributed properly and
check those.)

It would be nice to get something like chromium's certificate pinning
into curl, but that's a separate topic.

Thanks,
Jonathan

Bug#873792: qjackctl will not start at all

[Sebastian Ramacher]

Re-adding the bug to CC.

On 2017-08-31 16:02:13, Ed Peguillan III wrote:
> Sure.
> 
> |$ ldd -r /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5||
> ||linux-vdso.so.1 (0x7ffd883f3000)||
> ||libxcb-xinerama.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-xinerama.so.0
> (0x7f6ec82f9000)||
> ||libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
> (0x7f6ec7fe4000)||
> ||libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
> (0x7f6ec7da)||
> ||libfreetype.so.6 =>
> /usr/lib/x86_64-linux-gnu/freetype-infinality/libfreetype.so.6

And that's the issue. Please remove it and try again.

Cheers

> (0x7f6ec7aef000)||
> ||libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
> (0x7f6ec7388000)||
> ||libQt5DBus.so.5 => /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
> (0x7f6ec70fe000)||
> ||libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> (0x7f6ec69b5000)||
> ||libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f6ec6798000)||
> ||libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
> (0x7f6ec6458000)||
> ||libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1
> (0x7f6ec6256000)||
> ||libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6
> (0x7f6ec6046000)||
> ||libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6
> (0x7f6ec5e3e000)||
> ||libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6
> (0x7f6ec5c21000)||
> ||libxcb-xkb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-xkb.so.1
> (0x7f6ec5a05000)||
> ||libxcb-render-util.so.0 =>
> /usr/lib/x86_64-linux-gnu/libxcb-render-util.so.0 (0x7f6ec5801000)||
> ||libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0
> (0x7f6ec55f3000)||
> ||libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1
> (0x7f6ec53ec000)||
> ||libxcb-xfixes.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0
> (0x7f6ec51e4000)||
> ||libxcb-randr.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-randr.so.0
> (0x7f6ec4fd4000)||
> ||libxcb-image.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-image.so.0
> (0x7f6ec4dcf000)||
> ||libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0
> (0x7f6ec4bcb000)||
> ||libxcb-keysyms.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-keysyms.so.1
> (0x7f6ec49c8000)||
> ||libxcb-icccm.so.4 => /usr/lib/x86_64-linux-gnu/libxcb-icccm.so.4
> (0x7f6ec47c3000)||
> ||libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
> (0x7f6ec459b000)||
> ||libxcb-shape.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shape.so.0
> (0x7f6ec4397000)||
> ||libxkbcommon-x11.so.0 =>
> /usr/lib/x86_64-linux-gnu/libxkbcommon-x11.so.0 (0x7f6ec418f000)||
> ||libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0
> (0x7f6ec3f4f000)||
> ||libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x7f6ec3bd)||
> ||libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f6ec38cc000)||
> ||libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x7f6ec36b5000)||
> ||libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f6ec3318000)||
> ||libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3
> (0x7f6ec30a5000)||
> ||libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
> (0x7f6ec2e7a000)||
> ||libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f6ec2c6)||
> ||libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1
> (0x7f6ec29ee000)||
> ||libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16
> (0x7f6ec27bb000)||
> ||libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0
> (0x7f6ec2526000)||
> ||libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3
> (0x7f6ec22d6000)||
> ||libicui18n.so.57 => /usr/lib/x86_64-linux-gnu/libicui18n.so.57
> (0x7f6ec1e5c000)||
> ||libicuuc.so.57 => /usr/lib/x86_64-linux-gnu/libicuuc.so.57
> (0x7f6ec1ab4000)||
> ||libdouble-conversion.so.1 =>
> /usr/lib/x86_64-linux-gnu/libdouble-conversion.so.1 (0x7f6ec18a3000)||
> ||libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f6ec169f000)||
> ||/lib64/ld-linux-x86-64.so.2 (0x7f6ec87fe000)||
> ||libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
> (0x7f6ec148d000)||
> ||libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1
> (0x7f6ec1288000)||
> ||libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0
> (0x7f6ec1073000)||
> ||libxcb-util.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-util.so.0
> (0x7f6ec0e6c000)||
> ||libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
> (0x7f6ec0c68000)||
> ||libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
> (0x7f6ec0a62000)||
> ||libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0
> (0x7f6ec085f000)||
> ||libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0
> (0x7f6ec065c000)||
> ||libxshmfence.so.1 => 

Bug#873831: [debhelper-devel] Bug#873831: debhelper: [meson] Default to a UTF8 locale?

[Steve Langasek]

On Thu, Aug 31, 2017 at 10:41:18PM +0300, Jussi Pakkanen wrote:
> On Thu, Aug 31, 2017 at 5:37 PM, Jeremy Bicha  wrote:

> > I believe that meson assumes it's built using a UTF-8 locale. Is this
> > something we can have debhelper handle automatically for the meson
> > buildsystem?

> A more interesting question is why does Debian insist on using a
> default setting from 1968? Utf-8 has been around and used by default
> for 10+ years. Why is it not the default for package building by now?

Because the transition is fraught.  C.UTF-8 is now built and always
available as part of the libc package, but it's not built into the binary
and making libc itself treat it as a built-in default is problematic; which
means there's a need to configure C.UTF-8 on the system at install time as
the default.

It is the correct thing to do going forward; it's just a little unclear how
to get there cleanly.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#873882: src:python-jedi: please provide git repo with sources of Debian package

[Jochen Sprickerhof]

Package: src:python-jedi
Severity: minor

Dear Maintainer,

the package claims to provide the sources here:

https://anonscm.debian.org/cgit/python-modules/packages/python-jedi.git

(cf. https://packages.debian.org/source/sid/python-jedi)

Sadly this repo does not exist. Could you please provide a valid link to
your source repo?

Thanks!

Jochen


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

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

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Julien Puydt]

Hi,

Le 31/08/2017 à 14:48, Ximin Luo a écrit :

> eclib, giac, linbox succeeded but flint fails:
> 
> [..]
> make[3]: Entering directory '/<>'
> g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -I/<> -c 
> interfaces/NTL-interface.cpp -o build/interfaces/NTL-interface.o
> g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -I/<> 
> interfaces/test/t-NTL-interface.cpp build/interfaces/NTL-interface.o -o 
> build/interfaces/test/t-NTL-interface -L/<> -L/usr/local/lib 
> -L/usr/local/lib -L/usr/local/lib -lflint -lmpfr -lgmp -lm -lntl -lpthread 
> make[3]: Leaving directory '/<>'
> ZZ_to_fmpzPASS
> ZZX_to_fmpz_polyPASS
> ZZ_pX_to_fmpz_mod_polyPASS
> ZZ_pE_to_fqPASS
> ZZ_pEX_to_fq_polyPASS
> zz_pX_to_fmpz_mod_polyFAIL:
> f_poly1 = 61 40559  2065 31588 35949 5581 18565 23027 17733 40355 21583 29748 
> 34876 9541 13193 37235 25453 21973 26716 1397 32001 6909 21509 13786 20347 
> 3693 31431 1471 14890 19641 12608 1894 24849 8969 15639 30973 20096 8110 
> 30791 35078 29416 16789 35010 10460 34287 20737 768 35601 22276 17792 3619 
> 10427 1950 5016 21067 39969 274 29530 39547 13397 8480 1868 19224
> f_poly2 = 61 40559  -19790727 -303309173 -345202259 -53532299 -178238240 
> -221104641 -170248949 -387500890 -207234907 -285627289 -334901346 -91572681 
> -126652564 -357530909 -244383081 -210965945 -256508959 -13342514 -307283542 
> -66307056 -206504919 -132330231 -195352356 -35404314 -301808647 -14072502 
> -142955585 -188579709 -121015448 -18127979 -238583748 -86097788 -150133779 
> -297388174 -192959626 -77824611 -295644319 -336847976 -282464019 -161164677 
> -336158541 -100413624 -329223675 -199083394 -7299852 -341836210 -213885890 
> -170816716 -34714885 -100089185 -18655190 -48097958 -202287225 -383810407 
> -2554943 -283558998 -379754929 -128599192 -81393433 -17884651 -184564785
> zz_pE_to_fqFAIL:
> p = 31
> mod = x^2+19*x+12
> f1 = 20*a+16 - 2
> zzpe:[-418 -538]
> f2 = -538*a-418 - 2
> zz_pEX_to_fq_polyAborted
> Makefile:211: recipe for target 'check' failed
> make[2]: *** [check] Error 134
> [..]

I could reproduce the matter, asked upstream if it was known, and since
it wasn't:
https://github.com/wbhart/flint2/issues/372

Snark

Bug#871697: jellyfish: Please add arm64

[Andreas Tille]

Hi,

On Thu, Aug 31, 2017 at 09:24:48PM +0100, Edmund Grimley Evans wrote:
> > > Instead of:   "pand " off
> > > It should be: "pand " #off
> > 
> > please excuse my ignorance for ASM - but could you please simply send
> > me a corrected quilt patch.  I do not understand what you mean.
> 
> Modified file is attached.
> 
> (The '#' is just the C preprocessor stringification operator as I've
> changed the macro argument from string to integer constant.)

Sorry, but this patch does not apply.  You have recommended a change
of the *original* code.  That's no proper quilt patch.

Kind regards

  Andreas.

> Author: Edmund Grimley Evans 
> Last-Update: Thu, 10 Aug 2017 18:27:02 UTC
> Bug-Debian: https://bugs.debian.org/871697
> Description: Replace asm statements by C code to increase portability
> Note: Does not work as described - needs verification
> 
> --- a/include/jellyfish/rectangular_binary_matrix.hpp
> +++ b/include/jellyfish/rectangular_binary_matrix.hpp
> @@ -276,13 +276,20 @@ namespace jellyfish {
>  // #pragma GCC diagnostic pop
>  
>  // i is the lower 2 bits of x, and an index into the smear array. 
> Compute res ^= smear[i] & p[j].
> +#ifdef __x86_64__
>  #define AND_XOR(off)\
>  asm("movdqa (%[s],%[i]), %[load]\n\t"   \
>  "pand " #off "(%[p]),%[load]\n\t"   \
>  "pxor %[load],%[acc]\n\t"   \
>  : [acc]"="(acc)   \
>  : "[acc]"(acc),  [i]"r"(i), [p]"r"(p), [s]"r"(smear), 
> [load]"x"(load))
> -
> +#else
> +#define AND_XOR(off) do {   \
> +xmm_t a = { smear[i / 8], smear[i / 8 + 1] };   \
> +xmm_t b = { p[(off) / 8], p[(off) / 8 + 1] };   \
> +acc ^= a & b;   \
> +} while (0)
> +#endif
>  
>  uint64_t i, j = 0, x = 0;
>  for(unsigned int w = 0; w < nb_words(); ++w) {
> @@ -294,16 +301,16 @@ namespace jellyfish {
>}
>for( ; j > 7; j -= 8, p -= 8) {
>  i = (x & (uint64_t)0x3) << 4;
> -AND_XOR("0x30");
> +AND_XOR(0x30);
>  x >>= 2;
>  i = (x & (uint64_t)0x3) << 4;
> -AND_XOR("0x20");
> +AND_XOR(0x20);
>  x >>= 2;
>  i = (x & (uint64_t)0x3) << 4;
> -AND_XOR("0x10");
> +AND_XOR(0x10);
>  x >>= 2;
>  i = (x & (uint64_t)0x3) << 4;
> -AND_XOR("");
> +AND_XOR(0);
>  x >>= 2;
>}
>  }
> @@ -313,18 +320,19 @@ namespace jellyfish {
>  switch(j) {
>  case 6:
>i = (x & (uint64_t)0x3) << 4;
> -  AND_XOR("0x20");
> +  AND_XOR(0x20);
>x >>= 2;
>  case 4:
>i = (x & (uint64_t)0x3) << 4;
> -  AND_XOR("0x10");
> +  AND_XOR(0x10);
>x >>= 2;
>  case 2:
>i = (x & (uint64_t)0x3) << 4;
> -  AND_XOR("");
> +  AND_XOR(0);
>  }
>  
>  // Get result out
> +#ifdef __x86_64__
>  uint64_t res1, res2;
>  asm("movd %[acc], %[res1]\n\t"
>  "psrldq $8, %[acc]\n\t"
> @@ -332,6 +340,10 @@ namespace jellyfish {
>  : [res1]"=r"(res1), [res2]"=r"(res2)
>  : [acc]"x"(acc));
>  return res1 ^ res2;
> +#else
> +return acc[0] ^ acc[1];
> +#endif
> +
>}
>  #endif // HAVE_SSE
>  


-- 
http://fam-tille.de

Bug#873881: xfce4-whiskermenu-plugin: xfce-whiskermenu-plugin does not have mugshot as a recommended package

[Jason Lee Quinn]

Package: xfce4-whiskermenu-plugin
Version: 1.6.2-1
Severity: normal

Dear Maintainer,

The package xfce-whiskermenu-plugin does not recommend (or suggest) that the
mugshot package be installed.

This can lead to an error dialog when the profile picture is clicked saying

Failed to execute child process "mugshot" (No such file or directory)

   * What led up to the situation?
clicked on profile icon near user name in whisker menu

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
installed mugshot package

   * What was the outcome of this action?
clicking on profile picture launches mustshot


It is possible that the default profile application for XFCE
was changed to mugshot automatically when I installed some other
desktop. Somebody who has a vanilla XFCE desktop would be able
to say for sure. Nevertheless, since it is definitely possible
for mugshot to be the used profile manager, at a minimum
it should be a suggested package.



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

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

Versions of packages xfce4-whiskermenu-plugin depends on:
ii  libc6   2.24-11+deb9u1
ii  libcairo2   1.14.8-1
ii  libexo-1-0  0.10.7-1
ii  libgarcon-1-0   0.4.0-2
ii  libgcc1 1:6.3.0-18
ii  libgdk-pixbuf2.0-0  2.36.5-2
ii  libglib2.0-02.50.3-2
ii  libgtk2.0-0 2.24.31-2
ii  libstdc++6  6.3.0-18
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-3
ii  xfce4-panel 4.12.1-2

xfce4-whiskermenu-plugin recommends no packages.

xfce4-whiskermenu-plugin suggests no packages.

-- no debconf information

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Uwe Kleine-König]

Hello Christopher,

On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote:
> On Wed, Aug 30, 2017 at 1:36 PM, Uwe Kleine-König  
> wrote:
> >> >
> >> > diff --git a/validation/backend/sum.c b/validation/backend/sum.c
> >> > index 0604299..d0be8dd 100644
> >> > --- a/validation/backend/sum.c
> >> > +++ b/validation/backend/sum.c
> >> > @@ -1,3 +1,5 @@
> >> > +#define __powerpc64__
> >> > +#define _CALL_ELF 2
> >> >  #include 
> >> >  #include 
> >> >
> >> >
> >>
> >> Yep, sparse/sparsec do not define various macros that gcc/clang define
> >> by default on a given architecture. This is a known problem (that I have
> >> been meaning to fix ...). The 'workaround' for the time being is to use
> >> the cgcc front-end to sparse. (for example 'make CC=cgcc', or perhaps
> >> 'cgcc -no-compile').
> >>
> >> [You didn't mention your usage - is this for a kernel build?]
> >
> > This problem became visible during the make check phase when creating 
> > packaged
> > on the listed archs for horst[1]. You can see a build logs at
> >
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=horst=s390x=5.0-1=1503905687=0
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=horst=ppc64el=5.0-1=1503906226=0
> >
> > The error message looks identical (I checked the ppc64el log) to the
> > problem with backend/sum.c:
> >
> > sparse -g -O2 -fdebug-prefix-map=/<>=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -std=gnu99 -Wall 
> > -Wextra -g -I. -DDO_DEBUG -I/usr/include/libnl3 *.[ch]
> > /usr/include/powerpc64le-linux-gnu/gnu/stubs.h:8:12: error: unable 
> > to open 'gnu/stubs-32.h'
> 
> That is very much like on x86_64 missing define "#weak_define __x86_64__ 1"
> 
> Does cgcc work for you? In the future we do want to move the archetecture
> related define from cgcc into sparse by itself. For now you can set
> "sparse" as "cgcc -no-compile"

Yes that works. So to address the Debian bug I can do:

 - move sparse to /usr/lib
 - teach cgcc about the move of sparse
 - make /usr/bin/sparse call cgcc -no-compile "$@"

or is it easier to teach sparse about the architecture stuff?

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#873880: tiff: CVE-2017-13726

[Salvatore Bonaccorso]

Source: tiff
Version: 4.0.3-12.3
Severity: important
Tags: security upstream patch
Forwarded: http://bugzilla.maptools.org/show_bug.cgi?id=2727

Hi,

the following vulnerability was published for tiff.

CVE-2017-13726[0]:
| There is a reachable assertion abort in the function
| TIFFWriteDirectorySec() in LibTIFF 4.0.8, related to tif_dirwrite.c and
| a SubIFD tag. A crafted input will lead to a remote denial of service
| attack.

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-2017-13726
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13726
[1] http://bugzilla.maptools.org/show_bug.cgi?id=2727
[2] 
https://github.com/vadz/libtiff/commit/f91ca83a21a6a583050e5a5755ce1441b2bf1d7e

Regards,
Salvatore

Bug#872765: linux-image-4.13.0-rc7-amd64: further information

[Ricardo Fabian Peliquero]

Dear maintainer,

Please find attached further information regarding this bug:
strace, ltrace and ls output.

The problem is still present in 4.13.0-rc7-amd64.

Should you need any other test, please let me know.

Kindest regards,

Ricardo
# Non working mixer

; uname -a
Linux hp425 4.13.0-rc7-amd64 #1 SMP Debian 4.13~rc7-1~exp1 (2017-08-30) x86_64 
GNU/Linux

; LANG=en ls -l /dev/mixer
ls: cannot access '/dev/mixer': No such file or directory

; ls -l /dev/snd/
total 0
drwxr-xr-x 2 root root   80 ago 31 16:55 by-path
crw-rw 1 root audio 116,  5 ago 31 16:55 controlC0
crw-rw 1 root audio 116,  2 ago 31 16:55 controlC1
crw-rw 1 root audio 116,  8 ago 31 16:55 hwC0D0
crw-rw 1 root audio 116,  4 ago 31 16:55 hwC1D0
crw-rw 1 root audio 116,  7 ago 31 16:55 pcmC0D0c
crw-rw 1 root audio 116,  6 ago 31 16:55 pcmC0D0p
crw-rw 1 root audio 116,  3 ago 31 16:55 pcmC1D3p
crw-rw 1 root audio 116,  1 ago 31 16:55 seq
crw-rw 1 root audio 116, 33 ago 31 16:55 timer

; ls -l /dev/snd/by-path/
total 0
lrwxrwxrwx 1 root root 12 ago 31 16:55 pci-:00:14.2 -> ../controlC0
lrwxrwxrwx 1 root root 12 ago 31 16:55 pci-:01:05.1 -> ../controlC1

; LANG=en ltrace aumix -v 90
setlocale(LC_ALL, "")   = nil
bindtextdomain("aumix", "/usr/share/locale")= "/usr/share/locale"
textdomain("aumix") = "aumix"
access("/dev/mixer", 0) = -1
getopt(3, 0x7fffee92f958, "hILqSd:f:C:v:b:t:s:w:P:p:l:m:c:x"...) = 118
strchr("vbtswplmcxWrio123", 'v')= "vbtswplmcxWrio123"
open("/dev/sound/mixer", 2, 00) = -1
dcgettext(0, 0x55f64df0c4c4, 5, -104)   = 0x55f64df0c4c4
perror("aumix:  error opening mixer"aumix:  error opening mixer: No such file 
or directory
)   = 
fputc('\n', 0x7f63f0d6d520
) = 10
exit(1 
+++ exited (status 1) +++

; LANG=en strace aumix -v 90
execve("/usr/bin/aumix", ["aumix", "-v", "90"], [/* 17 vars */]) = 0
brk(NULL)   = 0x560d4c68c000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f134f875000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=77980, ...}) = 0
mmap(NULL, 77980, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f134f861000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libgpm.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\35\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=23056, ...}) = 0
mmap(NULL, 2119264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f134f44f000
mprotect(0x7f134f454000, 2093056, PROT_NONE) = 0
mmap(0x7f134f653000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7f134f653000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libncursesw.so.5", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240{\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=194496, ...}) = 0
mmap(NULL, 2290168, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f134f21f000
mprotect(0x7f134f24e000, 2093056, PROT_NONE) = 0
mmap(0x7f134f44d000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2e000) = 0x7f134f44d000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\316\0\0\0\0\0\0"..., 832) = 
832
fstat(3, {st_mode=S_IFREG|0644, st_size=170784, ...}) = 0
mmap(NULL, 2267936, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f134eff5000
mprotect(0x7f134f01b000, 2093056, PROT_NONE) = 0
mmap(0x7f134f21a000, 20480, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7f134f21a000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\4\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1681176, ...}) = 0
mmap(NULL, 3787104, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f134ec58000
mprotect(0x7f134edeb000, 2097152, PROT_NONE) = 0
mmap(0x7f134efeb000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x193000) = 0x7f134efeb000
mmap(0x7f134eff1000, 14688, PROT_READ|PROT_WRITE, 

Bug#873754: stretch-pu: package flightgear/1:2016.4.4+dfsg-3+deb9u1

[Markus Wanner]

Hi,

sorry for initially messing up the release names. This issue and the
attached debdiff should target stretch alias stable.

I just filed another similar issue for jessie: #873877.

Unstable already got the security fix with 1:2017.2.1+dfsg-4. The
original security issue reported by Florent is #873439 (CVE-2017-13709 [0]).

Kind Regards

Markus Wanner


[0]:
https://security-tracker.debian.org/tracker/CVE-2017-13709



signature.asc
Description: OpenPGP digital signature

Bug#873783: wcc: FTBFS on non-amd64 architectures

[Philippe Thierry]

Le 31/08/2017 à 21:58, Aaron M. Ucko a écrit :

> Great, thanks for looking into all of these subissues!
>
Well... sorry for the false positive news but wsh needs big update to
support other arches.
It is based on a ldscript used to map relocated content which is arch
specific. This ldscript has been made only for amd64.
I can try to make one or two more, but not for all the arches !

I will push an issue to Jonathan in mainstream to discuss this with him.
It would be great to have at least arm* & powerpc (personal choice of
course :) )

In the meantime, I've updated to amd64 only. it should work on
hurd/kfreebsd now.

-- 
 OPhilippe Thierry.
/Y\/  Hardened embedded systems
o#o   GPG: 7010 9A3C E210 763E 6341  4581 C257 B91B CDAF C1EA




signature.asc
Description: OpenPGP digital signature

Bug#873879: tiff: CVE-2017-13727

[Salvatore Bonaccorso]

Source: tiff
Version: 4.0.3-12.3
Severity: important
Tags: patch security upstream
Forwarded: http://bugzilla.maptools.org/show_bug.cgi?id=2728

Hi,

the following vulnerability was published for tiff.

CVE-2017-13727[0]:
| There is a reachable assertion abort in the function
| TIFFWriteDirectoryTagSubifd() in LibTIFF 4.0.8, related to
| tif_dirwrite.c and a SubIFD tag. A crafted input will lead to a remote
| denial of service attack.

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-2017-13727
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13727
[1] http://bugzilla.maptools.org/show_bug.cgi?id=2728
[2] 
https://github.com/vadz/libtiff/commit/b6af137bf9ef852f1a48a50a5afb88f9e9da01cc

Regards,
Salvatore

Bug#871348: robocode FTBFS

[Emmanuel Bourg]

Le 31/08/2017 à 13:12, Markus Koschany a écrit :

> The error message indicates some kind of problem with plexus-utils which
> is outdated and does not ship the MatchPatterns class. I'm not sure how
> this is all related to the maven-dependency-plugin but maybe an upgrade
> to the latest upstream release of plexus-utils will resolve #871348 ?

libmaven-dependency-plugin-java depends on libplexus-utils-java, but the
plugin actually depends on plexus-utils 3.0.9, so the
libplexus-utils2-java package should have been used instead. I wonder
how this managed to work previously :) I've modified locally
maven-dependency-plugin and this error goes away (I'll upload it
shortly), but then another error appears:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:3.0.0:single
(make-assembly) on project robocode.distribution: Failed to create
assembly: Error creating assembly archive src: Cannot transform line
endings on this kind of file: robocode-1.9.2.6/robocode.dummy.zip
[ERROR] Doing so is more or less guaranteed to destroy the file, and it
indicates a problem with your assembly descriptor.
[ERROR] This error message is new as of 2.5.3.
[ERROR] Earlier versions of assembly-plugin will silently destroy your
file. Fix your descriptor

Emmanuel Bourg

Bug#873878: glusterfs-client: mount.glusterfs needs bash as /bin/sh

[Michael Lundkvist]

Package: glusterfs-client
Version: 3.12.0-1
Severity: serious
Tags: upstream
Justification: Policy 10.4

Version 3.12 of Glusterfs adds code in /sbin/mount.glusterfs that depends on 
bash.

With dash as /bin/sh, I get the following error message when trying to mount a 
glusterfs volume:
> /sbin/mount.glusterfs: 667: /sbin/mount.glusterfs: Bad substitution

Line 667 is:
667 [ ${volume_str:0:1} = '/' ] && {

Modifying mount.glusterfs to use /bin/bash makes it possible to mount again.

/Micke


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

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

Versions of packages glusterfs-client depends on:
ii  fuse  2.9.7-1
ii  glusterfs-common  3.12.0-1
ii  libc6 2.24-17
ii  libssl1.1 1.1.0f-5
ii  python2.7.13-2

glusterfs-client recommends no packages.

glusterfs-client suggests no packages.

-- no debconf information

Bug#873783: wcc: FTBFS on non-amd64 architectures

[Aaron M. Ucko]

Philippe Thierry  writes:

> I will make some more tests on various arches including CI). If
> everything is okay I update the package.

Great, thanks for looking into all of these subissues!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#873450: MPI_Init in C also fails [Re: Bug#873450: openmpi: MPI_init in fortran fails on kfreebsd-amd64]

[Boud Roukema]

This is not a pure fortran bug: the same error occurs for a C
even-less-than-hello-world program. These tests are on a different machine,
again on a physical partition. The fortran error is unchanged.

++ cat /etc/debian_version
buster/sid

++ uname -vorsmpi
GNU/kFreeBSD 10.3-0-amd64 #0 Fri Jan 20 17:41:38 UTC 2017 x86_64 amd64 Intel(R) 
Core(TM) i7-4770K CPU @ 3.50GHz GNU/kFreeBSD

++ dpkg -l | egrep 'gcc|mpi'
ii  g++  4:7.1.0-2  
kfreebsd-amd64 GNU C++ compiler
ii  g++-77.2.0-2
kfreebsd-amd64 GNU C++ compiler
ii  gcc  4:7.1.0-2  
kfreebsd-amd64 GNU C compiler
ii  gcc-5-base:kfreebsd-amd645.4.1-5
kfreebsd-amd64 GCC, the GNU Compiler Collection (base package)
ii  gcc-6-base:kfreebsd-amd646.4.0-4
kfreebsd-amd64 GCC, the GNU Compiler Collection (base package)
ii  gcc-77.2.0-2
kfreebsd-amd64 GNU C compiler
ii  gcc-7-base:kfreebsd-amd647.2.0-2
kfreebsd-amd64 GCC, the GNU Compiler Collection (base package)
ii  gfortran 4:7.1.0-2  
kfreebsd-amd64 GNU Fortran 95 compiler
ii  gfortran-7   7.2.0-2
kfreebsd-amd64 GNU Fortran compiler
ii  libb-hooks-endofscope-perl   0.21-1 all 
   module for executing code after a scope finished compilation
ii  libgcc-7-dev:kfreebsd-amd64  7.2.0-2
kfreebsd-amd64 GCC support library (development files)
ii  libgcc1:kfreebsd-amd64   1:7.2.0-2  
kfreebsd-amd64 GCC support library
ii  libmagic-mgc 1:5.31-1   
kfreebsd-amd64 File type determination library using "magic" numbers (compiled 
magic file)
ii  libopenmpi-dev   2.1.1-6+b1 
kfreebsd-amd64 high performance message passing library -- header files
ii  libopenmpi2:kfreebsd-amd64   2.1.1-6+b1 
kfreebsd-amd64 high performance message passing library -- shared library
ii  make 4.1-9  
kfreebsd-amd64 utility for directing compilation
ii  mpi-default-bin  1.9
kfreebsd-amd64 Standard MPI runtime programs (metapackage)
ii  mpi-default-dev  1.9
kfreebsd-amd64 Standard MPI development files (metapackage)
ii  openmpi-bin  2.1.1-6+b1 
kfreebsd-amd64 high performance message passing library -- binaries
ii  openmpi-common   2.1.1-6all 
   high performance message passing library -- common files

++ gcc --version
gcc (Debian 7.2.0-2) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


++ cat mpi_include_mpi_h_detect.c
#include 
int main(int argc,
 char** argv){
  MPI_Init(NULL,NULL);
  MPI_Finalize();
  return 0;
}

++ rm -f a.out

++ mpicc --showme
gcc -I/usr/lib/x86_64-kfreebsd-gnu/openmpi/include/openmpi 
-I/usr/lib/x86_64-kfreebsd-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent
 
-I/usr/lib/x86_64-kfreebsd-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include
 -I/usr/lib/x86_64-kfreebsd-gnu/openmpi/include -pthread -L/usr//lib 
-L/usr/lib/x86_64-kfreebsd-gnu/openmpi/lib -lmpi

++ mpicc --verbose mpi_include_mpi_h_detect.c
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-kfreebsd-gnu/7/lto-wrapper
Target: x86_64-kfreebsd-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-2' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-7 
--program-prefix=x86_64-kfreebsd-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --disable-libitm --disable-libsanitizer 
--enable-plugin --enable-default-pie --with-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-kfreebsd-gnu 
--host=x86_64-kfreebsd-gnu --target=x86_64-kfreebsd-gnu
Thread model: posix
gcc version 7.2.0 

Bug#870987: Bug#814176: Bug#793492: Bug#814176: azureus: (Build-)Depends on OpenJDK 7

[Emmanuel Bourg]

Le 27/08/2017 à 00:07, Scott Kitterman a écrit :

> I would like to give Emmanuel time to respond to this.  I've tagged the bug 
> moreinfo to hold on on processing it for the moment.  If Emmanuel agrees to 
> the removal or we don't hear back in two weeks, then go ahead and remove the 
> moreinfo tag and I'll process the removal then.

I'm busy on another task for now but I plan to upload the current state
of the azureus repository when I'm done. The package builds fine, there
is still an issue with the embedded browser but downloading torrents works.

Emmanuel Bourg

Bug#873877: jessie-pu: package flightgear/3.0.0-5+deb8u3

[Markus Wanner]

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

Dear Release Team,

here's an update for jessie, fixing #873439 (CVE-2017-13709). It's based
on a patch and debdiff by Florent Rougon. The corresponding stretch-pu
request is #873754.

A bit about the security issue: Malicious add-ons could write arbitrary
user's files, possibly even executable ones. The fix is in two parts,
back-ported to older releases by Florent Rougon.

Please verify the attached debdiff for fixing the issue in jessie with
the next point release.

Kind Regards

Markus Wanner
diff -Nru flightgear-3.0.0/debian/changelog flightgear-3.0.0/debian/changelog
--- flightgear-3.0.0/debian/changelog   2017-07-02 14:39:08.0 +0200
+++ flightgear-3.0.0/debian/changelog   2017-08-31 09:09:03.0 +0200
@@ -1,3 +1,16 @@
+flightgear (3.0.0-5+deb8u3) jessie; urgency=high
+
+  [ Florent Rougon ]
+  * Add two patches for CVE-2017-13709:
+  - call-fgInitAllowedPaths-earlier-c7a2ae.patch (required by the next
+patch)
+  - CVE-2017-13709-FGLogger-2a5e3d.patch
+
+  [ Markus Wanner ]
+  * Massage patch meta information to fit DEP-3.
+
+ -- Markus Wanner   Thu, 31 Aug 2017 21:44:41 +0200
+
 flightgear (3.0.0-5+deb8u2) jessie; urgency=high
 
   * Add patch restrict-save-flightplan-secu-fix-faf872.patch: prevent
diff -Nru 
flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch 
flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch
--- 
flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch
1970-01-01 01:00:00.0 +0100
+++ 
flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch
2017-08-31 08:56:58.0 +0200
@@ -0,0 +1,54 @@
+Description: Call fgInitAllowedPaths earlier: after Options::processOptions
+ Call fgInitAllowedPaths() right after Options::processOptions() (which,
+ among other things, determines $FG_ROOT and processes
+ --allow-nasal-read). This way, fgInitAllowedPaths() can be used in much
+ more code, such as when initializing subsystems.
+ .
+ (cherry picked from commit c7a2aef59979af3e9ff22daabb37bdaadb91cd75)
+Forwarded: not-needed
+Author: Florent Rougon 
+
+--- a/src/Main/fg_init.cxx
 b/src/Main/fg_init.cxx
+@@ -1023,7 +1023,12 @@
+ fgGetNode("/sim")->removeChild("aircraft-dir");
+ fgInitAircraft(true);
+ flightgear::Options::sharedInstance()->processOptions();
+-
++
++// Rebuild the lists of allowed paths for cases where a path comes from an
++// untrusted source, such as the global property tree (this uses $FG_HOME
++// and other paths set by Options::processOptions()).
++fgInitAllowedPaths();
++
+ render = new FGRenderer;
+ render->setEventHandler(eventHandler);
+ globals->set_renderer(render);
+--- a/src/Main/main.cxx
 b/src/Main/main.cxx
+@@ -461,7 +461,12 @@
+ } else if (configResult == flightgear::FG_OPTIONS_EXIT) {
+ return EXIT_SUCCESS;
+ }
+-
++
++// Set the lists of allowed paths for cases where a path comes from an
++// untrusted source, such as the global property tree (this uses $FG_HOME
++// and other paths set by Options::processOptions()).
++fgInitAllowedPaths();
++
+ // Initialize the Window/Graphics environment.
+ fgOSInit(, argv);
+ _bootstrap_OSInit++;
+--- a/src/Scripting/NasalSys.cxx
 b/src/Scripting/NasalSys.cxx
+@@ -800,9 +800,6 @@
+   .member("singleShot", ::isSingleShot, ::setSingleShot)
+   .member("isRunning", ::isRunning);
+ 
+-// Set allowed paths for Nasal I/O
+-fgInitAllowedPaths();
+-
+ // Now load the various source files in the Nasal directory
+ simgear::Dir nasalDir(SGPath(globals->get_fg_root(), "Nasal"));
+ loadScriptDirectory(nasalDir);
diff -Nru flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch 
flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch
--- flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch
1970-01-01 01:00:00.0 +0100
+++ flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch
2017-08-31 08:57:36.0 +0200
@@ -0,0 +1,68 @@
+Description: Security: don't allow FGLogger to overwrite arbitrary files
+ Since the paths of files written by FGLogger come from the property
+ tree[1], they must be validated before we decide to write to these
+ files.
+ .
+ [1] Except for the "empty" case, which uses the default name
+ 'fg_log.csv'.
+ .
+ This fixes CVE-2017-13709.
+ .
+ (cherry picked from commit 2a5e3d06b2c0d9f831063afe7e7260bca456d679)
+Forwarded: not-needed
+Author: Florent Rougon 
+
+--- a/src/Main/logger.cxx
 b/src/Main/logger.cxx
+@@ -11,10 +11,14 @@
+ 
+ #include 
+ #include 
++#include 
+ 
+ #include 
++#include 
+ 
+ #include "fg_props.hxx"
++#include "globals.hxx"
++#include "util.hxx"
+ 
+ using 

Bug#873876: apt-cacher: File size mismatch error when downloading similar to #755184

[michael goff]

Package: apt-cacher
Version: 1.7.10+deb8u2
Severity: important

Dear Maintainer,

Greetings, I have the most current apt-cacher in the raspbian repository, using 
armhf.
I found ticket #755184 which seems to be the same problem but reported at a 
different version number. 
When trying to perform apt-get on a large package that is not in the cache the 
download will begin then fail and start over again, repetedly.
doing tail on the error file and watch on the file being downloaded the error 
msg happens at the same time as the file size being reset to 0B.
Wed Aug 30 02:07:26 2017|info [9904]: ALARM! 
/mnt/addon/apt-cacher-cache/packages/archive.raspberrypi.org_debian/wolfram-engine_11.0.1+2017031701_armhf.deb
 file size mismatch (found 5259264, expected 240084788). Renaming to 
/mnt/addon/apt-cacher-cache/packages/archive.raspberrypi.org_debian/wolfram-engine_11.0.1+2017031701_armhf.deb.corrupted.

I have squid and apt-cacher installed on the same server, at first I thought 
they were in conflict but with further anylsis squid is not involved at all. I 
tried to route the traffic through squid using http_proxy = 127.0.0.1:8080 and 
127.0.0.1:80 and 10.1.0.1:8080 and 10.1.0.1:80 but all of those attempts 
received a 503. Can apt-cacher use squid on the same server? I would like to 
use this feature while this bug is being looked at, maybe even perminently. 
What am I doing wrong with that? I changed the squid port to 8080 btw. The 
private address the server uses is 10.1.0.1.
The problem is reproducable on any large file. 

I can see that the debian distro has newer versions of the package than the 
raspbian distro does, should I assume that the raspbain distro just needs to be 
updated? can you assist with the proxy problem?

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l

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

Versions of packages apt-cacher depends on:
ii  debconf [debconf-2.0]  1.5.56+deb8u1
ii  ed 1.10-2
ii  libdpkg-perl   1.17.27
ii  libfilesys-df-perl 0.92-5+b1
ii  libfreezethaw-perl 0.5001-1
ii  libio-interface-perl   1.07-2+b1
ii  libipc-shareable-perl  0.61-1
ii  libnetaddr-ip-perl 4.075+dfsg-1+b1
ii  libsys-syscall-perl0.25-2+deb8u1
ii  libwww-curl-perl   4.17-1+b1
ii  libwww-perl6.08-1
ii  lsb-base   4.1+Debian13+rpi1+nmu1
pn  perl:any   
ii  ucf3.0030
ii  update-inetd   4.43

Versions of packages apt-cacher recommends:
ii  libberkeleydb-perl  0.54-2+b1

Versions of packages apt-cacher suggests:
pn  libio-socket-inet6-perl  

-- Configuration Files:
/etc/apt-cacher/apt-cacher.conf changed:
cache_dir = /mnt/addon/apt-cacher-cache
daemon_port = 3142
group = root
user = root
daemon_addr = 10.1.0.1
distinct_namespaces = 1
allowed_hosts = *
supported_archs = avr32, amd64, alpha, arm, arm64, armel, armhf, hppa, 
hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, m32r, m68k, mips, mipsel, 
netbsd-alpha, netbsd-i386, powerpc, powerpcspe, ppc64, s390, s390x, sh4, sparc, 
sparc64, x32
ubuntu_release_names = dapper, edgy, feisty, gutsy, hardy, intrepid, jaunty, 
karmic, lucid, maverick, natty, oneiric, precise, quantal, raring, saucy, 
trusty, utopic
generate_reports = 1


-- debconf information:
* apt-cacher/mode: daemon

Bug#873831: debhelper: [meson] Default to a UTF8 locale?

[Jussi Pakkanen]

On Thu, Aug 31, 2017 at 5:37 PM, Jeremy Bicha  wrote:

> I believe that meson assumes it's built using a UTF-8 locale. Is this
> something we can have debhelper handle automatically for the meson
> buildsystem?

A more interesting question is why does Debian insist on using a
default setting from 1968? Utf-8 has been around and used by default
for 10+ years. Why is it not the default for package building by now?

Bug#865180: On Big Endian support

[Kai Pastor, DG0YT]

Relevant upstream changes for Big Endian builds are

aed9a2d7d20d019c8cf5dff0d8e5edeee2b4d2d8
14a683b07b7657f766b84c6c67f9080bef8af7c5

Cf. 
https://github.com/OpenOrienteering/mapper/commits/14a683b07b7657f766b84c6c67f9080bef8af7c5/CMakeLists.txt

Bug#873875: qemu: CVE-2017-13711: Slirp: use-after-free when sending response

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.8+dfsg-6
Severity: normal

Hi,

the following vulnerability was published for qemu.

CVE-2017-13711[0]:
Slirp: use-after-free when sending response

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-2017-13711
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13711
[1] https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg05201.html
[2] http://www.openwall.com/lists/oss-security/2017/08/29/6

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#871697: jellyfish: Please add arm64

[Andreas Tille]

Hi Edmund,

On Thu, Aug 31, 2017 at 07:11:59PM +0100, Edmund Grimley Evans wrote:
> Instead of:   "pand " off
> It should be: "pand " #off

please excuse my ignorance for ASM - but could you please simply send
me a corrected quilt patch.  I do not understand what you mean.

> (It may be necessary to disable "-Werror": an unrelated issue.)

That's done in gcc-7.patch.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#873874: uim FTBFS with libanthy-dev 1:0.3-5

[Adrian Bunk]

Source: uim
Version: 1:1.8.6+gh20161003.0.d63dadd-4
Severity: serious
Tags: buster sid

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

...
checking anthy/anthy.h usability... yes
checking anthy/anthy.h presence... yes
checking for anthy/anthy.h... yes
checking for anthy_init in -lanthy... yes
checking for ANTHY_UTF8... no
...
   debian/rules override_dh_install
make[1]: Entering directory '/build/1st/uim-1.8.6+gh20161003.0.d63dadd'
install -d 
/build/1st/uim-1.8.6+gh20161003.0.d63dadd/debian/libuim-data/var/lib/uim
dh_install --sourcedir=debian/tmp
dh_install: Cannot find (any matches for) 
"usr/lib/*/uim/plugin/libuim-anthy-utf8.so" (tried in debian/tmp, debian/tmp)

dh_install: uim-anthy missing files: usr/lib/*/uim/plugin/libuim-anthy-utf8.so
dh_install: Cannot find (any matches for) 
"usr/share/uim/pixmaps/anthy-utf8.png" (tried in debian/tmp, debian/tmp)

dh_install: uim-anthy missing files: usr/share/uim/pixmaps/anthy-utf8.png
dh_install: missing files, aborting
debian/rules:68: recipe for target 'override_dh_install' failed
make[1]: *** [override_dh_install] Error 25
m

Bug#873873: banshee-community-extensions FTBFS with banshee 2.6.2-6.2

[Adrian Bunk]

Source: banshee-community-extensions
Version: 2.4.0-4
Severity: serious
Tags: buster sid

Some recent change in unstable makes banshee-community-extensions FTBFS:

https://tests.reproducible-builds.org/debian/history/banshee-community-extensions.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/banshee-community-extensions.html

...
Making all in Jamendo
make[4]: Entering directory 
'/build/1st/banshee-community-extensions-2.4.0/src/Jamendo'
/usr/bin/mono-csc \
-define:RELEASE \
 \
 \
-debug -target:library -out:../../bin/Banshee.Jamendo.dll \
 \
 -r:/usr/lib/banshee/Banshee.Core.dll 
-r:/usr/lib/banshee/Banshee.Services.dll 
-r:/usr/lib/banshee/Banshee.ThickClient.dll 
-r:/usr/lib/banshee/Banshee.WebBrowser.dll 
-r:/usr/lib/banshee/Banshee.Widgets.dll 
-r:/usr/lib/banshee/Hyena.Data.Sqlite.dll -r:/usr/lib/banshee/Hyena.Gui.dll 
-r:/usr/lib/banshee/Hyena.dll -r:/usr/lib/banshee/Mono.Media.dll 
-r:/usr/lib/banshee/MusicBrainz.dll 
-r:/usr/lib/cli/dbus-sharp-2.0/dbus-sharp.dll 
-r:/usr/lib/cli/dbus-sharp-glib-2.0/dbus-sharp-glib.dll 
-r:/usr/lib/cli/taglib-sharp-2.1/taglib-sharp.dll 
-r:/usr/lib/pkgconfig/../../lib/cli/Mono.Addins-0.2/Mono.Addins.dll 
-r:/usr/lib/pkgconfig/../../lib/cli/atk-sharp-2.0/atk-sharp.dll 
-r:/usr/lib/pkgconfig/../../lib/cli/gdk-sharp-2.0/gdk-sharp.dll 
-r:/usr/lib/pkgconfig/../../lib/cli/glib-sharp-2.0/glib-sharp.dll 
-r:/usr/lib/pkgconfig/../../lib/cli/gtk-sharp-2.0/gtk-sharp.dll 
-r:/usr/lib/pkgconfig/../../lib/cli/pango-sharp-2.0/pango-sharp.dll 
-r:ICSharpCode.SharpZipLib -r:Mono.Cairo -r:Mono.Posix -r:System  -r
 esource:./Jamendo.addin.xml,Jamendo.addin.xml  
-resource:./ThemeIcons/22x22/categories/jamendo.png,jamendo.png 
./Banshee.Jamendo/JamendoDownloadManager.cs ./Banshee.Jamendo/JamendoSource.cs 
./Banshee.Jamendo/JamendoView.cs ./Banshee.Jamendo/JamendoWebBrowserShell.cs 
../../src/AssemblyInfo.cs
error CS0006: Metadata file `/usr/lib/banshee/Banshee.WebBrowser.dll' could not 
be found
Compilation failed: 1 error(s), 0 warnings
Makefile:809: recipe for target '../../bin/Banshee.Jamendo.dll' failed
make[4]: *** [../../bin/Banshee.Jamendo.dll] Error 1



Likely due to:

banshee (2.6.2-6.2) unstable; urgency=medium

  * Non-maintainer upload.
  * Disable webkit features, the currently used library will not
be in buster. (Closes: #790198)

 -- Adrian Bunk   Tue, 15 Aug 2017 13:12:12 +0300

Bug#873821: wcc Depends: binutils (< 2.29) but 2.29-8 is to be installed

[Philippe Thierry]

Le 31/08/2017 à 20:56, Adrian Bunk a écrit :

> Sorry my bad, then a binNMU should be sufficient.
Yes this is the case here :-)

>
> But since you anyway plan an upload for #873783 this will en passant
> also fix this problem.
>
>> but if I update the package version (to 0.0.2+dfsg-2), the
>> upgrade test of piupart will also fails, while the -1 version of the
>> package is not rebuilt in the Debian ftp-master.
> There won't be any problems with piuparts when you upload 0.0.2+dfsg-2
Ok, I thought that a binNMU was first required to make it work first.
I'll then wait a little to finish the update to close #873783 in the
same time.

Thanks,

-- 
 OPhilippe Thierry.
/Y\/  Hardened embedded systems
o#o   GPG: 7010 9A3C E210 763E 6341  4581 C257 B91B CDAF C1EA




signature.asc
Description: OpenPGP digital signature

Bug#873784: libdazzle: FTBFS on mipsel and ppc64el: test-fuzzy-index fails

[Jeremy Bicha]

Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=787012

I have no clue about this one.

We need libdazzle for gnome-builder 3.26.

Thanks,
Jeremy Bicha

Bug#873872: font-manager FTBFS with vala 0.36

[Adrian Bunk]

Source: font-manager
Version: 0.7.3-1
Severity: serious
Tags: buster sid

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

...
UX/Models/CollectionModel.vala:108.38-108.43: error: Argument 1: Cannot convert 
from `Gee.ArrayList' to 
`Gee.Collection'
var sorted = sort_groups(groups);
 ^^
Compilation failed: 1 error(s), 0 warning(s)
Makefile:2116: recipe for target 'libfontmanager_la_vala.stamp' failed
make[2]: *** [libfontmanager_la_vala.stamp] Error 1

Bug#873871: imagemagick: CVE-2017-12875

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-11
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/659

Hi,

the following vulnerability was published for imagemagick.

CVE-2017-12875[0]:
| The WritePixelCachePixels function in ImageMagick 7.0.6-6 allows
| remote attackers to cause a denial of service (CPU consumption) via a
| crafted file.

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-2017-12875
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12875
[1] https://github.com/ImageMagick/ImageMagick/issues/659

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#873821: wcc Depends: binutils (< 2.29) but 2.29-8 is to be installed

[Adrian Bunk]

On Thu, Aug 31, 2017 at 08:43:35PM +0200, Philippe Thierry wrote:
> Hello!
> 
> Le 31/08/2017 à 16:01, Adrian Bunk a écrit :
> > Package: wcc
> > Version: 0.0.2+dfsg-1
> > Severity: serious
> >
> > The following packages have unmet dependencies:
> >  wcc : Depends: binutils (< 2.29) but 2.29-8 is to be installed
> Thanks for the report.
> 
> I've check where the error comes from. This is the result of the version
> of binutils dependency (<2.29) generated by dpkg-buildpackage. The
> source package only has a build dependency on binutils-dev (without
> explicit version).
> When building again the package, the Depends list is updated:
> 
> Depends: libbinutils (>= 2.29), libbinutils (<< 2.30), libc6 (>= 2.14), 
> libcapstone3 (>= 3.0.0), libelf1 (>= 0.142), liblua5.3-0, libopenlibm2 (>= 
> 0.4), lua5.2
> 
> This means that a simple rebuild of wcc with uptodate sid should correct
> the error,

Sorry my bad, then a binNMU should be sufficient.

But since you anyway plan an upload for #873783 this will en passant
also fix this problem.

> but if I update the package version (to 0.0.2+dfsg-2), the
> upgrade test of piupart will also fails, while the -1 version of the
> package is not rebuilt in the Debian ftp-master.

There won't be any problems with piuparts when you upload 0.0.2+dfsg-2

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#873870: Update to 2.0.10

[Amr Ibrahim]

Package: uget

Hello,

Please update uget to 2.0.10.

http://ugetdm.com/blog/6-news/85-new-stablebeta-releases-of-uget-plus-new-website-coming-soon

  uGet 2.0.10: (2017-08-24)

 User can use sorting in any category and status.
 curl plug-in: It can use ftruncate() to create large file.
 Fix: uGet doesn't close File Descriptor when saving config file.
 add translation files.


uGet 2.0.9: (2017-02-18)

 Use character ↓/↑ to replace D:/U: to display speed.
 avoid configure file corrupted on sudden shutdown.
 curl plug-in: crashes when download file > 4GB.
 Fix: program will move download to incorrect position if user 
switch to offline mode.
 Fix: Segmentation fault after pressing delete key on gtk window.
 Fix: Wayland hidden tray.
 update translation files.

Bug#726355: assaultcube: new upstream version of AssaultCube

[Jason Lee Quinn]

Package: assaultcube
Followup-For: Bug #726355


Assaultcube 1.1.x is DEAD. All players have moved on to the newer 1.2.x
servers. It is a waste of bandwidth and time to download this game from Debian.
Since the package is no longer maintained and is basically worthless, it should
be removed.



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

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

Versions of packages assaultcube depends on:
pn  assaultcube-data  
ii  libc6 2.24-11+deb9u1
ii  libgcc1   1:6.3.0-18
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libopenal11:1.17.2-4+b2
ii  libsdl-image1.2   1.2.12-5+b8
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libstdc++66.3.0-18
ii  libvorbisfile31.3.5-4
ii  libx11-6  2:1.6.4-3
ii  zlib1g1:1.2.8.dfsg-5

assaultcube recommends no packages.

assaultcube suggests no packages.

Bug#873783: wcc: FTBFS on non-amd64 architectures

[Philippe Thierry]

Le 31/08/2017 à 05:10, Aaron M. Ucko a écrit :
> Source: wcc
> Version: 0.0.2+dfsg-1
> Severity: important
> Tags: upstream
> Justification: fails to build from source
>
> Builds of wcc for architectures other than (Linux) amd64 have been
> failing.
>
> On non-x86 architectures, there are two considerations: the
> embedded copy of openlibm under src/wsh generally has no
> $(ARCH)/Make.files, and GCC doesn't support -masm=intel regardless.
> You could sidestep the former by building against separately packaged
> libopenlibm-dev (as called for by Policy 4.13), but the latter may be
> more of a problem.
Should be corrected by last update using libopenlibm-dev from Debian.
For non-Linux, I've updated to Architecture: linux-any by  now. I'll
check for Freebsd & Hurd in the meantime.
>
> On non-Linux architectures (kFreeBSD and presumably also the Hurd if
> and when clang becomes installable there), there's no 
> for arch.h to include.
>
> On i386, wsh somehow winds up compiled for the wrong architecture,
> leading to link errors:
>
>   /usr/bin/ld: skipping incompatible 
> /usr/lib/gcc/i686-linux-gnu/7/../../../i386-linux-gnu/libiberty.a when 
> searching for -liberty
>   /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu/libiberty.a when 
> searching for -liberty
>   /usr/bin/ld: cannot find -liberty
>
> On x32 (admittedly not a release architecture), wcc is still in the
> Needs-Build queue; I'm not sure what will happen there.
I will make some more tests on various arches including CI). If
everything is okay I update the package.

Cheers,

-- 
 OPhilippe Thierry.
/Y\/  Hardened embedded systems
o#o   GPG: 7010 9A3C E210 763E 6341  4581 C257 B91B CDAF C1EA




signature.asc
Description: OpenPGP digital signature

Bug#873869: deja-dup FTBFS with vala 0.36

[Adrian Bunk]

Source: deja-dup
Version: 34.3-1
Severity: serious
Tags: buster sid

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

...
build/1st/deja-dup-34.3/deja-dup/widgets/ConfigList.vala:336.39-336.42: error: 
Argument 1: Cannot pass value to reference or output parameter
  (model as Gtk.ListStore).remove(iter);
  
[ 51%] Built target deja-dup-nautilus
/build/1st/deja-dup-34.3/deja-dup/widgets/ConfigLocation.vala:400.18-400.21: 
error: Argument 1: Cannot pass value to reference or output parameter
store.remove(iter);
 
/build/1st/deja-dup-34.3/deja-dup/widgets/ConfigLocation.vala:405.22-405.29: 
error: Argument 1: Cannot pass value to reference or output parameter
store.remove(sep_iter);
 
...

Bug#873821: wcc Depends: binutils (< 2.29) but 2.29-8 is to be installed

[Philippe Thierry]

Hello!

Le 31/08/2017 à 16:01, Adrian Bunk a écrit :
> Package: wcc
> Version: 0.0.2+dfsg-1
> Severity: serious
>
> The following packages have unmet dependencies:
>  wcc : Depends: binutils (< 2.29) but 2.29-8 is to be installed
Thanks for the report.

I've check where the error comes from. This is the result of the version
of binutils dependency (<2.29) generated by dpkg-buildpackage. The
source package only has a build dependency on binutils-dev (without
explicit version).
When building again the package, the Depends list is updated:

Depends: libbinutils (>= 2.29), libbinutils (<< 2.30), libc6 (>= 2.14), 
libcapstone3 (>= 3.0.0), libelf1 (>= 0.142), liblua5.3-0, libopenlibm2 (>= 
0.4), lua5.2

This means that a simple rebuild of wcc with uptodate sid should correct
the error, but if I update the package version (to 0.0.2+dfsg-2), the
upgrade test of piupart will also fails, while the -1 version of the
package is not rebuilt in the Debian ftp-master.

-- 
 OPhilippe Thierry.
/Y\/  Hardened embedded systems
o#o   GPG: 7010 9A3C E210 763E 6341  4581 C257 B91B CDAF C1EA



signature.asc
Description: OpenPGP digital signature

Bug#873868: zeitgeist FTBFS with vala 0.36

[Adrian Bunk]

Source: zeitgeist
Version: 0.9.16-0.2
Severity: serious
Tags: buster sid

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

...
Making all in libzeitgeist
make[3]: Entering directory '/build/1st/zeitgeist-0.9.16/libzeitgeist'
/usr/bin/valac \
--target-glib=2.36 --pkg gio-2.0 --pkg gio-unix-2.0 --pkg sqlite3 
../config.vapi -C   --vapi zeitgeist-datamodel-2.0.vapi -H 
zeitgeist-datamodel.h --library zeitgeist-2.0  \
data-source.vala errors.vala mimetype.vala enumerations.vala event.vala 
subject.vala timerange.vala timestamp.vala ontology-uris.vala ontology.vala 
result-set.vala simple-result-set.vala utils.vala
timestamp.vala:79.34-79.40: error: The symbol `timeval' could not be found
var m_seconds = (int64) (timeval.tv_sec) * 1000;
 ^^^
Compilation failed: 1 error(s), 0 warning(s)
Makefile:1237: recipe for target 'libzeitgeist_datamodel_2_0_la_vala.stamp' 
failed
make[3]: *** [libzeitgeist_datamodel_2_0_la_vala.stamp] Error 1

Bug#861744: torbrowser-launcher: Should not be part of Stretch

[u]

Hello Roger,

Roger Shimizu:
> Dear Maintainer,
> 
> Is it time to upload backports of 0.2.7-3 to stretch?
> I'm also wondering why it didn't hit testing yet.

I agree with you and will take care of it this month.

Cheers!
u.

Bug#873866: tophat: Please add arm64

[Edmund Grimley Evans]

Source: tophat
Version: 2.1.1+dfsg-3
User: debian-...@lists.debian.org
Usertags: arm64

It seems to be possible to build this package on arm64.
Is there any reason why it would not work on arm64?