Bug#849440: udd: Please use HTTP 503 for "Current system load is too high"

[Niels Thykier]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd

Hi,

While using the UDD bugs interface today, I got a """Current system
load (49.52) is too high. Please retry later!""" error.

I noticed that it is returned with a "HTTP 200 OK" status, so
automatic processes will assume the request went well.  Furthermore,
you will always get HTML even if you request YAML[1], so any one
automatically processing gets "garbage" sent to their next step in the
pipeline due to this bug.

Thanks,
~Niels

[1] In the absence of a well-defined API for errors using an HTML
error page is fine (provided they are not served with a HTTP 20X
code).

Bug#849439: imagemagick: CVE-2016-10062: fwrite issue in ReadGROUP4Image

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.8.9.9-5
Severity: important
Tags: upstream security

Hi,

the following vulnerability was published for imagemagick. AFAICT,
this is not yet fixed up to the version in unstable. the CVE
assignment is at[1] and reads as:

> > Check return of write function
> > ==
> > 
> > Debian bug: https://bugs.debian.org/845196
> > Reference URL: https://security-tracker.debian.org/845196
> > Upstream commit:
> >   - 
> > https://github.com/ImageMagick/ImageMagick/commit/933e96f01a8c889c7bf5ffd30020e86a02a046e7
> >   - 
> > https://github.com/ImageMagick/ImageMagick/commit/4e914bbe371433f0590cefdf3bd5f3a5710069f9
> > Upstream issue: https://github.com/ImageMagick/ImageMagick/issues/196
> > Upstream version fixed: 7.0.1-10
> > 
> > The above fixes may be incomplete, according to the upstream issue. In
> > addition, the -6 branch seems to have an incomplete fix as well.
> 
> Use CVE-2016-10060 for the issue fixed in 
> 933e96f01a8c889c7bf5ffd30020e86a02a046e7.
> Use CVE-2016-10061 for the issue fixed in 
> 4e914bbe371433f0590cefdf3bd5f3a5710069f9.
> 
> Use CVE-2016-10062 for the fwrite issue in ReadGROUP4Image. This was
> specifically noted at the beginning of issues/196, but not fixed in
> either of these commits. It is not the same as the fputc issue in
> ReadGROUP4Image.

CVE-2016-10062[0]:
fwrite issue in ReadGROUP4Image

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-10062
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10062
[1] http://www.openwall.com/lists/oss-security/2016/12/26/9

Regards,
Salvatore

Bug#848859: Lowering the bug`s severity

[Anton Gladky]

severity 848859 minor
tags 848859 +unreproducible
thanks

Hi  Santiago,

thanks for your bugreport! I tried to reproduce the failing
test, building getfem on barriere.d,o 5 times but in all
cases it did not failed. Also the last upload of getfem was
successfully built on all supported platforms.

Nevertheless I am not closing the bug, but lowering its
severity for the case if the bug will appear again.

Best regards

Anton

Bug#849438: jessie-pu: package libfcgi-perl/0.77-1+deb8u1

[Salvatore Bonaccorso]

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

Hi SRM

Moritz Mühlenhoff suggested to fix CVE-2012-6687 for libfcgi-perl via
a point release (since it does not warrant a DSA). Attached is a
debdiff for libfcgi-perl as in stable.

Could you consider to have it included in the upcoming point release?

Regards,
Salvatore
diff -Nru libfcgi-perl-0.77/debian/changelog libfcgi-perl-0.77/debian/changelog
--- libfcgi-perl-0.77/debian/changelog	2014-08-12 23:13:41.0 +0200
+++ libfcgi-perl-0.77/debian/changelog	2016-12-27 08:06:30.0 +0100
@@ -1,3 +1,10 @@
+libfcgi-perl (0.77-1+deb8u1) jessie; urgency=medium
+
+  * Team upload.
+  * CVE-2012-6687: numerous connections cause segfault DoS (Closes: #815840)
+
+ -- Salvatore Bonaccorso   Tue, 27 Dec 2016 08:06:30 +0100
+
 libfcgi-perl (0.77-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru libfcgi-perl-0.77/debian/patches/CVE-2012-6687.patch libfcgi-perl-0.77/debian/patches/CVE-2012-6687.patch
--- libfcgi-perl-0.77/debian/patches/CVE-2012-6687.patch	1970-01-01 01:00:00.0 +0100
+++ libfcgi-perl-0.77/debian/patches/CVE-2012-6687.patch	2016-12-27 08:06:30.0 +0100
@@ -0,0 +1,85 @@
+Description: fix CVE-2012-6687 in bundled libfcgi
+Origin: https://bugs.launchpad.net/ubuntu/+source/libfcgi/+bug/933417
+Bug-Debian: https://bugs.debian.org/815840
+Forwarded: https://rt.cpan.org/Ticket/Display.html?id=118405
+Last-Update: 2016-12-27
+
+--- a/os_unix.c
 b/os_unix.c
+@@ -36,6 +36,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #ifdef HAVE_NETDB_H
+ #include 
+@@ -97,6 +98,9 @@
+ static int shutdownPending = FALSE;
+ static int shutdownNow = FALSE;
+ 
++static int libfcgiOsClosePollTimeout = 2000;
++static int libfcgiIsAfUnixKeeperPollTimeout = 2000;
++
+ void OS_ShutdownPending()
+ {
+ shutdownPending = TRUE;
+@@ -162,6 +166,16 @@
+ if(libInitialized)
+ return 0;
+ 
++char *libfcgiOsClosePollTimeoutStr = getenv( "LIBFCGI_OS_CLOSE_POLL_TIMEOUT" );
++if(libfcgiOsClosePollTimeoutStr) {
++libfcgiOsClosePollTimeout = atoi(libfcgiOsClosePollTimeoutStr);
++}
++
++char *libfcgiIsAfUnixKeeperPollTimeoutStr = getenv( "LIBFCGI_IS_AF_UNIX_KEEPER_POLL_TIMEOUT" );
++if(libfcgiIsAfUnixKeeperPollTimeoutStr) {
++libfcgiIsAfUnixKeeperPollTimeout = atoi(libfcgiIsAfUnixKeeperPollTimeoutStr);
++}
++
+ asyncIoTable = (AioInfo *)malloc(asyncIoTableSize * sizeof(AioInfo));
+ if(asyncIoTable == NULL) {
+ errno = ENOMEM;
+@@ -751,19 +765,16 @@
+ {
+ if (shutdown(fd, 1) == 0)
+ {
+-struct timeval tv;
+-fd_set rfds;
++struct pollfd pfd;
+ int rv;
+ char trash[1024];
+ 
+-FD_ZERO(&rfds);
++pfd.fd = fd;
++pfd.events = POLLIN;
+ 
+ do 
+ {
+-FD_SET(fd, &rfds);
+-tv.tv_sec = 2;
+-tv.tv_usec = 0;
+-rv = select(fd + 1, &rfds, NULL, NULL, &tv);
++rv = poll(&pfd, 1, libfcgiOsClosePollTimeout);
+ }
+ while (rv > 0 && read(fd, trash, sizeof(trash)) > 0);
+ }
+@@ -1113,13 +1124,11 @@
+  */
+ static int is_af_unix_keeper(const int fd)
+ {
+-struct timeval tval = { READABLE_UNIX_FD_DROP_DEAD_TIMEVAL };
+-fd_set read_fds;
+-
+-FD_ZERO(&read_fds);
+-FD_SET(fd, &read_fds);
++struct pollfd pfd;
++pfd.fd = fd;
++pfd.events = POLLIN;
+ 
+-return select(fd + 1, &read_fds, NULL, NULL, &tval) >= 0 && FD_ISSET(fd, &read_fds);
++return poll(&pfd, 1, libfcgiIsAfUnixKeeperPollTimeout) >= 0 && (pfd.revents & POLLIN);
+ }
+ 
+ /*
diff -Nru libfcgi-perl-0.77/debian/patches/series libfcgi-perl-0.77/debian/patches/series
--- libfcgi-perl-0.77/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ libfcgi-perl-0.77/debian/patches/series	2016-12-27 08:06:30.0 +0100
@@ -0,0 +1 @@
+CVE-2012-6687.patch

Bug#849251: dput: allow using sftp for uploads

[Pirate Praveen]

On ചൊവ്വ 27 ഡിസംബര്‍ 2016 12:34 വൈകു, Ben Finney wrote:
> On 27-Dec-2016, Pirate Praveen wrote:
> 
>> Changing method to sftp in ~/.dput.cf is seems to be working. Though
>> the documentation could be improved mentioning available methods.
> 
> The manual page ‘dput(1)’ mentions (in the “DESCRIPTION” section) the
> available methods. ‘sftp’ is not a method installed from the Debian
> package.
> 
> So I'm not sure how “Changing method to sftp in ~/.dput.cf” is working
> for you; there must be some changes from the Debian ‘dput’ package on
> the host you're using.
> 
> Can you conform the suggestions in this bug report work for you in a
> standard Debian host?

I'm using dput-ng.




signature.asc
Description: OpenPGP digital signature

Bug#849251: dput: allow using sftp for uploads

[Ben Finney]

On 27-Dec-2016, Pirate Praveen wrote:

> Changing method to sftp in ~/.dput.cf is seems to be working. Though
> the documentation could be improved mentioning available methods.

The manual page ‘dput(1)’ mentions (in the “DESCRIPTION” section) the
available methods. ‘sftp’ is not a method installed from the Debian
package.

So I'm not sure how “Changing method to sftp in ~/.dput.cf” is working
for you; there must be some changes from the Debian ‘dput’ package on
the host you're using.

Can you conform the suggestions in this bug report work for you in a
standard Debian host?

-- 
 \ “Too many pieces of music finish too long after the end.” —Igor |
  `\   Stravinskey |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849437: rsyncrypto: please indicate that libssl-dev needs to be >= 1.1.0

[Logan Rosen]

Package: rsyncrypto
Version: 1.13-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Dear Maintainer,

The upstream build system now checks that OpenSSL is 1.1.0 or greater, but the
build dependency still has a version check for libssl-dev >= 0.9.7.

In Ubuntu, the attached patch was applied to achieve the following:

  * Indicate that build dependency of libssl-dev needs to be >= 1.1.0.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: stretch/sid
  APT prefers yakkety-updates
  APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500, 
'yakkety'), (100, 'yakkety-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru rsyncrypto-1.13/debian/control rsyncrypto-1.13/debian/control
--- rsyncrypto-1.13/debian/control	2016-06-24 06:32:02.0 -0400
+++ rsyncrypto-1.13/debian/control	2016-12-27 01:41:00.0 -0500
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Shachar Shemesh 
-Build-Depends: debhelper (>= 9), libssl-dev (>= 0.9.7), libargtable2-dev, autotools-dev
+Build-Depends: debhelper (>= 9), libssl-dev (>= 1.1.0), libargtable2-dev, autotools-dev
 Standards-Version: 3.9.8.0
 Homepage: http://rsyncrypto.lingnu.com
 

Bug#849436: unblock: exim4/4.88~RC6-2

[Andreas Metzler]

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

Please shorten the waiting time for migration of exim4 to testing. This
package's version includes a fix for CVE-2016-9963 (stable's DSA 3747-1).

* Add macro IGNORE_SMTP_LINE_LENGTH_LIMIT to allow disabling the SMTP DATA
  physical line limit check for both for SMTP DATA ACL and remote_smtp*
  transports. Closes: #828801
  Also update corresponding NEWS entry.
* [lintian] debian/changelog: s/lenght/length/
* Pull 75_Fix-DKIM-information-leakage.patch from upstream GIT, fixing DKIM
  information leakage issue CVE-2016-9963.

unblock exim4/4.88~RC6-2

TIA, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .changes but not in first
-
-rw-r--r--  root/root   /usr/lib/debug/.build-id/0e/6ccd0a87df0978d44e8c56384725977293a6dd.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/41/1af8cce86cb5d33e1bdbb837691965bcf4bbe5.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/46/d0128b00d8487771080db604a216ffe5bbc4c9.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/8b/070c0099a8863f5af9e0dc6b4b8b30c882d5e3.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/a2/748941706aae40a4a467296db62bc5fbc5874e.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/b5/21f3139342b3cc5fefc9d5160d1c609170bdf2.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/bc/5c505fbec14f3a52727df50b7ed9a256a6896a.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/d6/5072ddeb66cc7ad6950e23e0ea5d2ea76f9015.debug

Files in first .changes but not in second
-
-rw-r--r--  root/root   /usr/lib/debug/.build-id/37/68bfb280763a8320ac0cb1b3f5128a6b2f7d50.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/67/180bb423dc99137f0dc7f115e46fa176414b9b.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/71/e8fbf0661a197ef7edf1a50faf9114d0551867.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/76/2c5a67771e75896543d5308d0f31e3a17102b1.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/a0/65508918ffd2a967a51fb0e172d0d85890798c.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/e0/2d1716e0c78e2d1fc27323ec0283c2048e0680.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/f0/aa82f38a765839ff6488981bb29adf9d0c7f4d.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/fc/0f8ff4895d18f4a3647db63921eba5887c1477.debug

Control files of package exim4: lines which differ (wdiff format)
-
Depends: debconf (>= 0.5) | debconf-2.0, debconf (>= 1.4.69) | cdebconf (>= 0.39), exim4-base (>= [-4.88~RC6-1),-] {+4.88~RC6-2),+} exim4-base (<< [-4.88~RC6-1.1),-] {+4.88~RC6-2.1),+} exim4-daemon-light | exim4-daemon-heavy | exim4-daemon-custom
Version: [-4.88~RC6-1-] {+4.88~RC6-2+}

Control files of package exim4-base: lines which differ (wdiff format)
--
Version: [-4.88~RC6-1-] {+4.88~RC6-2+}

Control files of package exim4-config: lines which differ (wdiff format)

Version: [-4.88~RC6-1-] {+4.88~RC6-2+}

Control files of package exim4-daemon-heavy: lines which differ (wdiff format)
--
Version: [-4.88~RC6-1-] {+4.88~RC6-2+}

Control files of package exim4-daemon-heavy-dbg: lines which differ (wdiff format)
--
Build-Ids: [-e02d1716e0c78e2d1fc27323ec0283c2048e0680-] {+a2748941706aae40a4a467296db62bc5fbc5874e+}
Version: [-4.88~RC6-1-] {+4.88~RC6-2+}

Control files of package exim4-daemon-light: lines which differ (wdiff format)
--
Version: [-4.88~RC6-1-] {+4.88~RC6-2+}

Control files of package exim4-daemon-light-dbg: lines which differ (wdiff format)
--
Build-Ids: [-3768bfb280763a8320ac0cb1b3f5128a6b2f7d50-] {+0e6ccd0a87df0978d44e8c56384725977293a6dd+}
Version: [-4.88~RC6-1-] {+4.88~RC6-2+}

Control files of package exim4-dbg: lines which differ (wdiff format)
-
Build-Ids: [-67180bb423dc99137f0dc7f115e46fa176414b9b 71e8fbf0661a197ef7edf1a50faf9114d0551867 762c5a67771e75896543d5308d0f31e3a17102b1 a065508918ffd2a967a51fb0e172d0d85890798c fc0f8ff4895d18f4a3647db63921eba5887c1477-] {+411af8cce86cb5d33e1bdbb837691965bcf4bbe5 46d0128b00d8487771080db604a216ffe5bbc4c9 8b070c0099a8863f5af9e0dc6b4b8b30c882d5e3 b521f3139342b3cc5fefc9d5160d1c609170bdf2 d65072ddeb66cc7ad69

Bug#849251: dput: allow using sftp for uploads

[Pirate Praveen]

On ചൊവ്വ 27 ഡിസംബര്‍ 2016 01:57 രാവിലെ, Ben Finney wrote:
>> Also, you could upload using scp (see the `ssh-upload` target in
>> dput), which is arguably even better than sftp.
> 
> Pirate, do either of these suggestions resolve the problem for you?

Changing method to sftp in ~/.dput.cf is seems to be working. Though the
documentation could be improved mentioning available methods.

For example manpage of dput and dput.cf should mention is. Also
/etc/dput.cf can add a commented entry for all supported methods.

There is only a passive mention of sftp method currently,

"ssh_config_options
   Not supported. Please switch to the sftp method which
supports your
   options from ssh_config(5) natively.
"

"method
   This command is mostly supported. However, there is no
support for
   the rsync method."

It can mention the supported methods are,  so and so




signature.asc
Description: OpenPGP digital signature

Bug#842895: mariadb-10.0: CVE-2016-6664 CVE-2016-5617

[Salvatore Bonaccorso]

Control: retitle 842895 mariadb-10.0: CVE-2016-6664
Control: clone 842895 -1
Control: reassign -1 src:mariadb-10.1
Control: retitle -1 mariadb-10.1: CVE-2016-6664

Hi Otto,

On Wed, Nov 02, 2016 at 07:27:40AM +0100, Salvatore Bonaccorso wrote:
> Source: mariadb-10.0
> Version: 10.0.16-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> 
> Hi,
> 
> the following vulnerabilities were published for mariadb-10.0.
> 
> CVE-2016-6664[0], which is a duplicate of CVE-2016-5617.
> 
> CVE-2016-5617[1]:
> | Unspecified vulnerability in Oracle MySQL 5.5.51 and earlier, 5.6.32
> | and earlier, and 5.7.14 and earlier allows local users to affect
> | confidentiality, integrity, and availability via vectors related to
> | Server: Error Handling.

FTR: The second CVE has been rejected in favour of CVE-2016-6664, so
retitling this bug accordingly to avoid confusions.

Since now mariadb-10.1 entered as well unstable, cloning this bug for
reference. I have though not (yet) checked if any of the other CVEs is
as well open with the 10.1.20 upstream release.

Regards,
Salvatore

Bug#849434: ii totem 3.0.1-8 not working after security updates

[Robert Thomas]

Package: ii totem
Version: 3.0.1-8

Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.82-1 i686 GNU/Linux

After i installed security updates 12/26/2016, totem crashes right after i
try to open it. I see a quick graphics of it and then it disappears. Vlc
media player 0.9-2 opens and stalls and won't close.
I'm using weezy 7.11
I have openshot video editor and kdenlive installed and they still work.
I also upgraded adobe flash player in firefox to version 24.0.0.186 the
other day and didn't use totem after that so it may have had something to
do with it but i think it was the security updates.
Please help me, i will mess around with it and see what i can do thanks.
Robert Lee Thomas raomby...@gamail.com

Can i undo the updates to fix it? Or would uninstalling totem and
reinstalling it be a solution?

>From /var/log/apt/history.log
Start-Date: 2016-12-26  21:16:39
Upgrade: exim4-config:i386 (4.80-7+deb7u3, 4.80-7+deb7u4), libnss3:i386
(3.26-1+debu7u1, 3.26-1+debu7u2), libicu48:i386 (4.8.1.1-12+deb7u5,
4.8.1.1-12+deb7u6), exim4-daemon-light:i386 (4.80-7+deb7u3, 4.80-7+deb7u4),
unzip:i386 (6.0-8+deb7u5, 6.0-8+deb7u6), imagemagick-common:i386
(6.7.7.10-5+deb7u9, 6.7.7.10-5+deb7u10), firefox-esr:i386
(45.5.1esr-1~deb7u1, 45.6.0esr-1~deb7u1), iceweasel:i386
(45.5.1esr-1~deb7u1, 45.6.0esr-1~deb7u1), libupnp6:i386 (1.6.17-1.2+deb7u1,
1.6.17-1.2+deb7u2), libgme0:i386 (0.5.5-2, 0.5.5-2+deb7u1),
libmagickcore5:i386 (6.7.7.10-5+deb7u9, 6.7.7.10-5+deb7u10),
libmagickcore5-extra:i386 (6.7.7.10-5+deb7u9, 6.7.7.10-5+deb7u10),
libmagick++5:i386 (6.7.7.10-5+deb7u9, 6.7.7.10-5+deb7u10), libgd2-xpm:i386
(2.0.36~rc1~dfsg-6.1+deb7u6, 2.0.36~rc1~dfsg-6.1+deb7u7),
libmagickwand5:i386 (6.7.7.10-5+deb7u9, 6.7.7.10-5+deb7u10), exim4:i386
(4.80-7+deb7u3, 4.80-7+deb7u4), imagemagick:i386 (6.7.7.10-5+deb7u9,
6.7.7.10-5+deb7u10), libservlet2.5-java:i386 (6.0.45+dfsg-1~deb7u3,
6.0.45+dfsg-1~deb7u5), exim4-base:i386 (4.80-7+deb7u3, 4.80-7+deb7u4),
perlmagick:i386 (6.7.7.10-5+deb7u9, 6.7.7.10-5+deb7u10), libnss3-1d:i386
(3.26-1+debu7u1, 3.26-1+debu7u2)
End-Date: 2016-12-26  21:18:08

Messages from /var/log/messages

Dec 26 13:13:06 debian kernel: [0.00]  BIOS-e820: 0010
- 5fe88c00 (usable)
Dec 26 13:13:06 debian kernel: [0.00]  BIOS-e820: 5fe88c00
- 5fe8ac00 (ACPI NVS)
Dec 26 13:13:06 debian kernel: [0.00]  BIOS-e820: 5fe8ac00
- 5fe8cc00 (ACPI data)
Dec 26 13:13:06 debian kernel: [0.00]  BIOS-e820: 5fe8cc00
- 6000 (reserved)
Dec 26 13:13:06 debian kernel: [0.00]  BIOS-e820: f000
- f400 (reserved)
Dec 26 13:13:06 debian kernel: [0.00]  BIOS-e820: fec0
- fed00400 (reserved)
Dec 26 13:13:06 debian kernel: [0.00]  BIOS-e820: fed2
- feda (reserved)
Dec 26 13:13:06 debian kernel: [0.00]  BIOS-e820: fee0
- fef0 (reserved)
Dec 26 13:13:06 debian kernel: [0.00]  BIOS-e820: ffb0
- 0001 (reserved)
Dec 26 13:13:06 debian kernel: [0.00] NX (Execute Disable)
protection: active
Dec 26 13:13:06 debian kernel: [0.00] SMBIOS 2.3 present.
Dec 26 13:13:06 debian kernel: [0.00] last_pfn = 0x5fe88
max_arch_pfn = 0x100

Bug#849433: dazzdb: FTBFS with ld --as-needed

[Logan Rosen]

Package: dazzdb
Version: 1.0+20160930-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Dear Maintainer,

dazzdb 1.0+20160930-1 fails to build in Ubuntu because the compiler-flags.patch 
adds libraries
to the linker options (LDFLAGS) instead of where library flags should be 
placed, at the end
(in LDLIBS).

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/compiler-flags.patch: Update to use LDLIBS instead of
LDFLAGS, fixing FTBFS with ld --as-needed.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: stretch/sid
  APT prefers yakkety-updates
  APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500, 
'yakkety'), (100, 'yakkety-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru dazzdb-1.0+20160930/debian/patches/compiler-flags.patch dazzdb-1.0+20160930/debian/patches/compiler-flags.patch
--- dazzdb-1.0+20160930/debian/patches/compiler-flags.patch	2016-10-12 04:35:47.0 -0400
+++ dazzdb-1.0+20160930/debian/patches/compiler-flags.patch	2016-12-27 00:49:32.0 -0500
@@ -2,13 +2,13 @@
 Author: Afif Elghraoui 
 Forwarded: no
 Last-Update: 2015-09-13
 dazzdb.orig/Makefile
-+++ dazzdb/Makefile
+--- a/Makefile
 b/Makefile
 @@ -1,6 +1,7 @@
  DEST_DIR = ~/bin
  
  CFLAGS += -O3 -Wall -Wextra -Wno-unused-result -fno-strict-aliasing
-+LDFLAGS += -lm
++LDLIBS += -lm
  
  ALL = fasta2DB DB2fasta quiva2DB DB2quiva DBsplit DBdust Catrack DBshow DBstats DBrm simulator \
fasta2DAM DAM2fasta DBdump rangen
diff -Nru dazzdb-1.0+20160930/debian/patches/rename-simulator.patch dazzdb-1.0+20160930/debian/patches/rename-simulator.patch
--- dazzdb-1.0+20160930/debian/patches/rename-simulator.patch	2016-10-12 04:35:47.0 -0400
+++ dazzdb-1.0+20160930/debian/patches/rename-simulator.patch	2016-12-27 00:49:42.0 -0500
@@ -7,7 +7,7 @@
 +++ dazzdb/Makefile
 @@ -3,7 +3,7 @@
  CFLAGS += -O3 -Wall -Wextra -Wno-unused-result -fno-strict-aliasing
- LDFLAGS += -lm
+ LDLIBS += -lm
  
 -ALL = fasta2DB DB2fasta quiva2DB DB2quiva DBsplit DBdust Catrack DBshow DBstats DBrm simulator \
 +ALL = fasta2DB DB2fasta quiva2DB DB2quiva DBsplit DBdust Catrack DBshow DBstats DBrm dsimulator \

Bug#845196: imagemagick 8:6.8.9.9-5+deb8u6 still vulnerable to Bug#845196

[Salvatore Bonaccorso]

Hi Antonie and Bastien,

On Tue, Dec 20, 2016 at 02:58:21PM -0500, Antoine Beaupré wrote:
> Hi secteam,
> 
> I believe the fix for bug#845196 shipped with DSA-3726-1 is incomplete,
> at least in stable. It does ship with this patch:
> 
> https://github.com/ImageMagick/ImageMagick/commit/1be809ae06f2fcb094836960edb707f81422e964
> 
> but not this one:
> 
> https://github.com/ImageMagick/ImageMagick/commit/933e96f01a8c889c7bf5ffd30020e86a02a046e7
> 
> so it is missing one fputc check in convert.
> 
> On 2016-12-20 13:34:03, Bastien Roucaries wrote:
> > Please reopen and.notify sécurity team
> 
> The bug report is actually still opened in stable, according to the BTS,
> so I don't believe a change is required there. I have removed the fixed
> marker from the security tracker and added a relevant note.

So for reference, CVEs were assigned for those. Actually as well one
more for the "fwrite issue in ReadGROUP4Image", we should fill that as
separate bugreport.

CVE assignment:
http://www.openwall.com/lists/oss-security/2016/12/26/9

> > Check return of write function
> > ==
> > 
> > Debian bug: https://bugs.debian.org/845196
> > Reference URL: https://security-tracker.debian.org/845196
> > Upstream commit:
> >   - 
> > https://github.com/ImageMagick/ImageMagick/commit/933e96f01a8c889c7bf5ffd30020e86a02a046e7
> >   - 
> > https://github.com/ImageMagick/ImageMagick/commit/4e914bbe371433f0590cefdf3bd5f3a5710069f9
> > Upstream issue: https://github.com/ImageMagick/ImageMagick/issues/196
> > Upstream version fixed: 7.0.1-10
> > 
> > The above fixes may be incomplete, according to the upstream issue. In
> > addition, the -6 branch seems to have an incomplete fix as well.
> 
> Use CVE-2016-10060 for the issue fixed in 
> 933e96f01a8c889c7bf5ffd30020e86a02a046e7.
> Use CVE-2016-10061 for the issue fixed in 
> 4e914bbe371433f0590cefdf3bd5f3a5710069f9.
> 
> Use CVE-2016-10062 for the fwrite issue in ReadGROUP4Image. This was
> specifically noted at the beginning of issues/196, but not fixed in
> either of these commits. It is not the same as the fputc issue in
> ReadGROUP4Image.

Regards,
Salvatore

Bug#849432: gdm3: CVE-2016-1000002: Information leak before screen lock

[Salvatore Bonaccorso]

Source: gdm3
Version: 3.14.1-7
Severity: important
Tags: upstream security
Forwarded: https://bugzilla.gnome.org/show_bug.cgi?id=753678

Hi,

the following vulnerability was published for gdm3. Filling the issue
so that we have a reference as well in the BTS. Laurent Bigonville
confirmed it is reproducible with different GPUs, so it might not be
only a glitch from the graphic stack.

CVE-2016-102[0]:
No description was found (try on a search engine)

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-102
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-102
[1] https://bugzilla.gnome.org/show_bug.cgi?id=753678
[2] https://bugzilla.gnome.org/show_bug.cgi?id=776051

Regards,
Salvatore

Bug#849431: daligner: FTBFS with ld --as-needed

[Logan Rosen]

Package: daligner
Version: 1.0+20160927-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Dear Maintainer,

daligner 1.0+20160927-1 fails to build in Ubuntu because the lddflags.patch 
adds libraries
to the linker options (LDFLAGS) instead of where library flags should be 
placed, at the end
(in LDLIBS).

See 
https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries 
for more
information.

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/lddflags.patch: Update to put libs in LDLIBS instead of
LDFLAGS, fixing FTBFS with ld --as-needed.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: stretch/sid
  APT prefers yakkety-updates
  APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500, 
'yakkety'), (100, 'yakkety-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru daligner-1.0+20160927/debian/patches/lddflags.patch daligner-1.0+20160927/debian/patches/lddflags.patch
--- daligner-1.0+20160927/debian/patches/lddflags.patch	2016-10-12 03:05:03.0 -0400
+++ daligner-1.0+20160927/debian/patches/lddflags.patch	2016-12-26 23:33:21.0 -0500
@@ -4,19 +4,19 @@
 Author: Afif Elghraoui 
 Forwarded: not-needed
 Last-Update: 2016-01-08
 daligner.orig/Makefile
-+++ daligner/Makefile
+--- a/Makefile
 b/Makefile
 @@ -1,43 +1,34 @@
  DEST_DIR = ~/bin
  
  CFLAGS += -O3 -Wall -Wextra -Wno-unused-result -fno-strict-aliasing
-+LDFLAGS += -lm
++LDLIBS += -lm
  
  ALL = daligner HPC.daligner LAsort LAmerge LAsplit LAcat LAshow LAdump LAcheck LAindex
  
  all: $(ALL)
  
-+daligner: LDFLAGS += -lpthread
++daligner: LDLIBS += -lpthread
  daligner: daligner.c filter.c filter.h align.c align.h DB.c DB.h QV.c QV.h
 -	gcc $(CFLAGS) -o daligner daligner.c filter.c align.c DB.c QV.c -lpthread -lm
  

Bug#849371: [Reportbug-maint] Bug#849371: reportbug: Version 7.1.1 crashes at launch

[Sandro Tosi]

control: severity -1 important
control: forcemerge 848692 -1

On Mon, Dec 26, 2016 at 5:23 AM, Jean-Luc Coulon (f5ibh)
 wrote:
>  File "/usr/lib/python3/dist-packages/reportbug/utils.py", line 316, in 
> get_user_id
>addr = email.utils.formataddr((realname, email))
> AttributeError: 'str' object has no attribute 'utils'

this has been reported already at 848692 and it's due to a punctuation
character in the name (`-` in your case), if you remove that (it is
just a workaround for now) you can start using reportbug again

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#836443: ocserv: Request for Jessie backport

[Aron Xu]

Control: tags -1 + pending

The backported package is in backports-NEW for 6 days, needing an
ftp-master to take care of it...

Cheers,
Aron

Bug#849430: quickfix: FTBFS on sparc64: many tests crash

[Aaron M. Ucko]

Source: quickfix
Version: 1.14.4+dfsg-1
Severity: important
Justification: fails to build from source (but built successfully in the past)

The build of quickfix for sparc64 (admittedly not a release
architecture) failed, as excerpted from
https://buildd.debian.org/status/fetch.php?pkg=quickfix&arch=sparc64&ver=1.14.4%2Bdfsg-1&stamp=1482756619
below.  Could you please take a look?

Thanks!

FAIL: check.sh
==

ut: no process found
at: no process found

  
C++/test/DataDictionaryTestCase.cpp:420: error: Failure in checkGroupCount: 
Unhandled exception: Crash!
C++/test/DataDictionaryTestCase.cpp:430: error: Failure in 
checkGroupRequiredFields: Unhandled exception: Crash!
C++/test/FieldConvertorsTestCase.cpp:235: error: Failure in 
utcTimeStampConvertTo: Unhandled exception: Crash!
C++/test/MessageSortersTestCase.cpp:104: error: Failure in groupOrder: 
Unhandled exception: Crash!
C++/test/MessagesTestCase.cpp:198: error: Failure in setStringWithGroup: 
Unhandled exception: Crash!
[...]
C++/test/MessagesTestCase.cpp:1167: error: Failure in newOrderCrossSetString: 
Unhandled exception: Crash!
C++/test/SessionTestCase.cpp:427: error: Failure in nextLogon: Unhandled 
exception: Crash!
[...]
C++/test/SessionTestCase.cpp:1383: error: Failure in initiatorLogonAtStartTime: 
Unhandled exception: Crash!
C++/test/SessionFactoryTestCase.cpp:53: error: Failure in 
startDayAndEndDayAreDifferent: Unhandled exception: Crash!
C++/test/SocketAcceptorTestCase.cpp:85: error: Failure in 
receivePartialMessage: Unhandled exception: Crash!
FAILURE: 58 out of 186 tests failed (58 failures).
Test time: 2.52 seconds.
  

FAIL check.sh (exit status: 58)

-- 
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#849429: quickfix: FTBFS on alpha: many numeric discrepancies

[Aaron M. Ucko]

Source: quickfix
Version: 1.14.4+dfsg-1
Severity: important
Justification: fails to build from source (but built successfully in the past)

The build of quickfix for alpha (admittedly not a release
architecture) failed, as excerpted from
https://buildd.debian.org/status/fetch.php?pkg=quickfix&arch=alpha&ver=1.14.4%2Bdfsg-1&stamp=1482759745.
below.  Could you please take a look?

Thanks!

FAIL: check.sh
==

ut: no process found
at: no process found

  
C++/test/DataDictionaryTestCase.cpp:430: error: Failure in 
checkGroupRequiredFields: Unhandled exception: Incorrect data format for value: 
9 99
C++/test/DictionaryTestCase.cpp:55: error: Failure in setGetInt: Unhandled 
exception in CHECK_EQUAL(9827362, object.getInt( "INTKEY2" ))
C++/test/FieldConvertorsTestCase.cpp:96: error: Failure in integerConvertTo: 
Expected 1234 but was 1134
C++/test/FieldConvertorsTestCase.cpp:97: error: Failure in integerConvertTo: 
Expected 12345 but was 12145
C++/test/FieldConvertorsTestCase.cpp:98: error: Failure in integerConvertTo: 
Expected 123456 but was 123156
C++/test/FieldConvertorsTestCase.cpp:99: error: Failure in integerConvertTo: 
Expected 1234567 but was 1234167
C++/test/FieldConvertorsTestCase.cpp:100: error: Failure in integerConvertTo: 
Expected 12345678 but was 12345178
C++/test/FieldConvertorsTestCase.cpp:101: error: Failure in integerConvertTo: 
Expected 123456789 but was 123456189
C++/test/FieldConvertorsTestCase.cpp:102: error: Failure in integerConvertTo: 
Expected 2147483647 but was 2147483147
C++/test/FieldConvertorsTestCase.cpp:107: error: Failure in integerConvertTo: 
Expected -1234 but was -1134
C++/test/FieldConvertorsTestCase.cpp:108: error: Failure in integerConvertTo: 
Expected -12345 but was -12145
C++/test/FieldConvertorsTestCase.cpp:109: error: Failure in integerConvertTo: 
Expected -123456 but was -123156
C++/test/FieldConvertorsTestCase.cpp:110: error: Failure in integerConvertTo: 
Expected -1234567 but was -1234167
C++/test/FieldConvertorsTestCase.cpp:111: error: Failure in integerConvertTo: 
Expected -12345678 but was -12345178
C++/test/FieldConvertorsTestCase.cpp:112: error: Failure in integerConvertTo: 
Expected -123456789 but was -123456189
C++/test/FieldConvertorsTestCase.cpp:113: error: Failure in integerConvertTo: 
Expected -2147483647 but was -2147483147
C++/test/SessionTestCase.cpp:1328: error: Failure in processQueuedMessages: 
Expected 5004 but was 1000
C++/test/SessionTestCase.cpp:1330: error: Failure in processQueuedMessages: 
Expected 2 but was 1
FAILURE: 4 out of 186 tests failed (18 failures).
Test time: 13.20 seconds.
  

FAIL check.sh (exit status: 18)

-- 
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#849428: quickfix: FTBFS: GarbledMessage tests sometimes (randomly?) fail

[Aaron M. Ucko]

Source: quickfix
Version: 1.14.4+dfsg-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of quickfix for many architectures failed due to bad outcomes
of GarbledMessage tests (one per affected architecture, but with
varying details, as summarized below).  Could you please take a look?

Thanks!

Specifically:

* On armel, fix50sp2/3c_GarbledMessage.def failed with "Broken pipe" on
  line 15.
* On armhf, fix50sp1/3c_GarbledMessage.def failed with "Broken pipe" on
  line 15.
* On i386, fix50sp2/3c_GarbledMessage.def failed with a field count
  mismatch on line 18.
* On mips and mipsel, fix50sp2/2d_GarbledMessage.def failed with
  "Broken pipe" on line 15.
* On s390x, fix50sp1/2d_GarbledMessage.def failed with a field count
  mismatch on line 18.
* On powerpc (admittedly no longer a release architecture),
  fix50sp2/3c_GarbledMessage.def failed with "Broken pipe" on line 15.

-- 
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#849419: libopenjfx-java: Description should clarify libopenjfx-java is not automatically on classpath without pkg openjfx

[tony mancill]

On Mon, Dec 26, 2016 at 09:38:09PM +, George Bateman wrote:
> An Ant build script for a Java package intended to be used with Oracle
> Java would not build, as it could not find the openjfx library. I had to
> modify the Ant script to add /usr/share/java/openjfx/jre/lib/ext/jfxrt.jar
> to its classpath manually, even though this would not have been necessary
> if I'd been using Oracle Java.
> 
> By experimentation I found out that the package openjfx had to be installed
> in addition to libopenjfx-java for the script to automatically be able
> to use the library without adding it to the classpath manually, but it
> should have been made clear on both packages' description pages that
> this was the case.

Hi George,

Thank you for reporting this issue.  I ran into the same problem with a
gradle-based package during the packaging of easybind.  I thought it
better to patch [1] the build system than to add a build-dep on openjfx.

I haven't looked into the openjfx/libopenjfx-java packaging yet, but I'm
wondering if we can either (a) fix this in libopenjfx-java, or (b) patch
up the Debian build toolchain to find the openjfx JARs.  I suspect we'll
see a big increase in the number of OpenJFX packages in the next release
cycle.

Cheers,
tony

[1] 
https://anonscm.debian.org/cgit/pkg-java/easybind.git/tree/debian/patches/01_build_gradle.patch


signature.asc
Description: PGP signature

Bug#840132: xrdp-sesman.service sometimes fails to start on boot

[David Gilmour]

Package: xrdp
Followup-For: Bug #840132

Dear Maintainer,

I have two systems on which xrdp fails to start at boot. On both
systems, subsequently running "systemctl start xrdp" always succeeds,
and if it is followed by "systemctl start xrdp-sesman", xrdp functions
normally and accepts sessions.

The systemd error report immediately after boot (before the successful
manual start) is as follows:

● xrdp.service - xrdp (X Remote Desktop Protocol) protocol server
   Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; vendor
preset: enabled)
   Active: inactive (dead) since Mon 2016-12-26 19:26:54 PST; 40min ago
 Docs: man:xrdp(8)
   man:xrdp.ini(5)
  Process: 1166 ExecStopPost=/bin/rm -rf /var/run/xrdp/sockdir
(code=exited, status=0/SUCCESS)
  Process: 1162 ExecStop=/usr/sbin/xrdp $XRDP_OPTIONS --kill
(code=exited, status=0/SUCCESS)
  Process: 856 ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS (code=exited,
status=0/SUCCESS)
  Process: 831 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup
(code=exited, status=0/SUCCESS)
 Main PID: 1100 (code=exited, status=0/SUCCESS)

Dec 26 19:26:51 pod systemd[1]: Starting xrdp (X Remote Desktop
Protocol) protocol server...
Dec 26 19:26:52 pod systemd[1]: xrdp.service: PID file
/run/xrdp/xrdp.pid not readable (yet?) after start: No such file or
directory
Dec 26 19:26:53 pod systemd[1]: Started xrdp (X Remote Desktop Protocol)
protocol server.
Dec 26 19:26:54 pod xrdp[1100]: (1100)(140648291601216)[INFO ] starting
xrdp with pid 1100
Dec 26 19:26:54 pod xrdp[1100]: (1100)(140648291601216)[ERROR]
xrdp_listen_main_loop: listen error, possible port already in use
Dec 26 19:26:54 pod xrdp[1100]: (1100)(140648291601216)[DEBUG] Closed
socket 11 (AF_INET6 :: port 0)

On the second system, the error message is different; the xrdp service
fails because of a timeout.  Both systems are on xrdp
0.9.1~2016121126+git5171fa7-1.

One thing possibly interesting about both systems is that they are both
kvm hosts.  After each system reaches network.target, the dependency for
starting xrdp in systemd, quite a bit of subsequent network
configuration takes place: virtual network interfaces, bridges,
wlan probing and more.  In other words, it's clear that xrdp is trying
to start in a system whose network configuration is still very much
underway.

Of course, in all cases, xrdp-sesman also fails to start, with the cause
being the failed dependency on xrdp.service.  For that reason I am
attaching to this bug.

- David

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

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

Versions of packages xrdp depends on:
ii  adduser  3.115
ii  init-system-helpers  1.46
ii  libc62.24-8
ii  libfuse2 2.9.7-1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libopus0 1.1.3-1
ii  libpam0g 1.1.8-3.3
ii  libssl1.11.1.0c-2
ii  libx11-6 2:1.6.4-2
ii  libxfixes3   1:5.0.3-1
ii  libxrandr2   2:1.5.1-1
ii  lsb-base 9.20161125

Versions of packages xrdp recommends:
ii  xorgxrdp  0.9.1~2016121126+git5171fa7-1

Versions of packages xrdp suggests:
pn  guacamole  

Versions of packages xorgxrdp depends on:
ii  libc6  2.24-8
pn  xorg-input-abi-24  
ii  xserver-xorg-core [xorg-video-abi-23]  2:1.19.0-2

Versions of packages xorgxrdp recommends:
ii  xorg  1:7.7+18

Versions of packages xrdp is related to:
pn  vnc-server  

-- no debconf information

Bug#849387: RFS: farmhash/0~20161014-g92e897b-1 [ITP]

[Adam Borowski]

Control: tags -1 +moreinfo

On Mon, Dec 26, 2016 at 03:23:22PM +, lumin wrote:
>   I am looking for a sponsor for my package "farmhash"
> 
>  * Package name: farmhash
>    Version : 0~20161014-g92e897b-1
>  * URL : https://github.com/google/farmhash

I'm afraid that the -dev package installs a lot of cruft to /usr/share/doc/,
this includes all the sources and test cases for the testsuite, instructions
how to run the testsuite, and so on.

That place is meant for user documentation, or possibly examples.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#849427: ITP: mpgrafic -- MPI version of N-body initial conditions grafic package

[Boud Roukema]

Package: wnpp
Severity: wishlist
Owner: Boud Roukema 

* Package name: mpgrafic
  Version : 0.3.2
  Upstream Author : Simon Prunet, Christophe Pichon, Boud Roukema
* URL : https://bitbucket.org/broukema/mpgrafic
* License : GPL-v2+
  Programming Lang: fortran
  Description : MPI version of N-body initial conditions grafic package
   mpgrafic produces initial conditions files for N-body simulations of
   cosmological large-scale structure formation. It is a free-licensed,
   MPI-parallelised, rewritten version of Ed Bertschinger's grafic-1
   program, producing output files in the grafic format. It includes
   options for an Eisenstein and Hu baryonic wiggles power spectrum, for
   using a low-resolution map for large-scale modes in the spirit of
   grafic-2, and together with constrfield, can be used for generating
   constrained initial conditions. Details are given in Prunet et al
   (2008) http://cdsads.u-strasbg.fr/abs/2008ApJS..178..179P.
 
   I would like to maintain this package together with the
   debian-astro team. I need a sponsor! I have a draft version of 
   the debian package nearly ready, but I still need the ITP number to
   do it properly.

Cheers
Boud

Bug#849426: [openvdb] Add python3 support

[Lars Kruse]

Package: openvdb
Version: 3.2.0-2.1
Severity: normal

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

Hello,

with v3.2 openvdb gained python3 support.
See the changelog:
 https://github.com/dreamworksanimation/openvdb/blob/v3.2.0/openvdb/CHANGES#L149
or the merged feature branch:
 
https://github.com/dreamworksanimation/openvdb/commit/4f5d7cb073bf1d798d5ed2044992d7d29ef09fc8

I would highly appreciate a python3 module for openvdb. Currently there is
only a python2 module.

Thank you for your time!

Cheers,
Lars

--- System information. ---
Architecture: 
Kernel:   Linux 4.8.0-1-686-pae

Debian Release: stretch/sid
  500 testing 192.168.2.12 

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

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#833037: python-factory-boy: missing depends on ipaddress

[Brian May]

Chris Lamb  writes:

> severity 833037 serious
> thanks
>
> Surely this bug is RC severity? :)
>
>> I'm surprised to see no resolution within 2 months of time for such an
>> easy bug to fix.
>>
>> Brian, if you don't want to take care of this package, I will ask for
>> its removal from Debian again. I have no time for it myself.
>
> This might be the time :)

Errr... If somebody wants me to fix a bug, it would be really could if
they could actually contact me. Thomas Goirand's email was never sent to
me - the email was sent to the BTS only, not me. I have a backlog right
now, will see what I can do.
-- 
Brian May 

Bug#849380: imagetoraster produces "Unsupported raster data"

[Till Kamppeter]

Fixed in upstream BZR rev. 7588.

Problem were bugs in the calculation of the page geometry in imagetoraster.

Thank you very much for the bug report.

Bug#781155: openbsd-inetd: openbsd-inetd.service should be the main service file

[Marco d'Itri]

On Apr 10, Michael Biebl  wrote:

> Ideally, the .service file name and sysv init script do match.
> If that is not the case, because upstream chose a different name, my
> recommendation is to create a symlink and ship that statically in the
> package, i.e. not create it via Alias=.
Such a link already exists.
Is there anything else that I should do or should I close this bug?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#849425: diffoscope: test_openssh_pub_key.test_diff fails on jessie after ssh-keygen output format change

[Brett Smith]

Source: diffoscope
Version: git as of 011987f
Severity: minor
Tags: upstream

On jessie, test_openssh_pub_key.test_diff fails like this:

=== FAILURES ===
__ test_diff ___

differences = []

@skip_unless_tools_exist('ssh-keygen')
def test_diff(differences):
expected_diff = open(data('openssh_pub_key_expected_diff')).read()
>   assert differences[0].unified_diff == expected_diff
E   assert '@@ -1 +1 @@\...2.pub (RSA)\n' == '@@ -1 +1 @@\n...Test2 (RSA)\n'
E   @@ -1 +1 @@
E - -1024 0a:57:8d:93:be:8b:5c:47:7a:b6:5c:91:16:87:cd:1e 
/home/brett/repos/diffoscope/tests/data/test_openssh_pub_key1.pub (DSA)
E - +4096 8a:a5:52:0a:3f:af:8d:2d:76:52:72:e1:a8:0a:a2:47 
/home/brett/repos/diffoscope/tests/data/test_openssh_pub_key2.pub (RSA)
E + -1024 SHA256:v/O+0ETvi2H5TGRXky1RhQ1/WFwLlPpxch5E2Mrj6FM Test1 (DSA)
E + +4096 SHA256:9dH1CMkA6DSfPWU7vNwdPKS5/ppN4LMdvHTP60l7aSA Test2 (RSA)

tests/comparators/test_openssh_pub_key.py:47: AssertionError
== 1 failed, 3 passed in 0.14 seconds ==

This happens because, since jessie, ssh-keygen has added the -E option to
specify the fingerprint hash algorithm, and defaulted it to SHA256.  Older
versions used the colon-separated format (md5?).

I was working on a patch for this, but unfortunately the right thing to do
isn't obvious.  Older versions of ssh-keygen, as in jessie, don't support
the -E option at all.  This makes it difficult to ensure diffoscope's
output is consistent regardless of the version of ssh-keygen on the
underlying host.

We could have the comparator try to specify -E md5, and then fall back to
omitting the -E option if that fails, but that seems a little regressive
since md5 is basically deprecated.

We could have the test sniff for the host's ssh-keygen version, and expect a
different diff based on when it started outputting sha256 fingerprints by
default, but that punts on the consistent output issue.

What do the maintainers think?

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

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

Bug#846002: blends-tasks must not be priority:important - ballot proposal

[Margarita Manterola]

> I believe the TC should rule on this issue and I propose the following ballot:
> 
> A: The blends-tasks package should be dropped and its contents integrated into
> tasksel.
> Z: Further discussion
> 
> (...)
> My vote for the above mentioned ballot, then:
> A > Z

It has been brought to my attention that this was mixing the discussion and the
voting period. Please consider this a starter for the discussion period of this
ballot. Once people voiced their opinion we may call for a proper vote.

Thanks.

-- 
Marga

Bug#848792: beignet: Beignet causes blender crash

[Paul Wise]

Forwarding from IRC:

 Can someone forward http://paste.debian.net/904862/
(untested patch) to bug 848792 and its submitter?

When I loaded it, the paste contained this:

That hardware is much too old for beignet-opencl-icd to do anything
useful with (so you aren't losing anything by uninstalling it), but
*crashing* on such hardware is still a bug.

It is due to context creation failing while beignet is checking whether
the hardware is supported, so making this "return failure" instead of
"assert" (as below) will probably fix it, but this has *not* been
tested.  I expect to be able to test and push it before the freeze.

(The path "/home/geier/beignet" is the path the beignet source code was
in when it was compiled into the beignet* packages: it is normal to see
such nonexistent-on-your-machine paths when using a debugger on Debian
packages.)

--- a/src/intel/intel_driver.c
+++ b/src/intel/intel_driver.c
@@ -133,30 +133,29 @@
   return 1;
 }
 
-static void
+static int
 intel_driver_context_init(intel_driver_t *driver)
 {
   driver->ctx = drm_intel_gem_context_create(driver->bufmgr);
-  assert(driver->ctx);
+  if(!driver->ctx) return 0;
+  return 1;
 }
 
 static void
 intel_driver_context_destroy(intel_driver_t *driver)
 {
   if(driver->ctx)
 drm_intel_gem_context_destroy(driver->ctx);
   driver->ctx = NULL;
 }
 
 static int
 intel_driver_init(intel_driver_t *driver, int dev_fd)
 {
   driver->fd = dev_fd;
   driver->locked = 0;
   pthread_mutex_init(&driver->ctxmutex, NULL);
 
   if (!intel_driver_memman_init(driver)) return 0;
-  intel_driver_context_init(driver);
+  if (!intel_driver_context_init(driver)) return 0;
 
 #if EMULATE_GEN
   driver->gen_ver = EMULATE_GEN;

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#835641: diffoscope: traceback when comparing dangling symlink to directory

[Brett Smith]

Here's a patch to prevent the traceback.  It just detects the general
situation (comparing a directory with something else) and bails with a
more helpful message when they're incompatible.

I checked what diff does, and it does something slightly more nuanced:
if you compare directory D against non-directory F, it tries to compare
`/D/$(basename F)` against F.  If that directory+basename path is itself
a directory, then it bails with an error message like the one in this
patch.  Personally I felt like the path translation wasn't especially
helpful, so decided to just bail immediately.

-- 
Brett Smith

>From 7ec9f8df87ec18263a2f327951cffc08a9631fc8 Mon Sep 17 00:00:00 2001
From: Brett Smith 
Date: Mon, 26 Dec 2016 19:26:05 -0500
Subject: [PATCH] comparators: Avoid comparing a directory with non-directory.

There's no sensible way to do this comparison, so just bail with an error
message.  Previously we assumed both paths were files and ran comparator
tools on them, which led to more obscure errors.
---
 diffoscope/comparators/__init__.py | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/diffoscope/comparators/__init__.py b/diffoscope/comparators/__init__.py
index e80b6d5..c97fc3e 100644
--- a/diffoscope/comparators/__init__.py
+++ b/diffoscope/comparators/__init__.py
@@ -121,11 +121,28 @@ def bail_if_non_existing(*paths):
 sys.stderr.write('%s: %s: No such file or directory\n' % (sys.argv[0], path))
 sys.exit(2)
 
+def bail_if_incompatible_file_types(path1, path1_isdir, path2, path2_isdir):
+if path1_isdir == path2_isdir:
+return
+fmt_args = {
+'prog': sys.argv[0],
+'path1': path1,
+'verb1': "is" if path1_isdir else "is not",
+'path2': path2,
+'verb2': "is" if path2_isdir else "is not",
+}
+errmsg = "{prog}: {path1} {verb1} a directory while {path2} {verb2}".format(**fmt_args)
+print(errmsg, file=sys.stderr)
+sys.exit(2)
+
 def compare_root_paths(path1, path2):
+path1_isdir = os.path.isdir(path1)
+path2_isdir = os.path.isdir(path2)
 if not Config().new_file:
 bail_if_non_existing(path1, path2)
-if os.path.isdir(path1) and os.path.isdir(path2):
+if path1_isdir and path2_isdir:
 return compare_directories(path1, path2)
+bail_if_incompatible_file_types(path1, path1_isdir, path2, path2_isdir)
 container1 = FilesystemDirectory(os.path.dirname(path1)).as_container
 file1 = specialize(FilesystemFile(path1, container=container1))
 container2 = FilesystemDirectory(os.path.dirname(path2)).as_container
-- 
2.1.4

Bug#848893: nvidia-settings: When launching "nvidia-settings" -- "undefined symbol error"

[Andreas Beckmann]

Control: merge -1 849128

On 2016-12-20 16:41, Arcademan wrote:
> When launching "nvidia-settings" via the terminal window I see the following 
> error:
> 
> ERROR: /usr/lib/libnvidia-gtk3.so.367.57: undefined symbol: ctk_init_check
...

I could reproduce this also with 375.26-1 by rebuilding it in jessie,
while the packages in sid are fine. Need more time to investigate.
Probably something is not linked in the correct order, causing some
symbols to be lost. Help would be welcome.


Andreas

Bug#849424: RFP: Adobe Flash PPAPI -- Adobe flash for Pepper plugin API

[Matti Palmström]

Package: wnpp
Severity: wishlist

* Package name: flashplugin-nonfree-ppapi
  Version : 24.0
  Upstream Author : Adobe
* URL : https://get.adobe.com/flashplayer/

* License : Non-free
  Programming Lang:
  Description : Download script for Adobe Flash PPAPI

Since Google don't update the pepper flash plugin for i386 any longer
it would be  nice with an alternative for those who uses Chromium on
i386.

I assume it should be easy to use flashplugin-nonfree as a base for
this. Also add an AMD64 version for those who by some reason want to
run Adobe's PPAPI flash on amd64.

Boom chanka

/M

Bug#849422: fvwm: the module list in the fvwm(1) is obsolete

[Vincent Lefevre]

Package: fvwm
Version: 1:2.6.7-2
Severity: minor

The fvwm(1) man page still mentions FvwmWinList, which no longer
exists.

Other removed modules may be in the same case. I haven't checked.

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, 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 fvwm depends on:
ii  libc6   2.24-8
ii  libcairo2   1.14.8-1
ii  libfontconfig1  2.11.0-6.7
ii  libfreetype62.6.3-3+b1
ii  libfribidi0 0.19.7-1
ii  libgdk-pixbuf2.0-0  2.36.2-1
ii  libglib2.0-02.50.2-2
ii  libice6 2:1.0.9-1+b1
ii  libperl4-corelibs-perl  0.003-2
ii  libpng16-16 1.6.26-6
ii  libreadline77.0-1
ii  librplay3   3.3.2-16+b1
ii  librsvg2-2  2.40.16-1
ii  libsm6  2:1.2.2-1+b1
ii  libstroke0  0.5.1-8
ii  libtinfo5   6.0+20161126-1
ii  libx11-62:1.6.4-2
ii  libxcursor1 1:1.1.14-1+b1
ii  libxext62:1.3.3-1
ii  libxft2 2.3.2-1
ii  libxinerama12:1.1.3-1+b1
ii  libxpm4 1:3.5.12-1
ii  libxrender1 1:0.9.10-1
ii  perl5.24.1~rc4-1

Versions of packages fvwm recommends:
ii  lxmenu-data  0.1.5-1
ii  python   2.7.13-1
ii  python-xdg   0.25-4

Versions of packages fvwm suggests:
ii  cpp   4:6.2.1-1
ii  libx11-protocol-perl  0.56-7
ii  m41.4.17-5
ii  perl-tk   1:804.033-1+b3
pn  stalonetray   

-- no debconf information

Bug#849423: fvwm: the FvwmDebug module is missing

[Vincent Lefevre]

Package: fvwm
Version: 1:2.6.7-2
Severity: normal

The FvwmDebug module is missing, while it was present in 2.6.5,
and it isn't announced as removed like other modules.
/usr/share/doc/fvwm/changelog.gz just contains about them:

  - Some fvwm modules have been removed:
  - FvwmDragWell   (no replacement)
  - FvwmGTK(no replacement)
  - FvwmSave   (no replacement)
  - FvwmSaveDesk   (no replacement)
  - FvwmScroll (no replacement)
  - FvwmTabs   (no replacement, never worked anyway)
  - FvwmTaskBar(use FvwmButtons)
  - FvwmTheme  (in core of fvwm as colorsets)
  - FvwmWharf  (use FvwmButtons)
  - FvwmWinList(use WindowList command)
  - FvwmWindowMenu (use WindowList command)
  - FvwmIconBox(use the IconBox style instead)

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, 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 fvwm depends on:
ii  libc6   2.24-8
ii  libcairo2   1.14.8-1
ii  libfontconfig1  2.11.0-6.7
ii  libfreetype62.6.3-3+b1
ii  libfribidi0 0.19.7-1
ii  libgdk-pixbuf2.0-0  2.36.2-1
ii  libglib2.0-02.50.2-2
ii  libice6 2:1.0.9-1+b1
ii  libperl4-corelibs-perl  0.003-2
ii  libpng16-16 1.6.26-6
ii  libreadline77.0-1
ii  librplay3   3.3.2-16+b1
ii  librsvg2-2  2.40.16-1
ii  libsm6  2:1.2.2-1+b1
ii  libstroke0  0.5.1-8
ii  libtinfo5   6.0+20161126-1
ii  libx11-62:1.6.4-2
ii  libxcursor1 1:1.1.14-1+b1
ii  libxext62:1.3.3-1
ii  libxft2 2.3.2-1
ii  libxinerama12:1.1.3-1+b1
ii  libxpm4 1:3.5.12-1
ii  libxrender1 1:0.9.10-1
ii  perl5.24.1~rc4-1

Versions of packages fvwm recommends:
ii  lxmenu-data  0.1.5-1
ii  python   2.7.13-1
ii  python-xdg   0.25-4

Versions of packages fvwm suggests:
ii  cpp   4:6.2.1-1
ii  libx11-protocol-perl  0.56-7
ii  m41.4.17-5
ii  perl-tk   1:804.033-1+b3
pn  stalonetray   

-- no debconf information

Bug#849354: fvwm: Click not always taken into account or freezes the desktop

[Vincent Lefevre]

On 2016-12-26 12:54:05 -0700, Jaimos Skriletz wrote:
> On Mon, Dec 26, 2016 at 12:06 PM, Vincent Lefevre  wrote:
> > On 2016-12-26 02:24:30 +0100, Vincent Lefevre wrote:
> >> Since I've upgraded fvwm from 1:2.6.5.ds-4.1 to 1:2.6.7-2 (last night),
> >> I have the following problems. I have the following in my config:
> >>
> >> Mouse 1 A   SCM Raise
> >
> > and the problem is reproducible with just this line in the config file.
> 
> Thank you for your bug report.
> 
> It seems to me the issue is with the context A (anywhere) in your binding.
> When you run the Raise function. Since this can be done Anywhere, the
> context of which window to Raise may not be correctly set.
> 
> I don't know the details completely, but my understanding is if the
> context is not set to a window, Raise will want you to pick the
> window to raise, so it will pause fvwm and let you click on the
> window you want to raise.

But this is not what I observe. Well, if I click over the root window,
I get this behavior as expected, and this is fine. Note that concerning
the problem I've reported, I always clicked inside the window to be
raised. Note also that if:
  * I SCM-click inside Window A,
  * the problem occurs,
  * I click inside Window B,
then it is Window A that is raised, not Window B. This means that FVWM
knew really which window had to be raised.

Note also that when FVWM wants me to pick the window to raise (e.g.
after a SCM-click over the root window), the mouse pointer changes
to a cross. But when the problem occurs, the mouse pointer remains
the same as usual and still changes depending on the context as
usual.

> It may also be the context is set to a different window than you
> expect. This could also explain the inconsistency of being able to
> reproduce it, since most times when you use the binding the context is
> as you expect it to be and the correct window is raised, but sometimes
> it is not, in which case you either have fvwm pause for you to pick
> the window to raise or it preforms the action on a different window.

I don't understand what you mean.

> Two solutions would be to narrow the context to say the window and its
> decorations, FSTW, or wrap the Raise command into a function on use a
> conditional (such as ThisWindow or Current) to force the context. More
> on the context for functions can be found here:
> 
> http://fvwmforums.org/wiki/Config/FunctionContext/

I suppose that the context is correct since FVWM raises the correct
window after a click anywhere (see above). To be sure, I wanted to
test with:

AddToFunc RaiseDbg
+ I Echo $[w.name]
+ I Raise

Mouse 1 A   SCM RaiseDbg

but I can't reproduce the problem with this!

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

Bug#824532: [Pkg-auth-maintainers] Bug#846359: Bug#848327: RFS: libu2f-host/1.1.3-1

[Simon Josefsson]

Luca Capello  writes:

> Sorry, I still do not see the reasoning behing such a move:
>
>   
>
> Mickael or Martin (both Bcc:ed), can you elaborate a bit more, please?
> Yes, I have read the full bug and I fully agree with Robert and Simon
> (both Bcc:ed), moreover:
>
> 1) U2F devices are seen as *keyboards*, not a special U2F *device*
>(please anyone correct me if I am wrong), and udev already contains
>exceptions with more-specific devices like iDRACs...

Just a minor correction.  U2F devices aren't keyboards, even though the
YubiKey can appear as one too.  U2F uses HID though.

Otherwise I share your concern about moving the udev rule into
libu2f-host.  I'm not against it, I just feel that it does not appear as
as the optimal solution.  I don't know what the optimal solution is
though.

/Simon


signature.asc
Description: PGP signature

Bug#793101: [Pkg-auth-maintainers] Bug#793101: Yubikey core error: no yubikey present

[Simon Josefsson]

Luca Capello  writes:

> As the main author of the YubiKey 4 wiki page[1] and given the recent
> interest for the YubiKey 4 at work[2], I have successfully prepared a
> jessie-backports for 1.17.3-1 (no changes needed).

Yay, thank you!

/Simon


signature.asc
Description: PGP signature

Bug#848133: RFS: rdup/1.1.15-1.0

[Félix Sipma]

I think I won't have time to work on this soon, so my changes won't be for
stretch anyway. I propose to try to fix the issues you mentioned in your
previous email, and to start the MIA process. At what step of
https://wiki.debian.org/qa.debian.org/MIATeam should I start? Is it possible to
start at "Suggest orphaning" with a mail to Jose and the MIA team in Cc:?

I hope you Jose will be able to answer in the meantime, that will of course be
the easiest!

Thanks again Tobias,


Félix


signature.asc
Description: PGP signature

Bug#610835: Installing caml pulls in half the world

[Juliusz Chroboczek]

Hi Mehdi, good to hear from you.

> Ok, so the bug is in the description. Could you please provide a patch which
> enhances the descriptions and makes them less confusing?

No, sorry.

-- Juliusz

Bug#753350: ITP: youtube-dl-gui -- a graphical frontend for youtube-dl

[Félix Sipma]

Hi Joel,

Do you still plan to work on a package for youtube-dl-gui? If not, I'll be
happy to do it myself.

Thanks!


signature.asc
Description: PGP signature

Bug#849421: RM: clojure1.6 -- ROM; Replaced by clojure (>= 1.8)

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the clojure1.6 package, it has been replaced by the clojure
package recently upgraded to the version 1.8.

Thank you,

Emmanuel Bourg

Bug#849420: zfs-dkms: Provide metapackage for most recent supported kernel?

[Nikolaus Rath]

Package: zfs-dkms
Version: 0.6.5.8-1~bpo8+1
Severity: normal

Hello,

As far as I can tell, zfs support for the jessie-backports kernel
generally comes a little after the kernel itself lands in
jessie-backports. This means that it's very hard to track the backports
kernel and use zfs - either one has to manually vet (and delay) every
kernel upgrade, or one has to live with ZFS being unavailable for a
while after each upgrade.

Would it be possible to provide a metapackage that always depends on the
most recent backports kernel that also supports ZFS? That would solve
the problem nicely...

Best,
-Nikolaus

Bug#849419: libopenjfx-java: Description should clarify libopenjfx-java is not automatically on classpath without pkg openjfx

[George Bateman]

Package: libopenjfx-java
Version: 8u111-b14-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

An Ant build script for a Java package intended to be used with Oracle
Java would not build, as it could not find the openjfx library. I had to
modify the Ant script to add /usr/share/java/openjfx/jre/lib/ext/jfxrt.jar
to its classpath manually, even though this would not have been necessary
if I'd been using Oracle Java.

By experimentation I found out that the package openjfx had to be installed
in addition to libopenjfx-java for the script to automatically be able
to use the library without adding it to the classpath manually, but it
should have been made clear on both packages' description pages that
this was the case.

Many thanks,

George Bateman.


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

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

Versions of packages libopenjfx-java depends on:
ii  libopenjfx-jni  8u111-b14-1

libopenjfx-java recommends no packages.

libopenjfx-java suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFPBAEBCAA5FiEEhCkfJ9Js3nBacaLYxBeqnEA5788FAlhhjbQbHGdlb3JnZS5i
YXRlbWFuMTZAZ21haWwuY29tAAoJEMQXqpxAOe/PI4IIAIq0YJ1g3pB1LvPZ+7/V
gYjVBWRZlK59eYSrqbKzc4gEqoe710eT/sFyn7VK+S2e3Vaxq3/7uGLXuSKvcnce
7xrgh6XoOhrCL9iyicqaejrRminzc6TyOeTZbnbLR1NILsbxcqCqTMFxywbtV2ZA
6YkipvNphIXJqG0zPuepU5sgujIrqtmr/mQXWxlDg2jttAXWcibk38pMOiNMCDJq
gnmWaiSZ9vyxCrI52NvUgArPbLFm5Zz4aXk9oIGWpD+N5mHZBNAQ7EkNsDjNmvFS
VEuAmiYe1bbXGeFGcik+8MR0n4745iDFdO0476tuSP4gyPy2RcqElR8+ZrrsyLCm
wBc=
=Atyt
-END PGP SIGNATURE-

Bug#820780: clarify syntax of ‘cancel’ command for queue control

[Ben Finney]

Control: retitle -1 clarify syntax of ‘cancel’ command for queue control
Control: tags -1 + help

On 12-Apr-2016, Neil Williams wrote:

> >From the manpage:
> 
>If you've uploaded packages with  the  --delayed  option  (uploaded  to
>DEFERRED queue), then use the cancel command with a .changes file.
> 
>$ dcut cancel dput_0.9.4_i386.changes

I notice that this example, and the description of the ‘cancel’
command at ftp://ftp.upload.debian.org/pub/UploadQueue/README>,
only ever show a base filename (with no directory).

> $ dcut cancel  ../pytest-django_2.9.1-2.1_amd64.changes

Whereas this command has a directory in the path (‘../’). That might
be a salient difference.


Is this constraint – the argument to ‘cancel’ *must* be a base
filename only – imposed by the upload queue processor? If so, the
response:

> .commands file has invalid Commands line: cancel 
> ../pytest-django_2.9.1-2.1_amd64.changes
> debsign: .commands file appears to be invalid. see:
> ftp://ftp.upload.debian.org/pub/UploadQueue/README
> for valid format

is not very helpful, because the referenced document does not make
that constraint plain.


I'm casting this to ‘debian-devel’ for confirmation whether this is
actually the problem. Can someone with knowledge of the upload queue
processing clarify this?

-- 
 \ “Whatever a man prays for, he prays for a miracle. Every prayer |
  `\   reduces itself to this: “Great God, grant that twice two be not |
_o__)   four.”” —Ivan Turgenev |
Ben Finney 


signature.asc
Description: PGP signature

Bug#709889: radvd restart

[Geert Stappers]

Hello Marc,

Most likely is your relocations to another country completed.

How well does the new radvd restart?


Regards,
Geert Stappers

Bug#820780: moreinfo on dcut cancel failure

[Ben Finney]

On 12-Apr-2016, Neil Williams wrote:
> Further to this bug report, dcut -i changes_file does not work if the
> package is in the deferred queue:

This additional information seems better as a separate report; the
original report is about the ‘dcut(1)’ manual page and the ‘cancel’
command, where this is about neither.

> So the package still exists in the deferred queue (6 days left) and
> it looks like I'll have to rely on a REJECT due to a lower version
> than now exists in unstable.

I don't know what change in ‘dcut’ you're asking for. Is this perhaps
a report to file against a different BTS package?

-- 
 \ “Computers are useless. They can only give you answers.” —Pablo |
  `\   Picasso |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849417: [Pkg-nagios-devel] Bug#849417: nagios-nrpe-server: segfault during SSL negotiation with older NRPE 2.15 plugin

[Sebastiaan Couwenberg]

Control: tags -1 unreproducible moreinfo

Hi Adam,

Thanks for reporting this issue. Unfortunately I cannot reproduce it.

On 12/26/2016 09:06 PM, Adam Di Carlo wrote:
> Given a situation where a debian/stable (Jessie) server is polling an
> NRPE node running the latest unstable NRPE server, with all debugging
> enabled (ssl_logging=-1), I am getting the following segfault, as reported in
> /var/log/syslog:
> 
> Dec 26 14:49:38 salsa nrpe[14736]: Connection from 192.168.1.5 port 59564
> Dec 26 14:49:38 salsa nrpe[14736]: Host address is in allowed_hosts
> Dec 26 14:49:38 salsa kernel: [176235.037105] nrpe[14736]: segfault at 
> 5335 ip 7fd44f408496 sp 7ffd5abfb418 error 4 in 
> libc-2.24.so[7fd44f388000+195000]
> 
> However, if I rachet down the SSL debugging, e.g., ssl_logging=0x03,
> the segfault disappears. 

To help reproduce this issue, can you clarify how nagios-nrpe-server is
configured. I assume that you configured SSL before removing the -n
option of the nrpe daemon? Do you use a CA certificate, or self-signed?

-- System Information:
> -- Configuration Files:
> /etc/default/nagios-nrpe-server changed:
> USE_SSL=1

Please note that the /etc/default/nagios-nrpe-server changed in
nagios-nrpe (3.0.1-3) because of the systemd service file.

The USE_SSL option is no longer used, instead the NRPE_OPTS variable is
used to disable SSL in both the init script and systemd service file.
The default content is now as attached.

> /etc/nagios/nrpe.cfg changed:
> log_facility=daemon
> debug=1
> pid_file=/var/run/nagios/nrpe.pid
> server_port=5666
> nrpe_user=nagios
> nrpe_group=nagios
> allowed_hosts=127.0.0.1,192.168.1.5
> dont_blame_nrpe=1
> allow_bash_command_substitution=0
> command_timeout=60
> connection_timeout=300
> ssl_version=SSLv2+
> ssl_logging=-1

It doesn't look like you configured SSL, but you did enable the feature.

To use SSL in NRPE 3.x you'll need to configure at least a certificate
file (ssl_cert_file) and its key (ssl_privatekey_file), e.g. for the
snakeoil certificate generated by the ssl-cert package:

 ssl_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
 ssl_privatekey_file=/etc/ssl/private/ssl-cert-snakeoil.key

For proper SSL certificates you also need to configure the path to the
CA certificate (including intermediate certificates) in ssl_cacert_file.

Also note that setting dont_blame_nrpe=1 has no effect, the package is
not configured with --enable-command-args.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
# defaults file for nagios-nrpe-server
# (this file is a /bin/sh compatible fragment)

# NRPE_OPTS are any extra cmdline parameters you'd like to pass along to the
# nrpe daemon.
#
# The -n option disables SSL support.
# Don't remove this option before configuring SSL in /etc/nagios/nrpe.cfg!
# See /usr/share/doc/nagios-nrpe-server/README.SSL.md.gz for instructions.
NRPE_OPTS="-n"

# NICENESS is if you want to run the server at a different nice() priority.
# (only used by the init script)
#NICENESS=5

# INETD is if you want to run the server via inetd (default=0, run as daemon).
# (only used by the init script)
#INETD=0

Bug#848969: RFS: dvdisaster/0.79.5-1~exp1

[Carlos Maddela]

On 27/12/16 07:19, Sean Whitton wrote:
> control: tag -1 +moreinfo
>
> Dear Carlos,
>
> On Wed, Dec 21, 2016 at 10:25:28PM +1100, Carlos Maddela wrote:
>>  * Package name: dvdisaster
>>Version : 0.79.5-1~exp1
> Is there some special reason for the '~exp1'?  You can just use -1 to
> upload to experimental, and then -2 if you want to upload 0.79.5 to
> unstable.
>
The only reason I've done that is because that was what I was told to do
for the dmalloc package. I wasn't sure as I'm still relatively new to this.





signature.asc
Description: OpenPGP digital signature

Bug#848416: RFS: pyvtk/0.5.18-1 [ITA]

[Sean Whitton]

control: tag -1 +moreinfo

Dear Pierre,

Thank you for your interest in adopting this package.

Unfortunately, your work has not been properly integrated with what is
already in Debian:

- you marked version 0.4.74-4 as released but it was never uploaded

- you haven't included the NMU 0.4.74-3.1

- your work is not pushed to the team git repository

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#809625: empire-hub: maintainer address bounces

[Tobias Frost]

Control: Severity -1 important

Hi Angsgar,

I'm in contact with the maintainer and the plans to fix this.
The "working" email is in CC.

Also, I thought about the severity of this bug. I guess for now it is
to say this is not serious. One time a fellow DD told me to always ask
this question if you pick a RC severity: "Should this be a reason to
delay a release?" If the
answer is no, the severity shouhld not be RC. I guess the answer here
is no. 

Also this is is not listed in https://release.debian.org/stretch/rc_pol
icy.txt, so -- as I was told in #830151 -- this is not RC.

(Additional, the bouning email type of bugs are normally not fixable by
an NMU and not so much diffence to packages with working emails but not
working maintainers -- we also do not make them RC on suspect of
MIA-ness or if they don't answer emails.) 

-- 
tobi (for the MIA Team)

Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

[Маша Глухова]

I should add, I also had failures with diffoscope version 64 and older, but
no failures on newer versions. It seems likely that
one of the changes fixed this bug as a side effect, but I cannot yet tell
which one.

Bug#849418: kali-linux-full: Can't install kali-linux-full when running light.

[William Leathem]

Package: kali-linux-full
Version: Well, I don't know.
Severity: important

Dear Maintainer,

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

   * What led up to the situation? - I don't know, it should work, right?
   * What exactly did you do (or not do) that was effective (or
 ineffective)? - I edited the sources.list file and ran this command: 
apt-get update, no effect.
   * What was the outcome of this action? - No effect, at all.
   * What outcome did you expect instead? - I expected it to work normally.

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


-- System Information:
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:kali-rolling
Codename:   kali-rolling
Architecture: i686

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

Bug#849251: dput: allow using sftp for uploads

[Ben Finney]

Control: retitle -1 dput: allow using sftp for uploads
Control: severity -1 wishlist
Control: tags -1 + moreinfo

On 24-Dec-2016, Mattia Rizzolo wrote:
> > > On Sat, 2016-12-24 at 12:34 +0530, Pirate Praveen wrote:
> > >> If dput allowed using sftp, I could avoid this extra step. Please
> > >> consider adding sftp option.

Thanks for the suggestion. I am setting the severity to “wishlist”.

> On Sat, Dec 24, 2016 at 04:35:19PM +0100, Ansgar Burchardt wrote:
> > dput seems to already support rsync which is probably a good
> > choice when one has connection problems as it should support
> > continuing the upload.
> 
> Also, you could upload using scp (see the `ssh-upload` target in
> dput), which is arguably even better than sftp.

Pirate, do either of these suggestions resolve the problem for you?

-- 
 \   “Pinky, are you pondering what I'm pondering?” “Well, I think |
  `\   so (hiccup), but Kevin Costner with an English accent?” —_Pinky |
_o__)   and The Brain_ |
Ben Finney 


signature.asc
Description: PGP signature

Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

[Santiago Vila]

Hi.

I have built version 66 one hundred times in unstable.
The builds were made on 19 different autobuilders.
The number of failed builds has been zero.
(Previously it failed 10% of the time).

If you do not remember what kind of change may have fixed this,
then there must be some broken build-depends in testing which
is fixed in unstable.

I guess the right thing to do would be to find which one, reassign
this bug, and then close it, but we should ensure that the
fixed build-dependency propagates to testing.

Thanks.

Bug#849417: nagios-nrpe-server: segfault during SSL negotiation with older NRPE 2.15 plugin

[Adam Di Carlo]

Package: nagios-nrpe-server
Version: 3.0.1-3
Severity: normal

Given a situation where a debian/stable (Jessie) server is polling an
NRPE node running the latest unstable NRPE server, with all debugging
enabled (ssl_logging=-1), I am getting the following segfault, as reported in
/var/log/syslog:

Dec 26 14:49:38 salsa nrpe[14736]: Connection from 192.168.1.5 port 59564
Dec 26 14:49:38 salsa nrpe[14736]: Host address is in allowed_hosts
Dec 26 14:49:38 salsa kernel: [176235.037105] nrpe[14736]: segfault at 5335 
ip 7fd44f408496 sp 7ffd5abfb418 error 4 in 
libc-2.24.so[7fd44f388000+195000]


However, if I rachet down the SSL debugging, e.g., ssl_logging=0x03,
the segfault disappears. 


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

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

Versions of packages nagios-nrpe-server depends on:
ii  adduser  3.115
ii  init-system-helpers  1.46
ii  libc62.24-8
ii  libssl1.0.2  1.0.2j-4
ii  libwrap0 7.6.q-25
ii  lsb-base 9.20161125

Versions of packages nagios-nrpe-server recommends:
ii  monitoring-plugins2.2-2
ii  monitoring-plugins-basic  2.2-2

Versions of packages nagios-nrpe-server suggests:
pn  xinetd | inetd  

-- Configuration Files:
/etc/default/nagios-nrpe-server changed:
USE_SSL=1

/etc/nagios/nrpe.cfg changed:
log_facility=daemon
debug=1
pid_file=/var/run/nagios/nrpe.pid
server_port=5666
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts=127.0.0.1,192.168.1.5
dont_blame_nrpe=1
allow_bash_command_substitution=0
command_timeout=60
connection_timeout=300
ssl_version=SSLv2+
ssl_logging=-1
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p 
/dev/hda1
command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200
include=/etc/nagios/nrpe_local.cfg
include_dir=/etc/nagios/nrpe.d/

/etc/nagios/nrpe_local.cfg changed:
include=/etc/shared/nagios/nrpe.cfg
command[check_swap]=/usr/lib/nagios/plugins/check_dummy 0
command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 800 -c 1200
command[check_users]=/usr/lib/nagios/plugins/check_users -w 60 -c 100


-- no debconf information

Bug#848969: RFS: dvdisaster/0.79.5-1~exp1

[Sean Whitton]

control: tag -1 +moreinfo

Dear Carlos,

On Wed, Dec 21, 2016 at 10:25:28PM +1100, Carlos Maddela wrote:
>  * Package name: dvdisaster
>Version : 0.79.5-1~exp1

Is there some special reason for the '~exp1'?  You can just use -1 to
upload to experimental, and then -2 if you want to upload 0.79.5 to
unstable.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849326: [Pkg-kde-extras] Bug#849326: [amarok] Collection is disabled due to failing MySQL operation (errmsg.sys) at startup

[Alex Dănilă]

Probably something with reportbug-ng. It was the first time I used it. 
Seem mostly the same versions as for Matthias.


Thank you,
Alex


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

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

Versions of packages amarok depends on:
ii  amarok-common 2.8.0-7
ii  amarok-utils  2.8.0-7
ii  kde-runtime   4:16.08.3-1
ii  libavcodec57  7:3.2.2-1
ii  libavformat57 7:3.2.2-1
ii  libavutil55   7:3.2.2-1
ii  libc6 2.24-8
ii  libcurl3-gnutls   7.51.0-1
ii  libgcrypt20   1.7.5-2
ii  libgdk-pixbuf2.0-02.36.2-1
ii  libgl1-mesa-glx [libgl1]  13.0.2-3
ii  libglib2.0-0  2.50.2-2
ii  libgpod4  0.8.3-8it:
ii  libkcmutils4  4:4.14.26-1
ii  libkdecore5   4:4.14.26-1
ii  libkdeui5 4:4.14.26-1
ii  libkdewebkit5 4:4.14.26-1
ii  libkdnssd44:4.14.26-1
ii  libkfile4 4:4.14.26-1
ii  libkio5   4:4.14.26-1
ii  libknewstuff3-4   4:4.14.26-1
ii  liblastfm11.0.9-1
ii  libloudmouth1-0   1.5.3-2
ii  libmariadbclient1810.1.20-3
ii  libmariadbd18 10.1.20-3
ii  libmtp9   1.1.12-1
ii  libmygpo-qt1  1.0.9-2
ii  libofa0   0.9.3-13
ii  libphonon44:4.9.0-4
ii  libplasma34:4.14.26-1
ii  libqjson0 0.8.1-3
ii  libqt4-dbus   4:4.8.7+dfsg-11
ii  libqt4-network4:4.8.7+dfsg-11
ii  libqt4-opengl 4:4.8.7+dfsg-11
ii  libqt4-script 4:4.8.7+dfsg-11
ii  libqt4-sql4:4.8.7+dfsg-11
ii  libqt4-svg4:4.8.7+dfsg-11
ii  libqt4-xml4:4.8.7+dfsg-11
ii  libqtcore44:4.8.7+dfsg-11
ii  libqtgui4 4:4.8.7+dfsg-11
ii  libqtscript4-core 0.2.0-1
ii  libqtscript4-gui  0.2.0-1
ii  libqtscript4-network  0.2.0-1
ii  libqtscript4-sql  0.2.0-1
ii  libqtscript4-uitools  0.2.0-1
ii  libqtscript4-xml  0.2.0-1
ii  libqtwebkit4  2.3.4.dfsg-9.1
ii  libsolid4 4:4.14.26-1
ii  libstdc++66.2.1-7
ii  libthreadweaver4  4:4.14.26-1
ii  libx11-6  2:1.6.4-2
ii  libxml2   2.9.4+dfsg1-2.1
ii  phonon4:4.9.0-4

Versions of packages amarok recommends:
ii  clamz0.5-2+b1
ii  kio-audiocd  4:16.08.3-1

Versions of packages amarok suggests:
pn  amarok-doc 
ii  libqt4-sql-mysql   4:4.8.7+dfsg-11
pn  libqt4-sql-psql
ii  libqt4-sql-sqlite  4:4.8.7+dfsg-11
pn  moodbar

Versions of packages amarok-common depends on:
pn  perl:any  

amarok-common recommends no packages.

Versions of packages amarok is related to:
ii  phonon-backend-vlc [phonon-backend]  0.9.0-2

-- no debconf information


On 25/12/16 18:57, Pino Toscano wrote:

Hi,

In data domenica 25 dicembre 2016 16:51:23 CET, Alex Dănilă ha scritto:

Package: amarok
Version: 2.8.0-7
Severity: important

--- Please enter the report below this line. ---
After upgrading everything from Testing to Unstable, Amarok cannot use
the music collection anymore. An error related to the MySQL error type
version is displayed at startup:

GREPME MySQLe query failed! (2000) Error message file
'/usr/share/kde4/apps/amarok/mysqle/errmsg.sys' had only 969 error
messages, but it should contain at least 982 error messages.
Check that the above file is the right version for this program! on init
In most cases you will need to resolve these errors before Amarok will
run properly.

Amarok is able to play music, but all features related to the collection
are gone.

--- System information. ---

Unfortunately, this part (system information) does not provide the
versions of packages... please paste it from the output of
   $ reportbug --template amarok

Thanks,

Bug#849355: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

Hello,

This was reported by a Debian user. Please retain the CC to
849355-forwar...@bugs.debian.org in your response, so that
the Debian BTS has a record.

In short when running FvwmIconMan, fvwm prints warnings to stderr when
opening and closing windows. I too have had this issue in 2.6.7 (and
previous versions) so I can also say it affects my Debian system.

-- Forwarded message --
From: Vincent Lefevre 
Date: Sun, Dec 25, 2016 at 6:37 PM
Subject: Bug#849355: fvwm: GetWindowSizeHints warnings when windows
and opened and closed
To: Debian Bug Tracking System 


Package: fvwm
Version: 1:2.6.7-2
Severity: normal

I get the following warnings in my .xsession-errors file (where FVWM's
standard error is redirected):

[fvwm][GetWindowSizeHints]: <> reason: 2: The hints have been
ignored because the window's current size would have become invalid.
The new hints will become active when the window generates the next
ConfigureRequest.

when a window is opened.

[fvwm][GetWindowSizeHints]: <> reason: 4: The hints have been
ignored because the window's current size would have become invalid.
The new hints will become active when the window generates the next
ConfigureRequest.

when a window is closed.

I've tried with windows from the following applications: xterm, Emacs,
xev. This seems to be always reproducible.

This also occurs when I move to a different page with FvwmPager, with
lots of warnings (I assume one for each window of the old and new
pages).

After 23 hours, the size of my .xsession-errors file is 678 KB.
I don't think that the space taken is much a problem, but the major
consequence is that these warnings can easily hide more interesting
warning/error messages (from FVWM or applications started by it).

Edit (from a followup email):

This only occurs when I use the FvwmIconMan module (which I start
from RestartFunction, itself invoked from InitFunction).

If I remove my specific FvwmIconMan configuration, the problem still
occurs.

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, 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 fvwm depends on:
ii  libc6   2.24-8
ii  libcairo2   1.14.8-1
ii  libfontconfig1  2.11.0-6.7
ii  libfreetype62.6.3-3+b1
ii  libfribidi0 0.19.7-1
ii  libgdk-pixbuf2.0-0  2.36.2-1
ii  libglib2.0-02.50.2-2
ii  libice6 2:1.0.9-1+b1
ii  libperl4-corelibs-perl  0.003-2
ii  libpng16-16 1.6.26-6
ii  libreadline77.0-1
ii  librplay3   3.3.2-16+b1
ii  librsvg2-2  2.40.16-1
ii  libsm6  2:1.2.2-1+b1
ii  libstroke0  0.5.1-8
ii  libtinfo5   6.0+20161126-1
ii  libx11-62:1.6.4-2
ii  libxcursor1 1:1.1.14-1+b1
ii  libxext62:1.3.3-1
ii  libxft2 2.3.2-1
ii  libxinerama12:1.1.3-1+b1
ii  libxpm4 1:3.5.12-1
ii  libxrender1 1:0.9.10-1
ii  perl5.24.1~rc4-1

Versions of packages fvwm recommends:
ii  lxmenu-data  0.1.5-1
ii  python   2.7.13-1
ii  python-xdg   0.25-4

Versions of packages fvwm suggests:
ii  cpp   4:6.2.1-1
ii  libx11-protocol-perl  0.56-7
ii  m41.4.17-5
ii  perl-tk   1:804.033-1+b3
pn  stalonetray   

-- no debconf information

Bug#812032: mldemos: FTBFS with GCC 6: needed for in-class initialization

[Legimet]

This patch allows the package to build with GCC 6.Index: mldemos-0.5.1/Core/glwidget.h
===
--- mldemos-0.5.1.orig/Core/glwidget.h
+++ mldemos-0.5.1/Core/glwidget.h
@@ -114,9 +114,9 @@ public:
 
 static const GLint texWidth = 128;
 static const GLint texHeight = 128;
-static const float texHalfWidth = 64.0f;
-static const float texHalfHeight = 64.0f;
-static const float texRadius = texWidth*0.9;
+static constexpr float texHalfWidth = 64.0f;
+static constexpr float texHalfHeight = 64.0f;
+static constexpr float texRadius = texWidth*0.9;
 static const int textureCount = 2; // 0: samples, 1: wide circle
 static GLuint *textureNames;
 static unsigned char **textureData;
Index: mldemos-0.5.1/Core/basicMath.h
===
--- mldemos-0.5.1.orig/Core/basicMath.h
+++ mldemos-0.5.1/Core/basicMath.h
@@ -129,6 +129,7 @@ static u32 *randPerm(u32 length, s32 see
 // matlab code to generate the table
 // erf(x) = (x>0?1:-1) * erftable((int)(min(6.f,abs(x))*100));
 // 0:0.01:6
+#if __cplusplus < 201103L
 static const float erftable [] = 
 {
 0.f, 0.011283418496f, 0.0225645746918449f, 0.0338412223417354f, 0.045061451247f, 0.0563719777970166f, 0.0676215943933084f, 0.0788577197708907f, 0.0900781258410182f, 0.1012805939146269f, 0.1124629160182849f, 0.1236228961994743f, 0.1347583518199201f, 0.1458671148356958f, 0.1569470330628558f, 0.1679959714273635f, 0.1790118131981057f, 0.1899924612018088f, 0.2009358390186958f, 0.2118398921577497f, 0.2227025892104785f, 0.2335219229821036f, 0.2442959115991287f, 0.2550225995922731f, 0.2657000589537920f, 0.2763263901682369f, 0.2868997232157491f, 0.2974182185470128f, 0.3078800680290340f, 0.3182834958609522f, 0.3286267594591273f, 0.3389081503107902f, 0.3491259947955827f, 0.3592786549743590f, 0.3693645293446587f, 0.3793820535623103f, 0.3893297011286642f, 0.3992059840429992f, 0.4090094534196940f, 0.4187387000697961f, 0.4283923550466685f, 0.4379690901554394f, 0.4474676184260253f, 0.4568866945495403f, 0.4662251152779575f, 0.4754817197869237f, 0.4846553900016797f, 0.4937450508860821f, 0.5027496706947650f, 0.5116682611885233f, 0.5204998778130465f, 0.5292436198411704f, 0.5378986304788544f, 0.5464640969351416f, 0.5549392504563904f, 0.5633233663251089f, 0.5716157638237684f, 0.5798158061639961f, 0.5879229003816007f, 0.5959364971979084f, 0.6038560908479259f, 0.6116812188758802f, 0.6194114618987212f, 0.6270464433381957f, 0.6345858291221413f, 0.6420293273556719f, 0.6493766879629542f, 0.6566277023003051f, 0.6637822027413580f, 0.6708400622350779f, 0.6778011938374186f, 0.6846655502174442f, 0.6914331231387512f, 0.6981039429170445f, 0.7046780778547458f, 0.7111556336535152f, 0.7175367528055909f, 0.7238216139648592f, 0.7300104312985789f, 0.7361034538206912f, 0.7421009647076605f, 0.7480032805977895f, 0.7538107508749625f, 0.7595237569377731f, 0.7651427114549946f, 0.7706680576083524f, 0.7761002683235567f, 0.7814398454905507f, 0.7866873191739325f, 0.7918432468144954f, 0.7969082124228322f, 0.8018828257659413f, 0.8067677215477618f, 0.8115635585845578f, 0.8162710189760625f, 0.8208908072732779f, 0.8254236496438183f, 0.8298702930356671f, 0.8342315043402079f, 0.8385080695553697f, 0.8427007929497148f, 0.8468104962282766f, 0.8508380177009420f, 0.8547842114541484f, 0.8586499465266515f, 0.8624361060900967f, 0.8661435866351080f, 0.8697732971635868f, 0.8733261583878896f, 0.8768031019375383f, 0.8802050695740817f, 0.8835330124147180f, 0.8867878901652547f, 0.8899706703629624f, 0.8930823276298567f, 0.8961238429369151f, 0.8990962028797120f, 0.9020003989659357f, 0.9048374269152169f, 0.9076082859716850f, 0.9103139782296355f, 0.9129555079726694f, 0.9155338810266469f, 0.9180501041267614f, 0.9205051842990297f, 0.9229001282564582f, 0.9252359418101295f, 0.9275136292954247f, 0.9297341930135782f, 0.9318986326887336f, 0.9340079449406524f, 0.9360631227731995f, 0.9380651550787114f, 0.9400150261583302f, 0.9419137152583653f, 0.9437621961227241f, 0.9455614365614331f, 0.9473123980352520f, 0.9490160352563626f, 0.9506732958050965f, 0.9522851197626489f, 0.9538524393597054f, 0.9553761786408961f, 0.9568572531449688f, 0.9582965696005648f, 0.9596950256374592f, 0.9610535095131181f, 0.9623728998544057f, 0.9636540654142689f, 0.9648978648432043f, 0.9661051464753108f, 0.9672767481287117f, 0.9684134969201232f, 0.9695162090933357f, 0.9705856898613637f, 0.9716227332620125f, 0.9726281220266002f, 0.9736026274615670f, 0.9745470093426969f, 0.9754620158216676f, 0.9763483833446440f, 0.9772068365826185f, 0.9780380883732035f, 0.9788428396735702f, 0.9796217795242320f, 0.9803755850233603f, 0.9811049213113221f, 0.9818104415651265f, 0.9824927870024649f, 0.9831525868950262f, 0.9837904585907746f, 0.9844070075448683f, 0.9850028273589058f, 0.9855784998281805f, 0.9861345949966329f, 0.9866716712191824f, 0.9871902752311301f, 0.9876909422243223f, 0.9881741959297683f, 0.9886405487064082f, 0.98909050

Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

On Sun, Dec 25, 2016 at 6:48 PM, Vincent Lefevre  wrote:
> On 2016-12-26 02:37:46 +0100, Vincent Lefevre wrote:
>> I get the following warnings in my .xsession-errors file (where FVWM's
>> standard error is redirected):
>>
>> [fvwm][GetWindowSizeHints]: <> reason: 2: The hints have been 
>> ignored because the window's current size would have become invalid.  The 
>> new hints will become active when the window generates the next 
>> ConfigureRequest.
>>
>> when a window is opened.
>>
>> [fvwm][GetWindowSizeHints]: <> reason: 4: The hints have been 
>> ignored because the window's current size would have become invalid.  The 
>> new hints will become active when the window generates the next 
>> ConfigureRequest.
>>
>> when a window is closed.
> [...]
>
> This only occurs when I use the FvwmIconMan module (which I start
> from RestartFunction, itself invoked from InitFunction).
>
> If I remove my specific FvwmIconMan configuration, the problem still
> occurs.
>

Thank you for the bug-report.

I too have seen these warnings in my log file but never tracked them
down to FvwmIconMan causing them. I will pass this on to fvwm-workers.

jaimos

Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

[Santiago Vila]

On Mon, Dec 26, 2016 at 07:37:55PM +, Chris Lamb wrote:
> Santiago Vila wrote:
> 
> > If I do "python3 -m pytest" afterwards this is what it's shown:
> […]
> > Note: This is still diffoscope_63 in stretch, not sure if I should
> > better try the version in unstable and forget completely about this
> > version.
> 
> Please do so; the icc tests were fixed later and there have been quite
> a few other changes that makes focusing on stretch's version a poor
> return on time :)

Ok. I'm now building in unstable, many times. No failures so far.

Is it likely/possible that the changes between testing and unstable
have fixed this bug as a side effect?

Thanks.

Bug#559335: aoetools: init script doesn't wait long enough,???tries to umount not mounted filesystems

[Christoph Biedl]

tags 559335 moreinfo
thanks

Andrei Caraman wrote...

> There are two issues with /etc/init.d/aoetools.  One is on startup, the
> second on stop.
(...)

Hello everybody,

it's been a while ... I'm about to adopt aoetools after it was in limbo
for quite some time. About this bug, I find mixed reactions whether
it's still applicable, so can you please re-check?

Christoph



signature.asc
Description: Digital signature

Bug#849354: fvwm: Click not always taken into account or freezes the desktop

[Jaimos Skriletz]

On Mon, Dec 26, 2016 at 12:06 PM, Vincent Lefevre  wrote:
> On 2016-12-26 02:24:30 +0100, Vincent Lefevre wrote:
>> Since I've upgraded fvwm from 1:2.6.5.ds-4.1 to 1:2.6.7-2 (last night),
>> I have the following problems. I have the following in my config:
>>
>> Mouse 1 A   SCM Raise
>
> and the problem is reproducible with just this line in the config file.
>

Thank you for your bug report.

It seems to me the issue is with the context A (anywhere) in your binding.
When you run the Raise function. Since this can be done Anywhere, the
context of which window to Raise may not be correctly set.

I don't know the details completely, but my understanding is if the
context is not
set to a window, Raise will want you to pick the window to raise, so
it will pause
fvwm and let you click on the window you want to raise.

It may also be the context is set to a different window than you
expect. This could also explain the inconsistency of being able to
reproduce it, since most times when you use the binding the context is
as you expect it to be and the correct window is raised, but sometimes
it is not, in which case you either have fvwm pause for you to pick
the window to raise or it preforms the action on a different window.

Two solutions would be to narrow the context to say the window and its
decorations, FSTW, or wrap the Raise command into a function on use a
conditional (such as ThisWindow or Current) to force the context. More
on the context for functions can be found here:

http://fvwmforums.org/wiki/Config/FunctionContext/

jaimos

Bug#849416: fpc-source: Please provide a symbolic link to the corresponding source directory

[Kari Pahula]

Package: fpc-source
Version: 3.0.0+dfsg-10
Severity: wishlist

I'm using fpc-source-3.0.0 as a build dependency for gearhead, to copy
over and patch some line drawing instructions to get smoother console
mode box borders for it.  Currently, I've used fpc-source-3.0.0
directly as the build dependency and access files from under
/usr/share/fpcsrc/3.0.0/ in my debian/rules.

I'd like to rather use fpc-source as the build dependency.  I expect
to have the files I use stay the same across fpc versions.  Nothing
really prevents me from doing that as is but it would get downright
trivial to do so on my end if fpc-source had a symlink like
/usr/share/fpcsrc/default which pointed to the 3.0.0 (as it is
currently) directory.

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

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

Versions of packages fpc-source depends on:
ii  fpc-source-3.0.0  3.0.0+dfsg-10

fpc-source recommends no packages.

fpc-source suggests no packages.

-- no debconf information

Bug#849077: [pkg-wpa-devel] Bug#849077: wpasupplicant: [Regression] Updating wpasupplicant makes not possible to connect to encrypted WiFi

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 26 de diciembre de 2016 20:04:08 ART Andrew Shadura wrote:
> On 26/12/16 19:28, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Thanks to Eduard Bloch at [bug] I've tried adding
> > 
> > [device]
> > wifi.scan-rand-mac-address=no
> > 
> > to /etc/NetworkManager/NetworkManager.conf
> > 
> > and updating wpasupplicant... and voilá, WiFi is on again.
> > 
> > [bug] 
> > 
> > I don't know if it's a bug in the driver, NM or wpasupplicant, but at
> > least
> > things now work.
> 
> Lisandro, what NM version are you using? A related bug has been fixed by
> mbiebl recently:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835822#67

Interesting. I was using 1.4.2-3. After trying this workaround/fix I updated 
to 1.4.4-1 which is what I'm currently using.

Thanks!

-- 
Quizá, para muchos, ahora que lo pienso, Wikipedia tiene
ciertamente un defecto imperdonable. No adorna.
  Ariel Torres, "Probablemente, la Wikipedia esté bien"
  La Nación Tecnología, Sábado 25 de agosto de 2007
  http://www.lanacion.com.ar/tecnologia/nota.asp?nota_id=937889

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


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

Bug#849403: diffoscope: Improvesupport for Android apps

[Reiner Herrmann]

On Mon, Dec 26, 2016 at 07:19:17PM +0200, Emanuel Bronshtein wrote:
> 2. Support parsing android resources not in APK file
>
> Support for some Android files (such as: AndroidManifest.xml & 
> resources.arsc) was added in:
> https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=3e748664a91b7ced412547a204e1473161425d4f
> but it works only if comparing APK files, not directories / when the content 
> archived in other format (non ZIP)

That's unfortunately a limitation of apktool that it only operates on
the whole apk archive, and is not able to dump already extracted files
(like the binary AndroidManifest).


signature.asc
Description: Digital signature

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[John Paul Adrian Glaubitz]

On 12/22/2016 12:36 PM, John Paul Adrian Glaubitz wrote:
> Could you please remove the ada-m68k.diff patch from the gcc-7
> source package now. It's existence still breaks the build, it has
> been merged upstream now as already discussed.
> 
> Ada is currently is disabled on gcc-6 and gcc-7 anyway, so gcc-7
> should build fine with the patch removed unless there are other
> Ada-unrelated issues.

I just did that. gcc-7 built fine on m68k and I just uploaded it.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

[Chris Lamb]

Santiago Vila wrote:

> If I do "python3 -m pytest" afterwards this is what it's shown:
[…]
> Note: This is still diffoscope_63 in stretch, not sure if I should
> better try the version in unstable and forget completely about this
> version.

Please do so; the icc tests were fixed later and there have been quite
a few other changes that makes focusing on stretch's version a poor
return on time :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

[Santiago Vila]

On Sat, 24 Dec 2016, Ximin Luo wrote:

> For all you people that already have single-CPU KVM VMs set up, can you 
> please try to reduce your test cases that still reproduce the bug?
> 
> For example, can you still reproduce it with `debian/rules clean build`? What 
> about `python3 -m pytest`? Then, does it reproduce when you start manually 
> disabling various tests? What about when running only 1 test case?

Building the package by hand makes three tests to fail.

If I do "python3 -m pytest" afterwards this is what it's shown:

= test session starts ==
platform linux -- Python 3.5.2+, pytest-3.0.5, py-1.4.31, pluggy-0.4.0
rootdir: /build/diffoscope-63, inifile: 
plugins: cov-2.4.0
collected 248 items

tests/test_difference.py ...
tests/test_main.py .
tests/comparators/test_binary.py ...
tests/comparators/test_bzip2.py ..
tests/comparators/test_cbfs.py ss
tests/comparators/test_cpio.py ..
tests/comparators/test_deb.py ...
tests/comparators/test_debian.py ...
tests/comparators/test_dex.py 
tests/comparators/test_directory.py 
tests/comparators/test_elf.py ..
tests/comparators/test_epub.py 
tests/comparators/test_fonts.py 
tests/comparators/test_fsimage.py .sss
tests/comparators/test_gettext.py .
tests/comparators/test_git.py ...
tests/comparators/test_gzip.py ...
tests/comparators/test_haskell.py s.s
tests/comparators/test_icc.py F.FF
tests/comparators/test_image.py 
tests/comparators/test_ipk.py .
tests/comparators/test_iso9660.py ...
tests/comparators/test_java.py 
tests/comparators/test_json.py .
tests/comparators/test_macho.py ..ss
tests/comparators/test_mono.py 
tests/comparators/test_pdf.py .
tests/comparators/test_png.py 
tests/comparators/test_ppu.py 
tests/comparators/test_ps.py .
tests/comparators/test_rlib.py 
tests/comparators/test_rpm.py ..
tests/comparators/test_sqlite.py 
tests/comparators/test_squashfs.py ...
tests/comparators/test_tar.py ...
tests/comparators/test_text.py ..
tests/comparators/test_utils.py .ss.
tests/comparators/test_xz.py ..
tests/comparators/test_zip.py ..

=== FAILURES ===
_ test_identification __

icc1 = < 
/build/diffoscope-63/tests/data/test1.icc>

def test_identification(icc1):
>   assert isinstance(icc1, IccFile)
E   assert False
E+  where False = isinstance(< 
/build/diffoscope-63/tests/data/test1.icc>, IccFile)

tests/comparators/test_icc.py:32: AssertionError
__ test_diff ___

differences = []

@skip_unless_tools_exist('cd-iccdump')
def test_diff(differences):
expected_diff = open(data('icc_expected_diff')).read()
>   assert differences[0].unified_diff == expected_diff
E   IndexError: list index out of range

tests/comparators/test_icc.py:45: IndexError
__ test_compare_non_existing ___

monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7fc9dec67128>
icc1 = < 
/build/diffoscope-63/tests/data/test1.icc>

@skip_unless_tools_exist('cd-iccdump')
def test_compare_non_existing(monkeypatch, icc1):
monkeypatch.setattr(Config(), 'new_file', True)
difference = icc1.compare(NonExistingFile('/nonexisting', icc1))
assert difference.source2 == '/nonexisting'
>   assert len(difference.details) > 0
E   assert 0 > 0
E+  where 0 = len([])
E+where [] = .details

tests/comparators/test_icc.py:52: AssertionError
== 3 failed, 230 passed, 15 skipped in 52.10 seconds ===


Note: This is still diffoscope_63 in stretch, not sure if I should
better try the version in unstable and forget completely about this
version.

Thanks.

Bug#849415: ITP: git-crecord -- interactively select chunks to commit with Git

[Andrew Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrew Shadura 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: git-crecord
  Version : 20161216.0
  Upstream Author : Andrew Shadura  and others
* URL : https://github.com/andrewshadura/git-crecord
* License : GPL-2+
  Programming Lang: Python
  Description : interactively select chunks to commit with Git

git-crecord is a Git subcommand which allows users to interactively select
changes to commit using a ncurses-based text user interface. It is a port
of the Mercurial crecord extension originally written by Mark Edgington.

git-crecord allows you to interactively choose among the changes you
have made (with line-level granularity), and commit only those changes
you select.  After committing the selected changes, the unselected changes
are still present in your working copy, so you can use crecord multiple
times to split large changes into several smaller changesets.

git-crecord supports some of the most popular options of git commit:
- --author=, --date=, --message=, --amend, --signoff.

At the moment git-crecord supports partial commit only, with partial
stage and unstage being work in progress.

- -- 
Cheers,
  Andrew

-BEGIN PGP SIGNATURE-

iQExBAEBCAAbBQJYYW10FBxhbmRyZXdzaEBkZWJpYW4ub3JnAAoJEJ1bI/kYT6UU
RdcH/j/LFvVQitOHlXtokX3G6O5fUhnFldlafZPTvona9JZnCJEJ9xtceLfnwe18
Uws/OhL9kDCix1w3cNFMhHIQ8NlFQZycKoZhvKNJ1jKUqhHep8g70rY+pKN8Z1+U
UKxxvbO3qQkMuDtDHUsMQn7ZtWD2vAr9SPdK+I3Fw33jGydqkUlIUdZ3J3T15UYo
49+zzoj814n4FcItxRbcy9RVZ/bgB4p4+zN+HMYbUQyezdN+CaC2EmMo1jw2TPkJ
f9Qi53W8X2c5ikFz6UFSif0E0Fk23ErI1zbJY1FSzk4ba05WAa0zHq/0YvH2hdhK
XG1d3XYhVuyI5fKnZnI4FDMWWPg=
=Alii
-END PGP SIGNATURE-

Bug#849354: fvwm: Click not always taken into account or freezes the desktop

[Vincent Lefevre]

On 2016-12-26 02:24:30 +0100, Vincent Lefevre wrote:
> Since I've upgraded fvwm from 1:2.6.5.ds-4.1 to 1:2.6.7-2 (last night),
> I have the following problems. I have the following in my config:
> 
> Mouse 1 A   SCM Raise

and the problem is reproducible with just this line in the config file.

> 1. If the window is not yet on top, then it is not always raised.
> Well, I'm not sure. It could be problem 2. See below.
> 
> 2. If the window is already on top, then this sometimes freezes the
> desktop: I can't do anything until I do another click.
> 
> I'd say that problem 1 occurs at around 1 over 10. AFAIK, it had never
> occurred before the upgrade.

I've downgraded to 2.6.5, and I could reproduce the problems, which
are the same IMHO.

When I SCM-click over a window that is not yet on top and the problem
occurs, I can:
  1. Click anywhere, and the window is raised. Back to normal.
  2. Hit [Return], and the window is raised. Back to normal.
  3. Hit [Escape], and the window is not raised. Back to normal.
  4. The arrow keys move the mouse pointer; with the Shift key, faster.
 Ditto with b, f, h, j, k, l, n, p.

Most keys do not have any effect. So, this seems to be a FVWM feature
(SCM-click over the root window is similar, and this is normal in this
case), but this feature is triggered when it should *not* be.

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

Bug#734688: Logs are not rotated for a month

[Christoph Biedl]

Mathieu Parent wrote...

> The actual upstream fix for it is:
> https://github.com/logrotate/logrotate/commit/fc1c3eff61edf8e9f0a4bfa980f3a6030a6b271f
> 
> And it is included in version 3.11.0.
> 
> The way forward is to update Debian package to 3.11.0.

ACK. This version handles my test cases in a robust way.

Christoph, consider this a Tested-by:


signature.asc
Description: Digital signature

Bug#849077: [pkg-wpa-devel] Bug#849077: wpasupplicant: [Regression] Updating wpasupplicant makes not possible to connect to encrypted WiFi

[Andrew Shadura]

On 26/12/16 19:28, Lisandro Damián Nicanor Pérez Meyer wrote:
> Thanks to Eduard Bloch at [bug] I've tried adding
> 
> [device]
> wifi.scan-rand-mac-address=no
> 
> to /etc/NetworkManager/NetworkManager.conf
> 
> and updating wpasupplicant... and voilá, WiFi is on again.
> 
> [bug] 
> 
> I don't know if it's a bug in the driver, NM or wpasupplicant, but at least 
> things now work.

Lisandro, what NM version are you using? A related bug has been fixed by
mbiebl recently:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835822#67

-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

Bug#849414: Crashes immediately on armhf with "Segmentation fault"

[Ximin Luo]

Package: motion
Version: 4.0-1
Severity: normal

 Forwarded Message 
Subject: Bug report for motion: Crashes immediately with "Segmentation fault"
Date: Mon, 26 Dec 2016 19:04:19 +0100
From: Alek 
To: Ximin Luo 

Hi,

sorry for not using reportbug to report the bug, but reportbug
currently does not work on my system.
Stack trace and package versions below…
Thanks

––
# motion
Segmentation fault
––

––
# cat /proc/cpuinfo 
processor   : 0
model name  : ARMv7 Processor rev 2 (v7l)
BogoMIPS: 100.24
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part: 0xc08
CPU revision: 2

Hardware: Allwinner sun4i/sun5i Families
Revision: 
Serial  : 1625420801818090
––
(It's a »NextThing C.H.I.P.«)
–– 
# cat /etc/apt/sources.list
deb http://ftp.us.debian.org/debian/ sid main contrib non-free

deb http://ftp.us.debian.org/debian/ jessie main contrib non-free
deb-src http://ftp.us.debian.org/debian/ jessie main contrib non-free

deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free

deb http://http.debian.net/debian jessie-backports main contrib non-free
deb-src http://http.debian.net/debian jessie-backports main contrib
non-free

deb http://opensource.nextthing.co/chip/debian/repo jessie main


deb http://opensource.nextthing.co/chip/debian/pocketchip jessie main
––
Package: motion   
Version: 4.0-1
Architecture: armhf
––

$ apt-rdepends  --state-follow=Installed reportbug | grep -v debconf | awk '$1 
~ /^Depends:/{print $2}' | xargs apt-get download --print-uris
Reading package lists... Done
Building dependency tree   
Reading state information... Done
'http://ftp.us.debian.org/debian/pool/main/a/adduser/adduser_3.115_all.deb' 
adduser_3.115_all.deb 241436 
SHA256:c5efe1de379afe17aacc2f50cb1dd1569552f0387379a1929f0f95ba5311a279
'http://ftp.us.debian.org/debian/pool/main/a/apt/apt_1.4~beta2_armhf.deb' 
apt_1.4~beta2_armhf.deb 1169698 
SHA256:eb729a6e6df0e9d2da99784a33511f3fe783f228bbdb7a22ed0b0445740007c8
'http://ftp.us.debian.org/debian/pool/main/a/apt/libapt-pkg5.0_1.4~beta2_armhf.deb'
 libapt-pkg5.0_1.4~beta2_armhf.deb 841310 
SHA256:744370dadbcc785fd6029778b819f2c840ee46a5b464d7cbff31e6a5d6ae6a30
'http://ftp.us.debian.org/debian/pool/main/a/attr/libattr1_2.4.47-2_armhf.deb' 
libattr1_1%3a2.4.47-2_armhf.deb 16930 
SHA256:34761c1df4f6f9ffe823cccb412ec11bd6b7906565ab2a9abad024d3efee1e19
'http://ftp.us.debian.org/debian/pool/main/a/audit/libaudit-common_2.6.7-1_all.deb'
 libaudit-common_1%3a2.6.7-1_all.deb 17932 
SHA256:3f57f1310fb00ecbae621471f93bd5be1b62e6ab52cbc720ea93f5b29c5f9241
'http://ftp.us.debian.org/debian/pool/main/a/audit/libaudit1_2.6.7-1_armhf.deb' 
libaudit1_1%3a2.6.7-1_armhf.deb 48288 
SHA256:85c16aacdf229e30027d3d627fd266bbf818ef1e3f168421600999b6e9274544
'http://ftp.us.debian.org/debian/pool/main/b/bzip2/libbz2-1.0_1.0.6-8_armhf.deb'
 libbz2-1.0_1.0.6-8_armhf.deb 42814 
SHA256:1fbda9a9d1ccc59fc7cd55f2ae88be7c7a49a3f6ed36754f1c6998fbd3de267b
'http://ftp.us.debian.org/debian/pool/main/c/ca-certificates/ca-certificates_20161130_all.deb'
 ca-certificates_20161130_all.deb 202884 
SHA256:86334cbea59c84ccf91c296a412787cfc0374edb9e83ee69318c3647845ecdf9
'http://ftp.us.debian.org/debian/pool/main/c/chardet/python3-chardet_2.3.0-2_all.deb'
 python3-chardet_2.3.0-2_all.deb 96020 
SHA256:91b5191325a45961191e1714aedf618fda47fa71e5f9b09e1a83738935eaf7f8
'http://ftp.us.debian.org/debian/pool/main/c/curl/libcurl3-gnutls_7.51.0-1_armhf.deb'
 libcurl3-gnutls_7.51.0-1_armhf.deb 257594 
SHA256:7eded47976f862a1c9aa858d24de9064ad994d45fc78ff220cd9f936c7462ea7
'http://ftp.us.debian.org/debian/pool/main/c/cyrus-sasl2/libsasl2-2_2.1.27~101-g0780600+dfsg-1_armhf.deb'
 libsasl2-2_2.1.27~101-g0780600+dfsg-1_armhf.deb 97934 
SHA256:b688cbb39aba0a3b4d63c8f996fba205f6b87ddac5ef7d0dd4ea840199867d25
'http://ftp.us.debian.org/debian/pool/main/c/cyrus-sasl2/libsasl2-modules-db_2.1.27~101-g0780600+dfsg-1_armhf.deb'
 libsasl2-modules-db_2.1.27~101-g0780600+dfsg-1_armhf.deb 66508 
SHA256:2ddb121e4b98a53d3697e08a1d851d86786c80d5597db588d987c537cabc237a
'http://ftp.us.debian.org/debian/pool/main/d/db5.3/libdb5.3_5.3.28-12_armhf.deb'
 libdb5.3_5.3.28-12_armhf.deb 596420 
SHA256:31b0a0d9c75c1daf3a22c35c8d79751285f7331e8862c99cd5e1cf6afde700ef
'http://ftp.us.debian.org/debian/pool/main/d/debian-archive-keyring/debian-archive-keyring_2014.3_all.deb'
 debian-archive-keyring_2014.3_all.deb 40060 
SHA256:017a2fba215cd64612891f5aa02546be5c0e30923a66672f889867cc6dd8d3a0
'http://ftp.us.debian.org/debian/pool/main/d/debianutils/debianutils_4.8.1_armhf.deb'
 debianutils_4.8.1_armhf.deb 99210 
SHA256:4065dec093c169c01a9410f224720c056bc224128357efd8d98dae60021ae98e
'http://ftp.us.debian.org/debian/pool/main/d/dh-python/dh-python_2.20160818_all.deb'
 dh-python_2.20160818_all.deb 82968 
SHA256:f4

Bug#623605: #623605 - gnome-system-monitor: Network usage drops on mouseover

[Conrad Hughes]

Hi Pedro,

I'm afraid I've no idea how to reproduce this any more: there appears to
be no tooltip on mouseover in 3.14.1-1, so I guess you could say the
problem has gone since the feature has gone..

Regards,
Conrad

Bug#828607: closing 828607

[Niels Thykier]

Ferenc Wágner:
> Niels Thykier  writes:
> 
>> close 828607 
>> thanks
> 
> Hi Niels,
> 
> Thanks for re-closing this bug.  Could you please help me understand why
> xml-security-c 1.7.3-4 hasn't migrated to testing yet, even though
> https://qa.debian.org/excuses.php?package=xml-security-c says it's "47
> days old (needed 10 days)" and "valid candidate"?  Is this related to
> the ssl1.0 transition?  Do I have to do anything to move things forward?
> 

Hi,

According to Britney, migrating xml-security-c would break
"libsaml2-dev, libshibsp-dev, libxmltooling-dev" (at least on mipsel).

The latter two looks like they will become ready to migrate later today,
so it /might/ fix itself tonight.

Thanks,
~Niels

Bug#828607: closing 828607

[Ferenc Wágner]

Niels Thykier  writes:

> close 828607 
> thanks

Hi Niels,

Thanks for re-closing this bug.  Could you please help me understand why
xml-security-c 1.7.3-4 hasn't migrated to testing yet, even though
https://qa.debian.org/excuses.php?package=xml-security-c says it's "47
days old (needed 10 days)" and "valid candidate"?  Is this related to
the ssl1.0 transition?  Do I have to do anything to move things forward?
-- 
Thanks,
Feri

Bug#836786: JavaScript beautifier added

[Emanuel Bronshtein]

js-beautify is used as JavaScript code beautifier from commit:
https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?=002f05444cc0a238d8e617b31dabef4111b4ecd2
which fix the above examples, but there are more results that have partial 
results in lines, such as:

in attribute inside xml file: 
./usr/lib/x86_64-linux-gnu/ImageMagick-6.9.7/config-Q16/configure.xml
https://tests.reproducible-builds.org/debian/dbd/experimental/amd64/imagemagick_6.9.7.0+dfsg-1.diffoscope.html

in html file: 
./usr/share/doc/singular-dev-doc/html/include_2factory_2factoryconf_8h_source.html
in .h file: ./usr/include/x86_64-linux-gnu/singular/factory/factoryconf.h
https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/diffoscope-results/singular.html

for some of them a beautifier will help (a good idea anyway, even if not 
related to this bug), a general fix as suggested in point 2 will be better 
(expand with JavaScript code)

Bug#734688: Logs are not rotated for a month

[Mathieu Parent]

Control: tag -1 + upstream fixed-upstream

Hello,

2016-12-26 1:29 GMT+01:00 Christoph Biedl :
> Hello everybody,
>
> looking at this old but nasty bug that must be fixed for stretch:
>
> * Trying to understand what goes wrong I wrote a small script that
>   creates a few scenarios and executes logrotate then. Run it in
>   an arbitrary directory like /tmp/ as regular user, with a single
>   parameter in the range 0 to 4. Expect a lot of failures.
>
> * In my understanding logrotate never compresses older logfiles even
>   if they are not compressed yet, this will lead to the observed
>   clashes. So I was about to write a patch that similar for Bolesław's
>   proposal detects if the target file already exists, but would
>   compress it then. However:
>
> * github[1] contains a link[2] to a patch gentoo created. At least
>   for all scenario my test script above creates, it solves the problems.
>   I'd suggest you all test it as well and report back.

The actual upstream fix for it is:
https://github.com/logrotate/logrotate/commit/fc1c3eff61edf8e9f0a4bfa980f3a6030a6b271f

And it is included in version 3.11.0.

The way forward is to update Debian package to 3.11.0.

Regards
-- 
Mathieu

Bug#849077: [pkg-wpa-devel] Bug#849077: wpasupplicant: [Regression] Updating wpasupplicant makes not possible to connect to encrypted WiFi

[Lisandro Damián Nicanor Pérez Meyer]

Thanks to Eduard Bloch at [bug] I've tried adding

[device]
wifi.scan-rand-mac-address=no

to /etc/NetworkManager/NetworkManager.conf

and updating wpasupplicant... and voilá, WiFi is on again.

[bug] 

I don't know if it's a bug in the driver, NM or wpasupplicant, but at least 
things now work.

Cheers, Lisandro.

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


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

Bug#849413: freedombox-setup: Drop net-tools dependency, no longer needed

[James Valleroy]

Package: freedombox-setup
Severity: minor
Tags: patch

Previously we were using some programs in net-tools, but they are no
longer needed:
- We now use NetworkManager to set up our network connections.
- The diagnostic tests to check open ports have been moved to Plinth,
and no longer use netstat.

net-tools is also considered obsolete by its Debian maintainer
(https://lists.debian.org/debian-devel/2016/12/msg00606.html).

I'm attaching a patch that drops the dependency on net-tools. I've done
basic testing of this patch, by building an image with freedom-maker and
accessing Plinth.

--
James
From 94e7d5de31b8c5431eef8c024401a1517f331b13 Mon Sep 17 00:00:00 2001
From: James Valleroy 
Date: Mon, 26 Dec 2016 11:54:08 -0500
Subject: [PATCH] Drop net-tools dependency

- We now use NetworkManager to set up our network connections.

- The diagnostic tests to check open ports have been moved to Plinth,
and no longer use netstat.
---
 debian/control | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/control b/debian/control
index ebb722c..4bd105f 100644
--- a/debian/control
+++ b/debian/control
@@ -52,7 +52,6 @@ Depends: ${misc:Depends}
  , lsof
  , netcat-openbsd
  , network-manager
- , net-tools
  , openssh-server
  , parted
  , plinth (>> 0.9.2)
-- 
2.11.0



signature.asc
Description: OpenPGP digital signature

Bug#849034: broadcom-sta-dkms: Can't connect to wireless, regression

[Lisandro Damián Nicanor Pérez Meyer]

On viernes, 23 de diciembre de 2016 13:36:07 ART Eduard Bloch wrote:
[snip] 
> Try adding
> 
> [device]
> wifi.scan-rand-mac-address=no
> 
> to /etc/NetworkManager/NetworkManager.conf and rebooting.

Eduard, you rock. At this point I don't know if it's a bug in the driver, wpa 
or NM, but for sure this made all work.

Thanks *a lot*!

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


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

Bug#829606: jessie-pu: package duck/0.7+deb8u1

[Moritz Mühlenhoff]

On Sun, Aug 28, 2016 at 03:55:24PM +0100, Adam D. Barratt wrote:
> Control: tags -1 +confirmed -moreinfo
> 
> [re-ordered]
> 
> > Am 2016-07-29 um 14:20 schrieb Julien Cristau:
> > > Control: tag -1 moreinfo
> > > 
> > > On Mon, Jul  4, 2016 at 18:22:46 +0200, Simon Kainz wrote:
> [...]
> > >> Paul Wise found out that duck rund untrusted code from the current 
> > >> directory as
> > >> well as the ./lib and ./lib/checks directory. The attached patch fixes 
> > >> this
> > >> issue.
> > >>
> > > Hi,
> > > 
> > > any chance of a diff from git diff -M or similar so the actual changes
> > > are easier to spot?
> 
> On Mon, 2016-08-01 at 20:41 +0200, Simon Kainz wrote:
> > Ok, please see the attached patch, which is the same as the previous
> > one, but cleaned up - i made a diff without commiting all my changes,
> > so git had a hard time recognising rename vs. delete&create new.
> 
> The changelog says "jessie-security" - with that changed to simply
> "jessie", please go ahead.

Simon,
what't the status here?

Cheers,
Moritz

Bug#844408: python-mimeparse: Vcs-Browser and Vcs-Git are broken

[Free Ekanayaka]

Mathias Ertl  writes:

> Hello,
>
> On 12/20/2016 11:44 AM, Free Ekanayaka wrote:
>> On 19 December 2016 at 22:12, Mathias Ertl > > wrote:
>> 
>> Hi,
>> 
>> I have just wasted another hour on trying to finally close this ticket
>> and finally start push a new version of this library.
>> 
>> I'm sorry, but my time is precious, just like anyone else's. This is the
>> git repository:
>> 
>> https://github.com/mathiasertl/python-mimeparse
>> 
>> 
>> Either we use that or please remove me as maintainer of the package.
>> 
>> 
>> I've taken the repository above and pushed it to Debian, you can clone
>> and commit to it with:
>> 
>> git clone
>> ssh://mathiasertl-gu...@git.debian.org/git/python-modules/packages/python-mimeparse.git
>> 
>
> That seems to work now. I do not see how I could've created that
> repository myself, I don't see any interface for it. Maybe it's hidden
> in some of the pages that simply don't work.

If you happen to need to create a repo in the future:

https://wiki.debian.org/Python/GitPackaging#Creating_new_repositories

> I have pushed changes to update the VCS-* URLs to the Debian repository.
> I guess that change would finally close this ticket?

I guess so, thanks. I'll give the changes a double check and then
perform the upload.

Cheers,

Free

Bug#849412: src:ovito: voro++ vendored in ovito

[Ghislain Antony Vaillant]

Package: src:ovito
Severity: normal

Dear Maintainer,

Ovito uses a vendored copy of voro++. It would be worth patching it to
use the system version once the latter is packaged.

Cheers,
Ghis


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

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

Bug#849411: diffoscope: HTML markup warnings/errors

[Emanuel Bronshtein]

Source: diffoscope
Severity: normal

Dear Maintainer,

W3 validator report several errors/warnings for diffoscope output, for example:
https://validator.w3.org/nu/?doc=https://tests.reproducible-builds.org/debian/dbd/unstable/amd64/monotone_1.1-9.diffoscope.html
https://validator.w3.org/nu/?doc=https://tests.reproducible-builds.org/debian/dbd/unstable/amd64/r-cran-filehash_2.3-1.diffoscope.html

list of reported issues:

Error: Bad value  for attribute name on element a: An ID must not be the empty 
string.
Error: Bad value #monotone-doc_1.1-9_all.deb/file list for attribute href on 
element a: Illegal character in fragment: space is not allowed.
Error: Bad value monotone-doc_1.1-9_all.deb/file list for attribute name on 
element a: An ID must not contain whitespace.
Error: Forbidden code point U+0098.
Error: Saw U+ in stream.
Error: td start tag in table body.
Error: End tag td seen, but there were open elements.
Error: Stray end tag del.
Error: Unclosed element ins.
Error: Unclosed element del.
Error: Table column 4 established by element col has no cells beginning in it.
Error: Table column 2 established by element col has no cells beginning in it.
Error: A table row was 2 columns wide, which is less than the column count 
established using column markup (4).

Warning: The name attribute is obsolete. Consider putting an id attribute on 
the nearest container instead.
Warning: This document appears to be written in English. Consider adding 
lang="en" (or variant) to the html start tag.

Bug#835367: ITP: voro++, progress on this ITP

[Ghislain Vaillant]

Hi Roger and the debian-astro team,

Could you please let me know what is your status on this ITP? I have a
package using an embedded copy of voro++ which would benefit from your
work.

Best regards,
Ghis

Bug#849410: ITP: libsub-quote-perl -- helper modules for subroutines

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libsub-quote-perl
  Version : 2.003001
  Upstream Author : mst - Matt S. Trout (cpan:MSTROUT) 
* URL : https://metacpan.org/release/Sub-Quote
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : helper modules for subroutines

This package includes two modules:

Sub::Quote provides performant ways to generate subroutines from strings.

Sub::Defer contains subroutines which provide the user with a convenient way
to defer creation of subroutines and methods until they are first called.

The package will be maintained under the umbrella of the Debian Perl Group.


signature.asc
Description: Digital Signature

Bug#848888: [PKG-Openstack-devel] Bug#848888: python-testtools: The testtools.deferredruntest module is not importable

[Free Ekanayaka]

Thomas Goirand  writes:

> On 12/22/2016 11:58 PM, Free Ekanayaka wrote:
>> Hello,
>> 
>> Thomas Goirand  writes:
>> 
>>> On 12/21/2016 02:57 PM, Free Ekanayaka wrote:
 Hello,

 I've prepared a 1.8.0-4.1 NMU upload to fix this bug, you can find it in
 the debian/bug-84 branch of this repository:

 git://anonscm.debian.org/collab-maint/deb-python-testtools.git
 

 The relevant commit/diff is:

 https://anonscm.debian.org/cgit/collab-maint/deb-python-testtools.git/commit/?h=debian/bug-84&id=429fb32d6f81f62e900750c7354d311b5605db5e

 If there are no objection I'll proceed with the upload (or lemme know if
 you want to do it yourself).

 Cheers,

 Free
>>>
>>> Hi,
>>>
>>> It'd be a way nicer if you could use Gerrit to share your patch. The way
>>> to do it is to use git review. If you don't know how, I can tell you,
>>> otherwise, I'll commit your patch to Gerrit. Please let me know what you
>>> prefer.
>> 
>> Sure, I wasn't aware of that. If you can send me a few pointers I'll get
>> it pushed to Gerrit.
>> 
>> Free
>
> First, register yourself, following the instructions here:
>
> https://wiki.openstack.org/wiki/How_To_Contribute#If_you.27re_a_developer
>
> What's important, is to get a launchpad ID and become an active
> contributor, so you get a Gerrit login. Once that's done, you can add
> something like this to your ~/.gitconfig:
>
> [gitreview]
>   username = thomas-goirand
>
> Then simply do this:
>
> # apt-get install git-review
> # git clone https://git.openstack.org/openstack/deb-python-testtools
> # cd deb-python-testtools
> # git checkout debian/newton
> [ ... add your patch here ... ]
> # git commit -a
> # git review
>
> The last command "git review" will push the patch to the CI, and build
> the package. Once that's done, we can review and approve the patch.
>
> If all of the above is too complex, we can still push the patch for you.

Thanks for the pointers, I've submitted:

https://review.openstack.org/#/c/415025/

It seems the CI pass is green (there are a few lintian messages, but
unrelated to the changeset, something we might want to clean up later
on).

Free

Bug#806092: [Pkg-electronics-devel] Bug#806092: proposed fix

[Bdale Garbee]

Dima Kogan  writes:

> I'm attaching two patches to fix this. Please review soon if
> possible. If I don't hear back by Dec 26, I'll NMU this. That's the
> latest possible day to meet the cutoff for stretch.

Thank you for your work on this.  I see that an upload has happened.
Please push this patch to the collab-maint git repo master branch, and
tag with "debian/20140316-3.1" so we don't lose track of this work going
forward.  If you don't know how to do this, let me know and I can do it
for you.

Regards,

Bdale


signature.asc
Description: PGP signature

Bug#745423: ITP: rubocop -- Ruby static code analyzer, based on the community Ruby style guide

[Miguel Landaeta]

retitle 745423 ITP: rubocop -- Ruby static code analyzer, based on the 
community Ruby style guide
thanks

Hi,

I'm interested in having this package in Debian, so I'll take care of
its packaging.

Thanks,

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#849377: debsums: Replace MD5 with a more secure algorithm

[Axel Beckert]

Control: tag -1 + confirmed
Control: severity -1 important
Control: block -1 by 540215
Control: retitle -1 debsums: Replace MD5 with a more secure algorithm, e.g. 
SHA256

Hi,

Javier Serrano Polo wrote:
> It would be nice if debsums worked with an algorithm more secure than
> MD5.

Yes, but before that, there need to be packages which support that.
See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540215#55
where this has been stated in the past. I fully agree with Ryan (the
previous maintainer of debsums).

> This issue is tracked at
> https://wiki.debian.org/Sha256sumsInPackages , but it does not seem
> to be any progress.

Indeed, there it says "dpkg: √ sha256sums file is saved in
/var/lib/dpkg/info/", but on an uptodate Debian Sid I see not a single
file with "ls -l /var/lib/dpkg/info/*.sha*sum*".

> While waiting for a proper solution, could you add this
> text to the package description?
> 
> "MD5 is considered weak nowadays. Do not rely on debsums to detect
> malicious changes."
> 
> This concern is because it is easy to craft programs with the same MD5
> hash that follow different execution paths.

With that argument, dpkg would need the same addition for its "dpkg
--verify". So I'd rather implement SHA256 checking if there would be a
package I could test that with.

So

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#849409: RM: partitionmanager [mips64el mipsel mips] -- ROM; Please remove bd-uninstallable mips* binary packages

[Jonathan Carter]

Package: ftp.debian.org
Severity: normal

Please remove bd-uninstallable binaries for partitionmanager on mips, mipsel 
and mips64el architectures.

Bug#849400: debian-installer: LUKS on rootfs and boot

[Cyril Brulebois]

Hi,

Pali Rohár  (2016-12-26):
> Package: debian-installer
> Severity: normal
> 
> Dear Maintainer,
> 
> Debian installer refuse me to install entire system (including /boot) on
> one encrypted partition. It shows me this red fatal error message:
> 
>   [!!] Partition disks
> 
>   Encryption configuration failure
> 
>   You have selected the root file system to be stored on an encrypted 
> partition. This
>   feature requires a separate /boot partition on which the kernel and initrd 
> can be stored.
> 
>   You should go back and setup a /boot partition.
> 
> There are two buttons  and  but both buttons go
> back and refuse to continue...
> 
> Then I tried to have separate /boot and separate / partitions, both
> LUKS encrypted. But Debian installer again refused to install such
> configuration. It show me another red fatal error message:
> 
>   [!!] Partition disks
> 
>   Encrypted configuration failure
> 
>   You have selected the /boot file system to be stored on an encrypted 
> partition. This is
>   not possible because the boot loader would be unable to load the kernel and 
> initrd.
>   Continuing now would result in an installation that cannot be used.
> 
>   You should go back and choose a non-encrypted partition for he /boot file 
> system.
> 
> Again there are two buttons:  and  and again both go
> back and does not allow me to process changes and continue.
> 
> And that error message is incorrect. Grub2 has already supports for
> accessing LUKS partitions. Just add GRUB_ENABLE_CRYPTODISK=y (or in
> older versions GRUB_CRYPTODISK_ENABLE=y) to /etc/default/grub.
> 
> Debian installer should allow users to install system on fully
> encrypted disk (also with /boot) and should not force users to have
> always /boot unencrypted.
> 
> At least expert users should be able to skip that error message and
> continue installation as error message is not truth anymore.

FWIW: This is implemented in the partman-crypto package, see
check.d/crypto_check_mountpoints

And yeah, given latest grub features, updating this logic/these checks
seems to make sense.

I'm not sure about possible side effects / requirements (like having to
preconfigure grub to have appropriate configuration bits); this would
likely lead to having to update some documentation; one might have to be
careful about archs where grub is available/can load stuff from an
encrypted device.


KiBi.


signature.asc
Description: Digital signature

Bug#849362: libstring-diff-perl: FTBFS: test failures with new libyaml-perl

[Niko Tyni]

Control: tag -1 patch

On Mon, Dec 26, 2016 at 10:59:33AM +0200, Niko Tyni wrote:
> Package: libstring-diff-perl
> Version: 0.07-1
> Severity: serious
> User: debian-p...@lists.debian.org
> Usertags: autopkgtest

>   #   Failed test at t/02_diff_fully-pp.t line 16.
>   # Structures begin differing at:
>   #  $got->[1] = undef
>   # $expected->[1] = ARRAY(0x557f6be5d7a8)
>   # Looks like you failed 1 test of 13.

Patch attached.
-- 
Niko Tyni   nt...@debian.org
>From 14e39a0ce479023f6e4fb226528ca86bb2bd58af Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Mon, 26 Dec 2016 19:39:12 +0200
Subject: [PATCH] Fix the test suite for YAML-1.21 compatibility

YAML-1.21, specifically ,
changed the handling of trailing nulls.

Adapt the test suite accordingly.

Bug-Debian: https://bugs.debian.org/849362
---
 t/02_diff_fully-pp.t | 2 +-
 t/02_diff_fully.t| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/02_diff_fully-pp.t b/t/02_diff_fully-pp.t
index 69a96ab..27e32bd 100644
--- a/t/02_diff_fully-pp.t
+++ b/t/02_diff_fully-pp.t
@@ -30,7 +30,7 @@ new: perl
 --- data1
 -
  - ['-', 'perl']
--
+- []
 --- data2
 old: perl
 new: 
diff --git a/t/02_diff_fully.t b/t/02_diff_fully.t
index f816a89..6c4c8d8 100644
--- a/t/02_diff_fully.t
+++ b/t/02_diff_fully.t
@@ -29,7 +29,7 @@ new: perl
 --- data1
 -
  - ['-', 'perl']
--
+- []
 --- data2
 old: perl
 new: 
-- 
2.11.0

Bug#849408: mention if ipv6 scripts are executed in addition, or instead of, ip scripts

[積丹尼 Dan Jacobson]

Package: ppp
Version: 2.4.7-1+4
Severity: wishlist
File: /usr/share/man/man8/pppd.8.gz
X-Debbugs-Cc: pau...@samba.org

   /etc/ppp/ipv6-up
  Like /etc/ppp/ip-up, except that it is executed when the link is
  available for sending and receiving IPv6 packets. It is executed
  with the parameters

  interface-name   tty-devicespeedlocal-link-local-address
  remote-link-local-address ipparam


Mention if these are executed in addition, or instead of, /etc/ppp/ip-up etc.

Bug#849407: diffoscope: Failures/Errors/Warnings in readelf/objdump usages

[Emanuel Bronshtein]

Source: diffoscope
Severity: normal

Dear Maintainer,

readelf/objdump return errors/warnings and sometimes fails, examples:

1. objdump: can't disassemble for architecture UNKNOWN!

1.1 objdump: section '.plt' mentioned in a -j option, but not found in 
any input file

http://37.218.242.117/com.traffar.pentago_2.apk.diffoscope.html#lib/armeabi-v7a/libSDL2.so

1.2 objdump: section '.text' mentioned in a -j option, but not found in 
any input file

http://37.218.242.117/us.achromaticmetaphor.agram_21.apk.diffoscope.html#lib/mips64/libanagram.so

2. readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/libgpg-error.html

3. readelf: Error: the dynamic segment offset + size exceeds the size of the 
file
https://tests.reproducible-builds.org/debian/dbd/unstable/amd64/lakai_0.1-2.diffoscope.html

4. readelf: Error: no .dynamic section in the dynamic segment
https://tests.reproducible-builds.org/debian/dbd/unstable/arm64/dbmix_0.9.8-6.3.diffoscope.html

5. readelf: Warning: There is a hole [0x741d3 - 0x741fc] in .debug_loc section.
https://tests.reproducible-builds.org/debian/dbd/unstable/arm64/k3b_2.0.3a-2.diffoscope.html

6. readelf: Warning: Section '.rodata' was not dumped because it does not exist!
https://tests.reproducible-builds.org/debian/dbd/unstable/arm64/zbar_0.10+doc-10.diffoscope.html


apart from fixing the above usages, maybe consider using radare2 
https://packages.debian.org/sid/radare2
which has disassembler for many formats/architectures instead by default if 
possible (readelf/objdump combination will be used as fallback)

debian-bugs-dist@lists.debian.org

[Ulyanich Michael]

Package: dunst
Version: 1.1.0-2
Severity: normal

Dear Maintainer,

just try:

notify-send 'summary' 'text'  # all right, summary is bold
notify-send 'summary with &' 'text'  # summary looks like 'text', it is not
bold



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

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

Versions of packages dunst depends on:
ii  libc62.24-8
ii  libcairo21.14.8-1
ii  libdbus-1-3  1.10.14-1
ii  libfreetype6 2.6.3-3+b1
ii  libglib2.0-0 2.50.2-2
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libx11-6 2:1.6.4-2
ii  libxdg-basedir1  1.2.0-1
ii  libxext6 2:1.3.3-1
ii  libxft2  2.3.2-1
ii  libxinerama1 2:1.1.3-1+b1
ii  libxss1  1:1.2.2-1

dunst recommends no packages.

dunst suggests no packages.