Bug#859522: RM: gaim-librvp -- RoQA; unmaintained; RC buggy; dead upstream; very low popcon

[Mattia Rizzolo]

Package: ftp.debian.org
X-Debbugs-Cc: gaim-lib...@packages.debian.org

Please remove gaim-librvp from the archive.

popcon is very low, just 2.
There has been no uploads since 2007, and even the last upstream release
has not been packaged, despite being from 2008.
RC bug opened one year ago has seen no replies.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#859520: [apt-cacher-ng] RequiresMountsFor should be in Unit section, rather than Service

[Antonio Russo]

Package: apt-cacher-ng
Version: 3-4
Severity: normal

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

The most visible symptom is a log message

[/lib/systemd/system/apt-cacher-ng.service:13] Unknown lvalue 
'RequiresMountsFor' in section 'Service'

Moving that parameter into the Unit section should handle the problem.


Thank you.

Bug#859521: unblock: khtml/5.28.0-2

[Maximiliano Curia]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

I've backported 2 fixes (with 3 patches) in khtml for stretch that I consider 
important enough, the first two fix the java permission dialogs for khtml 
widgets, the main user for these dialogs is the konqueror version that is not 
currently in stretch, but we might want to add it to stretch-backports in the 
future: 
 java: set names in permission dialog (856a968)
 java: apply the names to the right buttons (bd4be07)
Following that, an UX fix:
 Error page, correctly load the image (with a real URL) (ce81d9c)

Also, I've change the ssl build-dependency of khtml to libssl1.0-dev to follow 
the qt5 decission to stay with it (#856004).

And uploaded 5.28.0-2 with these changes.

I'm attaching the corresponding debdiff, the version 5.28.0-2 is already in 
sid, and built in all the release archs.

Happy hacking,

Please unblock package khtml

unblock khtml/5.28.0-2

- -- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEE+JIdOnQEyG4RNSIVxxl2mbKbIyoFAljjx3gQHG1heHlAZGVi
aWFuLm9yZwAKCRDHGXaZspsjKpX5EAC/ukHA4zHChkXk433VhrGNg1xFMqww0pIR
iTJCR90yfp26V7dtm3kp2JQMW4omg/SXY7BY/W5cEy6lEgHgQxAzEB8+Pa8/XdbR
kuHD7vwmtf6o8E81MspFahI+3NPLYfiXiMGyGvle/IcJv3aFko2/6eB90SJRX/G3
XQlneFk/bIVXr6CBt4prwl6wZrp2mSLwYLiP/ed+pgK/+lBj1vyJg0dkbi7abTF0
R7BKyTBOFCgAKvsycpob15Fksre4xgO7XX7tzlKBo0KP+aYgsTGQEuw2y2wQno6z
A2KQHdsawfHTjxFoOdt8djBdJEoUMx5pRZXzHoYUkg6uCLcfDUiwb193d+I/JMPg
Tcybw9km3laeACnZu/UHyccBNj2L52/mcEADLprr0BfZxIg1256KHJ5/W1FVVFrq
hK1Q4agKf2SkYIo8LG7EQHx9q6d3FEx70/SEYytb4PzWTEcl59DZqyQ7zTxrvQZJ
pi+o51Y1NAgBgFyotMJW19ZlTwDomkyqWAVIuQLHtStGV1mSFJ0qBmroBi0tbhIZ
A85EgieVudGe1f1AevEWR32ssyOD8rgE2ah0b7ISEJeb0rMy66Nj6y46UoQA1dCR
BdmKygSR4Y8cEmDQNE6zRXkymwVn1RmMOUFDdBDj1SEmovaKpA+ASPOxEe6FhOqR
zXIZzK+zbw==
=ZUOr
-END PGP SIGNATURE-
diff -Nru khtml-5.28.0/debian/changelog khtml-5.28.0/debian/changelog
--- khtml-5.28.0/debian/changelog   2016-11-18 16:08:04.0 +0100
+++ khtml-5.28.0/debian/changelog   2017-04-03 12:46:47.0 +0200
@@ -1,3 +1,17 @@
+khtml (5.28.0-2) unstable; urgency=medium
+
+  * Change libssl-dev build dependency to libssl1.0-dev to follow qt5.
+Thanks to Sebastian Andrzej Siewior for reporting and many others for the
+follow ups
+(Closes: 856004)
+  * Add upstream patches for the java permission dialog:
+java-set-names-in-permission-dialog.patch
+java-apply-the-names-to-the-right-buttons.patch
+  * Add new upstream patch:
+Error-page-correctly-load-the-image-with-a-real-URL.patch
+
+ -- Maximiliano Curia   Mon, 03 Apr 2017 12:46:47 +0200
+
 khtml (5.28.0-1) unstable; urgency=medium
 
   [ Automatic packaging ]
diff -Nru khtml-5.28.0/debian/control khtml-5.28.0/debian/control
--- khtml-5.28.0/debian/control 2016-11-18 16:08:04.0 +0100
+++ khtml-5.28.0/debian/control 2017-04-03 12:46:47.0 +0200
@@ -28,7 +28,7 @@
libphonon4qt5experimental-dev (>= 4:4.6.0),
libpng-dev,
libqt5x11extras5-dev (>= 5.5.0~),
-   libssl-dev,
+   libssl1.0-dev,
pkg-config,
pkg-kde-tools (>= 0.15.15ubuntu1~),
qtbase5-dev (>= 5.5.0~),
diff -Nru 
khtml-5.28.0/debian/patches/Error-page-correctly-load-the-image-with-a-real-URL.patch
 
khtml-5.28.0/debian/patches/Error-page-correctly-load-the-image-with-a-real-URL.patch
--- 
khtml-5.28.0/debian/patches/Error-page-correctly-load-the-image-with-a-real-URL.patch
   1970-01-01 01:00:00.0 +0100
+++ 
khtml-5.28.0/debian/patches/Error-page-correctly-load-the-image-with-a-real-URL.patch
   2017-04-03 12:46:47.0 +0200
@@ -0,0 +1,41 @@
+From: Luigi Toscano 
+Date: Sat, 18 Mar 2017 23:16:28 +0100
+Subject: Error page, correctly load the image (with a real URL)
+
+Summary:
+The local address to the image is injected into an HTML page (the
+error page). This address needs to be a proper URL with file:///,
+not just the absolute path to the image file - otherwise
+KIO::SimpleJobPrivate::simpleJobInit complains with "Invalid URL".
+
+Test Plan:
+Compiles, and when trying to load an invalid address in Konqueror
+with the KHTML part, the warning picture on the top-left corner is
+now visible.
+
+Reviewers: mpyne
+
+Reviewed By: mpyne
+
+Subscribers: mpyne, #frameworks
+
+Tags: #frameworks
+
+Differential Revision: 

Bug#859519: grub-common: A mistake in the Spanish grub-mklayout help translation

[Manolo Díaz]

Package: grub-common
Version: 2.02~beta3-5
Severity: minor
Tags: l10n

Dear Maintainer,

When the Spanish localization is used 'grub-mklayout --help' says:

  -i, --input=FICHEROestablece el fichero de salida. El
 predeterminado es STDOUT

that means:

  -i, --input=FILE   output filename. Default is STDOUT

Best Regards,
-- 
Manolo Díaz

Bug#859518: RM: facturlinex2 -- RoQA; RC buggy; very low popcon; unmaintained

[Mattia Rizzolo]

Package: ftp.debian.org
X-Debbugs-cc: facturlin...@packages.debian.org

Please remove facturlinex2 from the archive.

The maintainer is MIA, with unanswered RC bugs since 5 years ago.
Package skipped wheezy, jessie and stretch.
Popcon is just 2.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#859517: unblock: python-django/1.10.7-1

[Chris Lamb]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: python-modules-t...@lists.alioth.debian.org

Dear release team,

Please consider unblocking python-django 1.10.7-1 for stretch. The
relevant debian/changelog entry is:

python-django (1:1.10.7-1) unstable; urgency=medium

  * New upstream security release:

- CVE-2017-7233: Open redirect and possible XSS attack via user-supplied
  numeric redirect URLs.

  Django relies on user input in some cases (e.g.
  django.contrib.auth.views.login() and i18n) to redirect the user to an
  "on success" URL. The security check for these redirects (namely
  django.utils.http.is_safe_url()) considered some numeric URLs (e.g.
  http:9) "safe" when they shouldn't be.

  Also, if a developer relies on is_safe_url() to provide safe redirect
  targets and puts such a URL into a link, they could suffer from an XSS
  attack. (Closes: #859515)

- CVE-2017-7234: Open redirect vulnerability in django.views.static.serve().

  A maliciously crafted URL to a Django site using the
  django.views.static.serve() view could redirect to any other domain. The
  view no longer does any redirects as they don't provide any known,
  useful functionality.

  Note, however, that this view has always carried a warning that it is
  not hardened for production use and should be used only as a development
  aid. Thanks Phithon Gong for reporting this issue. (Closes: #859516)

Debdiff attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff -Nru python-django-1.10.6/AUTHORS python-django-1.10.7/AUTHORS
--- python-django-1.10.6/AUTHORS2017-03-01 14:28:15.0 +0100
+++ python-django-1.10.7/AUTHORS2017-04-04 16:16:56.0 +0200
@@ -692,6 +692,7 @@
 Stanislaus Madueke
 starrynight 
 Stefane Fermgier 
+Stefano Rivera 
 Stéphane Raimbault 
 Stephan Jaekel 
 Stephen Burrows 
diff -Nru python-django-1.10.6/debian/changelog 
python-django-1.10.7/debian/changelog
--- python-django-1.10.6/debian/changelog   2017-03-01 21:27:22.0 
+0100
+++ python-django-1.10.7/debian/changelog   2017-04-04 17:53:30.0 
+0200
@@ -1,3 +1,33 @@
+python-django (1:1.10.7-1) unstable; urgency=medium
+
+  * New upstream security release:
+
+- CVE-2017-7233: Open redirect and possible XSS attack via user-supplied
+  numeric redirect URLs.
+
+  Django relies on user input in some cases (e.g.
+  django.contrib.auth.views.login() and i18n) to redirect the user to an
+  "on success" URL. The security check for these redirects (namely
+  django.utils.http.is_safe_url()) considered some numeric URLs (e.g.
+  http:9) "safe" when they shouldn't be.
+
+  Also, if a developer relies on is_safe_url() to provide safe redirect
+  targets and puts such a URL into a link, they could suffer from an XSS
+  attack. (Closes: #859515)
+
+- CVE-2017-7234: Open redirect vulnerability in 
django.views.static.serve().
+
+  A maliciously crafted URL to a Django site using the
+  django.views.static.serve() view could redirect to any other domain. The
+  view no longer does any redirects as they don't provide any known,
+  useful functionality.
+
+  Note, however, that this view has always carried a warning that it is
+  not hardened for production use and should be used only as a development
+  aid. Thanks Phithon Gong for reporting this issue. (Closes: #859516)
+
+ -- Chris Lamb   Tue, 04 Apr 2017 17:53:30 +0200
+
 python-django (1:1.10.6-1) unstable; urgency=medium
 
   * New upstream bugfix release:
diff -Nru python-django-1.10.6/debian/.git-dpm 
python-django-1.10.7/debian/.git-dpm
--- python-django-1.10.6/debian/.git-dpm2017-03-01 21:27:22.0 
+0100
+++ python-django-1.10.7/debian/.git-dpm2017-04-04 17:53:30.0 
+0200
@@ -1,11 +1,11 @@
 # see git-dpm(1) from git-dpm package
-9e1c5de966ec84bda893f71e4d24080bfb53134e
-9e1c5de966ec84bda893f71e4d24080bfb53134e
-6af4842fcd60f750ff0cca6d0265854bd0910160
-6af4842fcd60f750ff0cca6d0265854bd0910160
-python-django_1.10.6.orig.tar.gz
-fd39b2134bafbd5b4af4500a948158abf3961e2b
-7734864
+0e464e28dd41c3a8d8fc0f3317650ec4e029b8c5
+0e464e28dd41c3a8d8fc0f3317650ec4e029b8c5
+f18dfc589f0b4a909be9e0cdcf48b70b4f3a7e4e
+f18dfc589f0b4a909be9e0cdcf48b70b4f3a7e4e
+python-django_1.10.7.orig.tar.gz
+5edd13a642460c33cdaf8e8166eccf6b2a2555df
+7737654
 debianTag="debian/%e%%%v"
 patchedTag="debian/patches/%e%%%v"
 upstreamTag="upstream/%e%%%u"
diff -Nru 
python-django-1.10.6/debian/patches/02_disable-sources-in-sphinxdoc.diff 

Bug#859515: python-django: CVE-2017-7233: Open redirect and possible XSS attack via user-supplied numeric redirect URLs

[Salvatore Bonaccorso]

Source: python-django
Version: 1.7.7-1
Severity: important
Tags: security upstream patch

Hi,

the following vulnerability was published for python-django.

CVE-2017-7233[0]:
|Open redirect and possible XSS attack via user-supplied numeric
|redirect URLs

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-7233
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7233

Regards,
Salvatore

Bug#859516: python-django: CVE-2017-7234: Open redirect vulnerability in django.views.static.serve()

[Salvatore Bonaccorso]

Source: python-django
Version: 1.7.7-1
Severity: important
Tags: security upstream patch

Hi,

the following vulnerability was published for python-django.

CVE-2017-7234[0]:
Open redirect vulnerability in django.views.static.serve()

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-7234
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7234

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#859513: New version available upstream

[Jeffrey Cliff]

Package:  libjs-angularjs
Version:1.6.1-1
Severity:   wishlist
Tags: experimental

Upstream has released a couple of new versions, currently at 1.6.4
https://github.com/angular/angular.js/releases

Bug#859514: file conflict with keyutils

[Alf Gaida]

Package: manpages
Version: 4.09-2
Severity: grave

Unpacking manpages (4.10-1) over (4.09-2) ...
dpkg: error processing archive /var/cache/apt/archives/manpages_4.10-1_all.deb 
(--unpack):
 trying to overwrite '/usr/share/man/man7/keyrings.7.gz', which is also in 
package keyutils 1.5.9-9
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)



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

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

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
it  man-db [man-browser]  2.7.6.1-2

-- no debconf information

Bug#859512: heaptrack: Could not find heaptrack interpreter executable: heaptrack_interpret

[Alberto Luaces]

Package: heaptrack
Version: 1.0.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

sorry I cannot be of more help since I was merely evaluating the
package, but when I try to trace the execution of any program, I get
the error:

$ heaptrack /bin/ls
Could not find heaptrack interpreter executable: 
/usr/bin/../lib/heaptrack/libexec/heaptrack_interpret

Certainly, I cannot find any heaptrack_interpret file on my system.

I am using the fish shell, but nothing changed when using bash.

Thanks!

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages heaptrack depends on:
ii  libboost-iostreams1.62.01.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-regex1.62.01.62.0+dfsg-4
ii  libc6   2.24-9
ii  libgcc1 1:6.3.0-11
ii  libstdc++6  6.3.0-11
ii  zlib1g  1:1.2.8.dfsg-5

heaptrack recommends no packages.

heaptrack suggests no packages.

-- no debconf information

Bug#859511: libbsd-dev: trying to overwrite '/usr/share/man/man3/explicit_bzero.3.gz', which is also in package manpages-dev 4.10-1

[Chris Lamb]

Package: libbsd-dev
Version: 0.8.3-1
Severity: serious

Hi,

I'm seeing:

[…]

Unpacking libbsd-dev:amd64 (0.8.3-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-tduipc/101-libbsd-dev_0.8.3-1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/man3/explicit_bzero.3.gz', which is also 
in package manpages-dev 4.10-1


Regards,

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

Bug#859213: stack smashing detected: x11vnc terminated

[Bernhard Ehlers]

The development of x11vnc seems to take place at 
https://github.com/LibVNC/x11vnc.
After adding the patches from https://github.com/LibVNC/x11vnc/pull/25 my 
issues are gone.

Bug#851486: Debug logs

[Adam Ward]

I finally located the serial cable.

Using the images firmware.BananaPi.img.gz and partition.img.gz (dated 
10-Jan-2017 21:37) at

http://ftp.uk.debian.org/debian/dists/jessie/main/installer-armhf/current/images/netboot/SD-card-images/

I started the installer and got the logs up to, and including, the 
network detection.

I did this using the serial console.
I attached a USB keyboard before turning the device on, but it was not 
working during the install.


Hardware summary and syslog is pasted below.

Hardware summary:
uname -a: Linux bananapi-wired 4.9.0-1-armmp #1 SMP Debian 4.9.2-2 
(2017-01-12) armv7l GNU/Linux

lsmod: Module  Size  Used by
lsmod: realtek 2775  0
lsmod: ohci_platform   4786  0
lsmod: ohci_hcd   37834  1 ohci_platform
lsmod: ehci_platform   5526  0
lsmod: dwmac_sunxi 2431  0
lsmod: stmmac_platform 4942  1 dwmac_sunxi
lsmod: ehci_hcd   64996  1 ehci_platform
lsmod: stmmac 97760  3 stmmac_platform,dwmac_sunxi
lsmod: usbcore   195632  4 
ehci_hcd,ohci_hcd,ehci_platform,ohci_platform

lsmod: phy_sun4i_usb   8637  0
lsmod: sunxi_mmc  12421  0
lsmod: extcon_core13223  1 phy_sun4i_usb
lsmod: usb_common  3659  2 phy_sun4i_usb,usbcore
lsmod: leds_gpio   3390  0
df: Filesystem   1K-blocks  Used Available Use% Mounted on
df: none10250820102488   0% /run
df: devtmpfs493880 0493880   0% /dev
free:  total used free   shared  buffers
free: Mem:   102504873368   951680502000
free: -/+ buffers:  73368   951680
free: Swap:000
/proc/cmdline:  console=ttyS0,115200
/proc/cpuinfo: processor: 0
/proc/cpuinfo: model name   : ARMv7 Processor rev 4 (v7l)
/proc/cpuinfo: BogoMIPS : 48.00
/proc/cpuinfo: Features	: half thumb fastmult vfp edsp thumbee neon 
vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm

/proc/cpuinfo: CPU implementer  : 0x41
/proc/cpuinfo: CPU architecture: 7
/proc/cpuinfo: CPU variant  : 0x0
/proc/cpuinfo: CPU part : 0xc07
/proc/cpuinfo: CPU revision : 4
/proc/cpuinfo:
/proc/cpuinfo: processor: 1
/proc/cpuinfo: model name   : ARMv7 Processor rev 4 (v7l)
/proc/cpuinfo: BogoMIPS : 48.00
/proc/cpuinfo: Features	: half thumb fastmult vfp edsp thumbee neon 
vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm

/proc/cpuinfo: CPU implementer  : 0x41
/proc/cpuinfo: CPU architecture: 7
/proc/cpuinfo: CPU variant  : 0x0
/proc/cpuinfo: CPU part : 0xc07
/proc/cpuinfo: CPU revision : 4
/proc/cpuinfo:
/proc/cpuinfo: Hardware : Allwinner sun7i (A20) Family
/proc/cpuinfo: Revision : 
/proc/cpuinfo: Serial   : 1651664a0642d465
/proc/device-tree/model: LeMaker Banana Pi\00/proc/iomem: 
-bfff : 0.sram

/proc/iomem: 0001-00010fff : 1.sram
/proc/iomem: 01c0-01c0002f : /soc@01c0/sram-controller@01c0
/proc/iomem: 01c00030-01c0003b : /soc@01c0/interrupt-controller@01c00030
/proc/iomem: 01c02000-01c02fff : /soc@01c0/dma-controller@01c02000
/proc/iomem: 01c0f000-01c0 : /soc@01c0/mmc@01c0f000
/proc/iomem: 01c20008-01c2000f : /clocks/clk@01c20008
/proc/iomem: 01c20010-01c20013 : /clocks/clk@01c20010
/proc/iomem: 01c20030-01c20033 : /clocks/clk@01c20030
/proc/iomem: 01c20060-01c20067 : /clocks/clk@01c20060
/proc/iomem: 01c20068-01c2006b : /clocks/clk@01c20068
/proc/iomem: 01c2006c-01c2006f : /clocks/clk@01c2006c
/proc/iomem: 01c20088-01c2008b : /clocks/clk@01c20088
/proc/iomem: 01c2008c-01c2008f : /clocks/clk@01c2008c
/proc/iomem: 01c20090-01c20093 : /clocks/clk@01c20090
/proc/iomem: 01c20094-01c20097 : /clocks/clk@01c20094
/proc/iomem: 01c200b8-01c200bb : /clocks/clk@01c200b8
/proc/iomem: 01c200bc-01c200bf : /clocks/clk@01c200bc
/proc/iomem: 01c200c0-01c200c3 : /clocks/clk@01c200c0
/proc/iomem: 01c200cc-01c200cf : /clocks/clk@01c200cc
/proc/iomem: 01c200d8-01c200db : /clocks/clk@01c200d8
/proc/iomem: 01c200dc-01c200df : /clocks/clk@01c200dc
/proc/iomem: 01c20100-01c20103 : /clocks/clk@01c20100
/proc/iomem: 01c20104-01c20107 : /clocks/clk@01c20104
/proc/iomem: 01c20108-01c2010b : /clocks/clk@01c20108
/proc/iomem: 01c2010c-01c2010f : /clocks/clk@01c2010c
/proc/iomem: 01c20110-01c20113 : /clocks/clk@01c20110
/proc/iomem: 01c20118-01c2011b : /clocks/clk@01c20118
/proc/iomem: 01c2011c-01c2011f : /clocks/clk@01c2011c
/proc/iomem: 01c2012c-01c2012f : /clocks/clk@01c2012c
/proc/iomem: 01c20130-01c20133 : /clocks/clk@01c20130
/proc/iomem: 01c2013c-01c2013f : /clocks/clk@01c2013c
/proc/iomem: 01c20140-01c20143 : /clocks/clk@01c20140
/proc/iomem: 01c20800-01c20bff : /soc@01c0/pinctrl@01c20800
/proc/iomem: 01c20d00-01c20d1f : /soc@01c0/rtc@01c20d00
/proc/iomem: 01c28000-01c2801f : serial
/proc/iomem: 01c28c00-01c28c1f : serial
/proc/iomem: 01c29c00-01c29c1f : 

Bug#859219: phpmyadmin: Fails to build from source, illegal character in input string

[Niels Thykier]

Michal Čihař:
> Hi
> 
> Niels Thykier píše v Út 04. 04. 2017 v 12:37 +:
>> Would it be possible to use a short term work around by using a
>> different locale during the tests (e.g. en_US.UTF-8)? Then we can use
>> look at a better long term solution after stretch has been released.
> 
> I've done that just now (I would have done that on previous upload if I
> didn't forget).
> 

Thanks, much appreciated. :)

Unfortunately, I am told that "en_US.UTF-8" is not guaranteed to exist
(despite that it is there on our buildds) unless you B-D on locales-all.

If you don't want that, you can use:

"""
Build-Depends: locales


test:
  localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias \
   --quiet debian/en_US.UTF-8 || exit 1
  LOCPATH=debian LC_ALL=en_US.UTF-8 phpunit --config \
phpunit.xml.nocoverage --exclude-group selenium \
--exclude-group network

clean:
  rm -f debian/en_US.UTF-8
"""

Mind you though, that this assumes "locales" and *not* locales-all.  At
least back in the Squeeze/Wheezy days, locales-all was not a substitute
for locales IRT to code-snippet above.

Thanks,
~Niels

Bug#859451: [Pkg-utopia-maintainers] Bug#859451: dbus: error messages on boot for systems with NSS LDAP

[Laurent Bonnaud]

On 04/04/2017 15:58, Michael Biebl wrote:

> Can you double check that all users from
> 
> grep -s -R -E "(user|group)=" /etc/dbus-1/system.d/
> /usr/share/dbus-1/system.d/ | sed 's/.*/\1/' | sort -u
> 
> are available in /etc/passwd and /etc/group

Here it is:

# grep -s -R -E "(user|group)=" /etc/dbus-1/system.d/ 
/usr/share/dbus-1/system.d/ | sed 's/.*/\1/' | sort -u
 user="root"
 user="systemd-network"
 user="systemd-resolve"

# grep systemd /etc/passwd
systemd-timesync:x:100:103:systemd Time 
Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:104:systemd Network 
Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:105:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:106:systemd Bus Proxy,,,:/run/systemd:/bin/false

-- 
Laurent.

Bug#858897: closed by Ben Hutchings <b...@decadent.org.uk> (Bug#858897: fixed in linux 4.10.7-1~exp1)

[Alexandra N. Kossovsky]

The problem is solved now.  Thank you very much!

On 03/04/17 15:03, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the src:linux package:

#858897: linux-image-4.10.0-trunk-amd64-unsigned: NETFILTER_XT_MATCH_SOCKET and 
NF_SOCKET_IPV4 are disabled: IP_TRANSPARENT does not work

It has been closed by Ben Hutchings .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Ben Hutchings 
 by
replying to this email.





--
Alexandra N. Kossovsky
OKTET Labs (http://www.oktetlabs.ru/)

Bug#859510: Generated header file without means to regenerate

[James Clarke]

Source: ruby-unf-ext
Version: 0.0.7.2-2
Severity: serious

Hi,
While investigating #859463 with Niels, we noticed that the file in
question, ext/unf_ext/unf/table.hh, is pre-generated, but the original
sources[1] (and script used to process the sources[2]) are not present
in main.

Regards,
James

[1] https://github.com/sile/unf/tree/master/data
[2] https://github.com/sile/unf/blob/master/lisp/gen-table.lisp

Bug#859463: ruby-unf-ext FTBFS on ppc64el: unf/table.hh:13539:25: error: narrowing conversion of '-52' from 'int' to 'char' inside { } [-Wnarrowing]

[Niels Thykier]

On Mon, 03 Apr 2017 23:38:48 +0300 Adrian Bunk  wrote:
> Source: ruby-unf-ext
> Version: 0.0.7.2-2
> Severity: serious
> 
> ruby-unf-ext FTBFS on ppc64el (originally reported by Frederic Bonnard):
> 
> ...
> unf/table.hh:13539:25: error: narrowing conversion of '-51' from 'int' to 
> 'char' inside { } [-Wnarrowing]
> unf/table.hh:13539:25: error: narrowing conversion of '-123' from 'int' to 
> 'char' inside { } [-Wnarrowing]
> unf/table.hh:13539:25: error: narrowing conversion of '-50' from 'int' to 
> 'char' inside { } [-Wnarrowing]
> unf/table.hh:13539:25: error: narrowing conversion of '-105' from 'int' to 
> 'char' inside { } [-Wnarrowing]
> unf/table.hh:13539:25: error: narrowing conversion of '-52' from 'int' to 
> 'char' inside { } [-Wnarrowing]
> ...
> 
> 
> Complete log is attached.

This is caused by ppc64el having "char" being unsigned by default.
Beyond the table that needs to be converted/dealt with, there are about
20 -Wsign-conversion issues in the code that smells like they may cause
issues as well.

That said, a short term fix may be to revert:
https://github.com/knu/ruby-unf_ext/commit/1e2d2bc29798342ab2616eb3d74ea36c793a33e4

Thanks,
~Niels

Bug#706656: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

> Any reason you took this off-list?  I'm not sending your mail back to it
> without your permission, but if it was a mistake, feel free to post any of my
> replies back to the list as well.

I'm sorry, that wasn't my intention. I believe one of your responses was
addressed to me personally, so I thought you wanted to discuss the issue in
private first to reduce list noise. Or, maybe I forgot the Cc myself at some
point, and your responses were off-list after that.

Looks like this was a total misunderstanding!

The previous discussion follows:

>> >> Looking at libArcus, I see two things: the problem that it detects is
>> >> that the watch file doesn't match any file on github.  This is because of
>> >> the "d" you left in there, which means it will only match versions
>> >> starting with a literal d.  If you remove it, it accepts any file that
>> >> starts with a number (and ends with .tar.gz).
>> > 
>> > Argh. I thought I had copy-pasted the Github rule from the Debian docs.
>> > Looks like I messed that up.
>> 
>> Now I remember why I did this:
>> I was planning to tag my Debian releases as 'd2.3.1' to differentiate them
>> from the upstream '2.3.1'. But that's not the best idea, and they still lack
>> the Debian release ('2.3.1-1').
>> 
>> I'll probably settle for debian-2.3.1 (branches) and debian-2.3.1-1 (tags).
> 
> Ah, I see.  I think you should use upstream's releases anyway; if you need to
> make changes for the packaging, they should just be part of the package, not a
> fork from upstream.  Especially if the only change that your personal upstream
> has compared to the real upstream is the version number.
> 
> So unless I'm missing something, I think you should use Ultimaker's source as
> upstream.  If you need any changes (such as using packaged libraries), they
> should be part of the packaging (through patches).
> 
> Of course it is still useful to have your packaging (the debian directory)
> under version control as well, and using names for those releases also makes
> sense.  If you want to name them debian-* that's fine, although given that 
> they
> only contain the debian directory, it doesn't seem like it would confuse 
> anyone
> anyway.
> 
>> Ok, so... libclipper is not what you think it is.
>> The one used by Cura comes from here: http://www.angusj.com/delphi/
>> While the one in Debian is this one:
>> http://www.ysbl.york.ac.uk/~cowtan/clipper/clipper.html
> 
> Ah yes, clipper has weird and annoying naming.  I talked to upstream about it,
> but they don't want to change it.  I think it had something to do with a
> package naming conflict in Red Hat.  In any case, the package is called
> libpolyclipping.  There is a pkg-config file with it, but it's broken, so I
> changed it.  I don't think the change made it in upstream's release, although
> I'm not sure.  Code should use #include  and be compiled with:
> 
> g++ `pkg-config --cflags polyclipping` -c source.cpp -o object.o
> g++ `pkg-config --libs polyclipping` object.o -o target
> 
> This will add -I/usr/include/polyclipping and -lpolyclipping respectively.
> 
>> Cura's clipper consists of two files and has no external dependencies. I 
>> don't
>> think repackaging it is worth the effort. Should a security-critical bug be
>> discovered, it's not going to be too hard to convince the Cura developers to
>> patch CuraEngine.
> 
> When I packaged the previous version of Cura (of which only CuraEngine made it
> into Debian), I thought it was worth the effort, so luckily for you I already
> packaged it. :)
> 
>> rapidjson is a different story. I managed to build CuraEngine with
>> librapidjson from sid by patching CMakeLists and removing rapidjson from the
>> tree. I'm not particulary happy with the solution, but it seems to work.
> 
> Sounds good.  I think this is the way to go; I understand upstream when they
> want to bundle their dependencies, so it's not useful to try to convince them
> to stop doing that (aside from the fact that we most likely wouldn't succeed).
> But them bundling them doesn't mean that we should use those version.  One
> point of having a distribution is that we can trust our packages, so we don't
> have to fear our dependencies doing weird things without us knowing about it.
> 
>> Now, as for the final result: It is mostly unusable, and I don't know yet if
>> it's upstream's fault or that I missed some files. In any case, there was a
>> regression in 2.3 that made the UI unusable on small screen resolutions. 
>> 2.1.3
>> had worked fine.
> 
> I tried the earlier version from you, which was also unusable for me because 
> it
> didn't support delta printers.  I downloaded their new release (2.4), which
> works fine for me.
> 
>> I'm going to double-check if I've missed any files, and then I'll patch up 
>> the
>> the sources to 2.4.0. Hopefully that fixes things.
> 
> Sounds good.  Thanks for your work!
> Bas
> 

Bug#859451: [Pkg-utopia-maintainers] Bug#859451: dbus: error messages on boot for systems with NSS LDAP

[Michael Biebl]

Am 04.04.2017 um 13:53 schrieb Laurent Bonnaud:
> On 04/04/2017 13:29, Simon McVittie wrote:

>> Alternatively, your NSS configuration might be such that the NSS-backed
>> library calls that dbus-daemon uses during configuration loading (mainly
>> getpwuid_r() and getgrnam_r() I think) hit the network even if the
>> group is configured locally.
> 
> In /etc/nsswitch.conf LDAP is configured as follows:
> 
> passwd: files ldap
> group:  files ldap

Any idea why NSS tries to use ldap although, as you said, all system
users are local? Can you double check that all users from

grep -s -R -E "(user|group)=" /etc/dbus-1/system.d/
/usr/share/dbus-1/system.d/ | sed 's/.*/\1/' | sort -u

are available in /etc/passwd and /etc/group



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#859389: ejabberd: SSL handshake fails in Pidgin and Yaxim after 2.1.10-4+deb7u2 update

[Philipp Huebner]

Hi,

as it turns out, the new cipher set is more restrictive than intended
and only leaves ciphers supported exclusively via TLS 1.2, thus
indirectly disabling not only SSLv3 but also TLS 1.0 and TLS 1.1.

Hardcoding the cipher set is really a pain and I urge everyone to
upgrade to at least ejabberd 14.07 where SSL/TLS is easily configurable.

Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#859508: thunderbird: Please add build support for sh4

[John Paul Adrian Glaubitz]

Source: icedove
Version: 1:45.8.0-3
Severity: normal
Tags: patch
User: debian-sup...@lists.debian.org
Usertags: sh4

Hi!

The attached patch adds build support for Thunderbird 45.x for SuperH
(sh4). Most of the changes contained in this patch have already been
merged upstream (upstream commit are mentioned in the patch), the only
part not merged upstream yet is the SH-specific XPCOM code [1] which
is also currently part of Debian's Thunderbird package in the patch
"Add-xptcall-support-for-SH4-processors.patch".

Since the version of the patch that the Debian package is currently
shipping is outdated and does not actually work, I have requested
the removal of this patch in #859362 [2].

Please let me know when you need help with any of the patches I sent
in. I'm happy to provide updated patches for newer Thunderbird versions
if necessary.

Thanks,
Adrian

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=382214
> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859362

--
 .''`.  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
Description: Add sh4 support to Thunderbird
 Cherry-picked and adapted patches from Firefox upstream:
 - b179235c38eb631286f9e2fd4a7b23361dbab6d2
   Bug 1329194 - js:jit: Use PowerPC atomic operations on SH.
 - ba58645c87ed7e08b16adc3b40f0c6e3b6a2e140
   Bug 1329194 - mfbt:tests: Define RETURN_INSTR for SH in TestPoisonArea.
 - 942df3d3a4a1db3d182e97c54fb1705c50128470
   Bug 1329194 - ipc:chromium: Add platform defines for SH.
 - 85ae466ed90b3a0cac396aed24722ce4d0febb31
   Bug 1329194 - media:webrtc: Add platform defines for SH.
 - 5a74d13630a969473f72a143f37728f5bb87f552
   Bug 1329194 - mozbuild: Add SH4 as target architecture.
 - (not committed upstream yet)
   Bug 382214 - xpcom: Add xptcall support for Linux/SH
 - (not committed upstream yet)
   Bug 382214 - xpcom: Make SH xpctcall inline assembly position-independent
Author: John Paul Adrian Glaubitz 
Last-Update: 2017-04-04

--- icedove-45.8.0.orig/mozilla/ipc/chromium/src/build/build_config.h
+++ icedove-45.8.0/mozilla/ipc/chromium/src/build/build_config.h
@@ -106,6 +106,9 @@
 #elif defined(__s390__)
 #define ARCH_CPU_S390 1
 #define ARCH_CPU_32_BITS 1
+#elif defined(__sh__)
+#define ARCH_CPU_SH 1
+#define ARCH_CPU_32_BITS 1
 #elif defined(__alpha__)
 #define ARCH_CPU_ALPHA 1
 #define ARCH_CPU_64_BITS 1
--- icedove-45.8.0.orig/mozilla/js/src/jit/AtomicOperations.h
+++ icedove-45.8.0/mozilla/js/src/jit/AtomicOperations.h
@@ -306,6 +306,8 @@ AtomicOperations::isLockfree(int32_t siz
 || defined(__ppc64le__) || defined(__PPC64LE__) \
 || defined(__ppc__) || defined(__PPC__)
 # include "jit/none/AtomicOperations-ppc.h"
+#elif defined(__sh__)
+# include "jit/none/AtomicOperations-ppc.h"
 #elif defined(JS_CODEGEN_NONE)
 # include "jit/none/AtomicOperations-none.h"
 #elif defined(JS_CODEGEN_X86) || defined(JS_CODEGEN_X64)
--- icedove-45.8.0.orig/mozilla/media/webrtc/trunk/build/build_config.h
+++ icedove-45.8.0/mozilla/media/webrtc/trunk/build/build_config.h
@@ -157,6 +157,9 @@
 #elif defined(__s390__)
 #define ARCH_CPU_S390 1
 #define ARCH_CPU_32_BITS 1
+#elif defined(__sh__)
+#define ARCH_CPU_SH 1
+#define ARCH_CPU_32_BITS 1
 #elif defined(__alpha__)
 #define ARCH_CPU_ALPHA 1
 #define ARCH_CPU_64_BITS 1
--- icedove-45.8.0.orig/mozilla/mfbt/tests/TestPoisonArea.cpp
+++ icedove-45.8.0/mozilla/mfbt/tests/TestPoisonArea.cpp
@@ -154,6 +154,9 @@
 #elif defined __s390__
 #define RETURN_INSTR 0x07fe /* br %r14 */
 
+#elif defined __sh__
+#define RETURN_INSTR 0x0b000b00 /* rts; rts */
+
 #elif defined __aarch64__
 #define RETURN_INSTR 0xd65f03c0 /* ret */
 
--- icedove-45.8.0.orig/mozilla/xpcom/reflect/xptcall/md/unix/moz.build
+++ icedove-45.8.0/mozilla/xpcom/reflect/xptcall/md/unix/moz.build
@@ -316,6 +316,11 @@ if CONFIG['OS_ARCH'] == 'Linux':
 '-fomit-frame-pointer',
 '-mbackchain',
 ]
+elif CONFIG['OS_TEST'] in ('sh4', 'sh4a'):
+SOURCES += [
+'xptcinvoke_linux_sh.cpp',
+'xptcstubs_linux_sh.cpp',
+]
 
 FINAL_LIBRARY = 'xul'
 
--- /dev/null
+++ icedove-45.8.0/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_linux_sh.cpp
@@ -0,0 +1,211 @@
+/* -*- Mode: C; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*-
+ *
+ * * BEGIN LICENSE BLOCK *
+ * Version: MPL 1.1/GPL 2.0/LGPL 2.1
+ *
+ * The contents of this file are subject to the Mozilla Public License Version
+ * 1.1 (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ * http://www.mozilla.org/MPL/
+ *
+ * Software distributed under the License is distributed on an "AS IS" basis,
+ * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
+ * for the specific language governing rights and limitations under the
+ * 

Bug#859507: ITP: r-cran-lexrankr -- extractive summarization of text with the LexRank algorithm

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-lexrankr
  Version : 0.4.0
  Upstream Author : Adam Spannbauer 
* URL : https://cran.r-project.org/package=lexRankr
* License : MIT
  Programming Lang: R
  Description : extractive summarization of text with the LexRank algorithm
 An R implementation of the LexRank algorithm implementing stochastic
 graph-based method for computing relative importance of textual units
 for Natural Language Processing. We test the technique on the problem
 of Text Summarization (TS). Extractive TS relies on the concept of
 sentence salience to identify the most important sentences in a
 document or set of documents. Salience is typically defined in terms of
 the presence of particular important words or in terms of similarity to
 a centroid pseudo-sentence.


Remark: This package will be maintained by the Debian Med team since it
might be useful for the epidemiology task.  The maintenance will be done at
   svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-lexrankr/trunk/

Bug#857343: closed by Markus Koschany <a...@debian.org> (Bug#857343: fixed in logback 1:1.1.9-2)

[Markus Koschany]

Am 01.04.2017 um 08:20 schrieb Fabrice Dagorn:
> The POC is a simple Eclipse java project.
> 
> UnsafeReceiver will open a ServerSocketReceiver on  port and wait
> forever.
> 
> Injector will then open a client Socket to the ServerSocketReceiver and
> serialize a Calculator instance through the wire.
> 
> Calculator implements ILoggingEvent to prevent ClassCastException on
> deserialization but Logback won't check more and getLoggerName() is called.
> 
> In this case, the gnome calculator is executed.

Thank you for the reproducer. I believe the issue is fixed now and I am
going to upload the new revision soon.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#859506: ITP: seqsero -- Salmonella serotyping from genome sequencing data

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: seqsero
  Version : 1.0
  Upstream Author : Shaokang Zhang (zsk...@uga.edu) and Xiangyu Deng 
(xd...@uga.edu)
* URL : https://github.com/denglab/SeqSero
* License : GPL
  Programming Lang: Python
  Description : Salmonella serotyping from genome sequencing data
 SeqSero is a pipeline for Salmonella serotype determination from raw
 sequencing reads or genome assemblies.
 .
 SeqSero is a novel tool for determining Salmonella serotypes using high-
 throughput genome sequencing data. SeqSero is based on curated databases
 of Salmonella serotype determinants (rfb gene cluster, fliC and fljB
 alleles) and is predicted to determine serotype rapidly and accurately
 for nearly the full spectrum of Salmonella serotypes (more than 2,300
 serotypes), from both raw sequencing reads and genome assemblies. The
 performance of SeqSero was evaluated by testing
  1. raw reads from genomes of 308 Salmonella isolates of known serotype
  2. raw reads from genomes of 3,306 Salmonella isolates sequenced and
 made publicly available by GenomeTrakr, a U.S. national monitoring
 network operated by the Food and Drug Administration; and
  3. 354 other publicly available draft or complete Salmonella genomes.
 SeqSero can help to maintain the well-established utility of Salmonella
 serotyping when integrated into a platform of WGS-based pathogen
 subtyping and characterization.


Remark: This package will be maintained by the Debian Med team at
https://anonscm.debian.org/git/debian-med/seqsero.git

Bug#859271: thunderbird: Please add build support for m68k

[John Paul Adrian Glaubitz]

Hi Carsten!

On 04/02/2017 10:11 AM, Carsten Schoenert wrote:
> your patch(es) are being applied into the debian/sid branch. Thanks for
> preparing the set.

Thanks a lot for the consideration.

> Right now I can't say if we will upload another 45.8.0 version to
> unstable. Upstream isn't clear on preparing a 45.9.0 or go over to 52.0
> directly.

I see, thanks for the heads-up. In any case, I can provide updated patches
for the Firefox 52.0 code base. There are some minor tweaks necessary
to make the patches work with the newer code base.

> An maybe we need to drop those patches for the Stretch
> release, we need to ask the release team if they accept this two patches.

No hurries, take your time :).

> But they are not lost in that case, they will need some adoptions for
> 52.x for sure.

That's correct. And I am happy to provide these patches for you once
that happens. Just ping me back on any of the patches and I will
follow up with updated patches quicklu.

> I'm having some trouble with building 52.0 for now and dropping before
> all extra modifications to get a successful build.

Let me know if there is anything I can help with. I have some experience
with building Firefox already so I might be able to help :).

Thanks,
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#859219: phpmyadmin: Fails to build from source, illegal character in input string

[Michal Čihař]

Hi

Niels Thykier píše v Út 04. 04. 2017 v 12:37 +:
> Would it be possible to use a short term work around by using a
> different locale during the tests (e.g. en_US.UTF-8)? Then we can use
> look at a better long term solution after stretch has been released.

I've done that just now (I would have done that on previous upload if I
didn't forget).

-- 
Michal Čihař | https://cihar.com/ | https://weblate.org/


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

Bug#859505: should allow for installing without deploying uftpd service

[Yaroslav Halchenko]

Package: uftp
Version: 4.9.3-1
Severity: wishlist

uftpd can be used without system user privileges, and it is impossible to
start another uftpd if there is a system one already running on that port.

Now git-annex (https://git-annex.branchable.com/git-annex-multicast/) can use
it to exchange content between the clones, so there is a specific use case for
above scenario where having a service running would conflict

moreover listening on the network and saving everything received without
any additional authentication sounds like a security and DoS hazard

altogether I do not think that in default mode of installation uftp package,
it should deploy itself as a service to save anything anywhere, and may
be only through debconf question either server-wide service should be deployed
(with default answer 'No') it should install such a service

thanks! ;)

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

Kernel: Linux 4.9.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 uftp depends on:
ii  debconf [debconf-2.0]  1.5.60
ii  libc6  2.24-9
ii  libssl1.1  1.1.0d-2

uftp recommends no packages.

uftp suggests no packages.

-- debconf-show failed

Bug#859504: python-requests breaks packages using urllib3

[Ilias Tsitsimpis]

Package: python-requests
Version: 2.12.4-1
Severity: important
Tags: patch

Hello,

thank you for maintaining python-requests.

It seems that patch use-pip-unbundling.patch doen not work as expected:

>>> import sys, urllib3
>>> from urllib3.exceptions import HTTPError
>>> urllib3.exceptions.HTTPError is HTTPError
True
>>> sys.modules["urllib3.exceptions"] is urllib3.exceptions
True
>>> import requests
>>> urllib3.exceptions.HTTPError is HTTPError
False
>>> sys.modules["urllib3.exceptions"] is urllib3.exceptions
False

This causes (otherwise correct) Python programs to fail by simply
importing the 'requests' module. The solution proposed by upstream[1]
doesn't work either.

[1] 
https://github.com/kennethreitz/requests/blob/master/requests/packages/__init__.py

Attached is a patch that works for me and seems to fix the above bug.
It would be great if this could be fixed for stretch.

Best,

-- 
Ilias
diff -pru old/debian/patches/use-pip-unbundling.patch new/debian/patches/use-pip-unbundling.patch
--- old/debian/patches/use-pip-unbundling.patch	2017-04-04 13:31:19.965450626 +0300
+++ new/debian/patches/use-pip-unbundling.patch	2017-04-04 13:35:17.882779284 +0300
@@ -10,11 +10,11 @@ Patch-Name: use-pip-unbundling.patch
  requests/packages/__init__.py | 66 +--
  1 file changed, 51 insertions(+), 15 deletions(-)
 
-diff --git a/requests/packages/__init__.py b/requests/packages/__init__.py
-index 4077265..b1206b2 100644
+Index: b/requests/packages/__init__.py
+===
 --- a/requests/packages/__init__.py
 +++ b/requests/packages/__init__.py
-@@ -23,20 +23,56 @@ request.
+@@ -23,20 +23,54 @@ request.
  from __future__ import absolute_import
  import sys
  
@@ -34,24 +34,21 @@ index 4077265..b1206b2 100644
 -import chardet
 -sys.modules['%s.chardet' % __name__] = chardet
 +try:
-+__import__(vendored_name, globals(), locals(), level=0)
++__import__(modulename, globals(), locals(), level=0)
 +except ImportError:
-+try:
-+__import__(modulename, globals(), locals(), level=0)
-+except ImportError:
-+# We can just silently allow import failures to pass here. If we
-+# got to this point it means that ``import requests.packages.whatever``
-+# failed and so did ``import whatever``. Since we're importing this
-+# upfront in an attempt to alias imports, not erroring here will
-+# just mean we get a regular import error whenever requests
-+# *actually* tries to import one of these modules to use it, which
-+# actually gives us a better error message than we would have
-+# otherwise gotten.
-+pass
-+else:
-+sys.modules[vendored_name] = sys.modules[modulename]
-+base, head = vendored_name.rsplit(".", 1)
-+setattr(sys.modules[base], head, sys.modules[modulename])
++# We can just silently allow import failures to pass here. If we
++# got to this point it means that ``import requests.packages.whatever``
++# failed and so did ``import whatever``. Since we're importing this
++# upfront in an attempt to alias imports, not erroring here will
++# just mean we get a regular import error whenever requests
++# *actually* tries to import one of these modules to use it, which
++# actually gives us a better error message than we would have
++# otherwise gotten.
++pass
++else:
++sys.modules[vendored_name] = sys.modules[modulename]
++base, head = vendored_name.rsplit(".", 1)
++setattr(sys.modules[base], head, sys.modules[modulename])
  
 -try:
 -from . import idna
@@ -67,6 +64,7 @@ index 4077265..b1206b2 100644
 +vendored('urllib3.contrib')
 +vendored('urllib3.contrib.ntlmpool')
 +vendored('urllib3.contrib.pyopenssl')
++vendored('urllib3.contrib.socks')
 +vendored('urllib3.exceptions')
 +vendored('urllib3.fields')
 +vendored('urllib3.filepost')

Bug#859262: Re: freezes Orca screen reader

[Niels Thykier]

On Sat, 01 Apr 2017 13:54:17 +0300 Mika Hanhijärvi wrote:
> Package: synaptic
> Version: 0.84.2
> Severity: grave
> 


Hi Mika,

Sorry to hear that synaptic is causing you issues.

I am CC'ing the accessibility list hoping that they might have an
insight to what is happening.  I have quoted the original mail in full
below for their sake.

Thanks,
~Niels

(PS: Please CC me on replies if you need my attention.  I am not the
maintainer of synaptic)

On Sat, 01 Apr 2017 13:54:17 +0300 Mika Hanhijärvi wrote:
> Synaptic often freezes the Orca screen reader so that Orca speaks nothing 
> until
> Synaptic is closed. The same happens on both of my laptops running Debian
> Stretch.
> 
> I am blind so I have to use computer using Orca screen reader. It happens wery
> often that when I e.g click the Reload button in Synaptic, or select Reload
> from the Synaptic menu, then Orca screen reader stops speaking. Synapticdoes
> not freeze the whole desktop, just Orca.  This problem seems to happen
> randomly, sometimes it happens sometimes it does not. When Synaptic has
> finished reloading the package database information Orca may start speaking
> again, but often it does not. If it does not then I have to close the Synaptic
> by pressing alt + F4 after which Orca starts to speak again.
> 
> It also happens sometimes that if I have reloaded repository package database
> information and click Mark all updades after that then Orca stops speaking. On
> my second laptop it currently happens almost every time that Orca stops
> speaking when I click the Mark all updates or select it from the menu. Tkhat
> also seems to happen randomly, sometimes it happens sometimes not.
> 
> I have not noticed any problems like that when I have used other applications,
> this happns only when I am using Synaptic.
> 
> As I said I have two laptops running Debian Stretch and both have the same
> problems. Both laptops have been upgraded from Jessie to Stretch. The first
> laptop was almost clean Jessie installation before it was upgraded to Stretch,
> it still has wery little apps installed.
> 
> I am using Gnome desktop. I am blind so it is difficult for me to try to 
> figure
> out what is wrong. I I have used both espeak and espeak-ng speech synthetisers
> with Orca screen reader, the same problem exists notmatter which of those is 
> in
> use.
> 
> [...]

Bug#820925: kio: Facebook web shortcut no longer works

[Maximiliano Curia]

¡Hola Salvo!

El 2016-10-25 a las 13:27 +0200, Maximiliano Curia escribió:
Control: tag -1 + upstream 
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=371657



¡Hola Salvo!



El 2016-04-13 a las 19:43 +0200, Salvo Tomaselli escribió:

The file /usr/share/kservices5/searchproviders/facebook.desktop
provides a web shortcut to search facebook.



However the query used seems to be out of date and no longer works.



It should be replaced with this line



https://www.facebook.com/search/top/?init=quick=\\{@}


I've forwarded this request upstream, the upstream bug report can be 
seen here: https://bugs.kde.org/show_bug.cgi?id=371657


Upstream replied to the issue on the 2016-10-26, but since I don't use facebook 
I can't really test this. So, it would make more sense if you could follow the 
issue upstream.


Happy hacking,
--
"If you optimize everything, you will always be unhappy."
-- Donald Knuth
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#801751: sftp: The host key for this server was not found, but another type of key exists

[Maximiliano Curia]

Control: tag -1 + upstream moreinfo
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=352709

¡Hola Salvo!

El 2015-10-14 a las 10:05 +0200, Salvo Tomaselli escribió:
Package: kio 
Version: 5.15.0-1 
Severity: normal 
Tags: upstream



See upstream bug:
https://bugs.kde.org/show_bug.cgi?id=352709



apparently libssh needs to be updated to 0.7.2


Sorry that it took so long to get back to you.

Thanks for reporting, libssh-4 0.7.3-1 was uploaded to Debian the 2016-06-09, 
so I guess this issue is fixed now. Does this version fixes the issue for you?


Happy hacking,
--
"Seek simplicity, and distrust it." -- Whitehead's Rule
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#859111: [Debian-med-packaging] Bug#859111: ariba: FTBFS: FAIL: Test run_bowtie2 unsorted

[Sascha Steinbiss]

forwarded 859111 https://github.com/sanger-pathogens/ariba/issues/170
tags 859111 upstream
thanks

Hi all,

> On Thu, Mar 30, 2017 at 06:20:16PM +0300, Adrian Bunk wrote:
>> Control: retitle -1 ariba FTBFS with bowtie2 2.3.1-1
> [...]
>> This is actually not related to the ariba version but to the bowtie2 version,
>> ariba 2.6.1+ds-1 in stretch builds with the stretch bowtie2 2.3.0-2 but 
>> FTBFS with the sid bowtie2 2.3.1-1
> 
> Do we already know whether the newer upstream version fixes this?

No, it doesn't. I just tested it. Given that the test failure seems to
be caused by differences between result and reference, and bowtie2 2.3.1
introduced different default values for one of the parameters [1], it
might be likely that it's connected to that. I have contacted upstream
[2] -- they are usually quite responsive.

Cheers
Sascha

[1] http://bowtie-bio.sourceforge.net/bowtie2/index.shtml
[2] https://github.com/sanger-pathogens/ariba/issues/170

Bug#858596:

[Salvo Tomaselli]

close 858596
thank you

Whatever it was that generated the issue, after removing the
.xsession-errrors file, I can no longer reproduce it. So I'm closing
this.

Bug#859493: libgsl2: move libgslcblas.so into a separate package

[James Cowgill]

Hi,

On 04/04/17 12:44, Dirk Eddelbuettel wrote:
> On 4 April 2017 at 11:54, James Cowgill wrote:
> | On 04/04/17 11:14, Dirk Eddelbuettel wrote:
> | > On 4 April 2017 at 10:45, James Cowgill wrote:
> | There are some lesser upsides going forward though:
> | - the package would become more policy compliant
> | - no need to ship libgslcblas.so to users who never use it
> 
> That's the thing: I don't think I have seen a use case of GSL that did _not_
> involve libgslcblas.  They are welded together at the hip (per gsl-config).
> 
> edd@max:~/git/rcppquantuccia(master)$ gsl-config --libs
> -L/usr/lib/x86_64-linux-gnu -lgsl -lgslcblas -lm
> edd@max:~/git/rcppquantuccia(master)$ 
> 
> One can/could override, nobody does AFAICT.

Ah sorry my script must have been wrong. I did another scan.

# Number of ELFs in packages depending on libgsl2
$ wc -l elfs
2315 elfs

# Number of ELFs linking against libgsl.so.19
$ for i in $(cat elfs); do readelf --dynamic $i | grep -q libgsl.so.19 && echo 
$i; done | wc -l
704

# Number of ELFs linking against libgslcblas.so.0
$ for i in $(cat elfs); do readelf --dynamic $i | grep -q libgslcblas.so.0 && 
echo $i; done | wc -l
681

I guess -Wl,as-needed accounts for most of the difference.

James



signature.asc
Description: OpenPGP digital signature

Bug#859100: webkit2gtk: webkit2gtk loads system-installed extensions by default

[Alberto Garcia]

On Thu, Mar 30, 2017 at 12:26:37PM +0200, Jérémy Lal wrote:

> It appears that when/if a java or flash plugin is installed from
> another debian package, webkit2gtk tries to load it, even when
> setting a custom, local, webextensions directory as documented in
> https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebContext.html#webkit-web-context-set-web-extensions-directory

Web Extensions != NPAPI plugins

Web Extensions are these:

   
https://blogs.igalia.com/carlosgc/2013/09/10/webkit2gtk-web-process-extensions/

NPAPI plugins are java, flash, etc.

Try to disable them with this setting:

   
https://webkitgtk.org/reference/webkit2gtk/unstable/WebKitSettings.html#webkit-settings-set-enable-plugins

Berto

Bug#859219: phpmyadmin: Fails to build from source, illegal character in input string

[Niels Thykier]

On Fri, 31 Mar 2017 21:06:00 +0200 Michal  wrote:
> Hi
> 
> Jeremy Bicha píše v Pá 31. 03. 2017 v 14:10 -0400:
> > Package: phpmyadmin
> > Version: 4:4.6.6-1
> > Severity: serious
> > 
> > phpmyadmin 4:4.6.6-1 and 4:4.6.6-2 fail to build from source in a
> > clean sid chroot (and in Ubuntu 17.04).
> > 
> > Build log excerpt
> > 
> > 
> > There was 1 error:
> > 
> > 1) PMA_Charset_Conversion_Test::testCharsetConversion
> > iconv(): Detected an illegal character in input string
> > 
> > /<>/libraries/charset_conversion.lib.php:111
> > /<>/test/libraries/PMA_charset_conversion_test.php:61
> 
> This is known problem, see #854821. Unfortunately the discussion there
> stopped month ago without any clear outcome.
> 
> And indeed I did forget about it when doing new upload. Still I think
> this should be fixed at glibc side.
> 
> -- 
>   Michal Čihař  | https://cihar.com/ | https://weblate.org/

Hi,

Would it be possible to use a short term work around by using a
different locale during the tests (e.g. en_US.UTF-8)? Then we can use
look at a better long term solution after stretch has been released.

Thanks,
~Niels

Bug#859502: shadowsocks-libev: typos in manpages

[Roger Shimizu]

Package: shadowsocks-libev
Version: 2.6.3+ds-1
Severity: important
Tags: patch upstream

Report and fix commit was from upstream BTS#1210:
 - https://github.com/shadowsocks/shadowsocks-libev/pull/1210
And commit of the fix:
 - https://github.com/shadowsocks/shadowsocks-libev/commit/a0d38b3
 (need to change a bit to backport to stretch version)

Under doc/, ss-local.asciidoci, ss-redir.asciidoc, and ss-server.asciidoc
the '>' is missing from a few options.

Bug#858190: unblock: manpages/4.10-1

[Dr. Tobias Quathamer]

Am 03.04.2017 um 17:56 schrieb Niels Thykier:

Control: tags -1 confirmed


unblock manpages/4.10-1

The package has not been uploaded to unstable, I'll wait for your
approval before doing so.

Regards,
Tobias


Ack, please go ahead.

Thanks,
~Niels


Hi Niels,

thanks a lot, the package has just been accepted into unstable.

Regards,
Tobias




signature.asc
Description: OpenPGP digital signature

Bug#857990: Please don't remove npm from Stretch

[Niels Thykier]

Jérémy Lal:
> 2017-04-03 16:45 GMT+02:00 Niels Thykier :
>> [...]
>>
>> @Jérémy Lal: Your call:
>>
>>  * Are you willing to support npm for 3-5 years in stretch given its
>>current state?
>>- If yes, then tag the npm bug stretch-ignore or downgrade it
>>- If no, then we will effectuate the removal before the release.
> 
> I agree completely with the above analysis, and I'm not willing to support
> the current npm version that is in testing.
> 
> To others, preoccupied that npm won't be available in debian:
> - please help with npm maintenance
> - hopefully we'll make an updated version installable through debian 
> backports,
> 
> Jérémy.
> 

Thanks for the reply.  Accordingly, I have tagged the following bugs:

 * is-blocker: #857994 (qtwebchannel-opensource-src)
 * will-remove: #857986, #857990, #857991

Note for ruby-license-finder + npm2deb: If the package can trivially
drop the npm dependency, it is welcome to stay in stretch.

@QT/KDE maintainers: A timely upload for #857994 would greatly be
appreciated, so we can finish up this soon.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Bug#858802: [Letsencrypt-devel] Bug#858802: AttributeError: 'module' object has no attribute 'DependencyError'

[Patrick Lam]

This is running on a DigitalOcean VPS:

plam@patricklam:~$ uname -a
Linux patricklam 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1
(2015-04-24) x86_64 GNU/Linux


plam@patricklam:~$ apt-cache policy $(apt-rdepends -p certbot 2>|
/dev/null|awk '/Depends/ {print $2}'|sort -u)|awk '/^[^ ]/ {
package=$0 } /  Installed/ { print package " " $2 }'
awk: (none)
base-files: 9.8
ca-certificates: 20161130
debconf: 1.5.60
debconf-2.0: (none)
dpkg: 1.18.23
gcc-6-base: 6.3.0-11
init-system-helpers: 1.47
install-info: 6.3.0.dfsg.1-1+b2
libacl1: 2.2.52-3+b1
libattr1: 1:2.4.47-2+b2
libbz2-1.0: 1.0.6-8.1
libc6: 2.24-9
libdb5.3: 5.3.28-12+b1
libexpat1: 2.2.0-2
libffi6: 3.2.1-6
libgcc1: 1:6.3.0-11
libgdbm3: 1.8.3-14
liblzma5: 5.2.2-1.2+b1
libncursesw5: 6.0+20161126-1
libpcre3: 2:8.39-3
libperl5.24: 5.24.1-2
libpython2.7-minimal: 2.7.13-2
libpython2.7-stdlib: 2.7.13-2
libpython-stdlib: 2.7.13-2
libreadline7: 7.0-2
libselinux1: 2.6-3+b1
libsqlite3-0: 3.16.2-3
libssl1.1: 1.1.0e-1
libtinfo5: 6.0+20161126-1
mime-support: 3.60
multiarch-support: 2.24-9
openssl: 1.1.0e-1
perl: 5.24.1-2
perl-base: 5.24.1-2
perl-modules-5.24: 5.24.1-2
python: 2.7.13-2
python2.7: 2.7.13-2
python2.7: 2.7.13-2
python2.7-minimal: 2.7.13-2
python-acme: 0.10.2-1
python: 2.7.13-2
python-certbot: 0.10.2-1
python-cffi-backend-api-max: (none)
python-cffi-backend-api-min: (none)
python-chardet: 2.3.0-2
python-configargparse: 0.11.0-1
python-configobj: 5.0.6-2
python-cryptography: 1.7.1-2
python-enum34: 1.1.6-1
python-funcsigs: 1.0.2-3
python-idna: 2.2-1
python-ipaddress: 1.0.17-1
python-minimal: 2.7.13-2
python-mock: 2.0.0-3
python-openssl: 16.2.0-1
python-parsedatetime: 2.1-3
python-pbr: 1.10.0-1
python-pkg-resources: 33.1.1-1
python-pyasn1: 0.1.9-2
python-requests: 2.12.4-1
python-rfc3339: 1.0-4
python-setuptools: 33.1.1-1
python-six: 1.10.0-3
python-tz: 2016.7-0.2
python-urllib3: 1.19.1-1
python-zope.component: 4.3.0-1
python-zope.event: 4.2.0-1
python-zope.hookable: 4.0.4-4+b2
python-zope.interface: 4.3.2-1
readline-common: 7.0-2
tar: 1.29b-1.1
tzdata: 2017a-1
zlib1g: 1:1.2.8.dfsg-5

On Tue, Apr 4, 2017 at 12:59 AM, Harlan Lieberman-Berg
 wrote:
> Patrick Lam  writes:
>> I get a similar error on an upgraded stretch box:
>
> That's perplexing.  I just ran an upgrade from jessie to stretch on a
> clean box, installed certbot -- works fine.  I can't replicate this at
> all.  What architecture are you running on?
>
>> The output of the command is empty.
>
> My guess is you're missing apt-rdepends.  Can you install it and rerun
> the command please?
>
> Thanks,
> --
> Harlan Lieberman-Berg
> ~hlieberman

Bug#859100: webkit2gtk: webkit2gtk loads system-installed extensions by default

[Jérémy Lal]

2017-04-04 14:16 GMT+02:00 Alberto Garcia :
> On Thu, Mar 30, 2017 at 12:26:37PM +0200, Jérémy Lal wrote:
>
>> It appears that when/if a java or flash plugin is installed from
>> another debian package, webkit2gtk tries to load it, even when
>> setting a custom, local, webextensions directory as documented in
>> https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebContext.html#webkit-web-context-set-web-extensions-directory
>
> Web Extensions != NPAPI plugins
>
> Web Extensions are these:
>
>
> https://blogs.igalia.com/carlosgc/2013/09/10/webkit2gtk-web-process-extensions/
>
> NPAPI plugins are java, flash, etc.

Indeed, nevertheless,

> Try to disable them with this setting:
>
>
> https://webkitgtk.org/reference/webkit2gtk/unstable/WebKitSettings.html#webkit-settings-set-enable-plugins

i'm already doing that

```
WebKitSettings* settings = webkit_web_view_get_settings(view);
g_object_set(settings,
  "enable-plugins", FALSE,
  "enable-java", FALSE,
  NULL
);
webkit_web_view_load_uri(view, uri);
```
(see also 
https://github.com/kapouer/node-webkitgtk/blob/6586b60/src/webview.cc#L614)

Jérémy

Bug#859501: unblock: netcdf/1:4.4.1.1-2

[Bas Couwenberg]

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

Please unblock package netcdf

It fixes #859430 by enabling the PIE hardening buildflags.

unblock netcdf/1:4.4.1.1-2

Kind Regards,

Bas
diff -Nru netcdf-4.4.1.1/debian/changelog netcdf-4.4.1.1/debian/changelog
--- netcdf-4.4.1.1/debian/changelog 2016-11-22 07:24:16.0 +0100
+++ netcdf-4.4.1.1/debian/changelog 2017-04-04 08:09:19.0 +0200
@@ -1,3 +1,11 @@
+netcdf (1:4.4.1.1-2) unstable; urgency=medium
+
+  * Enable PIE hardening buildflags.
+(closes: #859430)
+  * Drop unused lintian overrides for hardening-no-pie.
+
+ -- Bas Couwenberg   Tue, 04 Apr 2017 08:09:19 +0200
+
 netcdf (1:4.4.1.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru netcdf-4.4.1.1/debian/netcdf-bin.lintian-overrides 
netcdf-4.4.1.1/debian/netcdf-bin.lintian-overrides
--- netcdf-4.4.1.1/debian/netcdf-bin.lintian-overrides  2016-08-28 
15:45:53.0 +0200
+++ netcdf-4.4.1.1/debian/netcdf-bin.lintian-overrides  1970-01-01 
01:00:00.0 +0100
@@ -1,2 +0,0 @@
-# PIE breaks the build
-netcdf-bin: hardening-no-pie *
diff -Nru netcdf-4.4.1.1/debian/rules netcdf-4.4.1.1/debian/rules
--- netcdf-4.4.1.1/debian/rules 2016-08-28 15:45:53.0 +0200
+++ netcdf-4.4.1.1/debian/rules 2017-04-04 08:08:33.0 +0200
@@ -2,9 +2,8 @@
 
 #export DH_VERBOSE=1
 
-# Enable hardening build flags, except:
-#  pie: causes build failure
-export DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
+# Enable hardening build flags
+export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 

Bug#806213: kinit: starting up iceweasel with multiple windows/tabs sometimes causes lock-up

[Maximiliano Curia]

Control: tag -1 + unreproducible

¡Hola Arthur!

El 2016-01-14 a las 14:27 +1030, Arthur Marsh escribió:
Package: kinit 
Version: 5.16.0-1 
Followup-For: Bug #806213


I tried starting iceweasel avoiding kinit using krunner (alt F2 from 
plasma desktop) and had no problems, therefore the issues appears to lie 
with package kinit.


Sorry that it took so long to get back to you.

I'm currently unable to reproduce this issue (using firefox instead of 
iceweasel), and I guess that the issue has solved itself since it was last 
reported. Is this issue still reproducible for you? If so, can you provide a 
list of sites that are started by you firefox that cause this issue?


Is the issue still reproducible with new user?

Happy hacking,
--
"Anytime you have a fifty-fifty chance of getting something right, there's a
90 percent probability you'll get it wrong."
-- The 50-50-90 rule
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#859500: curl: CVE-2017-7407

[Salvatore Bonaccorso]

Source: curl
Version: 7.38.0-4
Severity: important
Tags: security patch upstream fixed-upstream

Hi,

the following vulnerability was published for curl.

CVE-2017-7407[0]:
| The ourWriteOut function in tool_writeout.c in curl 7.53.1 might allow
| physically proximate attackers to obtain sensitive information from
| process memory in opportunistic circumstances by reading a workstation
| screen during use of a --write-out argument ending in a '%' character,
| which leads to a heap-based buffer over-read.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-7407
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7407

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#859499: shadowsocks-libev: ss-local doesn't do DNS resolving for acl bypassed domains

[Roger Shimizu]

Package: shadowsocks-libev
Version: 2.6.3+ds-1
Severity: important
Tags: patch upstream

Report was from upstream BTS#1148:
 - https://github.com/shadowsocks/shadowsocks-libev/issues/1148
And commit of the fix:
 - https://github.com/shadowsocks/shadowsocks-libev/commit/9c7add7


I'm using the latest version (2.6.3) of ss-local on macOS, the ACL doesn't work 
properly.
It only works when I open urls in proxy_list.

$ wget 
https://github.com/shadowsocks/shadowsocks-libev/raw/master/acl/gfwlist.acl -P 
/tmp/

$ ss-local  -s x.x.x.x \
   -p 8388 \
   -b 127.0.0.1   \
   -l 1080   \
   -k password  \
   -m rc4-md5  \
   --acl /tmp/gfwlist.acl

# it works
$ curl -x socks5h://127.0.0.1:1080 https://www.google.com/
...

# it doesn't work
$ curl -x socks5h://127.0.0.1:1080 https://www.baidu.com/
curl: (35) Server aborted the SSL handshake

Bug#844566: qemu-system-x86: ipv6 and dns is broken with netdev user

[Samuel Thibault]

Control: tags -1 + patch upstream

Hello,

This is most probably the same issue as reported on qemu-devel:
http://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg05070.html

which is solved by the attached patch already commited upstream for the
2.9 release.

I'll probably be good to request an unblock from the release team,
because otherwise this bug will be a real pain for the whole Stretch
period.

Samuel
commit e42f869b5118fa9ac64dcea624276204567fc581
Author: Samuel Thibault 
Date:   Sun Mar 26 20:28:11 2017 +0200

slirp: Make RA build more flexible

Do not hardcode the RA size at all, use a pl_size variable which
accounts the accumulated size, and fill rip->ip_pl at the end.

This will allow to make some blocks optional.

Signed-off-by: Samuel Thibault 
Reviewed-by: Philippe Mathieu-Daudé 

diff --git a/slirp/ip6_icmp.c b/slirp/ip6_icmp.c
index 298a48dd25..d0f5cc1456 100644
--- a/slirp/ip6_icmp.c
+++ b/slirp/ip6_icmp.c
@@ -143,17 +143,10 @@ void ndp_send_ra(Slirp *slirp)
 /* Build IPv6 packet */
 struct mbuf *t = m_get(slirp);
 struct ip6 *rip = mtod(t, struct ip6 *);
+size_t pl_size = 0;
 rip->ip_src = (struct in6_addr)LINKLOCAL_ADDR;
 rip->ip_dst = (struct in6_addr)ALLNODES_MULTICAST;
 rip->ip_nh = IPPROTO_ICMPV6;
-rip->ip_pl = htons(ICMP6_NDP_RA_MINLEN
-+ NDPOPT_LINKLAYER_LEN
-+ NDPOPT_PREFIXINFO_LEN
-#ifndef _WIN32
-+ NDPOPT_RDNSS_LEN
-#endif
-);
-t->m_len = sizeof(struct ip6) + ntohs(rip->ip_pl);
 
 /* Build ICMPv6 packet */
 t->m_data += sizeof(struct ip6);
@@ -171,6 +164,7 @@ void ndp_send_ra(Slirp *slirp)
 ricmp->icmp6_nra.reach_time = htonl(NDP_AdvReachableTime);
 ricmp->icmp6_nra.retrans_time = htonl(NDP_AdvRetransTime);
 t->m_data += ICMP6_NDP_RA_MINLEN;
+pl_size += ICMP6_NDP_RA_MINLEN;
 
 /* Source link-layer address (NDP option) */
 struct ndpopt *opt = mtod(t, struct ndpopt *);
@@ -178,6 +172,7 @@ void ndp_send_ra(Slirp *slirp)
 opt->ndpopt_len = NDPOPT_LINKLAYER_LEN / 8;
 in6_compute_ethaddr(rip->ip_src, opt->ndpopt_linklayer);
 t->m_data += NDPOPT_LINKLAYER_LEN;
+pl_size += NDPOPT_LINKLAYER_LEN;
 
 /* Prefix information (NDP option) */
 struct ndpopt *opt2 = mtod(t, struct ndpopt *);
@@ -192,6 +187,7 @@ void ndp_send_ra(Slirp *slirp)
 opt2->ndpopt_prefixinfo.reserved2 = 0;
 opt2->ndpopt_prefixinfo.prefix = slirp->vprefix_addr6;
 t->m_data += NDPOPT_PREFIXINFO_LEN;
+pl_size += NDPOPT_PREFIXINFO_LEN;
 
 #ifndef _WIN32
 /* Prefix information (NDP option) */
@@ -203,16 +199,14 @@ void ndp_send_ra(Slirp *slirp)
 opt3->ndpopt_rdnss.lifetime = htonl(2 * NDP_MaxRtrAdvInterval);
 opt3->ndpopt_rdnss.addr = slirp->vnameserver_addr6;
 t->m_data += NDPOPT_RDNSS_LEN;
+pl_size += NDPOPT_RDNSS_LEN;
 #endif
 
+rip->ip_pl = htons(pl_size);
+t->m_data -= sizeof(struct ip6) + pl_size;
+t->m_len = sizeof(struct ip6) + pl_size;
+
 /* ICMPv6 Checksum */
-#ifndef _WIN32
-t->m_data -= NDPOPT_RDNSS_LEN;
-#endif
-t->m_data -= NDPOPT_PREFIXINFO_LEN;
-t->m_data -= NDPOPT_LINKLAYER_LEN;
-t->m_data -= ICMP6_NDP_RA_MINLEN;
-t->m_data -= sizeof(struct ip6);
 ricmp->icmp6_cksum = ip6_cksum(t);
 
 ip6_output(NULL, t, 0);
commit a2f80fdfc683019901cdf4c0863a5920c0ca7245
Author: Samuel Thibault 
Date:   Sun Mar 26 20:46:34 2017 +0200

slirp: Send RDNSS in RA only if host has an IPv6 DNS server

Previously we would always send an RDNSS option in the RA, making the guest
try to resolve DNS through IPv6, even if the host does not actually have
and IPv6 DNS server available.

This makes the RDNSS option enabled only when an IPv6 DNS server is
available.

Signed-off-by: Samuel Thibault 
Reviewed-by: Philippe Mathieu-Daudé 

diff --git a/slirp/ip6_icmp.c b/slirp/ip6_icmp.c
index d0f5cc1456..777eb574be 100644
--- a/slirp/ip6_icmp.c
+++ b/slirp/ip6_icmp.c
@@ -144,6 +144,9 @@ void ndp_send_ra(Slirp *slirp)
 struct mbuf *t = m_get(slirp);
 struct ip6 *rip = mtod(t, struct ip6 *);
 size_t pl_size = 0;
+struct in6_addr addr;
+uint32_t scope_id;
+
 rip->ip_src = (struct in6_addr)LINKLOCAL_ADDR;
 rip->ip_dst = (struct in6_addr)ALLNODES_MULTICAST;
 rip->ip_nh = IPPROTO_ICMPV6;
@@ -189,18 +192,18 @@ void ndp_send_ra(Slirp *slirp)
 t->m_data += NDPOPT_PREFIXINFO_LEN;
 pl_size += NDPOPT_PREFIXINFO_LEN;
 
-#ifndef _WIN32
 /* Prefix information (NDP option) */
-/* disabled for windows for now, until get_dns6_addr is implemented */
-struct ndpopt *opt3 = mtod(t, struct ndpopt *);
-opt3->ndpopt_type = NDPOPT_RDNSS;
-opt3->ndpopt_len = NDPOPT_RDNSS_LEN / 8;
-opt3->ndpopt_rdnss.reserved 

Bug#859498: atom4: no package files present

[Andrew J. Buehler]

Package: atom4
Version: 4.1-6+b5
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Within the past few days, I have installed atom4 from Debian testing,
using 'apt-get install atom4'.

After having done so, I get the following:

$ dpkg -c /var/cache/apt/archives/atom4_4.1-6+b5_amd64.deb
drwxr-xr-x root/root 0 2013-07-31 12:20 ./
drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/
drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/games/
drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/
drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/doc/
drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/doc/atom4/
-rw-r--r-- root/root  3093 2003-03-13 09:03
./usr/share/doc/atom4/README.gz
-rw-r--r-- root/root   216 2013-07-31 12:20
./usr/share/doc/atom4/changelog.Debian.amd64.gz
-rw-r--r-- root/root  1967 2013-07-31 12:20
./usr/share/doc/atom4/changelog.Debian.gz
-rw-r--r-- root/root   388 2013-07-31 12:20
./usr/share/doc/atom4/copyright
drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/games/
drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/games/atom4/
drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/man/
drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/man/man6/
drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/menu/
-rw-r--r-- root/root   244 2013-07-31 12:20 ./usr/share/menu/atom4

$ dlocate atom4
atom4: /.
atom4: /usr
atom4: /usr/games
atom4: /usr/share
atom4: /usr/share/doc
atom4: /usr/share/doc/atom4
atom4: /usr/share/doc/atom4/README.gz
atom4: /usr/share/doc/atom4/changelog.Debian.amd64.gz
atom4: /usr/share/doc/atom4/changelog.Debian.gz
atom4: /usr/share/doc/atom4/copyright
atom4: /usr/share/games
atom4: /usr/share/games/atom4
atom4: /usr/share/man
atom4: /usr/share/man/man6
atom4: /usr/share/menu
atom4: /usr/share/menu/atom4

By comparison, I also get:

$ apt-file search atom4
atom4: /usr/games/atom4
atom4: /usr/share/doc/atom4/README.gz
atom4: /usr/share/doc/atom4/changelog.Debian.amd64.gz
atom4: /usr/share/doc/atom4/changelog.Debian.gz
atom4: /usr/share/doc/atom4/copyright
atom4: /usr/share/games/atom4/blackball12.xpm
atom4: /usr/share/games/atom4/blueball12.xpm
atom4: /usr/share/games/atom4/greenball12.xpm
atom4: /usr/share/games/atom4/purpleball12.xpm
atom4: /usr/share/games/atom4/redball12.xpm
atom4: /usr/share/games/atom4/tritile12.xpm
atom4: /usr/share/games/atom4/turqball12.xpm
atom4: /usr/share/games/atom4/wheel12-1.xpm
atom4: /usr/share/games/atom4/wheel12-2.xpm
atom4: /usr/share/games/atom4/wheel12-3.xpm
atom4: /usr/share/games/atom4/wheel12-4.xpm
atom4: /usr/share/games/atom4/wheel12-5.xpm
atom4: /usr/share/games/atom4/wheel12-6.xpm
atom4: /usr/share/games/atom4/whiteball12.xpm
atom4: /usr/share/games/atom4/yellowball12.xpm
atom4: /usr/share/man/man6/atom4.6.gz
atom4: /usr/share/menu/atom4
games-thumbnails: /usr/share/games/thumbnails/atom4.png
lammps-doc: /usr/share/doc/lammps-doc/Eqs/compute_sna_atom4.jpg

but that is a listing of files known to (a local record of the contents
of) the archive as being in this package, not files actually installed
on my system.

Reinstalling the package from the same .deb file changes nothing.

As far as I can tell, this package does not actually install any files
outside of /usr/share/doc/, except for the menu file.

I am reporting this as grave, because I see nothing to indicate that
this would not happen the same way on any and every computer, and if
that is the case this package is completely unusable.

Please A: figure out why these files are missing from the currently
installable package and correct that, B: determine that they are not
missing from the .deb in the repositories and help me figure out why
they are missing on my own machine, or C: have this package removed from
the archive, or at least from testing for the release. (The last,
obviously, is the least preferable option.)


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

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

-- debconf-show failed

Bug#859451: dbus: error messages on boot for systems with NSS LDAP

[Laurent Bonnaud]

On 04/04/2017 13:29, Simon McVittie wrote:

> Sorry, I meant /etc/dbus-1/system.d/*.conf 

No problem!  This system has only standard unmodified stuff:

# ls -l /etc/dbus-1/system.d/
total 48
-rw-r--r-- 1 root root   947 May 26  2015 org.freedesktop.hostname1.conf
-rw-r--r-- 1 root root   937 May 26  2015 org.freedesktop.locale1.conf
-rw-r--r-- 1 root root 12499 Jul 28  2016 org.freedesktop.login1.conf
-rw-r--r-- 1 root root  1604 Jul 28  2016 org.freedesktop.network1.conf
-rw-r--r-- 1 root root   953 Jul 28  2016 org.freedesktop.resolve1.conf
-rw-r--r-- 1 root root 11898 Mar  2 09:21 org.freedesktop.systemd1.conf
-rw-r--r-- 1 root root   947 May 26  2015 org.freedesktop.timedate1.conf

> For completeness, several other paths could potentially
> mention users and groups, including /etc/dbus-1/system-local.conf
> and /usr/share/dbus-1/system.d/*.conf.

Those do not exist on this system.

> The bus configuration often also references group names and identities -
> are those all local? (I suspect not.)

In fact dbus is only installed as a dependency for libpam-systemd and I did not 
touch anything.

> Alternatively, your NSS configuration might be such that the NSS-backed
> library calls that dbus-daemon uses during configuration loading (mainly
> getpwuid_r() and getgrnam_r() I think) hit the network even if the
> group is configured locally.

In /etc/nsswitch.conf LDAP is configured as follows:

passwd: files ldap
group:  files ldap

and I use the following packages:

ii  libnss-ldapd:amd64 0.9.7-2amd64 
   NSS module for using LDAP as a naming service
ii  libpam-ldapd:amd64 0.9.7-2amd64 
   PAM module for using LDAP as an authentication service

> I'd rather not: this is very much an "at own risk, if you are absolutely
> sure you know what you are doing" option that can easily cause circular
> dependencies. (Much like getting your user and group information from
> the network, in fact...)

The suggestion in README.Debian could be preceded with a big warning such as: 

  "Warning, the following only applies to systems that use 
/etc/network/interfaces for network configuration and not daemons that use dbus 
such as NetworkManager, ConnMan, wicd, ..."

-- 
Laurent.

Bug#804191: kinit: turning off monitor causes the kdeinit process to crash

[Maximiliano Curia]

Control: tag -1 + help

¡Hola Stephen!

El 2015-11-05 a las 16:54 -0600, Stephen Crowley escribió:
Package: kinit 
Version: 5.15.0-1 
Severity: important


I have a display attached to the DP port. When i turn off the power to the 
external screen, kde tries to switch everything over to the primary display 
built into the laptop and it causes the kdeinit process to crash, and the 
system becomes unusable (window borders stop rendering, panel unresponsive etc)


Sorry that it took so long to get back to you.

I can't reproduce the issue as reported, I'm inclined to think that the issue 
was solved in the meantime, but, since I don't have a DP monitor to test this 
with I'm requesting help to test this issue.


Is this issue reproducible/still reproducible by you?

Happy hacking,
--
"If a million people believe a foolish thing, it is still a foolish thing."
-- France's Rule of Folly
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#586135: Misterhouse v4.2 released

[Robert J. Clay]

MisterHouse v4.2 was released last month and all further work that I
will be doing for

the Debian package will be based on that version.

Changelog: https://github.com/hollie/misterhouse/wiki/Changelog

Debian packaging branch:  https://github.com/rocasa/misterhouse/commits/debian

Robert James Clay

rjclay@gmail.comj...@rocasa.us

Bug#859493: libgsl2: move libgslcblas.so into a separate package

[Dirk Eddelbuettel]

On 4 April 2017 at 11:54, James Cowgill wrote:
| Hi,
| 
| On 04/04/17 11:14, Dirk Eddelbuettel wrote:
| > On 4 April 2017 at 10:45, James Cowgill wrote:
| > | Package: libgsl2
| > | Version: 2.3+dfsg-1
| > | Severity: normal
| > | 
| > | Hi,
| > | 
| > | As a followup from the thread on debian-backports[1], please can you
| > | move libgslcblas.so from libgsl2 into a separate package. This will
| > | allow clean upgrades without conflicts when the SONAME of gsl is changed
| > | and would have avoided the current backports uninstallability situation.
| > | See policy 8.1 for more info about this.
| > | 
| > | This may result in a transition if there are any packages in the archive
| > | which use libgslcblas.so, because they will need their dependencies
| > | updating.
| > 
| > I have maintained GSL for 18 years.  The soname changed once.  Besides,
| > upstream is now largely stable, releases happen way fewer than before.
| > 
| > To be this is an issue in search of a problem, as opposed to an actual
| > problem.  I don't really agree with the assessment and would rather not do
| > this.
| 
| I will admit that since this any fix is unlikely to be allowed into
| stretch, the major damage has already been done.
| 
| There are some lesser upsides going forward though:
| - the package would become more policy compliant
| - no need to ship libgslcblas.so to users who never use it

That's the thing: I don't think I have seen a use case of GSL that did _not_
involve libgslcblas.  They are welded together at the hip (per gsl-config).

edd@max:~/git/rcppquantuccia(master)$ gsl-config --libs
-L/usr/lib/x86_64-linux-gnu -lgsl -lgslcblas -lm
edd@max:~/git/rcppquantuccia(master)$ 

One can/could override, nobody does AFAICT.

Dirk

| - avoid accidentally breaking the package again in the unlikely event
|   the SONAME is bumped again
| 
| The downside of a package transition may never materialize since I
| cannot find any packages which actually link to libgslcblas.so (in a
| very quick search). I guess there might be an "external packages"
| downside if non-Debian packages use libgslcblas.so.
| 
| So I do think there are good reasons to do this for buster. Downgrade
| the bug to wishlist if you want.
| 
| James
| 
| x[DELETED ATTACHMENT signature.asc, application/pgp-signature]

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

Bug#852059: [Pkg-dns-devel] Bug#852059: opendnssec-signer: installation hangs on invoke-rc.d due to script name being to long

[Michael Biebl]

On Mon, 3 Apr 2017 14:37:27 +0200 Michael Biebl  wrote:
> Am 03.04.2017 um 13:32 schrieb Michael Biebl:

> > In jessie, your opendnssec-signer SysV init script didn't use
> > init-d-script, which would explain the regression in stretch.
> 
> After rebooting the test VM using sysvinit, the system get's stuck
> during boot. This confirms that it's not an issue in invoke-rc.d (as
> /etc/init.d/rc start the init scripts directly without using
> invoke-rc.d) but makes this issue even more severe, as it renders the
> system unbootable.

Hm, wait a second. After looking at the SysV init script, it's rather
obvious what's broken:

https://anonscm.debian.org/git/pkg-dns/opendnssec.git/tree/debian/opendnssec-signer.init#n27

This while loop never finishes as you don't actually read from the file.
There's a missing
done < "$TMPFILES"

After you fix that, the service will no longer hang but you'll get those
error messages:

chown: invalid group: 'opendnssec:opendnssec - -'

Starting OpenDNSSEC Signer: opendnsec-signerstart-stop-daemon: warning:
this system is not able to track process names
longer than 15 characters, please use --exec instead of --name.
start-stop-daemon: warning: this system is not able to track process names
longer than 15 characters, please use --exec instead of --name.
OpenDNSSEC signer engine version 2.0.4
 failed!


I fear the SysV init scripts for opendnssec-{signer,enforcer} are in a
pretty much borked state atm.
The do_tmpfiles() routine is broken in several ways.

The start/stop routine using --name is broken as well, as you use
NAME=opendnssec-signer
but that isn't the actual name of the binary that is spawned.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#586135: Fwd: [mh] Announcement: 4.2 Released!

[Robert J. Clay]

-- Forwarded message --
From: H Plato 
Date: Wed, Mar 15, 2017 at 8:36 PM
Subject: [mh] Announcement: 4.2 Released!
To: The main list for the MisterHouse home autom <
misterhouse-us...@lists.sourceforge.net>


It's been a little over a year, and there's been a surprising amount of
updates, enhancements, and new features added to MH! Looking at the pull
requests, I figure about 107 commits were included in this release.

Release Highlights (from what I gathered from the commits)

   - Integration with 2 major voice control systems, Alexa & Siri
   - "Continuous Integration" when submitting pull requests to catch errors
   quickly
   - IA7 v1.3 Changes
  - Scheduler – click developer mode. Add a cron-like trigger right on
  the IA7 Model. See Schedule.PM for more advanced usage.
  - Push Notifications and browser audio
  - Object Logger - see the entire history of device changes.
  - Updated floorplan -- developer mode allows interactive placement.
  Still some placement issues however
  - Support for RRDTool 1.5.1+
  - Authentication - colored gear, and a dynamic log in/out button
  - IA7ized a bunch of IA5 stuff. Triggers, comics, email,
  - Purple button for unknown state (ia7_config state_colors allows for
  color overrides)
  - Support for $config_parms in the collections.json
  - Logging issues or errors to the print log when parsing
  collections.json
  - View the ia7_config and rrd_config on the about mr.house page.
   - New Modules added
  - Doorbird
  - mysensors
  - evapotranspiration
  - scheduler
  - Ecobee3
  - Pushsafer
  - DSC
  - Insteon ezio8sa
  - WGL rain8Net
   - Updated Modules
  - Razberry
  - Venstar Colortouch
  - PLCBus
  - Philips Hue
  - Clipsal CBus
  - Pushover
  - Harmon
  - OmniStat
  - Davis AdvantageProII
  - UPB
  - Wink
   - ...and various system enhancements / bugfixes


For more details, I've updated the Changelog/Release Notes which can be
read here 

Thanks again to Lieven for his excellent documentation of the release
process!



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

To unsubscribe from this list, go to: https://lists.sourceforge.net/
lists/listinfo/misterhouse-users





-- 
Robert J. Clay
rjc...@gmail.com

Bug#859497: ITP: libqtaccountsservice -- Qt-style API for AccountsService DBus interface

[Jan Luca Naumann]

Package: wnpp
Severity: wishlist
Owner: Jan Luca Naumann 

* Package name: libqtaccountsservice
  Version : 0.7.0
  Upstream Author : Pier Luigi Fiorini 
* URL : https://github.com/lirios/qtaccountsservice
* License : LGPL
  Programming Lang: C++
  Description : Qt-style API for AccountsService DBus interface

This library provides a Qt-style API to use freedesktop.org's AccountsService
DBus service. For more information see description of AccountsService under
http://www.freedesktop.org/wiki/Software/AccountsService

Bug#859410: libwebkit2gtk-4.0-37: Memory pressure relief renders system unusable

[Alberto Garcia]

Control: tags 859410 moreinfo

On Mon, Apr 03, 2017 at 08:16:59PM +0200, Alessio wrote:

> >> Please, seriously consider to cherrypick the solution.
> >>
> >> https://bugs.webkit.org/show_bug.cgi?id=164052
> >
> > ...but this was already cherry-picked in 2.14.3:
> 
> Didn't noticed it... Quite strange, though, because I suffered the
> very same problem past week. Could we keep this bug open for a
> while, so to verify if I can reproduce it?

Ok, please come back when you have more information.

Berto

Bug#859451: dbus: error messages on boot for systems with NSS LDAP

[Simon McVittie]

On Tue, 04 Apr 2017 at 12:36:35 +0200, Laurent Bonnaud wrote:
> On 03/04/2017 20:21, Simon McVittie wrote:
> 
> > Yes: if any user or group mentioned in /etc/dbus/system.d/
> > comes from LDAP, then it needs to know who they are.
> 
> This directory does not exist on this system.

Sorry, I meant /etc/dbus-1/system.d/*.conf (my earlier mail was missing
the -1). For completeness, several other paths could potentially
mention users and groups, including /etc/dbus-1/system-local.conf
and /usr/share/dbus-1/system.d/*.conf.

> > and doubly so if system users are in LDAP.
> 
> System users are all local in /etc/passwd.

That's good - it's very easy to get circular dependencies otherwise.
The bus configuration often also references group names and identities -
are those all local? (I suspect not.)

Alternatively, your NSS configuration might be such that the NSS-backed
library calls that dbus-daemon uses during configuration loading (mainly
getpwuid_r() and getgrnam_r() I think) hit the network even if the
group is configured locally.

> >>  - would it be possible to order the dbus start after network is available?
> > In general no, because some ways to get on the network require D-Bus
> > (NetworkManager, ConnMan, wicd), so you would have a circular
> > dependency.
> 
> This system is minimal and uses plain old /etc/network/interfaces

Right, so this works *for you*, but it cannot be applied in general.

> > # /etc/systemd/system/dbus.service.d/local.conf
> > [Unit]
> > Wants=network-online.target
> > After=network-online.target
> 
> How about suggesting this solution in /usr/share/doc/dbus/README.Debian?

I'd rather not: this is very much an "at own risk, if you are absolutely
sure you know what you are doing" option that can easily cause circular
dependencies. (Much like getting your user and group information from
the network, in fact...)

S

Bug#824348: missing dependencies

[Jonathan Dowland]

planet-venus definitely does not depend on python-django by default. Perhaps
the Debian theme does? But not the fancy_classic one.


signature.asc
Description: Digital signature

Bug#859458: console-setup: Setup font on initrd

[Anton Zinoviev]

rename 859458 Because of displays with very high dpi, not only the keyboard, 
but the font has to be configured early
thanks

Console packages have always configured the keyboard as early as 
possible in order to facilitate interaction during bad fsck.  They have 
never tried (at least in Debian) to configure the font.  But your 
argument is valid so I am renaming this bug accordingly.

On Mon, Apr 03, 2017 at 09:12:21PM +0200, Jörg Sommer wrote:
> 
> Can you add files like these to the package, please?

I am considering this issue closed because there are already files like 
these in the package. :)  See the option

setupcon --setup-dir

which is supposed to be used by initrd builders.  At the moment Dracut 
uses this option, I don't know if there are other initrd builders in 
Debian which use it.

But even with Dracut, the font will not be configured by initrd because 
console-setup does not try to do this.  Which is unfortunate because 
earlier versions of console-setup included font configuration in initrd.

Anton Zinoviev

Bug#859496: /usr/bin/debsnap: debsnap cannot download binary packages

[Alberto Garcia]

Package: devscripts
Version: 2.17.5
Severity: important
File: /usr/bin/debsnap

I'm trying to download a binary package with debsnap but it fails all
the time.

$ debsnap -a amd64 xterm

debsnap: fatal error at line 271:
Unable to retrieve information for xterm from 
http://snapshot.debian.org/mr/binary/xterm/.

$ debsnap -v -a amd64 xterm 256-1
Getting json http://snapshot.debian.org/mr/binary/xterm/
debsnap: fatal error at line 271:
Unable to retrieve information for xterm from 
http://snapshot.debian.org/mr/binary/xterm/.

Those URLs however seem to return correct JSON files.

Berto

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev 1.18.23
ii  libc62.24-9
ii  perl 5.24.1-2
pn  python3:any  

Versions of packages devscripts recommends:
ii  apt 1.4~rc2
ii  at  3.1.20-3
ii  curl7.52.1-3
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2017.01.20
ii  dput0.12.0
ii  equivs  2.0.9+nmu1
ii  fakeroot1.21-3.1
ii  file1:5.29-3
ii  gnupg   2.1.18-6
ii  libdistro-info-perl 0.14
ii  libdpkg-perl1.18.23
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.20-1
ii  liburi-perl 1.71-1
ii  libwww-perl 6.15-1
ii  licensecheck3.0.29-1
ii  lintian 2.5.50.1
ii  man-db  2.7.6.1-2
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-debian  0.1.30
ii  python3-magic   1:5.29-3
ii  sensible-utils  0.0.9
ii  strace  4.15-2
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.18-5
ii  xz-utils5.2.2-1.2+b1

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-3
ii  build-essential  12.3
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  5.0.5+dfsg1-5
ii  gpgv 2.1.18-6
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
pn  mozilla-devscripts   
ii  mutt 1.7.2-1
ii  openssh-client [ssh-client]  1:7.4p1-9
pn  piuparts 
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
ii  w3m  0.5.3-34

-- no debconf information

Bug#859495: /usr/share/man/man1/display-im6.q16.1.gz: manpage says to install wrong package for HTML docs

[G. Branden Robinson]

Package: imagemagick-6.q16
Version: 8:6.9.7.4+dfsg-2
Severity: normal
File: /usr/share/man/man1/display-im6.q16.1.gz

"man display" says:

   For more information about the display command, point your  browser  to
   file:///usr/share/doc/imagemagick-6-common/html/www/display.html(on
   debian  system  you  may  install   the   imagemagick-6   package)   or
   http://www.imagemagick.org/script/display.php.

But that's wrong.

$ dpkg -S /usr/share/doc/imagemagick-6-common/html/www/display.html
imagemagick-6-doc: /usr/share/doc/imagemagick-6-common/html/www/display.html

The same problem seems to exist for all the manpages, probably due to 
templating:

$ man animate compare composite conjure convert display identify \
 import mogrify montage stream

-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
compare:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
convert:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
composite:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
conjure:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
display:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
identify:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
import:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
mogrify:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
montage:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
stream:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, 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 imagemagick-6.q16 depends on:
ii  hicolor-icon-theme 0.15-1
ii  libc6  2.24-9
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-2
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-2

Versions of packages imagemagick-6.q16 recommends:
ii  ghostscript  9.20~dfsg-3
ii  libmagickcore-6.q16-3-extra  8:6.9.7.4+dfsg-2
ii  netpbm   2:10.0-15.3+b2

Versions of packages imagemagick-6.q16 suggests:
pn  autotrace
ii  cups-bsd [lpr]   2.2.1-8
ii  curl 7.52.1-3
pn  enscript 
pn  ffmpeg   
ii  fig2dev [transfig]   1:3.2.6a-2
ii  gimp 2.8.18-1
pn  gnuplot  
pn  grads
pn  graphviz 
ii  groff-base   1.22.3-9
pn  hp2xx
pn  html2ps  
ii  imagemagick-6-doc [imagemagick-doc]  8:6.9.7.4+dfsg-2
ii  libwmf-bin   0.2.8.4-10.6
pn  mplayer  
pn  povray   
pn  radiance 
ii  sane-utils   1.0.25-3
ii  texlive-binaries [texlive-base-bin]  2016.20160513.41080.dfsg-2
ii  transfig 1:3.2.6a-2
pn  ufraw-batch  
ii  xdg-utils1.1.1-1

-- no debconf information

Bug#859493: libgsl2: move libgslcblas.so into a separate package

[James Cowgill]

Hi,

On 04/04/17 11:14, Dirk Eddelbuettel wrote:
> On 4 April 2017 at 10:45, James Cowgill wrote:
> | Package: libgsl2
> | Version: 2.3+dfsg-1
> | Severity: normal
> | 
> | Hi,
> | 
> | As a followup from the thread on debian-backports[1], please can you
> | move libgslcblas.so from libgsl2 into a separate package. This will
> | allow clean upgrades without conflicts when the SONAME of gsl is changed
> | and would have avoided the current backports uninstallability situation.
> | See policy 8.1 for more info about this.
> | 
> | This may result in a transition if there are any packages in the archive
> | which use libgslcblas.so, because they will need their dependencies
> | updating.
> 
> I have maintained GSL for 18 years.  The soname changed once.  Besides,
> upstream is now largely stable, releases happen way fewer than before.
> 
> To be this is an issue in search of a problem, as opposed to an actual
> problem.  I don't really agree with the assessment and would rather not do
> this.

I will admit that since this any fix is unlikely to be allowed into
stretch, the major damage has already been done.

There are some lesser upsides going forward though:
- the package would become more policy compliant
- no need to ship libgslcblas.so to users who never use it
- avoid accidentally breaking the package again in the unlikely event
  the SONAME is bumped again

The downside of a package transition may never materialize since I
cannot find any packages which actually link to libgslcblas.so (in a
very quick search). I guess there might be an "external packages"
downside if non-Debian packages use libgslcblas.so.

So I do think there are good reasons to do this for buster. Downgrade
the bug to wishlist if you want.

James



signature.asc
Description: OpenPGP digital signature

Bug#859494: collectd: CVE-2017-7401

[Salvatore Bonaccorso]

Source: collectd
Version: 5.4.1-6
Severity: important
Tags: security patch upstream

Hi,

the following vulnerability was published for collectd.

CVE-2017-7401[0]:
| Incorrect interaction of the parse_packet() and
| parse_part_sign_sha256() functions in network.c in collectd 5.7.1 and
| earlier allows remote attackers to cause a denial of service (infinite
| loop) of a collectd instance (configured with "SecurityLevel None" and
| with empty "AuthFile" options) via a crafted UDP packet.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-7401
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7401
[1] https://github.com/collectd/collectd/issues/2174

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#859451: dbus: error messages on boot for systems with NSS LDAP

[Laurent Bonnaud]

On 03/04/2017 20:21, Simon McVittie wrote:

> Yes: if any user or group mentioned in /etc/dbus/system.d/
> comes from LDAP, then it needs to know who they are.

This directory does not exist on this system.

> I would not recommend using non-local NSS without some sort of cache
> (unscd, nss-updatedb or sssd), 

This system has nslcd but I think it only has RAM cache and I guess that a 
cache on persistent storage would be needed.

> and doubly so if system users are in LDAP.

System users are all local in /etc/passwd.

>>  - would it be possible to order the dbus start after network is available?
> In general no, because some ways to get on the network require D-Bus
> (NetworkManager, ConnMan, wicd), so you would have a circular
> dependency.

This system is minimal and uses plain old /etc/network/interfaces

> If you don't use any of those, then you can configure this locally
> by creating /etc/systemd/system/dbus.service.d/local.conf containing
> something like this (untested and quite possibly wrong, see systemd
> documentation):
> 
> [Unit]
> Wants=network-online.target
> After=network-online.target

Thanks for this solution!  I tried it and after a limited number of boots I 
have not seen the problem again.  Since boots are non deterministic it is not a 
perfect test, and I'll let you know if I see the error messages again.

How about suggesting this solution in /usr/share/doc/dbus/README.Debian?

-- 
Laurent.

Bug#859435: linux-image-4.9.0-2-amd64: Total freeze of the PC at lightdm connexion screen

[Grand T]

Hello,

If I compile myself the kernel 4.9.20


#~/Téléchargements/linux/linux-4.9.20$ fakeroot make -j 4 deb-pkg


pkg-deb: building package 'linux-firmware-image-4.9.20' in 
'../linux-firmware-image-4.9.20_4.9.20-1_amd64.deb'.

dpkg-deb: building package 'linux-headers-4.9.20' in 
'../linux-headers-4.9.20_4.9.20-1_amd64.deb'.

dpkg-deb: building package 'linux-libc-dev' in 
'../linux-libc-dev_4.9.20-1_amd64.deb'.

dpkg-deb: building package 'linux-image-4.9.20' in 
'../linux-image-4.9.20_4.9.20-1_amd64.deb'.

dpkg-deb: building package 'linux-image-4.9.20-dbg' in 
'../linux-image-4.9.20-dbg_4.9.20-1_amd64.deb'.

dpkg-source: info: utilisation du format source « 3.0 (custom) »

dpkg-source: info: construction de linux-4.9.20 dans linux-4.9.20_4.9.20-1.dsc

dpkg-genchanges: info: inclusion du code source original dans l'envoi (« upload 
»)



~/Téléchargements/linux$ ls

linux-4.4.59

linux-4.9.20

linux-4.9.20_4.9.20-1_amd64.changes

linux-4.9.20_4.9.20-1.debian.tar.gz

linux-4.9.20_4.9.20-1.dsc

linux-4.9.20_4.9.20.orig.tar.gz

linux-4.9.20.tar.xz

linux-firmware-image-4.9.20_4.9.20-1_amd64.deb

linux-headers-4.9.20_4.9.20-1_amd64.deb

linux-image-4.9.20_4.9.20-1_amd64.deb

linux-image-4.9.20-dbg_4.9.20-1_amd64.deb

linux-libc-dev_4.9.20-1_amd64.deb



sudo dpkg -i linux-firmware-image-4.9.20_4.9.20-1_amd64.deb 
linux-headers-4.9.20_4.9.20-1_amd64.deb linux-image-4.9.20_4.9.20-1_amd64.deb



Sélection du paquet linux-firmware-image-4.9.20 précédemment désélectionné.

(Lecture de la base de données... 202471 fichiers et répertoires déjà 
installés.)

Préparation du dépaquetage de linux-firmware-image-4.9.20_4.9.20-1_amd64.deb ...

Dépaquetage de linux-firmware-image-4.9.20 (4.9.20-1) ...

Sélection du paquet linux-headers-4.9.20 précédemment désélectionné.

Préparation du dépaquetage de linux-headers-4.9.20_4.9.20-1_amd64.deb ...

Dépaquetage de linux-headers-4.9.20 (4.9.20-1) ...

Sélection du paquet linux-image-4.9.20 précédemment désélectionné.

Préparation du dépaquetage de linux-image-4.9.20_4.9.20-1_amd64.deb ...

Dépaquetage de linux-image-4.9.20 (4.9.20-1) ...

Paramétrage de linux-firmware-image-4.9.20 (4.9.20-1) ...

Paramétrage de linux-headers-4.9.20 (4.9.20-1) ...

Paramétrage de linux-image-4.9.20 (4.9.20-1) ...

Warning: Unable to find an initial ram disk that I know how to handle.

Will not try to make an initrd.

update-initramfs: Generating /boot/initrd.img-4.9.20

Création du fichier de configuration GRUB…

Found background image: /usr/share/images/desktop-base/desktop-grub.png

Image Linux trouvée : /boot/vmlinuz-4.9.20

Image mémoire initiale trouvée : /boot/initrd.img-4.9.20

Image Linux trouvée : /boot/vmlinuz-4.4.59

Image mémoire initiale trouvée : /boot/initrd.img-4.4.59

Image Linux trouvée : /boot/vmlinuz-3.16.0-4-amd64

Image mémoire initiale trouvée : /boot/initrd.img-3.16.0-4-amd64

Found memtest86+ image: /boot/memtest86+.bin

Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin

Debian GNU/Linux 8 (jessie) trouvé sur /dev/sda7

fait


I can boot my kernel 4.9 with no issue

Bug#858860: RFS: arpwatch [ITA]

[Hugo Lefeuvre]

Hi Lukas,

> > Gianfranco suggested also asking the pkg-security-team for possible
> > sponsors. It would be great if one of you could have a look and
> > provide guidance! If team maintenance is be possible, I'd like that
> > very much.
> 
> I think arpwatch would be a good fit for the team.  Is there somebody
> willing to review my packaging work?

This seems to be a good fit for the team, indeed.

https://git.somlen.de/arpwatch.git/ returns 403 Forbidden :)

Quick review:

* lintian reports

  P: arpwatch source: source-contains-data-from-ieee-data-oui-db ethercodes.dat 

  but it looks like you already fixed it. If this warning is not relevant
  anymore please override it.

* There's no copyright entry for you

Nitpicking:

in debian/changelog: why "remove dmassagevendor" ? This changelog entry
could be more verbose.

$ cme check dpkg
[...]
Warning in 'dirs:0' value 'usr/sbin': Make sure that this directory is actually 
needed. See 
L for details
Warning in 'dirs:1' value 'var/lib/arpwatch': Make sure that this directory is 
actually needed. See 
L for details
[...]
Warning in 'control source Vcs-Git' value 
'git://anonscm.debian.org/collab-maint/arpwatch.git': An unencrypted
transport protocol is used for this URI. It is recommended to use a
secure transport such as HTTPS for anonymous read-only access.

Warning in 'control source Vcs-Git' value 
'git://anonscm.debian.org/collab-maint/arpwatch.git': URL is not the
canonical one for repositories hosted on Alioth.

Warning in 'control binary:arpwatch Pre-Depends:0' value 'dpkg (>= 1.16.1)': 
unnecessary versioned dependency: dpkg (>= 1.16.1).
Debian has oldstable -> 1.16.18; stable -> 1.17.27; unstable -> 1.18.23; 
testing -> 1.18.23;

Warning in 'copyright Format' value 
'http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/': Format 
uses insecure http protocol instead of https
checking data
check done

$ codespell *
aclocal.m4:784: seperate  ==> separate
aclocal.m4:787: independantly  ==> independently
aclocal.m4:788: dependancies  ==> dependencies
arp2ethers:8: occurance  ==> occurrence
config.sub:1161: nto  ==> not  | disable due to \n
debian/changelog:129: wont  ==> won't, wont
dns.c:140: cannonical  ==> canonical
WARNING: Decoding file ethercodes.dat
WARNING: using encoding=utf-8 failed.
WARNING: Trying next encoding: iso-8859-1
ethercodes.dat:785: Intruments  ==> Instruments
ethercodes.dat:838: Aircaft  ==> Aircraft
ethercodes.dat:1180: Engeneering  ==> Engineering
ethercodes.dat:2083: Internation  ==> International
ethercodes.dat:7447: MANAGMENT  ==> MANAGEMENT

Otherwise, the package looks good. I did not review everything yet,
I'll take a second look later. :)

Cheers,
 Hugo

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E


signature.asc
Description: PGP signature

Bug#859493: libgsl2: move libgslcblas.so into a separate package

[Dirk Eddelbuettel]

On 4 April 2017 at 10:45, James Cowgill wrote:
| Package: libgsl2
| Version: 2.3+dfsg-1
| Severity: normal
| 
| Hi,
| 
| As a followup from the thread on debian-backports[1], please can you
| move libgslcblas.so from libgsl2 into a separate package. This will
| allow clean upgrades without conflicts when the SONAME of gsl is changed
| and would have avoided the current backports uninstallability situation.
| See policy 8.1 for more info about this.
| 
| This may result in a transition if there are any packages in the archive
| which use libgslcblas.so, because they will need their dependencies
| updating.

I have maintained GSL for 18 years.  The soname changed once.  Besides,
upstream is now largely stable, releases happen way fewer than before.

To be this is an issue in search of a problem, as opposed to an actual
problem.  I don't really agree with the assessment and would rather not do
this.

Dirk
 
| Thanks,
| James
| 
| [1] https://lists.debian.org/debian-backports/2017/03/msg00027.html
| 
| x[DELETED ATTACHMENT signature.asc, application/pgp-signature]

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

Bug#859004: Bug#859001: Let's remove BrowserLauncher from Stretch

[Emmanuel Bourg]

On 03/30/2017 04:30 PM, Ole Streicher wrote:


One question here: the tutorial [1] says

"Use the isDesktopSupported() method to determine whether the Desktop
API is available. On the Solaris Operating System and the Linux
platform, this API is dependent on Gnome libraries. If those libraries
are unavailable, this method will return false. After determining that
the Desktop API is supported, that is, the isDesktopSupported() returns
true, the application can retrieve a Desktop instance using the static
method getDesktop()."

So, on a random (minimal) Debian (Jessie/Stretch) installation, how safe
is it to assume that this works when default-jre is installed? And do I
need to check if Desktop.Action.BROWSE is available or can I safely
assume it?


Excellent question, this needs some testing with various desktop 
environments.


Emmanuel Bourg

Bug#859478: offlineimap: 'maxage' comments are wrong, offlineimap DELETES your mails

[Ilias Tsitsimpis]

Control: fixed -1 6.6.0~rc3+dfsg1-1

Hi Cyril,

On Tue, Apr 04, 2017 at 01:28AM, Cyril Brulebois wrote:
> Looking at the code, it seems “is that older than maxage?” is
> implemented by looking at the timestamp in the filename for local
> mails, which happens to be October 2016 for a mail received in 2015!

Your analysis is correct. Here is a blog post which explains in depth
the above bug:

http://www.offlineimap.org/devel/2015/04/14/why-we-changed-maxage.html

This should be fixed in newer versions of OfflineIMAP. Could you please
give it a try?

You may also be interested in the 'sync_deletes' feature, introduced in
version 7.0.6+dfsg1-1. Copying from the docs:

This option stands in the [Repository RemoteExample] section.

Propagate deletions from remote to local. Messages deleted in this 
repository
won't get deleted on the local repository if set to "no". Default is yes.

Best,

-- 
Ilias

Bug#859492: mumps: Incomplete debian/copyright?

[Drew Parsons]

tags 859492 + fixed pending
thanks

On Tue, 2017-04-04 at 10:03 +0100, Chris Lamb wrote:
> 
> I just ACCEPTed mumps from NEW but noticed it was missing
> attribution 
> in debian/copyright for at least src/ana_orderings.F.
> 
> (This is not exhaustive so please check over the entire package 
> carefully and address these on your next upload.)
> 

Thanks Chris, I've added a copyright entry in git.

A copyright grep doesn't show up any other anomalies.

Drew

Bug#673515: ETA ?

[Apollon Oikonomopoulos]

Hi,

On 14:26 Sun 02 Apr , Varac wrote:
> Hi,
> 
> I second Geert, it's awesome to see progress on this !
> 
> I need to migrate my v3 puppetmaster to v4 soon and am wondering when
> puppetdb could make it into debian. Or if it's worth waiting for it or
> using puppetlabs packages for now.

I'm working on this (although a bit slowly). I'd say around mid-May is a 
reasonable date to expect this to be finished, if all goes well.

Regards,
Apollon

Bug#858187: boinc-manager: boincmgr suddenly needs -d /etc/boinc-client

[Christian Beer]

On 04.04.2017 11:34, Christian Beer wrote:
> It spawns the window but it does not show any information. It does not
> "connect" to the client. I could reproduce this with 7.6.33+dfsg-10
> without a password set. I can also not select "localhost" using the
> manager as this uses a password internally. This was fixed in
> https://github.com/BOINC/boinc/pull/1789 but not ported to Debian. This
> only has an effect on the dialog not on the commandline argument but we
> might be uncovering a similar issue there too.

Addendum: I couldn't reproduce this with a build from master
immediately, but if I don't leave my home directory I could reproduce
it. Even the build from master with PR1820 applied shows this behavior.
If I start the Manager while my current directory is not my home
directory (e.g. /, /usr/bin/, ~/someotherdir/) the command "boincmgr -n
localhost" works as expected (for both versions Debian and master+1820)
and shows me the client information. It just doesn't work when you run
it in your home directory which is the place I would expect it to work
not the other way around.

Regards
Christian

Bug#859001: Let's remove BrowserLauncher from Stretch

[Ole Streicher]

Hi Emmanuel,

Am 04.04.2017 um 10:52 schrieb Emmanuel Bourg:
> Excellent question, this needs some testing with various desktop
> environments.

I wrote a short test script and run it under Stretch and Jessie chroots,
right after

(jessie)oles@donar:~$ sudo apt install default-jre

---8<--
import java.awt.Desktop;
import java.net.URI;

class DesktopTest {
public static void main(String[] args) throws Exception {
System.out.println("isDesktopSupported()="
   + Desktop.isDesktopSupported());
Desktop d = Desktop.getDesktop();
System.out.println("Desktop=" + d);
System.out.println("Browse supported="
   + d.isSupported(Desktop.Action.BROWSE));
d.browse(new URI("https://www.debian.org;));
}
}
---8<--

with the following output:

(jessie)oles@donar:~$ java Desktop
isDesktopSupported()=true
Desktop=java.awt.Desktop@669e9a07
Browse supported=true
Exception in thread "main" java.io.IOException: Failed to show
URI:https://www.debian.org
at sun.awt.X11.XDesktopPeer.launch(XDesktopPeer.java:114)
at sun.awt.X11.XDesktopPeer.browse(XDesktopPeer.java:98)
at java.awt.Desktop.browse(Desktop.java:386)
at Desktop.main(Desktop.java:9)

So, on a default (not headless) Java installation, Java claims to both
isDesktopSupported() and isSupported(Desktop.Action.BROWSE).

The exception may be due to the fact that my Browser was running outside
of the schroot, that the dbus was not started ("xdg-open" shows this as
error), or that some other required component is not there.

Desktop#browse() calls the native function gnome_url_show() in
XDesktopPeer.java:

https://developer.gnome.org/libgnome/stable/libgnome-gnome-url.html

Best regards

Ole

Bug#859493: libgsl2: move libgslcblas.so into a separate package

[James Cowgill]

Package: libgsl2
Version: 2.3+dfsg-1
Severity: normal

Hi,

As a followup from the thread on debian-backports[1], please can you
move libgslcblas.so from libgsl2 into a separate package. This will
allow clean upgrades without conflicts when the SONAME of gsl is changed
and would have avoided the current backports uninstallability situation.
See policy 8.1 for more info about this.

This may result in a transition if there are any packages in the archive
which use libgslcblas.so, because they will need their dependencies
updating.

Thanks,
James

[1] https://lists.debian.org/debian-backports/2017/03/msg00027.html



signature.asc
Description: OpenPGP digital signature

Bug#631991: libmaven-ant-tasks-java is missing all its dependencies.

[Emmanuel Bourg]

On 04/03/2017 08:26 PM, Adrian Bunk wrote:


Missing dependencies are considered RC.

Adding ${maven:Depends} to Depends adds dependencies that look correct,
but someone should double-check whether this is the correct fix.


Actually the dependencies are embedded in the jar generated, so there is 
no need to declare the dependencies on the package.


Emmanuel Bourg

Bug#858187: boinc-manager: boincmgr suddenly needs -d /etc/boinc-client

[Christian Beer]

On 04.04.2017 09:55, Gianfranco Costamagna wrote:
> Hello
>
>> $ boincmgr -n localhost
>> [fails]
> (it spawns correctly the window to me, but not the second time I run it, I 
> mean
> only when no windows are already open)
It spawns the window but it does not show any information. It does not
"connect" to the client. I could reproduce this with 7.6.33+dfsg-10
without a password set. I can also not select "localhost" using the
manager as this uses a password internally. This was fixed in
https://github.com/BOINC/boinc/pull/1789 but not ported to Debian. This
only has an effect on the dialog not on the commandline argument but we
might be uncovering a similar issue there too.

>> $ boincmgr -n localhost -d /etc/boinc-client
>> [works]
>
> works in the same way, no previous windows have to be already open

This works for me (Manager shows information from client when windows is
spawned) but I don't know why since the gui_rpc_auth.cfg is still not
readable by me (on purpose). I'm looking into why one works and the
other does not.

Regards
Christian

Bug#859378: unblock: screen/4.5.0-5 (pre-approval)

[Axel Beckert]

Control: tag -1 - moreinfo

Hi,

Niels Thykier wrote:
> Ack, please go ahead, thanks.

Uploaded last night, built fine on all architectures, hence removing
the moreinfo tag.

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#859492: mumps: Incomplete debian/copyright?

[Chris Lamb]

Source: mumps
Version: 5.1.1-1exp1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Drew Parsons 

Hi,

I just ACCEPTed mumps from NEW but noticed it was missing attribution 
in debian/copyright for at least src/ana_orderings.F.

(This is not exhaustive so please check over the entire package 
carefully and address these on your next upload.)


Regards,

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

Bug#859491: systemd socket activation is missing in 0.9.4c

[Alec Leamas]

Package: lirc
Version: 0.9.4c-8

This is a tracker for upstream bug 
https://sourceforge.net/p/lirc/tickets/274/ Due to upstream systemd 
changes, lirc fails to use systemd activation. This causes subtle bugs 
during system boot.

Bug#859111: [Debian-med-packaging] Bug#859111: ariba: FTBFS: FAIL: Test run_bowtie2 unsorted

[Sascha Steinbiss]

Hi all,

>> Control: retitle -1 ariba FTBFS with bowtie2 2.3.1-1
> [...]
>> This is actually not related to the ariba version but to the bowtie2 version,
>> ariba 2.6.1+ds-1 in stretch builds with the stretch bowtie2 2.3.0-2 but 
>> FTBFS with the sid bowtie2 2.3.1-1
> 
> Do we already know whether the newer upstream version fixes this?
> 
> Sascha: could you try to import it and pehaps upload it to unstable?
> Given there is already a difference between testing and unstable (2.6.1
> vs 2.7.1) it shouldn't make much difference at this point even in the
> freeze…

Sure, I can do this later today when I find some time. I'm a bit busy
atm with unrelated work but will get back to it.

Cheers
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#859490: unblock: haproxy/1.7.5-1 (pre-approval)

[Apollon Oikonomopoulos]

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

Dear Release Team,

We would like to upload HAProxy 1.7.5 to unstable and have it migrate to 
testing. Upstream says:

Released version 1.7.5 with the following main changes :
- BUG/MEDIUM: peers: fix buffer overflow control in intdecode.
- BUG/MEDIUM: buffers: Fix how input/output data are injected into 
buffers
- BUG/MEDIUM: http: Fix blocked HTTP/1.0 responses when compression is 
enabled
- BUG/MINOR: filters: Don't force the stream's wakeup when we wait in 
flt_end_analyze
- DOC: fix parenthesis and add missing "Example" tags
- DOC: update the contributing file
- DOC: log-format/tcplog/httplog update
- MINOR: config parsing: add warning when log-format/tcplog/httplog is 
overriden in "defaults" sections

Some background on the bugs fixed can be found at 
https://www.mail-archive.com/haproxy@formilux.org/msg25574.html

The code (src/ + include/) diffstat is as follows:

 include/common/buffer.h | 60 
++--
 src/cfgparse.c  | 38 ++
 src/channel.c   |  6 +++---
 src/filters.c   |  7 +--
 src/peers.c | 49 +++--
 src/proto_http.c| 24 +++-
 6 files changed, 122 insertions(+), 62 deletions(-)

See also the attached diff.

Can we proceed with the upload?

Regards,
Apollon

unblock haproxy/1.7.5-1
diff --git a/include/common/buffer.h b/include/common/buffer.h
index ce3eb40a..3a6dfd7f 100644
--- a/include/common/buffer.h
+++ b/include/common/buffer.h
@@ -156,6 +156,41 @@ static inline int bo_contig_data(const struct buffer *b)
 	return b->o;
 }
 
+/* Return the amount of bytes that can be written into the input area at once
+ * including reserved space which may be overwritten (this is the caller
+ * responsibility to know if the reserved space is protected or not).
+*/
+static inline int bi_contig_space(const struct buffer *b)
+{
+	const char *left, *right;
+
+	left  = bi_end(b);
+	right = bo_ptr(b);
+
+	if (left >= right)
+		right = b->data + b->size;
+
+	return (right - left);
+}
+
+/* Return the amount of bytes that can be written into the output area at once
+ * including reserved space which may be overwritten (this is the caller
+ * responsibility to know if the reserved space is protected or not). Input data
+ * are assumed to not exist.
+*/
+static inline int bo_contig_space(const struct buffer *b)
+{
+	const char *left, *right;
+
+	left  = bo_end(b);
+	right = bo_ptr(b);
+
+	if (left >= right)
+		right = b->data + b->size;
+
+	return (right - left);
+}
+
 /* Return the buffer's length in bytes by summing the input and the output */
 static inline int buffer_len(const struct buffer *buf)
 {
@@ -226,21 +261,6 @@ static inline int buffer_contig_area(const struct buffer *buf, const char *start
 	return count;
 }
 
-/* Return the amount of bytes that can be written into the buffer at once,
- * including reserved space which may be overwritten.
- */
-static inline int buffer_contig_space(const struct buffer *buf)
-{
-	const char *left, *right;
-
-	if (buf->data + buf->o <= buf->p)
-		right = buf->data + buf->size;
-	else
-		right = buf->p + buf->size - buf->o;
-
-	left = buffer_wrap_add(buf, buf->p + buf->i);
-	return right - left;
-}
 
 /* Returns the amount of byte that can be written starting from  into the
  * input buffer at once, including reserved space which may be overwritten.
@@ -340,17 +360,13 @@ static inline void bi_fast_delete(struct buffer *buf, int n)
 	buf->p += n;
 }
 
-/*
- * Tries to realign the given buffer, and returns how many bytes can be written
- * there at once without overwriting anything.
- */
-static inline int buffer_realign(struct buffer *buf)
+/* Tries to realign the given buffer. */
+static inline void buffer_realign(struct buffer *buf)
 {
 	if (!(buf->i | buf->o)) {
 		/* let's realign the buffer to optimize I/O */
 		buf->p = buf->data;
 	}
-	return buffer_contig_space(buf);
 }
 
 /* Schedule all remaining buffer data to be sent. ->o is not touched if it
@@ -402,7 +418,7 @@ static inline int bo_putblk(struct buffer *b, const char *blk, int len)
 	if (!len)
 		return 0;
 
-	half = buffer_contig_space(b);
+	half = bo_contig_space(b);
 	if (half > len)
 		half = len;
 
diff --git a/src/cfgparse.c b/src/cfgparse.c
index 074d5e67..95e95f62 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -4792,6 +4792,21 @@ stats_error_parsing:
 if (alertif_too_many_args_idx(1, 1, file, linenum, args, _code))
 	goto out;
 			}
+			if (curproxy->conf.logformat_string && curproxy == ) {
+char *oldlogformat = "log-format";
+char *clflogformat = "";
+
+if (curproxy->conf.logformat_string == default_http_log_format)
+	oldlogformat = "option httplog";
+else if (curproxy->conf.logformat_string == 

Bug#859360: [pkg-go] Bug#859360: Bug#859360: New version of golang-github-azure-azure-sdk-for-go-dev available upstream: 9.0.0-beta

[Potter, Tim]

On 3 Apr 2017, at 10:27 AM, Martín Ferrari  wrote:
> 
> On 02/04/17 20:15, Jeffrey Cliff wrote:
>> Package: golang-github-azure-azure-sdk-for-go-dev
>> Version: 2.1.1~beta-3
>> 
>> Upstream at github ( https://github.com/Azure/azure-sdk-for-go/releases
>> ) there's been quite a bit of development activity (950+ commits) on the
>> azure sdk and in particular ethereum has upgraded their required version
>> to version 6.0.
> 
> Wow, they sure seem to like to make major releases! :)
> 
> We will have to see how to do this update without breaking stuff. I
> can't imagine this will be API-compatible with 2.x?

Yes that's pretty nuts.  I'm poking around at devendoring things for Kubernetes,
and it requires v7.0.1-beta so I'm keen on seeing this package updated as well.


Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#858883: nslcd : missing symbols : _nss_ldap_version and _nss_ldap_enablelookups

[Laurent Bonnaud]

On 03/04/2017 20:27, Arthur de Jong wrote:

> Having the wrong NSS module installed should also explain this.

Yes and since I switched from libnss-ldap to libnss-ldapd the error messages 
from nslcd disappeared.  

This bug can be closed and you have probably seen my other bug report about 
mixing LDAP and NSS packages.

Thanks for you help!

-- 
Laurent.

Bug#859489: unblock: tryton-server/4.2.1-2

[Mathias Behrle]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: maintain...@debian.tryton.org


Please unblock package tryton-server

Version 4.2.1-2 fixes CVE-2017-0360 in unstable/testing.

unblock: tryton-server/4.2.1-2

-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6


pgpAYZdDOtxiI.pgp
Description: Digitale Signatur von OpenPGP

Bug#855911: linux-image-4.9.0-1-armmp: MMC failure on A20-OLinuXIno-LIME2

[Thibaut Girka]

After a little less than two weeks running on 4.8, the second board finally
crashed during an “aptitude update” with:

1062229.158740] mmc0: Card stuck in programming state! mmc_do_erase
[1062229.933728] sunxi-mmc 1c0f000.mmc: fatal err update clk timeout
[1062230.708711] sunxi-mmc 1c0f000.mmc: fatal err update clk timeout
[1062231.463699] sunxi-mmc 1c0f000.mmc: fatal err update clk timeout
[1062231.470938] mmc0: tried to reset card, got error -5
[1062231.476059] blk_update_request: I/O error, dev mmcblk0, sector 21346248
[1062231.483160] mmcblk0: error -5 sending status command, retrying
[1062231.489265] mmcblk0: error -5 sending status command, retrying
[1062231.495340] mmcblk0: error -5 sending status command, aborting
[1062232.268669] sunxi-mmc 1c0f000.mmc: fatal err update clk timeout
[1062233.043649] sunxi-mmc 1c0f000.mmc: fatal err update clk timeout
[1062233.798631] sunxi-mmc 1c0f000.mmc: fatal err update clk timeout
[1062233.805874] mmc0: tried to reset card, got error -5
[1062233.810996] blk_update_request: I/O error, dev mmcblk0, sector 2205936
[1062233.817793] blk_update_request: I/O error, dev mmcblk0, sector 2205944
[1062233.824550] blk_update_request: I/O error, dev mmcblk0, sector 2205952
[1062233.831305] blk_update_request: I/O error, dev mmcblk0, sector 2205960
[1062233.838047] blk_update_request: I/O error, dev mmcblk0, sector 2205968
[1062233.844802] blk_update_request: I/O error, dev mmcblk0, sector 2205976
[1062233.851541] blk_update_request: I/O error, dev mmcblk0, sector 2205984
[1062233.858288] blk_update_request: I/O error, dev mmcblk0, sector 2205992
[1062233.865045] blk_update_request: I/O error, dev mmcblk0, sector 2206000

Note that I'm not sure I have done a cold reboot when switching from 4.9
to 4.8. It has now been running (on 4.8) for nearly a month without any issue.

On the other hand, my main board running on linux 4.4 crashed twice.
Not being physically present when it crashed today, I could not figure out if
it crashed for the same reason, but it needed a cold reboot anyway.
As for the previous crash, I was actually logged on the machine and could get
some debug output. While the error handling changed from 4.4 to 4.9, it is
much probably the same issue: any task waiting on the MMC ended up being stuck:

[147837.706454] INFO: task logrotate:31041 blocked for more than 120 seconds.
[147837.713536]   Not tainted 4.4.0-1-armmp #1
[147837.718211] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[147837.726313] logrotate   D c0663814 0 31041  31040 0x
[147837.733020] [] (__schedule) from [] (schedule+0x50/0xa8)
[147837.740386] [] (schedule) from [] 
(schedule_timeout+0x208/0x290)
[147837.748418] [] (schedule_timeout) from [] 
(io_schedule_timeout+0xc0/0x138)
[147837.757274] [] (io_schedule_timeout) from [] 
(bit_wait_io+0x20/0x6c)
[147837.765611] [] (bit_wait_io) from [] 
(__wait_on_bit+0x94/0xd0)
[147837.773430] [] (__wait_on_bit) from [] 
(wait_on_page_bit+0xdc/0xf8)
[147837.781770] [] (wait_on_page_bit) from [] 
(__filemap_fdatawait_range+0xec/0x144)
[147837.791191] [] (__filemap_fdatawait_range) from [] 
(filemap_fdatawait_range+0x28/0x44)
[147837.801206] [] (filemap_fdatawait_range) from [] 
(filemap_write_and_wait_range+0x68/0x90)
[147837.811835] [] (filemap_write_and_wait_range) from [] 
(ext4_sync_file+0x12c/0x378 [ext4])
[147837.822372] [] (ext4_sync_file [ext4]) from [] 
(vfs_fsync_range+0x68/0xc8)
[147837.831421] [] (vfs_fsync_range) from [] 
(do_fsync+0x4c/0x74)
[147837.839142] [] (do_fsync) from [] (SyS_fsync+0x1c/0x20)
[147837.846318] [] (SyS_fsync) from [] 
(ret_fast_syscall+0x0/0x3c)
[147957.848353] INFO: task jbd2/mmcblk0p1-:107 blocked for more than 120 
seconds.
[147957.855792]   Not tainted 4.4.0-1-armmp #1
[147957.860475] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[147957.868642] jbd2/mmcblk0p1- D c0663814 0   107  2 0x
[147957.875442] [] (__schedule) from [] (schedule+0x50/0xa8)
[147957.882780] [] (schedule) from [] 
(schedule_timeout+0x208/0x290)
[147957.890846] [] (schedule_timeout) from [] 
(io_schedule_timeout+0xc0/0x138)
[147957.899757] [] (io_schedule_timeout) from [] 
(bit_wait_io+0x20/0x6c)
[147957.908153] [] (bit_wait_io) from [] 
(__wait_on_bit+0x94/0xd0)
[147957.916038] [] (__wait_on_bit) from [] 
(out_of_line_wait_on_bit+0x8c/0xa8)
[147957.924934] [] (out_of_line_wait_on_bit) from [] 
(__wait_on_buffer+0x40/0x44)
[147957.934222] [] (__wait_on_buffer) from [] 
(jbd2_journal_commit_transaction+0xcec/0x1760 [jbd2])
[147957.945065] [] (jbd2_journal_commit_transaction [jbd2]) from 
[] (kjournald2+0x108/0x2d0 [jbd2])
[147957.955886] [] (kjournald2 [jbd2]) from [] 
(kthread+0xfc/0x114)
[147957.963900] [] (kthread) from [] 
(ret_from_fork+0x14/0x3c)
[147957.971453] INFO: task openvpn:795 blocked for more than 120 seconds.
[147957.978144]   Not tainted 4.4.0-1-armmp #1
[147957.982813] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 

Bug#858187: boinc-manager: boincmgr suddenly needs -d /etc/boinc-client

[Gianfranco Costamagna]

Hello

>$ boincmgr -n localhost

>[fails]

(it spawns correctly the window to me, but not the second time I run it, I mean
only when no windows are already open)
>$ boincmgr -n localhost -d /etc/boinc-client
>[works]


works in the same way, no previous windows have to be already open

>$ dpkg -l boinc-manager|cat>Desired=Unknown/Install/Remove/Purge/Hold
>| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>||/ Name   VersionArchitecture Description
>+++-==-==--
>
>ii  boinc-manager  7.6.33+dfsg-10 amd64GUI to control and monitor the 
>BOINC core client


dpkg -l boinc-manager|cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionArchitecture Description
+++-==-==--
ii  boinc-manager  7.6.33+dfsg-11 amd64GUI to control and monitor the 
BOINC core client


G.

Bug#395573: VisIt: current status

[Ole Streicher]

Hi Alastair,

since I was pointed to visIt by our cosmologists: what is the status of
the packaging? It looks like you restarted this two years ago, but then
abandoned it. What were the difficulties, and what is the current status?

http://www.llnl.gov/visit/
https://anonscm.debian.org/cgit/debian-science/packages/visit.git

Best regards

Ole

Bug#859488: Missing dependency on python-pkg-resources

[Adrien Cunin]

Package: pwman3
Version: 0.5.1d-1
Severity: important

After installing pwman3:

# pwman3
Traceback (most recent call last):
  File "/usr/bin/pwman3", line 27, in 
from pwman import default_config, which
  File "/usr/lib/python2.7/dist-packages/pwman/__init__.py", line 22, in

import pkg_resources
ImportError: No module named pkg_resources

python-pkg-resources needs to be installed manually to fix that.

-- 
Adrien Cunin aka Adri2000
Ubuntu MOTU Developer
Debian Contributor



signature.asc
Description: OpenPGP digital signature

Bug#858187: boinc-manager: boincmgr suddenly needs -d /etc/boinc-client

[Christian Beer]

On 04.04.2017 09:00, Russell Coker wrote:
> $ boincmgr -n localhost
> [fails]
> $ boincmgr -n localhost -d /etc/boinc-client
> [works]
> $ dpkg -l boinc-manager|cat
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name   VersionArchitecture Description
> +++-==-==--
> 
> ii  boinc-manager  7.6.33+dfsg-10 amd64GUI to control and monitor the 
> BOINC core client
>
I think I know what's going on. If you start boincmgr there are two
places in the code that try to determine the location of the data and
configuration directory. We fiddled with one of those places to fix the
multiple Manager issue fixing this case. I think the previous behavior
was not intended but worked somehow.

The problem is that starting boincmgr from an arbitrary directory makes
it hard for the Manager to determine where the configuration files are
(it only looks in the current working directory). The assumption is that
boincmgr is always started in the directory where the configuration
files are (aka data directory). Using the menu links this is
automatically taken care of by changing the working directory before
starting boincmgr.

What I could imagine is a Debian specific fallback to the data directory
detection logic that first tries the current directory and if no config
files are found tries /var/lib/boinc-client/ which would restore the
previous behavior to boincmgr -n localhost that makes it independent
from the where it is started from. What I would like to investigate too
is the distinction between the -d and -e flags and what internal
variables they control in order to not create a regression and brake
something else.

Regards
Christian

Bug#856474: [PATCH] Kbuild.include: addtree: Remove quotes before matching path

[Michal Marek]

Dne 3.4.2017 v 22:20 Sam Ravnborg napsal(a):
> On Mon, Apr 03, 2017 at 03:25:10PM +0200, Michal Marek wrote:
>> On 2017-04-03 09:42, Masahiro Yamada wrote:
>>> Each Makefile knows it wants to see
>>> additional headers in the source tree, or objtree.
>>>
>>> I am guessing the right approach in a long run is,
>>> we require -I to specify $(srctree) or $(objtree) explicitly.
>>>
>>> ccflags-y := -I$(srctree)/foo/bar/baz
>>>
>>> or
>>>
>>> ccflags-y := -I$(objtree)/foo/bar/baz
>>>
>>>
>>> (For the latter, we can omit $(objtree)/ as it is ./)
>>>
>>>
>>> Then, delete $(call flags,_c_flags) after the conversion.
>>
>> Agreed. The addtree function is more of a hack to make things just work
>> with O=, but AFAIK there is no clean way to implement VPATH for -I
>> arguments. So it's sensible to get rid of the hack. It looks like it's
>> going to be lot of work though:
>>
>> $ git grep -e '-I' -- '*Makefile*' | wc -l
>> 732
>> $ git grep -e '-I *\$(\(src\|obj\)tree)' -- '*Makefile*' | wc -l
>> 166
> 
> There was a goal long time ago that moving the kernel source should
> not trigger a rebuild.
> Any hardcoded path would violate this (like $(srctree), $(objtree))
> 
> I dunno if this is really something to aim for today.
> 
> I have personally from time to time renamed the directory where
> I have kernel soruce (which is seen like moving the kernel source),
> and would not be happy if this always triggered a full rebuild.
> But this is frankly a corner case.

This should be working nowadays if you build without O= or if the
buildtree points to a subdirectory of the source tree. The srctree
variable is set to . or .. in such case. Although when I tried it now,
it still does not look perfect:

$ cd /dev/shm/mmarek/linux-2.6
$ make O=build -s defconfig
$ make O=build -s -j64
Setup is 15500 bytes (padded to 15872 bytes).
System is 6530 kB
CRC 4bc8f6e2
Kernel: arch/x86/boot/bzImage is ready  (#1)
$ grep -r $PWD build/
Binary file build/arch/x86/boot/setup.elf matches
Binary file build/arch/x86/boot/header.o matches
Binary file build/arch/x86/boot/video.o matches
Binary file build/arch/x86/boot/cpu.o matches
Binary file build/arch/x86/boot/printf.o matches
Binary file build/arch/x86/boot/string.o matches
Binary file build/arch/x86/boot/video-mode.o matches
Binary file build/arch/x86/boot/video-vga.o matches
Binary file build/arch/x86/boot/early_serial_console.o matches
Binary file build/arch/x86/boot/video-vesa.o matches
Binary file build/arch/x86/boot/cpucheck.o matches
Binary file build/arch/x86/boot/video-bios.o matches
Binary file build/arch/x86/boot/tty.o matches
Binary file build/arch/x86/boot/memory.o matches
Binary file build/arch/x86/boot/pm.o matches
Binary file build/arch/x86/boot/cmdline.o matches
Binary file build/arch/x86/boot/main.o matches
Binary file build/arch/x86/boot/a20.o matches
Binary file build/arch/x86/boot/regs.o matches
Binary file build/arch/x86/boot/version.o matches
Binary file build/arch/x86/boot/edd.o matches
Binary file build/arch/x86/boot/cpuflags.o matches
Binary file build/arch/x86/boot/pmjump.o matches
Binary file build/arch/x86/boot/copy.o matches
Binary file build/arch/x86/boot/bioscall.o matches
Binary file build/arch/x86/realmode/rm/video-bios.o matches
Binary file build/arch/x86/realmode/rm/video-mode.o matches
Binary file build/arch/x86/realmode/rm/video-vga.o matches
Binary file build/arch/x86/realmode/rm/video-vesa.o matches
Binary file build/arch/x86/realmode/rm/wakemain.o matches
Binary file build/arch/x86/realmode/rm/regs.o matches
Binary file build/arch/x86/realmode/rm/trampoline_64.o matches
Binary file build/arch/x86/realmode/rm/wakeup_asm.o matches
Binary file build/arch/x86/realmode/rm/copy.o matches
Binary file build/arch/x86/realmode/rm/bioscall.o matches
Binary file build/arch/x86/realmode/rm/reboot.o matches

All the 32bit object files contain the full path, but none of the .cmd
files do?! And we do trigger rebuild of a few files after moving the
tree, but we do so even in the original location, so it looks like
somebody got a custom rule wrong again.

Michal

Bug#859435: linux-image-4.9.0-2-amd64: Total freeze of the PC at lightdm connexion screen

[Grand T]

Hello,

If I compile myself the kernel 4.4.59 from https://www.kernel.org/

The Linux Kernel Archives
www.kernel.org
This site is operated by the Linux Kernel Organization, Inc., a 501(c)3 
nonprofit corporation, with support from the following sponsors. ...


cp /boot/config-3.16.0-4-amd64 .config

make olddefconfig

fakeroot make -j 4 deb-pkg


then

sudo dpkg -i linux-firmware-image-4.4.59_4.4.59-1_amd64.deb 
linux-headers-4.4.59_4.4.59-1_amd64.deb linux-libc-dev_4.4.59-1_amd64.deb 
linux-image-4.4.59_4.4.59-1_amd64.deb


then using Synaptic

Les paquets suivants ont été mis à jour :

linux-libc-dev (4.4.59-1) to 4.9.13-1


Les paquets suivants ont été réinstallés :

libc6-dev (2.24-9)


I can boot the kernel 4.4.59 with no issue

Bug#858881: pandas CI test fails

[Rebecca N. Palmer]

Control: retitle -1 pandas: several CI tests fail

This isn't the only problem:

-test_set_locale: this one passes when I run it manually, which vaguely 
suggests a missing dependency, but I don't know which one.


-test_binary_ops, test_mixed_arithmetic*: "Integers to negative integer 
powers are not allowed" due to a numpy change in 1.12.  Known upstream 
as https://github.com/pandas-dev/pandas/issues/15363, where the 
workaround is to skip the 'pow' part of these tests.


-test_integer_panel (Python 2 only): integer overflow in the 'pow' test.

Bug#858187: boinc-manager: boincmgr suddenly needs -d /etc/boinc-client

[Russell Coker]

reopen 858187
thanks

On Tue, 4 Apr 2017 04:14:09 PM Gianfranco Costamagna wrote:
> control: fixed -1 7.6.33+dfsg-10
> control: close -1
> 
> Hello,
> 
> >Version: 7.6.33+dfsg-10
> 
> actually this version should be working (I broke it between -6 and -9, but
> thanks to Christian I fixed it)
> 
> please reopen if this isn't the case

$ boincmgr -n localhost
[fails]
$ boincmgr -n localhost -d /etc/boinc-client
[works]
$ dpkg -l boinc-manager|cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionArchitecture Description
+++-==-==--

ii  boinc-manager  7.6.33+dfsg-10 amd64GUI to control and monitor the 
BOINC core client

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#856610: unblock: sqlalchemy/1.1.5+ds1-1

[Piotr Ożarowski]

Control: tags -1 - moreinfo

> that's because Thomas overwrote my NMU with another upload, please give
> me some time to talk with him

Thomas added my changes back, all 3 OpenStack packages have ">="
dependency only (no "<<" anymore)

Bug#848015: ciphersaber: diff for NMU version 1.01-2.1

[Stefan Hornburg (Racke)]

On 04/04/2017 07:01 AM, Mattia Rizzolo wrote:
> Control: tags 848015 + patch
> Control: tags 848015 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for ciphersaber (versioned as 1.01-2.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
> 

Dear Mattia,

the patch looks good to me.

Thanks a lot

   Racke

-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration.



signature.asc
Description: OpenPGP digital signature

Bug#859487: probably wrong dependencies on systemd startup unit

[Michael Tokarev]

Package: openbsd-inetd
Version: 0.20160825-2
Severity: normal

During system startup, inetd starts before networking, when local
IP addresses hasn't been configured yet.

As a result, services bound to specific IP addresses in inetd.conf
can't be started, for example on my system it complains

  netd[278]: 3142/tcp: bind: Cannot assign requested address

and apt cacher service (bound to a local interface) doesn't work
until I restart inetd manually.

Version of systemd on the system is 232-19, it looks like everything
worked fine with jessie version of systemd, but it was most likely
due to pure luck, not by design.

Thanks,

/mj

Bug#859346: unar revisions

[David Hedlund]

Debian BTS administrators >


Is that where I should send my recommendation?



On 2017-04-04 03:21, kr...@ftbfs.org wrote:

Hi,

Thanks for the suggestion.  Documenting which archive versions are 
supported sounds like a good idea.


I think you should report this to the upstream BTS, though, since we 
have no control over their website.


--
Matt

On Apr 2, 2017 10:20 AM, David Hedlund  wrote:

Package: unar
Version: 1.8.1-2

http://unarchiver.c3.cx/formats says that RAR is fully supported
"Including encryption and multiple volumes. Can also extract .EXE
self-extracting files using RAR."

With my version I could not extract RAR 1.3 and 5.0 archives.

* unar rar50.rar
rar50.rar: Couldn't recognize the archive format.
* unar rar13.rar
rar13.rar: RAR
Archive parsing failed! (File is not fully supported.)
No files extracted.


I got the sample files sent from rarlab.com so they are not corrupt.


#
Questions


* Can you please add a new colum, "Revision", in
http://unarchiver.c3.cx/formats in this order: "Format, Revision,
Support level, Notes"?


* Can you please also state which archives and archive *revisions*
that are supported in each further versions of the package "unar"?

Bug#859378: unblock: screen/4.5.0-5 (pre-approval)

[Niels Thykier]

Niels Thykier:
> Control: tags -1 confirmed moreinfo
> 
> Axel Beckert:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>>
>> Dear Release Team,
>>
>> https://bugs.debian.org/856824 (which I already fixed in experimental
>> a while ago) seems to be more severe than I initially thought. If
>> unfixed, it can lead to a race condition at boot time when running
>> with systemd as init system. See Marc's explanations at
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856824#24
>>
>> So I would upload screen/4.5.0-5 with the same fix as already applied
>> in experimental (and with no issues or bug reports there so far) to
>> unstable, too, if you're ok with it.
>>
>> I've prepared the upload in the "stretch" branch at
>> https://anonscm.debian.org/cgit/collab-maint/screen.git/log/?h=stretch
>>
>> The diff as currently committed to git (still at UNRELEASED on
>> purpose) is following, git I recommend to checkout the git
>> repository and run the following command instead:
>>
>>   git show 360c7cbfbe4dd7f2dac029b371da973731e4c2ad --color-words=.
>>
>> It makes clear that all of the commit is only removing the string
>> "var/" over and over again. Nevertheless here's the classic diff for
>> the change:
>>
>> [...]
> 
> 
> Ack, please go ahead, thanks.
> 
> ~Niels
> 


CC'ing KiBi for a d-i ack.

Thanks,
~Niels

Bug#533708: Packaging libhugetlbfs

[Punit Agrawal]

Brief update...

Turns out packaging a library needs a bit more care than a binary
package. I've now uploaded the current state of libhugetlbfs package
to github[0]. There are few issues with packaging that I'm working
through.

I would like to have the package ready for soon after the end of
freeze for stretch.

[0] https://github.com/punitagrawal/libhugetlbfs